最近急に意識が高まって本を読みまくっている。
この本は、色んな人が既に感想やまとめを書いていらっしゃるので個人的によかったところまとめる。
フェーズに応じてリーダーがとるべき振る舞いは違う
チームの状況に応じてリーダーがとるべき振る舞いは違うよねという話。本書ではチームの状態は以下のように説明されている。
- サバイバルフェーズ
- 学習フェーズ
- 自己組織化フェーズ
これからの時代はサーバント型のリーダーだ！みたいなことをよく聞くわけだけど、当然それはチームの状態によって異なるよねという話。サバイバルフェーズ(チームに余裕がない状態)では、指揮統制型でリーダーがチームの取るべき方向を示し引っ張っていくことが大切だとのこと。
また例えばチームが学習フェーズであっても、過ちを正すのに沢山の時間がかかる場合には指揮統制型で望むべきだともあった(例えば、「Gitととかよくわからないし、ファイルサーバで管理しましょう！」みたいなことをチームが言い出したとき、バージョン管理されてないがゆえのデータ削除なんかの間違いが起きてからリカバリするのはしんどいよね)。
こういうリーダーシップ論って極端な話が多い気がするんだけど、現実に即して振る舞いを変えるべきだということが書いてあってとても納得した。
コミットメント言語
これは 「XXを△△△までにやります」 ということをチームのメンバーにコミットしてもらうようにする、と言うものだ。これは他の方のブログでは結構炎上していたけど、意図がちゃんと伝わってないのではと思う。
このコミットメント言語には前提がある
- チームがサバイバルフェーズではない(チームに学習するだけの余裕があるといこと)
- コミットメント言語では制御下にあるものを対象とする(コントロールできないことはコミットメントしない)
- メンバーがコミットメントできない(コントロールできない)ことを言ったら、リーダーはコントロールできるものに変更するように依頼しなければならない。
コミットメントをするのは、メンバーに期日や約束を絶対に守らせるようにする！！といった精神論的な話ではなく、コミットメントをすることで、問題を可視化する ためだ。
「今週中にやろうと思ってるんですけど難しいかもしれませんねー」みたいなタスクがずっと宙ぶらりんになってしまった経験はないだろうか。今思うと、こういったタスクは振り返りでもあまり進捗が悪かった原因が話し合われない気がする。
コミットメントしようとしたときに、「XXまでに実施する」といった断定的なことが言いにくい場合には以下のような課題が見える。
- 実は他チームのタスクを抱えていてそれを実施する余裕がない
- タスクの粒度が荒すぎて / 難しすぎて、何から手を付けるべきか迷っている
コミットメント言語は上記のような課題を早めにあぶり出すためのものなのだと思う。
いい兄貴
この本には途中から日本人開発者のエッセイが収録されているんだけど、なかでも伊藤直也さんの話がよかった。チームを良くすることだけに集中して技術や事業の問題に向きあっていないと、本当に組織が困った時(事業が伸びない、プロダクトが使われない、技術的に困難な課題に躓いてしまった)に役に立たないリーダーになってしまうというようなことが書いてあった。
リーダーというとどうしても組織づくりみたいなところに目がいってしまうけど、文字通りチームを技術的に・プロダクト的に「リード」できる人間であり続ける必要があるんだなと再確認した(大変だな…）
まとめ
前に友人のエンジニアと飲んでたときに、「今後のキャリアを考えたときに、マネージメントか技術かどっちに進んだらいいんだろうなー」という話をしたことある。そのときに「suzan2goさんは、マネージメントっていうよりはリーダーシップとかプロジェクトを引っ張ってくとかそっちな気がするなー」ということを言われた。
当時はあまりピンと来てなかったんだけど、この本を読んでいくらかそれがどういうことなのかクリアになった気がする。相変わらず「マネージメントをする」と言われるとちょっと身構えてしまうけど、「リーダーをやる」ということにはこの本を読んで少し抵抗がなくなった感じがする(単純に言い方だけの話だと思うｗ)。
