プロジェクトはなぜ失敗しやすい？
先日こう書きました。
では、プロジェクトはなぜ失敗しやすいのでしょうか。
その原因はどこにあるのでしょうか。
これも様々な調査がありますが、プロジェクトマネジメントという要因を除けば、概ね「要件定義」で失敗していると見ていいでしょう。「要件定義」は噛み砕いて言うと、「何をやりたいのか、何を作ってやりたいことを実現するのかを決める」ことです。
満足を得られなかった理由の筆頭は「要件定義が不十分」、コストを順守できなかった理由の筆頭は「追加の開発作業が発生」、スケジュールを順守できなかった理由の筆頭は「システムの仕様変更が相次いだ」だった。
スケジュールを守れなかったプロジェクトで最も苦労した工程を尋ねると「要件定義」が筆頭に来た。
記事の引用にもある通り、システム開発のプロジェクトなのに「何を作るか」をちゃんと決めないから追加作業や仕様変更が発生し、何をやるかも決まっていないのに〆切が決めてしまっているからスケジュールも破綻して、中途半端なものが出来上がってバグだらけになったりするのです。
プロジェクトマネジメントを行うにあたって、計画時点で最も困るのがこの状態です。
やりたいこと、解決したいことが完全に決まってないけど、
とりあえず見切り発車しなければならない
契約は先に結ばれていて、そこで見積り予算まで確定しているけれども、要件が決め切れていない…だから後で予定と異なる事象が発生し、スケジュールが乱れ、混乱が品質の低下を招き、最後には責任の擦り付け合いが始まる…という嫌なループが繰り返されるのです。
ですが、それ以上に、エンジニアの多くが「要件定義」にすべきことが理解できていません。特に大手SIerの下につくと、それが顕著です。WBSがしっかりしているのですが、それはテンプレートがあるからで、大手SIerのマネージャーも、請けるパートナーもその妥当性がよくわかっていません。WBSの根拠があいまいな状態からスタートすることも珍しくありません。
多くの現場では「要求を洗い出し、現状と理想のギャップを整理し、システム化対象と非対象を切り分け、対象となる部分の業務要件やシステム要件を定義しろ」と言われているにもかかわらず、なぜかすでに「何を作るか」「どう作るか」にご執心で、設計と大差ないことしかできていない実情が後を絶ちません。おそらくは、各工程の"本質"を理解していないエンジニアの存在がそうさせているのです。
要件定義：「やりたいことのためにシステムは何を実現するのか」を決める
基本設計：「具体的に何を作るのか、どう実現するのか」を決める
詳細設計：「どう作るのか」を決める
一般的に、各工程に求められる本質は上記の通りです。
それぞれに階層化された段階があるのが普通です。
この流れはウォーターフォールでも、プロトタイピングでも、スパイラルでもアジャイルでも、どの開発モデルであってもほとんど変わりません。開発モデルの違いは進め方の違いであって、基本的な階層化の流れは同じだからです。
このことを知らず、プログラム一本で腕を磨いてきたエンジニア（プログラマー？）は、ドキュメンテーション能力も高くないことから、すぐにプログラムに起こす選択を取りがちです（まぁ気持ちはよくわかるんですけども）。
手戻りコストを最小化する取り組み
しかし、段階的に階層化することには意味があります。
それは、
大きな手戻りが発生する前に、マイルストーンごとに承認、承諾を得る
ことができる点にあります。
『トラブルを起こさない』
『トラブルを起こしてスケジュールを破たんさせない』
『トラブルを起こして関係者に迷惑をかけるようなことはしない』
ことを第一義に考えるリーダーやマネージャーは、慎重に段階を踏む進め方をします。それをしないリーダーやマネージャーは、よほどプロセス品質に自信があるか、あるいはよほど自分の身勝手で物事を進ませたいと考える人かのどちらかでしょう。周囲の迷惑を省みない人の思考とも言えます。
また、多くのエンジニアはおそらく本当の要件定義をしたことが無いのかもしれません。少し脱線しましたが、失敗原因の割合について、次の調査では『プロジェクトの失敗の原因の 50% が要件定義にある』とされています。
次に失敗原因の大きな割合の 17% を占める「スコープ定義（何をいつまでにやるかを決めること）」も要件定義に関連しているので、なんと要件定義はプロジェクト失敗原因の約 2/3 を占めるとも言えるのです。
請負開発の場合、要件定義はスコープの特定途中と言う側面もあり、一般的には設計が始まる前に改めて再見積りすることが多いものです。私が経験してきた大規模プロジェクトでも、その多くは
要件定義／調査解析：SES契約
基本設計～結合試験：請負契約
総合試験～カットオーバー：SES契約
となっていたと思います。その点から考えれば、要件定義工程は『計画』精度を高めるための準備段階と言う見方もできます。
つまり、要件定義工程にて整理が不十分な状態を残すということは、プロジェクトマネジメントにおける『目標』『プロセス』を定かすることができないと言うことでもあり、
・目的／目標を定かにしない
・スコープが特定できない
・スケジュールの確度が低い
・コスト進捗の管理方法が定かではない
・リスクマネジメントもロクに考えない
・コミュニケーション上の課題を解決しておかない
・リソースマネジメントをしっかり考えておかない
・品質基準はあっても、具体的な手順が存在しない
・ステークホルダーのエンゲージメントが図られていない
・（不足しているリソースの調達方法が定かではない）
これすべて、PMBOK（Project Management Body of Knowledge）上の知識エリアがまともに機能していないことを意味しているわけです。
過去たくさんのプロジェクトの炎上対策（火消し）に関わってきましたが、
炎上しているプロジェクトはまず間違いなく
・プロジェクト計画が存在しない／存在しても形骸化している
（形式的なものは残っていても、適切に改版もされていない、
周知もされずお蔵入りしているから、一切活用されない。ゴミ）
・要件定義が出来ていない
（形式的なものは残っていても、トラブル時点でゴミにしかなって
いない。設計のインプットになっていない。参考にもならない。）
ピクニック気分で雪山に登っているようなプロジェクトでは確実に遭難します。自業自得です。難しい登山では計画が特に重要なように、もしプロジェクトで遭難したくなければ、ちゃんと計画して準備を行い、適切な装備やメンバーを揃える必要があるのです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。