認知負荷削減の要はセルフサービス型のプラットフォーム
PTが具体的になにを提供していくのか見ていきます。SATには顧客価値を上げるためのコア業務とも言えるビジネスロジックの開発に集中してもらう必要があります。そのため、PTはビジネスロジックに関係しないノンコアの業務（認知負荷の原因）を代替させるプラットフォームを提供します。
具体的には、インフラサービス、データサービス、メッセージングサービス、開発ツール、API、ライブラリ、テンプレート、オブザーバビリティなどのシステム関連のリソースや、標準、ドキュメント、ノウハウ、サポート、業務プロセスの整備[1]なども含まれます。
[1] チームトポロジーが定義するプラットフォームはCNCFが定義するPlatformより広義です
ノンコア業務を担う際に、都度依頼して待ち時間が発生したり、使い方で戸惑ってしまったりしていては速いフローは実現できません。その為に、プラットフォームは開発者にとってのユーザ体験（DevEx）の良いセルフサービス型で提供されることが成功の鍵になってきます。これらは「内部開発者プラットフォーム（Internal Developer Platform）」と呼ばれます。
またDevExを高め、認知負荷を下げるために開発者にとってわかりやすいインタフェースで一元的に提供されることも鍵となるため、Webポータルが活用されます。これらは「内部開発者ポータル（Internal Developer Portal）」と呼ばれます。
前者については連載第4回、後者については連載第5回でより詳細に説明予定ですのでご期待ください。
開発者を顧客として考える「Platform as a Product」
これらのプラットフォームを提供するために、SATとPTは3つの内どの連携を取るべきでしょうか？ 基本的に「X-as-a-Service」が利用されます。これらの連携方法を活用することで第2回で言及された「開発者が欲しいものと全然マッチしていなかった」「運用されずに失敗する」などのアンチパターンに対する対策を行います。
PTはプラットフォームのユーザである複数のSATを顧客として扱い、コミュニケーションを重視してニーズを把握します。そしてPTはプラットフォームをプロダクトのように見立て、把握したニーズに優先度をつけ、マイルストーンを提示しながら、「ちょうどよい大きさ」を保ちながら、継続的な運用と拡張を行います。これが「Platform as a Product」とも言われる考えで、プラットフォーム作りの成功の最重要の鍵と言えます。
全社横断の共通基盤の構築プロジェクトの際など、社内の声の大きい方の鶴の一声で新しい技術が選ばれた結果、使われないプラットフォームができあがるのを聞いたことがありませんでしょうか？ これはまさにPTが顧客のニーズを把握せずプラットフォームを提供した結果に他なりません。
PTが利用するプロダクトマネジメントの手法については連載第6回で詳細を説明予定ですのでご期待ください。
SATとPTの連携ではもう一つ「コラボレーション」という連携方法が選択されることもあります。これは立ち上げ間もないSATやプラットフォームに新たな技術やツールを導入する際など価値を探索的に発見する場合に用いられます。その際、両チームは責任を共有し活動しますが、その価値が発見された後は、徐々に「X-as-a-Service」に移行し、オーナーシップを分割していくのが良いでしょう。
