Executive Summary
- 役割分担を明確する場合はRACIを理解しよう
- Aは「命令責任」、CとIはタイミングの違い、と理解しよう
- 誰かがやってくれる、と思っているタスクはないか確認しよう
はじめに
こんにちは、コバログです。久しぶりの投稿となります。
最近あるメディア媒体への寄稿準備をしており、中々自分のブログを更新する時間を持てずにおりました。
ひと段落したので、ブログの方も再度頑張っていこうと思います。
また、寄稿の話は時間があったらこちらのブログでも紹介しようかと思います。
さて今回はこのブログのメインの一つである、フレームワークにおいて「メンバーの役割分担を明確化するモデル」の中から「RACI」を取り扱っていきたいと思います。
それって誰の責任？
こばじゅんさん聞いてください！
今隣の部署と揉めてるんです。
何を揉めてるの？
先日ある資料作成をお願いしたんです。
作成はしてくれたんですが、一部市場調査が必要な箇所があって事前相談もなく勝手に実施されてたんです。
その内容はこちらの部門に大きく関わる事なんで、こちらでやりたかった。。
もしくは事前に一言相談してくれればよかったのに。。
って何てことがあったんですよね〜
う〜ん、それはコミュニケーションの問題もあると思うけど、、、
今後も定期的に依頼が発生するのであれば、事前にもっと役割分担を明確化した方が良いかもしれないね。
RACIを作って次回からお互いの役割をすり合わせしてみたら？
RACI (れーしー) ?
業務の責任者や責任範囲を明確にしたいときに使うフレームワークです。
R,A,C,Iは以下の頭文字をとっています。
| 名前 | 意味 | 説明 |
|---|---|---|
| Responsible | 実行責任者 | 業務を実行することに責任を持つ |
| Accountable | 説明責任者 | 業務内容や進捗、状況を組織内外に説明する責任を持つ |
| Consulted | 相談先 | 業務の実行を支援し、相談先となる |
| Informed | 報告先 | 業務の進捗について最新の情報を受け、報告先となる |
RとA, CとIの違いを理解する
なるほど、これを使ってどっちの部署がお互い何について責任を持っているか明確にするわけですね！
そういうことだね！
でもちょっと、待ってください。
R(相談先)とI(報告先)の違いがよく分からないんですが。
相談されるのと報告されるのは同じじゃないの？
さて、RACIを実際作成してみると、下記２つで迷うシーンがあります。
- RとAの違い
- CとIの違い
この違いについて解説していきましょう。
この二つの違いをわかりにくくしているのは、Aの日本語訳である「説明責任」だ。
よく政治家などが何か不祥事を犯して、記者や他党から「説明責任を果たせ」なんて聞くだろう。このシーンをイメージすると説明責任＝実施責任では？
という、イメージが働きRの「実行責任」と混同してくる。
これを解消するためにAは「説明責任」ではなく「命令責任」という訳語で理解するとわかりやすい。
つまり、Aの責任を持っている人は、命じたことへの責任で、Rは最後までやり遂げる事への責任だ。
プロジェクトに置き換えると、Aはプロジェクトオーナーやプロジェクトリーダー、Rはプロジェクトメンバーに該当する。
さらにわかりづらいのは、この違いだ。
相談される事と、知らさせる事は度々同じ意味を持つ。
なぜなら、相談されるということはその動作の中に「知らせらる事を包含しているからである」。
この二つを理解するためには、下記をイメージするとよい
- Cとは「事前に」相談される
- Iとは 「事後に」知らされる
そう、つまりタイミングの違いである。
Cのロールを持っている人は、何らかの課題や問題が発生した際にその解決方法について深い知見または解決方法を持っている可能性があるため、
「事前に」相談する事で問題の解消を図ったり、作業内容に問題がないかをレビュー出来る。
一方Iのロールを持っている人は、そのタスクの進捗に興味があり、その進捗を報告する義務があったり、その進捗が別のタスクの作業に影響があるため知っておきたい人が適切だと言える。
父の日のプレゼント作戦でRACIを理解する
な、なるほど。
何となく理解できました (笑)
怪しいな。。。じゃあ、分かりやすい具体例で考えよう。
次のシーンをイメージして、RACIの役割の違いを理解してみよう。
父の日に内緒で父さんにプレゼントを買うことを、母・兄・弟の三人で計画した。
母は兄・弟にお金を渡し、
兄にはA商店街でケーキを、
弟にはB商店街でネクタイを買う事をお願いした。
兄「ケーキは俺のセンスで決めていい？」母「いいわよ、よろしくね」
弟「ネクタイはどんなの買えばいいのかな？」母「兄ちゃんに聞いてみて」
兄の行動は？
兄は早速、ケーキを買うためにA商店街に向かう。しかし、ケーキは売り切れだった事を知る。
兄「まじかよ。う〜ん、C商店街に行くとするか。」
兄は機転を利かせ、ケーキを買うために計画を変更して対処する。
弟の行動は？
一方、弟はB商店街のスーツ売り場でネクタイコーナーを見つける。
弟「あ、もしもし兄さん？赤と黒があるけど、どっちがいいかな？」
兄「赤いもの着てるとこみたことないだろうが。黒にしろ、黒に。」
こうして、無事ケーキとネクタイを購入した二人は家に帰宅し、その日の夜母と三人で父にサプライズ祝いを行うことができました。
めでたしめでたし。
さて、上記の例をRACIにすると次のような形になる。
| タスク | 父 | 母 | 兄 | 弟 |
|---|---|---|---|---|
| ケーキを買う | I | A | R | |
| ネクタイを買う | I | A | C | R |
| トラブルに対処する | A | R | R | |
| 父の日を祝う | I + R | R | R | R |
ケーキを買うタスクについては母が承認してお金を出し(A)、兄がそのタスクを実行 (R)した。
兄はケーキがA商店街がないというトラブルに見舞われたが、ケーキを買うことそのものにスコープ変更が起きたわけではないので、自分の頭で方法を変えて「ケーキを買う」という実行責任を果たした。
一方、ネクタイについては弟が購入のタスクを担い (R)、兄にアドバイスを求めた (C)。
仮にネクタイが全て売り切れており、ハンカチへ変更しようと考えた場合、命令責任者である母 (A)にタスクのスコープ変更の承認をもらう必要がある。
そして、全てのタスクは完遂し、時差を経て父親はそれを知ることになる (I)。
最後は家族全員で父の日を祝う (R)事になる。父は祝われる側 (I)であると同時に、みんなとケーキを食べながらその日を祝う (R)のである。
RACIを使うことで役割と責任を可視化できる
このようにRACIを利用することで次のメリットが得られます。
- 各業務の役割と責任を可視化できる
- メンバーの円滑な連絡を整備できる
- 報連相のフローを明確化できる
このようにRACIを作ることで、「きっと誰かがやってくれるだろう」「このボール、どっちがやるんだろう」といった曖昧な状態となることを防ぎ、お互いの責任分界点を明確にすることができます。
必ずしも全てのプロジェクトやチームで作る必要はありませんが、役割が不明瞭になりやすい場合はこちらのフレームワークを使って、ぜひ見える化を図ってみてください！
以上、コバログでした。
コメント