テックリードを再生産可能にする - テックリード養成講座をやっている話

この記事はEngineering Management Advent Calendar 2022の7日目です.

今はエンジニアリングマネージャ(EM)としてエンジニアリングマネジメントの4領域(プロダクト・プロジェクト・テクノロジ・ピープル)すべてを見ていますが, それ以前は長い間テックリードをやっていました. その経験を活かして, 最近は後進を育ててテックリードあるいは「弱いEM」*1をできる人材を増やそうとしています(これ自体がピープルマネジメントの一環ですね).

テックリードを育てるためにやっていることの全容を詳細に書くと本が1冊書けるくらいになってしまうと思うので, その中でも再利用可能そうな(と言うより再利用可能にしたいと目論んでいる)「テックリード養成講座」について紹介したいと思います.

Memeplex.appで生成した,
テックなリードが養成されるイメージ

経緯

僕自身は, 社内で公式に「テックリード」というロールが設定されてから3.5年ほど, それ以前の非公式なロールとしての時代も含めると6年ほど, テックリード的な仕事を経験しました. さすがに長くやりすぎていて前途有望な若者に席を譲りたかったのと, EM職種を新設するにあたって第1世代としてやっていくために, テックリードではいられなくなりました. テックリード卒業およびEM就任の最初の仕事が, 後任のテックリードを育てることと, EMの職種定義(評価基準等)をCTOといっしょに考えることでした.

「後任のテックリードを育てる」だと1回限りですが, EMの仕事としてはもう少しメタに「テックリードというロールを再生産可能にする」と考えた方がよいと思います. 必要なスキルは何で, どうやったら身につくか.

テックリードに必要なスキル

テックリードが身につけるべきスキルを一言で表すと「よきソフトウェアアーキテクト」だと思っています. こう言うと単にソフトウェアを「うまく」設計できればよく, そしてそれは純粋に技術的な知識と経験の豊富さによって実現されるように聞こえるかもしれません. しかし「うまく」には, たとえば, 将来に渡って安定してシステムを運用できるとか, チームで効率よく開発できるとか, 儲かるとか, 考えるべきさまざまな要素があり, そういった要素を含めて判断が下せること, 判断を下すための視座を持っていること, そしてその判断でもってチームをまとめられることまで含んでいます. むしろ「うまく」の部分に比べれば純粋な技術的知識は瑣末な問題です. なぜならチーム内のもっと詳しい人を頼れば済むからです(しかも頼る相手は1人とは限らず, 分野によって変えてよいのです).

単純に技術的な知識をつけて引き出しを増やしたり, アーキテクト業のための細かなテクニック(たとえば以前紹介した「松竹梅メソッド」のようなもの)を磨くのは実地で学んでいけばいい*2として, 視座はどうやって身につけたらいいでしょうか? 自然と身につくまで待ってもいいです(僕自身がそうやって身につけました)が, それでは「再生産可能」とは言えません.

目の前の仕事としてのアーキテクト業は十分にできるようになった人には, 最後の一押しとしてテックリードに必要な視座を持ってもらい, 「テックリードやってみませんか」という誘いに自信を持って「はい!」と応えてもらいたいものです. そのための概念のインストールのようなことが今回の主題です.

学びの設計

新しい概念を学ぶのは非常に難しいことで, ただ抽象的な話を聞いただけでは実体験と結びつかずピンとこないと思います. 逆に実践を通して概念を見出していくのは「自然と身につくまで待つ」のと同じであり, 先人が苦労して発見した道を再び辿ることになって遠回りになります. 効率よく概念をインストールするには理論と実践を両輪で回すのがよいと思っています.

理論の部分は単純に座学でよく, 実践部分は, 本当に実務を通してやるには時間がかかって大変なため, 演習あるいはワークショップの形式で「テックリード養成講座」をやることにしました.

座学要素

