"作る"から"使われる"へ：Backstage 活用の現在地

本セッションでは、ソフトバンクにおける開発基盤整備の取り組みの一環として進めている、Backstage を活用した開発者ポータル構築の現在地について紹介します。まだ発展途上ではありますが、ポータルを実際の開発プロセスの中で活用してもらうために行っている取り組みや、その中で見えてきた設計・運用上の課題について共有します。

Transcript

1. “作る”から“使われる”へ Backstage 活用の現在地 ソフトバンク株式会社 2026年3月17日 AIプラットフォーム開発本部 クラウド開発第1統括部 サービス開発部 小林 慎平
2. アジェンダ © SoftBank Corp. All Rights Reserved. 2 • 背景 • 元々の課題 • Backstage 導入 • 導入効果 • 見えてきた課題 • 指標の設定 • まとめ
3. © SoftBank Corp. All Rights Reserved. • 2021 年ソフトバンクに中途入社 • クラウド基盤の設計・構築を経験 • DevOps・アプリケーション開発 • プラットフォームエンジニアリング 3 自己紹介
4. © SoftBank Corp. All Rights Reserved. 4 Platform Engineering の背景 2010年 Internal Developer Platform の起こり 2019年 Team Topology 2019年 Platform Engineering 2021年 Internal Developer Platform 引用：https://platformengineering.org/blog/the-story-of-platform-engineering 2026年現在 多数の組織で成熟した役割として認知 AI を絡めた高度化がトレンドか
5. © SoftBank Corp. All Rights Reserved. • 情報が複数箇所に分散 • 数十ほどあるサービスの一覧が整理されていない • 一部自動化は進んでいるものの手動の定型業務がまだまだある • 何が自動化されていてどこから申請すればいいか分からない • 運用チームにて terminal ではなく GUI で完結する UI の需要 部門 (プロダクト開発) 5 当部門における課題 開発 チーム 運用 チーム デリバリ チーム 企画 チーム
6. © SoftBank Corp. All Rights Reserved. 6 解決したかったこと
7. © SoftBank Corp. All Rights Reserved. • IDP 構築のためのフレームワーク (ほぼデファクト) • Spotify発のOSS 7 Backstage という選択肢
8. © SoftBank Corp. All Rights Reserved. 8 Backstage 導入で目指したもの 一般利用者 (企画/開発/ デリバリ/運用) コンテンツ提 供者 (主に開発) 見える化 サービス・チームの 技術ドキュメントと関係性 自動化 アカウント・権限・リソース申 請などの部門内手続き ◎ 各サービスの担当チームや関連のドキュメントがすぐに見つかる ◎ テンプレート＋セルフサービスで部門内の手続きがすぐに終わる ◎ 手続きは標準通り進められて履歴も残るため安心して進められる 閲覧 利用 情報 掲載 テンプレ 作成 Backstage 「見える化」と「自動化」のプラットフォーム
9. © SoftBank Corp. All Rights Reserved. • Group / Domain / System / Component / Resource を定義 ◦ 事前に Team Topology を整理しており、それに従った組織構成 ◦ 依存関係も定義 (階層・関連性) ◦ ownerを明示 ◦ 原則 1対1 でドキュメント (TechDocs) を紐づける 9 Catalog でのサービス・リソースの可視化 (1/2)
10. © SoftBank Corp. All Rights Reserved. Backstage により各サービスの「技術仕様」へのアクセスが容易に Backstage 従来 • 閲覧にはGitアカウントが必要 • 開発者以外は心理的障壁あり • 検索・目次の利便性にも難あり Azure SSO GitHub Login • Azure SSO でログイン • 各サービス資料を一箇所に集約 • 検索性に優れている 利用者 Catalog でのサービス・リソースの可視化 (2/2) 10
11. © SoftBank Corp. All Rights Reserved. • Azure のアカウントの管理について課題 ◦ 定型作業だが仕組みが非効率/属人的 → アカウント管理作業者の負担大 ◦ 手動ゆえの作業品質 ◦ リードタイムの大きさ、進捗状況が見えにくい 11 Azure のアカウント申請業務を Template 化 (1/2) After Before Backstage backlog GAS スプレッドシート Slack Google Chat Azure GitHub 承認者
12. © SoftBank Corp. All Rights Reserved. Backstage により手動対応工数を 85% 削減 フォーム 入力 利用者 Backstage 従来 ①Backlogの申請内容をSSに転記してGAS実行 ②作業後にステータス更新・通知 Workflow ①入力内容が通知され承認すると Workflowが実行される 権限付与 スクリプト Git 更新で自動的に権限が付与される 承認 45min 20回/月 = 15h/月 6min 20回/月 = 2h/月 ※作業履歴はGitに残る リードタイムの大幅削減にも寄与。追加改修により進捗状況の可視化も。 チーム外の PMO の作業が不要になり、申請 →承認→権限付与がチーム内で完結。 Azure のアカウント申請業務を Template 化 (2/2) 12
13. © SoftBank Corp. All Rights Reserved. • アカウントのライフサイクルにおける運用を含めた再設計が必要 ◦ Backstage 側だけでは完結しなかった • Azure の SSO 認証後、シームレスな GitHub アカウントとの連携のために ◦ EntraID ユーザーのカスタム属性に GitHub ユーザーの ID を持たせて 取り込み時に変換が必要 　→ 今後対応予定 13 見えてきた課題① アカウント設計の課題
14. © SoftBank Corp. All Rights Reserved. • 各チーム独自運用のドキュメントサイトが存在 • 構築中の Backstage では ◦ Markdown + MkDocs ：標準対応 ◦ Sphinx ：非対応 • 第一段ではCatalog + link によるドキュメント紐付けで対応 14 見えてきた課題② 独自ドキュメントサイトとの連携
15. © SoftBank Corp. All Rights Reserved. • 方針 ◦ 公開 Plugin で足りる部分はそのまま利用 ◦ 足りない部分は Custom Action を作成 ▪ 少人数での開発のため、作る・作らないの判断を適正化したい • 利用頻度・メンテナンスコストをもとに判断 ▪ Backstage の image とは別リポジトリ・別パッケージで管理 • 困りどころ ◦ 公開の Plugin は部品として充実しているが、追加開発なしで即 Template に組み込める状態ではないことが多い 15 見えてきた課題③ Plugin or Custom Action の判断
16. © SoftBank Corp. All Rights Reserved. 16 もっと使われるポータルを目指して • Backstage の利用度や導入効果の度合いを測るために 以下指標 (North Star Metrics) を設定 (※ 係数 10 は仮置き) 　TechDocs アクセス総数 + Catalog アクセス総数 + Software Template 実行数 × 10 NSMとは... 事業やプロダクトがユーザーに提供する「本質的な価値」を ひとつの数値で表したもの 例-1) Spotify : 「ユーザーの総再生時間」 例-2) Slack : 「週あたりのアクティブチーム数」
17. © SoftBank Corp. All Rights Reserved. • 「見える化」と「自動化」のプラットフォームの土台ができた ◦ 入口の一本化 ◦ GUI で完結する UI ◦ サービスの可視化 ◦ 定型業務の整理・移行による業務効率化 ◦ もっと使われることを目指した指標の設定 • 技術より組織整理・調整の難しさを感じた 17 まとめ