raci-matrix について
raci-matrixは、プロジェクト、製品ローンチ、継続業務における責任と意思決定権を整理するスキルです。RACIマトリクスに加え、意思決定、コミュニケーション、見直しの指針を示し、担当範囲を明確にします。
主な機能
- 01RACIの役割定義とマトリクス
- 02RASCIとDACIの形式に対応
- 03決定権限とエスカレーション経路
- 04チーム向けコミュニケーションテンプレート
- 05見直し周期とアンチパターンの確認
活用シーン
- 01製品ローンチの担当範囲を明確化
- 02プロジェクトチームの決定権を整理
- 03継続業務の責任分担を文書化
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/raci-matrixを入力して読み込まれたか確認します。
詳細
RACI マトリックススキル
このスキルは、プロジェクト、製品のローンチ、または継続的なプロセスを対象に、完全な RACI（実行責任者、説明責任者、協議先、報告先）マトリックスを作成します。チームに共有できる形式で出力することで、担当範囲を明確にし、意思決定のボトルネックを減らし、作業の重複をなくします。
必須入力
与えられた情報をもとに作成します。以下の項目に不足があっても、完全な出力を作成してください。不足箇所には妥当な仮定を補い、(仮定、要確認) と記し、最後に仮定の一覧を記載します。最初に質問するのは、中心となるテーマ自体が欠けていて、書く内容が何もない場合に限ります。
- プロジェクトまたはプロセス名
- マッピングする主要なアクティビティまたは意思決定（または、ユーザーがプロジェクトを説明し、このスキルが内容を導き出す）
- 関係するチームまたは役割（チーム名と、必要に応じて主要な個人名を列挙）
- 主な目的 — ローンチの担当範囲を明確にする／新しいチームのオンボーディング／ボトルネックの削減／ガバナンス文書の作成
- RACI のバリエーション — 標準の RACI、RASCI（支援者を追加）、または DACI（推進者、承認者、協力者、報告先）
出力構成
RACI マトリックス：[プロジェクト／プロセス名]
バージョン： [1.0] オーナー： [プログラムリード／PM] 日付： [日付] 関係するチーム： [チームの一覧]
1. 役割の定義
マトリックスを確認する前に、このプロジェクトにおける各文字の意味を合意してください。
| 文字 | 役割 | 定義 | ルール |
|---|---|---|---|
| R | 実行責任者 | 作業を行います。タスクを実際に実行する人を指します。 | R は複数設定できます。ただし、多すぎる場合はタスクの分割を検討してください |
| A | 説明責任者 | 成果に責任を持ち、意思決定を承認します。問題が起きた場合に説明責任を負います。 | 各行の A は必ず 1 つです。 2 つでも 0 でもいけません。 |
| C | 協議先 | 作業の前に、専門知識や意見を提供します。双方向のコミュニケーションが必要です。 | 協議先には、ただ対応可能な状態にするだけでなく、実際に参加してもらう必要があります。各行 3 つまでにしないと、かえって混乱します |
| I | 報告先 | 進捗や結果の通知を受けます。一方向のコミュニケーションです。 | 報告を受けるだけで、レビューや承認は行いません |
基本ルール：
- 各行の A は必ず 1 つ
- 同じ人またはチームが [X] 行を超えて A にならないようにしてください。説明責任が分散しすぎます
- C にはコストがかかります。誰かに協議するということは、回答を求めることを意味します。意図的に設定してください
- 同じタスクで R と A を兼任することはできません。ただし、その人が意思決定者である場合は例外です（小規模チームではよくあります）
2. RACI マトリックス
列にはチームまたは役割を、行にはアクティビティまたは意思決定を記載します。
| アクティビティ／意思決定 | [役割 1] | [役割 2] | [役割 3] | [役割 4] | [役割 5] | 備考 |
|---|---|---|---|---|---|---|
| [フェーズ 1：調査] | ||||||
| プロジェクトの範囲と目標を定義する | A/R | C | I | I | — | PM が主導し、技術的な実現可能性についてエンジニアリングチームに相談します |
| ユーザー調査を実施する | R | A | C | I | — | UX リサーチャーが実行し、PM が説明責任を負います |
| 調査結果を承認する | C | A | I | R | — | |
| [フェーズ 2：設計] | ||||||
| ソリューションのアプローチを定義する | A | R | C | I | I | |
| デザインシステム／UI デザイン | C | A/R | I | I | — | |
| デザインレビューと承認 | C | R | A | I | — | |
| アクセシビリティレビュー | I | R | A | C | — | |
| [フェーズ 3：構築] | ||||||
| 技術アーキテクチャに関する意思決定 | C | C | A/R | I | — | |
| スプリント計画 | A | C | R | I | I | |
| コードレビューとマージ | I | C | R | A | — | |
| セキュリティレビュー | I | C | C | A/R | — | |
| [フェーズ 4：ローンチ] | ||||||
| ローンチの実施可否の決定 | A | C | C | R | I | PM が最終決定権を持ちます |
| 本番環境へのリリース | C | I | A/R | I | — | |
| 顧客向けコミュニケーション | A/R | I | I | I | C | |
| ローンチ後のモニタリング | C | I | R | A | — | |
| [継続／定常業務] | ||||||
| インシデント対応 | I | C | R | A | — | |
| 機能の優先順位付け | A/R | C | C | I | I | |
| ステークホルダーへの報告 | A/R | I | I | I | C |
3. 意思決定マップ
重要度の高い意思決定については、意思決定の種類、権限を持つ人、意見が一致しない場合の解決方法を記録します。
| 意思決定 | 権限者（A） | 必ず相談する相手（C） | 意見が一致しない場合のエスカレーション先 |
|---|---|---|---|
| スコープの変更（工数の20％超） | [経営幹部スポンサー／プログラムリード] | [PM、エンジニアリングリード] | [運営委員会] |
| 予算超過（10％超） | [財務／経営幹部] | [PM、プログラムリード] | [CFO／取締役会] |
| アーキテクチャパターンの変更 | [エンジニアリングリード] | [テックリード、セキュリティ] | [CTO] |
| 本番稼働日の変更 | [PM] | [エンジニアリング、コミュニケーション、CS] | [プログラムスポンサー] |
| スコープからの機能削除 | [PM] | [プロダクト、UX、エンジニアリング] | [CPO] |
4. RACIでよくあるアンチパターンと解決策
完成したマトリクスを、次の失敗パターンに照らして確認します。
| アンチパターン | 症状 | 解決策 |
|---|---|---|
| Aが複数 | 2つのチームが、どちらも成果に対する責任を負っていると考えている | Aを1つに決め、もう一方はCまたはIにします |
| Aがいない | 意思決定が滞り、責任を感じる人がいない | 最も上位のステークホルダーをAに割り当てます |
| 全員がC | すべての意思決定が委員会に持ち込まれる | Cを一人ずつ確認します。この人の意見は、実際に結果を左右しますか。そうでなければIに変更します |
| RはいるがAがいない | 作業は完了するが、品質に責任を持つ人がいない | Aを追加します。通常はRのマネージャーです |
| AはいるがRがいない | 実行を伴わない説明責任となり、マネージャーが現場から切り離される | チームからRを追加するか、適切であればA/Rを兼任させます |
| Rが多すぎる | 責任の所在が曖昧になる | タスクをサブタスクに分割し、それぞれに明確なRを1人ずつ割り当てます |
| 重要なチームがマトリクスにいない | 影響を受けるにもかかわらず、RACIに含まれていない | そのチームを追加し、該当する行では最低でもIを割り当てます |
5. コミュニケーションテンプレート
RACIに合意したら、次のテンプレートを使って、関係するすべてのチームに伝えます。
件名： [Project Name] — 役割と責任の合意
[Project Name]のRACIマトリクスが確定しました。皆さんに関係する内容は次のとおりです。
[Role 1 team]： [X, Y, Z activities]に対する説明責任者です。これらの意思決定について最終判断を下し、成果が達成されなかった場合に説明責任を負います。
[Role 2 team]： [A, B, C]に対する実行責任者です。作業を実行します。[D]については相談先となります。意思決定を確定する前に、皆さんの意見を求めます。
[Role 3 team]： [E, F]について情報共有先となります。[weekly / milestone / launch]に更新情報をお送りします。エスカレーションが必要な事項に気づいた場合を除き、対応は不要です。
マトリクス全体はこちらで確認してください：[Link]。懸念事項があれば[Date]までにお知らせください。それ以降は、合意済みとして扱います。
6. RACIの見直し頻度
| きっかけ | 対応 |
|---|---|
| 新しいチームメンバーが加わる | そのメンバーの役割に関係する行を確認し、必要に応じてRを更新します |
| フェーズが変わる（例：ディスカバリー → デリバリー） | マトリクス全体を見直します。RやAが変わる場合があります |
| エスカレーションや責任の所在に関する混乱が発生する | マトリクスを使って原因を特定し、Aが欠けていないか確認します |
| 長期プログラムの開始から3か月が経過する | RACI全体を見直します。時間の経過とともに役割は変化します |
| チームの構成変更や再編がある | マトリクスを全面的に作り直します。責任に関する前提が変わるためです |
品質チェック
- すべての行にAが1つだけある
- 個人またはチームが、現実的な権限の範囲を超えてAを担っていない
- C列の対象者は少数に絞られている。全員に相談するとプロセスの効果が薄れます
- 各役割列から少なくとも1人の代表者がマトリクスを確認し、合意している
- 関係者全員にRACIを共有するためのコミュニケーション計画がある
- 意思決定マップに、プロジェクトで特に重要度の高い意思決定が5〜10件含まれている
アンチパターン
- 1つのタスクに複数のAccountableを割り当てないでください。責任を共有すると、誰も責任を負わなくなります。
- 5～6を超える役割を含むRACIを作成しないでください。読みにくくなり、実行も困難になります。
- RACIに沿って実行できないほど広範なタスクを含めないでください。意思決定単位の粒度まで分解してください。
- 対立を解決するプロセスを省略しないでください。意見の食い違いが一度起きると、解決プロセスのないRACIマトリックスは使われなくなります。
- ResponsibleとAccountableを混同しないでください。それぞれの役割における違いを明確に記載してください。
使用例となるフレーズ
- 「製品ローンチ用のRACIマトリックスを作成して」
- 「新しい部門横断プロジェクト用の責任分担表を作成して」
- 「この取り組みでは、誰が何を担当するの？RACIの作成を手伝って」
- 「エンジニアリングチームと製品チームの意思決定権を整理して」
- 「[チーム]が関わる[移行／ローンチ／プロセス]のRACIを作成して」