1on1 と聞いて浮かぶのは、上司と評価やキャリアを話す時間かもしれません。
ところが、テックリードとエンジニアリングマネージャー（EM＝メンバーの評価や育成に責任を持つ管理職）が別々に置かれたチームでは、同じメンバーの予定に 1on1 が二つ並ぶこともあります。
「EM の 1on1 がもうあるのに、テックリードまで同じ枠を持つ意味はあるのか」と迷ったことはありませんか？
テックリードと EM の役割の違いそのものは、以前の記事で整理しました。
私自身もテックリードを目指して学んでいる途中なので、足場にするのは先人が公開している一次情報です。
先に結論を書くと、テックリードの 1on1 は「技術の詰まり」と「判断の文脈」に絞った場として設計するのがよさそうでした。
二つの 1on1 は「何を育てるか」で分ける
まずは、どこに線を引くかという基準から考えます。
手がかりになるのが、『Talking with Tech Leads』の著者パトリック・クア（Patrick Kua）氏のThe Definition of a Tech Leadという記事です。
同氏は、EM が「人とチームの成長」に焦点を当てるのに対し、テックリードはメンバーとシステムの「技術的な成長」に焦点を当てる、と整理しています。
同じ記事には、同氏が駆け出しの頃にいた、テックリードと人の育成を担うチームリードが並ぶチームの話も出てきます。
そのチームで 1on1 を開いていたのはチームリードの側で、中身はフィードバックとキャリアの話でした。
テックリードのほうは、複数の開発者にまたがる技術の話題を受け持っていたそうです。
この分け方を 1on1 に当てはめると、評価・フィードバック・キャリアは EM の 1on1、設計の迷いや作業の詰まりはテックリードの 1on1、という線が引けます。
評価を持たないテックリードになら、「実はこの二日、ここで止まっている」という打ち明け話も早めに口にしやすいでしょう。
評価の場と、詰まりを話す場を分けておくこと自体に価値があると考えると、二つ目の 1on1 を持つ理由が見えてきます。
拾うのは「言われない詰まり」と「伝わっていない理由」
テックリードの 1on1 で拾いたいものは、大きく二つあります。
一つ目が、朝会やプルリクエストの場には出てこない詰まりです。
『Software Engineering at Google』の第 5 章How to Lead a Teamには、「障害物を取り除く」という節が置かれています。
同章は、チームの方針は固まっているのに技術的、あるいは組織的な障害物で止まってしまう場面があるとし、そこへ手を貸すのはよくあるリーダーの技術だと書いています。
例の一つは、社内の法務部門とのやり取りで数週間も止まっていたチームでした。
手詰まりの末に持ち込まれたマネージャーは、話すべき相手を知っていたおかげで 2 時間もかからずに片づけたそうです。
同章の結論は、正しい答えより、正しい相手を知っていることのほうが価値を持つ場面が多いというものでした。
テックリードが 1on1 で担うのも、詰まりを全部自分で解くことではなく、早めに拾って人や情報へつなぐことなのでしょう。
二つ目が、判断の文脈です。
Netflix が公開しているカルチャーメモは、マネージャーに「context not control（統制ではなく文脈を）」を求めています。
すべてを自分で制御する代わりに、良い判断に必要な文脈と明確さをチームに渡すという考え方です。
設計レビューで決まったことは、結論だけが先に広まり、理由があとに取り残されがちです。
理由を知らないメンバーは、前提が変わったときに自分で判断を更新できません。
1on1 で「最近決まったことで、理由が腑に落ちていないものはある？」と聞くだけで、結論だけが先に広まった決定に、あとから理由を届け直せるのです。
場の設計は「議題の持ち主」と「頻度」から決める
扱う中身が決まったら、次は場の形です。
参考になるのが、GitLab が公開しているハンドブックの1-1 のページです。
同ページは、インテルを率いたアンディ・グローブ氏の『High Output Management』を引いて、1on1 はメンバーの側の会議であり、議題と空気を決めるのもメンバーだと書いています。
議題は双方が足してよいものの、マネージャーが半分以上を書いているなら何かがおかしい兆し、という目安も添えられています。
話す量も、マネージャーが 2 割・メンバーが 8 割を目指すよう勧めていました。
頻度については、同じくグローブ氏の「その仕事への習熟度で決まる」という答えが引かれています。
目の前の仕事に慣れているメンバーほど、関わり方はゆるくてよいという意味です。
テックリードの 1on1 に置き換えるなら、触ったことのない領域に入ったメンバーとは間隔を詰め、慣れた領域の人とは広げるという調整になるでしょう。
初回には、場の使い方そのものを握っておくとよさそうです。
ララ・ホーガン氏が公開している「Questions for our first 1:1」には、「どんな 1on1 だといちばん役に立つか」という問いが入っています。
この問いに添えて、評価やキャリアの話は EM の 1on1 へ持っていってほしいと最初に伝えておけば、二つの場が混ざりにくくなると思います。
締めくくりの一問は、先の Google の章が勧める「何か必要なものはある？」で十分でしょう。
毎回この問いで終えると、メンバーのほうから必要なもののリストを持ってくるようになることもあるそうです。
つまずきやすい落とし穴
型を決めても、崩れやすいところは残ります。
進捗確認の場になる
テックリードは進捗が気になる立場なので、議題が「あのチケット、どう？」で埋まりがちです。
GitLab の目安に照らせば、リード側の議題が半分を超えた時点で黄信号です。
進捗は朝会やチケットで見えるので、1on1 はそこに出てこない詰まりのために空けておくとよいでしょう。
1on1 の中で決めてしまう
一対一で設計の相談を受けると、その場で結論を出したくなります。
ただ、クア氏の整理でテックリードが受け持つのは、複数の開発者にまたがる技術の話題でした。
二人きりで決めると、その場にいなかったメンバーだけが理由を知らない状態を、自分の手で作ってしまいます。
1on1 で拾った論点は、チームの場か記録に戻してから決めるという線を引いておくと安全です。
答えをすぐ渡さずに問い返す距離感については、メンタリングを扱った記事でも触れました。
兼任だと技術の話に偏る
クア氏は、プロダクトマネージャーとテックリードだけのチームでは、テックリードが EM の責任も引き継ぐと書いています。
そのうえで同氏の経験では、たいてい技術の話が優先され、人やチームの話が後回しになるそうです。
先の Google の章に出てくる TLM（テックリード兼マネージャー）の一人は、1on1 を技術的な困りごとから始めて場をほぐし、そのあと仕事を楽しめているかへ話を移していたといいます。
兼任なら、一つの枠の中で、技術と人の話の順番を決めておくと偏りに気づきやすくなるはずです。
最後に
テックリードの 1on1 は、評価とキャリアを EM に任せ、技術の詰まりと判断の文脈に絞る場として組むと、二つの 1on1 が重なりません。
議題はメンバーが持ち、頻度はその仕事への慣れで決め、拾った論点はチームの場へ戻します。
どれも特別な道具は要らず、最初の回に場の使い方を言葉にするだけで始められる形です。
まずは「理由が腑に落ちていない決定はある？」という一問を手元に置くところから始めたいと思います。
以上です。
コメントを残す