集中予約システム開発記 第２章 プロジェクト・キックオフとキーメンバー選出

　こんばんは、たっちです。

　不定期更新の３回目です。

　前回、新予約システムの決裁をもらい、システム開発に着手しましたので、最初に行ったのは、プロジェクト・キックオフの準備です。

プロジェクト・キックオフ準備

　正直情報システム部門でプロジェクト・キックオフを行うのは私が知る限り初めてです。

　私の移動前に大手ＳＩｅｒがやった某システムの刷新プロジェクトや、全社プロジェクトのキックオフはありましたが、情報システム部門が主催するプロジェクト・キックオフは初めてでした。

　プロジェクト・キックオフに向けてまずは事前準備と言う名のネゴです。

・プロジェクトオーナーの設定

・プロジェクトメンバー選出

・プロジェクト体制の決定と承認

・全体スケジュールの決定

・プロジェクトの目的と狙いの設定

プロジェクトオーナーの設定

　プロジェクトを進めるために重要なのはプロジェクトオーナーの設定です。

　今回のシステムが多くの部門の業務プロセスに影響すること、そしてそのために新しいルールを沢山決めないといけないことがあります。　そのため、ある程度の決定力と影響力のある方を据える必要があります。

　新しいルールを決めても、現場側がごねると業務プロセスが変わらなかったりしますので。

　そういった点で、今回は予約システムということで、集客営業部門とホテルの予約部門のトップの統轄部長が受けて戴くことができ、ホテル部門の本部長にも承諾も得ることが出来ました。

プロジェクトメンバー選出

　続いてプロジェクトメンバーの選出です。

　情報システム部門は私がプロジェクトリーダー、私の上司がプロジェクトマネージャーとして置き、業務チームの責任者にプロジェクトオーナー配下の営業部門のスタッフＩさん、今回ターゲットホテルになっている蓼科のホテルの予約部門責任者のＹさん、予約部門の影の支配者（笑）のＴさんに各セクションリーダーを担当してもらい、そこに各ホテル、各営業所の予約担当者を選出してもらって体制を作りました。

　そして毎月１回定期的に全体ミーティングを設定し、ルールの決定、運用方法の決定などを行うようにしました。

プロジェクト体制の決定と承認

　ということで、プロジェクト体制を決定し、関係部門の承諾をもらい本格的にプロジェクトの着手です。毎月名古屋に集まって貰わないといけませんので。今の時代であれば、ｚｏｏｍでオンラインというのも出来ましたが、オンサイトは膝詰めで話が出来たのは、反発の多い案件でしたので、有効だったと思います。

全体的スケジュールの決定

　スケジュールは新規開業のホテルが控えている事もあり、大筋は決まっていました。

　１１月に予約開始、３月オープンですのでシステムの本稼働は１１月という事になります。

　今回はいきなり前ホテルに導入ではなく、１ホテルづつ切り替えすることにしました。

　そのため新予約システムを利用するのは、対象ホテルの予約をするときのみ、というルールにしたため、さほど混乱はありませんでした。

　今までは、他のホテルを予約する際は、要望を聞いてから、利用ホテルに確認して、お客様には折り返し返事する方法から、新ホテルを取るときだけ、新予約システムにいきなり入力して、部屋が空いていれば、予約ＯＫとその場でお客様に返事出きるので、メリットが多かったため、その利便性を理解するにはちょうど良かったと思います。

　そうすることで、未導入のホテルからは早く自分のホテルにも導入して欲しいという声があがりましたから。

プロジェクトの目的と狙い

　プロジェクトを立ち上げる際に、私が部下に口酸っぱく言い続けていることが、プロジェクトの目的と狙いをにゃんと定義すること。

　良くシステムの目的が手段になることが多く、その都度突っ返しています。

　『目的　業務効率のため○○システムを導入する』なんて書いてあれば即書き直しさせます。

　システムを導入するのは目的ではなく手段です。これ一番大事。特にユーザーからの要望にはこう書かれている事が多いです。

