「要件定義がなかなか終わらない」理由
キーマン不在で膨れ上がる要件の中、プロジェクトメンバーはピンポン状態に
さて、要件定義とは、エンドユーザーの言い分をくまなく吸い上げることではない。新たなシステムを作るにあたっての基本構想（ビジネスゴール）にのっとり、業務プロセスの何を捨て、何を新しくし、何を変えるのかを決めていく、いう極めて重要なフェーズだ。ここでは、システム化の対象となる業務のプロセスオーナーがガッチリと関与し、新プロセスの意思決定をしていくことが求められる。
業務に詳しく、ビジネスゴールとの関連性を意識しながら意志決定ができる人間がいないと、当然要件定義は迷走する。
例えば、「在庫削減プロジェクト」をイメージしてみよう。調達・製造業務に携わる人は、在庫を減らしたい。しかし営業部門は、在庫不足はリスクなのでできるだけ多く抱えたい。全社視点に立つなら、「需要予測のプロセスも並行して考えよう」という話になるのが正しい姿だが、意志決定者が不在だと声の大きい方のユーザーが勝ってしまう。結果として、プロジェクトメンバーは「あちらの部門ではこう言われ」「こちらの部門ではああ言われ」をピンポン玉のように繰り返し、延々と要件が固まらない。
プロジェクトとは、錯綜する数々の利害関係者を調整しながら、ビジネスゴールを達成する取り組みだと考えている。よって、こういう局面ではまずそれぞれの言い分を聞き、ビジネスゴールと照らして着地すべき合意点を見つける。それぞれにメリットデメリットがあっても、最後は全社にとってそれが正しい選択であるということをはっきり理解してもらうようにコミュニケーションし、合意形成しながら進めていくというのがあるべき姿だ。
翻って、企業内でそういうことができる人財は、業務に精通しているだけではなく、コミュニケーションやファシリテーション力に長けて、意思決定のリーダーシップを備えている、ということになるが、例によって、そういうキーマンはシステムプロジェクトにアサインメントされないのが常だ。そして、「ピンドメ役」不在のまま、要件定義フェーズはずるずると遅延していく。
「システム設計がいつまでたっても終わらない」理由
忍び寄る「刺身」の誘惑
さて、こうなると、そろそろプロジェクトチームのお尻には火がついてくる。要件定義は終わっていないがスケジュール上はもう設計にはいっていなければならないからだ。ここで多くのプロジェクトはこう考える。「設計フェーズをやりながら要件定義をして遅れを取り戻そう」――。しかし、これは絶対に手を出してはいけない「禁断の木の実」だ。
フェーズを折り重ねて時間を縮めようとすると「刺身状態」に陥る
そもそも要件定義が終わらない理由は、「決められなかった」ことにある。引き続き二転三転する要件定義に加えて設計を並行して動かすと、要件に振り回されて設計手直しの無限ループが始まる。こうなると、SIベンダーを含めたプロジェクト全体が精神的肉体的に疲弊し、モチベーションが下がり、「とにかく早くプロジェクトを終わらせる」ということだけを目指すようになる。生産性は落ち、品質は低下するという負のスパイラルに突入し、終わりの見えない設計フェーズが延々と続くことになる。
本来、タスクの矢羽がきれいにシーケンシャルに並んだスケジュールでプロジェクトを進行させるべきところを、フェーズを折り重ねて時間を縮めようとするアプローチのため、われわれはこれを「刺身状態」と呼ぶ。刺身の切り身が一部重なりあって皿に並んでいるイメージだ。ちなみに前編で触れた、われわれがお客様のレスキュー要請を受けて立て直しに入った4年前のプロジェクトも、まさに設計フェーズが「刺身状態」で負のスパイラルに陥っていた。
思い切って一度前フェーズに立ち戻り、スケジュールを刺身からシーケンシャルな矢羽に組み立てなおして再起動する、という取組みの結果、最後は稼働に成功したものの、このプロジェクトは2年の遅延、お客様は2倍のコストを負担することになった。「刺身」には絶対に手を出してはいけない。これは鉄則である。
