【初心者向け】プロジェクト体制図と要員計画の書き方｜「旅行の例え」で基礎から着実に学ぶチーム作り

「プロジェクトが始まったけど、誰に何を頼めばいいか曖昧で進まない……」
「結局、いつもPMの自分ばかりが動いている気がする……」

システム開発プロジェクトにおいて、体制図は単なる「組織図」ではありません。それは、プロジェクトの意思決定スピードを左右し、トラブル発生時でも迷わず進むための「家族旅行の役割分担」のようなものです。

本記事では、30年の現場経験から導き出した「失敗しないプロジェクト体制の作り方」と、リソースを最適化する「要員計画」のポイントを、おなじみの「家族旅行」に例えて分かりやすく解説します。

体制図の目的：なぜ「旅行の役割表」が必要なのか？
PM・PL・メンバーの役割を「家族旅行」で理解する
プロの役割分担術：RACI（レイシ）マトリクス表
賢い要員計画の立て方：リソースを最適化する
まとめ：最高のプロジェクトは明確な「指揮系統」から
- 次のステップ：チームの足並みを揃える「旅の合言葉」を決めよう

体制図の目的：なぜ「旅行の役割表」が必要なのか？

家族旅行を想像してみてください。お父さんは「温泉に行きたい」、お母さんは「買い物をしたい」、長男は「話題のスポットに行きたい」とバラバラに主張し、誰もホテルの予約を確認していなければ、せっかくの旅行は台無しです。プロジェクトも全く同じです。

体制図を作る最大のメリットは以下の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%を「不測の事態への対応」や「休息・ナレッジ共有」の余白として残しておくことで、一人が欠けてもプロジェクトが沈没しない強靭なチームを作れます。