RACIチャートとは？定義、テンプレート、事例（2026年版）
役割を明確化し、混乱を排除し、予期せぬ停滞を防いでプロジェクトを完遂するための完全ガイド
RACIチャートとは？
RACIチャートとは、プロジェクトの各タスクを、実行、承認、助言、情報共有という4つの役割にマッピングする「責任分担表（RAM）」の一種です。RACIという名称は、Responsible（実行責任者）、Accountable（説明責任者）、Consulted（協議先）、Informed（報告先）の頭文字をとったものです。これら4つの関与レベルを適切に割り当てることで、プロジェクトの失敗の最大の原因である「誰が何をやるのかが曖昧」という問題を解消できます。
RACIチャートは通常、グリッド（表）形式で表示されます。左側の行にタスクや成果物を並べ、上部の列に役割や個人名を記載します。各交差部分にR、A、C、Iのいずれかの文字を記入し、そのタスクへの関与度合いを示します。これにより、プロジェクトマネージャーが頻繁に受ける4つの質問（誰がやるのか、誰が承認するのか、誰が意見を出すべきか、誰に知らせるべきか）に対し、すべての作業項目について一目で回答できる視覚的な資料が完成します。
このフレームワークは1950年代の産業プロセス管理に端を発し、1980年代にPMI（プロジェクトマネジメント協会）によってプロジェクト管理手法として形式化されました。現在では、ソフトウェア開発、建設、医療、マーケティング、製造、行政、コンサルティングなど、幅広い分野で活用されています。派生形として、RACIO（「範囲外」を追加）、RASCI（「サポート」を追加）、DACI（意思決定に特化したDriver、Approver、Contributor、Informed）などもありますが、オリジナルのRACIが依然として最も広く普及しています。
適切に作成されたRACIチャートは、責任に関する「暗黙の了解」を、文書化された「明示的なコミットメント」へと変えます。ステークホルダーから遅延の理由を問われた際、チャートを指し示しながら、誰がどの役割を担い、どこで問題が生じたのかを正確に議論できます。RACIチャートがなければ、こうした議論は責任のなすりつけ合いや、記憶の書き換えに陥ってしまいます。
R、A、C、Iの意味と具体例
Responsible（R：実行責任者）は、実際に作業を行う担当者です。コードを書き、文書を起案し、テストを実施し、機能を構築します。1つのタスクに複数の「R」が存在することもあります。例えば、フロントエンドとバックエンドの両方にまたがる機能開発では、それぞれのエンジニアが実行責任者となります。Rの役割は「実行」であり、実際に手を動かす人を指します。
Accountable（A：説明責任者）は、成果物に対して最終的な責任を持ち、完了の承認を行う唯一の人物です。RACIにおける最も重要なルールは、「1つのタスクにつきAは必ず1人」にすることです。2人が責任を負えば、実質的に誰も責任を負っていないのと同じです。問題が発生した際、お互いに相手が対処していると思い込んでしまうからです。Aは自ら作業を行う場合もあれば行わない場合もありますが、成果物のリリースに際して名前が載り、そのレビューが次のステップへの門番となる人物です。機能のローンチであれば、通常はプロダクトマネージャーやエンジニアリングリードがAを務めます。
Consulted（C：協議先）は、作業を完了させる前に意見を聞く必要がある人です。協議は双方向のコミュニケーションであり、実行責任者（R）が積極的にフィードバックを求め、協議先（C）がそれに応えます。一般的なCの例としては、特定分野の専門家、セキュリティ担当、法務、エンジニアの作業をレビューするデザイナー、顧客向け変更点について助言するカスタマーサクセスなどが挙げられます。協議は成果物が確定する「前」に行われるべきものです。
Informed（I：報告先）は、作業の進捗や完了を知る必要があるものの、事前に意見を出す必要はない人です。報告は一方通行であり、主要なマイルストーンの後に通知や概要を受け取ります。役員（ロードマップレベルでの進捗確認）、他チーム（依存関係にあるチーム）、リリースノートを受け取る顧客などがこれに当たります。C（協議先）とI（報告先）を混同することは、RACIにおける2番目に多いミスです（1番はAが複数いること）。これにより、本来不要なレビュープロセスに人々を巻き込んでしまうことになります。
具体例で考えてみましょう。「認証サービスを本番環境にデプロイする」というタスクの場合、シニアバックエンドエンジニアが実行責任者（R）となります。実際にデプロイ作業を行うからです。エンジニアリングマネージャーは説明責任者（A）です。ローンチを承認し、本番環境での障害発生時に最終責任を負うからです。セキュリティアーキテクトは協議先（C）となります。デプロイ前に認証フローのレビューが必要だからです。カスタマーサポートチームは報告先（I）です。顧客からの問い合わせに対応するためにデプロイ完了を知る必要がありますが、デプロイの可否を決定する権限は持ちません。4つの役割、4つの関与レベルにより、曖昧さはゼロになります。
RACIチャートを使うべき時（と使うべきでない時）
RACIチャートが最も威力を発揮するのは、複数のチームや役割が連携して成果物を出すクロスファンクショナルなプロジェクトです。1つの会議の中で「これの担当は誰？」という質問が複数回出たら、それが導入のサインです。もしチーム内で責任の所在について議論が紛糾しているなら、RACIチャートを導入する価値は1週間以内に実感できるでしょう。
新規プロジェクトの立ち上げ、主要機能のリリース、組織再編、コンプライアンスや監査プログラム、ベンダーのオンボーディングなど、2つ以上のチームにまたがり5名以上が関与する取り組みで活用してください。また、新しいチームメンバーのオンボーディングにも非常に有効です。「誰に何を相談すべきか」を1枚のマップで示すことができるからです。
小規模で役割が明確な単一チーム内の作業では、RACIチャートは不要です。2人で行うタスクで、お互いの役割が明らかな場合、このフレームワークを使うメリットはありません。暗黙の了解がすでに取れている場合、チャートの作成・維持コストがその価値を上回ってしまいます。判断の目安として、チャートを埋めるためだけに無理やり役割をひねり出さなければならないのなら、その作業レベルにおいてRACIは適切なツールではありません。
役割が週単位で激しく入れ替わるような、実験的要素の強い作業でもRACIは避けるべきです。初期段階のリサーチやディスカバリー（発見）フェーズでは、気づいた人がタスクを拾うような緩やかな責任体制の方が適していることが多々あります。早い段階で役割を固定しすぎると、探索的作業に必要な機動力が損なわれる可能性があります。作業が安定し、成果物や期限が定義された構造的なプロジェクト計画へと移行してからRACIを導入しましょう。
RACIチャートを作成する7つのステップ
ステップ 1：プロジェクトのあらゆる成果物、タスク、または決定事項をリストアップします。各行が特定の担当者に割り当て可能な作業単位（通常は1〜2週間の工数）となるよう、十分に粒度を細かく設定してください。「プロジェクト管理」や「コミュニケーション」といった曖昧な行は避け、「最終予算の承認」や「ベンダー契約の締結」のように具体的な項目を使用します。一般的な中規模プロジェクトでは、15〜40行程度になります。
ステップ 2：チャートの上部にすべての役割（ロール）または個人名をリストアップします。チームが大規模でメンバーの入れ替わりがある場合は、役割（プロジェクトマネージャー、リードエンジニア、デザイナー、QAリードなど）を使用します。チームが小規模で安定している場合は、個人名を使用します。組織を跨ぐ引き継ぎを明確にするため、必要に応じて外部の役割（クライアント、ベンダー、法務顧問、外部監査人など）も含めてください。
ステップ 3：各行に対して、ただ一人の「説明責任者（Accountable）」を特定します。これはRACI作成において最も難しく、多くのチャートが失敗するポイントです。必ず一人だけを選ぶようにしてください。もし二人が説明責任を負っているように見える場合は、「成果物が完了した際、誰の予定表に『最終版の承認』のリマインダーが表示されるか？」「完了チェックボックスの横に誰の名前が記載されるか？」を自問してください。その答えが、説明責任者となる人物です。
ステップ 4：「実行責任者（Responsible）」を特定します。これは複数人でも構いません。各タスクについて、「実際に作業を行うのは誰か？」を確認してください。単に作業をリードする人だけでなく、実行に携わる全員をリストアップします。例えば、UIの再設計タスクであれば、モックアップを作成するデザイナーと、それを実装するエンジニアの両方が実行責任者となります。
ステップ 5：「協議先（Consulted）」を特定します。「最終決定の前に誰の意見が必要か？」を確認してください。ここでは徹底的に最小限に絞り込みます。協議先が増えるたびに、実行責任者はレビューを待つ必要が生じ、サイクルタイム（所要時間）が長くなります。協議ではなく「報告」で十分な場合は、報告先に変更してください。原則として「報告先」とし、「協議先」は正当な理由がある例外的な場合にのみ設定すべきです。
ステップ 6：「報告先（Informed）」を特定します。「意見を出す必要はないが、何が起きたかを知っておく必要があるのは誰か？」を確認してください。通常、協議先よりも長いリストになります。役員、関連チームのリーダー、顧客対応チーム、およびその結果が計画に影響を与える可能性のあるすべての人を含めます。
ステップ 7：チームでチャートの内容を検証します。ワーキングセッションで一行ずつ確認してください。よくある修正点として、説明責任者がいない行（一人割り当てる）、説明責任者が二人いる行（どちらが真のオーナーか調整する）、協議先が多すぎる行（一部を報告先に変更する）、どの行にも登場しない役割（削除するか、本来行うべき作業を追加する）などが見つかります。検証が終わったら、全員が参照できる場所にチャートを保管し、スコープが変更されるたびに更新してください。
RACI チャートの例：ソフトウェア製品のリリース
6週間のソフトウェア製品リリースを想定し、以下の役割を配置します：プロダクトマネージャー、エンジニアリングリード、デザイナー、QAリード、マーケティングマネージャー、カスタマーサクセスリード、およびCEO。成果物には、機能スコープの承認、技術設計レビュー、UIデザインの承認、ビルドとテストの実行、セキュリティレビュー、ベータプログラムの開始、マーケティングキャンペーンの開始、そして最終的なゴーライブ（本番公開）が含まれます。
「機能スコープの承認」では、プロダクトマネージャーが説明責任者（A）、エンジニアリングリードとデザイナーが実行責任者（R：スコープの検討に寄与するため）、CEOが協議先（C：リリース内容の決定に経営陣の意見が必要な戦略的案件のため）、マーケティングマネージャーとカスタマーサクセスリードが報告先（I）となります。
「技術設計レビュー」では、エンジニアリングリードが説明責任者（A）と実行責任者（R）の両方を兼ねます（設計の責任を持ち、自ら作成するため）。プロダクトマネージャーとQAリードは協議先（C）となり、その他の役割は報告先（I）となります。「UIデザインの承認」では役割が入れ替わり、デザイナーが説明責任者（A）、プロダクトマネージャーが協議先（C）、エンジニアリングリードが報告先（I）となります（デザイナーの指定に従って実装は行いますが、デザインの決定権は持たないため）。
「ビルドとテストの実行」では、実装を担当するすべてのエンジニアを実行責任者（R）とし、エンジニアリングリードが引き続き説明責任者（A）を務めます。QAリードはテスト実行部分の実行責任者（R）となります。「セキュリティレビュー」では、セキュリティアーキテクト（協議先のみの列としてロールリストに追加）がゲートキーパーとなり、エンジニアリングリードが調査結果の解決に対する説明責任者（A）となります。
最終的な「ゴーライブ」の行は、チャートの中で最も横断的な項目になります。プロダクトマネージャーが説明責任者（A）、すべてのエンジニアリングとQAの役割が実行責任者（R）、マーケティングマネージャーとカスタマーサクセスリードが協議先（C：彼らの準備状況がゴーライブの判断に影響するため）、そしてCEOが報告先（I）となります。この行こそがチャートの真価を発揮する場面です。リリース当日、全員が自分がどのゲートを守るべきか、そして誰の許可が必要かを正確に把握できている状態になります。
避けるべきRACIチャートのよくある間違い
「説明責任者が複数いる」ことは、最も一般的で、かつ最も深刻な間違いです。説明責任者が二人いると、どちらも結果に責任を持たず、相手が主導していると思い込んでしまいます。必ず一人に絞ってください。もし業務が本当に共同所有されている場合は、作業を2行に分割し、それぞれが自分の担当分に対して説明責任を持つようにします。
「協議先が多すぎる」のは、二番目によくある間違いです。協議先が増えるごとに、レビュー待ちで数日、数週間と時間が失われます。協議先が5人いる行は、1人の行よりも5倍の時間がかかります。四半期ごとに協議先の割り当てを点検し、成果物の内容に積極的な変化をもたらさない役割は報告先に変更してください。
「役割と個人を混同する」と、体制が脆弱になります。チャートに「リードエンジニアがセキュリティレビューの説明責任者である」と記載されていれば、担当者が交代しても、役割と個人の紐付けを更新するだけでチャートは機能し続けます。しかし「田中さんが説明責任者である」と記載されていると、田中さんがチームを離れた瞬間にチャートは破綻します。プロジェクトが特定の個人よりも長く続く場合は役割を使用し、プロジェクトが短期間でメンバーが固定されている場合は個人名を使用してください。
「チャートを形骸化させる」ことは、緩やかな失敗への道です。RACIチャートは現状を反映している時にこそ最も役立ちますが、プロジェクトが動き出すと放置されがちです。フェーズの移行、スコープの変更、チームの増員や脱退など、プロジェクトの主要な節目ごとにチャートを見直し、更新する習慣をつけてください。誰も手を付けていない2ヶ月前のチャートは、誤解を招くため、チャートがないよりも悪い状態です。
「チームによる検証ステップを省く」と、初期の誤りがそのまま放置されます。独断で作成したRACIチャートの初版は、ほぼ間違いなく細部で現実と乖離しています。自分が割り当てた説明責任者の列は、チームが考える本来の責任分担と一致しないものです。最終決定とする前に、必ずワーキングセッションでチーム全体に共有してください。たとえ行の内容に変更がなくても、誰が何に責任を持つかという共通認識をチームが持つことができ、その議論自体に価値の半分があると言えます。
Instagantt で RACI チャートとガントチャートを連携させる
RACIチャートは「誰が」を明らかにし、ガントチャートは「いつ」を明らかにします。これら2つのツールは、代替手段ではなく、互いに補完し合うものです。優れたプロジェクト計画には、すべての成果物に対する所有権を定義するRACIチャートと、それらの成果物を依存関係やマイルストーンとともにタイムライン上に配置するガントチャートの両方が含まれています。
Instaganttでは、各タスクに1人の担当者をプライマリオーナー（説明責任者：Accountable）として設定し、共同作業者（実行責任者：Responsible）を追加し、コメントやタスクの説明を使用して協議先（Consulted）や報告先（Informed）を記録することで、RACI構造を反映させることができます。ガントチャートのタイムラインにより、時間軸に沿ったRACIの運用状況が可視化されます。ある説明責任者に複数の成果物が同じ週に集中している場合、ボトルネックが発生する前にワークロードビューでフラグが立てられます。
Instaganttのパブリックスナップショット機能を使用すると、編集権限を与えることなく、両方のビューをステークホルダーと共有できます。協議先の人々には、その意見が必要になる数日前にスナップショットのリンクを送信し、報告先の人々には、数秒で確認できるマイルストーンのみのビューを送信します。RACIの所有権マップとライブのガントタイムラインを組み合わせることで、プロジェクトのコミュニケーションは定例会議からセルフサービスのリンクへと進化します。
大規模なプログラムの場合、Instaganttのワークブックを使用して複数のプロジェクトを1つのワークスペースにグループ化できます。各プロジェクトで定義したRACIの役割はポートフォリオビューに集約され、例えば、同じ説明責任者が3つの並行プロジェクトでクリティカルパス上にいることなどを把握できます。このようなプロジェクトを横断した所有権の可視化は、静的なスプレッドシートのRACIチャートでは不可能であり、プロジェクトツールの外ではなく、ツール内でRACIを管理すべき強力な理由の1つです。
Instaganttの無料プランで、RACIを考慮した最初のガントチャートを作成してみましょう。スプレッドシートからタスクリストをインポートし、上記のRACIの定義に従ってオーナーを割り当て、成果物間に依存関係を追加して、チームとパブリックスナップショットを共有してください。明確な所有権と可視化されたタイムラインの組み合わせにより、チャートは単なる記録用の文書から、日々のプランニングツールへと変わります。