　システムを入れることで、何がどうなるかをはっきりとさせることが大切です。

　３０年近く前の事なので正確には憶えていませんが、だいたいこんな事だったと思います。

目　的：

　全ての予約情報を一元化することで、どこからでも簡単に全ての予約が取れるようにする

ねらい：

　１．お客様から予約の申込みがあった際に、即時に予約回答ができるようになる。

　２．紙の予約カード、台帳を廃止し、全てコンピュータで管理する

　３．全ての予約受付拠点（ホテル、営業所）で全てのホテルの部屋、レストランの空き状況が分かり、予約することが可能になる。

　４．予約のローカルルールは廃止し、システムでルールを管理できるようにする。

共通課題：

　プロジェクトメンバーで認識しておいてほしい点を先に提示しました。

　・部屋の空室状況が公開されること

　・空いていれば、勝手に予約が入ってくること

　・ローカルルールは廃止すること

　・予約はその場で処理すること

　・台帳などの紙管理は廃止してもらうこと

　現場からは反発になりそうな事を先手を打っておくということです。

　こちらを準備してキックオフに臨んだわけです。

集中予約システム開発記 第１章 企画と承認

　こんばんは、たっちです。

　前回から始めた集中予約システムの取組の振り返りから教訓を振り返るシリーズです。

　ホテルシステムをよく分かっていないＳＩが手を出すと大火傷をします。あくまで当時はですが。

　今はＵＩＵＸや操作性、レスポンスなどには敏感になっているので、それほどではないと思いますが、どの点に重きを置くかを理解しておく必要があります。

現状の課題整理

　よく課題を整理すると言われますが、だいたいそう言うときに出てくるのは、事象であったり、問題点が出てきます。

　『課題とは解決する（できる）ことである』

　現場の人に業務で困っていること、問題はないですか？改善すべき事はなんですか？と聞くと、山のように出てきます。

　・顧客管理システムがない

　・チェックインに時間がかかる

　・紙が多い　などなど。

　以前、とある有名な外資系コンサルティングファームのコンサルタントがこれらの『課題』について、報告書が出てたのですが、内容をみてびっくりしました。

『課題』

　　・顧客管理システムがない

『解決方法』

　　・顧客管理システムを導入する

　思わず吹き出しそうでした（吹き出しましたが）

　こんな回答の為にん千万掛けるのか・・

　いや、ちゃんとしたコンサルタントは居ますので・・そこはご理解ください。

　当然、間にはそれなりの資料は入っていますが、中身がカスカスなので、これじゃ割に合わないと言うことで、そこで終わって貰いましたが。

　上からの話しなので、費用とははまあ、目をつぶってです。

教訓　コンサルはピンキリ。はずれを引かないようにコンサルタントの見極めは重要。

　コンサルを使うと、コンサルからあれやって、これやってと、納品物の資料の素材集めばかり頼んでくるのははずれ多し。

　現場で問題分析とか、本当にこまっていること、真因を見つけにいこうとするコンサルタントは役に立ちます。

『顧客管理システムがない』

　この手の話で良くやるのは、なぜなぜ分析からですね。

　『顧客管理システムがないのか』

　　→なぜ顧客管理が出来ないのか？

　　　「顧客の特定が出来ないから」

　　　→なぜ顧客の特定が出来ないのか？

　　　　「チェックインするまで実際の利用者がわからないから」

　　　　→なぜチェックインするまで利用者が出来ないのか？

　　　　　「会員制ホテルのため、予約は会員様から予約がはいるため」

　　→顧客管理システムがないと何が困るのか？

　　　「宿泊者の好みや、趣味嗜好がわかるとより良いサービスができるようにかるから」

　　　→趣味嗜好はどうやって入手できるのか

　　　　「お客様との会話から入手している」

　みたいな禅問答のような会話から、本当に必要な事や要求を導き出していきます。

