エンジニアの転職を止める経済的介入の方法

• シニアエンジニアの離職問題は情報の流れではなく、経営陣のインセンティブ構造の問題であり、四半期業績に最適化された報酬体系が長期投資を要する人材維持と根本的に衝突している
• シニアエンジニアが1人離職した際の総コストは50万〜100万ドルに達し、採用費、欠員コスト、オンボーディング、暗黙知（tribal knowledge）の損失などが複数の予算に分散されて見えにくい
• 14か月前の警告を無視した決済処理会社がブラックフライデーに347万ドルの損失を被った事例では、本来の修正コストは8万ドルにすぎなかった
• 6つの構造的介入（離職コスト会計、インシデント追跡、経営陣オンコール、報酬への定着率反映、技術諮問委員会、ICトラックの同等報酬）が、インセンティブを再整列させる解決策として提示される
• こうした介入は、経営陣が定着率を経済的問題として認識し、構造的変化を受け入れる意思があるときにのみ有効であり、形式的な導入はむしろ逆効果を招く

---

情報が流れても行動が変わらない理由

"The constraint is not information flow. It is economics."

• この記事はエンジニア離職を扱う連載の第2回であり、第1回 なぜあなたの最高のエンジニアたちは他社で面接を受けているのかで扱った情報の非対称性の問題のその後を扱う
• 第1回ではシニアエンジニアがなぜ去るのかを説明しており、核心的な原因は、問題が存在しても経営陣に届かない構造にあった
• しかし本稿は、その前提をさらに一歩押し進める
  • 情報の流れを実際に改善したときに何が起こるのかを扱う
  • 結論は直感に反して、ほとんどの場合は何も変わらないという点である
• 組織は問題を認識するためにさまざまな仕組みを導入する
  • スキップレベル1:1ミーティングの導入
  • 匿名フィードバックチャネルの運用
  • 外部コンサルタントによるリテンション調査の実施
• その結果、エンジニアたちは非常に明確に問題を伝える
  • 技術的負債が士気を蝕んでいる
  • アーキテクチャの意思決定で専門性が無視されている
  • オンコール負担が持続可能でない水準にある
• 経営陣はそれを聞いてうなずく
  • 問題を認める
  • 優先順位を調整すると話す
• しかし四半期が変わると、意思決定は以前と同じように繰り返される
  • 同じやり方で四半期目標を達成する
  • そしてそのやり方とは、今しがた聞いた問題を再び無視することである
• この時点で記事は核心を明確にする
  • 問題は情報不足ではない
  • 問題は経済的構造、すなわちインセンティブ設計である

核心的な問題: 役員のインセンティブ構造

• VP of Engineeringが10月に直面した意思決定の計算の例
  • 四半期業績レビューまで3か月、エンジニアの株式ベスティングまでは6か月残っている
• あるシニアプラットフォームエンジニアが次のように要請する
  • 認証システムを6週間かけてリファクタリングしたいということ
  • 技術的負債が蓄積しており、構造が脆弱になっている
  • セキュリティ研究者2人がすでに危険信号を伝えている
• しかし現状は曖昧である
  • 実際の障害はなく、顧客からの苦情もなく、売上への影響もない
  • あるのは「今直さなければ危機になる」というエンジニアの警告だけである
• VPには2つの選択肢がある
  • 選択肢A: リファクタリングを承認
    • 6週間にわたり機能開発速度の低下を受け入れる
    • 四半期OKR未達の可能性が生じる
    • CEOに対し、「顧客には見えない技術作業」のためにロードマップが遅れた理由を説明しなければならない
    • すでに営業チームが約束した機能リリース日程が揺らぐリスク
    • 結果として年末ボーナスに直接悪影響が及ぶ可能性がある
    • この選択の報酬を受け取るのは12〜18か月後である: そのシニアエンジニアが「技術的判断が尊重される」ことを理由に組織に残ること
  • 選択肢B: 機能優先を決定
    • 技術的負債を「重要だ」と認めつつ「次の四半期」に先送りする
    • 予定されたロードマップをそのままリリースしてOKRを達成し、ボーナスを受け取る
    • シニアエンジニアは当面残る。ストックオプションがまだベスティングしていないからである
    • 認証システムが後で問題を起こしても、それは将来の四半期の問題である
    • エンジニアが6か月後に去っても採用で置き換え可能だと判断する
• この構造では選択肢Bが常に勝つ - 最終的に失敗するまでは
  • 製品リリース中に基幹システム障害が発生し、18か月の間にシニアエンジニア5人が離職し、CFOが「なぜ再採用コストに毎年140万ドルを費やしているのか」と問い始めるまで、Bが勝つ
