みなさんこんにちは。エーピーコミュニケーションズ ACS事業部 亀崎です。
多分これが2025年最後の投稿になると思います。 ご存知のように私は 開発者ポータル Backstage 推しで、このブログでも多くの記事を投稿してまいりました。
そうした中で気づいたのは Backstage をより活用するためには Platform Engineering 、 Team Topologies、 InnerSourceといった 要素との連携が重要であるということです。それはどういうことか。2025年の最後にこれら4つの統合について考えたいと思います。
Platform Engineering 成功の鍵：Team Topologies, InnerSource, そして Backstage による統合戦略
近年、ソフトウェア開発の現場では「開発者の認知負荷」を下げ、 デリバリー速度を向上させるための手法（仕組み）として Platform Engineering が 注目を集めています。
しかし、単に便利なツールを導入するだけでは、真の成果は得られません。 Platform Engineering (仕組み) を成功させるには、 Team Topologies（組織）、InnerSource（文化）、 そしてそれらを具現化する Backstage（技術） のそれぞれを密接に連携させることが不可欠です。
今回は、これら4つの要素がどのように関係し、相乗効果を生み出すのかを解説します。
三位一体の戦略
まずは抽象的な概念部分の主要な3つの要素、 Platform Engineering、Team Topologies、InnerSourceについてみていきましょう。
Platform Engineering を実践する際、私たちは「仕組み・組織・文化」の 3つの壁にぶつかります。 これらを解決するのが、さきほど挙げた3つ要素の組み合わせです。
1 Team Topologies (組織)：組織の形と責任を定義
Team Topologies は、チームの境界線とインタラクション（相互作用）を 設計するためのフレームワークで、以下の点を実現するよう組織と責任を定義します。
認知負荷の削減: プラットフォームチームは、開発チーム（Stream-alignedチーム）が 負うべき複雑なインフラ運用の負荷を肩代わりします。
X-as-a-Service: プラットフォームは「依頼して作ってもらうもの」ではなく、 サービスとして提供され、開発者がセルフサービスで利用できる状態を目指します。
2 InnerSource (文化)：ボトルネックを解消する文化
プラットフォームチームが優秀であればあるほど、すべての要望がそこに集中し、 チームが「中央集権的なボトルネック」化するリスクがあります。
そうしたリスクを回避するために以下のような点を考慮する必要があります。
共同改善: 開発チームがプラットフォームに新機能を必要とした際、 プラットフォームチームの着手を待つのではなく、自らコードを修正しプルリクエストを 送れるようにします。
サイロ化の防止: 組織全体で知見を共有し、車輪の再発明を防ぐオープンな文化を醸成します。
3 Platform Engineering (仕組み)：技術的な土台 IDP
これらを技術的に支えるのが、Internal Developer Platform (IDP) です。
そのゴールは「開発者がセルフサービスで、素早く、安全に本番環境へデプロイできる」状態を 作ることです。
Backstage：概念を現実に変える「ハブ」
これらの抽象的な概念を、日々の業務で触れる「実体」へと落とし込むのが、 開発者ポータルである Backstage です。Backstage は、Platform Engineering の 中心的なインターフェースとして機能します。
Platform Engineering の「顔」としての機能
Backstage は Internal Developer Platform(IDP) のフロントエンドです。
Software Templates: 開発者が新しいマイクロサービスを立ち上げる際、 Backstage 上のテンプレートを選ぶだけで、社内標準に準拠したリポジトリ、CI/CD パイプライン、 クラウド環境が数分で自動生成されます。
Team Topologies の「境界線」を可視化する機能
Backstage の Software Catalog は、システムの所有権を明確にします。
Ownership: 「このサービスのオーナーは誰か？」「どのチームが管理しているか？」が 常に表示されます。これにより、何かあった際の連絡先を探し回る無駄な時間が削減され、 チーム間の境界線が実体化します。
InnerSource の「マーケットプレイス」としての機能
Backstage で提供される様々な情報は、社内の資産を発見しやすくします。
Discoverability: 誰がどんな API を公開しているか、どんなライブラリがあるかを 検索可能にします。
TechDocs: 「コードの近くにドキュメントを書けば、自動でポータルに反映される」 仕組みを提供し、外部チームがそのプロジェクトを理解し、コントリビュートするハードルを 劇的に下げます。
シナジーが生み出す理想的なサイクル
Backstage を中心にこれらを統合すると、以下のようなポジティブなサイクルが回ります。
定義 (Team Topologies): チームの役割と境界を決め、認知負荷のターゲットを明確にします。
構築 (Platform Engineering): 開発者が楽になるためのセルフサービス基盤を Backstage 上に構築します。
公開 (InnerSource): 各チームが作ったコンポーネントや知見を Backstage に登録し、 誰でも再利用・改善できるようにします。
改善 (InnerSource): プラットフォーム自体も InnerSource 形式で開放し、 ユーザー（開発者）からのフィードバックとコントリビューションで進化を実現します。
まとめ：ツール導入の先にあるもの
Platform Engineering の本質は、単なるツールの導入ではなく 「開発者が価値提供に集中できる環境をデザインすること」にあります。
Team Topologies で組織を整え、 InnerSource で協力の作法を決め、 Platform Engineering で仕組みを作り、 Backstage でそれらを一つの体験として統合する。
この 4要素が揃ったとき、組織のデリバリー能力は最大化されます。しかし全部を一気に実現するのも大変です。 皆さんの組織でも、まずは Backstage で「システムの所有権を可視化する」ところから始めてみてはいかがでしょうか。
PlaTTのご紹介
Platform Engineering、Team Topologies、InnerSourceの三位一体の環境を統合し、活用するためのOSS Backstageですが それを活用するためには様々な知識も必要になります。今回の内容もそうしたものを表すものでもあると思います。
またBackstageのアップデート等の運用コストはPlatform Teamに対する認知負荷を高めてしまう要因でもあります。 そうした課題を解消するのが、私たちが提供するBackstageのManaged Service「PlaTT」です。
弊社では様々な検証も行っており、皆さんの「面倒」を解消することができると考えています。
ぜひ皆さんのお手伝いをさせてください。よろしくお願いいたします。