　２５年前の結論は、利用者の特定が出来ないから、会員制ホテルだからこそ、会員ご本人だけはデータで管理できるようにしよう。

　その後、ゲストの話が何度も出てきますが、最終的にはゲストの顧客管理は実装しておりません。

『紙が多い』

　アナログ→デジタルの臭いがプンプンします。

　→なぜ紙が多いのか？

　　「ホテルの予約連絡にＦＡＸでやりとりをしている」

　　→なぜ予約を紙でやり取りするのか？

　　　「伝達ミスと受取の記録をのこすため」

　　　→なぜ記録を残すのか

　　　　「先方から届いていないと言われる事があるので相互確認のため」

　このＦＡＸのやり取りのため、１日ＦＡＸが５００枚近くになっていました。そのため、このＦＡＸを無くすことが目的の一つとなりました。

　またこのＦＡＸの多さの理由が会員制ホテルのため、予約時は会員権所有のホテルに電話をして、会員権の権利を確認した上で予約を取る必要があり、これをオンラインでできるようにする事が重要なポイントになりました。

ゴール

・社内ＦＡＸでのやりとりをなくす。

・どこからでもすべてのホテルが予約できるようにする。

　今では当たり前の事ですが、２５年前はある意味チャレンジャブルな目標でした。

システム開発のために解決しなければならないこと

　過去の経験から単純にシステム作って終わりではありません。

　今回は大幅な業務プロセスを変える必要があるためです。

①他のホテルから勝手に予約を取れるようにする

②予約時に紙の予約カードを書かずに直接コンピューターに入力する

③ホテル毎のルールは廃止し、名称、ルールなどを統一化する

　今までのやり方を１８０度変える運用は現場から猛反発がありました。

　システムに直接入力するなんて無理。他のホテルから勝手に部屋を使われるとコントロールが出来ない。部屋の在庫管理の方法は自分の所の方法じゃなきゃいやだ。などなど。

　まあ、こうなるのは想定内で、毎月全ホテルの予約担当者と営業所の予約担当者を集めて会議・会議・会議でした。

　部屋の在庫管理はブロック単位に管理できるようにして、どこからでも予約できるオープンなブロックや、自分のホテルしか予約できないブロック、営業所専用のブロックなどで管理するようにする事で、最初はＯＴＡに少しづつ部屋を出すようにオープンブロックに数部屋だす運用から徐々に増やしていって、気づいたら、殆どの部屋をオープンブロックに出すように仕向けていきました。

　コンピューターに直接入力するために、ＵＩＵＸ（当時はそんな言葉ありませんが）には意識して、わざとそれまで使っていたオフコンの画面に近い操作性にしました。

　電話で会話しながら、予約を入力する流れを作った感じです。

　そんなやりとりを延々と続け、このシステムをオープンから利用する蓼科の予約担当者とがっちり手を握って進めました。

　この時の予約担当者は私が山中湖で一緒に仕事していた人なので、かなり協力的で助かりました。

予算の役員会決裁

　システムの開発規模がだいたい詰まった所で億単位の案件でしたので、取締役会での審議です。

　実際の説明などは上司が行いましたが、説明資料などは私が作成して取締役会に挑んで無事承認。会社に入って初めて取締役会という場にでた記念すべき案件でした。

　開発パートナーはオフコンのシステムを担当していた会社に決まっておりましたので、ＲＦＰはありません。

　予約担当者会議で決めた方針に基づいて、機能概要書や画面イメージなどをペースに要件定義フェーズ、設計へと進みます。

アーキテクチャ決定

　開発パートナーは元々オフコンで保守をしてもらっていた会社。

　実は私が軽井沢で最初にさわったときは、別の会社が開発していましたが、その会社の親会社がとある事で倒産。そのシステムを引き継いでくれた会社での案件です。

　山中湖ではその会社の下請けの会社がへたこいていたのです。

　ですので、それ以来ぶりの仕事です。ＲＳ６０００での開発時はオフコンしかやれないと言うことで辞退されたのですが、その時にはオープンでやれますとのことで、復活となった訳です。

