
RACIチャートの意味とは?プロジェクトの責任分担を見える化する!
RACIチャートの意味とは?プロジェクトの責任分担を見える化する! https://biz-tips-collection.com/wp/wp-content/uploads/2018/05/raci_eyecatch-1024x683.jpg 1024 683 Biz Tips Collection Biz Tips Collection https://biz-tips-collection.com/wp/wp-content/uploads/2018/05/raci_eyecatch-1024x683.jpgRACI(レイシー)チャートとは、プロジェクトにおいて、プロジェクトメンバーの役割を明確にするためのフレームワークだ。コンサルタントがプロジェクトマネージメントでよく使用したりする。ステークホルダー(関係者や組織)が多い時に特に有効なツールとして利用できる。そんなRACIチャートがどんなフレームワークで、どのような場面で利用されるのか、解説する。
RACIチャートとは、役割や責任を定義するフレームワーク
「この件は誰がボールをもっているんだ?」
「渡辺さんが進めてたんじゃなかったの?」
それぞれの役割が明確でないと、このように、誰も進めていないタスクが発生したり、ボールの押し付け合いが発生したりする。
このような事態が発生しないようにプロジェクト、特にステークホルダーが多いプロジェクトでは、役割の明確化が重要だ。
RACIチャートは、そんな時のために使用されるフレームワークの一つだ。
RACIチャートは一言で言えば責任分担表だ。
RACIチャートでは参加者を以下の4つに分類する。
参加者は、人の場合もあれば、複数の組織が関わる場合は、組織単位の場合もある。
Responsible(実行責任者):タスクを実際に実行することに責任を持つ人。複数いることもある。
Accountable(説明責任者):タスクの結果に最終責任を持つ人。成果物やタスクの遂行に対して上層部などへ説明責任を持つ。タスクの承認者ともいえる。1人にすべきである。
Consulted(協業先):タスクに対して相談を受ける人。実行や成果に明確な責任は持たないが、必要な専門知識などをもっており必要に応じてサポートする。
Informed(報告先):タスクの進捗・完了や成果物について、報告を受ける人。
Consulted(協業先)とInformed(報告先)は、必ずしも必要でないが、Responsible(実行責任者)とAccountable(説明責任者)は必須となる。
RACIチャートを作る際、しっかりこの4つの定義を理解している必要がある。いざ作り始めて、作りづらさを感じる時は、ここの定義がしっかりわかっていないもしくは明確に決定されていない場合が多い。以下がよくごっちゃにされてしまう役割の違いだ。
あいまいにされやすいResponsibleとAccountableの違い
上司と部下で例えるとわかりやすい。部下はタスクを実際に実行するが、その結果を更に上の部長に報告するのはその部下の上司だ。部下がやらかしたら、上司が責任をとらされる。だから、上司は部下のタスク内容を管理や承認する。この場合の部下がResponsibleで上司がAccountableだ。
実際の現場でタスクの最終責任者が実際に実行する場合、つまりResponsibleとAccountableが同じ人物の場合も当然ある。
わかりにくいConsultedとInformedの違い
ConsultedとInformedもまた、区別がつかず混同されることが多い二つだ。
わかりやすい違いは2点。
・Consultedではコミュニケーションが双方向だが、Informedは一方通行の報告。
・Consultedでは主に動く前にコミュニケーション(相談)する。Informedでは主に動いた後にコミュニケーション(報告)する。
Consultedはどう進めるか困ったときに聞く人、Informedは進捗があった後に伝えておく人だ。
RACIチャートの例
上記のRACIの各役割の定義を踏まえ、実際のRACI表(チャート)は例えば以下の通りになる。
縦軸に人(もしくは組織)、横軸にタスク、そして各マスに役割が記載されている。
見ての通り、ResponsibleとAccountableは同じ場合もあれば、ConsultedとInformedはない場合が多い。
多数のステークホルダーで責任分担の認識をしっかり共有することが重要
RACIチャートが最も効果を発揮するのは、多数の参加者(ステークホルダー)がいる複雑なプロジェクトの場合だ。逆に、少人数のプロジェクトでは、わざわざRACIチャートを作らなくとも、各タスクの担当者を決めているレベルで十分回るケースが多い。複雑なプロジェクトでは、ボールがどこになるのか不明確にならないよう、RACI図を整理して公開しておくとよい。
逆にうまく行っていないプロジェクトで、現在のRACIチャートを書いて、役割が不明確なところを特定するという、問題解決的な使い方も可能だ。役割の不明確さだけでなく、AccountableとResponsibleの担当部署が遠すぎて、うまく連携できていない、という課題を特定できたケースも過去にあった。
ステークホルダーが多く、複雑なプロジェクトでは、RACIチャートを整理するのも手だ。