フレームワーク活用ガイドひとことで言うと#
Responsible（実行責任者）、Accountable（説明責任者）、Consulted（相談先）、Informed（報告先） の4つの役割でタスクごとの担当を整理するマトリクス。「誰がやるのか」「誰が最終決定するのか」を明確にすることで、責任の曖昧さをなくす。
押さえておきたい用語#
- Responsible（実行責任者）
- 実際にそのタスクを手を動かして実行する人。1つのタスクに複数人いることもある。
- Accountable（説明責任者）
- そのタスクの最終的な承認・決定権を持つ人。各タスクに必ず1人だけ。「誰が最終責任を取るか」を明確にする。
- Consulted（相談先）
- 実行前に意見やアドバイスを求められる人。双方向のコミュニケーションが発生する。専門家やステークホルダーが該当。
- Informed（報告先）
- 結果や進捗を事後に報告される人。一方向のコミュニケーション。知っておく必要があるが意思決定には関与しない。
RACIマトリクスの全体像#
こんな悩みに効く#
- 「誰がやるの？」が曖昧で、タスクが宙に浮く
- 複数の人が同じことをやっていたり、逆に誰もやっていなかったりする
- 部門をまたぐプロジェクトで、責任の押し付け合いが起きる
基本の使い方#
各タスクに対して、関係者を4つの役割に分類する。
- R（Responsible）: 実際にそのタスクを実行する人。作業の担い手
- A（Accountable）: 最終的な承認・決定権を持つ人。各タスクに必ず1人
- C（Consulted）: 実行前に相談される人。専門知識を持つアドバイザー
- I（Informed）: 結果を事後に報告される人。知っておく必要がある関係者
最重要ルール: Aは各タスクに必ず1人だけ。2人以上いると「誰が最終責任を持つのか」が曖昧になる。
縦軸にタスク（またはプロセス）、横軸に関係者を並べたマトリクスを作る。
- タスクは具体的に分解する（「マーケティング」ではなく「LP制作」「広告運用」「効果測定」）
- 関係者は個人名またはチーム名で書く
- 抜け漏れがないよう、プロジェクトの全工程を洗い出す
マトリクスの各セルに、R・A・C・Iのいずれかを記入する。空欄（関与なし）もOK。
チェックポイント:
- すべてのタスクにAが1人いるか？（0人も2人以上もNG）
- Rがいないタスクはないか？（誰もやらないタスクは進まない）
- 1人にRが集中しすぎていないか？（ボトルネック発生のサイン）
- Cが多すぎないか？（相談先が多いと意思決定が遅くなる）
作ったRACIマトリクスを全員で確認し、合意する。一方的に決めてはいけない。
- 「自分はCだと思っていたのにRになっている」といった認識のズレを解消する
- 合意後はチームの共有ドキュメントとして常に参照できるようにする
- プロジェクトの進行に合わせて、必要に応じてアップデートする
具体例#
背景: PMの山田さんが毎回のリリースで「誰が最終GOを出すのか」で揉める問題を解決したかった。
作成したRACIマトリクス:
| タスク | PM | エンジニア | デザイナー | QA | 事業部長 |
|---|---|---|---|---|---|
| 要件定義 | A | C | C | I | I |
| UI設計 | I | C | R | I | I |
| 実装 | I | R | C | I | I |
| テスト | I | C | I | R | I |
| リリース判断 | R | C | I | C | A |
| 社内アナウンス | R | I | I | I | A |
導入前の問題:
- リリース判断で毎回3〜4人が「自分に相談がなかった」と不満
- 平均意思決定時間: 4.2日
- 手戻り率: 23%
導入後の成果:
| 指標 | Before | After | 変化 |
|---|---|---|---|
| リリース判断の平均所要時間 | 4.2日 | 1.8日 | 57%短縮 |
| 「相談がなかった」クレーム | 月5件 | 月0件 | ゼロ |
| 手戻り率 | 23% | 9% | 61%減 |
「リリース判断のAは事業部長」と明確にしたことで、PMが判断材料を揃えて事業部長に確認するフローが定着。全員の役割が明確になり、無駄な会議が3つ消えた。
背景: 元請け・設計事務所・設備会社・内装会社の4社合同プロジェクト。各社の責任範囲が曖昧で、問題が起きるたびに「それはうちの仕事じゃない」が発生。
RACI作成前の状況:
- 工程遅延: 月平均3.5件
- 責任所在の議論にかかる時間: 週4時間
- 手戻り工事: 半年で12件
主要タスクのRACIマトリクス（一部抜粋）:
| タスク | 元請けPM | 設計事務所 | 設備会社 | 内装会社 |
|---|---|---|---|---|
| 基本設計承認 | A | R | C | I |
| 設備配管設計 | I | C | R/A | C |
| 内装仕上げ | I | C | I | R/A |
| 施工スケジュール調整 | R/A | C | C | C |
| 検査・引き渡し | A | R | R | R |
6ヶ月後の成果:
| 指標 | Before | After | 変化 |
|---|---|---|---|
| 工程遅延/月 | 3.5件 | 0.8件 | 77%減 |
| 責任議論の時間/週 | 4時間 | 0.5時間 | 88%減 |
| 手戻り工事/半年 | 12件 | 3件 | 75%減 |
| プロジェクト総コスト | — | 8%削減 | — |
4社の代表者が1日かけてRACIを作成した時間は、半年間で何百時間もの「責任議論」を節約した。部門横断・会社横断のプロジェクトでこそRACIの威力は最大になる。
背景: 市のDX推進で「オンライン申請システム」を導入するプロジェクト。情報政策課・市民課・税務課・福祉課・総務課・広報課の6課が関与するが、「誰が何をやるのか」が不明確だった。
RACI作成前の問題:
- 住民からの問い合わせのたらい回し: 月40件
- 「うちの課の仕事じゃない」発生頻度: 週6回
- システム要件の決定: 3ヶ月以上かかっている
作成したRACIマトリクス（主要タスク）:
| タスク | 情報政策課 | 市民課 | 税務課 | 福祉課 | 総務課 | 広報課 |
|---|---|---|---|---|---|---|
| システム要件定義 | R/A | C | C | C | I | I |
| 申請フォーム設計 | R | A | C | C | I | I |
| セキュリティ審査 | R | I | I | I | A | I |
| 住民向け説明会 | C | R | I | I | I | R/A |
| 運用マニュアル作成 | A | R | R | R | I | I |
1年後の成果:
| 指標 | Before | After | 変化 |
|---|---|---|---|
| たらい回し件数/月 | 40件 | 6件 | 85%減 |
| 要件決定にかかる期間 | 3ヶ月+ | 3週間 | 75%短縮 |
| 課間の認識齟齬 | 週6回 | 週1回未満 | 85%減 |
| オンライン申請利用率 | 0% | 34% | — |
行政は「縦割り」と言われるが、RACIで横の連携を明文化すれば壁は薄くなる。特に「Aを1人に決める」ルールが、合議制に慣れた組織の意思決定を加速させた。
やりがちな失敗パターン#
- 全員がRになっている — 「みんなで責任を持とう」は聞こえがいいが、実際は誰も責任を取らない状態になる。Rは本当に手を動かす人だけに
- Aが形骸化している — 名前だけAで、実際は誰も最終判断しない。Aの人は「承認する/しない」の意思決定を本当に行う人にする
- 作って満足する — RACIは運用してこそ意味がある。タスクが追加されたり体制が変わったりしたら、すぐにアップデートする
- タスクの粒度が粗すぎる — 「マーケティング」のような大きなくくりでRACIを作ると、実際の業務で使えない。「LP制作」「広告運用」「効果測定」のように具体的に分解する
- Cを増やしすぎる — 「念のため相談」でCが5人以上いるタスクは、調整コストが膨大になる。本当に専門知識が必要な人だけをCにする
まとめ#
RACIマトリクスは、「誰が何をするか」を4つの役割で明確にするシンプルなツール。特に部門横断プロジェクトや新しいチームで威力を発揮する。作るときは必ず関係者全員で合意すること。そして「Aは各タスクに1人だけ」のルールを徹底することが、責任の曖昧さをなくす最大のポイント。