• 根本的な不一致だからである
  • 役員報酬の構造は四半期単位の成果に最適化されている
  • しかし、エンジニアの定着と技術的負債の解消は長期投資を必要とする
  • 情報の流れの改善だけではこのギャップを埋められない
  • 解決策は経済構造そのものの再設計である

Why the Math Favors Dysfunction - 計算してみると機能不全になるのは当然

• 隠れたコストは目に見えない形で作用し、合理的な行為者に非合理的な行動を取らせる

• 年俸**$200,000クラスのシニアエンジニア1人が離職した場合、実際の総コストは$500,000〜$1,000,000以上**と計算される

  • 多くの経営陣はこの数字を聞くと誇張だと思うが、そうではない。計算方法は次のとおり

• 直接的な代替コスト: $85,000-$100,000

  • 採用手数料: 外部リクルーター手数料20〜25%で、20万ドルのエンジニアなら$40,000〜$50,000
    • 内部採用（求人掲示板、ソーシングツール、リクルーター給与）として自前で対応する場合は$15,000〜$20,000
  • サイニングボーナス: 競争の激しい市場では、シニア候補を確保するのに$20,000〜$40,000が必要
    • 特に現在の会社に持分を残したまま移る場合は必須
  • 引っ越し費用: 該当時に国内移動なら$10,000〜$30,000、海外ならさらに高い

• 欠員（Vacancy）コスト: $50,000-$100,000

  • シニアエンジニアの採用まで平均3〜6か月かかる
  • 欠員期間中もそのエンジニアの仕事は止まらず、2種類のコストが同時に発生する
    • 1つは業務再配分によるチーム生産性の低下で、もう1つは業務放棄による機会費用の発生
  • 業務再配分コスト $25,000-$40,000:
    • 退職したエンジニアの業務の約**60%**が残ったチームメンバーに分散される
    • これは業務リソースの自由な再配置ではなく、生産性低下につながる
    • すでに業務量が飽和しているエンジニアは、慣れていない領域のコードレビューを処理し、自分が開発していないシステムについての質問に答え、十分に理解していないサービスを保守しなければならない
    • エンジニア3人がそれぞれ20%の追加業務を吸収する場合、単に20%多く働くのではなく、コンテキストスイッチによって全体効率が下がる
    • 欠員期間中、エンジニア1人あたり10〜15%の生産性損失を招く
    • 業務再配分コストの計算
      • 業務を吸収するエンジニア数 × 生産性低下率 × 欠員期間（月） × (平均年俸 / 12)
      • 一般的なシナリオでは、エンジニア3人 × 12%の生産性低下 × 4か月 × ($180,000 / 12) = $21,600
      • 離職したエンジニアがインフラ・セキュリティ・プラットフォームのような専門性の高い領域を担当していた場合は、$30,000〜$40,000まで上昇
  • 業務放棄コスト $25,000-$60,000:
    • 残り40%は再配分されず、先送りまたは完全に放棄される
    • プラットフォーム改善、技術的負債の削減、アーキテクチャ進化、ドキュメント整備、メンタリングなど、機能リリースには直結しないが将来の危機を防ぐ仕事が静かにロードマップから外される
    • 業務放棄（Work Abandonment）の即時コストは、実施されなかった作業の給与換算価値で計算される
      • 離職したエンジニアの業務の**40%**が欠員期間中に実施されない
      • 計算式は40% × 4か月 × ($200,000 / 12) = $26,667
    • しかし本当のコストは即時では終わらない
      • 先送りされた作業は、その後の四半期にわたって累積コストを生み出す
      • たとえば
        • シニアインフラエンジニアが計画していたデータベース最適化が延期されると
          • クエリ性能が徐々に低下し
          • 最終的には当初の作業範囲をはるかに超える緊急対応が必要になる
        • そのエンジニアが担当していたアーキテクチャレビューが止まると
          • 高コストなミスを事前に防げる専門性が失われた状態で
          • 技術的意思決定が進められる
    • 測定可能な業務放棄コストは
      • 「本来やるべきだったのに、やらなかった作業」の価値
      • 保守的な計算式は次のとおり
        • (放棄された業務割合 × 年俸 / 12) × 欠員月数
        • (40% × $200,000 / 12) × 4か月 = $26,667
    • 現実的な業務放棄コストの範囲は**$25,000〜$60,000**
      • 放棄された作業が予防的なものか、機能中心のものかの比率によって変わる
  • 総欠員コスト（Combined Vacancy Cost）: $50,000〜$100,000
    • 業務再配分コスト**$25,000〜$40,000** + 業務放棄コスト**$25,000〜$60,000**の2項目を合算した結果
    • これは4か月間ポジションが空いた状態で発生する直接的かつ測定可能な影響だけを反映した数値
  • 計算自体は保守的に行われている

