GitHubのエンジニアリングシステム成功プレイブック

• エンジニアリングの成功には、品質(Quality)、速度(Velocity)、開発者満足度(Happiness) の3領域が調和することが重要
• ESSP(Engineering System Success Playbook) は、これを統合的に改善し、ビジネス成果を最大化するための3段階フレームワークを提供する
• SPACE、DevEx、DX Core 4、DORA など複数のフレームワークに基づいて設計された 12の主要指標 により、組織の現状を把握し、改善目標に応じて 優先順位を設定 し、段階的に 変化を実装・調整 する
  • これら12の指標は、各領域を定量的に追跡できるよう構成されており、組織ごとに状況に応じてカスタマイズ 可能
• あらゆる改善は、チーム単位での持続可能性 と システム思考 を基盤とし、先行指標と遅行指標 をあわせて考慮するバランスの取れたアプローチを強調する
• 短期的な改善ではなく、持続可能な長期的変化 を追求する
• ESSPは 独自の測定ツールがなくても開始でき、アンケートなどの定性的手法による初期診断も有用
• GitHubは自社事例を通じて、品質中心の改善が最終的に速度と開発者満足度にも良い影響を与える ことを強調している

GitHubのエンジニアリング成功メトリクス

• Quality
  • Change failure rate: 変更失敗率
    → 障害や問題を引き起こした変更の割合
    • 計算方法: (失敗したデプロイ数 / 全デプロイ数) × 100
    • ヒント: どの基準で失敗と見なすかをチーム内で明確に合意しておくこと（例: ロールバックの有無、モニタリング警告など）
  • Failed deployment recovery time: デプロイ失敗からの復旧時間
    → 失敗したデプロイをロールバックするか、正常状態に復旧するまでにかかった時間
    • 計算方法: 各失敗デプロイの復旧完了時点 − 失敗発生時点の 中央値
    • ヒント: アラートシステムやログから自動抽出する方式を推奨。平均より 中央値 の使用を推奨（外れ値の影響を防ぐため）
  • Code security and maintainability: コードのセキュリティ性と保守性
    • 計算方法: 静的解析ツール、GitHub Advanced Security、CodeQL などを通じて、脆弱性数、複雑度、カバレッジ などを総合評価
    • ヒント: 定期的な自動スキャンを設定すること。リファクタリングやセキュリティポリシー変更の効果測定に活用できる
• Velocity
  • Lead time: リードタイム
    → コード変更が本番環境に反映されるまでの時間
    • 計算方法: PRが作成された時点から、マージ後にデプロイされるまでの時間
    • ヒント: 平均ではなく 中央値 を使うことで歪みを減らせる。リードタイムが長い場合は、PR待機時間やレビュー遅延を別途測定する
  • Deployment frequency: デプロイ頻度
    → どの程度の頻度で本番デプロイが行われているか
    • 計算方法: 一定期間内の デプロイ回数 （日次/週次）
    • ヒント: 自動化されたデプロイを含めるかどうかを明確にする必要があり、小規模チームでは週次基準のほうが適切な場合がある
  • PRs merged per developer: 開発者1人あたりのマージ済みPR数
    • 計算方法: PRの総マージ数 / 貢献した開発者数
    • ヒント: 比較のための手段ではなく、チームのワークフロー効率を測る用途で活用すること。PRのサイズや複雑さとあわせて解釈する必要がある
• Developer Happiness
  • Flow state experience: フロー状態の体験
    • 計算方法: 開発者アンケートで「最近の没入体験の頻度/持続時間」を評価
    • ヒント: 月1回以上の定期調査を推奨。自由記述式の回答を含めると質的な洞察も得られる
  • Engineering tooling satisfaction: エンジニアリングツール満足度
    • 計算方法: 開発者アンケートを通じて、ツール利用の満足度と改善希望事項を収集
    • ヒント: ツールごとの詳細項目（IDE、CI、課題追跡など）に分けると、実質的な改善ポイントを導き出しやすい
  • Copilot satisfaction: Copilot利用満足度
    • 計算方法: Copilotライセンス保有者を対象に満足度調査を実施（NPSまたはスコア）
    • ヒント: 導入直後 と 3か月後 など、時点別の比較を推奨。フィードバックを通じて教育や活用事例を改善できる
