GitHub Universe '25 Recap Tokyoにて LT登壇
皆さんこんにちは。ACS事業部 亀崎です。
先日（2025年11月26日）渋谷で開催された GitHub Universe '25 Recap Tokyo にて同僚の田中とともにLTに登壇させていただきました。
LTのタイトルは、『GitHubをスーパーチャージ！カタログ、標準化、可視化で開発を加速するBackstageポータルとの連携』。 いつものようにBackstage（および弊社のBacksage Managed Service、PlaTT）についてご紹介させていただきました。 ここではその内容を再構成して簡単にお伝えしようと思います。
と、ここで始めるまえに、ちょっと余談。
実はこのタイトル、内部では少し異論がありました。そのポイントが「スーパーチャージ」、この言葉に馴染みがないのではないか？というものでした。
私としては、IT系の様々な登壇でも結構当たり前に使われているもので、結構一般化しているのではないか。感覚的には伝わるのではないか、と思っていたのですが、そうでもないのでしょうか。とても気になっています・・・
余談はここまでにして、あらためて。BackstageでGitHubでの開発をSuperchargeしちゃいましょう。
開発を加速するBackstageとの連携
AI駆動開発時代に発生する課題
GitHub Copilotの登場で、AIアシスト開発・AI駆動開発が浸透し、開発のスタイルが変化しつつあるというのは皆さんも感じていると思います。 AI駆動開発が浸透すると、１つの開発チームのメンバーは減少（その代わりにCopilotが加わる）すると考えています。しかし１つの開発チームで扱う開発リポジトリの数は増加すると思います。そして全体として開発チームの数は増加するはずです。
開発チーム・リポジトリ増加のイメージ
数多くの機能が開発されること自体は悪いことではありませんが、これにより「リポジトリ・スプロール（乱立）」が顕在化すると言われています。
リポジトリの乱立でどういった問題が起きるのか。私たちの経験から、以下の３つの課題が発生する（実際に発生してきている）と考えています。
情報を探す時間の増加
GitHub Copilotの登場で以前よりは比較的簡単にコード実装ができるのは皆さんもご存知のとおりです。しかし、組織全体から見た場合、同じような機能をあちこちで実装するのは非効率ではないでしょうか。できれば同じものは再利用したい。また、まったく同じではないまでも、似たような機能があるならば参考にしたい。
そう考えた組織内で場合、同じ・類似の機能がないか探したいと考えます。少数のリポジトリであればそれほど大きな問題にはなりませんが、さきほど挙げたように組織内ではリポジトリスプロールが起きていて、多数のリポジトリが存在している状況になります。リポジトリの数に比例して情報を探す時間も増加してしまいます。
この結果、情報検索時間が増加したり、そうした検索を避けて個々に独自実装することで類似機能が乱立といった状態になり、結果として意図せず開発生産性が低下する、といった状況に陥りかねません。
オーナーの不明確化
多数のリポジトリが出来上がると、相対的にオーナーシップが不明確になりやすくなります。ぱっと作ってあまり責任をもってメンテナンスされないなどが発生しやすくなると考えています。
またオーナーシップが明確であった場合でも別の課題があります。
機能の再利用などでそれぞれのサービス・ツールに依存関係が生まれてきます。せっかくある機能を利用しようとして不明点があった場合にだれに問い合わせればよいか。
自分が公開している機能・APIの不具合改修やバージョンアップをしようとしている場合に、APIを利用しているサービス・ツールがどこのチームなのかを知りたい。
そういった状況が発生しやすくなると思います。リポジトリスプロールが発生している状況ではこうしたことも手間が増えます。
繰り返される共通設定
GitHub Cpilotが浸透するとモノリシックな設計から小規模な機能の組み合わせやマイクロサービスに準じた設計に変化していくものと考えます。そうした場合に、リポジトリ作成の機会は増えていきます。 そうしたリポジトリ作成のたびに、リポジトリ初期設定を繰り返すことになります。例えばブランチプロテクションルールなどのGitHub Rulesetなどのコンフィグレーションや、.github フォルダ下に配置する 組織標準の GitHub Action workflowファイルや Copilot Instruction等のファイルの登録がこの初期設定に該当します。
こうした初期設定ではできれば組織全体として同じようなものとしたいのですが、手順書等を用意した主導設定ではミスも起きやすく、なにより面倒です。
従来からこうした課題は発生していたと思いますが、GitHub Copilotを中心としたAI駆動開発の浸透でより頻繁に、そしてより小規模な組織でも発生しやすくなってきていると感じています。 せっかくGitHub Copilotにより開発生産性が高まってきていますが、それもどこかで向上率が下がってしまうことが起きるのです。
Backstageによる課題解決
上記にあげた課題を解決してくれるのがBackstageです。
Backstageをご存知ないかたはぜひ以下の投稿もご覧ください。
さきほど挙げた3つの課題「情報を探す時間の増加」「オーナーの不明確化」「繰り返される共通設定」はAI駆動開発ではじめて現れる課題ではなく、開発組織がスケールしていく際に起きるもので、以前から起きていたものでもあります。
Spotify社では組織拡大の中でまさにこの３つの課題が発生しました。そしてこれらを解決するためにBackstageを開発しました。 ということでBackstageはこれらの課題解決にぴったりなツールなのです。
課題解消方法の紹介
ではどのようにBackstageがそれぞれの課題を解決するかをみていきましょう。
「情報を探す時間の増加」の解消
Backstageでは組織内の開発資産をカタログという形で管理できます。これを一覧することができます。
それぞれのカタログではGitHub等の外部ツールと連携して、様々な状態を表示することもできます。 以下の例ではGitHubのDependabot AlertやIssue、Pull Requestの一覧などが表示されています。
この他KubernetesやArgo CDのステータスなど、実行環境の状況も表示することができるので、カタログから開発の状況から実行状態までまとめて見ることができます。
もちろん検索機能も用意されており、キーワード検索で必要な情報を探し出すことも容易です。
このほか、API定義の表示やリポジトリに作成したMarkdownなどによる説明資料もカタログの中で表示することができます。
さまざまな情報をまとめ、探し、表示することができる、というのがBackstageカタログの利点です。
「オーナーの不明確化」の解消
Backstageでは、それぞれのカタログにはオーナーを明示する必要があります。このためオーナーシップを明確にする効果があります。 それに加えて以下のように、それぞれのカタログ情報の依存関係をグラフ表示することができます。
ピンクのところが今表示しているカタログ（リポジトリ）とお考えください。そのカタログ（リポジトリ）を利用しているカタログ（リポジトリ）はどういったものがあるか、そのオーナーは誰か（またはどのチームか）といったことがこのグラフから読み取ることができます。
オーナーを中心に見た場合には、そのオーナー（チーム）がどういった機能を開発しメンテナンスしているかもわかります。
もちろんグラフ上のエンティティをクリックするとそのカタログ情報に遷移するできるので、依存関係やオーナーシップをより詳細に確認することができるのです。
「繰り返される共通設定」の解消
繰り返し作業にはBackstageのScaffolder Template機能が便利です。
繰り返し作業をテンプレートという形式でまとめ、こちらもカタログとして登録します。そのテンプレートを利用したいユーザーはそうしたテンプレートカタログの中から使いたいものを選択し、必要な情報を入力するだけです。
こちらの例では入力を完了すると、.github化のGitHub Action workflowやGitHub Copilot instructionなどのファイルをあらかじめ用意したリポジトリを新規作成、ブランチルールを設定するとともにGitHub Copilot Reviewをデフォルトで有効にするなどGithub Rulesetやいくつかのコンフィグレーションを設定した状態にします。
あらかじめ決まった内容を実行するので、とても簡単でミスも発生しません。
Backstage導入の効果
Spotify社の調査によると、Backstageを導入した結果以下のように開発生産性があがったとの結果を得られたそうです。
- GitHubの活動アクティビティが2.3倍に増加
アクティブな開発者は生産性が高いことも証明 - 開発者のコード変更頻度が2倍に増加、サイクルタイムが17%短縮
開発速度の向上、アウトカムに寄与していることへの証明 - ソフトウェアのデプロイ頻度2倍増加、コードの改修間隔 3倍に延長 本番環境へのデプロイ率が高く、その寿命が長いことは、コードの品質が高く、
- 12 か月後 会社在籍率が 5% 高い
開発者体験の向上から、開発者の満足度を維持するにつながっていることを示す
Backstageで得られる改善がこれだけになります。これにGitHub Copilotがもつ生産性向上の期待値を考えると、そうとう高い生産性が得られるのではないでしょうか。まさに「スーパーチャージ」ですね。
PlaTTのご紹介
このような便利な機能がいくつもあるBackstageですが、必要なPluginを探してそれを導入したり、アップデート等の管理が面倒なものです。 また、導入して終わりというものでもなく、使い方を探求することでその能力を100％発揮できるようになるものも多いです。 こういうところを１つ１つ解消するのって面倒ではありませんか？ そんな面倒さを解消するのが、私たちが提供するBackstageのManaged Service「PlaTT」です。
以前から紹介しているブログの記事を見ていただいてもわかる通り、自社で様々な検証も行っており、皆さんの「面倒」を解消することができると考えています。 ご興味のある方がいらっしゃいましたらぜひ弊社までご連絡ください。
よろしくお願いします。