• オンボーディングと適応コスト: $100,000-$125,000

  • 新しいシニアエンジニアの生産性: 1か月目は約25%、2〜3か月目は50%、4〜5か月目は75%、6か月目にフル生産性へ到達
    • 1か月目: 生産性75%損失 = ($200,000 / 12か月) × 0.75 = $12,500
    • 2〜3か月目: 生産性50%損失 = ($200,000 / 12か月) × 0.50 × 2 = $16,667
    • 4〜5か月目: 生産性25%損失 = ($200,000 / 12か月) × 0.25 × 2 = $8,333
    • 最初の6か月の生産性ギャップ合計: $37,500
  • オンボーディング人員コスト: 新しいシニアエンジニアは最初の1か月に週10〜15時間、2〜3か月目に週5〜8時間、他のエンジニアの時間を消費する
    • 1か月目: 週12時間 × 4週 × 時給$90 = $4,320
    • 2〜3か月目: 週6時間 × 8週 × 時給$90 = $4,320
    • 時給$90基準のオンボーディング人員コスト: $8,640
  • つまり最初の6か月で**$46,140**の損失が発生する
  • ただし、多くのシニアエンジニアが前任者レベルのドメイン専門性に到達するまで約1年かかるため、$92,000-$125,000が見込まれる

• 組織知（Tribal Knowledge）の損失: $100,000-$300,000

  • 最も定量化しにくいが、その後の四半期にミスという形で現れる
  • 離職したエンジニアが知っていたこと:
    • コードベースのどの部分が脆弱で、慎重な変更が必要か
    • どの顧客が特別な要件を持っており、その理由は何か
    • どのアーキテクチャ上の判断が意図的なトレードオフで、どれが技術的負債なのか
    • 10,000行あるサービスの中で、本当に重要な3行のコード
    • あるデータベースクエリが非効率に見えてもそのように書かれた理由（3年前に見つかった特定条件で「明らかな」最適化がデータ破損を引き起こした）
  • 文脈不足によるミス: 新しいエンジニアが「遅い」クエリを最適化した結果、会社の上位2顧客の中核ワークフローが停止
    • 問題特定に2日（$4,615）、適切な修正実装に1週間（$7,692）、顧客関係の修復
    • 単一インシデントのコストは約$12,000〜$15,000で、離職したシニアエンジニア1人あたり初年度に3〜5回発生
  • 意思決定の遅延: 離職したエンジニアなら30秒で答えた質問に、今では3時間のコード考古学、Slack履歴検索、「なぜこうしたか知っている人いる？」という会話が必要
    • 週2回、6か月続いた場合: $14,040
  • 延期または放棄されたプロジェクト: 離職したエンジニアだけが認証システムを十分に理解しており、SSO統合を安全に実装できた
    • そのプロジェクトは6〜9か月遅延し、SSOが50万ドル規模の企業契約に必要だった場合、その遅延コストは測定可能
  • この種の内部知識損失に対する保守的な推定値: 退職後12か月で**$100,000〜$300,000**

• エンジニア離職1件あたりの総コスト

  • 直接的な代替: $85,000-$100,000
  • 欠員コスト: $50,000-$100,000
  • 適応とオンボーディング: $92,000-$125,000
  • 内部知識の損失: $100,000-$300,000
  • 保守的な合計: $327,000-$625,000
  • プロジェクト遅延と機会費用を含む現実的な合計: $500,000-$1,000,000

• これらのコストは 予算全体に分散され、ノイズに埋もれてしまう: 採用費はHR予算に計上され、生産性の損失は追跡されず、社内知識の蒸発は四半期報告に表示されない

  • 技術的負債の先送りや機能優先の意思決定は 即時かつ可視的な成果 を生み出す: 営業チームのデモ、マーケティングのリリース発表、CEOの取締役会報告など
  • 経済学者が「ゆでガエル」問題と呼ぶ現象である:
    • 個々の従業員の退職は対処可能に見え、技術作業の延期は合理的に見え、四半期ごとの折衷案も個別には正当に見える
    • パターンが明白になったとき（年間シニアエンジニア離職率18%、累積した技術的負債、連鎖的なシステム障害）、組織は すでに機能不全を正常なもの として受け入れてしまっている

回復（Recovery）はどのようなものか

• ブラックフライデーの惨事の14か月前、中堅決済処理企業のシニアプラットフォームエンジニアが具体的な懸念を提起
  • 「トランザクション処理システムが想定されるホリデー期のトラフィックに耐えられません」
  • データベースのシャーディングとキュー最適化が必要だという詳細な提案を提出: エンジニアリング工数6週間、インフラ費用$80,000と試算
