プロジェクト体制図と要員計画の書き方｜「誰がやる？」をなくす役割分担の極意
プロジェクトが始まったけど、誰に何を頼めばいいか曖昧で進まない…
結局、いつもPMの自分ばかりが動いている気がする…
システム開発プロジェクトにおいて、体制図は単なる「組織図」ではありません。それは、プロジェクトの意思決定スピードを左右し、トラブル発生時でも迷わず進むための「家族旅行の役割分担」のようなものです。
本記事では、30年の現場経験から導き出した「失敗しないプロジェクト体制の作り方」と、リソースを最適化する「要員計画」のポイントを、おなじみの「家族旅行」に例えて分かりやすく解説します。
体制図の目的：なぜ「旅行の役割表」が必要なのか？
家族旅行を想像してみてください。お父さんは「温泉に行きたい」、お母さんは「買い物をしたい」、長男は「話題のスポットに行きたい」とバラバラに主張し、誰もホテルの予約を確認していなければ、せっかくの旅行は台無しです。プロジェクトも全く同じです。
体制図を作る最大のメリットは以下の3点です。
- エスカレーションパス（指示と報告のルート）の確立: 誰が最終決定を下すのかを明確にし、「判断待ち」による停滞を防ぎます。
- カウンターパート（対等な窓口）の明確化: お客様（家族）と開発側（旅行代理店）の「相談相手」を固定し、指示の錯綜をなくします。
- 責任範囲の可視化: 「誰かがやると思っていた」という隙間を排除し、全員の持ち場を明確にします。
PM・PL・メンバーの役割を「家族旅行」で理解する
プロジェクトの主な役割を、旅行に関わる人たちに例えて整理しましょう。指揮命令の流れが重要です。
PM（プロジェクトマネージャー）＝「お父さん（全体責任者）」
- 役割: プロジェクト全体の目的（楽しい旅行の実現）に全責任を持ちます。
- 指揮のイメージ: 予算を管理し、旅の行き先を最終決定します。トラブル時に「予定を変更するか、強行するか」を決める最終意思決定者です。
PL（プロジェクトリーダー）＝「お母さん（現場リーダー）」
- 役割: PMの指示のもと、特定のユニット（食事や移動）の現場指揮を執ります。
- 指揮のイメージ: 実務を担う長男・長女たち（メンバー）に「準備はできた？」と指示を出し、遅れがあればお父さん（PM）に報告し、調整を仰ぎます。
ステークホルダー ＝ 「親戚・近所の人」
- 役割: 直接旅行には行きませんが、予算を出してくれる重要人物です。
- 実務での例え: 資金を出す経営層や、システムを使う他部署の担当者など、「無視できない関係者」です。
プロの役割分担術：RACI（レイシ）マトリクス表
体制図で「箱」を書いただけでは、誰が決定権を持つのか不明確です。実務ではRACI（レイシ）というフレームワークを使って、指示系統を定義します。
- R（Responsible：実行者）: 実際に手を動かして作業する人。
- A（Accountable：承認者）: そのタスクの結果に責任を持ち、最終判断する人（必ず1人だけ）。
- C（Consulted：相談先）: アドバイスや専門知識を提供してくれる人。
- I（Informed：報告先）: 決定事項を共有される人。
【事例】家族旅行のRACIマトリクス表
具体的に、旅行のタスクをRACIで整理すると以下のようになります。全てのタスクに「責任者（A）」と「実行者（R）」が定義されていることがポイントです。
| タスク （作業内容） | お父さん （PM） | お母さん （PL） | 長男・長女 （メンバー） | おじいちゃん （スポンサー） |
|---|---|---|---|---|
| 行き先の最終決定 | A | C | I | C |
| ホテルの予約作業 | A | R | R | I |
| 当日の車の運転※ | A | C | R | I |
| 昼食場所のリサーチ | I | A | R | – |
| 出発時間の通知 | A | I | R | I |
※当日の車の運転：「実際にハンドルを握る人(R：長男・長女)」と、「どのルートを通るか最終判断する人(A：お父さん)」を明確に分けることで、車内でのケンカ（混乱）を防ぎ、スムーズな進行を可能にします。さらに、道に詳しいお母さんに相談（C）したり、到着を待つおじいちゃんへ報告（I）したりすることで、チーム全体が連携できます。
【重要】RACIを運用する上での鉄則
RACIの各役割が「必須」か「任意」かという点は、プロジェクトの健全性を保つ上で非常に重要なポイントです。結論から言うと、「A（承認者）」は絶対に必須であり、かつ「1つのタスクに対して1人だけ」という鉄則があります。
1. A（Accountable：承認者）：【必須・絶対1人】
- 必須の理由: 「最終的に誰が決めるのか」が決まっていないと、意見が割れた時にプロジェクトが止まってしまいます。
- 1人だけの理由: 承認者が2人以上いると、責任のなすりつけ合いが発生したり、指示が矛盾したりする原因になります。「船頭多くして船山に上る」状態を防ぐためのルールです。
2. R（Responsible：実行者）：【必須・1人以上】
- 必須の理由: 「誰がやるか」が決まっていなければ、タスクは完了しません。
- 人数の目安: タスクの規模に応じて複数人でも構いませんが、多すぎると「誰かがやるだろう」という心理（社会的手抜き）が働くため、リーダー格を1人決めるのが望ましいです。
3. C（Consulted：相談先）：【任意】
- 考え方: 専門知識が必要ない単純なタスクであれば、設定しなくても問題ありません。
- 注意点: 設定しすぎると、相談（会議やレビュー）に時間がかかりすぎ、スピードが遅れる「コンサル過多」に陥ることがあります。本当に必要なアドバイザーに絞ります。
4. I（Informed：報告先）：【任意】
- 考え方: そのタスクの結果が他の作業に影響しない場合は不要です。
- 注意点: ただし、ステークホルダー（おじいちゃん）など、進捗を把握しておくべき相手を漏らすと、後からトラブルになるリスクがあるため、慎重に判断します。
よくある「RACIのNGパターン」
家族旅行の例で言えば、「今日の宿をどこにするか（A）」は、必ずお父さんかお母さんのどちらか1人が最終決定権を持たないと、いつまでも予約ができないという状態をイメージしてください。
- Aが不在: 誰も責任を取らず、物事が決まらない。
- Aが複数: 誰に判断を仰ればいいか現場が混乱する。
- Cが多すぎる: 調整に時間がかかりすぎて、実行（R）が進まない。
- Rが不在: 計画だけで、誰も手を動かしていない。
賢い要員計画の立て方：リソースを最適化する
体制（誰がやるか）が決まったら、次は「いつ、どれくらいの力を借りるか」を決める「要員計画」が必要です。
要員計画とは「適切なタイミングでの手配」
要員計画とは、プロジェクトの各フェーズにおいて、必要なスキルを持つ人を、必要な人数分だけ確保する計画のことです。
家族旅行でいえば、「いつ、どんな専門家や乗り物が必要か」を手配することに似ています。
- 旅の計画段階では「旅のプロ（旅行代理店）」の知恵を借りる。
- 移動中には「運転できる人」を確保する。
- 現地では「ガイドさん」をピンポイントで呼ぶ。 ずっと全員を拘束するのではなく、「必要な時だけ、最適な人をアサインする」のがスマートな計画です。
フェーズごとの「参加とフェーズアウト」
プロジェクトの進行に合わせて、メンバーを入れ替える（フェーズアウトさせる）ことでコストと品質を両立させます。
- 要件定義（計画）: 家族の要望（ビジネスニーズ）を正確に聞き取り、形にするコミュニケーション力の高いベテランを配置。
- 開発（実行）: 計画に基づいて、黙々と設計や実装（運転や手配）を進められる実務担当を最大化。
- テスト（確認）: 「本当に忘れ物はないか？」「行程通りか？」を客観的に判断できる「厳格なチェック担当」を投入。
稼働率の罠（予備の体力を残す）
「全員が100%の力で、24時間フル稼働する」という計画は、机上の空論です。
- バッファの確保: 旅行中に誰かが風邪を引いたり、渋滞に巻き込まれたりするように、プロジェクトにも予期せぬトラブルはつきものです。
- 実質稼働の目安: プロは実働を80〜90%で見積もります。残りの10〜20%を「不測の事態への対応」や「休息・ナレッジ共有」の余白として残しておくことで、一人が欠けてもプロジェクトが沈没しない強靭なチームを作れます。
まとめ：最高のプロジェクトは明確な「指揮系統」から
体制図と要員計画は、プロジェクトという長旅を成功させるための「家族のチームワーク」そのものです。
「誰が最後に決めるのか」「困ったら誰に言うのか」を全員が理解し、適切なタイミングで適切な力が発揮できれば、どんなトラブルが来ても乗り越えられます。あなたのプロジェクトに、「決まらない曖昧さ」や「無理な詰め込み」はありませんか？一度、この「家族旅行」の視点でチームの形を見直してみてください。
次のステップ：チームを迷わせない「旅の合言葉」
体制と計画が整ったら、次に必要なのは「全員が同じルール（標準）で動くこと」です。
どれほど優れたドライバーがいても、交通ルールがバラバラでは事故が起きてしまいます。チーム全員が迷わず、同じスピード感で進むための「プロジェクト標準」の作り方については、こちらの記事で詳しく解説しています。プロジェクト標準｜チーム全員が迷わないための「旅の合言葉」
