yigarashiのブログ

学んだことや考えていることを書きます

「エラスティックリーダーシップ」でソフトウェア開発をうまくリードする方法を考える

僕にはリーダーシップがわからない。
しかし無策で取り組むべきでないことだけはわかる。

ということで、自分の周囲で共通言語としてよく参照されている「エラスティックリーダーシップ」を読むことにした。自分は新米リーダーとして困りをたくさん抱えているのだが、そこから脱出するための知見が山のように書いてあった。適用しやすいシンプルな枠組みや考え方が提示されていて、最高のリーダー、そして最高のチームを目指して頑張ろうという気になった。初版は2017年5月で今さら感もあるが、学んだことや考えたことを整理してみる。

エラスティックリーダーシップモデル

ここが本書の中心であり一番有名なところだと思う。チームにはサバイバルモード、学習モード、自己組織化モードの3種類があり、それぞれでリーダーは異なるリーダーシップを発揮するべきというもの。具体的には、サバイバルモードであれば指揮統制でチームが学習する余裕を生み出し、学び始める学習モードではコーチとしてチームが問題解決の能力を獲得できるように、自己組織化モードではファシリテーターとして自律的な問題解決を支援するようにとしている。チームリーダーマニフェストを引用して、チームリーダーは適切にリーダーシップタイプを使い分けることで、チームを成長させ自己組織化させるための存在だとしている。各モードやリーダーシップタイプについては、インターネット上にも様々な解説があるのでそちらを参照して欲しい。

まず自分がなるほどと思ったのは、チームリーダーの目標が「チームの自己組織化」と言い切られている点だ。当初は漠然と「何か重要な決定をしなければいけない」「未来の方針を示さなければいけない」と肩肘を張っていたのだが、もう少し引いた視点でリーダーのあり方を考えられるようになった。僕が目指すべきはチームとして期待された責任を果たし成果を出せる状態だ。その理想のやり方が自己組織化で、優先的に上手くなりたい事項は時間を生み出して学習したら良いし、その時チームで能力を獲得するのがどうしても困難なら自分が処理したら良い。重要な決定や未来の方針は一般に難しいのでリーダーまでフォールバックするケースが多いだけで、チームが議論して適切に判断できるならそれに越したことはないし、それを目指さないとリーダーがボトルネックになってしまう。

もうひとつ素晴らしいと思ったのは、「学習モード」によって自己組織化への道のりの解像度が高まっている点だ。これまでもスクラムマスターの文脈で自己組織化のことは知っていたし、それが望ましい状態であることも知っていた。ただ、そこにどうやって到達したら良いかが曖昧だった。自分が解決することをやめて、ティーチング、コーチング、ファシリテーションをするのだと言われても、では今日なにを始めるかに繋がらなかった。エラスティックリーダーシップモデルはそこを具体化してくれている。自己組織化した状態になるには、課題を解決する方法や自力で解決に至るメタスキルがチームに備わっていなければいけない。ならばそれを学習するフェーズが必要だというシンプルな主張が「学習モード」である。これまで自分は、指揮統制か全てを任せるかオールオアナッシングの選択肢しか持ち合わせていなかったので、その間に丁寧に能力獲得を支援する振る舞いがあるという教えは大きな意味を持つ。具体的な技術やスキルに加えて、「問題を解決するのは僕だけの仕事ではない」こともまた丁寧に教え、自己組織化への階段を一歩ずつ登ることを学んだ。

本書はこうした重要な気づきを促しつつ、各フェーズでうまくやるためのフレームワークや多様な話題をカバーするエッセイ集までついてくるのでとにかく心強い。リーダーとしての振る舞いに困っている人はぜひ読むと良いと思う。共通のモデルで喋れる人が増えるのも望ましい。

誰でもリーダーになることはある

こうした抽象的なマネジメント論になると、自分とは関係ないと思うエンジニアも多いような気もするのだが、このモデルはチームでコードを書いていく大小様々な場面に適用できると思う。例えばチームで1、2ヶ月くらいかかる大きめの機能開発をリードすることになったとしよう。チームの基本ロールとしてのリーダーでなくとも、こういった一時的なプロジェクトリーダーを引き受けることはあると思う。

