エンジニアリング

心理的安全性は、厳しい指摘をなくすことではありません。Google の調査やコードレビューのガイドをもとに、率直な指摘と攻撃的な言葉を分けるものと、テックリードが先に決めておける議論の型をまとめました。

チームトポロジーの4つのチームタイプと3つのインタラクションモードを、認知負荷とコンウェイの法則から整理。テックリードが担当領域を棚卸しして負荷を減らす提案につなげる手順と、取り入れるときの落とし穴も押さえます。

一括刷新が止まる理由と、機能単位で新システムを育てるストラングラーフィグパターンを整理しました。継ぎ目の見つけ方と、テックリードが先に決めておく3つの論点まで。

内製かSaaS導入かの判断を、Martin Fowlerのユーティリティと戦略的の分け方と、機会費用の2軸で整理しました。買ったあとに業務を寄せる理由と、比較表より先に見るべき3点もまとめています。

全面書き直しと漸進的改善の分岐点を、Joel SpolskyとMartin Fowlerの主張から3つの問いに整理しました。構造を保つフィットネス関数と、判断で陥りやすい落とし穴もまとめています。

技術選定を機能比較の点数勝負にしないために。運用の重さ、新しい技術に使える「予算」、選ばなかった案の理由、チームの採用状況の地図という4つの視点を、一次情報に沿って整理しました。

「動いているコードは触るな」と言われたとき、テックリードはどう答えるか。今の動きをテストで固定し、小さく分けて、日々の作業に埋め込む3つの手当てを整理します。

ADR（Architecture Decision Record）は技術判断の理由を1枚に残す軽量な記録です。Nygardの5節テンプレート、書き換えずsupersedeする運用、対象の絞り方を整理しました。

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

テックリードの仕事を技術・人・プロセスの3つの軸に分解して整理しました。Pat Kua氏の定義とThoughtWorksの解説をもとに、決定と品質・評価単位の変化・仕組み化という中身を確認します。