LASSIC Media らしくメディア
Backstageで開発者ポータル構築を外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Backstageは、サービス・ドキュメント・テンプレートを一元管理する開発者ポータル基盤です。
- ソフトウェアカタログ・ソフトウェアテンプレート・TechDocsという中核機能で、開発者の認知負荷を下げます。
- オープンソースのため自前ホスティングが前提となり、導入・運用体制の設計が成否を分けます。
サービス・ドキュメント・権限の分散が開発者の負荷を高める
Backstage 開発者ポータル IDP 構築 外注とは、Spotifyが主導開発しCNCF（Cloud Native Computing Foundation、クラウドネイティブ技術を推進する非営利団体）でホストされるオープンソースフレームワーク「Backstage」を用いて、社内の開発者向け窓口を一元化するポータル基盤を、外部パートナーへの委託で構築・整備する取り組みを指します*1。
マイクロサービス化やクラウド活用が進む組織では、サービスの数だけドキュメント・リポジトリ・CI/CD（継続的インテグレーション・継続的デリバリー、コードの統合とリリースを自動化する仕組み）・権限設定が分散しやすくなります。どのサービスを誰が所有しているか、最新の手順書がどこにあるかを探すだけで時間を要する状況は、開発者の認知負荷を高める要因です。
新しく加わったメンバーのオンボーディング（新規参画者が業務に必要な知識・権限を得るまでの一連の過程）でも、同じ課題が表面化します。サービス一覧・利用ツール・申請フローが複数の場所に分かれていると、独り立ちまでの立ち上がりが遅れがちです。こうした背景から、社内の情報とツールへの入り口を1か所にまとめる開発者ポータルへの関心が高まっています。
ここで整理しておきたいのが、本稿のテーマとの違いです。プラットフォームエンジニアという人材の確保・補完を外注する取り組みとは異なり、本稿はBackstageというソフトウェアを使ってポータルという「仕組み」そのものを構築する話であることに留意してください。人を増やす前に、まず土台となる基盤を整える発想です。
ソフトウェアカタログ・テンプレート・TechDocsが担う役割
Backstageは「an open source framework for building developer portals（開発者ポータルを構築するためのオープンソースフレームワーク）」と公式サイトで説明されています*1。Spotifyが自社の開発体験改善のために生み出した仕組みをオープンソース化したもので、2020年9月にCNCFへ寄贈され、2022年3月にサンドボックスからインキュベーティングプロジェクトへ昇格しました*2。
Backstageの中核機能は大きく3つに整理できます。第一が「ソフトウェアカタログ」です。公式ドキュメントでは「a centralized system that keeps track of ownership and metadata for all the software in your ecosystem（組織内のあらゆるソフトウェアの所有者情報とメタデータを一元管理する仕組み）」と定義されており、サービス・ウェブサイト・ライブラリ・データパイプラインなどが対象になります*3。各コンポーネントの情報はYAML形式のメタデータファイルとしてソースコード管理システムに保存し、通常のGitワークフローの中でオーナーチーム自身が更新する設計です*3。
第二が「ソフトウェアテンプレート」です。公式ドキュメントは「a tool that can help you create Components inside Backstage（Backstage内でコンポーネントの作成を支援するツール）」と説明しており、コードの雛形を読み込み、入力された変数をテンプレートに反映したうえで、GitHubやGitLabといった外部リポジトリへ公開する流れで動作します*4。標準化された雛形から新規プロジェクトを立ち上げる経路は、一般に「ゴールデンパス」と呼ばれる考え方に近い運用です。ただし「ゴールデンパス」という語自体はBackstage公式のSoftware Templatesページには登場せず、本稿では実務上の呼称として補足するにとどめます。
第三が「TechDocs」です。公式ドキュメントでは「docs like code」という考え方に基づき、「Engineers write their documentation in Markdown files which live together with their code（エンジニアがコードと同じ場所にMarkdownでドキュメントを書く）」仕組みと説明されています*5。最小限の設定でドキュメントサイトをBackstage上に自動生成し、カタログ上の各サービスページから該当ドキュメントを発見できるようにする点が特徴です*5。これら3機能に加え、プラグインによる機能拡張がBackstageの構成要素とされています*1。
こうした複数の中核機能を束ねて「開発者に対する社内向けの窓口」を1つにまとめる考え方は、一般に内部開発者プラットフォーム（Internal Developer Platform、IDP）と呼ばれます。Backstageはこの内部開発者プラットフォームを構築するための代表的なオープンソースの選択肢のひとつという位置づけです。カタログでサービスの現状を可視化し、テンプレートで新規開発の入り口を揃え、TechDocsで手順書の置き場所を統一する、という3つの機能が組み合わさることで、開発者が自分で情報にたどり着ける状態を目指します。
自前ホスティング・カタログの鮮度・組織の巻き込みが論点になる
Backstageを導入する際に避けて通れないのが、自前ホスティングの前提です。公式のセットアップ手順では「npx @backstage/create-app@latest」コマンドでアプリの雛形を生成したうえで、認証設定・データベース設定・本番環境へのデプロイを利用者自身が行う構成になっています*6。公式ドキュメントは初期状態について「This is not a production-ready installation（このままでは本番運用向けの状態ではない）」と明記しており、Backstage自体にマネージドサービス（提供元が運用まで担うサービス形態）は用意されていません*6。つまり、導入後の保守・アップデート・監視までを含めて、誰が運用責任を持つかを先に決めておく必要があります。
次に論点となるのがカタログの鮮度維持です。ソフトウェアカタログの情報はオーナーチームが通常のGitワークフローの中で更新する設計になっているため*3、更新を継続する仕組みがなければ登録情報と実態が乖離していきます。カタログに古い情報が残ったままでは、探す手間を減らすはずのポータルがかえって信頼されなくなるという逆効果を招きかねません。
3つめが組織の巻き込みです。Backstage公式の導入ガイドでは、Backstageの運用・保守やユーザー採用の推進、ソフトウェア開発のベストプラクティスをソフトウェアテンプレートに組み込む役割を担う中央チームの設置が推奨されています*7。具体的な普及施策として、ランチ＆ラーン形式の勉強会、新規プラグイン開発時の人員派遣、ハッカソン開催、利用状況メトリクスの週次共有などが例示されています*7。ポータルは作って終わりではなく、使われ続けるための継続的な働きかけが前提になっている点は、発注前に理解しておくべき事実です。
この3つの論点を軽視して構築だけを外部に委託すると、リリース後にカタログの更新が止まり、利用が広がらないまま形骸化するリスクがあります。内製でこれらすべてを賄うには、Backstageの技術知見に加え、社内調整・啓発活動を担う人員を継続的に確保する必要があり、体制構築だけでも相応の準備期間を要します。
要件定義・環境構築・運用設計を分担できる外注範囲
Backstageの外部委託を検討する際は、委託範囲を工程ごとに切り分けて整理すると発注の準備がしやすくなります。主な工程は、要件定義（どのサービスをカタログ化しどの部門を対象にするかの整理）、環境構築（認証基盤・データベース・デプロイ環境の設計と構築）、カタログ・テンプレートの初期整備（既存サービスのメタデータ登録とゴールデンパス用テンプレートの作成）、TechDocsの導入（既存ドキュメントのMarkdown化と反映）、そして運用設計（更新ルール・監視体制・普及施策の設計）です。
このうち環境構築とカタログ初期整備は、Backstage自体の技術仕様の理解と、既存システムの構成把握という2つの知識が同時に求められる工程です。内製で完結させる場合、Backstageのプラグイン開発・YAMLメタデータ設計・認証連携の知識に加え、自社の既存サービス全体を棚卸しできる人員が必要になり、規模によっては複数名での並行対応が求められます。専門知識が不足したまま進めると、カタログの設計を誤って後から作り直す手戻りが発生し、かえって導入期間が延びる可能性があります。
外部パートナーに依頼する場合と内製で進める場合の違いは、初期構築のスピードと、Backstage特有の設計ノウハウの有無に表れます。内製では自社ドメイン知識を活かしやすい一方、Backstageのバージョンアップ追従やプラグイン選定の勘所は経験によって差が出やすい領域です。外部パートナーに委託する場合は、要件定義から環境構築までを短期間で立ち上げやすくなる一方、運用フェーズでの巻き込み施策は社内の実行力に依存するため、構築後の運用設計をどちらが担うかを契約前に明確にしておくことが重要です。
まとめ：Backstage外注で確認すべき3つの軸
本稿では、Backstageを用いた開発者ポータル・内部開発者プラットフォーム構築を外注する際の要点を整理しました。要点を3つに集約すると次の通りです。第一に、Backstageはソフトウェアカタログ・ソフトウェアテンプレート・TechDocsという中核機能で、サービス・雛形・ドキュメントの分散を解消する仕組みです。第二に、オープンソースであるがゆえに自前ホスティングが前提となり、運用責任の所在を先に決める必要があります。第三に、カタログの鮮度維持と組織への浸透は構築後も続く取り組みであり、委託範囲に運用設計を含めるかどうかが成否を分けます。
よくある質問
Backstageの利用にライセンス費用はかかりますか。
Backstageはオープンソースソフトウェアとして提供されており、ソフトウェア自体のライセンス費用は発生しません。ただし、ホスティングするサーバーやデータベースの費用、構築・運用にあたる人員の工数は別途必要になります。自前で運用する前提のため、体制構築のコストを含めて検討することが大切です。
Backstage導入にはどの程度の期間がかかりますか。
対象サービスの数や既存ドキュメントの整備状況によって幅があり、公表された標準期間はありません。要件定義・環境構築・カタログ初期登録・TechDocs移行という工程を経るため、対象範囲を絞った小規模な導入から始め、段階的に対象を広げる進め方が実務上は取られやすい方法です。
既存のドキュメントツールからTechDocsへの移行は必須ですか。
必須ではありません。TechDocsはMarkdownでドキュメントをコードと同じ場所に置く「docs like code」の考え方に基づく機能であり*5、既存のドキュメントを段階的にMarkdown化しながら移行する進め方も可能です。全面移行を急ぐより、更新頻度の高いドキュメントから優先することが実務的です。
外注する場合、構築後の運用も任せられますか。
委託範囲として運用設計・保守を含めることは可能ですが、カタログの鮮度維持や社内への普及活動は社内の関与が欠かせません*7。構築のみを委託するのか、運用の一部まで含めるのかを契約前に切り分けて合意しておくことをおすすめします。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Backstage「What is Backstage?」（backstage.io、https://backstage.io/docs/overview/what-is-backstage/）
- *2 出典：CNCF「Backstage」プロジェクトページ（https://www.cncf.io/projects/backstage/）CNCF受け入れ2020年9月8日・インキュベーティング昇格2022年3月15日
- *3 出典：Backstage「Software Catalog」（https://backstage.io/docs/features/software-catalog/）
- *4 出典：Backstage「Software Templates」（https://backstage.io/docs/features/software-templates/）
- *5 出典：Backstage「TechDocs」（https://backstage.io/docs/features/techdocs/）
- *6 出典：Backstage「Getting Started」（https://backstage.io/docs/getting-started/）
- *7 出典：Backstage「Adopting Backstage」（https://backstage.io/docs/overview/adopting/）
