本連載について
この記事は、難解なプロジェクトマネジメントのノウハウを、誰もが経験したことのある「家族旅行」に例えてわかりやすく解説する全12回のシリーズです。(※どの回からでも単独でお読みいただけます)

第4回となる今回は、誰が何をやるかを明確にする「プロジェクト体制図と役割分担(RACI)」についてお届けします!

「役割分担を決めたはずなのに、なぜか自分ばかりに作業が集中して忙しい……」
「『誰かがやるだろう』とお見合いになり、いつもタスク(ボール)が地面に落ちている」

プロジェクトの現場で、こんな徒労感や「ポテンヒット」に悩まされていませんか?

プロジェクトの目的地が決まり、スケジュール(旅程表)ができたら、いよいよ「誰と一緒に旅をするか」を決める番です。それがプロジェクトにおける「体制図」と「要員計画」です。

実は、プロジェクトが円滑に進むかどうかは、メンバーのスキルの高さ以上に、「誰が何を決定し、誰が実務を担うのか」という境界線がはっきりしているかにかかっています。

今回は、PMであるあなた自身が抱え込みから抜け出し、チームが自律的に動き出すための「役割分担」の考え方を、家族旅行に例えて解説します。

なぜプロジェクトに「体制図」が必要なのか?

「少人数のチームだし、わざわざ図にしなくても誰が何をするかは分かっているはず」 現場が忙しいと、体制図の作成を後回しにしがちですよね。

しかし、プロジェクトという「初めての挑戦」では、平時の業務とは違う役割が求められます。 旅行でも、普段はおっとりしているお父さんが「運転手」になり、しっかり者のお母さんが「会計」を担うように、プロジェクトという非日常を乗り切るための「仮の姿(ロール)」を定義し、全員で共有する必要があるのです。

体制図の目的は「コミュニケーション経路」の明確化

体制図を作る本当の目的は、単なる組織の上下関係(エラい順)を示すことではありません。 「何かトラブルが起きたとき、誰に相談・報告すればいいか」というコミュニケーションの経路(エスカレーションルート)を明らかにすることにあります。

【一覧表】旅行の配役でスッとわかる!プロジェクトの主要な役割

プロジェクトにおける主要な役割は、家族旅行の配役に置き換えると非常にイメージしやすくなります。

プロジェクトの役割旅行に例えると?期待されるアクション(役割)
プロジェクトオーナー旅のスポンサー(おじいちゃん)  予算を出し、最終的な「行って良かった」を判断する人
プロジェクトマネージャー(PM)  旅の幹事(あなた)全体の段取りを組み、トラブル時に最終的な判断を下す人
プロジェクトリーダー(PL)各車両の運転手担当するチーム(車両)の安全と進捗に責任を持つ人
メンバー旅行の参加者自分の持ち場(作業)を楽しみながら完遂する人
ステークホルダー(利害関係者)留守番の家族や親戚直接は行かないが、お土産や報告を待っている関係者

タスクの押し付け合いを防ぐ!役割分担フレームワーク「RACI」

「担当者は決まっているのに、なぜか物事が進まない、決まらない」 そんな時は、RACI(レイシ)という役割分担のフレームワークを活用してみてはいかがでしょうか。これは、一つのタスクに対して「誰がどこまで関わるか」を4つのアルファベットで定義するものです。

RACIを「家族旅行」に例えると超シンプル

難しそうなアルファベットも、旅行の役割に当てはめるとスッと理解できます。

  1. 【R】Responsible(実行責任者)= 手を動かす人
    • 例:実際にハンドルを握って運転するお父さん
  2. 【A】Accountable(説明責任者)= 最後にハンコを押す人
    • 例:ルートの最終決定権を持つ幹事
  3. 【C】Consulted(協力を仰ぐ人)= アドバイスをくれる人
    • 例:「あそこの道は混むよ」と教えてくれる、旅行好きの知人
  4. 【I】Informed(報告を受ける人)= 結果を知っておくべき人
    • 例:「今、無事に宿に着いたよ」という報告を受けるおじいちゃん

【重要】現場が混乱しない「RACI」3つの運用鉄則

RACIを表にするだけで満足してはいけません。プロジェクトをパニックから救い、自走させるためには、以下の鉄則を守って運用しましょう。

鉄則1:A(説明責任者)は必ず1つのタスクに「1人」

「船頭多くして船山に上る」の言葉通り、決定権を持つ人が2人以上いると現場は混乱します。旅行のルートを決めるのは幹事ただ一人です。責任の所在を曖昧にしないことが、迅速な意思決定の鍵になります。

鉄則2:すべてのタスクに「R(実行責任者)」を置く

「誰かがやるだろう」というタスクは、結局誰もやりません。ハンドルの握り手がいない車は事故を起こします。タスクがポテンヒットするのを防ぐため、必ず「実際に手を動かす人(R)」を明確に指名しましょう。

鉄則3:C(相談)とI(報告)を増やしすぎない

アドバイスをもらう相手(C)や、結果を報告する相手(I)の人数を増やすほど、コミュニケーションに割く時間は膨れ上がります。「車内の全員に毎分進捗を報告する」ような無駄なルールは、ドライバー(R)を疲れさせるだけです。相談・報告する相手は必要最小限に絞りましょう。

優秀な人への「丸投げ」を防ぐ!賢い要員計画の立て方

