---
title: 共創するソフトウェア開発
tags:  #backstage #platform engineering #team topologies #innersource  
author: [Hitoshi Kamezaki](https://www.docswell.com/user/turtle2005)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/Y76WL8ND7V.jpg?width=480
description: 「InnerSource, Platform Engineering, Team Topologiesで共創を加速する」と題し、ソフトウェア開発を組織的により効率的に、高速に進めるためのポイントを解説します。  2026年4月23日作成版
published: April 24, 26
canonical: https://www.docswell.com/s/turtle2005/Z7NG6W-2026-04-24-175734
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/Y76WL8ND7V.jpg)

「共創するソフトウェア開発」
〜 InnerSource, Platform Engineering, Team Topologiesで共創を加速する 〜
株式会社エーピーコミュニケーションズ
© AP Communications Co., Ltd.


# Page. 2

![Page Image](https://bcdn.docswell.com/page/G75M195874.jpg)

自己紹介
ACS事業部 PlaTTサービス室
室長
亀崎 仁志
SIer やモバイルアプリケーション開発の企業でインフラからアプリケーションまでを
カバーするフルスタックエンジニアとして様々な開発プロジェクトに参画。
2015年にエーピーコミュニケーションズ入社。Platform Engineering 領域の
サービス「PlaTT」の開発責任者として、Backstage の機能拡張などに取り組む。
@turtle2005
in/hitoshikamezaki
© AP Communications Co., Ltd.
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/9J2912NVER.jpg)

ACS事業部のミッション
Platform EngineeringやAIを活用し、
DevExの向上でお客様のDX内製化を推進する
私たちACS事業部はNeoSIerの新たなSIモデルとして、エンタープライズ企業のDX内製化を推進しております。
内製化推進のためのお客様開発組織のDexEx向上をミッションに、Platform Engineering、Microsoft
Azureの
プラットフォームやAI技術を活用しセルフサービス化されたSIを確立・提供し日本企業のデジタル化を加速さ
せて参ります。
© AP Communications Co., Ltd.
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/DEY4ZYPQJM.jpg)

開発の高速フローを実現する
３つの柱
© AP Communications Co., Ltd.


# Page. 5

![Page Image](https://bcdn.docswell.com/page/VJNY3P5278.jpg)

高速フローを実現する３つの柱
多くの組織が陥るDevOpsアンチパターン
なぜ組織がスケールすると開発速度は低下するか？
ツールを導入し、チームを増やしても開発速度低下の根本的な問題は解決しない。
●
アンチパターン１：スケールしない組織構造
特定のDevOps専門チームやクラウドチームがボトルネック化し、組織全体の
イノベーションを阻害する。彼らが知識を独占し、他のチームはチケットを
切って待つだけになる。
●
DevOps
専門
チーム
アンチパターン２：高すぎる認知負荷
開発チームがインフラ、セキュリティ、ビジネスロジック、新技術など、あま
りにも多くの責任を負わされている。結果としてコンテキストスイッチが増
え、疲弊し、本来の価値提供に集中できなくなる。
●
開発
チーム
アンチパターン３：ツール先行で「人」と「プロセス」を無視
遅い
デリバリー
最新ツールを導入すれば問題が解決すると考え、チーム間コミュニ
ケーションや組織構造の重要性を見過ごす。
© AP Communications Co., Ltd.
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/YE9P93YDJ3.jpg)

高速フローを実現する３つの柱
高速フローを実現する３つの柱
優れたエンジニアリング組織は、「構造」「ツール」「文化」という３つの要素を
意図的に設計し、統合することで実現される
高速な価値提供フローを実現するための３つの要素
●
●
●
構造（Structure） ：Team Topologies
ツール（Tools）
： Platform Engineering
文化（Culture）
：InnerSource
© AP Communications Co., Ltd.
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GE8D9M65ED.jpg)

高速フローを実現する３つの柱
高速フローを実現する３つの柱
（１）構造（Structure）
（２）ツール（Tools）
（３）文化（Culture）
：
：
：
Team Topologies
Platform Engineering
InnerSource
© AP Communications Co., Ltd.
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LELMW3937R.jpg)