• VP of Productによって優先順位を下げられる:
  • 他の2つの機能リリースのほうが重要だと判断された
  • 四半期レビューでは「潜在的な問題を事前に把握する能力」は称賛されたが、アーキテクチャ提案書はJiraに放置された
• そのエンジニアは4か月後に15%の昇給を得て競合へ転職し、代替人材の採用には3か月の探索と$47,000の採用コストを要し、戦力化までさらに5か月かかった
• その間にシニアエンジニアがさらに2人離職: 1人は技術的負債への失望、もう1人は社内には存在しなかったPrincipal Engineer職を社外で受け入れた
• その最初の警告が再び議論されたのは9か月後のアーキテクチャレビュー
  • その時点では提案の文脈や解決方法に関する組織的記憶がすでに失われていた
  • ジュニアエンジニアに「代替案を調査する」任務が割り当てられた
• ブラックフライデー当日、午前9時47分にトランザクションが急増し、惨事が始まった
  • 午前10時23分からデータベースが書き込みリクエストを拒否
  • ボトルネックは14か月前に指摘されたまさにその箇所であり、この障害により**$2.5M規模のトランザクション処理が失敗**
  • 復旧には5時間を要した
    • 緊急インフラ増強費用**$180,000**に加え、恒久的なアーキテクチャ変更のためエンジニア3人が休日中ずっと残業した
  • 12月3日、CTO主導で新たな項目を含むポストモーテムが経営陣に提出された
    • 「Previously Raised Concerns」セクションが追加され、そのエンジニアの最初の警告、優先順位から外した判断、その後の人材流出がすべて記録された
    • CFOが総コストを試算した
  • エンジニア離職コスト（シニア3人）: 1人当たり**$235,000**の測定可能コストが発生
    • リクルーティング**$47,000** + サイニングボーナス**$30,000** + 欠員コスト**$83,000**（平均4か月）+ オンボーディング・立ち上がり**$75,000**
    • 合計**$705,000**
  • トライバルナレッジ喪失コスト: $2.2M
    • データベース構造、障害モード、既存の解決策に対する理解が組織から失われた
    • 問題を再発見し、解決策を再調査し、緊急事態の中で実装しなければならなかった
    • この知識ギャップにより、計画されたマイグレーションは危機対応へと変わってしまった
    • 調査コスト、誤った試行、緊急ベンダー投入、加盟店対応コストが積み上がった
  • 失敗したトランザクションのコスト:
    • 決済処理に失敗した金額**$2.5M**
    • 手数料率は2.9%だったため直接の売上損失は**$72,500**だが、契約上すべての取引を処理する義務がある
    • そのため、処理失敗によるSLA違反の違約金**$180,000および加盟店サポートと離反防止コスト$45,000**が発生
  • 緊急インフラ費用: $180,000
    • 緊急データベース拡張（追加の読み取りレプリカ、アップグレード済みインスタンス、Expeditedベンダーサポート費用）
    • ロードバランサー再設定とCDN最適化により、14か月前に想定されていたトラフィックを処理可能にした
  • 復旧および事後対応コスト: $87,000
    • シニアエンジニア3人が休日の週末に72時間、2.5倍の残業率で勤務: $51,923
    • より広いエンジニアリングチームによる2週間の後続対応: $38,462
  • 事故総コスト: $3.47M
  • 当初提案されていた予防コスト: $80,000（シニアエンジニア1人の6週間分のエンジニアリング工数とインフラ費用を含む）
  • ポストモーテムの1ページ目には**$3.47M vs $80,000と記されており、この数字が会話の方向を変えた**
• CEOは取締役会からの質問に対応して定着率分析を指示
  • シニアエンジニアの離職率は年率34%（収益性のある企業の業界平均の2倍超）
  • 以前は経営陣のレビューなしに保管されていた退職面談から一貫したパターンが浮かび上がった
    • 有能なエンジニアは、技術的懸念が認識されても実行されないと離職していた
  • 18か月間で4つの改善策を実施:
    • CFOが四半期報告書で顧客獲得コストと並べて離職コストの追跡を開始 — 突然、平均離職コスト$235,000がマーケティング支出の意思決定のような文書に現れるようになった
    • すべての経営陣が四半期ごとのオンコールローテーションに参加 — データベース作業の優先順位を下げたVP of Productは最初の週に23ページのレポートを受け取ったが、そのうち19件は過去6か月で指摘されていた技術的負債に関するものだった
    • 報酬委員会が役員の変動報酬に人材定着要素を追加: シニアエンジニアを年間90%維持することがボーナス算定の**25%**を占める
    • ディレクターおよびVPレベルと報酬をそろえたStaffおよびPrincipal ICトラックを新設
