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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

テックリードとしてシステムの未来を示して品質の期待を合わせる

最近チームのテックリードを拝命して、テクノロジーマネジメント領域もリードすることになりました。興味の中心は開発プロセスやデリバリーで、エンジニアリングはまだまだひよっこなので苦労の日々が続いています。この記事では新米テックリードとしての取り組みをひとつ紹介します。

私のチームでは10個近いコンポーネントのオーナーシップを持っています。それらの品質の期待度は大きく異なり、変更頻度、採用技術、システムに占める重要度といったパラメータから決定されます。この期待を見誤ると、変更頻度が極めて低いコンポーネントを頑張ってリファクタリングしたり、モダンな技術が採用され寿命の長いシステムを雑に拡張したりと、成果の小さいアクションを取ってしまいます。逆にこの期待を適切に捉えられると、チームのリソースがコスパが高いアクションに向かっていくことが期待できます。変更頻度の高いコンポーネントのCI/CDを改善し、重要なコンポーネントのリファクタリングを積極的に行う、といったムーブメントが自然に起こると理想です。また、そうした認識が揃っていることによって、レビュー等のコミュニケーションも円滑になることが予想されます。

こうした考えから、コンポーネントの品質期待度を順位づけして、チームのScrapboxに明記してみることにしました。実際に書いてみて面白かったのは、なぜその順位なのかを深掘りすることで、その一覧がそのままシステムの現状と未来を簡潔に示すドキュメントになったことです。例えば以下のような記述が並びました（実際は各コンポーネントで5行くらい書いています）。

• XXX
  • Scalaで書かれていてアーキテクチャも堅牢なので長くメンテナンスする
• YYY
  • リプレイス候補だが変更頻度が高いのでリードタイムに効くところは積極的に投資する
• ZZZ
  • 古代のシステムで変更が困難になりつつあり最優先でリプレイスする
• AAA
  • システム上の重要度は低いので動かなくなったらそのまま止めたい

水面下で検討されているリプレイスの計画なども透明化され、チームが自律的に行動するための材料を提供することができました。チームに参加して間もないメンバーからも、なかなかこういう雰囲気を感じ取るのは難しいので助かるとポジティブなフィードバックをもらいました。アクションを整理する際の指針としても機能し、実際に変更頻度の高いコンポーネントのデプロイ時間を半分にしてやったりと、コスパの高い開発にも繋がりつつあります。

優れたソフトウェアエンジニアを目指して、やはり日常的に品質向上に取り組みたいですが、そこの踏ん張りを効かせるには「そのコードに未来があると信じられる」ことが非常に重要だと思います。3年後、5年後も誰かがメンテするなら頑張ってやろうかという気持ちが湧いてきますし、実際に効果も高いです。そこを多少は信じやすい状態にしたのが今回の施策で、チームの足場をわずかでも固められたのではないかと思います。

Scrapboxの献立リストから食べるものを自動で決める

今日は豚の味噌漬けを食べた。コロナ禍に入ってから食事のほとんどを自炊でまかなっている。週に2回スーパーに買い出しに行くのだが、そんなに長居したいご時世でもないので、買い出し前夜に献立を計画して何を買うかメモするようにしている。

しかしこの計画が妙につらい。プライベートのScrapboxにある献立ページを眺め始めると、自分が何を食べたいのか悶々と考えてしまう。他にも、今の冷蔵庫の状態だとか、献立の共通の食材だとか、旬の食材だとか、さまざまな要素が献立を左右することになる。仕事で疲れている日に計画が重なると、意思決定力が摩耗しているので、ああでもないこうでもないと1時間くらい悩んでしまうこともある。

そうは言っても、たかだか数日なにを食べるかというだけの話である。そんなにリソースを使うのがいい加減バカらしくなってきたので、雑に自動化することにした。Scrapboxで以下のようなUserScriptを読み込むようにして、献立ページでConsoleを開いてkondate()と打ってやるだけだ。献立はだいたいリスト形式で並べてある。

// https://www.nxworld.net/js-array-shuffle.html
const shuffle = ([...array]) => {
  for (let i = array.length - 1; i >= 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [array[i], array[j]] = [array[j], array[i]];
  }
  return array;
}

window.kondate = (n = 6) => {
  const array = scrapbox.Page.lines
    .slice(4)
    .map((l) => l.text.replace(/\s/g, ''))
    .filter((s) => s !== '' && s[0] !== '[');
  return shuffle(array).slice(0, n);
}

めちゃくちゃ生活感のある実行結果が出ている。諦めてここから選ぶというルールにすることで、無限の可能性から解放されることに成功した。別に全部が全部この通りである必要はなくて、ひとつ決まれば食材の依存関係で勝手に思いつくこともある。とにかく初手で献立の洪水に投げ込まれないことが重要である。店に行った時なんかも、壁一面のメニューから選ぶよりも、「おすすめランチ」みたいなペライチのメニューから選ぶ方が気が楽だと思う。そんな感じだ。

最初は、献立管理をGitHubのリポジトリに移して、買い出しのメモまで自動生成するようなツールを夢想したのだが、献立くらいScrapboxで適当に管理したいし、楽になりたいのだから実装も楽をしたいと思って考えていたらこんな形になった。

上司とのシンクロ率を高める

最近、指揮系統ツリーの真ん中くらいでリーダーシップを発揮することが増えてきました。つまり自分に上司も部下もいるという状態です（業界的には上司、部下という雰囲気ではないですが便宜上）。そこでうまくやる方法を色々と考えているのですが、そのひとつとして「上司とのシンクロ率を高める」のが良いんじゃないかと考えています。自分の上司の思想や目指す方向を知り、腹落ちし、そっちに向けて自分もマネジメントをする。そうすれば組織としての成果を最大化できるだろうという目論見です。まあ当たり前といえばそうなんですが、ちゃんとできたら偉いと思います。

