GitHub Engineering System Success Playbook

GitHub エグゼクティブ インサイトで公開

GitHub では、より良いビジネス成果は高品質なコード、速度、開発者の幸福度が単独でもたらされるだけではないと考えています。品質、速度、開発者の幸福度が実際に同時に効果をもたらすときに、組織が最高の結果を実現できます。より大きな価値をビジネスにもたらすエンジニアリングを求めている場合、これらの基礎ゾーンを強化して、チームが成功する良い条件を作ることが不可欠です。

これは GitHub のエンジニアリング システムの成功するプレイブック (ESSP) の要点です。GitHub Copilot のような AI ツールの導入の検討や、パフォーマンスを妨げているボトルネックの特定と解消を問わず、組織に有意義で大幅な改善をもたらすことができる 3 ステップのプロセスです。

SPACE や DevEx、DX Core 4、DORA を含む複数のフレームワークにインスパイヤされ、このプレイブックはバランスが取れた包括的なアプローチを説明し、時間の経過とともにトラッキングし、必要に応じて反復できる各"ゾーン"にメトリクスを割り当てることができます。

プロセスの簡単な内訳は以下のとおりです。

• ステップ 1: 成功への現在の障壁を特定する
• ステップ 2: 目標を達成するためにやるべきことを評価する
• ステップ 3: 変化のインプリメンテーション、結果のモニタリング、調整を行う

ESSP の中核には、長期的で持続可能な改善を優先するシステム的な思考のアプローチがあります。一時的な成果はイニシアチブを開始するために素晴らしい手段ですが、ネガティブな下流効果をもたらす可能性があります。例えば、コード レビューの所要時間を短縮することで開発を加速化することができますが、広範囲なシステムには対処しません。インフラやドキュメント習慣をテストするようなものであり、下流にボトルネックを発生させてコード品質に悪影響を与えるリスクがあります。

このプロジェクトは、エンジニアリング システムの変更をはじめ、有意義な下流への影響をもたらすための規範的ガイダンスに対する多くのカスタマー リクエストに応えるために開発されました。多くの場合は GitHub Copilot の導入を伴います。顧客のエンジニアリング パフォーマンスの向上または生成 AI の投資を擁護しながら、ベンダーが経験した課題や成功話を理解するため、DevEx と DevOps メトリクスのベンダーとやり取りもしました。したがって、エンジニアリングの成功話に伴う複雑さを、実用的で達成可能な手順とバランスを取るため、この手順はチーム用に作成されました。改善の過程の早期段階にある場合も対象とします。

プレイブックでは、各ゾーンに対する改善の取り組みの一環として、モニタリングの対象になる推奨メトリクスを要約します。これらのメトリクスは下流または遅行メトリクスであり、大半の事例では先行メトリクスで補足する必要があることに注意してください。コンテキストによっては、先行と遅行のメトリクスの両方はテレメトリやアンケート データを使用して測定することができます。これらのメトリクスが計算される方法は、チームのエンジニアリング ワークフローとサポートしているシステムによって異なります。

プレイブックを読み進める際、いくつかのコンセプトを意識することをお勧めします。

• 常にチームの視点を捉えた改善を行う
• ゲーミフィケーションを避けるため、注意しながらメトリクスを選択して使用する
• 測定のデメリットを測定のメリットをバランスを取る
• ベンチマークに頼り過ぎることよりも、長期的な改善に焦点を当てる

エンジニアリング チームは大掛かりな変化とビジネス結果の加速化を促進する潜在力を持っています。

GitHub の ESSP を使用すると、エンジニアの最善の努力を動機付けて擁護する優秀な文化を育むことで、エンジニアリングの能力を発揮することができます。詳細は e ブック と 1 ページ文書を参照してください。