• 18か月後、この決済企業のシニアエンジニア離職率は年率9%まで低下
• さらに重要だったのは、アーキテクチャレビューのプロセスが変わったこと:
  • 技術的負債の提案には今や試算された障害コストが含まれる
  • 経営陣は日常的に「これを先送りすると、エンジニア離職のリスクはどれくらいですか？」と尋ねるようになった
• もともとデータベースへの懸念を提起していたプラットフォームエンジニアがPrincipal Engineerとして復帰
  • 退職時と比べて年収40%増 — とくにインフラ拡張のリードとして採用された
• そのエンジニアの復帰は、数字が示した変化とともに、組織の経済的計算が実際に変わったことを象徴していた

実際に効果があった6つの介入（Intervention）

• インセンティブを再整列する構造的介入であり、情報収集や共感活動ではなく経済的な再設計

• 影響力の階層構造

  • 6つの介入は負担が大きく見えるかもしれないが、実装難易度と価値創出までの時間は同じではないため、順序が重要
  • 最も早く成果を出す方法: 組織の最小限の合意だけで済む介入
    • 離職コスト会計（#1）: CFOの承認と財務アナリストの時間だけが必要
    • 無視された警告によるインシデント追跡（#2）: SREプロセスの変更だけでよい。予算や組織再編は不要で、体系的な事後分析の文書化があればよい
    • どちらも30日以内に開始でき、より困難な戦いに向けた定量的な証拠を提供する
  • 中期的な介入: 文化の変化は必要だが、報酬制度の再編は不要
    • 経営陣のオンコール・ローテーション（#3）: ある経営陣メンバーがインフラ改善作業の先送りの結果を直接体験したときに成功し、その方針は自然に定着する
    • 権限を持つ技術諮問委員会（#5）: 経営陣が自分たちの判断が覆される可能性を本当に受け入れたときに効果を発揮し、小規模な試験運用方式は数四半期以内に失敗する
    • 実装スケジュールは3〜6か月: 単なる方針変更ではなく、信頼構築が必要だから
  • 構造的介入: 取締役会または報酬委員会の承認が必要で、6〜12か月を要するが、最も深い変化をもたらす
    • 報酬制度に人材維持指標を組み込む（#4）: 経営陣のボーナスがシニアエンジニアの維持に連動すると、技術的負債が一夜にして戦略的に重要になる
    • ICトラックの同等性確保（#6）: Staff Engineerがチーム管理なしで部門長級の報酬を得られれば、技術的専門性の維持が構造的に可能になる
  • 最小実行可能介入: 異なる階層の2要素を組み合わせる
    • 離職コスト会計（早い成果） + 報酬への維持指標の反映（構造的変化）
    • 前者がビジネスケースを構築し、後者が経営陣にとって行動を合理的にする
  • 危機的状況の企業: 早い成果をすぐに実行しつつ、構造的変化を並行して設計
  • 早期警戒サインが出ている企業: 測定（コスト会計、インシデント追跡）から始め、その結果データでより深い介入を正当化

• 1. 離職コスト会計（Cost-of-Attrition Accounting）

  • 見えないものを見えるようにする: すべてのシニアエンジニア離職の総コストを計算
    • 平均採用コスト $35,000
    • 完全な生産性に達するまで約6か月（シニアエンジニア年収の50%）
    • 知識喪失によるプロジェクト遅延
    • そのエンジニアだけが理解していたアーキテクチャ上の意思決定に伴う機会費用
  • この数値を月次で追跡し、CACや売上指標と同じ役員ダッシュボードに含める
  • ある金融サービス企業では四半期ごとの離職コストを追跡した結果
    • Q1: シニア2人が離職、$400,000
    • Q3: 年間予想コスト $900,000
    • CFOがこれを年間エンジニアリング予算 $3Mと並べて提示すると
    • CEOの質問は「なぜ辞めたのか」から**「防ぐにはいくら必要か」**へと変わった
    • 結果として技術的負債の解消と報酬調整に**$400,000を投資すると
      シニア離職率は43%減少し、投資額は2四半期で全額回収**された

