移譲の物差しを活用してエンジニアを育てる
概要
O'Reilly Japan - エンジニアリングマネージャーのしごとに「移譲の物差し」という概念があります。
それを活用してエンジニアを育成する方法を考えます。
この記事で伝えたいこと
- 移譲の物差しとは何か
- 移譲の物差しを活用してエンジニアを育てるテクニックを紹介する
移譲とは
移譲とは
タスクの責任を自分から部下に移動すること
悪い移譲のパターン
自分がやってしまう
本来、メンバーに振るべきタスクまでも自分ひとりで抱えてしまう。
メンバーは重要な仕事を任されないため、信頼されていないと感じてしまう。
丸投げしてしまう
メンバーに丸投げしたら、タスクそのものを忘れてしまう。
タスクが完了したか、どんな品質だったかも感知しない。
タスクが適切に管理されていないため、期待した品質に届かず、期限も守られなくなる
移譲にとって重要な概念
説明責任
タスクを求められる品質で完了させる責任を持つということ
実行責任
タスクを実際に自分で行うということ
移譲とは
タスクの実行責任を他の人に託しつつ、説明責任を持つこと。
良い移譲をするには
良い移譲はタスクの実行責任を誰かに渡す一方で、説明責任を負い続けることで行われます。
以下の図で示すようにタスクを個人にどのように移譲するかには度合いがあります。
引用：O'Reilly Japan - エンジニアリングマネージャーのしごと/初版/51p
図の左から右にいくに従って移譲の度合いが大きくなっていきます。
「完璧な移譲」は移譲された人が助けを借りることなく、期待される品質でタスクを完成できる場合にのみ可能なことに注意が必要です。
また、仕事の重要度により、より重要な仕事は移譲を少なくし、より重要でない仕事は移譲するなどして、コントロールを操作することが大事です。
移譲の度合いに応じた育成
ここからが本題です。移譲の度合いに応じてどのような育成テクニックがあるかを考えていきます。
移譲なし
自分で全部やることです。
自分がやり方を示す
部下を教育します。
ドキュメントやガイドラインを用意し、それに沿って自分が実際にコードを書きながら、隣で見ていてもらいましょう。
相手が行い自分がガイドする
コーチングをします。
相手がコードを記述し、それに対して自分がガイドしていきます。
相手が行い、自分が頻繁にチェックする
タスクの粒度を数時間単位に分割します。
マイクロマネジメントに近い手法です。一日に何回か相談タイミングを設けて、その時点で困っていることを引き出して解決しましょう。
参考：「進捗どうですか？」より2015倍捗る「困ってますか？」 - Qiita
相手が行い、自分がときどきチェックする
タスクの粒度を数時間〜１日に分割します
毎日タスクの成果物を提出してもらいます。途中なら途中と記述しておいてもらうと、どこが完成していて、していないのかがわかります。
翌朝レビューを返します。
終わったら相手が知らせてくる
タスクを相手に投げて、完了次第、軽くタスクの内容をチェックして完了します。
相手のことを強く信用しています。
完全な移譲（相手がやる）
丸投げのことです。
移譲につかえそうなアイデア
タスクを一旦TODOリストに書き出してもらって、レビューする
何をするかを明確にしつつ、間違った方向に進むことを防ぐことができる。
テストコードだけ先に書いてもらって、レビューする
作る機能はわかっているものの、どんな機能を実際につくればいいか、イメージがつかないときに有効
毎日ペア・プログラミングする
メンター側の負担が半端ないですが、ジュニアの成長を高速化できます。
タスクの粒度を下げる
タスクの粒度を数分〜数時間で終わる単位に分解する。
作業中に迷いがなくなるため、作業がゲーム感覚でスムーズに進む
コードの雛形をtodoコメントベースで実装してレビューする
手戻りを減らせます。
Discussion