プロジェクトは「最初から最後まで、全員が同じ熱量で参加する」わけではありません。 「とりあえず多めに人を集めておこう(最初から全員参加)」というのは、空港までの送迎に現地ガイドまで連れて行くようなもので、コストばかりがかさみます。

特に注意したいのが、「兼務(掛け持ち)の限界」です。 「あの人は優秀だから、あれもこれも頼もう」と、特定の人に役割を集中させていませんか? 旅行で言うなら、「運転手が、運転しながらスマホで次の宿の予約もこなし、地図の確認も同時にやっている」ような極めて危うい状態です。

PM自身が詳細な開発作業まで兼務してしまうと、全体を俯瞰する判断が鈍り、トラブルへの対応が遅れます。「一人が一つの役割に集中できる環境」を守ることも、立派な要員計画(リソース最適化)の一つです。

プロジェクト体制図のイメージ(組織の繋がりを視覚化)

今回の旅行の例を体制図(組織図)に落とし込むと、以下のような関係性になります。組織の繋がりと、それぞれの役割(RACIの要約)をセットにして視覚化してみましょう。

  • 【家族(プロジェクトチーム)】
    • プロジェクト責任者(お父さん):予算の決定と、旅行全体の成功に責任を持つ。
      • ┗ プロジェクトリーダー(お母さん):行先やスケジュールの実務を仕切り、メンバーを指揮する。
        • ┗ メンバー(子供・祖父母):旅行を楽しむ一方、準備などのタスクを分担する。
  • 【外部ステークホルダー(対等な関係)】
    • 旅行会社の責任者(Aさん):お父さんと対等な立場で連携する。
    • 旅行会社の窓口担当(Bさん):お母さんと対等な立場で実務のやり取りをする。

このように図解(リスト化)することで、誰が誰に報告し、誰が誰をバックアップしているのかが一目でわかります。これがチームの「安心感」に繋がります。

【現場のリアル】あなた一人だけが必死に「地図」を見ていませんか?

役割分担が崩壊しているプロジェクトには、ある共通の予兆があります。

それは、「運転席のあなた(PM/PL)だけが必死に地図(スケジュールや課題一覧)を見つめ、他のメンバーが全員助手席や後部座席で寝ている(他人事になっている)状態」です。

あなた一人が責任感に燃えて「全部自分でやったほうが早い」「自分が頑張れば終わる」とタスクを抱え込んでしまうと、チームは「自分たちは単なる乗客だ」と思い込み、どんどん主体性を失っていきます。

助手席の人に「次のサービスエリアを確認して」と頼むように、適切に役割(R)をメンバーに渡していくこと。それが、あなた自身のパニックや疲弊を防ぎ、チームを自走させる第一歩です。

まとめ:体制図と役割分担は「チーム結束の証」

体制図と役割分担は、決して「責任の押し付け合い」や「誰が悪いかを決めるため」にあるのではありません。 一人では辿り着けない目的地に、全員の力を合わせて到達するための「結束の証」です。

  1. 体制図でコミュニケーションの経路(エスカレーションルート)を作る
  2. RACIの鉄則で「誰が主導し、誰が決めるか」を明確にする
  3. リソースを最適化し、特定の人に負荷(兼務)を集中させない

誰が主役で、誰が支えるのか。これを明確にするだけで、チームの動きは見違えるほど軽やかになり、あなた自身の負担もグッと減るはずです。さあ、最高の仲間と共に、次のステージへ出発しましょう!

次の記事: プロジェクト標準の作り方|「人によってやり方が違う」をなくす標準化ルール

メンバーと役割が決まったら、次は「仕事の進め方(ルール)」を揃える番です。「人によってやり方が違う……」という現場のイライラを解消し、チームのスピードを上げるための「合言葉」の作り方を次回は学んでいきましょう!

プロジェクト管理を「旅行の例え」で学ぶ:全12回ガイド
【導入編:コンセプトを理解する】
 第1回:プロジェクトマネジメントとは?
 第2回:プロジェクト計画書の書き方
【実践編:地図とチームを作る】
 第3回:マスタースケジュールとWBS
 第4回:体制図と役割分担(RACI)(本記事)
 第5回:標準化(旅の合言葉)の作り方
 第6回:コミュニケーション計画
【実行編:トラブルを乗り越える】
 第7回:リスク管理と課題管理
 第8回:キックオフ会議の進め方
 第9回:進捗管理とWBS運用
 第10回:品質管理と成果物
【完結編:ゴールを価値に変える】
 第11回:変更管理(スコープ変更)
 第12回:プロジェクト終結と振り返り

要件定義のやり方|家族旅行で学ぶ成功への7ステップ【完全保存版】要件定義の進め方がわからないPMやSE必見!システム開発の上流工程を「家族旅行」に例えて解説した全7ステップの完全ガイドです。企画構想から業務とシステムの切り分け、優先順位付けまで、現場で迷わないための鉄則を体系的にまとめました。...
ABOUT ME
hidechi
情報システムエンジニアとして35年以上、システム開発の最前線に立つ現役エンジニア。10億円規模の大規模案件など、数多くのプロジェクトマネジメント経験から得た「現場ですぐに使える実践的な知見」を発信します。日々、厳しい現場で奮闘しているPMやSEの皆さんの一助となれば幸いです。