• 2. 無視された警告によって発生したインシデントを追跡する

  • 事後分析テンプレートを修正し、必須セクション「事前警告（Prior Warnings）」を追加
  • 担当者に、Jira、Slack、アーキテクチャレビューのノート、メールで、この障害モードに関する過去の警告を確認するよう求める
  • 文書化項目: 警告が提起された時点、提起者、提案された対策、優先度を下げた理由
  • インシデントコストの計算: ダウンタイムによる売上影響、カスタマーサポート負荷、復旧に要したエンジニア時間
  • あるヘルスケアテック企業はこの方式を導入した後
    • 6か月以内に本番インシデントの70%が事前に予測されていたことを発見
    • エンジニアは懸念を提起していたが、経営陣は機能開発に集中して問題解決の優先度を下げていた
    • 1年間の総コスト: 防げたはずのインシデントで180万ドルのコストが発生
    • 主要障害16件のうち14件で技術的警告が正しかったことを経営陣が確認すると、パターンの深刻さに気づいた
    • 予測が一貫して正確だと証明されると、行動が変わった

• 3. 経営陣オンコール・ローテーション

  • すべての役員（プロダクト、VP、ディレクターを含む）が四半期ごとに1週間ずつオンコールを担当
  • エスカレーション方針:
    • オンコールエンジニアが、そのアラートが以前に優先度を下げられた修正や先送りされた技術作業に関連すると判断した場合
    • 時間帯や曜日に関係なく、その判断を下した責任者に直接報告する
  • これはどんなダッシュボードよりも強力な体験学習をもたらす
  • 事例: あるVP of Productは、7か月前にエンジニアが「あると良い」修正としてフラグを立てていた同じデータベース接続プール問題で、5日間に17件の呼び出しを経験
    • その問題はP3として扱われ、VPは代わりに3つの機能リリースを優先していた
    • 午前3時の呼び出しが5回連続した後、P0に変更され、8日以内に修正
    • 後にそのVPは「エンジニアはアラート疲れを誇張していると思っていた。そうではなかった」と認めた

• 4. 役員報酬に人材リテンション指標を反映

  • 経営陣の変動報酬の25%をシニアエンジニア維持率に連動させるよう制度を再設計
  • 「シニア」の定義: 勤続2年以上、評価で期待を上回る、または中核システムを担当
  • 目標設定: シニアエンジニアの年間90%維持
    • 目標未達ならボーナスを比例的に減額
    • 目標超過ならボーナスは倍率をかけて支給
  • 事例: あるSeries BのSaaS企業が2021年にこの制度を導入
    • シニアエンジニア離職率は年28%
    • 経営陣の初期反発: 「誰かがより良いオファーを受けることを、こちらでコントロールはできない」と反対
    • CEOの返答: 「なら、私たちは給与以外で競争力がないことを認めることになる。改善するか、報酬への影響を受け入れるかだ」
    • 1年以内に離職率は11%に低下
    • 退職面談のパターンも変化: 退職するエンジニアは、機能不全による離職（無視された技術的懸念、成長機会の欠如、有害な文化）ではなく、機会による離職（より大きな企業でのシニア昇進、スタートアップ創業、転居）を挙げるようになった
    • 経営陣が今や人材維持への当事者意識を持つようになり、ボーナス目標の達成は最も簡単な部分になってしまった

• 5. 実質的な権限を持つ技術諮問委員会（TAB）

  • エンジニアリング組織が選出した（経営陣任命ではない）シニアエンジニア5人で委員会を構成
  • Cレベルとの四半期ミーティング
  • 1つの権限: 四半期に1件、経営判断を拒否できる
  • 要件: 拒否する場合は、技術的正当性、想定コスト、リスク分析を含む書面による代替案の提出が必須
    • 経営陣はCEO承認と文書化された理由がある場合にのみ拒否権を無効化できる
  • 事例: あるブロックチェーン・インフラ企業が2020年初頭にTABを設置
    • 2年間で拒否権を2回行使
    • 1回目の拒否: 独自のコンセンサスフレームワーク構築の決定を止め、代わりに既存のオープンソース・プロトコル拡張を提案。推定で18か月の開発時間を節約
    • 2回目の拒否: 包括的なロールバックテストなしでのデータベース移行リリースを阻止。事後の実装分析では、TABが200万ドル規模のデータ破損インシデントを防いだと推定
    • 本当の影響はもっと微妙だった: 経営陣が技術判断を最終化する前に**「TABはこれを承認するか？」**と尋ね始めた
    • 拒否の脅威によって、TABに届く前の提案の質が変化した
    • エンジニアは、技術的判断がついに経営判断において重要になったと報告

• 6. 報酬上の同等性を備えたIC（個人貢献）トラック

• ICのキャリア発展経路を明確に設定: Staff Engineer、Principal Engineer、Distinguished Engineer

  • 報酬バンドはそれぞれDirector、VP、SVP水準に一致している必要がある

• 昇進基準: チーム規模やレポートラインではなく、技術的影響力、アーキテクチャ主導力、他のエンジニアの生産性を高める波及効果