• Business Outcomes
  • AI leverage: AI活用度
    • 計算方法: Copilotコミット比率、AIコード提案の採用率、利用時間など
    • ヒント: GitHubの Copilot Telemetry API や内部計測を活用できる。定性的フィードバックとあわせて分析するとより有効
  • Engineering expenses to revenue: 売上に対するエンジニアリング費用比率
    • 計算方法: エンジニアリング関連支出 / 総売上
    • ヒント: 内部会計基準の整備が必要。比較のために月次または四半期ごとのトレンド分析を推奨
  • Feature engineering expenses to total engineering expenses: 総エンジニアリング費用に占める機能開発費の割合
    • 計算方法: (機能開発関連支出 / 全エンジニアリング支出)
    • ヒント: 保守、インフラ、テストなど 機能開発以外の費用分類基準を事前に明確化 しておくことで、正確な測定が可能になる

[エンジニアリング成功のための3段階]

Step 1: Identify the current barriers to success

• 現在の開発プロセスの問題点とエンジニアリングの成功を妨げる障壁を特定することが中核
• これは今後の改善の方向性と優先順位を設定するための**ベースライン（baseline）**として機能する
• アプローチ
  • **SDLC（Software Development Life Cycle）**全体の流れを分析してボトルネックを把握
  • GitHubでは12の標準指標を基準に分析するが、組織の特性に合わせて一部のみを活用することも可能
• チーム参加
  • 単一のリーダーではなく、チームメンバー全員が改善プロセスを一緒に定義すべき
  • 少数の指標だけで意味のある対話を始めるだけでも十分
• 方法論

  • 1. 基本フローの理解

    • エンジニアリング全体の流れを次のように分けて確認する:
      • 計画（Plan） → 開発（Develop） → レビュー（Review） → ビルド（Build） → テスト（Test） → リリース（Release） → 運用（Operate）

  • 2. 定量的シグナルの収集

    • 次のような定量データを分析する:
      • デプロイ頻度: どれくらいの頻度でデプロイされるか
      • リードタイム: コードを書いた時点からデプロイまでにかかる時間
      • 変更失敗率: デプロイ後にエラーが発生する割合
      • MTTR（平均復旧時間）: 問題発生後に復旧までかかる時間

  • 3. 定性的シグナルの収集

    • 開発者およびチームの経験に基づくフィードバックを収集:
      • チームメンバーはいつ非効率を感じるか
      • どのツールや手順が繰り返し問題を引き起こすか
      • どの活動が最も大きな心理的負担を与えるか
    • 方法:
      • アンケート、レトロスペクティブ、1:1インタビューなどを活用
      • 事前定義されたESSP質問リストを使ってもよい

  • 4. 核となる問題の定義

    • 収集したデータを通じて**障壁（Barrier）**を定義
    • 例:
      • "リードタイムが長く、新機能の開発が遅れている"
      • "ビルド失敗が頻発し、デプロイの信頼性が低い"
      • "開発者が頻繁にコンテキストスイッチング（Context switching）を強いられている"
    • 問題は具体的で観察可能な形で記述すべき

  • 5. 指標の優先順位付け

    • すべての指標を一度に改善するのではなく、最も大きな影響を持つ1つまたは2つの指標に集中
    • この優先順位は、今後のStep 2とStep 3における改善の試行および成果測定の基準になる
