LESSON 40分

ストーリー

佐
佐藤CTO
“エンジニアの生産性を測りたい”。経営陣からよく言われるリクエストだ

佐藤CTOが慎重に言葉を選びました。

佐
佐藤CTO
でも”コミット数”や”コード行数”で測ったら最悪の結果になる。間違ったメトリクスは、正しい行動を罰する。だからこそ、何を測り、何を測らないかを慎重に設計する必要がある
あなた
何を測るべきなんでしょうか？
あ
佐
佐藤CTO
チームのアウトカム（成果）を測り、個人のアウトプット（産出量）は測らない。これが鉄則だ

DORA メトリクス

4つのキーメトリクス

Google の DORA（DevOps Research and Assessment）チームが、数千の組織の調査から導き出した4つのメトリクスです。

メトリクス定義EliteHighMediumLow
デプロイ頻度本番環境へのデプロイ回数オンデマンド（1日複数回）週1〜月1月1〜半年1半年1未満
リードタイムコミットから本番デプロイまでの時間< 1時間1日〜1週間1週間〜1ヶ月1ヶ月〜半年
変更失敗率デプロイ後に障害やロールバックが発生する割合0-15%16-30%16-30%46-60%
復旧時間（MTTR）障害検知から復旧までの時間< 1時間< 1日1日〜1週間> 半年
dora_measurement:
  deploy_frequency:
    source: "CI/CDツールのデプロイログ"
    calculation: "成功したデプロイ数 / 計測期間"

  lead_time:
    source: "Git + CI/CDツール"
    calculation: "各PRの (デプロイ完了時刻 - 最初のコミット時刻) の中央値"

  change_failure_rate:
    source: "インシデント管理ツール + デプロイログ"
    calculation: "障害を引き起こしたデプロイ数 / 全デプロイ数"

  mttr:
    source: "インシデント管理ツール"
    calculation: "各インシデントの (復旧時刻 - 検知時刻) の中央値"

「DORAメトリクスの素晴らしさは、速度と安定性が両立することを証明した点だ。速く動く組織ほど障害も少ない。速度を犠牲にして安定性を得る、という考えは間違いだった」 — 佐藤CTO

SPACE フレームワーク（詳細）

前のステップで概要を学んだSPACEを、実践レベルで掘り下げます。

測定設計の原則

SPACEの3つのルール:
1. 最低3つの次元から指標を選ぶ
2. 定量指標と定性指標を組み合わせる
3. 個人・チーム・組織の複数レベルで測定する

実践的な指標セット

次元チームレベル指標測定方法
Satisfaction開発者満足度スコア四半期サーベイ（1-5スケール）
Performance計画達成率完了ストーリーポイント / 計画ポイント
ActivityPRマージ数GitHub API から自動集計
CommunicationPRレビューターンアラウンドPR作成からレビュー完了まで
Efficiency中断なし作業時間カレンダー分析 + サーベイ

アンチメトリクス：測ってはいけない指標

Goodhart の法則

“指標が目標になると、良い指標でなくなる”

アンチメトリクスなぜ危険か何が起きるか
コード行数多いほど良いと勘違い不必要なコードが増える
コミット数頻度を目的化意味のないコミットが増える
PR数量を追うPRが極端に小さくなりレビュー効率低下
バグ修正数多いほど優秀と評価バグを事前に入れるインセンティブ
残業時間少ないほど良いと強制見えない残業が増える
個人のベロシティ個人間比較チームワーク崩壊、見積もり膨張
実際に起きた失敗事例

事例: コード行数で評価した結果

ある企業がエンジニアの評価にコード行数を導入した結果:

  • 1行で書ける処理を10行に分割する開発者が出現
  • リファクタリング（コードを減らす作業）を誰もやらなくなった
  • コードベースが1年で3倍に膨張
  • 保守コストが急増し、結局評価制度を廃止

教訓: メトリクスは「何を測るか」だけでなく「どう使うか」が重要。個人評価ではなくチーム改善に使う。

エンジニアリング効果性（Engineering Effectiveness）

フレームワーク

Engineering Effectiveness = f(
  Developer Experience,    # 開発者体験
  Development Velocity,    # 開発速度
  Quality & Reliability,   # 品質と信頼性
  Business Impact          # ビジネスインパクト
)

ダッシュボード設計

engineering_dashboard:
  tier1_business_impact:
    - "Feature Lead Time（アイデア→本番）"
    - "Customer-facing Incidents/月"
    - "Developer NPS"

  tier2_delivery_performance:
    - "DORA 4 Key Metrics"
    - "Sprint Goal達成率"
    - "テストカバレッジ推移"

  tier3_operational_health:
    - "ビルド成功率"
    - "フレイキーテスト数"
    - "セキュリティ脆弱性数"
    - "依存関係の更新状況"

  tier4_team_health:
    - "開発者満足度サーベイ"
    - "オンボーディング期間"
    - "離職率"

メトリクスの導入プロセス

4ステップ

Step 1: 目的を明確にする
  └── 「何を改善したいのか？」を先に決める

Step 2: 仮説を立てる
  └── 「このメトリクスを改善すれば、XX が良くなるはず」

Step 3: 計測を自動化する
  └── 手動収集は続かない。CI/CD + API で自動化

Step 4: 定期的にレビューする
  └── 月次でトレンドを確認し、アクションを決める

導入時の注意事項

原則説明
まず計測、次に改善現状を知らずに改善はできない
少数精鋭3-5個の指標から始める
チームで合意トップダウンではなくチームで指標を選ぶ
透明性全員がダッシュボードにアクセスできる
非難しないメトリクスの悪化を個人の責任にしない

まとめ

ポイント内容
DORA4つのキーメトリクスで開発パフォーマンスを測定
SPACE5次元で開発者生産性を多角的に評価
アンチメトリクス個人のアウトプット量を測ると逆効果
原則チームのアウトカムを測り、改善のために使う

チェックリスト

  • DORAメトリクスの4指標とElite基準を理解した
  • SPACEフレームワークの実践的な運用方法を把握した
  • アンチメトリクスとGoodhartの法則を理解した
  • メトリクス導入のプロセスと注意事項を把握した

次のステップへ

次は演習です。チームトポロジー、プラットフォーム、DX、メトリクスを統合して、エンジニアリング組織の設計を行いましょう。

推定読了時間: 40分