　なので、アーキテクチャから検討。でもこの時点ではデータベースはオラクルに決定していました。オラクルで開発が決まっていたので、開発言語もオラクルで揃えましょうと言うことで、Oracle Developer 2000 で開発する事に。

　これはPL/SQLで開発することで、モジュールをクライアントサイドやサーバーサイドで実行が可能ということでの採用でした。当時のことは良く覚えていませんが、要するにストアドプシージャ化がやりやすいというこですね。

　レポーティングはVB+クリスタルレポートなどで対応しました。

《決定事項》

予約画面　　Oracle Developer 2000 R2.0

フロント　　Oracle Developer 2000 R2.0

帳票印刷　　Visual Basic 6.0 +Christal Report

バッチ系　　Oracle PL/SQL

Database　　Oracle Database 8.0 EE

Windows NT 4.0 Server ＆ Workstation

ハードウェアはＮＥＣの販社でしたので、ＮＥＣは決定。

教訓

　システム導入の成功の鍵は業務プロセスをどれだけ変えることが出来て、それが利用者に受け入れられるかだ。

集中予約システムについて

　たっちです。

　ホテル会社のＩＴ部門でシステム企画とかアーキテクトとして働いています。定年が見えてきたので、自己の記録と次世代への引き継ぎのためにアウトプットしていこうと思っています。

　先日、２５年近く稼働続けたシステムのサービス停止を迎えました。

　チェーンホテルをネットワークで繋いだオンラインのホテル予約システムです。

　私がＩＴ部門に異動して最初に関わった大型案件で、システムの企画から要件定義、基本設計、使用技術選定、ユーザーとの調整から保守までずーっと関わり続けてきたシステムでした。

　当初のものから数倍の機能拡張を続けてきて、肥大化もしましたが、よくも今日まで使ってこれたと感心してしまいます。

　Windows NT4.0でカットオーバーを迎え、クライアントがWindows10、サーバーはWindows2003でひっぱり続けてきました。

　私のＩＴ人生のほとんどを占めてきたこのプロジェクトを振り返りながら、ＩＴプロジェクトで得てきた経験をアウトプットしてみようと思います。数回のシリーズになると思いますので、ぼちぼちやっていこうと思います。

序章　～集中予約システムの着手にいたるまで～

私がホテルシステムに関わった経緯

　私は今の会社に入社したのは、軽井沢に新しくホテルを建てることになり、私が前職にいた会社が運営していたビジネスホテルの支配人が今の会社に転職しており、私はその方に誘われました。

　私は前の会社で今で言う『ひとり情シス』としてシステムやパソコンの導入に関わっていた関係で引き抜いてくれた感じです。

　当然ホテルの現場ですので、ＩＴ要員ではなくフロントスタッフとしての採用です。

　当時のホテルシステムはＮＥＣ製のホテルパッケージ（ＮＥＨＯＰＳ）とアドオンで開発された予約システムで稼働しており、私はあくまでいちフロントスタッフの立場でした。

　前の会社でホテルシステムの導入や導入後のカスタマイズなんかをやっていましたので、ホテルシステムの機能やホテルオペレーションは理解をしていましたので、あまり違和感なく、仕事はこなせていました。

　ホテルシステム内部を直接触ることは出来ませんでしたので、バックオフィス業務をLotus123とかで管理レポートなんかを作って対応していました。

　そんな仕事をしているのをみた当時の総支配人が次に建てる山中湖のホテル開業に私を名指しで呼んでくれました。役割の名前は『シフトコントローラー』で後にも先にも、私一人しか付いたことのない役職でした。ただ主な仕事は総支配人の下で予実管理、次年度のみ予算策定をしつつ、フロントのヘルプや人員計画とかなんでも屋な感じだったな。

