テックリードを任されると、EM（エンジニアリングマネージャー）や部長といった上司から「技術のことは任せるよ」と言われることがあります。
けれど、技術選定は自分で決めてよいのか、リリース日をずらす判断は上に上げるべきなのかまでは、たいてい言葉になっていません。
新任テックリードの最初の90日を扱った記事でも、この線引きを後回しにすることを落とし穴の一つに挙げました。
私もテックリードを目指して学んでいる途中なので、足場にするのは書籍や公開されている資料です。
先に結論を書くと、任される範囲は判断の種類ごとに段階で握り、上げる線は「戻せるかどうか」で引くと、上司との食い違いを早めにつぶせます。
テックリードの権限は上司から借りている
線を引く前に、なぜ先にすり合わせが要るのかを確かめておきます。
手がかりになるのが、Staff エンジニアの役割をまとめたウィル・ラーソン（Will Larson）氏が、StaffEng で公開しているガイドです。
Staying aligned with authority（Will Larson・StaffEng）
同氏は、肩書きに伴う組織上の権限は、より大きな権限から貸し出されたものだと書いています。
与えられたものは取り上げられることもあり、権限を保てるかは、それを与えた人、多くの場合は直属の上司とどれだけそろっているかにかかる、という整理でした。
テックリードが技術の判断を下せるのも、上司がその範囲を任せているからにほかなりません。
範囲が言葉になっていなければ、自分がどこまで借りているのかを知らないまま決めることになります。
なお、評価や採用の責任がテックリードと EM のどちらにあるかという役割の境界は、別の記事で整理しました。
ここで扱うのは、その境界の内側で「どの判断を、どこまで任されるか」のほうです。
任される範囲は 7 つの段階で握る
「任せる」と「任せない」の二択で考えると、すり合わせはすぐに行き詰まります。
マネジメントの手法を公開している Management 3.0 のデリゲーション・ポーカーは、この間を7 つの段階に分けて示した道具です。
Delegation Poker & Delegation Board（Management 3.0）
同ページは、委譲は二択ではなく、独裁者と無政府主義者のあいだには多くの濃淡があると書いています。
7 つの段階を、上司が任せる側、テックリードが任される側として読み替えると、次のようになります。
- 伝える（Tell）: 上司が決めて伝える
- 売り込む（Sell）: 上司が決め、納得してもらえるよう説明する
- 相談する（Consult）: 上司が意見を聞いてから決める
- 合意する（Agree）: 二人で一緒に決める
- 助言する（Advise）: 上司は助言し、テックリードが決める
- 尋ねる（Inquire）: テックリードが決め、上司は後から聞く
- 任せる（Delegate）: テックリードに完全に任せる
同ページが勧めているのは、判断の種類を縦に、7 つの段階を横に並べた「デリゲーション・ボード」に、領域ごとの段階を書き込むことです。
テックリードと上司のあいだなら、例えば次のような項目が候補になるでしょう。
- チームで使うライブラリやツールの選定
- 設計方針とコードレビューの基準
- リリース日やスコープの変更
- 他チームとの取り決め（API の互換性など）
- 採用面接での技術評価
進め方は、同じ項目について上司とテックリードがそれぞれ段階を選び、同時に見せ合うというものです。
選んだ段階がずれた項目が、先に話し合っておくべき線になります。
上げる線は「戻せるかどうか」で引く
上げる線は、どの判断を上げるかと、いつ上げるかの二つに分けて考えます。
どの判断を上げるか
どれを高い段階に置き、どれを上司の側に残すかは、判断の重さで分けられます。
その基準に使えるのが、Amazon のジェフ・ベゾス氏が 2015 年の株主への手紙に書いた判断の二つの型です。
一つ目の Type 1 は、結果が重大で、元に戻せないか、ほぼ戻せない判断です。
同氏はこれを一方通行のドアにたとえ、時間をかけて慎重に、よく相談してから決めるべきだとしています。
二つ目の Type 2 は、変更でき、戻せる判断で、行き来できるドアにあたります。
判断の多くはこちらで、判断力のある個人や小さなグループがすばやく決められるし、そうすべきだと同氏は書いていました。
これをデリゲーション・ボードに重ねると、一つの目安が立てられます。
戻せる判断は 5〜7 の段階に置いてテックリードが決め、戻せない判断は 3〜4 に置いて上司を巻き込むという分け方です。
例えば、ライブラリの選定は後から差し替えられますが、外部に公開する API の仕様や顧客と約束する期日は、一度出すと簡単には戻せません。
戻せるかどうかの見方は、作るか買うかの判断を扱った記事でも「撤退の道」として取り上げました。
いつ上げるか
線を引いても、上げるのが遅れれば効き目は薄れます。
先のラーソン氏のガイドは「上司を驚かせてはいけない」と書き、上司を驚かせることほど早く信頼を壊すものはないと続けています。
驚かせてしまったときはインシデントとして扱って学び、繰り返さないよう努めることも勧めていました。
リスクは、結果になってから知らせるより、見えた時点で共有するほうが傷は浅く済みます。
上げる条件は、デリゲーション・ボードと一緒に先に書いておくと迷いません。
- 約束した期日やスコープに影響が出そうだと分かったとき
- 判断の影響がチームの外に広がりそうなとき
- 戻せない判断に当たったとき
上げるほどではない情報は、週に一度の短い共有で上司の手元に届けておきます。
ラーソン氏も、週次のメールや、その週の注力を共有するチャンネルのスレッドを例に挙げています。
線を引いたあとに崩れやすいところ
線を一度書いても、運用の中で崩れやすい場面が三つあります。
何でも上げてしまう
ベゾス氏は同じ手紙で、組織が大きくなると、重い Type 1 の決め方を多くの Type 2 の判断にまで使いがちになると書いています。
その結果として挙げられているのが、遅さ、考えの浅いリスク回避、不十分な実験、そして発明の減少でした。
テックリードが戻せる判断まで上げると、上司が詰まりどころになり、チームの速度そのものが落ちます。
反対に、Type 1 の判断を習慣的に Type 2 の軽さで決める組織は大きくなる前に消えていく、と同氏は脚注で添えています。
線を見直さない
デリゲーション・ポーカーのページは、委譲を一歩ずつ進めていくものとして描いています。
判断の領域と段階を定期的に見直し、判断に成長や成熟が見えたら段階を先へ進めるよう勧めていました。
着任直後に 3 に置いた項目も、上司との 1on1 で見直しながら 5 や 6 へ動かしていけます。
上司の優先順位とずれたまま走る
段階が高い項目ほど、上司の目が届かないところで判断が積み重なります。
ラーソン氏は、1on1 でほかに注力すべき領域がないか、自分の優先順位が上司の優先順位とそろっているかを尋ねるよう勧めています。
任された範囲の中で正しく決めていても、向かう先がずれていれば、借りている権限は細っていくでしょう。
最後に
上司との期待調整は、任される範囲を判断の種類ごとに段階で握り、戻せない判断とリスクだけを早めに上げる作業でした。
段階は二択ではなく 7 つあり、戻せるかどうかで置き場所が決まり、驚かせないために途中で共有します。
そして一度決めた線は、信頼が積み上がるにつれて動かしていくものです。
線がまだ言葉になっていないなら、判断の種類を五つほど書き出して、次の 1on1 に持っていくところから始められます。
以上です。
コメントを残す