発注側のPMにとって、RACIマトリクスは「誰が何を決め、誰が実務を担い、誰に相談・共有するのか」を一枚で可視化する強力な武器です。とくに、社内の業務部門と外部ベンダーが混在するデジタル案件では、役割の曖昧さが手戻り・遅延・余計な摩擦を生みがち。この記事では、事業会社での企画実務とコンサルの両面に通じた視点から、RACIの基本、SaaS導入の具体例、運用で効かせるコツまでを丁寧に解説します。IT知識に自信がなくても実務で使えるよう、誤解しやすい点や現場の失敗パターンも織り込み、すぐに試せる初期設定と会議運営の実践まで落とし込みます。
発注側PMが押さえるRACIの基本：導入効果と現場で起きる誤解・失敗と初期設定のコツ
RACIマトリクスは、成果物や意思決定単位ごとに役割を「R（Responsible：実行責任）」「A（Accountable：最終責任・承認）」「C（Consulted：要相談・助言）」「I（Informed：連絡・共有）」で整理するフレームワークです。WBSが「何を・いつまでに・どの順でやるか」を示すのに対し、RACIは「誰が何の責任を持つか」を明確にします。とくに発注側PMは、社内の意思決定とベンダー実装の接続点で責任が分散しがちなので、RACIで先に交通整理しておくことが効果的です。口約束や前提で動くと、後から「誰が決めたのか」「なぜ共有されていないのか」が問題化します。RACIは、その曖昧さを構造的に解消する安全装置です。
Rの定義は「実務を回し、成果物を作る人（またはチーム）」、Aは「意思決定と承認の最終責任者で、成果物に対しYes/Noを出す人」。Cは「意思決定前に相談すべき関係者」、Iは「意思決定や進捗を知らせるべき人」です。原則として、各成果物にAは1名（または1つの役職）に絞るのが鉄則です。Aが複数だと承認が遅れ、責任の所在がぼやけます。Rは実務上、複数でも成立しますが、多すぎるとタスクの割付が曖昧になるので、中心のRを明確にしましょう。
導入効果としては、意思決定のスピードアップ、手戻りの削減、ベンダーと事業側の期待値整合、エスカレーション経路の明確化が挙げられます。会議の出席者もRACIから逆算できるため、必要な人だけが必要な議題に参加し、無駄な会議の圧縮にも効きます。上層部への説明では、「Aが誰か」を明示すると、承認の責務とタイムラインを腹落ちさせやすくなります。さらに、RACIは契約文書（SOW）やRFPに織り込むことで、発注条件として対外的に拘束力を持たせられます。これにより、後出しの解釈を防ぎます。
現場での誤解で多いのは、RACIを「人事の役割表」と捉え、固定的にしすぎるケースです。RACIはプロジェクトの成果物・意思決定単位で都度定義するものです。また、CやIに「念のため」と多数を入れてしまい、結果として誰も読まないという事態も起こりがちです。Aを委員会や会議体にしてしまうのも失敗の元です。会議体は審議の場に過ぎず、最終責任を持つ個人（または明確な役職）をAに設定しましょう。
実務でよくある失敗は、タスク粒度でRACIを作り込み過ぎて運用不能になること、Aが決めない文化を放置して承認が無期限に滞ること、ベンダーにAを置いてしまい意思決定が外部化することです。さらに、RとAの入れ替わり（ベンダーが意思決定、事業側が作業）という逆転現象も見かけます。これは後戻りの温床です。RACIは「何についてのA/Rか」を成果物名で明示し、承認の締め切りとエスカレーションをセットで設計する必要があります。
初期設定のコツは、まず「成果物リスト」を先に作ることです。要件定義書、設計方針、移行計画、UAT完了判定、リリース承認など、意思決定や承認が発生する単位に絞ってRACIを定義します。各成果物ごとにAを1名に決め、A本人の合意を取り付けてください。Rは実務の主担当を1つに定め、補助的Rは注記で扱うと管理しやすいです。C/Iは「助言がなければ品質やリスクに重大な影響が出る人だけ」に厳選しましょう。
運用を意識した小さな一歩から始めるのが成功の秘訣です。最初は主要な10〜15の成果物だけでRACIを作り、毎週の定例で更新します。会議の議題はRACIの成果物にひも付け、各議題で「本日のAは誰か」「決めるのか、相談なのか、共有なのか」を明示します。決めきれない場合はエスカレーション先もRACIで定義しておきます。こうして、RACIを「見せるだけの図」から「意思決定を駆動する運用装置」へと育てましょう。
具体例で学ぶRACI作成手順：SaaS導入での発注側・ベンダー・業務部門の役割と承認フロー
ここでは、営業向けのCRM系SaaSを導入する想定で、発注側PM、業務部門（営業企画・現場）、情報システム、情報セキュリティ、ベンダー（SaaSベンダー/導入パートナー）、法務・購買、経理・内部統制、経営層が関与する構図を例にします。このシナリオは、典型的に「使い勝手」と「統制・セキュリティ」と「コスト・契約」が交差するため、RACIの効果が出やすい領域です。関係者が多いほど、Aの一意性とC/Iの絞り込みが効いてきます。意思決定のスピードを左右するのは、誰がどの成果物で最終責任を持つかの事前合意です。この前提を固めることが、手戻りを劇的に減らします。
手順の第一歩は「成果物の棚卸し」です。例として、企画書・投資対効果試算、ベンダー選定評価表、RFP、要件定義書、セキュリティリスク評価結果、基本設計方針（Fit/Gap）、SaaS設定仕様、データ移行計画・スクリプト、インターフェース設計、UAT計画・シナリオ、UAT完了判定、トレーニング資料・実施報告、運用手順書、SLA合意、リリース計画、Go-Live承認、ハイパーケア完了判定、最終支払承認などを挙げます。成果物は「意思決定や承認が発生するもの」を優先します。WBS上の細かいタスク（例：画面Aのレイアウト調整）はRACIの対象外で構いません。まずは15前後の主要成果物に絞りましょう。
次にA（最終責任）の割当です。原則として、企画書・投資判断は事業部長（またはプロダクトオーナー）、RFPとベンダー選定は発注側PM（最終は調達委員会の長でも可）、要件定義は発注側PM（業務責任を背負うなら事業側POでも可）、セキュリティ評価は情報セキュリティ責任者、設計方針は発注側PM、UAT完了判定は事業側PO、Go-Live承認はステアリング（最終責任者は事業部長）、運用手順は情報システム責任者、支払承認は経理部門長といった具合に、「誰がYes/Noを出すのか」を個人/役職で指名します。ベンダーにAを置かないのが基本です。Aに業務インパクトと統制の両責任が乗っているか確認します。
R（実行）とC/I（相談・共有）を埋めていきます。SaaS設定仕様やデータ移行のRは導入パートナー、UAT計画のRは発注側PM、UATシナリオ作成・実行のRは業務部門、セキュリティ評価のRは情報セキュリティ、運用手順書のRは情報システム、トレーニングのRはベンダーと業務部門で共同などが典型です。Cには、要件定義で情報システム・セキュリティ、インターフェース設計で関連システム担当、課金に関わる項目では経理・内部統制を入れます。Iには経営層、サポート部門、広報など影響を受けるが意思決定に関与しない関係者を置きます。Rは「実動の中心」を1つに寄せ、共同作業は注記で表現すると迷いが減ります。
承認フローを段階ごとに定義します。例として、企画承認（A：事業部長）→RFP承認（A：発注側PM/購買責任者）→ベンダー選定承認（A：調達委員会の長）→要件定義合意（A：発注側PM）→セキュリティリスク受容承認（A：情報セキュリティ責任者）→設計方針承認（A：発注側PM）→UAT完了判定（A：事業側PO）→Go-Live承認（A：事業部長）→最終支払承認（A：経理部門長）。各承認には、インプット条件（例：合意済み要件、試験エビデンス、リスク一覧）、締切、代行承認条件（不在時の委任）をセットにします。承認が遅延した場合のエスカレーション先も明記し、日程の防波堤を用意します。
ドキュメント化は簡潔に、一枚で見渡せることが重要です。Excelやスライドで成果物を行、関係者を列に並べ、R/A/C/Iを入力します。列は役職名ベースにすると属人化を防げます。作成後は、関係者全員でレビュー会を実施し、異論は場で解消します。最終版はRFPやSOWの付録として契約範囲に織り込み、定例会の議題テンプレートや議事録の末尾にハイパーリンクを置きます。
最後に、運用ルールを決めます。RACIは週次で見直し、体制変更やスコープ変更時は必ず更新すること。会議では議題ごとに「本件のA/R/C/I」を読み上げ、決める会か相談の会かを冒頭で宣言します。承認期限は議事録に明記し、未承認は「意思決定ログ」で追跡します。ベンダー側PMにもRACIの運用ルールを説明し、合意を取ります。これで、RACIは実際に意思決定を動かす実務ツールになります。
運用で効かせるRACI：ベンダー調整・意思決定・エスカレーションと会議体運営の実践
ベンダー調整にRACIを効かせる第一歩は、「論点を成果物にひも付ける」ことです。例えば「この要件、誰が決めるの？」という曖昧な質問は、「要件定義書の改訂版に関するAは発注側PM、Rは導入パートナー」と具体化します。ベンダーから仕様変更の提案が来たら、該当する成果物のAに承認を求める運びにし、ベンダー独断で進めないガードをかけます。逆に、Rが滞っている場合はRのチームリードにボトルネックの除去を支援します。役割に照らして要求と支援を切り分けることで、感情論に陥らず建設的に前進できます。
意思決定を加速するには、「RACI付き議事録」と「意思決定ログ」を導入しましょう。各議題の冒頭にA/R/C/Iを記載し、結論欄にはAの承認可否と条件、期限を明確化します。Cの関係者には事前レビュー期限を設け、期限までにコメントが無ければ黙示同意とみなすルールを敷くと停滞が減ります。Iへの共有は、週次ダイジェストで十分です。Aが不在の会議では決めない、という原則も徹底すると、場当たり的な合意が消えます。
エスカレーションは「何が起きたら、誰が、誰に、いつまでに」というトリガーと経路をRACIとセットで決めます。例えば「Aが承認期限を48時間過ぎたら、発注側PMがステアリング委員長へエスカレーション」「クリティカル欠陥でUAT停止時は、ベンダーPMから発注側PMへ2時間以内、以降は業務側POと連名で経営に報告」といった具体性が重要です。エスカレーションは責めるためでなく、意思決定資源を上位へ引き上げるための仕組みだと説明しておくと、心理的抵抗が減ります。ログ化し、再発防止に活かしましょう。
会議体運営はRACIを土台に設計します。週次ワーキングはR中心（設計・移行・設定の実務進行）、隔週の設計審査はA中心（方針決定と承認）、月次ステアリングはA/I中心（進捗とリスクの意思決定と共有）に役割を分けます。各会議の招待リストはRACIから自動的に導出し、必要以上のC/Iを呼ばないのがコツです。アジェンダは「成果物名ベース」で並べ、各議題のゴール（決める/相談/共有）を明示します。前日までに資料を配布し、Cのコメント締切を設定します。
RACIは生き物です。体制変更、スコープ変更、外部監査指摘、重大インシデントの後には必ず更新します。変更履歴を残し、最新版はコラボレーションツールで常時参照可能にします。新メンバーのオンボーディングでは、RACIと承認フローから説明を始めると、キャッチアップが早くなります。契約変更やCR（チェンジリクエスト）の際は、影響する成果物のA/Rが変わるかをチェックリスト化して確認します。RACIの更新を後回しにしないことが、混乱回避の最短ルートです。
効果測定とアンチパターンの監視も有効です。KPIとして、未割当のA件数、承認リードタイム、Cの過多（1成果物あたりCが5超なら要見直し）、エスカレーション件数と解決時間を追います。赤信号は「Aが会議体」「ベンダーにA」「C/Iが多すぎて誰も読まない」「Rが不在でAが実務する」などです。逆に、良い兆候は「Aの承認期限遵守率が高い」「会議参加者が適正に絞られている」「意思決定ログの鮮度が高い」こと。定量と定性の両輪で運用を磨くことで、RACIはプロジェクトの推進力になります。
RACIは図表を作ることが目的ではなく、「適切な人が適切なタイミングで適切な決定を下す」ための運用設計です。発注側PMとして、成果物単位でAを一意にし、Rの実動とC/Iの関与を最小限で最適化するだけで、ベンダー調整も社内承認も驚くほど滑らかになります。まずは主要な成果物15件程度から始め、会議体と意思決定ログに一体化させてください。SaaS導入のような関係者が多い案件ほど、RACIの効果は顕著です。次の定例から、議題ごとにA/R/C/Iを読み上げる運用を試し、意思決定のスピードと品質の違いを体感してみてください。
ナレッジ
コメント