• Step 1を成功させるためのヒント
  • 1. 表面的な見え方ではなく根本原因に集中すること
    • 表面的な症状だけを見て判断せず、問題の根に深く踏み込む必要がある
      • 例: 速度が遅い理由が「手動テスト」にあるように見えても、実際の原因は自動テストへの信頼不足かもしれない
    • そのためには、ソフトウェアエンジニアリングでよく見られる**アンチパターン（antipattern）**を参考にするのが有益
  • 2. アンチパターンを参考にすること
    • アンチパターンとは、よく使われる解決策だが実際には問題を解決できず、むしろ副作用を引き起こしうるやり方を意味する
    • GitHubではチーム内に存在しうるアンチパターンの例を別リソースとして提供しており、自己点検ツールとして活用可能
  • 3. 適切な人々を参加させること
    • Step 1のTask 1では、さまざまな役割のメンバーから入力を得ることが重要
      • 例: 開発者、テスター、運用、セキュリティ、プロダクトマネージャーなど
    • こうすることで、ワークフロー全体を立体的に理解でき、特定の視点を取りこぼさずに済む
  • 4. 定量データと定性データをバランスよく活用すること
    • メトリクス（指標）だけでは全体の文脈を理解できない
    • 定量分析に加えて、チームメンバーの心理面・文化面・協業面の問題に関する定性的フィードバックも収集する必要がある
    • 例: チームの士気低下、コミュニケーション不足、レトロスペクティブでの不満などは数値には現れない
  • 5. 障壁を多く選びすぎないこと
    • すべての問題を一度に解決しようとせず、最も影響が大きく緊急性の高い障壁に集中する
    • 初期段階で改善課題を多く抱えすぎると、実行力と勢いを失うリスクがある
  • 6. 心理的安全性を確保すること
    • チームメンバーが不利益や報復を恐れずに率直に意見を言える環境を整える必要がある
    • これは本当の問題を明らかにするための中核条件であり、改善活動の信頼性と効果を高める
  • 7. 比較は学習のためであり、評価のためではない
    • チーム間の指標比較やワークフローの違いは、定量的な成果評価ではなくインサイト導出のために活用すべき
    • チームごとに状況、目標、技術スタック、制約条件が異なるため、単純比較は誤解を招く可能性がある
    • その代わり、何がうまく機能しているかを共有し、教訓を導き出す学習文化を奨励すべき

Step 2: 目標を達成するために何をすべきかを評価する

• 目的
  • Step 1で定義した核心的な問題（Barrier）を解決するために、どのような変化を実行すべきかを分析する段階
  • 単純な機能導入やツール変更を超えて、組織的・技術的・文化的な次元の根本原因と解決策を把握する

• 1. 現在の状態の根本原因分析

  • 単に「速度が遅い」「満足度が低い」という結果を超えて、
    • なぜ遅いのか、
    • どのような構造的・組織的理由があるのか、
    • 変更できるものとできないものを区別する必要がある
  • 利用可能なツール:
    • 5 Whys手法
    • フィッシュボーン（原因-結果）図
    • チームのレトロスペクティブにおける定性的フィードバック分析

• 2. 可能な解決策の導出

  • 問題に対する技術的、文化的、プロセス的な解決策をブレインストーミングする
  • 例:
    • 技術面: テスト速度の向上、CI/CDパイプラインの改善
    • 文化面: コードレビュー慣行の整備、オンボーディングの改善
    • プロセス面: PRサイズの制限、マージ基準の変更
  • GitHubの推奨手法:
    • 観察に基づく解決策と人間中心の改善案を組み合わせて導き出す

• 3. 効果とリスクの評価

  • 各解決策について、次の要素を評価する:
    • 期待効果: どの改善指標に影響を与えられるか
    • 実現可能性: チームのリソースと現実的な実行力
    • 組織的受容性: 変化に対する抵抗の水準
    • 短期/長期効果の区別: すぐに結果が出るのか、継続的な変化なのか
  • そのために**Pilot（試験運用）**を推奨
    • 小規模なチーム単位で試し、フィードバック収集後に拡大するかどうかを決定

• 4. 優先順位の選定とコミュニケーション

  • 複数の解決策の中から、次の基準で優先順位付けする:
    • 最も大きなインパクトを与えられるもの
    • 最も実行可能なもの
    • 最も緊急性の高い痛点を解決するもの
  • この決定はチームメンバーと共有し、合意を得る必要があり、
    • OKRや改善目標の形で明確に記載するのが望ましい
