ひとことで言うと#
開発組織が「正しいものを、正しく、速く」作れているかを多角的に測定し、ボトルネックを特定して改善するフレームワーク。個人の生産性ではなく、組織全体としてのアウトプットの有効性に焦点を当てる。
押さえておきたい用語#
- Engineering Effectiveness(エンジニアリング エフェクティブネス)
- 開発組織全体がビジネス価値を生み出す能力のこと。スピード・品質・開発者体験の総合指標で評価する。
- DORA Metrics
- デプロイ頻度・リードタイム・変更失敗率・MTTRの4指標。デリバリーパフォーマンスを測る業界標準である。
- SPACE Framework
- Satisfaction、Performance、Activity、Communication、Efficiencyの5次元で開発者の生産性を多角的に捉えるフレームワーク。
- Developer Friction(開発者フリクション)
- 開発者の作業を妨げる障壁や非効率を指す。ビルドの遅さ、ドキュメント不足、承認プロセスの重さなど。
- Engineering Enablement
- 開発者が本来の開発に集中できるようインフラ・ツール・プロセスを整備する活動。
エンジニアリング・エフェクティブネスの全体像#
こんな悩みに効く#
- エンジニアリングに投資しているが、ビジネス成果につながっているか見えない
- チーム間で生産性に大きな差があるが、原因がわからない
- DORA指標を導入したが、数字が改善しても現場の実感と合わない
基本の使い方#
- ツール: CIの高速化、開発環境の改善、モニタリングツール導入
- プロセス: レビューフローの簡素化、デプロイ手順の自動化
- 組織: チーム間の依存関係解消、プラットフォームチームの設立
具体例#
エンジニア80名のBtoB SaaS。DORA指標のリードタイム(コミットからデプロイまで)が平均14日と遅く、改善を試みていた。
3層の計測を導入して分析。
| 層 | 指標 | 値 | 問題? |
|---|---|---|---|
| アウトプット | リードタイム | 14日 | 遅い |
| プロセス | PRレビュー待ち時間 | 平均3.2日 | ボトルネック |
| プロセス | CI実行時間 | 8分 | OK |
| 体験 | 「レビューが遅い」フラストレーション | 82% | 高い |
原因はCIではなくレビュープロセスにあった。レビュアーの自動アサイン + 24時間SLAの導入で、PRレビュー待ちが 3.2日 → 0.8日、リードタイムが 14日 → 5日 に短縮。
エンジニア300名、20チーム体制のEC企業。チームごとのデプロイ頻度が週0.5回〜日3回と10倍以上の差があった。
チーム横断で3層指標を比較分析。生産性の低いチームには共通して「他チームへの依存がスプリントの30%以上」という特徴があった。
Team Topologyの考え方を導入し、チーム間依存を解消。共有サービスをプラットフォームチームに集約した結果、最低のチームのデプロイ頻度が 週0.5回 → 週3回 に改善。
エンジニア40名のスタートアップ。四半期の開発者サーベイでeNPS(推奨度)が +35 → +10 に急落。同時期のDORA指標は改善傾向だったため、数字だけ見ていたら見逃していた。
体験指標を深掘りすると、「会議が増えて集中できない」「技術負債の対応に時間が割けない」という不満が急増していた。組織拡大に伴うプロセスの重さが原因。
会議の棚卸し + 技術負債対応の工数を20%確保するポリシーを導入。次の四半期でeNPSは +10 → +28 に回復し、その間の離職はゼロだった。
やりがちな失敗パターン#
- アウトプット指標だけで判断する — DORA指標が改善しても、開発者が疲弊していたら持続しない。体験指標を必ず併用する
- 個人のパフォーマンス評価に使う — メトリクスを個人の評価に直結させると、指標のゲーミング(数字だけ良くする行動)が起きる。チーム単位で使う
- すべての指標を同時に改善しようとする — 四半期ごとに1〜2個のボトルネックに集中して改善する。全方位は力が分散して成果が出ない
- 計測の仕組みだけ作って放置する — ダッシュボードを作るだけでは何も変わらない。四半期レビューで指標をチームに共有し、具体的なアクションにつなげる
まとめ#
エンジニアリング・エフェクティブネスは 「アウトプット」 「プロセス」「体験」 の3層で開発組織の有効性を測定し、ボトルネックを特定して改善するフレームワーク。DORA指標だけでは見えない問題を体験指標で補い、指標間の相関分析で根本原因にアプローチする。四半期ごとのレビューサイクルで継続的に改善を回すことが重要。