テックリードをやる上で知っておくとよい概念, テックリードの責務がそもそもソフトウェア開発においてどういう位置付けなのかといった話です. この部分はいずれどこかにきちんとアウトプットしたいのですが, かなりの分量になってしまうのでここではかいつまんで説明します. (実際の養成講座では, 伝えたい内容の大部分をカバーしたものをたまたま同僚が社内勉強会のネタとして話してくれたので, 今のところその時の社内資料を使っています.)

ソフトウェアエンジニアが関わるプロダクト開発では, 良い成果が得られるかどうかの不確実性が高い状況にうまく対処する必要があります. 良い成果(売上が上がる, ユーザが増える, 顧客の成功に貢献する, 顧客が次回も案件をくれる, などなど)を得るために, (1) 何をするのが一番よいか予めはっきりとはわからない(目的不確実性), (2) どうやるのがよいのか予めはっきりとはわからない(方法不確実性), という2つの不確実性があります.

たとえば, デュアルトラックアジャイルでは, ディスカバリトラックとデリバリトラックでそれぞれ目的不確実性と方法不確実性に対処します. 細かい単位で反復し, 経験主義的に学習し, チームワークを発揮することで, 常に「前よりもうまくやる」ようにして, 成功期待値を上げていきます.

アジャイルでやるかどうかは一見ただの手法の選択の話に思えますが, 常に環境が変化し先の見通しがはっきりとはわからない中でうまくやっていくための方法という意味ではもっと一般的に成立する話です*3.

テックリードが主に見るべきエンジニアの主戦場はデリバリトラックで, 方法不確実性にどう対処するかという話になります. だから, どう作るかを考えるアーキテクトとしての役割が重要になります. 細かい単位で反復して効率よく学習を繰り返すには継続的デリバリが必要とか, 素早さとプロダクトの安定性のバランスをうまく取るためにDevOpsやSREといった考え方を取り入れるとか, そういった話はすべてここにつながってきます. もちろん「どう作るか」のプロセスの部分(プロジェクトマネジメント)も大いに関係します(テックリードが考えるべきかどうかは別として).

ワークショップ

ワークショップと言ってもそれほど大袈裟なものではなく, 1回30分くらいで2~3人まで*4の受講者とインタラクティブに話しながらテンプレートを埋めていくものです. 以下が各回のテンプレートです. 講師役(ファシリテータ)が留意すべきポイントを付記してあります.

第0回

第0回 テックリード養成講座

テックリードという役割を再生産可能なロールにするためにいろいろするよ

この会の前提・目的

• テックリードの具体的なあり方に正解はない
• 自分とチームに合ったテックリードになれそうというイメージを持ち、自信を持ちたいですね
• そのために実際に自分の頭で考えていくための演習です

あわせて読みたい

座学資料へのリンク

感想コーナー

この回は事前に座学資料を読んできてくださいというものです.

第1回

第1回 テックリードとは

前提として以下の話がありますね

• 世の中の決まった定義はない
• 社内の公式なルールとして書かれているのは「チームの技術面での連絡窓口」のみ
• チームごとにはもっと力を発揮することが期待されているはず(だがあえて明文化されていない)

テックリードのロール(やっていそうな役割)

以下の手順で考えてみよう

1. ロールをいくつか挙げてみよう (網羅してなくてよい)
2. そのロールがなぜ必要なのか考えてみよう
3. 必要性が生まれる理由を考えてみよう (なぜなぜ5回)

• e.g. 技術的な選択に関する責任者

テックリード以外の領域

上で挙げたこととは共通しないが、会社の目的を達成するためのサブゴールにはどんなものがある?

• e.g. 成功確率の高い施策を考える

上で挙げたことに共通する目的は?

• 上の例は何の話をしているか?

テックリードのミッション

以上をふまえて「テックリードのミッション」を1文で表すとすると?

ここにミッションを書く

テックリードが果たすべき役割を抽象化されたミッションの形で導き出すために, テックリードの役割(だというイメージを持っているもの)を挙げてもらいます. 抽象化のために「なぜ」の問いを繰り返して, なるべく抽象的かつ, 他のロールとは区別できる程度に具体的な表現にします.

「テックリード以外の領域」のところは座学要素として出てきたテックリードの位置付けを再確認し, 他のロールとの関係性を改めて整理するために設けています.