• 事例: あるフィンテック企業で、6か月以内にStaff級エンジニア3人が離職

• 退職インタビューで同じパターンが見られた: "マネージャーにならない限りL7の報酬には到達できない。管理はしたくなく、開発者でいたい"

  • 会社は報酬の同等性があるICトラックを導入
  • 1年以内に: 以前面接を受けていたエンジニア2人がPrincipalに昇進、同様のキャリアパスがない競合他社からシニアIC 3人を採用、シニア技術人材の離職が62%減少
  • さらに重要なのは、会社に残ったエンジニアたちが推定300万ドルに相当するアーキテクチャ上のミスを防いだこと
    • これは、ジュニアまたはミドルレベルのエンジニアが専門性や権限の不足により異議を唱えられなかった意思決定だった

実行経路（Implementation Paths）

• 実行スケジュールは組織が置かれた深刻度によって異なる

• 危機的状況の企業（シニア離職率 >20%、最近重大障害が発生）

  • 1〜2週目: 実際の12か月間の離職コストを計算（採用費、生産性が立ち上がるまでの適応時間、プロジェクト遅延、不足する知識の損失を含む）、退職面談のパターンを分析し、本番事故を以前に無視された警告に対応付ける
  • 3〜4週目: CFOとCEOに発見事項を提示し、パターンを示す（技術的懸念の提起 → 優先順位の引き下げ → エンジニア離脱 → 事故またはコスト）、総損失を定量化し、即時介入を提案する
  • 5〜8週目: 経営陣オンコールローテーションを開始（最も速い文化転換）、離職コストの追跡を開始（継続的変化のケースを構築）、エンジニア3人でTABパイロットを作成し、経営陣ダッシュボードで月次の離職コスト追跡を開始する
  • 9〜12週目: 取締役会に報酬構造の変更を提示し、経営陣ボーナスを定着率に連動させ、ICキャリアトラックを正式に発表し、何がなぜ変わったのかを透明に伝える

• 早期警告兆候がある企業（離職率12〜18%、エンジニアが1:1で懸念を言及）

  • 1〜2か月目: 離職コストの追跡と経済的ケースの構築を開始し、定着リスクと何が残留につながるかについてエンジニア調査を行い、最も頻繁に言及された3つの懸念を特定する
  • 3〜4か月目: リソース担当役員と経営陣オンコールローテーションのパイロット、TABパイロットを開始し、両方を技術的負債と組織的摩擦の可視化に用い、先送りされた作業コストを文書化する
  • 5〜6か月目: 恒久的な報酬構造の変更を実施し、TABの権限を正式化し、ICキャリアトラックの基準と報酬バンドを公開し、シニアエンジニアの定着を明示的な経営目標に設定する

これが効果を持たない場合

• これらの介入は3つのシナリオで予測どおりに失敗し、これを認めなければ時間を無駄にするだけになる

• 1. そもそも離職を前提に設計されたビジネスモデル

  • コンサルティング会社や契約業者は年間20〜40%の離職率を想定している
  • ビジネスモデルが人材の代替コストを価格に織り込み、請求レートは組織内の専門知識が限定的であることを前提に設定されている
  • プロダクト企業向けに設計された人材定着戦略は、クライアントローテーションが自然な離職を誘発し、パートナートラックが意図的にアップ・アンド・アウト圧力を生む環境では意味がない
  • 同様に、プロダクト市場適合前の初期スタートアップでは、エンジニア離脱が定着失敗ではなく必要なピボットを示す場合がある
    • 会社が6か月ごとに根本的に方向転換しているなら、低い定着率は体系的機能不全ではなく適切な人材再配置を意味する

• 2. 実行しているふりだけの場合（Implementation Theater）

  • 形だけの介入は無介入よりも悪い結果を生む
  • 実際の拒否権を持たないTABは、エンジニアの懸念を拡散させる排出口になる
    • 体系的に無視される提案に時間を投じると、怒りだけが強まる
  • 根本原因の解決と結びつかない経営陣のオンコールローテーションは、責任の伴わない見せかけの共感を生む
    • 自分が優先順位を付けて解決できない問題で呼び出されるVPは、エンジニアが頻繁に不満を述べていることだけを学ぶ
  • 計算はされても経営陣ダッシュボードや報酬議論に一切登場しない離職コスト会計は、理論上の議論のまま終わる
  • 中途半端に実施された介入は、リーダーシップが構造的変化への本気の意思なしに関心を示すふりをしているだけだと示す

