『任せる技術』で組織の成果を出す方法を考える

『任せる技術』を読んで、業務を任せられるソフトウェアエンジニアになる

ソフトウェアエンジニアとして技術力を日々伸ばそうとここまで生きてきていたが、組織としてのアウトプットを考える必要が出てくる機会が最近多くなった。

個人ではなく、組織のパフォーマンスを考えると大きく変わるのが、「個人の改善だけではどうにもならない」点だ。 これまでは、自分の中で工夫していれば個人としてのパフォーマンスを良くできた（そしてこれは比較的簡単だった）。しかし、組織となると他のメンバーのことを意識した改善が必要になってくる。

他のメンバーが関わってくると、個人でうまくいったやり方が通用しないため、根本的に発想を変えないといけない。 今の自分のポジションはあくまでプレイヤーだが、組織のパフォーマンスを考えていけるよう、これまで避けていたマネジメントのスキルを伸ばすために、読んで学びになったのが『任せる技術』だ。

まとめ

• マネジメントの重要なスキルとして、「他人（部下 etc）に仕事を任せる」ことがある。
• 仕事を任せることで、自分の時間にゆとりを生み、空いた時間で緊急でない重要な仕事できる。
• 任せるためには大切な要素がある
  • 主体性を奪わない。作業を命令するのではなく、できるようにサポートする
  • 責任を意識してもらう。そのために、ビジョンや目的を明確にする
  • 他人（部下）の成長を自分の成長よりも喜べる価値観を持つ。そして、他人（部下）から信頼される人間になる

マネジメントとは、他人に主体性を持ってもらうための手法論

松下幸之助『経営の要諦とはつまり、誰にどの仕事をどこまでぎりぎりの要望をするか』（注: 出典確認できず）

業務を一人でこなして大きなことを成すことは難しい。ソフトウェアの世界だとそういう稀な例もあるが、事業をする上ですべてを一人でこなすのはかなり困難だ。 そのため、業務について他の誰かに任せる必要が出てくる。

任せる際には 7つのポイントがある。

1. 無理を承知で任せる
   • できるから任せるのではなく、任せるからできるようになってくる
2. 任せる仕事を見極める
   • いきなり高度な業務を任せない。任せるならそれ相応のサポートをする
3. 相手に任せると伝える
4. ギリギリまで力を発揮させて様子を見る
5. 口出しを我慢する
6. 定期的にコミュニケーションを取り、相談に乗る
7. 指示するのではなく、仕組みを作ってサポートする

この本では具体的に上記の内容が触れられているのだが、下記に自分なりに理解した要約をまとめる。

1. 主体性を奪わない。相手の仕事を奪ったり、失敗の経験を奪わない
   1. 自分で話した方が速いとか、自分で細かく指摘した方が良い、というのは実際にそうだとしても、そうした瞬間に他人の主体性を邪魔してしまう。自分も最初はうまく出来なかったことを念頭に置く。失敗しないと本当の意味で理解するのは難しい
   2. 自分のスキルを周囲にひけらかさない。相手のことを聞いて、相手の課題を理解し、その上でアドバイスをする。仕事を頼む立場はより一層話を聞くことが大切になる（傾聴）
   3. できるだけ数値で見せる。KPI や客観的で透明性のある評価があれば、命令せずとも自己判断で改善ができる
2. 責任を持ってもらう
   1. 作業ではなく、責任を持ってもらう。作業を依頼しただけでは「次何しましょう？」の状態が続く。責任を持つことで自律性が生まれる
   2. 仕事を任せた場合は、「任せた」と伝える。そうでないと、お互いに責任が宙に浮いて誰も責任を取らない状況になる
   3. 責任を感じると「何とかしないといけない」と感じるようになり、また完遂したときは達成感を得られる
   4. 責任をとった部下は、部下が主役として称える（上司が自分の成果として前に出ない）