メンバーの行動と組織のビジョンに一貫性があり結びついていることを、OKRについてまとめたMeasure What Mattersでは「アラインメント」と呼んで重要視しています。僕がやりたいのはだいたいこれで、自分の行動を上司のビジョンに結びつけるということです。ただ、アラインメントは自然に起こることではなく、そのためにOKRといったツールまで考案されて、組織を挙げてなんとかせよということが書籍では説かれています。

どうしたものかと思うわけですが、「とにかく何を考えているか聞く」のが意外と良いようです。自分より高い視座で組織やプロダクトの課題について考えている人が上司なわけなので（少なくとも自分の環境ではそれが信頼できる）、無理にまとめてもらわなくても、とにかく喋ってもらったら何かしら面白いことが聞けます。それをひと通り聞いて、改めて自分が考えていることと突き合わせてみると、見えていなかった位置付けができたり、過不足が見つかったりして、これがなかなか面白いです。

Measure What Mattersでは、完全な上意下達なOKR運用はアジリティを損なうなど弊害が多く、ボトムアップを取り入れて創造性を引き出すべきとしています。うまいことにこの点もクリアできていて、明確に指示されるわけでもなく、とにかく脳内にある課題や目標を見せてもらって、それを持ち帰って自分の動きを決められるので、僕の創造性は刺激され続けています。自分からアラインメントしにいく形を取れているのが面白いポイントだと思います。

もともとは、自分の指揮系統の割と上の方にいる人とサシ飲みする機会があり、そこで色々聞いて刺激を受けたことがきっかけです。そこから、いろんな上司から同じように聞いたら面白いんじゃない？これってつまり自分を上司にアラインメントするってことじゃない？と展開して今に至ります。問題意識がある程度そろっている必要はありそうですが、コロナ禍で貴重な雑談のきっかけにもなるので、ぜひ試してみてください。

計画は総量を増やす！ - プロジェクト進行と計画の量のイメージ

※本記事では継続開発をしているスクラムチームがまとまった機能をリリースする状況を想像してください。関係者は多くとも10人程度で、期間は3ヶ月程度のシンプルなものです。

プロジェクトのフェーズごとに適切な計画の量をイメージして共有できると上手くいく手応えがあり、それをチームに展開した時の様子を書こうと思います。自分が陥った失敗ケースも示すので参考にしてください。おそらくスクラム初心者が陥りがちな罠だと思います。

ウォーターフォール

まずは手慣らしです。古典的なウォーターフォールだと計画の量はこんなイメージです。

開発開始時に一気に計画を行い、開発がスタートすると再計画はほとんど行われません。リリースが近くなると、結合したりQAが走ったりして色々な問題が明らかになるので対処するための計画が発生します。この図のように後ろの山が小さく収まることは珍しく、実際は開発期間中にたまりにたまった問題が溢れ出して炎上します。これが散々言われているウォーターフォールの問題です。

うまくいかなかったケース

自分が初めてスクラムを実践したときは以下のような計画の量をイメージしました。

ずっと同じペースで計画をし続けようという図です。その時は、リファインメントによってプロダクトバックログアイテムを用意して、計画とレビューのイテレーションで軌道修正をしていけば、特別なイベントは必要ないのではないかと思っていました。

しかしそれは誤りで色々な問題が発生しました。その中でも最大の問題はプロジェクトの全体像が見えてこないことです。定期イベントだけでちびちび計画を更新していくので、次のスプリントか、良くて次の次くらいのプロダクトバックログアイテムしか準備されません。そうすると、全体の設計の整合性やプロジェクトのスケジュールがなかなか見えてきません。

自分のケースでは幸い整合性は保たれて無事ゴールしましたが、あとから問題が発覚してウォーターフォールと似たような失敗を経験する可能性は十分にあったでしょう。

うまくいったケース

自分がうまくいったケースでは以下のような計画の量をイメージしました。

まず、プロジェクト開始時はウォーターフォールかのように全体を設計します。ここで全てのプロダクトバックログアイテムが洗い出されるくらいが望ましいです。スクラムの文脈ではこのフェーズはあまり語られない印象があり難しいですが、必要なメンバーを集めて必要なだけ話すつもりで泥臭く進めると良いと思います。開発がスタートしたら、リファインメントや計画、レビューといった定期イベントによって、アイテムを詳細化したり過不足を補ったりします。リリースが近づいたらギアをアップして計画を増やします。POに毎日デイリースクラムに来てもらうといったことも考えられそうです。ここまでやると、だいぶ安定してプロジェクトが進むようになるでしょう。

一般的なプロジェクトマネジメントの文脈では最初にタスクを洗い出すのは定石で、いま思うと必要に決まってるじゃんと思うのですが、慣れないスクラムの文脈でもそれが必要だと認識して発揮するには意外と気づきが必要だったなと思います。

まとめ

プロジェクト進行と計画の量のイメージについて、いくつかのパターンを示しました。ウォーターフォールとスクラムもどきは、実は計画の総量は大して変わっておらず、割り振りを変えているだけです。それらが両方うまくいかないのはおもしろいと思います。安定したプロジェクト進行を得るには、計画のタイミングを調整するだけではダメで、計画の総量もちゃんと増やす必要があるということです。うまい話はタダではないんですね。計画にコストを払うことに抵抗がある人もいるかもしれませんが、プロジェクトが手戻りなく、予想通り、安定して進むのは本当に素晴らしいことです。平均的には一番早いでしょうし、成功体験にもなり、やってよかったと思えるプロジェクトになります。コストを払いすぎるということはまずないので、たくさん計画しましょう。