目次

  1. RACIとは
  2. RACIの役割
    1. Responsible（実行責任者）
    2. Accountable（説明責任者）
    3. Consulted（相談先）
    4. Informed（報告先）
  3. RACIチャートとは
    1. RACIチャートの必要性
    2. RACIチャートのメリット
    3. RACIチャートの活用シーン
  4. RACIチャートの作り方
    1. ステップ1.タスクを書き出す
    2. ステップ2.担当者を書き出す
    3. ステップ3.RACIを割り当てる
    4. ステップ4.関係者に共有する
  5. RACIチャートを使用するときの注意点
    1. 適用範囲を明確にする
    2. タスクの粒度を合わせる
    3. 定期的にアップデートする
  6. RACIを活用してプロジェクトを成功に導く

　RACI（レイシー）とは、プロジェクトにおいて、役割や責任を明確化するために用いられる概念です。タスクの実行に関連する役割である「Responsible（実行責任者）」「Accountable（説明責任者）」「Consulted（相談先）」「Informed（報告先）」の頭文字から構成されています。

　プロジェクトマネジメントにおいては、各タスクにおける役割と責任を明確化しておくことが重要です。タスクを実行している際にトラブルが発生したり、作業が遅延したりすることはよくあります。こういった場合に責任者が明確でないと、責任の押し付け合いになり、さらなるトラブルに発展しかねません。

　また、タスクを実行するうえで担当者がわからない点について相談したり、進捗状況を報告したりする対象が必要です。RACIを活用することで、これらの問題を回避し、円滑にプロジェクトを推進できるようになります。

　ここからは、RACIのそれぞれの役割と責任について詳しく説明していきます。

RACIの役割
RACIの役割（デザイン：中村里歩）

　Responsible（実行責任者）は、タスクを実際に実行し、責任を担う役割です。タスクの実行担当者が一人の場合は実行責任者も当然一人になりますが、実行担当者が複数人の場合は二つの考え方があります。

  • タスクの実行担当者すべてを実行責任者として表現する方法
  • 実行責任者を一人として、ほかの実行担当者をSupport（支援者）と表現する方法

　どちらの場合でも実行責任者と表現できますが、タスクに対する責任の意味合いが異なってくるため、プロジェクトを通してどちらの表現方法にするかを統一しておく必要があります。

　Accountable（説明責任者）はタスクを統括し、関係者に説明する責任を担う役割です。実行責任者からの報告でタスクの状況を把握し、タスクが正常に完了するための最終的な責任を負うことになるため、タスクのオーナーとも考えられます。

　責任の所在を確かなものにするためにも、一つのタスクにつき説明責任者は一人とする必要があります。小さなタスクの場合は、実行責任者が説明責任者を兼ねる場合も多くあります。

　Consulted（相談先）はタスクを実行するうえで、困ったことや問題が発生した際に相談先となる役割です。実行責任者や説明責任者に対してアドバイスを行う立場であるため、タスクに関する知識・経験を多く持ち合わせている人が適任になります。

　タスク内において専門性が分かれる可能性があり、タスクの実行・説明責任を負う立場でないことから、複数人設定しても問題ありません。実行責任者、説明責任者からの相談に対してアドバイスをする立場のため、双方向のコミュニケーションが求められます。

　Informed（報告先）は、タスクの進捗状況や完了の報告を受ける役割です。相談先と違い、通常は説明責任者からの報告を受けるだけの片方向コミュニケーションになりますが、報告内容に問題がある場合は説明責任者へ連絡します。

　報告先は、プロジェクト内外にあります。プロジェクト内の報告先は、該当するタスクに関連するタスクの関係者です。プロジェクトにおいては、タスク間に関連性や前後関係があり、各タスクが独立していることはほとんどありません。そのため、それらのタスクの関係者を報告先として、タスクの進捗状況を共有する必要があります。

　プロジェクト外の報告先は、プロジェクトの人員や工数、コストなどを管理している総務や経理などの管理部門や、プロジェクトに影響を与える可能性のあるステークホルダーが考えられます。これらの報告先は、報告を受けてタスクの状況に問題があると認識した場合、説明責任者に連絡して詳細な状況を確認するのが一般的です。

　プロジェクト内外のどの関係者を報告先とするかは、プロジェクトレベルで合わせておく必要があります。

　RACIの概念を図にしたものが、RACIチャートです。チャートで可視化することにより、各タスクについて誰が関係者であるかを把握しやすくする役割があります。

RACIチャート
RACIチャート（筆者作成）

　上記のように、縦軸にタスクを、横軸に担当者を配置して、タスクと担当者が交わる部分に担当者の役割をRACIの頭文字で記述するのが一般的です。

　RACIチャートは、プロジェクトを円滑に進めるうえで役に立つチャートです。プロジェクトの規模が大きくなってくると、関係者が増えたり、サブプロジェクトなどでプロジェクトチーム内が階層化されたりしがちです。すると、タスクの担当者が把握しづらい状態となり、マネジメントが複雑化し、トラブルの温床となります。