　ただこのオープン時はシステムの納品が全然間に合っておらず、グランドオープン１ヶ月前の段階でシステムの完成度は３０％ぐらいで、全然間に合いそうにありませんでした。

　というのも、軽井沢から一緒に異動してきた同僚から、私にシステムがかなりヤバい感じがすると相談があり、ホテルに詰めているＳＥさんを捕まえて詳しく話を聞いたところ、やっとソースが届いてデバッグが始まったところで、バグだらけで全然進んでいない。

　予約のレポートを出すと３つの数字がてんでバラバラで、実際の予約件数がまったく分からないというホントにヤバい状態でした。

　その状況をみて、慌てて総支配人にシステムのリカバリーに入ることの承諾を取りました。

　実は異動する際に、私にはフロントやコンピュータのことには手を出さず、総支配人の仕事を手伝ってくれと言われていたのですが、さすがにまともにオープンできないのはダメだろうと言うことで、許可を取ってしばらくシステムの稼働に注力を注ぐことになりました。

山中湖オープンまでの３週間

　まずは予約システムから。出力されるレポートがみんなバラバラの数字になるので、どれが正しいのか手拾いで集計。正しそうなものがわかれば、そのロジックから他のレポートの抽出条件を潰しにいけば、結果があってくるはず。

　ポイントはキャンセル待ちが残数に計算されているとかなので、ほぼ抽出条件とあたりを付けます。それでソースを読み込んでデバッグ。COBOLなんざ専門学校で習った以来ですがまあ、なんとかなりました。ＮＥＣのA-VXのCOBOLは初見でしたが見よう見まねでなんとかなります。

　そうやって予約数の精度が上がれば、予約はシステムを信用できるので、次のステップです。

　フロントシステムはもっとひどかった。納品されたソースをコンパイルするとエラーが山のように出てきて全く使い物にならない。

　とりあえず、チェックインとチェックアウトをできるようにして、正しい会計書を出すことだけを最優先に、日々のレポートはLotus123で集計できるようにしてオープンを迎えました。

　最終的にバグがなくなって落ち着いたのは、グランドオープンから２ヶ月が経っていました。

　その間、当時の情報システム部門の責任者が総支配人に呼び出され、その時に裏でデバッグを手伝っていた私のことが目に付いたそうで、その後に情報システム部門に引き抜かれた経緯となります。

ホテル現場で本当に必要な機能

　無事オープンできましたので、私は本来の業務に掛かります。

　ホテルシステムのレポートはどれも中途半端で使えないものが多く、ＮＥＣのCOBOLをマスターしたりファイル構造を理解したので、ここからは独自にプログラム書いて本当に必要なレポート作成に着手しました。

　山中湖でまる２年勤務しましたが、その間に作ったプログラムは５０本、レポートは１０種ぐらいになります。私の作ったプログラムはそのまま横展開され公式のプログラムとしてメンテ対応されるようになりました。

　このとき作られたプログラムはその後の再構築プロジェクトで必要なレポートととして作られる事になったので、やって良かったとおもっています。当然、最新の仕様でも組み込まれています。

ネットビジネス参入とオンライン予約システムとフロントシステム

　１９９５年２月のある日、本部の部長（入社時の総支配人）から電話が掛かってきました。

　『○○くん、元気か？そろそろホテルの仕事も飽きてきたやろ、味噌かつの生活はどうや？』と。

　３月に新しく立ち上がる全社プロジェクトのメンバーとして入れる事になったから春から名古屋に来いという異動の話でした。

　世間ではWindows95でお祭り騒ぎをしていた頃、パソコン通信を使ったオンラインのホテル予約システムの構築プロジェクトでした。

　パソコン通信からその後、インターネットへと代わりましたが、当時としては画期的な取り組みでした。

　ネットといえば、28800bpsの電話回線のモデムでしたので、コンテンツはCDｰROMで配布して、空室や予約申込みはオンラインで行うというハイブリッド方式で開発をすすめ、その後インターネットへと変わっていた仕組みです。

