責任割当マトリクス(RAM/RACI)によるITプロジェクトの役割・責任設計
1. 概要
A. 定義
責任割当マトリクス(Responsibility Assignment Matrix, RAM)とは、作業パッケージ・成果物・意思決定を組織上の役割に対応付け、誰がどの程度関与するかを明確にする管理手法である。
RACIはRAMの代表的な表現である。 Rは作業を実行するResponsible、Aは結果を最終的に保証して承認するAccountable、Cは事前に専門意見を出すConsulted、Iは進捗や結果を知らされるInformedを表す。 したがってRACIは連絡先一覧ではなく、成果物と権限を結び付ける運用設計図である。 組織が大きくなるほど複数部署が一つの作業に参加し、最終責任者が不明確になりやすい。 RACIはこの曖昧さを可視化し、遅延・重複レビュー・承認漏れ・責任転嫁を減らす。
B. 必要性と適用範囲
ITプロジェクトには業務責任者、分析者、開発者、運用者、セキュリティ、個人情報担当者、外部供給者が参加する。 組織図は報告関係を示すが、特定のリリース、移行、試験、復旧判断の所有者までは示さない。 WBSが何を行うかを示すなら、RAMは誰が実行し誰が結果を保証するかを示す。
クラウドやSaaSでは、事業者が基盤を運用しても、顧客がアカウント、データ分類、ポリシー設定、業務利用を担う場合がある。 この境界は障害発生後に初めて協議するのではなく、導入前に記録しなければならない。
2. 概念構造
A. WBS・OBS・RAM
WBSは範囲を成果物と作業パッケージへ分解する。 OBSは部署、チーム、供給者、専門職などの役割を表す。 RAMは両者を交差させ、適切な管理レベルで関与を示す。
flowchart LR
scope["プロジェクト範囲"] --> wbs["WBS<br/>成果物・作業パッケージ"]
org["組織・役割"] --> obs["OBS<br/>役割カタログ"]
wbs --> ram["RAM<br/>作業 × 役割"]
obs --> ram
ram --> raci["RACI規則<br/>R・A・C・I"]
raci --> governance["承認・報告・<br/>エスカレーション"]
WBSの粒度とRACIの行の粒度をそろえることが重要である。 行が大きすぎると複数の責任が混ざり、小さすぎると維持コストが増える。 成果物、意思決定ゲート、受入条件、外部約束を行の境界にすると実務に適合しやすい。
B. R・A・C・Iの意味
Responsible(R)は作業を実行し成果物を作る役割である。 複数のRを置くことはできるが、主担当が不明なら作業を分割する必要がある。
Accountable(A)は結果を保証し、承認・拒否・リスク受容を判断する役割である。 一般には一つの成果物に一つのAを置くと最終判断が明確になる。 複数の承認機関がある場合は、各承認範囲と最終的な調整者を記録する。
Consulted(C)は完了前に専門知識を提供する役割である。 Cとの会話は双方向であり、意見や条件を証跡として残す。 セキュリティ、法務、個人情報、データ品質のレビューはここに該当することが多い。
Informed(I)は進捗や結果を通知される役割である。 通知イベント、時期、チャネル、情報レベルを決め、通知過多を避ける。
| 記号 | 問い | 代表的な行為 |
|---|---|---|
| R | 誰が実行するか | 構築・運用・試験・是正 |
| A | 誰が結果を所有するか | 承認・リスク受容・説明 |
| C | 誰の専門知識が必要か | 事前レビュー・助言 |
| I | 誰が知る必要があるか | 状態・判断の通知 |
C. 役割と個人
初版では個人名より役職・役割を列に置く。 承認版では担当者、代理者、連絡経路、エスカレーションを対応付ける。 一人が複数役割を兼ねる場合は、自己レビューや権限衝突のリスクを明記する。
3. 作成と運用
A. 入力資料
プロジェクト憲章、範囲記述、WBS、スケジュール、利害関係者一覧、契約、セキュリティ要件、個人情報要件を集める。 資料の版と適用日を記録し、どの範囲に対するマトリクスかを明確にする。 移行、プライバシー評価、性能試験、訓練、切替、運用引継ぎを別々の責任対象にする。
B. 配置と検証
業務、開発、運用、セキュリティ、監査、規制、供給者の役割を洗い出す。 最初にRとAを配置し、その後に結果を改善するCとIだけを追加する。
flowchart TD
s["範囲・WBS・<br/>利害関係者を収集"] --> d["成果物・活動・<br/>判断単位を定義"]
d --> r["役割と権限を確認"]
r --> a["先にR・Aを配置"]
a --> ci["必要なC・Iを追加"]
ci --> check{"空白・過負荷・<br/>権限不一致?"}
check -- "はい" --> review["ワークショップ・<br/>合意・承認"]
review --> a
check -- "いいえ" --> baseline["基準線を登録・共有"]
baseline --> monitor["変更ゲートと回顧で更新"]
各行に少なくとも一つのRとAがあるか確認する。 次に各列の過負荷、権限不足、形式的な参加を確認する。 開発成果が受入・リリース・運用の責任につながっているか、行間の引継ぎも点検する。
| 検証 | 確認事項 | 是正 |
|---|---|---|
| 行の完全性 | 重要行にR・Aがあるか | 担当・権限・範囲を補う |
| 単一責任 | Aが空または重複していないか | 最終判断範囲を決める |
| 負荷 | 一つの役割に集中していないか | 委任・分割・代理者 |
| 協議 | Cが多すぎないか | 必須と任意を分ける |
| 通知 | Iが有用な情報を受けるか | イベント・チャネル・周期 |
| 権限 | 契約・組織権限と一致するか | 委任または契約を補う |
RACIはPMだけで作って配布する文書ではない。 Aには予算、要員、受入、停止判断の権限を、Rにはアクセスと能力を対応させる。 版、適用範囲、承認日、変更理由、次回レビュー日を基準線に記録する。
4. 変形モデルと関連手法
RASCIは、実行を支援するが結果を所有しないSupportを加える。 RACI-VSは独立確認のVerifyと正式署名のSign-offを分離する。 DACIはDriver、Approver、Contributors、Informedで意思決定の責任に焦点を当てる。
RACIは成果物と反復活動に強く、DACIはアーキテクチャや製品方針の判断に適する。 文字を増やしすぎると解釈費用が増えるため、組織標準と用語定義を先に決める。
| 手法 | 焦点 | 実務上の意味 |
|---|---|---|
| RAM | WBSと組織の対応 | 管理粒度を調整できる |
| RACI | 作業・成果物の責任 | 教育とレビューが容易 |
| RASCI | 作業と支援 | プラットフォーム協業に有用 |
| DACI | 意思決定 | DriverとApproverを明確化 |
| WBS | 範囲分解 | 権限は表さない |
| 組織図 | 報告関係 | 成果物の所有者は不明 |
アジャイルやDevOpsでも自己組織化によって責任が消えるわけではない。 日々の細かなタスクではなく、製品、プラットフォーム、セキュリティ、リリース、サービスの境界に適用する。 サービスオーナーをリスクのA、開発者を実装のR、セキュリティをC、経営層をIとする構成が考えられる。
5. 適用事例
A. 公共サービスのクラウド移行
供給者は移行スクリプトと試験環境のR、顧客のサービスオーナーはデータ品質と業務受入のAとなり得る。 個人情報担当は保持・削除条件をC、監査部門は証跡をIとして受け取る。 切替リハーサルでは業務利用者をR、ロールバック判断者をA、障害通知先をIとして分ける。
B. 金融の不正取引検知
データサイエンティストはモデルと評価報告のR、AML責任者は本番適用のAとなり得る。 セキュリティと個人情報担当は特徴量とアクセスをCとして確認する。 精度だけでなく、閾値変更、誤検知処理、手動解除、事故報告、再学習承認を別の行にする。
C. 障害対応
オンコール担当は診断と緩和のR、サービスオーナーは顧客影響と復旧優先度のAとなり得る。 セキュリティ運用は侵害可能性をC、顧客支援と経営層はIとして通知を受ける。 復旧後の事後報告と再発防止にもAを置き、暫定回避策を恒久対策と誤認しないようにする。
6. 限界と失敗パターン
見た目のために全セルを埋めると、重要な協議対象が埋没する。 意図した非関与を説明できるなら空欄でもよい。 管理者をすべてのRとAにするとボトルネックになり、実行者が隠れる。
権限・予算・アクセスを与えず責任だけを割り当てると、RACIは責任転嫁の文書になる。 組織変更、供給者変更、運用移行、事故の後には必ず見直す。 変更管理と連動させ、古いAや退職者のオンコールを残さない。
7. 発展: 責任を運用データにする
成果物ID、役割ID、権限、証跡の場所、適用期間、代理者を構造化して管理する。 変更チケットの対象サービスと現行RACIを比較し、責任の空白を自動警告する。 自動化システムは実行や通知はできても、リスクを受容するAにはしない。
承認リードタイム、再作業率、責任空白、変更後の更新遅延、エスカレーション遵守率を測定できる。 ただし個人の失点評価に直結させず、チームの学習とプロセス改善に用いる。
8. 考慮事項と示唆
A. 技術士の視点
第一に、行を部署ではなくサービス成果と統制ゲートで定義する。 第二に、Aへ権限と資源を、Rへアクセスと容量を与える。 第三に、WBS・OBS・リスク・変更・セキュリティ証跡・運用手順とRACIを接続する。 第四に、経営向け要約表とチーム向け詳細表を安定したIDで結ぶ。 第五に、事故後は誰を責める前に、担当者に情報・権限・時間があったかを検証する。
B. 答案構成
定義と必要性を述べ、WBS・OBS・RAMの関係を概念図で示す。 R・A・C・Iを表で整理し、RとAを分ける理由と単一Aの効果を文章で説明する。 入力、役割識別、配置、検証、合意、基準線、変更管理の流れを示し、クラウド移行または金融検知の事例で締める。
参考資料
- PMI, “The brick and mortar of project success” — https://www.pmi.org/learning/library/project-success-core-values-key-accountabilities-6262
- PMI, “Roles, responsibilities, and resources” — https://www.pmi.org/learning/library/best-practices-managing-people-quality-management-7012
- University of Essex, “Responsibility matrix” — https://www.essex.ac.uk/staff/strategic-project-delivery/responsibility-matrix
一言まとめ: RAM/RACIは作業、権限、連絡を結び付け、ITプロジェクトの実行者・最終責任者・レビュー者・通知先を明確にする実行型ガバナンスである。