高速フローを実現する３つの柱
【（１）構造】Team Topologies
チームの「認知負荷」を管理し、フローを最適化する
認知負荷 ： 人間の脳（ワーキングメモリ）にかかる情報処理の負担
1980年代にジョン・スウェラー氏によって提唱された理論、「人間の短期的記憶（ワーキングメモリ）には限界
がある」という前提に基づいたもの。
認知負荷タイプ
内容
最適化の方針
内在的負荷（Intrinsic）
学習対象そのものの複雑さに起因する負荷。
小さく
外在的負荷（Extraneous）
学習に無関係な負荷
無くす
学習関連負荷（Germane）
学習目標の達成のための認知活動により生じる負荷
ここにフォーカス
© AP Communications Co., Ltd.
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/4JMY9DZMJW.jpg)

高速フローを実現する３つの柱
【（１）構造】Team Topologies
チームの「認知負荷」を管理し、フローを最適化する
Team Topologies ： マシュー・スケルトン氏とマニュエル・パイス氏によって提唱された「ビジネスの変化に迅
速に対応するための組織設計とチーム間コミュニケーションのパターン」。組織をどう分割してどう連携させれ
ば開発スピードをおとさずにいられるか、についての方法論。
時間軸
Flow of Change
中核となる考え方
●
●
認知負荷の尊重
チームが一度に扱える複雑さには限界が
ある。この限界を超えると、生産性は劇
的に低下する
Stream-aligned team
Platform
team
フローへの集中
組織構造は、アイディアが顧客の価値に
変わるまでの速度（フロー）を最大化す
るために存在すべき
Enabling
team
Complicated subsystem
Team
© AP Communications Co., Ltd.
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/PJR9G46L79.jpg)

高速フローを実現する３つの柱
【（１）構造】Team Topologies
４つのチームタイプと３つのインタラクションモード
例：
© AP Communications Co., Ltd.
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/PEXQX2D6JX.jpg)

高速フローを実現する３つの柱
【（１）構造】Team Topologies
４つのチームタイプ
Team type
内容
Stream Aligned team
特定のビジネス価値（製品、機能など）の流れに沿って活動する。エンドツーエンドで責任を持つ主力
チーム。
Enabling team
特定の専門知識を持ち、Stream Aligned Teamが自律的に動けるよう支援・教育する。
Complicated-subsystem team
高度な、または特殊な専門知識が必要な部分を専門的に扱う。
Platform team
インフラや共通機能を整理し、他チームが「セルフサービス」で使える形で提供する。
チームタイプにより、そのチームがどういった役割を担うのか、どういった領域に集中しているのかが明確
になる。役割と領域を明確にすることで、取り扱うべき（学習関連）認知負荷が何であるかもクリアにな
る。
© AP Communications Co., Ltd.
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/3EK9WMXGED.jpg)

高速フローを実現する３つの柱
【（１）構造】Team Topologies
３つのインタラクションモード
Interaction mode
内容
Collaboration
2つのチームが密接に協力し、新しい発見や解決策を模索するモード。
X-as-a-Service
一方のチームが提供する機能やサービスを、もう一方が（過度な対話なしに）利用するモード。
Facilitation
一方のチームが、もう一方のチームのボトルネックを解消するために手助けするモード。
インタラクションモードを定めることで、チーム間の依存関係を適切なレベルに維持することができる。
過度なチーム間依存を防止し、価値提供フローのスピードを落とさないようにする。
© AP Communications Co., Ltd.
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/L73W1Y5575.jpg)

高速フローを実現する３つの柱
【（１）構造】Team Topologies
Team API
他のチームがそのチームとやり取りをするために必要な情報を公開・標準化したもの。
あらかじめ定義することで、誰にどうやって聞けばよいかやチーム間の責任範囲などが明確になり、
それぞれのチームの認知負荷を低減する。
APIとして定義するもの
内容
提供しているサービスと機能
そのチームが何を担当し、何に責任を持っているのか。
コミュニケーションチャネル
Slack等コミュニケーションツールのチャンネル名、定例会議の時間、緊急連絡先。
ドキュメント
利用ガイド、設計思想、FAQ、ロードマップ。
やりとりのルール
コードレビューの依頼方法、バグ報告の手順、オンボーディングの進め方。
© AP Communications Co., Ltd.
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/87DKX5DYJG.jpg)

高速フローを実現する３つの柱
高速フローを実現する３つの柱
（１）構造（Structure）
（２）ツール（Tools）
（３）文化（Culture）
：
：
：
Team Topologies
Platform Engineering
InnerSource
© AP Communications Co., Ltd.
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/VJPKPGX2E8.jpg)

