仕事術

テックリードが担うメンタリングの距離感を整理しました。答えを渡す前に問い返す、レビューを教材にする、最初の30日で目標を1つ決める。一次情報つきで、教えすぎと放置の間を埋めます。

テックリードの見積もりは精度勝負ではなく不確実性を扱う技術です。マコネルの定義と不確実性のコーンを踏まえ、点ではなく幅で答える伝え方と、期限が動かないときの選択肢の示し方を整理しました。

技術的負債を「毎回余計に払っている利息」として観測値で示し、次の機能とセットで返済を提案する組み立てを、Martin Fowler の四象限と元本返済の考え方を手がかりに整理しました。

Design Docは仕様書ではなく設計の合意を取る道具です。Googleの公開解説をもとに、5つの節の書き分け・分量の目安・4段階のライフサイクル・書かないほうがよい場合を整理しました。

コードレビューが形骸化・滞留するのは運用ルールが無いから。Googleのコードレビューガイドを一次情報に、目的・判断基準・応答時間・変更の大きさという4つの約束をテックリードがどう決めるか整理しました。

テックリードとプロダクトマネージャーの役割はどこで線を引くのか。PMは「何を」、テックリードは「どう」という原則と、見積もり・スコープ削り・技術的負債という三つの場面での分担を、公開資料をもとに整理しました。

テックリードに着任した最初の90日を、STARSでの状況の見立て・30日は聞く・60日で小さく決める・90日で仕組みに寄せる、という順番で整理しました。落とし穴も3つ添えています。

Staffエンジニアとテックリードの関係を、等級と役割という二層構造で整理しました。StaffEng が示す4つの原型のうちテックリードがどの位置にあるのか、求人票の読み方まで一次情報をもとに解説します。