　その立ち上げに関わり、その後にそのシステムと連携するホテルシステムをスクラッチで開発者するための設計に関わることになりました。

　それまではオフコン一辺倒だった所から、PCサーバー（当時はWindowsNT3.51）はまだ不安定だという事でIBM RS6000 AIX(UNIX)  Sybase、PCはWindowsNT3.51で開発言語はDelphiでした。

　オンライン予約はSQLWindowだったのですが、レスポンスに苦労していたため、開発ベンダーからの提案で変更しました。

　また、そもそも上位の予約システムの機能がミニマム過ぎて予約のコントロールは各拠点側のシステムでやらざるを得ないことから、あくまでＯＴＡのひとつようなポジションだったのが、そもそもの間違いでした。

ホテルシステム開発

　ホテルシステム開発ベンダーはホテルシステムを全く知らない会社（重工系ＳＩ）でしたので、ホテルシステムコンサルを交えて要件を決めていく感じでした。

　どうにかこうにかオープンは出来て横展開もやりかけましたが、最終的に２つのホテルでやめになりました。

　致命的だったのは、レスポンスが非常に悪かった。画面の表示だけで２～３秒かかってました。

　チューニングで少し改善はしましたが、そもそもマシンパワーが足りてなかったので、私からマシンスペックアップをはじめとする進言し、RS6000は３ランクぐらい上げて、PCは当時Pentium133ぐらいだったものを直ぐに入荷できるGateway2000のPentiumPro200にグラボ追加してマシンスペックと画像処理速度の改善をしたらやっと仕えるレベルになりました。

ja.m.wikipedia.org

　ＳＥさんはチューニングでと言い張りましたが、力業のほうが早くかつ確実に結果を出せる良い例でした。

　さすがにこのまま全ホテルへの展開は厳しいと判断し、別納方法を考える必要が出てきました。

　ここからが、(先日停止した)新しい予約システムの構築ストーリーとなります。

　長い前振りですが、これまでの経験と失敗が、あったからこそ、２５年も使い続ける事のできたシステムだなと思う訳です。

教訓１　レスポンス低下は業務効率が極端に下がるので、要件にはコミットする。ＰＧチューニングもありますが、物理的な性能向上はすぐに出来ることなので、とっととやってしまえ。

　次回に続きます。

トントカイモVer.2 始動

こちらは、ＩＴ系のアウトプット主体のブログサイトです。別に旅行よりのプライベートなブログはありますが、そちらはＩＴの話はあまりしませんので、別に立てた次第です。

内容はまだ何も決まっていませんが、思いつくままにＩＴに関わる事をつづっていこうと思います。

私について

私はユーザー企業のＩＴ部門でシステム企画とかやっています。

主に社内のシステム企画やシステム導入を担当しており、時々セゾン情報システムズの DataSpider Servista を使ったデータ連携をやったりしています。そのあたりが多くなるのかなと思っています。

私の経験

ＰＣはNEC PC-8001やSharp MZ-80Kに始まり、ビジネスプログラムはFujltsu FM-11からやってきました。専門学校のあとはPC-98系のMS-BASIC、C、C++、簡易言語で業務システム開発をやったあと、今の会社ではNEC のCOBOLでプログラムメンテをやったりしましたが、それ以降は個人レベルでJAVAやRubyなんかには手を出しましたが、基幹系のシステムのプログラミングはやっていません。

今の会社にはホテルのフロントスタッフとして入社し、その後社内のＩＴプロジェクトに関わってからＩＴ部門への異動となっています。

ＩＴ部門では基幹系システムの開発や導入、社内システムのWindows化や仮想化、ＡＷＳ化を担当、事業所間ネットワークの企画・構築、中期ＩＴ計画の立案、利用技術の選定、個別ＩＴプロジェクト遂行、プロジェクト管理など、広範囲をカバーしております。

少し前に流行ったフルスタックエンジニア（＆コーディネーター）を自負しております。

今後ともよろしくお願いします。