高速フローを実現する３つの柱
【（２）ツール】Platform Engineering
開発者向けのセルフサービス基盤を提供し、複雑性を抽象化する。
開発者が価値提供に専念できる環境を整える。
その環境が内部開発者プラットフォーム（IDP)。
ポイント
●
認知負荷の低減
開発者がインフラの設定やセキュリティ、ネットワークなどの詳細をすべて理解す
る必要がないよう、必要な機能を抽象化し、シンプルなインターフェースを提供す
る。
●
セルフサービス機能
開発者がチケットを切ってインフラ担当者の作業を待つのではなく、ポータルなど
を通じて自分たちで必要なリソース（DB、サーバー等）を即座に払い出せるよう
にする。
●
Platform as a Product
社内開発者を「顧客」として扱い、彼らの真の課題を解決するプロダクトとして開
発・提供する。
●
内部開発者プラットフォーム（IDP）の構築
これらを実現するために構築される具体的なツール群や基盤を提供する。
© AP Communications Co., Ltd.
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/2EVV26LXEQ.jpg)

高速フローを実現する３つの柱
【（２）ツール】Platform Engineering
開発者向けのセルフサービス基盤を提供し、複雑性を抽象化する。
「Platform as a Product」という発想
成功するプラットフォームは、社内開発者を「顧客」として扱い、
彼らの真の課題を解決するプロダクトとして開発・提供される
重要なマインドセット
●
Thinnest Viable Platform(TVP) - 実用最小限のプラットフォーム
巨大で万能なプラットフォームを目指すのではなく、開発者の最も大きなペインを解決する最小限の機能
から始める。
●
デベロッパー・エクスペリエンス（DevEx）の重視
アンケートやフィードバックを通じて開発者のニーズを継続的に収集し、プラットフォームの使いやすさ
を改善し続ける。
●
強制ではなく「選択」されるプラットフォーム
プラットフォームの利用を強制するのではなく、開発者が「使いたい」と思う魅力的なプロダクトにする
ことで、自発的な採用を促す。
© AP Communications Co., Ltd.
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/57GLRNXREL.jpg)

高速フローを実現する３つの柱
【（２）ツール】Platform Engineering
代表的なPlatformのスコープ
主要な定義における「Platform」の範囲は以下の４層に集約される
© AP Communications Co., Ltd.
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/4EQYVQ8YJP.jpg)

高速フローを実現する３つの柱
【（２）ツール】Platform Engineering
Platformのスコープ
「Platform」とはなにか、は定義する組織によって異なる
一般的なスコープ
観点
CNCF
Gartner社
Team Topologies
主な定義
技術的な能力（Capabilities）
内部プロダクト
最小実行可能基盤（TVP）
プラットフォームの
範囲
インフラ〜セキュリティまでのフルス
タックなAPI
IDP、ツールチェーン、ゴールデンパス
（Paved Roads）
ツール ＋ API ＋ 知識 + サポート
最重視する目的
クラウドネイティブな運用効率化
開発者の生産性向上・認知負荷の低
減
チーム間の高速なフローの実現
CNCF（Cloud Native Computing Foundation）を含め、多くの定義では基本的に「インフラ領域」に限定したものではない。
その中でもTeam Topologiesの定義はもっとも広く、非IT（例えば契約の自動チェックなど法務支援）などの領域もPlatformで提供する
サービスの一部と考えられる定義となっている。
３つの中ではGartner社の定義がもっとも一般的な認識となっている。
「Platform」とは、それぞれの組織が自組織に合ったPlatformのスコープを定め、組織内で合意すればよい。
© AP Communications Co., Ltd.
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/KJ4WMN2Z71.jpg)

高速フローを実現する３つの柱
【（２）ツール】Platform Engineering
開発者向けのセルフサービス基盤を提供し、複雑性を抽象化する。
組織が定めたスコープに沿って
（専任・兼任を問わず）１つ以上のチームが
認知負荷の軽減し開発者体験を向上するための成果物を提供する
© AP Communications Co., Ltd.
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/LE1Y85MD7G.jpg)

高速フローを実現する３つの柱
高速フローを実現する３つの柱
（１）構造（Structure）
（２）ツール（Tools）
（３）文化（Culture）
：
：
：
Team Topologies
Platform Engineering
InnerSource
© AP Communications Co., Ltd.
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/GEWGZ538J2.jpg)