　RACIチャートを用いてタスクの関係者を可視化することで、プロジェクトが円滑に進むようになります。

　RACIチャートには、以下のメリットがあります。

  • 役割と責任が可視化されることでプロジェクトチーム内での共通認識が高まり、トラブルを未然に防げる
  • 困った場合の相談先やトラブルが発生した場合の責任者がはっきりしているため、不要なコミュニケーションが発生せず、業務効率化につながる
  • 実行責任者と説明責任者が特定のメンバーに偏っていないか把握しやすく、タスクのバランスがとりやすくなったり、タスクに必要な人員の調整がしやすくなったりする

　RACIチャートはプロジェクトマネジメントにおいて、「資源マネジメント」を行う際に活用されます。プロジェクト資源マネジメントとは、プロジェクトを進めるうえで必要となる資源に関連するマネジメント活動のことで、資源についての計画、獲得、育成、コントロールなどが含まれます。資源は「人的資源」と「物的資源」に分かれており、RACIチャートは「人的資源」をマネジメントする際に使用するものです。

　サブプロジェクトなどで階層化されていたり、チームメンバーの役割が複数にまたがっていたりするなど、プロジェクト規模が大きく複雑化すればするほど、RACIチャートによる役割・責任の明確化と可視化の効果が発揮されます。

　また、RACIチャートは一般的にプロジェクトマネジメントで使用するものですが、役割、責任を明確にしておくことはプロジェクトだけでなく、通常の業務においても大切です。

　通常業務でも部門の業務管理にRACIチャートを活用することで、新たに配属されたメンバーが部門の業務の状況を把握できたり、マネージャーはメンバーの役割の偏りを把握しやすくなったりするなどのメリットもあります。

　ここでは、実際にRACIチャートを作るときの手順を見ていきましょう。

  1. タスクを書き出す
  2. 担当者を書き出す
  3. RACIを割り当てる
  4. 関係者に共有する

　それぞれの手順を解説します。

　縦軸の一番左の列に対象のタスクを書き出します。特に順番は決められていませんが、プロジェクト内で前後関係があったり、時間軸を意識したりして書き出すと、運用時に見やすく、管理がしやすくなります。

　横軸の一番上の行に担当者を書き出します。こちらも順番は決められていませんが、プロジェクト内にサブチームがある場合はサブチーム単位で書き出すと、管理がしやすくなります。

　タスクと担当者が交差するセルに役割・責任に応じて「R」「A」「C」「I」を書き込みます。実行責任者と説明責任者を兼ねる場合は「R/A」と言った形式で記載します。

　RACIチャートを作成しただけでは意味がありません。関係者に共有することで、プロジェクト内のタスクの役割・責任を明確化し、プロジェクトが円滑に進むようになります。

　すべての関係者が最新のRACIチャートを参照している状態が望ましいことから、できればメールなどで送付する形でなく、Web上で最新版を参照できる状態にしておくなどの共有方法がおすすめです。

　RACIチャートを使用するうえでは、以下の点に注意が必要です。

　大規模なプロジェクトの場合、タスクの量が膨大になります。この場合、一つのRACIチャートで表現しようとすると見づらくなってしまうため、プロジェクト内でRACIチャートの適用範囲を明確にルール化する必要があります。

　一つのRACIチャートで表現するのが難しい場合は、サブプロジェクト単位でRACIチャートを作成するなど分割することも検討しましょう。

　プロジェクト内のタスクが多い場合や、プロジェクトが階層化している場合、タスクの粒度が異なってくることがあります。例えば、設計書を作成するタスクがあり、基本設計書は全体を作成するのに一つのタスクとしているのに、詳細設計書は機能別にタスクを分けているといったケースが挙げられます。

　一つのRACIチャート内でタスクの粒度が異なると、関係者が混乱する恐れがあるため、タスクの粒度を合わせておくとよいでしょう。タスクの粒度が異なる場合は、別のRACIチャートで管理したほうが混乱が起こりません。

　プロジェクト初期にRACIチャートを作成して、プロジェクト完了まで同じものをそのまま使い続けるというケースがたまに見受けられます。しかし、プロジェクトが完了するまでプロジェクト体制や各タスクの役割が全く変わらないということはまれですし、ステークホルダーが増える可能性もあります。

　そのため、プロジェクトの期間に合わせて一定のタイミングでRACIチャートをアップデートし、最新の状態にしておく必要があります。

　プロジェクトにおいては、タスクを進めるうえでさまざまなマネジメント要素がありますが、これらを疎かにすると、トラブルが発生しやすくなったり、成果物のQCDにも影響を与えたりします。

　RACIを活用してプロジェクトの状態を可視化・共有化することで、トラブルを未然に防ぎ、プロジェクトを成功に導けます。RACIは概念も導入方法も難しいものではありません。まずは、RACIチャートを作ることから始めてみてはどうでしょうか？