役割分担マップ

基本的な意味と書き方

プロジェクトに関わる社内部署、制作業者、外部パートナーが「どの工程で何を担当するか」を 1 枚に可視化した表です。

プロジェクトマネジメントの手法である「RACI チャート(R: 実行責任 / A: 説明責任・承認 / C: 相談先 / I: 報告先)」の軽量版として多用されます。

行に「工程(素材撮影 / デザイン / コーディング / SEO / 広告 / 解析 / トラブル対応)」、列に「主体(発注者 Web 担当 / 営業 / 業者 PM / SEO 業者 / 広告代理店 / AI 活用担当)」を置き、各マスに R / A / C / I を記入します。意思決定マップと並べて運用すると、役割と判断の責任が完璧に揃います。

現場における核心と重要性(ポテンヒットの防止)

特に「制作・SEO・広告・インフラ」などを別々の会社に依頼するマルチベンダー運用において、この表がないと確実にプロジェクトが炎上します。役割が曖昧だと「業者は越権行為を恐れて遠慮し、社内は業者に丸投げする」ため、ボールが落ちて誰の責任でもなくなる(ポテンヒット)からです。

契約の初期段階で関係者全員と握り、半期に 1 度の見直しで運用の継ぎ接ぎ化を防ぎます。また、現代では「AI ツール(プロンプトエンジニア)」への委託範囲も列に加えるのが現実的です。

Web 担当者が陥りやすい落とし穴とリアルな対策(NG 事例)

① 「A(承認者)」が複数いてプロジェクトが止まる
RACI を書く際の絶対の鉄則は「1 つのタスクにつき、A(最終責任・承認者)は必ず 1 名に絞る」ことです。A に「Web 担当」と「営業部長」の両方を入れると、「で、どっちが決めるの？」と意思決定が宙に浮きます。

② 「相手がやる」という思い込みと交通整理の不在
最も恐ろしいのが、複数業者の役割境界が曖昧で、両方が「相手がやるだろう」と思い込んでタスクに穴が空くこと。また、「SEO 業者が発注者を飛ばして制作業者に直接修正指示を出し、見えない追加費用が発生する」といったトラブルを防ぐため、マップ上で指示系統(誰をハブにするか)を明確にする必要があります。

③ 死蔵化とインシデント対応の遅れ
作って満足してファイルが死蔵される、担当者の頭の中だけにあって明文化されていない、人事異動時に更新されないといった運用面の罠。サーバーダウンや炎上などの緊急時、この表は「誰に一番に連絡し、誰が復旧作業を行うか(エスカレーションルート)」を示す命綱になるため、関係者全員がいつでも見られる場所にピン留めしておくことが必須です。