• Step 2を成功裏に進めるためのヒント
  • 1. 長期的な持続可能性を必ず考慮すること
    • 短期的な成果だけに集中すると、かえって長期的な問題を引き起こす可能性がある
      • 例: 新しいツールの導入で速度を即座に改善できても、教育、サポート、変化管理が伴わなければ、かえってミスや混乱を招く
    • したがって、どの改善の試みも保守性と展開可能性まで考慮した戦略であるべき
  • 2. 各領域（zone）間のトレードオフを考慮すること
    • ある領域（例: 速度）を改善する変化が、別の領域（例: 開発者満足度、品質）を犠牲にしないよう注意する
      • 例: レビュー基準を緩和すると速度は上がるが、コード品質や開発者の疲労度が悪化する可能性がある
    • 常に影響範囲が複数の領域にまたがることを考慮し、バランスの取れたアプローチが必要
  • 3. 初期段階からチームを参加させること
    • チームが直接参加し、共に作った変化ほど成功確率が高い
    • 変化が**ボトムアップ（bottom-up）**で行われるよう、メンバーの意見を取り入れる
    • 一方的な指示型の**トップダウン（top-down）**の変化は、抵抗や無関心を招きうる
  • 4. 成功指標を明確に定義すること
    • 変化の実施前に、何をもって成功とするかを合意しておく必要がある
    • 例: 「デプロイ時間の短縮」が目標なら、
      • 遅行指標: 実際のデプロイ時間の減少
      • 先行指標: PR待機時間の減少、開発者アンケートで「PR速度の向上を実感」という回答の増加
    • **先行指標（Leading Indicator）と遅行指標（Lagging Indicator）**を併せて定義するのが理想的
  • 5. 完璧な計画よりも迅速な実験を志向すること
    • 小さな変化でも素早く試し、フィードバックを受けて改善する反復的アプローチが効果的
      • 初期段階では不完全な試みであっても小さな単位で試験し、効果が実証されれば拡大する
    • 失敗の可能性を下げ、変化に対するチームの俊敏性と適応力を強化するのに有利
  • 6. 少ない労力で大きな効果を出せる変化から試すこと
    • 変化項目が多く複雑なときは、まず**「高効果・低コスト」領域の改善案**から選ぶ
    • 例: シンプルなレビューガイドの導入、不要な通知の削除などは、迅速に適用できるうえ満足度に大きな影響を与えられる
    • 初期の成功体験はチームに自信を与え、より難しい問題へ進める推進力を提供する

Step 3: 変更を実装し、結果をモニタリングし、調整する

• Step 2で導き出した改善施策（Intervention）を実際に組織内で実行し、
  その成果を測定し、必要に応じて調整または反復改善することで、継続的なエンジニアリングの成功を目指す段階

• 1. 実行（Implement the change）

  • 実行前に次の点を明確にする必要がある:
    • どのような変化を行うのか？
    • 誰が責任を負うのか？
    • どの指標を基準に評価するのか？
    • いつからいつまで測定するのか？
  • 実行時の考慮事項:
    • 責任者の設定: オーナーシップの明確化
    • チームのオンボーディングと教育: なぜ変化が必要なのか、何が変わるのかを、チームメンバー全員が理解する必要がある
    • 変化の文書化: 記録を残し、今後のふりかえりや反復時の参考にできるようにする
  • 導入例:
    • CI/CD速度改善のためのビルドキャッシュ戦略の変更
    • コードレビュー方針の変更（例: 1日以内に応答するルールの導入）

• 2. モニタリング（Monitor the change）

  • 改善案の実行後、事前に定めた指標で効果を追跡・観察する
    • リードタイムが短縮されたか
    • 失敗率が低下したか
    • 開発者満足度が向上したか など
  • ツール:
    • GitHub Insights、Copilot Telemetry、社内BIシステム
    • 週次/月次レポートダッシュボード
    • 開発者アンケートまたはふりかえりフィードバック
  • 重要なポイント:
    • **ベースライン（baseline）**と比較できる必要がある
    • **単一の数値ではなくトレンド（推移）**を見ることが重要

