共創するソフトウェア開発

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

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

• https://twitter.com/turtle2005
• https://www.linkedin.com/in/hitoshikamezaki/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高速フローを実現する３つの柱 【（２）ツール】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

• https://www.cncf.io/

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

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

高速フローを実現する３つの柱 【（３）文化】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

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

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

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

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

• https://backstage.io/

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

• https://backstage.io/docs/overview/what-is-backstage/
• https://backstage.io/plugins/

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

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

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

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

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

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

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

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

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

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

最後に © AP Communications Co., Ltd.

最後に 弊社の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

• https://techblog.ap-com.co.jp/
• https://github.com/ap-communications/chocott-backstage
• https://www.ap-com.co.jp/cloudnative/
• https://www.ap-com.co.jp/platt/

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