シンプルさの原則|コードと機能を減らすことが信頼性になる理由
Google SRE本の「Simplicity」の章とWorkbookをもとに、偶有的な複雑さを押し返す理由、使わないコードを消す理由、複雑さの測り方と単純化の落とし穴をまとめた学習ノートです。
SREGoogle SRE本の「Simplicity」の章とWorkbookをもとに、偶有的な複雑さを押し返す理由、使わないコードを消す理由、複雑さの測り方と単純化の落とし穴をまとめた学習ノートです。
Tech Leadチームトポロジーの4つのチームタイプと3つのインタラクションモードを、認知負荷とコンウェイの法則から整理。テックリードが担当領域を棚卸しして負荷を減らす提案につなげる手順と、取り入れるときの落とし穴も押さえます。
Tech LeadAIがコードの多くを書くと、テックリードの品質保証は「全部読む」から「確かめる仕組みと承認の線を設計する」へ移ります。DORAの調査とGitHub・Claude Codeの公式情報を根拠に要点を整理。
Tech Lead生産性を数字で出せと言われたとき、コミット数を出すと読み違えます。デリバリーを測るDORAの5指標と、生産性を5つの次元へ分解するSPACEの違い、重ね方、導入でつまずく3点を整理しました。
Tech Lead一括刷新が止まる理由と、機能単位で新システムを育てるストラングラーフィグパターンを整理しました。継ぎ目の見つけ方と、テックリードが先に決めておく3つの論点まで。
FDEFDEとプロダクトマネージャーはどちらも顧客の声から始まる職種ですが、行き先が違います。SVPGの4つのリスク分担とPalantirのFDE像を並べて、声を集約する側と個別解を作る側の線引きを整理しました。
Tech Lead非機能要件は機能一覧に出てこないのに作り直しの原因になります。ISO/IEC 25010の9特性で抜けを探し、IPA非機能要求グレード2018の6大項目とレベルで水準の言葉をそろえる進め方を整理しました。
Tech Lead「動いているコードは触るな」と言われたとき、テックリードはどう答えるか。今の動きをテストで固定し、小さく分けて、日々の作業に埋め込む3つの手当てを整理します。
Tech Leadテストピラミッドを一次情報から整理し、チームへ導入する手順に組み直しました。棚卸しから始めて比率の丸暗記を避ける進め方をまとめています。
FDEPalantir発のFDE(Forward Deployed Engineer)を、生成AIを提供する会社がなぜ採用するのか。「一つの顧客に、多くの機能を」という型と、コンサルタントとの違いを公開資料から整理しました。