• 3. フィードバック収集（Collect feedback）

  • 定量的指標に加えて、開発者の観点から見てその変化が実際に役立ったかどうかのフィードバック収集が必要
    • ふりかえり、匿名アンケート、1:1ミーティングなどを活用
    • 改善の「体感」が高いか、逆に疲労感を与える変化ではないかを確認
  • 組織的な合意なしに性急に実行した変化は、抵抗や反発を招く可能性がある

• 4. 調整または反復（Adjust as needed）

  • 改善施策の結果が期待に届かなかったり副作用がある場合は、次のように対応する:
    • 変更を元に戻す、または補完する
    • 一部の要素だけを維持し、範囲を縮小する
    • より広い範囲に拡張適用する
  • 変化の成功/失敗にかかわらず、常に次を学ぶ必要がある:
    • どの要素が効果的だったか？
    • 何が阻害要因だったか？
    • 次は何を変えるべきか？
• Step 3を成功させるためのヒント
  • 1.すぐに完璧を期待しないこと
    • すべての変化がすぐに目に見える改善を生むわけではない
      • 効果が現れるまでには時間がかかることがある
      • チームにも変化に適応するプロセスが必要なため、忍耐と継続的な観察が重要
    • 初期段階では、アンケートなどの定性的フィードバックツールを活用して変化の体感を把握することが有効
  • 2.変化を継続的に反復・改善すること
    • 一度成功したからといってそのまま維持するのではなく、変化自体も絶えず進化し、調整されるべき
    • 新たな問題や外部環境の変化に応じて、既存の改善案も再検討する必要がある
    • チームがこれを定期的な活動として認識し、改善サイクルを継続できるように促すべき
  • 3.意図しない副作用に注意すること
    • 一部の変化は、他の領域に予期しない摩擦を引き起こす可能性がある
      • 例: デプロイ速度の向上は良い変化だが、品質検証が弱ければバグ増加につながる可能性がある
    • 指標だけでなく、ワークフロー全体の流れの変化もあわせて確認し、異常の兆候があれば即時対応が必要
  • 4.心理的安全性の状態を継続的に確認すること
    • 変化の後も、チームが自由に問題提起できる環境を維持する必要がある
    • 「口にされない問題」が蓄積しないよう、チームメンバーが率直なフィードバックを出せる雰囲気を作る必要がある
    • 変更後のプロセスに対する不満、過度な業務増加、予期しないストレスなど
  • 5.長期的な効果を継続的に評価すること
    • 短期的な成果ではなく、持続的な成果とチーム士気の向上が核心
    • 時間の経過とともに:
      • 変化が定着したか
      • 新たな副作用や問題が生じていないか
      • 成果の維持または低下があるかを継続的に点検する
  • 6.フィードバックを学習機会として活用すること
    • 失敗した変化も貴重な学習資産である
    • 何がうまくいかなかったのかをデータとフィードバックに基づいて分析し、次の試みに反映させるべき
    • チームにも失敗を学習の機会として認識するよう促す文化が重要

Beyond the steps: Make the playbook work for you

• Tailoring

  • 組織の特性に合わせて測定対象の指標と方法（テレメトリー vs アンケート）を選択する
  • 測定そのものを目的にせず、実質的な改善のためのツールとして活用すべき

• Change management

  • ADKAR、Kotterモデルなどの変革管理フレームワークを活用し、組織が変化にうまく適応できるよう支援することが重要

• Growth mindset

  • すべての試みを学習の機会と捉え、失敗を受け入れる姿勢が継続的改善の鍵となる

• Gamification

  • 動機付けベースの報酬設計は前向きな効果を生む可能性があるが、設計を誤ると逆に品質低下や不均衡を招く可能性がある

Alternatives to the GitHub Engineering System Success Playbook

• 状況によっては、ESSPではなくシンプルな機能利用中心の分析や個別ツールベースの改善戦略も可能
• 重要なのは、チームと組織に合った現実的なアプローチと継続的な改善努力である