RACI（責任分担マトリクス）

RACIが扱う軸は、タスクへの「関与のしかた」です。同じ人でもタスクごとに役割が変わるため、行にタスクや成果物、列に関係者を並べ、交点に役割を書き込みます。それぞれの意味は次のように区別します。

• Responsible（実行担当）：実際に作業して成果物を作る人です。要件定義書を書く、テストを実施するといった手を動かす役割で、一つのタスクに複数人が入ることもあります。
• Accountable（説明責任）：その成果物の完了を承認し、うまくいかなかったときに説明責任を負う人です。原則として一つのタスクにつき一人に絞ります。
• Consulted（相談先）：作業を進める前や途中で意見を求める相手です。双方向のやりとりが前提で、法務や有識者、レビュアーなどが該当します。
• Informed（報告先）：結果や進捗を一方向で知らされる相手です。相談はしないが状況は把握しておきたい上位者や隣接チームが入ります。

この整理が目指すのは、「誰の仕事か曖昧」「承認者が定まらない」「聞くべき人に聞かず後で手戻り」といった、責任の空白と重複を減らすことです。役割を言葉で決めておくと、会議で毎回確認し直す手間も抑えられます。

RACIは思いつきで埋めると崩れやすいため、順序を決めて作ると扱いやすくなります。おおまかには、タスクの洗い出し、関係者の列挙、役割の割り当て、関係者との合意、という流れで進めます。

• タスク・成果物を行に並べる：WBSやマイルストーンを下敷きにして、要件定義、基本設計、結合テストのように、責任が問われる単位で行を立てます。粒度が細かすぎると表が肥大するので、意思決定が伴う単位に寄せます。
• 関係者を列に並べる：個人名ではなく役割名（PM、開発リーダー、業務部門、発注元など）で列を作ると、担当交代があっても表が生き残りやすくなります。
• 交点にRACIを割り当てる：まずAccountableを一人に決め、次にResponsibleを置き、最後にConsultedとInformedを補います。Aから先に決めると空白が起きにくくなります。
• 関係者と読み合わせて合意する：作った本人だけが納得している表は機能しません。列に載った人と内容を確認し、認識のずれをその場で直します。

できあがる成果物は、プロジェクト計画書やキックオフ資料に添える一枚の表です。ステークホルダーの調整や、要件定義書のレビュー体制を決める場面で、そのまま議論のたたき台として使えます。

RACIは作れば効くわけではなく、運用でつまずく形にはいくつかの典型があります。表を作った後に確認しておきたい点を挙げます。

• Accountableが複数いる、または不在：承認者が二人いると押し付け合いになり、いないと決裁が止まります。行ごとにAが一人になっているかを最初に点検します。
• ConsultedとInformedの混同：相談したいのにInformedにしてしまい、意見を聞かないまま進めて手戻りになる形です。双方向か一方向かで役割が変わる点を意識します。
• 表を作って終わりにする：作成時点の体制で固定され、担当交代や計画変更に追随できなくなります。マイルストーンの節目で見直す運用とセットにします。
• Rが一人に偏る：実行担当がすべて同じ人に集まっていないかを見ます。負荷の偏りは、表を横ではなく縦に見ると気づきやすくなります。

いずれも、表そのものの誤りというより運用の緩みから生じます。作った直後と節目で見直すだけでも、責任の空白はかなり防げると考えられます。

RACIは責任分担の考え方の一つで、目的が近い枠組みがいくつかあります。軸は「どこまで細かく役割を分けるか」です。

• RASCI・RACI-VSなどの派生形：RASCIはSupport（支援）を加え、実行を助ける役割を明示します。RACI-VSはVerify（検証）とSign-off（最終承認）を分け、承認の段階を細かく扱います。関係者が多い大規模な案件で使われることがあります。
• PMBOKの責任分担マトリクス（RAM）：RACIはRAMの代表的な一形式という位置づけです。RAMという大きな枠の中に、RACIやその派生が含まれると捉えると整理しやすくなります。
• ステークホルダー分析との関係：ステークホルダー管理が「誰が関係者で、どんな関心を持つか」を扱うのに対し、RACIは「そのタスクで誰が何をするか」に踏み込みます。前者で洗い出した関係者を、後者の列に落とし込む流れになります。

どれを選ぶかは、プロジェクトの規模と関係者の多さで変わります。小さい案件で派生形まで使うと表が重くなるため、まずは素のRACIから始めて、必要に応じて役割を足す進め方が扱いやすいです。

RACIを扱えることは、プロジェクトマネージャーが責任分担をどう設計するかを言葉で説明できる材料になります。役割の空白や重複に早く気づき、承認者を一人に定め、相談先と報告先を区別する。こうした地味な調整の積み重ねが、手戻りや停滞を減らす動き方として面接や実務で評価されやすい部分です。転職を検討する場面でも、単に「調整が得意」と述べるより、どの工程で誰の責任を整理し、どんな成果物に落としたかを具体的に語れるほうが、担ってきた役割が伝わりやすくなります。まずは担当プロジェクトで素のRACIを一枚作り、節目で見直す習慣から始めると、経験として説明できる形になっていきます。

Accountableは本当に一人にしないといけませんか。

原則として一つのタスクにつき一人に絞るのが基本です。複数いると承認の押し付け合いや決裁の停滞が起きやすくなります。どうしても分担したい場合は、タスクの行をさらに分け、それぞれにAccountableを一人ずつ立てると整理しやすくなります。

ResponsibleとAccountableは何が違うのですか。

Responsibleは実際に手を動かして成果物を作る実行担当です。Accountableはその完了を承認し、うまくいかなかったときに説明責任を負う役割です。一人が両方を兼ねることもありますが、意味は分けて考えておくと、承認の抜けや責任の空白に気づきやすくなります。

RACIはいつ作るのがよいですか。

プロジェクトの計画段階、WBSやマイルストーンがおおよそ固まったタイミングで作ると使いやすいです。キックオフで関係者と読み合わせて合意し、その後はマイルストーンの節目で見直します。作りっぱなしにせず、体制や計画の変更に合わせて更新することが運用の鍵になります。