RACIマトリクスのテンプレートと例: あらゆるプロジェクトで使える形式

RACIマトリクスは、Responsible(実行責任者)、Accountable(説明責任者)、Consulted(相談先)、Informed(報告先)という4つの役割をプロジェクトのすべてのタスクに割り当て、誰が何を担当するのかを誰も推測しなくて済むようにするものです。各文字の完全な定義と考え方については、RACIマトリクスガイドで詳しく解説しています。

このページでは理論は省きます。今すぐコピーできる空のテンプレート、さまざまなプロジェクトタイプにわたる6つの実践例、そしてマトリクスを1週間後も役立つ状態に保ち、二度と開かれない文書にしないためのルールを紹介します。もしタスクの担当が実際の課題ではなく、足りないのが意思決定のための構造なら、RACI vs RASCI vs DACIに直接進んでください。

Key Facts

• PMIの2026年版Pulse of the Professionによれば、複雑なプロジェクトのおよそ3分の1が失敗しており、これは「プロジェクト全体の失敗率13%のほぼ2倍」にあたります。そして複雑なプロジェクトこそ、担当が明文化されないままになりやすい種類のプロジェクトです。
• PMBOK Guide第8版(PMI、2025年11月)は、6つの中核原則と7つのパフォーマンスドメインで構成されており、作業を行う人とその役割を意味するリソースは、その7つのうちのひとつです。
• PMIはモデル全体を支えるルールを明言しています。「すべてのタスクには、Accountableな人がちょうど1人いる」。Accountableは「成果に責任を持ち、それについて説明する唯一の人」と定義されています。以下のテンプレートはすべて、このルールを守れるように作られています。

空のRACIマトリクステンプレート

これをそのままスプレッドシートやドキュメントにコピーしてください。角括弧のラベルを自分のタスクと役割に置き換え、各セルにR、A、C、Iのいずれか1文字を入力します。その役割がその行にまったく関わらない場合は、セルを空白のままにします。

凡例: R = Responsible(作業を行う) · A = Accountable(成果に責任を持つ。1行につき必ず1人) · C = Consulted(作業の前に意見を出す。双方向) · I = Informed(作業の後に報告を受ける。一方向)

記入の手順

1. 左側には個々のアクションではなく、成果物を並べます。 マイクロタスクのすべてではなく、成果物のレベル(レポート、リリース、締結済みの契約)から始めます。適切なレベルの選び方は後述します。
2. 上側には役割を並べます。可能であれば名前で。 広く共有するテンプレートには職種名で構いませんが、実名にすると、2人が同じ肩書を持った瞬間に生じる曖昧さがなくなります。ステークホルダー分析マトリクスがあれば、そこから全員のリストを取り出して、利害関係のある人が漏れないようにします。
3. 何よりも先に、すべてのAccountableを割り当てます。 1行につきAは1人、例外はありません。これは、誰も責任を負わないままタスクが止まることを実際に防ぐ、唯一の割り当てです。
4. 次にResponsibleを割り当てます。 1人が最もすっきりしています。作業が本当に共有されているなら2人でも成り立ちます。3人以上なら、通常はその行をより小さな成果物に分割する必要があります。
5. ConsultedとInformedは最後に、どちらも短く保ちます。 Cはすべて、Responsibleの担当者が着手前に待たなければならない相手です。Iはすべて、誰かが読まなければならない通知です。CとIのリストが長いことが、マトリクスが形骸化し始める主な原因です。
6. 完成したマトリクスは、確定する前に、そこに載っている人たちに見せます。 1人で作ってメールで配ると、静かな不同意を招きます。プロジェクトのキックオフミーティングでの5分間があれば、引き継ぎの失敗になる前に意見の食い違いを見つけられます。

マトリクスを形骸化させないためのルール

RACIマトリクスは、これらが破られた瞬間に役に立たなくなります。たいていは、タスクが遅れるまで誰も気づきません。

6つのRACIマトリクス実践例

以下の各例は、断片ではなく、実際のシナリオに対する完全なマトリクスです。自分の役割とタスクに置き換えて使えますが、パターンに注目してください。どの例でも、1行につきAが1つというルールが守られています。

1. ソフトウェアリリースまたはプロダクトローンチ