ミッションとしてはおそらく「生産性の高さを維持したエンジニアリングができるチームにする」「よいアウトカムを素早く出し続けられるエンジニアチームにする」など、「うまく作る」を言語化したような文言が導かれると思います(導けるように「共通する目的は?」のところで問いを投げかけましょう). ただし必ずしもこの時点で完璧な文言が書けている必要はありません. この後の回で「これだとミッションと食い違っているように見えるけど, ミッションは本当に正しい?」などと訊いて適宜修正していけばよいと思います.

1文にまとめるところは受講者それぞれに書いてもらったり意見をとり入れたりしながら, 最終的にファシリテータが作文してまとめる形でかまいません. その際, この回で挙げられた役割に関しては「ミッション文ためにやってそうな役割を担う」と声に出して確認しながらやるとよいでしょう.

第2回

第2回 テックリードの具体的な仕事

いまテックリードがやっている / 世間でやっていると言われている 仕事

挙げてみよう

挙げたものに対して以下を考えてみよう

1. その仕事はミッションの達成にどう貢献するのか
2. ミッション達成のために他にやらなければならないことはないか
3. その仕事はテックリードがやらなければならないのか
4. 同じ目的の別の方法にはどんなものがありえるか

テックリードの役割を果たすために取るべき具体的なアクションについて考えてもらう回です. 具体的なアクションは1通りではなく, 自分が得意そうな方法を取ればいいことを意識してもらうことが目的です. もっと言えば, ミッションが達成されるなら必ずしもテックリードが直接アクションを取る必要はなく, 他のロールやチームの自律性によって達成されていても構わない点も重要です.

第3回

第3回 ケーススタディ(1/2)

チームの危機をどう救うか

事例に対して解決策を考えよう

• 解決のために情報が足りなければ訊いてよい (「状況の掘り下げ」に書き足す)
• 必ずしもテックリードの職責内で解決するとは限らない

事例1: 荒れたコードベース

• 状況
  • コードを追うのがたいへん
  • ある機能に1箇所手を入れるつもりでも直す箇所がたくさんある
  • 「他が壊れると嫌だからメソッドをコピーしてここでだけ新しい方を呼ぶ」としがち
  • デッドコードも多い
• 状況の掘り下げ
• 分析
• 解決策

事例2: 高いレビューコスト

• 状況
  • コードの差分が大きくなりがちでレビューに時間がかかる
  • メンバーがレビューしたがらないため実装が終わっていてもなかなかリリースできない
• 状況の掘り下げ
• 分析
• 解決策

事例3: 遅いリリースサイクル

• 状況
  • 週に1回リリースできればよい方な状態
  • テストを回すのに時間がかかり、作業ブランチのテストでジョブが埋まりがち
  • 同じバックエンドでもロールが複数あるためリリース手順をやるだけで時間がかかる
    • 手慣れていても30分
    • 慣れないと1時間以上
• 状況の掘り下げ
• 分析
• 解決策

事例4: 時間のかかる意思決定

• 状況
  • プロダクトのステークホルダが多い
  • ある機能に手を入れるには新仕様の確認のため各ステークホルダへ確認・調整が必要
  • 「確認・調整待ち」ステータスのタスクが山積み
  • 実装に入ってリリースまで辿りつくタスクが極端に少ない
• 状況の掘り下げ
• 分析
• 解決策

なにか他に思いつく事例は?

第2回まではトップダウンにミッションから役割, 役割からアクションを考えてきましたが, 今度はボトムアップに具体的な課題からアクション, アクションから役割を考えていきます.

事例は具体的であればあるほど話がしやすいため, 実際にあったことをベースにすると解像度が高くなってよいですが, 関係者に角が立たないように気をつけましょう. 上には一般的によくありそうなことを例として挙げていますが, 状況の掘り下げをスムーズにやるためにファシリテータが事例を用意しておくことが望ましいです. 受講者が持ち込んだ事例を取り上げてもよいと思います.

第4回

第4回 ケーススタディ(2/2)

