GitHub社内におけるエンジニアリングガバナンスはどのように行われているのか
今回は「GitHub社内におけるエンジニアリングガバナンスはどのように行われているのか」についてご紹介します。
関連ワード （方針、確実、社内等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
GitHub社内におけるエンジニアリングガバナンスがどのように行われているのかを紹介した同社のブログ「GitHub’s Engineering Fundamentals program: How we deliver on availability, security, and accessibility」（GitHubのエンジニアリングにおける基本原則：我々はいかにして可用性、セキュリティ、そしてアクセシビリティをデリバリしているのか）が公開されています。
GitHubにとって、ソフトウェアの開発力が同社の競争力に直結するものであることは明白です。エンジニアリングガバナンスは同社の経営にとって最も重要な要素であり、その同社が構築したエンジニアリングガバナンスのノウハウは多くのIT企業にとって参考になるものでしょう。
同社がどのようなガバナンスを行っているのか、ブログの内容からまとめてみました。
目指すべきゴールと優先すべき基本原則の設定
同社はまず、目指すべきゴールとして次のような目標を設定しています。
Our goal was to work cross-functionally to define, measure, and sustain engineering excellence with a vision to ensure our products and services are built right for all users.
私たちのゴールとして、すべてのユーザーにとって適切な製品とサービスが確実に提供されるようにするというビジョンの下で、部門を超えて連携し、エンジニアリングの卓越性を定義し、測定し、維持する、ということを設定します。
このゴールへ向かうためのプロセスとエンジニアリングカルチャーを構築するために、最も優先すべき以下の3つが「基本原則」（Fundamentals program」として設定されます。
Accessibility (A11Y): Truly be the home for all developers
アクセシビリティ（A11Y）：すべての開発者にとって真のホームとなるSecurity: Serve as the most trustworthy platform for developers
セキュリティ：開発者にとって最も信頼できるプラットフォームとして機能Availability: Always be available and on for developers
可用性：開発者がいつでも利用できるようにする
基本原則を守れているか、自動でスコアカード表示
GitHubの各サービスや機能がこの3つの基本原則に合致しているかどうかが、自動的に評価されスコアカードとして表示される仕組みも導入されました。
The scorecards are designed to let us know that a particular service or feature in GitHub has reached some expected level of performance against our standards. Scorecards align to the fundamentals pillars.
スコアカードは、GitHubの特定のサービスや機能が、私たちの基準に対して期待されるパフォーマンスレベルに達しているかどうかを私たちに知らせるためのものです。このスコアカードは、基本プログラムの3つの柱に沿ったものとして設定されます。
下記は「Secret Scanning」機能のスコアカードの例です。スコアカードにはこの機能のオーナー、連絡先としてのSlackのチャンネルなど、開発チームの基本的な情報と共に現在のリスクと修正状況などが表示されます。
「Secret Scanning」機能のスコアカードの例（記事の幅に合わせてPublickeyが一部画像を加工しています）このスコアカードを自動的に表示する仕組みのために、各サービスや機能ごとに重要度やQoSの内容、サービスの種類などの詳細がYAMLファイルとして記述され、そのYAMLファイルに基づいて自動的にスコアが計測され、継続的に示されます。
そしてスコアカードの示す内容が基本原則を満たしていない場合、効果的な解決のためのSLAとともにアクションアイテムが生成され、対応するIssueがリポジトリに自動的に生成され、担当する開発者のワークフローに組み込まれます。
これによって開発者は、担当する機能やサービスが基本原則を満たさない場合の対応をワークフローの中でシームレスに行うことができるようになっているのです。
基本原則を維持するための組織構造
スコアカードを基にして、各機能やサービスが基本原則から逸脱しないように計画し実行する責任は各担当チームにあります。
そうしたチームは次のような組織構造を持っています。
Exective sponsor（エグゼクティブスポンサー）
上級リーダーであり、リソースの調整、ガイダンスの提供、戦略的な意志決定などによって基本原則への対応をサポートする。
Pillar sponsor（ピラースポンサー）
エンジニアリングリーダーであり、可用性、セキュリティ、アクセシビリティという基本原則の3つの柱にフォーカスして組織全体の監督を行う。
Directly responsible individual (DRI)（直接責任担当）
基本原則に対応する直接的な責任を負う担当者であり、組織全体と協力してスケジュールや方針などについて適切な意志決定を行う。
Scorecard champion（スコアカードチャンピオン）
スコアカードの保守担当であり、スコアカードがつねに適切であり続けるための機能追加、保守、機能削除などを行う。
Service sponsors（サービススポンサー）
サービスの健全性の維持に責任を持ち、そのためにサービスを担当するチームを監督する
Fundamentals delegate（基本原則の代理人）
代理人は各サービスオーナーと基本原則のための作業の調整を行い、スポンサーによる作業の優先度付けを支援し、作業を完了させるためのリソースの確保を約束する。
スコアカードを一覧するダッシュボード
GitHub社内では、基本原則を満たしていないスコアカードを一覧にし、表示するダッシュボードも用意されていると説明されています。これにより重要なインシデントや作業をすぐに見分けて意志決定し、アクションを起こすことが容易になります。
下記がそのダッシュボードの例です。
いちばん重要なのはパートナーシップの文化
こうした基本原則とそれをサポートするためのスコアカードの自動化や組織構造によって、GitHubはビジネスにおける多くの改善を達成したとしています。
その上で、しかしいちばん重要なのはパートナーシップの文化だと次のようにブログの記事を結んでいます。
Most importantly, we celebrate the wins publicly, however small they may seem. Building the culture of collaboration, support, and true partnership has been key to sustaining the ongoing momentum of an organization-wide engineering governance program, and the scorecards that monitor the availability, security, and accessibility of our platform so you can consistently rely on us to achieve your goals.
最も重要なことは、どんなに小さなことであってもみんなでその勝利を祝福することです。協力し合い支援し合う本当のパートナーシップのカルチャーを構築することが、組織全体のエンジニアリングガバナンスプログラムの継続的な勢いを維持する鍵であり、私たちのプラットフォームの可用性、セキュリティ、アクセシビリティを監視するスコアカードなのです。