RACIマトリクスとは？役割・責任・プロセスオーナー

RACIマトリクスを使うと、プロセスの各アクティビティを役割に対応付け、実行担当者、最終責任者、相談先、情報共有先を明確にできます。プロセスオーナーやPMO、ガバナンスの担当者にとって、プロジェクト終了後も続く責任分担を定めるうえで役立ちます。

多くの組織には、再編時に作成されたRACIマトリクスが、どこかのフォルダーやスプレッドシートに保管されています。難しいのは、マトリクスを対象のプロセスに沿った状態に保つことです。プロセスが変わってもファイルは更新されず、監査で指摘されるまで誰も気付かないことがあります。このガイドでは、4つの文字の意味、RASCIやDACIとの違い、受注から入金までの具体例、そしてマトリクスをフォルダーではなくプロセスと結び付けて管理する方法を説明します。

RACIマトリクスで何が分かるのか

RACIマトリクスは、責任分担を割り当てるための表です。行にプロセスのアクティビティ、列にロールを並べ、それぞれのアクティビティにおける各ロールの役割を記録します。RACIのロールと責任を一度定義すれば、同じ4つの文字をどのプロセスでも使えます。

RACIチャート、RACI図、責任分担表など、チームによって呼び方は異なります。ビジネスの現場で使われるRACIは、いずれも同じ4つの文字を指し、アクティビティとロールを対応付けた表です。

参照済みと情報提供済みの違いは重要です。参照済みのロールは決定前に意見を出し、情報提供済みのロールは決定後に結果を把握します。全員を参照済みにすると、不要な手順が増えることがあります。

RACIマトリクスを使うと、責任の所在が明確になります。また、責任者が決まっていないアクティビティも見つかるため、意見の食い違いや遅延につながる前に対応できます。

RACI、RASCI、DACIの違い

RACI、RASCI、DACIは、目的に応じて異なるロールの定義を使います。RASCIはRACIに支援のロールを加えたものです。DACIは、プロセスのアクティビティ全体に責任を割り当てるのではなく、意思決定に焦点を当てます。チームで責任分担を話し合う際に、RACI、RASCI、DACIのどれを使うべきかが議題になることがあります。

RASCIは、ワークショップで支援するチームを明示することで、担当者がいない作業を見つけやすくなります。DACIは、意思決定のレビューで、アクティビティの実行者ではなく、決定を推進する人を明確にするのに役立ちます。どちらも同じ課題を別の角度から捉える方法であり、最終的には「この作業の責任を負うロールは誰か」という問いに行き着きます。

受注から入金までのRACIマトリクスの例

この受注から入金までの例では、7つのアクティビティに6つのロールを割り当てています。「なし」は、そのアクティビティに割り当てられた役割がないことを示します。

この例を参考に、プロセス内で次の点を確認してください。

• 作業の実行者と責任者は、必ずしも同じではありません。 受注の作成では、営業担当者が作業を行い、受注管理が結果に責任を持ちます。
• 相談先が多いと、調整の負担が増えることがあります。 与信条件の確認や支払いに関する異議の解決には、複数のロールが関わります。どの段階で意見を求めるかを明確にする際に、マトリクスが役立ちます。
• 責任が一部のロールに集中することがあります。 少数のロールが多くのアクティビティの責任者になっている場合、その結果を担う権限やキャパシティがあるか確認してください。

プロセスのRACIとプロジェクトのRACIの違い

プロジェクトには、明確な範囲と終了時点があります。成果物が完成すれば、プロジェクトのRACIは廃止できます。一方、プロセスは継続するため、RACIには継続的な責任分担を記載する必要があります。プロセスのオーナーシップに関するRACIでは、プロジェクトでは問われない「作業の終了後、誰がプロセスに責任を持つのか」を明確にします。

この違いは、オーナーシップの割り当て方にも影響します。

• 繰り返し発生するアクティビティの責任者を決めます。 プロジェクトでは、移行作業の責任者を決めることがあります。プロセスのRACIでは、支払いに関する異議の解決など、継続的なアクティビティの責任者も特定する必要があります。
• チームをまたぐ作業を考慮します。 受注から入金までのプロセスには、営業、与信管理、オペレーション、財務が関わります。RACIはロールとアクティビティを対応付けますが、エンドツーエンドのプロセスオーナーを自動的に決めるものではありません。
• プロセスの変更に合わせて割り当てを見直します。 新しいシステムやチーム、ルールによって、アクティビティの実行者や承認者が変わることがあります。
• マトリクスをプロセス文書化と一緒に管理します。 別のスプレッドシートで管理すると、対象のプロセスとのずれが生じることがあります。ロールと割り当てをプロセス文書化と一緒に管理すれば、まとめて見直しやすくなります。

すでにプロセスをモデル化している場合は、可能な限り責任に関する情報をプロセスモデルと一緒に管理してください。まずフローを定義する場合は、プロセスマッピングから始め、その後、定義したアクティビティにロールを割り当てます。

プロセスオーナーをどう決めるか

RACIマトリクスでは、個々のアクティビティに対する責任を割り当てます。ただし、それだけではプロセス全体の責任者は決まりません。プロセスレベルのロールは、別途定義してください。