高速フローを実現する３つの柱
【（３）文化】InnerSource
チームの境界を越えた協業を促進し、ボトルネックを解消する
専任Platform teamだけでは課題を解決できない。
Platform
team X
Platform
teamY
課題領域X
課題領域Y
課題領域a
課題領域b
課題領域c
課題領域d
組織内では
すでに解決策が
存在しているものも
Team B
Platform teamが取り組める
課題領域にも限りがある
InnerSource Projectを仮想Platform team化し、より広範囲の課題を解決する
© AP Communications Co., Ltd.
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/47ZL1NV9J3.jpg)

高速フローを実現する３つの柱
【（３）文化】InnerSource
チームの境界を越えた協業を促進し、ボトルネックを解消する
InnerSourceは、プラットフォームチームがボトルネックになるのを防ぎ、
組織全体の知識と貢献を活用するための「安全弁」である。
InnerSourceとは
オープンソース開発のベストプラクティスを、組織の内部に適用する手法。
Team A
Pull Request
(貢献）
Team B
なぜ重要なのか
●
●
●
ボトルネックの解消
プラットフォームに機能が足りないとき、利用側のチームがチケットを起票して待
つのではなく、自らコードを修正して貢献できる。
知識のサイロ化を防ぐ
コードと意思決定プロセスを透明にすることで、他のチームがどのように作ってい
るかを学び、再利用を促進する。
オーナーシップと貢献意欲の向上
開発者が組織全体のプロダクトに貢献できる機会を提供し、エンゲージメントを高
める。
共有
リポジトリ
Team C
© AP Communications Co., Ltd.
Pull Request
(貢献）
Team D
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/YJ6WL85DJV.jpg)

「開発者ポータル」による統合
© AP Communications Co., Ltd.


# Page. 24

![Page Image](https://bcdn.docswell.com/page/GJ5M19Y8J4.jpg)

「ポータル」による統合
高速フローを支える開発者ポータル
「構造」「ツール」「文化」の３つの柱を統合し、情報集約を担うのが「開発者ポータル」。
ポータルを通じて様々な関係者に環境・情報・コミュニケーション手段を提供することで、
「共創」を促す「場」としての機能を担う。
© AP Communications Co., Ltd.
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/9E2912GV7R.jpg)

「ポータル」による統合
高速フローを支える開発者ポータル
Backstage (https://backstage.io/)
全世界 の 3,000以上の組織で使われる開発者ポータルのフレームワーク。
音楽配信サービス世界最大手のSpotifyが自社サービス開発用に自社開発し、2020年にOSSとして公開。
現在はCNCFに寄贈されている。
© AP Communications Co., Ltd.
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/D7Y4ZYVQEM.jpg)

「ポータル」による統合
Backstageの特徴
統合的なUI、カタログ、テンプレート、システムの情報集約、
150 以上の超えるモダンなDevOpsツール連携プラグインが存在
ドキュメント情報の集約提供 引用：What is Backstage
引用：Backstage Plugin Marketplace
© AP Communications Co., Ltd.
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/VENY3PM2J8.jpg)

「ポータル」による統合
Backstageの特徴
© AP Communications Co., Ltd.
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/Y79P93NDE3.jpg)

「共創の場」で必要となるもの
© AP Communications Co., Ltd.


# Page. 29

![Page Image](https://bcdn.docswell.com/page/G78D9MK57D.jpg)

「共創」の場で必要となるもの
「共創の場」としての開発者ポータル
「共創の場」として提供される機能概要
© AP Communications Co., Ltd.
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/L7LMW3Z3JR.jpg)

「共創」の場で必要となるもの
InnerSourceのための開発者ポータル
InnerSourceを促進する開発者ポータル機能
カテゴリ
具体的な項目
見つける
検索機能とソフトウェア・カタログで、必要な情報・プロジェクトを見つける。
理解する
TechDocs等を用い、InnerSourceプロジェクトの使い方や貢献ルール等をより深く理解する。
活用する
GoldenPath（推奨する設定やコード）を組み込んだソフトウェアテンプレートを利用してセルフ
サービスでプロジェクトの内容を活用する。
貢献する
公開されたTeam APIに沿って、プロジェクトに貢献できる。
© AP Communications Co., Ltd.
30


# Page. 31

