エンジニア組織の健全性をどう評価するか

エンジニア組織の健全性は、コードの品質よりも組織の「構造」と「プロセス」に現れます。離職率・バス係数・デプロイ頻度といった定量指標と、採用基準や意思決定プロセスといった定性指標を組み合わせることで、投資判断・買収DDの場面でも精度の高い評価が可能です。

この記事では、エンジニア組織の健全性を 4つの評価軸 で体系化し、フェーズ別の判断基準とレッドフラグの見分け方を解説します。

組織の健全性とは何か

「組織が健全かどうか」は、定量指標と定性指標の2種類を重ねて評価します。

定量指標（現在の状態を映す）

離職率：エンジニアの年間離職率。スタートアップで15%超はやや高め、30%超は警戒水準です。
バス係数：「その人物が突然欠けたらプロジェクトが止まる人数」を示す指標。1に近いほど属人化リスクが高い。
デプロイ頻度：週あたりの本番リリース回数。チームの生産性と自動化成熟度を映します。
PRマージ時間：コードレビューのスピード。24時間以内が健全なチームの目安です。

定性指標（将来の変化を予測する）

採用基準の明文化度
オンボーディングの質と初期定着率
技術意思決定の透明性と合意形成プロセス
経営陣とエンジニアの相互理解の深さ

定量だけに頼ると「なぜその状態になったか」が見えず、定性だけでは「どのくらい深刻か」が測れません。2種類の指標を組み合わせることが評価の前提です。

4軸の評価フレームワーク

エンジニア組織の健全性は、次の4軸で評価します。

図1：エンジニア組織の健全性評価4軸

軸①：採用

採用のフェーズで組織の「未来の設計」が決まります。採用基準が明文化されていない組織は、担当者の感覚に依存するため、時期やメンバーによって採用品質がばらつきます。

確認すべきポイントは3つです。

技術面接の設計：コーディングテストの内容・評価基準が文書化されているか。「雰囲気で合否を決めている」組織はレッドフラグです。
採用ソースの多様性：リファラル（知人紹介）一辺倒ではないか。シリーズBを超えてもリファラル依存が高い場合、採用の再現性が低いおそれがあります。
90日定着率：入社3ヶ月以内の離職割合。この数値が高い場合は、オンボーディングまたはカルチャーフィットに問題があります。

軸②：定着

定着の観点では、「誰が残っているか」が「何人いるか」より重要です。特にシニアエンジニアの在籍年数と退職理由のパターンを重点的に確認します。

離職率の目安として、エンジニアの年間離職率はスタートアップで15〜20%が一般的な範囲です。20%を超えると組織的な問題がある可能性があり、30%超は危機的水準です（参考：米国Bureau of Labor Statistics「JOLTS」等の傾向値。日本の公式統計は限られます）。

バス係数 は特に重要です。「この人がいなくなったらサービスが落ちる」人物が1〜2名に集中している場合、PMI（ポスト・マージャー・インテグレーション）後のリスクが高まります。

軸③：スキル分布

スキル分布では、「現在できること」と「これからできること」の両方を評価します。

シニア/ジュニア比：シニアエンジニアが極端に少ない組織は技術的意思決定の質が担保されにくく、技術負債が蓄積しやすい傾向があります。
技術スタックの網羅性：サービスを支えるコア技術に対して複数人が対応できるかを確認します。1人しかわからないシステムは、投資後に発覚しがちな技術リスクの代表例です。
OJTとクロストレーニング：入社後の技術習得プロセスが設計されているかは、組織の将来的な拡張性に直結します。

軸④：意思決定

技術的な意思決定のプロセスが透明かどうかは、組織の成熟度を映す重要な指標です。

確認すべきポイントは ADR（アーキテクチャ決定記録）の有無 です。ADRとは、「なぜその技術選定や設計判断を行ったか」を文書で残したものです。ADRが整備されている組織は技術的な文脈を共有・引き継ぎできる体制が整っており、PMI後の統合コストが低くなる傾向があります。

デプロイ頻度とPRマージ時間は、意思決定の「スピードと質」の代理指標として活用できます。週1回以上デプロイできているチームは、意思決定の委譲が進んでいることが多いです。

レッドフラグとイエローフラグ

評価の結果、以下のパターンが見えた場合は注意が必要です。

レッドフラグ（即座に深堀りすべき）

バス係数が1〜2：特定の個人に技術的な知識が集中している。PMI後の離職リスクに直結します。
エンジニア離職率が年間30%超：報酬・マネジメント・カルチャーに構造的な問題がある可能性。
採用基準が完全に口頭・属人的：組織拡大フェーズで採用品質が保証できません。
デプロイ頻度が月1回以下：リリースサイクルが遅すぎると、PMI後の開発速度向上が難しい。

イエローフラグ（文脈で判断が必要）

シニアエンジニアがほぼいない：シード期なら許容範囲ですが、シリーズAを超えると改善が急務になります。
リファラル採用が70%以上：ネットワーク依存で将来の採用スケールに限界がある。ただし初期の組織凝集力は高い傾向があります。
PRマージ時間が72時間超：コードレビューの文化が薄いか、レビュアーが不足しています。

フェーズ別の健全性基準

スタートアップのフェーズによって、「何が健全か」の基準は変わります。

指標	シード（5人以下）	アーリー（5〜20人）	成長期（20人以上）
離職率	評価は参考程度	30%以内	20%以内
バス係数	1〜2でも許容	2以上を目指す	3以上が望ましい
採用基準	非公式でも可	部分的に文書化	完全文書化
デプロイ頻度	週1以上	週2〜3以上	毎日デプロイ可
ADRの存在	不要	あれば加点	必須に近い

シード期では採用基準が整っていなくても許容されますが、成長期でこれらの問題が残っている場合は、組織設計の根本的な課題として評価する必要があります。

ケーススタディ：健全 vs 不健全な組織

ソースコードを見ずに技術力を見抜く方法でも論じましたが、組織の健全性は表面的な情報だけでは判断できません。以下は4軸で評価した比較例です。

健全な組織の例

シリーズA調達後・エンジニア10名のSaaS企業。年間離職率12%・バス係数3以上・週2〜3回のデプロイを実施しています。採用面接は技術課題と価値観の2段構成で文書化されており、90日定着率90%。技術選定の際はADRを作成して全エンジニアがレビューする文化があります。

この組織の強みは「知識の分散」と「プロセスの明文化」です。キーマン離職のリスクは低く、PMI後の統合コストも小さいと予測できます。

不健全な組織の例

シリーズB調達後・エンジニア20名のスタートアップ。年間離職率35%・バス係数1（創業CTOのみが全インフラを把握）・デプロイは月2〜3回。採用はCTOのネットワーク頼りで基準は口頭のみ。ADRは存在せず、技術選定の理由を誰も説明できない状態です。

技術DDの全体像の観点から見ると、このケースはPMI後のリスクが高く、バリューアップ支援の優先課題として「CTO依存の解消」と「採用プロセスの整備」を設定すべきです。創業CTOが買収後も残留する場合でも知識の移転計画は必須であり、こうした組織評価から支援設計までを一貫して行うアプローチは投資家向けTiedProで説明しています。

まとめ

エンジニア組織の健全性を評価する際は、採用・定着・スキル分布・意思決定の4軸で定量・定性の両面から分析することが重要です。フェーズに応じた基準を適用し、レッドフラグとイエローフラグを区別することで、投資判断や買収後の統合計画の精度が高まります。