📎記事 - 仕事を任せるコツとやり方 - そーだいなるらくがき帳

Clipした日: 2024-11-23T17:09:18+09:00 Clipした記事: [仕事を任せるコツとやり方 - そーだいなるらくがき帳](https://soudai.hatenablog.com/entry/2024/11/23/132843) ---- チームで仕事を進めるうえで、仕事を任せるというのはとても重要だ。そうしないと事業はスケールしないし、マネージャやリーダーはチームの[ボトルネック](https://d.hatena.ne.jp/keyword/%A5%DC%A5%C8%A5%EB%A5%CD%A5%C3%A5%AF)になってしまう。　そこで自分が仕事を任せるうえで大事にしていることを書く。 1タスク単位の話からプロジェクト単位の話まで共通する汎用的なことを紹介する。 ## 裁量の範囲を決め、明確にする　任せる範囲を決めるということでもあるし、任せる範囲が複数の人の場合は役割分担なども明確にする必要がある。特にプロジェクトの場合はボールのお見合いになることも多い。　そこでチームで仕事をする上で大事な[フレームワーク](https://d.hatena.ne.jp/keyword/%A5%D5%A5%EC%A1%BC%A5%E0%A5%EF%A1%BC%A5%AF)を2つ紹介する。 ## RACIチャート　RACIチャートとは以下の4つの頭文字で、それぞれのポジションの役割をまとめるための[フレームワーク](https://d.hatena.ne.jp/keyword/%A5%D5%A5%EC%A1%BC%A5%E0%A5%EF%A1%BC%A5%AF)だ。 - Responsible - 実行責任者 - Accountable - 説明責任者 - Consulted - 協業先、相談先 - Informed - 報告先　それぞれの役割や責任を明確にすることで、チーム内のコミュニケーションが円滑になる。 RACIチャートの詳細については以下の記事を読んでほしい。 [RACI チャートとは？すぐわかる完全ガイド (実例付き) \[2024\] • Asana](https://asana.com/ja/resources/raci-chart) 　RACIチャートはプロジェクトの開始の場面で明確にしてもいいし、プロダクト[バックログ](https://d.hatena.ne.jp/keyword/%A5%D0%A5%C3%A5%AF%A5%ED%A5%B0)を[アサイ](https://d.hatena.ne.jp/keyword/%A5%A2%A5%B5%A5%A4)ンする時などにやっても良い。また仕事がなんだか上手く進んでいないな？というときはチームふりかえりなどで整理してもいい。特に異動や退職で引き継ぎの際に曖昧になったりしやすいので、そういうときも明確にすると良い。　脱線するが、asanaやJIRAなどのプロジェクト管理ツールが出す記事はプロジェクト管理のおすすめの[フレームワーク](https://d.hatena.ne.jp/keyword/%A5%D5%A5%EC%A1%BC%A5%E0%A5%EF%A1%BC%A5%AF)や考え方を多く紹介しているので一読すると良い。読みやすく大変参考になる。 [asana.com](https://asana.com/ja/resources/project-management) ## DACIモデル　RACIチャートに似ているDACIモデルというのもある。 RACIは前述のとおり、プロジェクトなど大きな単位での意思決定に対し、DACIはもう少し小さい粒度で意識すると良い。例えば決断の委譲はRACI、判断の委譲はDACIと言った感じだ。 - Driver - 仕事を進める人 - Approver - 仕事の承認、レビューワー - Contributors - 仕事をサポートする人 - 仕事を進める人たちが複数いる場合はDriverが責任者で他の人達はContributorsである - Informed - タスクを完了させるために必要な[ステークホルダー](https://d.hatena.ne.jp/keyword/%A5%B9%A5%C6%A1%BC%A5%AF%A5%DB%A5%EB%A5%C0%A1%BC) - 複数の場合もあるし、上司、CS、クライアントなど属性が違う場合もある - まず大前提として、DACIは最小まで細分化したタスクに対して[アサイ](https://d.hatena.ne.jp/keyword/%A5%A2%A5%B5%A5%A4)ンする単位の話であり、 DriverとApproverは、 **一つのタスクにつき一人** だ。 RACIはプロジェクトの単位だったりするので、例えば実行責任者と説明責任者がPjMとして兼任したりすることもあるが（良いことではないが）、DACIでのDriverとApproverの兼任は[アンチパターン](https://d.hatena.ne.jp/keyword/%A5%A2%A5%F3%A5%C1%A5%D1%A5%BF%A1%BC%A5%F3)だ。多くの場合、マネージャがApproverであり、Driverにメンバーを[アサイ](https://d.hatena.ne.jp/keyword/%A5%A2%A5%B5%A5%A4)ンする。そのうえでContributorsとInformedを事前に整理して進めよう。 Driverはそれらとコミュニケーションをとりながら情報を整理し、タスクを進めていく。 ## タスクを[アサイ](https://d.hatena.ne.jp/keyword/%A5%A2%A5%B5%A5%A4)ンする　上の[フレームワーク](https://d.hatena.ne.jp/keyword/%A5%D5%A5%EC%A1%BC%A5%E0%A5%EF%A1%BC%A5%AF)を理解したうえで、このスライドを読んでほしい。そうすると意思決定を円滑にして、タスクを明確にすえば、仕事が進んでいくことがわかる。 [speakerdeck.com](https://speakerdeck.com/soudai/aim-for-the-goal) ## 完了の定義　役割分担や責任範囲を決めたら、次は完了の定義を決める必要がある。タスクを分解し、[アサイ](https://d.hatena.ne.jp/keyword/%A5%A2%A5%B5%A5%A4)ンするときに完了の定義を決める。　完了の定義は **失敗したときの諦めるライン** も含む。具体的な例では以下のようなものを決める。 - 成果物の定義 - 期限 - 中間報告タイミング　これらは[5w1h](https://d.hatena.ne.jp/keyword/5w1h)を丁寧に整理するに近いし、ユーザストーリーを整理すると自然と纏まったりする。しかし開発作業ではない場合に往々にして漏れが生まれやすい。なので[ネクス](https://d.hatena.ne.jp/keyword/%A5%CD%A5%AF%A5%B9)トアクションをするまえに一旦、ここを整理するようにしてタスクを明確にすることが大事 ## 仕事を任せたら相手を信じる　完了の定義と最量範囲が明確であれば、問題があれば[エス](https://d.hatena.ne.jp/keyword/%A5%A8%A5%B9)カレーションされるはずだし、中間報告などのタイミングが明確になっているはずだ。そこで問題を認知すれば[リカバリ](https://d.hatena.ne.jp/keyword/%A5%EA%A5%AB%A5%D0%A5%EA)できるように設定されているので、それ以外のタイミングで不必要に報告を求めたり、現場に口を出しりしてはいけない。　もし、細かいフィードバックが必要なジュニアな相手に仕事を任せている場合は、そういう報告タイミングを作るべきである。明確に決めた場合はあとは信じる。そして信じて自分は別の仕事に集中する。　ここがプレイヤーとして優秀な人ほど苦手な印象がある。成果物が自分の意図した精度になっていないのであればそれは完了の定義が甘い、レビューの頻度が少ない、Contributorsが不足など設定条件の問題である。自分が全てをコン[トロール](https://d.hatena.ne.jp/keyword/%A5%C8%A5%ED%A1%BC%A5%EB)しようとすることをやめよう。 ## 最後に　逆に仕事を任せられる側は前述の内容を一通り確認して、期待値調整を行うことが重要だ。各項目を整理したうえで合意をとっておくことでスムーズに仕事が進めやすいし、条件などが変更された場合に差分がわかりやすい。　そして最後に仕事を任せるコツは「期待はしないが、信頼する」ことである。設定した条件を満たしてくれると信頼し、それ以上の成果については期待しないことだ。これは[夫婦円満](https://d.hatena.ne.jp/keyword/%C9%D7%C9%D8%B1%DF%CB%FE)のコツでもある。