プロジェクトガバナンスの失敗を回避せよ ― 体制外ガバナンスの実践
itpjstudy
プロジェクトガバナンスの成功は、チーム内だけで完結するものではありません。体制外に存在するシステムや組織、業務改革の動きが、スケジュール・成果物・品質に大きな影響を与えます。本記事では、体制外ガバナンスの必要性、典型的な失敗パターン、そして実務で活かせる具体策を整理して解説します。
Must-Read Insights
体制外ガバナンスとは何か
なぜ体制外主体への対応が必要か
体制外主体とは、プロジェクト組織図には名前がないものの、リソース・承認・データなどで意思決定に影響を与える存在です。無視するとスケジュール遅延や成果物の差し戻し、品質低下などのリスクを招きます。
主な体制外主体の例
- 既存システムの保守部門
- 業務改革を進める部門
- 全社基盤・標準化部門
- 並行して走る大型プロジェクト
- ユーザ企業が持つ開発センタ
この部門の確認を取らずに進めたら、テスト段階で仕様変更になった…
境界管理の考え方
体制外主体へのガバナンスは、「管理」ではなく境界の設計として捉えると整理しやすくなります。誰が決められるか、どこまで調整可能か、どのタイミングで関与するかを明確にしておくことが重要です。
体制外ガバナンスが必要となる主要な例
以下では、主要例について、具体的リスクも合わせて整理します。
インタフェース連携する既存システム
既存システムは体制外ですが、プロジェクト進行に密接に関わります。特にデータ連携や機能整合の合意が必要な場合、接合点の明確化が重要です。
主要リスク・課題例
- マイルストン合意が曖昧で、既存システム改修完了がインタフェーステストに間に合わない
- インタフェース定義が不十分で、例外処理の認識齟齬がシステムテストで発覚
並行して走る大型プロジェクト
複数プロジェクトが同時進行すると、リソースや共通モジュールの依存関係が課題になります。
主要リスク・課題例
- マイルストンの同期が取れず、成果物提供が必要なタイミングに遅れる
- 共通モジュール仕様変更が事前共有されず、手戻りが発生
| プロジェクトAだけの 利用リソース | プロジェクトBだけの 利用リソース | プロジェクトA・B 共通リソース | 共通リソースの 調整状況 |
| モジュールX | モジュールY | ライブラリZ | 未調整 |
業務部門が独自に進める業務改革/改編
組織や業務フローの変更は、システム要件やスケジュールに影響します。
主要リスク・課題例
- 全社構造改革で大きな組織変更が1年後に発生することになり、業務要件定義やシステムテストに影響
- 将来の組織変更を見据えて、業務要件や仕様の確認先が追加変更になり、仕様差異や手戻りが発生
このプロジェクトには影響が無いようにしてくれるだろうと思って、特に確認していなかったが、大きな仕様変更が必要になった…
全社共通基盤・標準化／統制部門
標準やセキュリティ、承認プロセスは、プロジェクトに制約を与えます。
主要リスク・課題例
- 標準やセキュリティ要件の事前確認不足で、差し戻しや再設計が発生
- 承認遅延でリリース計画に影響
ユーザ企業が持つ開発センタ
外部組織ですが、成果物やインタフェースに大きな影響があります。特に、プロジェクトに必要なプログラム開発をユーザ企業の開発センタに出す場合は、プロジェクト内で内製する場合に比べて、コミュニケーションに手間が掛かるケースがあります。
主要リスク・課題例
- ITパートナの設計者とユーザ企業側の開発センタとの手続・方法論の差により、当初想定した設計・開発パフォーマンスが出ない
- インタフェース仕様や開発ルールの認識齟齬で品質に影響
体制外ガバナンスの実践策（ソリューション）
依存関係と接合ポイントの明文化
体制外ガバナンスで最も重要なのは、「なんとなく分かっている依存関係」を明文化することです。
依存関係が曖昧なまま進むと、問題は必ず後工程で顕在化します。しかもその時には、「誰の責任か分からない」状態になりがちです。
明文化の目的は、相手を縛ることではありません。接合ポイントを可視化し、認識のズレを早期に潰すことです。
具体例
■ 既存システム / 並行プロジェクト：
o 接合点の要件や仕様を詳細に確認
- インタフェースレイアウトの確認だけでなく、項目や値などについて、双方での用途・制約を詳細に理解する
- インタフェース処理の正常系だけでなく、例外処理やタイムアウト時、再送制御の扱いまで確認しておく
- 木を見て森を見ずにならないように、接合点周辺の仕組みを業務も含めて、概要を双方に理解しておく
o 接合すべきタイミングを確認
- インタフェーステスト、システムテスト、UATなど、双方の仕組みをつなげたタスクがあるタイミングを確認・合意し、プロジェクトのマイルストンを守れるようにする
- タイミングを合意するだけでなく、そのタイミングで必要な品質レベル、作業内容まで掘り下げておく
■業務改革・組織再編：
o 組織・業務変化のシステム影響を見極める
- 改革内容は初期は概念的なことが多いが、できるだけ具体的に業務プロセスや業務要件に落とし込み、システム影響が把握できるようにしておく
- さらに、システム影響がある変更ケースについて伝えておき、業務改革・組織再編側でシステム影響の可能性を検知した場合は、情報共有されるようにしておく
■ユーザ企業が有する全社共通基盤/開発センタ：
o 作業依頼の手続きやルール、設計開発標準を確認する
- 本来はITパートナ内で完結する作業を、ITパートナとユーザ企業で分け合うことになるため、認識齟齬や作業遅延が起きないようにお作法を確認しておく
o リソース制約を確認する
- ITパートナと異なり、ユーザ企業はリソース制約が大きい場合があるため、事前に人員・環境などのリソースの制約を確認しておく
- ユーザ企業内の他のタスクとのスケジュール調整も必要となることも多い
依存関係は、存在するだけでは問題になりません。「見えていないこと」が問題なのです。
定期的コミュニケーションの場を設計
体制外主体との関係は、放置すれば自然と疎遠になります。なぜなら、日常業務の優先順位の中で、自分の担当でないプロジェクトは「自分ごと」になりにくいからです。
疎遠になる原因
o 相手が、人数不足やトラブル中で遠慮してしまう
→ 「忙しそうだから後で聞こう」と先送りされる。
o 機能や作業の押し付け合いで、良い関係性が築けていない
→ 予算や責任範囲が絡むと、防御的になります。
o 優先度や利害が異なる
→ こちらにとっての最優先が、相手にとってはそうではない。
o 所属組織やプロジェクトが異なるので、タイミングが合わない
→ 物理的距離・組織階層の違いが障壁になります。
こうした構造的な問題を解決するには、「話そう」ではなく、「話す場を予め設計する」ことが重要です。
対策例
- 定例会の設置（月次での合同進捗会議、隔週での合同課題確認会、など）
- 節目節目での合同検討会やレビュー会の設置（インタフェース定義書の合同読み合わせ会、要件定義フェーズの総括レポート確認会、など）
- プロジェクト管理標準への織り込み（設計開発ガイドライン、レビュー/承認プロセス、など）
- 中日程レベルでのマイルストン・スケジュールの共有（要件・仕様の締め切りタイミング、システムテストの開始/完了予定、など）
コミュニケーションは“努力”ではなく“設計”です。
主体をまたいだ、合意形成プロセスの設計
体制外ガバナンスが機能しない最大の原因は、「どうやって決めるのか」が決まっていないことです。
特に、プロジェクトの外の関係者との協議の場合、それぞれのプロジェクトの最終意思決定者が勝手に判断する訳にはいきません。
一方で、プロジェクトを進めるうえで、必要な関係者は予め分かることが多いです。既存システムや並行して走るプロジェクトも想定ができます。
そのため、プロジェクトを始める前に、コミュニケーションの仕方に加えて、合意形成プロセスも決めておくことが有用です。
合意形成は“人間関係”ではなく“プロセス設計”で安定します。
典型的な失敗パターンと回避策
相手が決めてくれない／承認が遅れる
「あの件、いつまでに決めてもらえますか？」
「あ、具体的に期限は提示していなかった…」
- 原因：必要なことや期日を明確に提示していない。普段接していないので、阿吽の呼吸は通じない
- 回避策：依頼事項や質問には対応期限を設定、背景も簡潔に共有、文書で認識合わせ
外部結合テストやリリース直前での差し戻し
「テスト中に仕様差し戻しが…」
- 原因：接合ポイント・依存関係が曖昧
- 回避策：事前文書化・マイルストンレビュー。大きなところで認識齟齬が無いように、全体像・要件レベルでの確認も怠らない
必要な機能改修の担当先が決まらない
「この機能改修、どちらのプロジェクト側で対応するんでしたっけ？」
- 原因：どちらが担当か曖昧。予算や工数も絡むので、新しい要件や課題はもめがち
- 回避策：担当・優先度を事前合意、定期レビュー、必要なら調整ルール設計
調整疲れによる形骸化
「細かい進捗まで共有されても興味が無い。関係あるところだけ明確に話してほしい」
- 原因：自分のプロジェクトに集中したい心理。情報過多で負担
- 回避策：関係情報だけ簡潔に共有、会議目的明確化、優先順位付け
体制外主体を無視せず、境界・接合点・ルール・コミュニケーションの仕組みを事前に設計することが、プロジェクト成功の鍵です。
- ガバナンスは管理ではなく設計
- 体制外統制は、プロジェクトマネージャ成熟度の指標
- コミュニケーションの仕組みを予め設ける
プロジェクト体制の内側だけでなく、外側との接点を意識し、接合ポイントやルールを明確化しておくことが、境界で決まるプロジェクト成功の秘訣です。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
