RACIマトリクスは、プロジェクト管理の世界で長く使われてきたフレームワークだ。Responsible（実行責任）、Accountable（説明責任）、Consulted（相談先）、Informed（報告先）の四つの役割を表に整理するだけで、誰が何をすべきかが一目でわかる——そう説明されることが多い。しかし、DexVault24がさまざまな組織の現場に入って見てきた実態は少し異なる。丁寧に作られたRACIマトリクスが、運用開始から数週間で誰にも参照されなくなるケースは珍しくない。問題はフレームワーク自体にあるのではなく、導入前に整えておくべき前提条件が見落とされていることにある。以下では、RACIを使い始める前に必ず確認すべき三つの問いを、具体的な状況とともに示していく。

一つ目の前提：意思決定のスコープが言語化されているか

RACIマトリクスが最初に崩れる場所は、「Accountable（説明責任者）」の欄だ。ある製造業のクライアントでは、製品ラインの仕様変更に関するRACIを作成したところ、品質保証部門のマネージャーと開発部門のリードの両方がA欄に名前を連ねた。誰も問題にしなかったのは、「どちらが最終的に決める人か」という問いを、組織として一度も言語化していなかったからだ。RACIはあくまで既存の意思決定構造を「見える化」するツールである。構造そのものが曖昧なままRACIを作ると、曖昧さを整形しただけの表ができあがる。導入前にまず問うべきは、「この組織では、誰がどの範囲の決定を単独で行えるか」という問いだ。それが答えられない段階でRACIを埋めることは、問題の先送りにすぎない。

二つ目の前提：タスクの粒度が組織全体で統一されているか

RACIマトリクスの行には「タスク」または「成果物」が並ぶ。ここで頻繁に起きる問題は、粒度のばらつきだ。東京のあるITサービス企業では、「要件定義書の作成」という一行の隣に「週次進捗会議の司会」という一行が並んでいた。前者は数週間にわたる複合作業、後者は一時間の定例業務だ。粒度が混在したRACIは、読む人によって解釈がまったく異なる。「要件定義書の作成」にRとして名前が入ったメンバーが、インタビューの設計から文書の最終確認まで全工程を担うと理解するかどうかは、個人の経験と文脈依存だ。導入前に、タスクの粒度の基準——たとえば「一つの行は一人が一週間以内に完了できる単位」——を明示しておくことが、機能するRACIの最低条件になる。

三つ目の前提：更新の責任者とタイミングが決まっているか

RACIマトリクスは静的な文書ではない。プロジェクトが進むにつれて担当者が変わり、新しいステークホルダーが加わり、タスクの定義も変化する。DexVault24が関与したあるメディア企業の事例では、プロジェクト開始時に丁寧に作成されたRACIが、三ヶ月後には「作成当時の状態を記録した歴史文書」と化していた。誰も更新しなかった理由は単純で、誰が更新する責任を持つかが決まっていなかったからだ。更新頻度とオーナーシップを最初に設計に含めないRACIは、時間が経つほど現実から乖離する。フレームワークの導入と同時に、「このマトリクスは誰がいつ見直すか」を決め、それ自体をRACIの一行として記載する——そのような運用設計を組み合わせて初めて、RACIは生きたツールになる。

なぜこの三つが見落とされるのか

これらの前提が見落とされる理由の多くは、RACIの「わかりやすさ」そのものにある。表形式で役割を埋めていく作業は、具体的な成果が出ているように感じさせる。ワークショップで全員が付箋を貼り、列に名前が埋まっていくプロセスは、合意形成が進んでいるという感覚を生む。しかし、その場で合意されているのは「誰の名前をどの欄に入れるか」であって、「その役割が実際に何を意味するか」ではないことが多い。ベルリンの組織開発コンサルタントMarco Richterが2010年代初頭に指摘したように、ツールの形式的な完成が、実質的な議論の終了を宣言してしまうことがある。RACIの導入前に必要なのは、表を埋める時間ではなく、表を埋める前の問いに向き合う時間だ。

DexVault24が現場で使うチェックの手順

DexVault24では、RACIの導入前に必ずクライアントと三段階の確認を行う。まず、組織内の代表的な意思決定を五つ挙げてもらい、それぞれの最終決定者を口頭で答えてもらう。答えが人によってばらつく場合、意思決定スコープの言語化が未完了と判断する。次に、過去三ヶ月で完了したタスクを一覧化し、最も時間がかかったものと最も短く終わったものを並べて比較する。粒度の差が五倍以上ある場合は、粒度基準の策定を先に行う。最後に、現在使用している他のプロジェクト管理ドキュメント——ガントチャート、課題管理表など——を誰がどの頻度で更新しているかを確認する。更新の習慣がない組織では、RACIの更新体制を別途設計する必要がある。この三段階は、RACIを導入すべきかどうかの判断にも使える。

RACIマトリクスは、正しい前提のもとで使えば、役割の重複や空白を可視化する実用的なツールだ。問題はツールそのものではなく、ツールが機能する条件を整えないまま導入することにある。DexVault24がこの記事で示した三つの問いは、RACIを「作る」前に「問う」ためのものだ。表を埋める前に立ち止まる時間が、結果的にプロジェクト全体の時間を節約する。