コラムカテゴリー：プロジェクトマネジメント
運営がうまくいっていないプロジェクトは「プロジェクト体制」が良くないケースが少なくありません。体制の悪さはプロジェクト計画書等に記載される「体制図」を見るとすぐにわかります。
プロジェクト体制図とは
プロジェクト体制図とは、プロジェクトのステークホルダー（利害関係者）の責任と役割を明確にし合意形成するために、分かりやすく階層構造で表した図です。
プロジェクト計画時にプロジェクトマネージャが作成し、プロジェクト責任者（プロジェクトオーナー）が承認します。
問題のあったプロジェクト体制図の事例
以下に実際にあったプロジェクトの体制図（簡略版）を記載していますので、どこに問題があるか考えてみましょう。
食品メーカーグループのホールディングス会社A社とグループ会社B社とで共同で行われた「IT基盤統合プロジェクト」の事例です。
※ 実際には各ボックスの中に実名が入っています
- 問題点①：プロジェクト責任が2系統に分かれている
- 最終的な意思決定者が一人でないためプロジェクトの方針がなかなか決まらない、一旦決まってもすぐに変わるといった事が頻繁に起き、プロジェクトの進行に支障が出ていました。
責任者はグループ全体の視点が必要となるので、このケースではA社が担うべきでした。 - 問題点②：ボックスの左右に線が伸びている
- 通常はボックスの上下に線があるので指揮命令系統が分かりますが、「支援チーム」と「事務局」には左右に線が伸びています。
これではどちらの意思決定、指示を優先すべきか不明確です。
また、酷いことに一方の線の先が更に分岐しているので、もはや線の意味が分からなくなっています。 - 問題点③：役割や責任がはっきりしないチーム名称である
- 「支援チーム」は上記の通り指示系統が不明確なチームですが、そもそも“支援チーム”という名前が漠然としており果たすべき機能も不明確です。これではプロジェクトメンバーによって「支援チーム」に求めることがバラバラになり「支援チーム」に対しての評価は低くなる可能性が高くなります。このような漠然とした役割の存在は、プロジェクト全体に悪影響を及ぼします。
「プロジェクト管理」もプロジェクトマネージャとしての責任を持つのか、管理チームの位置付けなのか不明確です。 - 問題点④：意味の不明な線がある
- 「グループ共通化プロジェクトマネージャ」（以下、共通化PM）と「基幹システム導入チーム」が点線で結ばれています。グループ共通化メンバーとの連携が必要となるのは想像できますが、結局このプロジェクトにおける共通化PMの責任の有無が不明確です。責任が無いのであれば線は無い方が良いでしょう。
「基幹システム導入チーム」は「プロジェクト管理」チームから指示を受ける一方、内容の異なる要求を共通化PMからも受け、プロジェクト運営に混乱が生じていました。
プロジェクト開始前にメンバー間で責任と役割を明確にして合意形成をしておかないと、プロジェクト開始後に必ず混乱が生じます。そのためにはプロジェクト体制図をしっかり作ることはとても重要な事なのです。
改善後のプロジェクト体制図
今回の事例のToBe（あるべき姿）は以下の通りです。
※ 視覚的に分かりやすくするため、アイコンを追加しています
- 改善ポイント（おさらい）
- 上で挙げた問題点の改善ポイントをおさらいすると、以下のとおりです。
- プロジェクトの最終的な意思決定者を明確にする
- 指揮命令系統を一本化する
- 役割と責任が明確になるような名称にする
- 責任が不明確な線は引かない
更なる改善のために
プロジェクト役割と責任をより明確にするために、プロジェクト体制図の補完資料として「責任分担表」の作成を推奨します。
「責任分担表」はタスク・個人毎に役割、責任を整理した表です。”RACI図”と呼ばれるフレームワークを使用したサンプルをご紹介します。
| No | プロセス | 役割分担（※） | |||
|---|---|---|---|---|---|
| プロジェクト 責任者 |
プロジェクト マネージャ |
PMO | … | ||
| 1 | ヒアリング日程調整 | A | R | … | |
| 2 | 要件定義書レビュー | A | C | … | |
| 3 | 工程完了判定 | A | C | … | |
| 4 | テスト環境構築 | A | I | … | |
| 5 | 操作教育 | A | C | … | |
| … | … | … | … | … | … |
- ※ 役割分担の意味
-
- R： Responsible（実行責任者） – タスク達成のために働く責任者。主担当。
- A： Accountable（説明責任者） – タスクの承認者。
- C： Consulted（協業先） – 助言、支援を行う者。
- I： Informed（報告先） – 進捗を常に把握している者。一方向の通信
- 社内でDXプロジェクトを発足させたが、どのような役割・体制で進めるべきか分からない
- ITベンダーがアジャイル型での開発を行う予定だが、発注企業としてどのような体制にすべきか他社事例を参考にしたい
- 社内のどのような人材をプロジェクトマネージャにアサインすべきか迷っている
- 任命したプロジェクトマネージャはITやプロジェクト管理の知識が無いので、今後のプロジェクト運営に不安がある
プロジェクト体制における様々な課題
プロジェクト体制における課題として、最近では以下のようなケースが多く見受けられます。
弊社では、ITやデジタル変革におけるプロジェクト経験豊富なコンサルタントが、多数在籍しており、上記のような課題解決の支援をしています。
もし社内だけでの解決が難しいようであれば、お気軽にご相談ください。
プロジェクト体制における課題解決支援の事例
関連サービス
2013年09月01日 (日)
青山システムコンサルティング株式会社