Engineering Leadは2つの行でAを、他の2つの行でRを持っていますが、これは作業に近い技術リードにとっては普通のことです。QAがテストが実際に行われる行にのみ登場し、すべての行には現れないことにも注目してください。それが、彼らのCの負荷を管理可能に保っています。

2. マーケティングキャンペーン

法務は、早い段階(コピーとクリエイティブ)ではConsultedであり、1回(正式なレビュー)だけAccountableです。これはよくある分け方で、作業がリスクを生みうるあらゆる場面で意見を出し、責任を持つのは承認そのものだけです。

3. 新入社員のオンボーディング

これは、AccountableがプロセスのすべてをHRまたは1人が担うのではなく、行によってHRと採用マネージャーの間を移るケースです。オンボーディングは2つの部門にまたがり、どちらもそのすべてを所有していないため、これは普通のことです。

4. ERPまたはシステムの導入

ここでのベンダーの義務を、作業範囲記述書(SOW)に書かれていることと突き合わせてください。設定と研修でRを持つベンダーに対応するSOWの条項がない場合、それは本番稼働後ではなく、契約締結の前に埋めるべきギャップです。

5. イベントまたはオフィス移転

引越し当日は、Rが同時に3つある唯一の行です(ファシリティ、IT、ベンダーがすべて並行して物理的な作業を行います)。これは、継続的に共有される成果物ではなく、調整された実行の1日であり、分割する必要がないため問題ありません。

6. 小規模チームのRACI(1人が複数の文字を持つ)

会社のウェブサイトをリニューアルする3人のチーム。創業者、契約のデザイナー兼デベロッパー、契約のマーケターです。部門長も委員会もなく、3人と期限だけがあります。

創業者は6行中5行でAを持っています。40人規模のプログラムであれば警戒すべきサインですが、ここではまさに適切です。3人のチームでは、作業に資金を出す人が、ほぼあらゆる場面で説明責任を負う当事者であるはずです。それでも重要なのは、Responsibleが1人に集中せずに分散していること、そして各契約担当者が、本当に自分の行では完全な責任(AとRの両方)を持っていることです。

壊れたマトリクスの見抜き方

マトリクスは、完成しているように見えても壊れていることがあります。信頼する前に確認すべきパターンは次のとおりです。

適切な粒度の選び方

RACIマトリクスが失敗する最も一般的な原因は、文字の割り当てが悪いことではなく、そもそもどの詳細レベルで作るかを誤ることです。

ほとんどの場合、成果物レベルから始めてください。元のリストが完全な作業分解構成図であっても、すべての末端ノードをマッピングするのではなく、その上位にある成果物をマッピングし、担当が本当に争点になっている2、3の成果物についてだけタスクレベルに下ります。40〜50行を超えるマトリクスは、通常、誰も実際に読まない状態になり、人々が読むのではなく検索するスプレッドシートに変わっています。

よくあるRACIマトリクスの間違い

マトリクスは作った後どこで使うか

キックオフのスライドにしか存在しないRACIマトリクスは、二度と誰も確認しないマトリクスです。一度作ったら、プロジェクトの中で担当が実際に試される場面に組み込んでください。

RACIが機能しなくなるとき

RACIは、各行のアウトプットが誰かが完了させる成果物であることを前提としています。行が実際には意思決定、つまりGo/No-Go、予算の判断、優先順位をめぐる争いになった瞬間、RACIは無理が出始めます。それは、何かがA列に属するのかをめぐる議論や、全員がConsultedで誰も明確に主導していないために、決まりそうで決まらない意思決定として現れます。

それが、その行、あるいはそのワークストリーム全体について、無理強いをやめてモデルを切り替えるべきサインです。RACI vs RASCI vs DACIをいつ使い分けるかの詳細な解説では、違いの見分け方と、2つのマトリクスが互いに矛盾しないように並行運用する方法を扱っています。

RACIマトリクスの価値は、文書そのものではなく、作業が始まる前にそれが促す対話にあります。上の空のテンプレートをコピーし、自分の机で1人で埋めるのではなく、実際に影響を受ける人たちと一緒に記入し、スコープや人員が変わったらすぐに見直してください。1行につきAccountableは1人、1人に負荷が集中しないResponsibleのリスト、そして人が実際に読めるほど短いConsultedとInformedのリスト。それがシステムのすべてであり、3人のウェブサイトリニューアルから複数ベンダーのERP展開まで、形を変えずにスケールします。