![Page Image](https://bcdn.docswell.com/page/4EMY9DVMEW.jpg)

「共創」の場で必要となるもの
セルフサービス実現のための開発者ポータル
Platform Engineeringにおけるセルフサービス
カテゴリ
具体的な項目
スキャッフォールディング
ボイラーコード生成、CI/CDや監視設定など整った状態でリポジトリ作成
プロビジョニング
クラウドリソースの払い出し
標準コンフィグレーション設定
あらかじめ用意された標準設定の適用
アクセス権限管理
一時的な管理者権限の申請、APIキーの発行
申請・登録
その他一般的な申請
© AP Communications Co., Ltd.
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/PER9G42LJ9.jpg)

「共創」の場で必要となるもの
Team APIとしての開発者ポータル
Team TopologiesにおけるTeam APIを構成する主な要素
カテゴリ
具体的な項目
基本情報
チーム名、ミッション（フォーカス）、チームタイプ
成果物や技術
所有するコードリポジトリ、APIエンドポイント、ライブラリ、UIコンポーネント
ドキュメント
ハウツーガイド、ロードマップ
運用ルール
バージョニング戦略（SemVerなど）、SLE（サービスレベル期待値）
コミュニケーションルール
チャットツールチャンネル、デイリースクラム・オフィスアワー等の時間
連携状況
現在連携しているチーム、相互作用モード（Collaboration, XaaS, Facilitating）
© AP Communications Co., Ltd.
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/P7XQX2P6EX.jpg)

「共創」の場で必要となるもの
オンボーディングとしての開発者ポータル
オンボーディングの現場で起きている課題と解決
© AP Communications Co., Ltd.
33


# Page. 34

![Page Image](https://bcdn.docswell.com/page/37K9WMDG7D.jpg)

「共創」の場で必要となるもの
オンボーディングフォームとしての開発者ポータル
チームオンボーディングをセルフサービス
カテゴリ
具体的な項目
コンテンツ
座学に必要な学習コンテンツ
スキャッフォールディング
学習に必要なサンドボックスの作成
進捗トラッキング
終了したコンテンツや、進捗状況を確認・表示
スタック解消支援
進捗状況等からスタックしているところを把握し、学習を支援
質疑応答
AIチャット、有識者による直接対話
その他必要となること
コンテンツ作成・更新支援：コンテンツそのものを作成するというチームの認知負荷を低減
© AP Communications Co., Ltd.
34


# Page. 35

![Page Image](https://bcdn.docswell.com/page/LJ3W1YR5J5.jpg)

「共創」の場で必要となるもの
技術羅針盤としての開発者ポータル
Tech Radarを用いた標準化の実現
Tech Radar・・ThoughtWorks社が提唱した「テクノロジー・レーダー」
組織が採用・評価・放棄すべき技術を視覚的にマッピングするためのフレームワーク。単
なるリストではなく、技術選定に「ガードレール」を設けるための戦略的対話ツールで以
下のように表現する
４つのカテゴリ：技術を「言語」「フレームワーク」「インフラ」「プロセス」などのカ
テゴリに分類。（内容はカスタマイズ可能）
４つのリング：技術の採用成熟度を同心円状に表現。
開発者ポータルのソフトウェアカタログ、ソフトウェアテンプレートやTechDocsと組み合
わせることで抽象的なガイドラインを具体的な開発者体験への変換できる。
© AP Communications Co., Ltd.
35


# Page. 36

![Page Image](https://bcdn.docswell.com/page/8JDKX5YYEG.jpg)

「ポータル」による統合
高速フローを支える開発者ポータル
開発者ポータルBackstageを活用することで共創を活性化し、高速フローを実現することができます。
© AP Communications Co., Ltd.
36


# Page. 37

![Page Image](https://bcdn.docswell.com/page/VEPKPG6278.jpg)

最後に
© AP Communications Co., Ltd.


# Page. 38

![Page Image](https://bcdn.docswell.com/page/27VV263X7Q.jpg)

最後に
弊社のPlatform Engineeringの取り組み
AP Communicationsでは、Platform Engineeringや開発者ポータルについての情報発信やサービス提供を
しております。ぜひご活用ください。
●
●
●
APC 技術ブログ (https://techblog.ap-com.co.jp/)
ちょこっとBackstage （https://github.com/ap-communications/chocott-backstage）
弊社サービス
○
クラウドネイティブ内製化支援サービス （https://www.ap-com.co.jp/cloudnative/）
○
開発者ポータル "PlaTT"シリーズ （https://www.ap-com.co.jp/platt/）
© AP Communications Co., Ltd.
38


# Page. 39

![Page Image](https://bcdn.docswell.com/page/5JGLRN3R7L.jpg)

最後に
ありがとうございました
© AP Communications Co., Ltd.
39