Tech

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

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

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

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