プロジェクト開始時は、リーダーが全体の設計や大まかなタスクの洗い出しを行なって地盤を整えるのが定石だ(この時点からチームで取り組めるのが理想かもしれないがチームの成熟がかなり必要だと思う)。これは指揮統制型のリーダーシップだ。しかしプロジェクトの最後までこの型を維持するのは良くない。ソフトウェア開発に不確実性はつきものなので、プロジェクトが進むにつれて最初に想定していなかった問題が次々と現れる。これは当たり前のことで、アジャイルに対処すれば良い。しかしあらゆる問題がリーダーのところに集中すれば、普通はパンクしてボトルネックになってしまう。もうわかったと思う。自己組織化を目指すのだ。メンバー全員が何をするか理解して、個別の実装で発生する問題を相互にコミュニケーションして勝手に解決する状況を作り出せるのが理想だ。そしてエラスティックリーダーシップモデルを知っていれば、そのために何をすべきかもわかる。一旦プロジェクトの速度を緩め、学習の時間を取れば良い。全員で設計を何度も見返したり、モブプロをやって重要な部分のインターフェースを作って見せたり、手段はいくらでもある。そうして詳細な仕様を決めるところから渡せるようになれば、リーダーの負担は劇的に少なくなる。コードレビューや全体の整合性をチェックすることに時間を使えるようになり品質も高まる。

これは実際に僕が失敗したパターンから得た教訓だ。まだエラスティックリーダーシップを読む前に始めたプロジェクトで、指揮統制型のリーダーシップを続けた結果、自分のところにどんどん問題が集まってきてとても疲れてしまった。次はもっとうまくやりたい。

チームトポロジーとの合わせ読み

エラスティックリーダーシップを読んでいて、チームトポロジーの「チームファースト思考」と繋がる部分があり理解が深まったので紹介する。チームファースト思考自体は、優れたプロダクトを生み出すには個人ではなくチームの営みが重要で、そのチームが機能するように物事をデザインするという考え方だ。

チームファースト思考が目指すのは安定して機能するチームだ。安定して機能するとは、つまり自己組織化モードに到達して、変化に適応しながら安定したハイパフォーマンスを発揮しているということだと思う。いち早くこの状態に到達するためには、学習モードを早く抜けられるかが重要な要素になるはずだ。学ぶことが多すぎたり、複雑すぎたりすると、チームが自己組織化に到達して高いパフォーマンスを発揮するまでの時間はどんどん長くなる。つまり認知負荷の問題である。チームトポロジーでは、チームの認知負荷を制限し適切な状態に保つことを非常に重視している。主題と言っても過言ではない。エラスティックリーダーシップでは学習モードにおける振る舞いとしてティーチングが大きく取り上げられているが、それと同じくらい、学ぶことに優先度をつけたり、無理に学ばなくて済むように組織とアーキテクチャの形を変えることも重要ということだ。以前書いたテックリードとしてシステムの未来を示して品質の期待を合わせる - yigarashiのブログも、学習モードの道のりを短縮するために、学ぶべきことに優先度をつけた施策と位置付けることができる。認知負荷と学習モードがつながって、自分の中では相互に解像度が高まった。

チームリーダーマニフェストが掲げるチーム像も、チームファーストの考え方とよく整合する。

偉大なチームは成長によって作られる。雇うことで作られるものではない。

チームリーダーの目標は、チーム内の人々のスキルを自己組織化に至るまで継続的に成長させることだ。

これがチームリーダーマニフェストの前半部分である。チームリーダーは自己組織化チームをつくりあげ成果を出すことに心血を注ぐ。それは容易な道のりではなく、チームに余裕を作り、スキルを学習させ、自律的に運用できるように長い時間をかける必要がある。こうした営みを可能にするためにも、長続きする安定したチームは欠かせない。そして一度機能するようになったチームを破壊するのがどれほど勿体無いことか、より実感を伴って理解できる。エラスティックリーダーシップの19章では、チームもまたチームリーダーによるプロダクトであるという思想が紹介されている。全くもってそうだと思う。チームリーダーはそのくらい熱心にメンバーの成長を志向するのが良いのだろうし、上位の意思決定者もそれをリスペクトできると良いと思う。

まとめ

以上、エラスティックリーダーシップを読んで考えたことをつらつらと書いてみた。なにはともあれ僕は今日も新米リーダーなので、学んだことを少しずつ試しながら、最高のチームを目指していこうと思う。