第3章 波乱含みの要件定義
丸投げの予感
前田がリフレッシュルームから自席に戻ると、PCの画面には、キックオフと懇親会の御礼のメールに対する三上からの返信が届いていた。
返信の内容は、プロジェクトの進め方について、初回ミーティングの前に、プロジェクトマネージャーである前田に相談したい。近いうちに一度改めて、2人だけで打ち合わせの機会をほしい、という頼みだった。
「前田さん、4月10日（水曜日）のランチミーティングはいかがでしょうか。実は、その日、東京の日本橋にある当社の直営店で催事の打ち合わせがあります。御社に近い有楽町あたりで打ち合わせできると幸いです。場所はご指定のところに伺います。」と記されていた。
前田は、グループウェアのスケジュール画面で、同日昼前後の予定を確認し、「承知しました」と返信した。場所は時々足を運ぶ、パスタの美味しいカフェを指定した。
４月10日の昼、三上とカフェで前田は対面した。そこで懇親会の席で聞くことができなかった、販売部と直販部を支援する業務部業務管理課から見た社内事情を三上から聞いた。
当初、朝日製作所に頼むつもりだった総務部情報システム課、課長の佐々木の思惑をひっくり返したのが、社長の藤四郎だという。三上は、販売部長兼専務取締役の高橋が横槍を入れて、本プロジェクトに参画した経緯などを、わざわざ前田に教えてくれた。新米プロジェクトマネージャーの前田に対して、プロジェクトを成功させるため、押さえておいてもらいたい情報として三上は助言したかったのだろうが、何より顧客側にプロジェクトの成功を強く望んでいる者がいるということは、前田のようなベンダー側の人間にとってはありがたい話であった。
三上はランチミーティングを終えた後、日本橋に向かっていった。前田は、日比谷ソフトウェアに帰社後、加藤に三上から伝え聞いた内容をかいつまんで報告した。
加藤は、前田から呉服の桐生の内情を伝え聞いて、キックオフミーティングで感じた嫌な予感を思い返していた。
日比谷ソフトウェアが担いでいるSF1は、様々な顧客接点（チャネル）から入手される顧客情報を一元管理することが特長である。ただ、顧客チャネルは、業種業態や、組織のビジネスモデルに応じて異なる、というのが一般的だ。企業によって強みは異なるのだから当然だ。
そこで導入にあたっては、カスタマイズが発生するのが前提、という特性を持つパッケージである。ただ、消費財や耐久財といった商材の特性に応じてセレクトされたデータ項目の組み合わせや値の定義情報が、雛形のデータモデルとして、あらかじめ用意されているため、この基本パターンとなるデータモデルを活用することで、ユーザー企業は短期間に導入を行える、というのがSF1のウリだった。
したがって、SF1に反映されたノウハウをもとに定義されたある種の定石、必勝パターンとしてのデータモデルに対して、ユーザー企業の現状および目指すビジネスモデルや業務を表現したデータモデルが、どこがどのように異なるのか、それらを照合するFit&Gap分析という作業が必要である。
その作業の後に、業務をシステムに合わせるのか、それとも、SF1をカスタマイズするのか、という合意形成を要件定義の段階で、顧客側が主体となって行う。このユーザー企業側の意思統一は、ベンダーが「丸投げ」をされて請け負えるような性質のものではなく、必ず顧客側が主体的に決めなければならない。加藤は前職そして、日比谷ソフトウェアでの数々のプロジェクトを通じてその教訓と原則を、身を以て知った。
ただ、呉服の桐生と交わした契約書には、日比谷ソフトウェアが請け負う作業内容には例の「システムに関する仕様の決定」が、含められていた。契約書のフォーマットは、呉服の桐生側が提示したものがベースになっている。
繰り返すが、「システムに関する仕様の決定」を主体的にリードするのは、受注する日比谷ソフトウェアではなくて、発注側の「呉服の桐生」であるべきだ。
しかし実は、ITプロジェクトの契約にあたってこの手の契約書は、特段珍しいものではない。
（契約書のお約束として書かれているものの、必ず、ベンダー任せになる、と決まっているわけではない）と加藤は自らに言い聞かせるようにつぶやいた。「今回は、要件を先方が取りまとめてくれるのだろうか」
要件定義がしっかりとなされないまま、ずるずると複数の現場からの要求が垂れ流しされ、開発側で吸収しようと残業が続き、身体を壊したかつての苦い経験を思い出していた。