3. 部下や他人の成長や成果が、自分の成長や成果よりも喜べる価値観を持つ。そして、信頼される人間になる
   1. 自分が得点を入れるというプレイヤーとしての価値観よりも、他人が得点を入れて、組織全体が改善することに対して喜べるような価値観を持てるよう、自分の考えを変える必要がある
   2. 相手に任せるということは、そもそも任されるに足る人物でなければならない。普段の会話や 1on1 を通じて相手との信頼を持ってこそ、責任を任せることができる

主体性を失わないフィードバック方法 / 脱マイクロマネジメント

具体的に主体性を失わないようにするためには、フィードバックの方法を気をつける必要がある。 例えば、ある課題 A が気になった場合、下記の順にフィードバックが強くなる。

1. 事実の FB : A になっているね
2. 主観の FB : A になっているね、なんとかならないかなー
3. 評価の FB : A になっているね、これはまずい
4. 提案の FB : A になっているね、これはまずい、B したほうがよいのでは？
5. 命令の FB : A になっているね、これはまずいので、B をしよう

主体性を失わないためには、1, 2 で済ませる。3 まで来ると相手は「命令されている」と感じてきてしまう。

ティーチングとコーチングの違い

書籍には記載がないが、フィードバックの仕方はティーチング、コーチングの話に関連すると感じた。

1. 自立 : 関与しない（責任を任せる）← コーチング
2. 半自立 : 事実を確認する（定例など）← コーチング
3. 半依存 : 主観、評価を伝える（一緒に作業する） <- ティーチング & コーチング
4. 依存 : 具体的にどうするか伝えて教える <- ティーチング

すでにある程度できる相手に仕事を任せるときは、コーチングする意識が大切。 逆に新人のような全くやったことない仕事を任せる場合は、ティーチングが必要になる。

依頼した相手が相談に来ないときの対処法

依頼したはずの仕事が進まず、相談されないまま期限ギリギリになって発覚するということがよくある。

相手からすれば依頼主に伝えるのが遅れると問題が悪化する。悪化すると、悪化した理由の説明が必要になり、より一層相談が難しくなる。 また純粋に仕事が手一杯で相談にいく余力が残っていないこともある。

そのため、

• × : 「何かあったら相談してほしい」
• ○ : なにかある前に定例会で相談

ということが大切になる。定例会を依頼主から実施できるとさらに相談が行いやすい。

相手にスーパマンになることを求めない

そもそもマネージャーになれる人は、なれるだけの才能やスキルがある。 そのため、自分ができることと同じことを相手にも出来てほしいと考えてしまう。

しかし、マネジメントは「自分のクローンを作ることではなく、組織の成果を出すこと」であるため、一人の部下のスキルが足りてなくても、他の複数名とあわせて成果が出せていればよいのだ。

マネージャーとしては一人の部下のスキルを高めるということに専念するよりも、組み合わせで考えることも忘れないようにする。 そのためにも、方法を標準化したり、ノウハウをチームに展開するということが大切になる（緊急度が低く、重要な仕事）。

所感

自分はプレイヤーとしてソフトウェアエンジニアリングの力を高めたいと思う一方で、組織としての成果を意識する必要がある。 これをいかに両立するかが今後のキャリアの鍵になりそうだ。

ただ、この本を読んで思ったのは、「他人に任せることができれば、自分の時間を変えることができる」ということだ（もちろん、そもそも他人に任すこともないように必要な仕事を絞ることが大切）。 簡単なコーディングやリファクタリングは自分が必ずやらなければならない仕事かというとそうでもない。 代わりに、もっと専門性のある OS の低レイヤーの課題や大規模なリファクタリングの手法論を学ぶ時間を取れたほうがよい。

他人に任せられると、プレイヤーとして学習できる時間が増えてくるのではないかと感じる。

また、マネージャーがコードを書いてはいけないという道理はない。むしろ、可視化の部分や標準化についてはコードの力を使ってもよいはずだ。 Management as a code のようなことが今後できてもよいのではないだろうか？