“作る”から“使われる”へ Backstage 活用の現在地 ソフトバンク株式会社 2026年3月17日 AIプラットフォーム開発本部 クラウド開発第1統括部 サービス開発部 小林 慎平 

アジェンダ © SoftBank Corp. All Rights Reserved. 2 • 背景 • 元々の課題 • Backstage 導入 • 導入効果 • 見えてきた課題 • 指標の設定 • まとめ 

© SoftBank Corp. All Rights Reserved. ● 2021 年ソフトバンクに中途入社 ● クラウド基盤の設計・構築を経験 ● DevOps・アプリケーション開発 ● プラットフォームエンジニアリング 3 自己紹介 

© 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 を絡めた高度化がトレンドか 

© SoftBank Corp. All Rights Reserved. ● 情報が複数箇所に分散 ● 数十ほどあるサービスの一覧が整理されていない ● 一部自動化は進んでいるものの手動の定型業務がまだまだある ● 何が自動化されていてどこから申請すればいいか分からない ● 運用チームにて terminal ではなく GUI で完結する UI の需要 部門 (プロダクト開発) 5 当部門における課題 開発 チーム 運用 チーム デリバリ チーム 企画 チーム 

© SoftBank Corp. All Rights Reserved. 6 解決したかったこと 

© SoftBank Corp. All Rights Reserved. ● IDP 構築のためのフレームワーク (ほぼデファクト) ● Spotify発のOSS 7 Backstage という選択肢 

© SoftBank Corp. All Rights Reserved. 8 Backstage 導入で目指したもの 一般利用者 (企画/開発/ デリバリ/運用) コンテンツ提 供者 (主に開発) 見える化 サービス・チームの 技術ドキュメントと関係性 自動化 アカウント・権限・リソース申 請などの部門内手続き ◎ 各サービスの担当チームや関連のドキュメントがすぐに見つかる ◎ テンプレート＋セルフサービスで部門内の手続きがすぐに終わる ◎ 手続きは標準通り進められて履歴も残るため安心して進められる 閲覧 利用 情報 掲載 テンプレ 作成 Backstage 「見える化」と「自動化」のプラットフォーム 

© SoftBank Corp. All Rights Reserved. ● Group / Domain / System / Component / Resource を定義 ○ 事前に Team Topology を整理しており、それに従った組織構成 ○ 依存関係も定義 (階層・関連性) ○ ownerを明示 ○ 原則 1対1 でドキュメント (TechDocs) を紐づける 9 Catalog でのサービス・リソースの可視化 (1/2) 

© SoftBank Corp. All Rights Reserved. Backstage により各サービスの「技術仕様」へのアクセスが容易に Backstage 従来 ● 閲覧にはGitアカウントが必要 ● 開発者以外は心理的障壁あり ● 検索・目次の利便性にも難あり Azure SSO GitHub Login ● Azure SSO でログイン ● 各サービス資料を一箇所に集約 ● 検索性に優れている 利用者 Catalog でのサービス・リソースの可視化 (2/2) 10 

© SoftBank Corp. All Rights Reserved. ● Azure のアカウントの管理について課題 ○ 定型作業だが仕組みが非効率/属人的 → アカウント管理作業者の負担大 ○ 手動ゆえの作業品質 ○ リードタイムの大きさ、進捗状況が見えにくい 11 Azure のアカウント申請業務を Template 化 (1/2) After Before Backstage backlog GAS スプレッドシート Slack Google Chat Azure GitHub 承認者 

© 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 

© SoftBank Corp. All Rights Reserved. ● アカウントのライフサイクルにおける運用を含めた再設計が必要 ○ Backstage 側だけでは完結しなかった ● Azure の SSO 認証後、シームレスな GitHub アカウントとの連携のために ○ EntraID ユーザーのカスタム属性に GitHub ユーザーの ID を持たせて 取り込み時に変換が必要 　→ 今後対応予定 13 見えてきた課題① アカウント設計の課題 

© SoftBank Corp. All Rights Reserved. ● 各チーム独自運用のドキュメントサイトが存在 ● 構築中の Backstage では ○ Markdown + MkDocs ：標準対応 ○ Sphinx ：非対応 ● 第一段ではCatalog + link によるドキュメント紐付けで対応 14 見えてきた課題② 独自ドキュメントサイトとの連携 

© SoftBank Corp. All Rights Reserved. ● 方針 ○ 公開 Plugin で足りる部分はそのまま利用 ○ 足りない部分は Custom Action を作成 ■ 少人数での開発のため、作る・作らないの判断を適正化したい ● 利用頻度・メンテナンスコストをもとに判断 ■ Backstage の image とは別リポジトリ・別パッケージで管理 ● 困りどころ ○ 公開の Plugin は部品として充実しているが、追加開発なしで即 Template に組み込める状態ではないことが多い 15 見えてきた課題③ Plugin or Custom Action の判断 

© SoftBank Corp. All Rights Reserved. 16 もっと使われるポータルを目指して ● Backstage の利用度や導入効果の度合いを測るために 以下指標 (North Star Metrics) を設定 (※ 係数 10 は仮置き) 　TechDocs アクセス総数 + Catalog アクセス総数 + Software Template 実行数 × 10 NSMとは... 事業やプロダクトがユーザーに提供する「本質的な価値」を ひとつの数値で表したもの 例-1) Spotify : 「ユーザーの総再生時間」 例-2) Slack : 「週あたりのアクティブチーム数」 

© SoftBank Corp. All Rights Reserved. ● 「見える化」と「自動化」のプラットフォームの土台ができた ○ 入口の一本化 ○ GUI で完結する UI ○ サービスの可視化 ○ 定型業務の整理・移行による業務効率化 ○ もっと使われることを目指した指標の設定 ● 技術より組織整理・調整の難しさを感じた 17 まとめ