• **プロセスオーナー：**エンドツーエンドのプロセス、そのパフォーマンス、改善に責任を持ちます。委員会ではなく1人を割り当て、その責任を文章だけでなくマトリクスのプロセスレベルの行に記録してください。
• **プロセスマネージャー：**日々のプロセス運用を調整し、パフォーマンスを監視して、問題をエスカレーションします。小規模な組織では、オーナーがこの役割を兼ねることもあります。
• **アクティビティの実行者：**マトリクスで担当者として示されるロールです。
• **ガバナンスフォーラム：**プロセスの構造的な変更をレビューし、プロセスオーナーだけでは解決できない問題への対応を支援します。

オーナーシップを明確に保つには、次の方法が役立ちます。

1. **各アクティビティに責任者を1つ割り当てます。**2人で作業を分担する場合、両方を担当者にできますが、責任者は1つにしてください。
2. **個人名ではなくロールを使います。**人は異動や転職をします。ロールに基づく割り当てなら、組織の変更後も管理しやすくなります。
3. **プロセスを確認できる場所でマトリクスを公開します。**RACIを見つけにくいと、日々の業務で参照されにくくなります。
4. **レビューのきっかけを決めます。**システム、チーム、規制が変わったときや、プロセスのパフォーマンスから責任分担の見直しが必要と考えられるときに、マトリクスをレビューしてください。

RACIマトリクスが役立たなくなるよくある間違い

RACIマトリクスが役立つのは、割り当てが明確で、意思決定の指針になる場合です。次のような問題に注意してください。

• **1つのアクティビティに複数の責任者を割り当てる。**責任を複数人で共有すると、誰に決定権があるのか分かりにくくなることがあります。責任者は1つにしてください。
• **参照済みと情報提供済みを混同する。**参照済みのロールは作業が確定する前に意見を出し、情報提供済みのロールは作業後に報告を受けます。
• **組織図をもとにマトリクスを作る。**報告系統からは、各プロセスのアクティビティに誰が関わるか分かりません。まずアクティビティを洗い出し、関係するロールを特定してください。
• **ロールの列を増やしすぎる。**対象のプロセスに関係するロールだけを含めてください。列が多すぎると、マトリクスを確認しにくくなります。
• **一度作成したマトリクスを見直さない。**プロセスや組織の変更に伴い、割り当てが実態に合わなくなることがあります。
• **マトリクスを事務作業として扱う。**プロセスの設計やレビューの段階で使えば、作業の割り当てを決められるうちに検討できます。

RACIチャートの作り方

1. 対象のプロセスを1つ選ぶ

   開始点と終了点が明確なフローを定義します。部門全体では範囲が広すぎて、読みやすいマトリクスにならないことがあります。

2. アクティビティを洗い出す

   「値引きを承認する」「与信条件を確認する」のように、動詞と目的語で表します。

3. 関係するロールを特定する

   列は組織図だけをもとにせず、アクティビティから導き出します。区別しやすいロール名を使ってください。

4. まず責任者を割り当てる

   各アクティビティの責任者を1つ決めます。チーム内で合意できない場合は、行の残りを埋める前に解決してください。

5. 担当者を割り当てる

   作業を実行するロールを少なくとも1つ追加します。担当者は複数でも構いません。

6. 必要に応じて参照済みと情報提供済みを追加する

   参照済みのロールは作業が確定する前に意見を出し、情報提供済みのロールには進捗を伝えます。アクティビティに関わらないロールのセルは空欄にします。

7. 意思決定の方法を確認する

   「このロール間で意見が分かれた場合、誰が決めるのか」と確認します。答えが明確でなければ、割り当てを見直してください。

8. プロセスオーナーとレビューのきっかけを記録する

   オーナー、レビューのきっかけとなる出来事、マトリクスを最後にレビューした日付を記録します。

話し合いでは「責任者」と「担当者」を明確に区別してください。また、担当者が変わってもチャートを使い続けられるよう、個人名ではなくロール名を使います。

RACIマトリクスでは分からないこと

RACIマトリクスには、想定される責任分担を記録します。実際にその割り当てどおりに作業が行われているか、プロセスが期待どおりの結果を出しているかは分かりません。

• **実際の業務の進め方は分かりません。**与信条件の確認を担当者に割り当てても、そのステップが省略されたり、遅れて完了したりしているかは分かりません。
• **内容が古くなることがあります。**チーム、システム、プロセスのステップが変わると、割り当てが実態に合わなくなることがあります。
• **アクティビティへのロールの割り当てであり、エンドツーエンドの結果すべてに対する責任を示すものではありません。**プロセスオーナーは、引き続きプロセス全体に責任を持つ必要があります。

マトリクスに、プロセスの実際の進み方を示すデータを組み合わせましょう。プロセスモニタリングとプロセスマイニングを使うと、文書化されたプロセスとイベントデータを比較できます。両者に違いがある場合は、文書化の内容と実際の業務の進め方のどちらに見直しが必要かを確認しましょう。

責任の所在を明確にしたら、インサイトを具体的な行動につなげる手順を紹介するプロセス最適化の進め方をご覧ください。取り組み方を検討する際は、プロセス改善の手法も参考になります。プロセスマイニングに必要なデータについては、イベントログの文書化をご覧ください。