第3回の続きをします. テックリードが解決すべきとも言えない課題をあえて取り上げていくとよいでしょう. なぜなら現実には「これはあなたが解決すべきことだよ」とは誰も教えてくれないからです.

第5回

第5回 テックリードとその周辺

ミッションを思い出そう

ここにミッションを書く

挙げてみよう

• TLのスコープに入らないけど必要そうなことは?
• それぞれについてやっていく役割を負っているのは誰?

エンジニアチームの生産性を高めるには?

プロダクトチームのアウトカムを高めるには?

グループ/事業のミッションを達成するには?

会社のミッションを達成するには?

テックリードの周辺の役割を観察して, 組織全体における位置づけを考えてもらう回です. 1段階か2段階上の視座のことがある程度想像できればよいので, あまり遠い範囲のことは深く話さなくてもよいと思います.

第6回

第6回 雑多な話題 / 自分なりのテックリード

メンバーとのコミュニケーション

コンテキストスイッチ

全体最適

その他、不安に感じることがあれば話しましょう

以下の問いに自分なりの答えをもっておきましょう

1. どういうチームにしていきたいですか?
2. そのために自分がテックリードとしてやれることはなんですか?

第5回までで拾いきれなかったFAQ的な話題を拾う回です.

メンバーとのコミュニケーションについては, 「テックリードの職責にはピープルマネジメントは含まないと思うが, チームビルディングを気にかけたり, チームメンバーと1on1している人もいるようで, そういうこともしないといけないのか」といった質問がよくあります. 僕の見解としては「(弊社では)職責ではないが, チームでの開発をよくするためにはお互いをよく知りよく話すことも重要で, 足りないと思うならやればよい」くらいです.

コンテキストスイッチに関しては, 「テックリードとしての会議が増えて時間が細切れになって集中できず, パフォーマンスが下がった」という相談をよく受けます. 僕の見解は「チームをまとめる仕事を別でやっているのだから, 1メンバーとしてのパフォーマンスが下がるのは当然, 受け入れよ」「どうしてもかつてのパフォーマンスを維持したいなら, コンテキストスイッチの達人になり, 手は動かせないが頭だけは動かせるときに詳細な設計を隅々まで考え, 頭の中にコードが一字一句浮かぶくらいにしておき, コードが書けるときがきたら頭の中のコードを無心でひたすら出力するだけ, となるまで自分自身を訓練せよ. これは訓練すればできるようになる」です.

全体最適については, 視座が上がってまわりのことがよく見えるようになると「チーム/グループ/会社全体でうまくやろうと思うと, 自分の裁量の範囲外の課題がボトルネックになっているが, 直接手を下せなくて悩ましい」といった声が出てきます. 僕の見解は「裁量を持っている人に言うだけは言って, ただ課題を確実に解決してもらえることは期待するな」です. 裁量の外のことを気にしてすべて背負い込んでしまうと壊れるのでやめましょう. まわりが見えていること自体はよいと思います.

おわりに

実は, この記事自体がテックリードの再生産性を上げるための取り組みの1つです. 「テックリード養成講座」のカリキュラムを作って何回かやってみたものの, 現状は僕自身が講師役を務めていて, テックリードを再生産するプロセスがスケールしていません. どういう考えでこの取り組みをやっているか言語化して, 講師役を増やしていきたいと思っています. 最終的には養成講座のやり方が僕の手を離れたところで改善されていくといいですね!

*1:エンジニアリングマネジメント4領域のうちすべてではないがいくつかを担っているEM

*2:もちろん学びやすくするための取り組みはいろいろ考えられますが今回の主題ではないので省略

*3:たとえば, 経営理論で言うならIO型やチェンバレン型ではもはや対処できず, シュンペータ型の経営理論(ダイナミック・ケイパビリティ等)で考えなければならないといった話も(僕から見れば)アジャイルと全く同じことを言っていて, もはや現代では(少なくともIT業界では)避けては通れません. 日本CTO協会の見解によれば企業がDXを進めるのも同じ課題意識です.

*4:4人以上だと30分では足りないことが経験的にわかってきました