• 3. 文化的前提条件の欠如

  • これらの介入には、多くの組織に欠けている文化的前提条件が必要である。すなわち、リーダーシップが評判管理ではなく本当の行動変化を望んでいなければならない
  • 経営陣がエンジニア定着を経済問題ではなくPR問題と見なすなら、最も目立つ介入（諮問委員会、リスニングツアー）だけを実施しつつ、コストのかかるもの（報酬構造の再編、実際の拒否権）は回避する
  • 診断テスト: 経営陣の変動報酬の25%をシニアエンジニア定着に連動させることを提案してみること
    • リーダーシップが即座に「うちでは無理な理由」を挙げるなら、答えは見つかったということだ
      • 彼らは個人的コストのない解決策を求めているのである
  • エンジニアに拒否権を与え、経営陣給与を定着に連動させ、四半期財務レビューに離職コストを反映する準備ができていない会社は、構造的変化の準備ができていない
  • 懸念を認めて「追加調査」を勧めるだけで、シニアエンジニアが離脱し続ける間にほこりをかぶるコンサルティング報告書に満足している
  • 介入は、リーダーシップが年間140万ドルの離職コストは、それを防ぐために必要な措置より大きいという事実を認識したときに機能する
    • その認識がなければ、どれほど多くの諮問委員会があっても経済的整合性の代わりにはならない

新しい経済計算

• 著者が率いたブロックチェーンインフラ企業は、3年間で10人から187人のエンジニアへ拡大しながらも
  • 年間シニアエンジニア離職率を**平均6%**に維持したが、これは超高速成長企業で一般的な35〜40%の離職率を大きく下回る数値だった
• 成果の原因は福利厚生や文化的施策ではなく、インセンティブ構造の再設計にあった
  • 中間管理職は、すべてが管理下にあるように見せることではなく、技術リスクの早期可視化で報われた
  • 事後分析では以前の警告の文書化が求められ、無視された警告は優先順位を下げた担当者の人事評価対象になった
  • 技術リーダーシップはアーキテクチャ決定に対する拒否権を保持していた。私たちは2回行使したが、拒否権を行使し得るという可能性だけで、提案全体の品質が向上した
  • 創業時からICキャリアトラックが存在し、最もシニアな非管理職は大半のディレクターより高い報酬を受け取っていた
• システムコスト: 報酬調整、ガバナンスのオーバーヘッド、一部機能を遅らせる技術的負債の優先付けに年間約**$400,000**
• 削減額:
  • 回避された離職コスト210万ドル（業界標準の35%離職率をシニアエンジニア人数に適用）
  • さらに、シニアエンジニアが停止権限を持っていたため、数百万ドル規模の事故を招かなかったアーキテクチャ決定からの、測定不能だが相当な節減効果があった

不都合な真実

• ほとんどの会社は、否応なく強制される状況が訪れるまでこのような介入を実施しない
• その強制要因はたいてい壊滅的である。数百万ドルのコストがかかる本番事故、基幹チームを麻痺させる大規模離職、あるいは競合が、あなたが拒んだもの、すなわち技術的判断への敬意を提示して、あなたの中核エンジニア陣の半分を奪っていく場合である
• その頃には、予防ではなく被害復旧に追われるようになる
  • 回復には多大なコストがかかる。次の危機を防げる最高のエンジニアたちがすでに去っているからだ
  • その後任者たちは有能ではあっても組織知識が不足しており、どんな警告を出すべきか分からず、破滅ループを加速させる
• 問題は、これらの介入が効果を持つかどうかではない。証拠は明白である
  • 経営陣のインセンティブを従業員定着に合わせて調整し、エンジニアに意味のある権限を与え、離職を経済問題として扱う会社は、従業員定着率、事故発生率、長期的な技術健全性の面で一貫して優れている
• 熟練エンジニアが離脱しており、一般的な解決策が効かないなら、問題はコミュニケーションではなく経済面にあるのかもしれない

[duddnd649]

経営陣はこれを聞いてうなずき、
問題を認め、
優先順位を調整すると言う
> ここから先で詰まる

[bichi]

不都合な真実 +

実際に決断を下すべき経営陣は、この文章を読んでも理解できない

[mstorm]

同意します。

[rrr6ttt]

ガチで

[jjw9512151]

解決策があるのが本当に貴重な文章ですね。ありがとうございます。

[ds2ilz]

モバイルで見ていますが、整列の問題なのか本文の途中に1行に1文字しか表示されないリストがいくつかあります。それだけでなく、少しでも深い階層に入ると行の長さが極端に短くなります。

[curioe]

修正しました。お知らせいただきありがとうございます。

[cysl0]

はい、iOS 26.1 x Safariでも同じ症状です

[bini59]

私もリファクタリングしたい

[ethanhur]

インセンティブを見せてくれれば、結果を見せよう - チャーリー・マンガー