プロジェクトガバナンスの本質：なぜ要件定義で決まるはずのプロジェクトが崩れるのか
itpjstudy
プロジェクトのコスト・期間・効果は、本来であれば要件定義フェーズまでで大きく決まります。これはウォーターフォール型開発の基本的な前提でもあります。
しかし、実際のシステム開発では、その前提が十分に機能せず、下流工程で問題が多発し、追加工数によって吸収され続けるケースが少なくありません。その結果、当初の計画は徐々に歪み、プロジェクト全体が肥大化していきます。
💬「最初に決めたはずの前提が、後工程でどんどん変わっていく」
これが、 多くのプロジェクト現場で繰り返される実感だと思います。
本記事では、この構造がなぜ起きるのか、そしてプロジェクトガバナンスの本質はどこにあるのかを整理します。
要件定義でプロジェクトはほぼ決まるという構造
要件定義は「設計」ではなくプロジェクト条件の固定フェー
要件定義は、単なる機能一覧の整理ではありません。プロジェクトの前提条件そのものを確定させるフェーズです。ここで業務のあるべき姿とシステムの実現範囲が定義され、プロジェクトの“枠組み”が決まります。
この段階で決まるものは以下です。
- 対象業務の範囲
- システム化の対象と非対象
- 業務フローの変更点
- 制約条件（予算・期間・技術）
要件定義は「設計の準備作業」ではなく、「経営・業務の意思決定として、その後の工程でやるべきことを決める作業」と言えます。
コスト・期間は、要件定義フェーズ完了時点で見積として確定する
要件定義が完了すると、ITパートナは作業計画を作成、工数を積み上げて全体見積を作成します。これをもとにユーザ企業はプロジェクト予算を確定させます。
このプロセスの本質は、「精度の高い見積を作る」というよりも、「前提条件に基づいて投資意思決定を行う」ことにあります。
| 項目 | 要件定義での状態 | 以降の扱い |
| スコープ | 固定 | 原則、変更管理対象 |
| コスト | 確定（基準値） | 変更は追加費用 |
| 期間 | 確定（基準線） | 変更は遅延扱い |
| 体制 | 仮確定 | 実行フェーズで調整 |
効果（ROI）もこの段階で実質的に決まる
システム導入の効果は「何を作ったか」ではなく、「業務がどう変わったか」に依存します。そのため、要件定義の段階で業務プロセスの設計がほぼ終わっている以上、期待される効果も実質的に確定されます。
💬 実装フェーズは「効果を詳細検討していく工程」ではなく「想定効果を実現する仕組みを実装していく工程」になる
この構造を理解していないと、「システム導入の効果の詳細は、後で考えれば良い」という誤解が生まれます。後工程で詳細検討して、システム仕様に変更が生じれば、それはそのまま費用増につながってしまいます。
現実には要件定義の前提が崩れ、下流で問題が噴出する
上流工程の弱さによる要件漏れと曖昧さ
多くのユーザ企業では業務知識は豊富である一方、それをIT要件として構造化する力が十分でないケースが見られます。その結果、要件定義には以下のような“見えない欠落”が残ります。
- 例外パターンの未整理
- 非機能要件（性能・運用）の不足
- データ定義の曖昧さ
- 業務間連携の抜け
- 既存システム内部の処理に関する調査漏れ
これらは、要件定義の段階では、問題として顕在化しにくい点が特徴です。
下流工程で仕様変更が多発する構造
設計・開発・テスト工程に入ると、初めて、新システムの具体的な画面・データ・処理フローが可視化されます。その時点で、以下のようなギャップが顕在化します。
- 「机上で考えていたときは業務運用できそうに思ったが、実際に完成した画面処理を見ると、煩雑過ぎる」
- 「業務ユーザは認識できていなかったが、周辺システムでの処理用に、様々なデータが必要だった」
- 「実務の現場では、要件定義で想定していた以上の例外処理が必要」
その結果、仕様変更・追加要件が連続的に発生し、要件定義時点の前提が徐々に崩れていきます。
要件定義に戻らずに、下流工程で吸収される現実
本来であれば、こうした問題は要件定義や基本設計にフィードバック（やり直し）されるべきです。しかし、実際には、以下の理由で、開発やテストといった下流工程での吸収が選ばれがちです。
- スケジュール優先（止められない。先に進むしかない）
- 契約変更の回避（既にアサインされている設計者・開発者をリリースできない）
- 意思決定の遅延（大きな判断には、ユーザ企業内での合意形成に時間がかかる）
その結果、問題は構造的に「下流工程で、付け焼刃的に対処され続ける状態」になります。
モグラ叩き型プロジェクト管理とマッチポンプ構造
問題は下流工程で個別対応され続ける
下流工程で発生する問題は、本来は構造問題であるにもかかわらず、現場では、個別課題や個別タスクとして処理されます。これにより、問題の本質が分解されて見えなくなります。
工数追加による延命型の対応
典型的な流れは以下です。
- 問題が発生する
- スケジュール維持が優先される
- 工数・人員が追加される（工数追加で、発生した課題を解決）
- 表面的に解決したように見える
- 根本原因は残る
この繰り返しが、プロジェクトの実態を徐々に歪めていきます。
プロジェクトの複雑化・肥大化
このような対症療法の積み重ねは、以下の副作用を生みます。
- 根本対応ではなく、小手先の対応
- 安易な仕様変更・仕様追加による、仕様分岐の増加
- テストケースの爆発
- 管理対象の増加
- 属人化の進行
結果として「誰も全体像を説明できない状態」に近づいていきます。
なぜ上流に遡った是正が行われないのか
意思決定コストと変更リスクの回避
要件定義に戻ることは、単なる技術判断ではなく経営判断になります。
- 追加コストの発生
- 納期遅延
- ステークホルダー調整
これらの負荷が大きいため、意思決定が先送りされやすくなります。
責任分界の曖昧さ
ユーザ企業とITパートナの間で責任範囲が曖昧だと、次の問題が発生します。
- 誰が要件を修正するのか不明
- どこまで戻るべきか判断できない
- 責任回避が優先される
この構造が、上流工程への回帰をさらに難しくします。
現場優先バイアスによるフィードバック不全
現場では「止めないこと」が最優先されます。そのため、構造を修正するよりも、現状を維持する方向に意思決定が傾きます。
💬「とにかく動かし続けることが正義になる瞬間がある」
その結果、上流工程に立ち返ることどころか、一度立ち止まって実情を点検することすら困難になります。
プロジェクトガバナンスの本質
上流の意思決定力と変更統制力の両立
プロジェクト成功に必要なのは、単なる要件定義能力ではありません。
- 何を作るかを決める力（上流）
- 変更を制御する力（統制）
- 崩れを検知する力（監視）
この3つが揃って初めて、ガバナンスが成立します。
下流吸収ではなく、上流へのフィードバック
理想的な構造は次のループです。
数個の課題のために、下流フェーズを止めてまで、上流フェーズに戻る必要はありません。しかし、個々の課題の検討においては、要件定義や設計で行ったような会議体に、必要なメンバが参加して、あるべき要件定義・設計を行うことが求められます。
- 問題発生（下流）
- 原因分析
- 要件・設計の一部やり直し（要件定義・設計に必要な会議体・メンバで実施）
- 再確定
しかし、現実には、このループが途中で断絶されています。
マッチポンプ構造からの脱却
現在の多くのプロジェクトは以下の循環に陥っています。
仕様変更として処理されていれば良い方です。プロジェクトによっては、本来、要件定義からやり直すべきものも、「バグ」として、すみやかに実装追加に進むケースも少なくありません。
| フェーズ | 実態 |
| 問題発生 | 下流で発生 |
| 対応 | 工数追加 |
| 見かけの解決 | スケジュール維持 |
| 結果 | 再発・肥大化 |
実装のための工数が大量に投入されて、出てきた問題を可及的に速やかに実装して完了させる考え方では、問題発生の原因である上流工程に踏み込んでいないため、問題が出続けます。結果、下流工程への人材投入が止まらず、雪だるま式にプロジェクトコストが膨らんでいきます。多くの場合、野放図な開発拡大で、二次障害が多発し、手が付けられない状態になります。
プロジェクトは“作る力”ではなく“制御する力”で決まる
上流の弱さは下流で必ず増幅される
要件定義の曖昧さは、必ず後工程で増幅され、コスト・品質・納期のいずれかに跳ね返ります。
工数追加は解決ではなく問題の延命
人員投入は短期的には有効に見えますが、構造的な解決にはなりません。前述のように、マッチポンプ構造を生み出し、状況を更に悪化させていくケースも多く見受けられます。
💬「増員で解決する」という発想そのものが、構造問題を隠す装置になり得る
真のプロジェクトガバナンスとは何か
真のガバナンスとは、以下の能力の統合です。
- 決める力（上流）
- 戻す力（フィードバック）
- 止める力（意思決定）
- 制御する力（統合管理）
これらを備えて初めて、プロジェクトは“管理可能な状態”になります。
意外に多くのプロジェクトで、本来は要件定義や設計をやり直した方が良い場面で、小手先の対応のため、大量に人員を投入して、状況が悪化・プロジェクトコストが膨大になるといった状況が見受けられます。
本記事では、どうしてそうなってしまうのかを、本来あるべき形から紐解くことで説明をしてみました。本当は「要件定義で決めたとおりに、進むべき」ということに立ち返ることが、問題状況の解消にヒントを与えると思いますので、ぜひ心に留めおいて頂けると幸いです。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
