※本記事は、AWS re:Invent 2024で行われた「Platform engineers as product managers: Boost your team's productivity (DOP102)」セッションの内容を基に作成されています。このセッションはAWSパートナーであるCortexによって提供されました。セッションの詳細情報はAWS re:Inventの公式サイト（https://go.aws/reinvent ）でご覧いただけます。

本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご覧いただくことをお勧めいたします。

登壇者紹介： Ganesh Datta氏は、内部開発者ポータルを提供するCortexの共同創業者兼CTOです。プラットフォームエンジニアリングとプロダクトマネジメントの融合による組織変革に深い知見を持ち、エンジニアリングエクセレンスを実現するためのプラットフォーム構築に豊富な経験を有しています。プラットフォームエンジニアリングを単なる技術的な取り組みではなく、組織全体の生産性と成功を導くための戦略的な取り組みとして捉え、その実現に向けて先進的な取り組みを行っています。

1. イントロダクション

1.1 プラットフォームエンジニアリング概要

プラットフォームエンジニアリングは、タイトルや役割としては比較的新しいものですが、その概念自体は決して新しいものではありません。私たちは長年これらのアイデアを学び、実践してきました。今回は特に、プロダクトマネジメントのマインドセットに焦点を当てて、なぜプラットフォームエンジニアリングにプロダクトマネジメントのマインドセットが必要なのかについてお話ししたいと思います。

私はCortexの共同創業者でCTOのGaneshです。Cortexは内部開発者ポータルを提供していますが、私はこれを「エンジニアリングエクセレンスのためのプラットフォーム」として考えています。つまり、単なるポータルサイトではなく、組織全体のエンジニアリング品質を向上させるための基盤として位置づけています。

このような位置づけは、プラットフォームエンジニアリングの本質的な役割を反映しています。プラットフォームエンジニアリングは、個々の開発者やチームの生産性を向上させるだけでなく、組織全体のエンジニアリング品質を向上させる重要な役割を担っています。そのためには、単なる技術的な実装だけでなく、プロダクトマネジメントの視点を持って、組織のニーズを理解し、適切なソリューションを提供していく必要があります。

1.2 プロダクトマネジメントの定義と目的

プロダクトマネジメントの根本的な目的は、顧客のニーズを解決することです。プロダクトマネジャーとして、私たちは内部顧客であれ外部顧客であれ、彼らのニーズを理解し解決することに焦点を当てています。ただし、これは単にニーズを解決するだけではなく、重要なビジネス成果の達成を目指して行われなければなりません。

例えば、コンシューマーアプリのプロダクトマネジャーであれば、月間アクティブユーザー（MAU）や日間アクティブユーザー（DAU）、収益などの主要な指標を重視することになります。これらの指標は、プロダクトが実際にビジネスにとって価値を生み出しているかを示す重要な指標となります。

プロダクトマネジメントの本質は、「どのように顧客のニーズを解決し、それを通じて望ましいビジネス成果を生み出すか」というプロセスにあります。顧客のニーズを理解し、それをビジネスの主要指標（ノーススターメトリクス）に結びつけることで、組織にとって真に価値のあるソリューションを提供することができます。これは内部向けのプラットフォーム開発であっても、外部向けの製品開発であっても変わりません。

2. ビジネス成果の3つの柱

2.1 イノベーションとTime to Market

エンジニアリングの観点から、私たちが重視すべきビジネス成果について説明したいと思います。まず最初に重要なのが、イノベーションとTime to Marketです。これは「どのように私たちはより多くのものを、より速くリリースできるか」という課題です。単にスピードを上げるだけでなく、競争力を維持し、市場での優位性を失わないようにすることが重要です。

この分野では、どれだけ素早く新しい機能や製品を市場に投入できるかが鍵となります。競争の激しい市場において、私たちは革新的な機能を迅速に提供し続ける必要があります。これは単なる開発速度の問題ではなく、市場での競争優位性を維持するための戦略的な要件です。

イノベーションとTime to Marketは、他のビジネス成果とも密接に関連しています。例えば、品質を維持しながら開発速度を上げることで、顧客エクスペリエンスを向上させることができます。また、効率的な開発プロセスを確立することで、コストを抑えながらも革新的な機能を提供することが可能になります。このように、イノベーションとTime to Marketは、組織の競争力を維持するための重要な要素となっています。

2.2 品質とカスタマーエクスペリエンス

品質とカスタマーエクスペリエンスは、ほとんどの組織にとって重要な成果指標です。特に金融機関やミッションクリティカルなアプリケーションを運用している組織では、1分のダウンタイムが数百万ドルものコストを生み出す可能性があります。

このような環境では、高いSLAを維持することが絶対的な要件となります。また、信頼性の確保は単なる技術的な課題ではなく、ビジネスの継続性と顧客満足度に直結する重要な要素です。

このビジネス成果は他の成果とも密接に関連しています。例えば、信頼性に投資することで、カスタマーエクスペリエンスを向上させるだけでなく、市場投入までの時間を短縮することにもつながります。なぜなら、バグの修正に費やす時間を削減できるからです。このように、品質と顧客体験の向上は、他のビジネス目標の達成にも貢献する重要な要素となっています。

2.3 コストと効率性

特に今日の環境において、コストと効率性は最重要課題となっています。これは必ずしも直接的に顧客ニーズに応えるものではありませんが、ビジネスにとって重要な指標の一つとなっています。多くの組織がこの北極星指標（ノーススターメトリクス）として、コストと効率性を重視しています。

これらの成果指標は相互に排他的なものではありません。むしろ、これらは密接に関連しています。例えば、信頼性への投資は、カスタマーエクスペリエンスを向上させるだけでなく、市場投入までの時間を短縮することにもつながります。バグの修正に費やす時間が減少するためです。また、信頼性の向上は長期的なコスト削減にもつながります。

このように、コストと効率性は単独の指標ではなく、他のビジネス成果と組み合わさることで、より大きな価値を生み出すことができます。そのため、コストと効率性の改善を目指す際は、他の成果指標とのバランスを常に考慮する必要があります。

3. エンジニアリングエクセレンス

3.1 オーナーシップとアカウンタビリティ

エンジニアリングエクセレンスは幅広いトピックですが、各組織が最高レベルで運営するためにどのように考えるべきかを説明したいと思います。エンジニアリングエクセレンスの最も基本的な要素は、オーナーシップとアカウンタビリティです。

これは単純に聞こえるかもしれませんが、非常に重要です。なぜなら、誰が何を所有し、誰が何に対して責任を持つのかを明確にしない限り、私たちが定義するベストプラクティスや推進する取り組みは、ただの空虚な掛け声になってしまうからです。アカウンタビリティが不明確な場合、ベストプラクティスを定義し、イニシアチブを推進しても、誰も責任を持って実行しないため、私たちは虚空に向かって叫んでいるようなものです。

そのため、エンジニアリングエクセレンスを追求する際の第一歩は、必ずオーナーシップとアカウンタビリティの確立から始めます。これは組織の成熟度に応じて、各分野の専門チームに分割されていくことになりますが、まずは誰が何に対して責任を持つのかを明確にすることが、あらゆる取り組みの基盤となります。

3.2 信頼性とオペレーショナルレディネス

エンジニアリングエクセレンスの重要な要素として、信頼性とオペレーショナルレディネスがあります。組織の成熟度が高まるにつれて、この分野はSREチームが担当するようになります。SREチームは、サービスの信頼性と運用準備態勢の確保を専門とし、組織全体の信頼性向上を推進します。

時間の経過とともに、組織の成熟度が上がると、エンジニアリングエクセレンスの各側面が専門チームに分かれていきます。例えば、SREチームはサービスの信頼性に、セキュリティチームはセキュリティとコンプライアンスに、クラウドインフラチームは標準化とガードレールに焦点を当てるようになります。

これらのチームがそれぞれの専門分野で、組織全体のエンジニアリングエクセレンスを向上させる取り組みを行います。例えば、SREチームは信頼性に関するベストプラクティスを定義し、それを組織全体に展開していきます。このように、各専門チームが自身の領域で責任を持ち、組織全体のエンジニアリング品質を高めていくのです。

この体制は、後述する「Platform-as-a-Product」の考え方とも密接に関連しており、各専門チームが提供するサービスやツールは、プラットフォームの重要な構成要素となります。

3.3 セキュリティとコンプライアンス

組織の成熟とともに、セキュリティとコンプライアンスは専門のセキュリティチームが担当するようになります。セキュリティチームは重要な役割を果たしますが、その役割は単にセキュリティを監視し制限を設けることだけではありません。

セキュリティチームの役割は、組織全体のセキュリティとコンプライアンスの要件を定義し、それらを効果的に実装することです。しかし、これは開発者の生産性を妨げることなく実現される必要があります。そのため、セキュリティチームは他の専門チーム、特にプラットフォームチームと密接に協力して、セキュリティ要件を自動化し、開発プロセスに組み込んでいきます。

オートメーションとセルフサービスの観点から、セキュリティ要件の組み込みは非常に重要です。例えば、データベースへのアクセス制御や認証情報の管理などを、セキュアでありながらも開発者が簡単に利用できる形で提供する必要があります。これにより、セキュリティチームはボトルネックではなく、むしろ開発を促進する存在となることができます。

この分野での成功は、後ほど詳しく説明するステークホルダー協働の事例でも触れますが、セキュリティチームがプラットフォームチームと協力して、セキュリティ要件を開発者フレンドリーな形で提供できるかどうかにかかっています。

3.4 標準化とガードレール

組織の成熟度が高まるにつれて、標準化とガードレールの分野は、プラットフォームチームやクラウドインフラチームが担当するようになります。これらのチームは、組織全体の標準化とベストプラクティスを確立し、維持する重要な役割を担います。

プラットフォームチームは、開発者が効率的に作業できるように標準化されたツールとプロセスを提供します。これは単なる制約ではなく、開発者の生産性を向上させるためのガイドラインとして機能します。例えば、新しいサービスを立ち上げる際のゴールデンパスを提供することで、開発者は最初から適切な設定とベストプラクティスに従った開発を行うことができます。

クラウドインフラチームとの連携も重要です。彼らは組織のクラウドインフラストラクチャ全体を管理し、スケーラビリティとセキュリティを確保する責任があります。プラットフォームチームは、クラウドインフラチームと協力して、これらの要件を開発者フレンドリーな形で提供する必要があります。

このように、標準化とガードレールは、組織全体のエンジニアリングエクセレンスを支える重要な柱となっています。これらは制約としてではなく、むしろ開発者の生産性を向上させ、品質を確保するための支援として機能するべきです。そのため、後述するPlatform-as-a-Productの考え方に基づいて、これらの機能を提供していくことが重要です。

4. プラットフォームエンジニアリングの3つの実践

4.1 開発者エクスペリエンス

プラットフォームエンジニアリングは、3つの重要な実践の交差点に位置しています。名称自体は比較的新しいものですが、これらの実践は長年にわたって存在してきました。その中でも開発者エクスペリエンスは、私たちが重視する取り組みの一つです。

開発者エクスペリエンスとは、私たちが重要だと考える施策を、開発者にとって優れた体験として提供することです。これは単にツールを提供するだけではなく、開発者が効率的に作業を行い、組織の目標を達成できるような環境を整えることを意味します。

特に重要なのは、開発者が業務を遂行する上で必要なツールやプロセスを、使いやすい形で提供することです。これには、開発環境のセットアップ、デプロイメントプロセス、モニタリングツールなど、開発のライフサイクル全体をカバーする必要があります。

また、開発者からのフィードバックを継続的に収集し、それを基に改善を行うことも重要です。フィードバックループを確立することで、提供するツールやプロセスが実際の開発者のニーズに合致しているかを確認し、必要に応じて調整を行うことができます。このような継続的な改善サイクルにより、開発者の生産性を持続的に向上させることが可能になります。

4.2 プロダクトマネジメントマインドセット

プラットフォームエンジニアリングの実践における2つ目の重要な要素は、プロダクトマネジメントのマインドセットです。私たちには内部顧客がおり、その内部顧客のために製品を構築する必要があります。このマインドセットは、組織全体の課題を解決するための取り組みを進める上で不可欠です。

内部顧客のニーズを理解することは、プラットフォーム構築の出発点となります。プラットフォームエンジニアとして、私たちは組織の目標達成を支援するためのソリューションを提供する責任があります。これは、単なる技術的な問題解決ではなく、ビジネス価値の創出につながる機能やサービスの提供を意味します。

価値提供の優先順位付けは、限られたリソースを最大限に活用するために重要です。組織が直面している課題や摩擦ポイントを特定し、それらの解決がどのようなビジネス成果につながるのかを見極めなければなりません。例えば、Time to Marketの改善が重要な課題であれば、その障害となっている要因を特定し、それらを解決するための機能開発に優先的にリソースを割り当てます。

継続的な改善サイクルの確立も重要です。プラットフォームの価値は、それが実際にユーザーのニーズを満たし、組織の目標達成に貢献できているかどうかで測られます。そのため、常にフィードバックを収集し、それに基づいて改善を重ねていく必要があります。これは後述するDevOpsマインドセットとも密接に関連し、技術的な実装と価値提供の両面から継続的な改善を進めていくことが重要です。

4.3 DevOpsマインドセット

プラットフォームエンジニアリングの3つ目の実践として、DevOpsマインドセットがあります。これは、プラットフォームエンジニアリングの技術的な側面を支える重要な要素です。プラットフォームの機能を実現するためには、自動化やツール開発、継続的なデリバリーの仕組みが不可欠です。

DevOpsマインドセットは、従来からプラットフォームエンジニアリングの技術的な基盤として存在してきました。私たちは自動化とツーリングを通じて、組織全体のエンジニアリング効率を向上させることを目指しています。これには、開発環境の構築から、デプロイメントパイプライン、モニタリング、そしてインフラストラクチャの管理まで、幅広い領域が含まれます。

このマインドセットは、開発者エクスペリエンスとプロダクトマネジメントのマインドセットと組み合わさることで、より大きな価値を生み出します。例えば、自動化やツールの開発は、単なる技術的な実装ではなく、開発者の実際のニーズに基づいて行われ、継続的な改善のサイクルに組み込まれる必要があります。

このように、DevOpsマインドセットは、プラットフォームエンジニアリングの技術的な実現を支える基盤として機能し、他の2つの実践と密接に関連しながら、組織全体のエンジニアリング効率の向上に貢献しています。これらの3つの実践が交差する点に、プラットフォームエンジニアリングの本質があるのです。

5. プロダクトマネジメントの失敗モード

5.1 エンドユーザーのニーズを想定すること

プロダクトマネジメントには、私たちがよく遭遇する典型的な失敗モードがいくつかあります。その中でも最も重要な失敗モードの一つが、エンドユーザーのニーズを想定してしまうことです。これは私が「If you build it, they will come（作れば使われる）」と呼ぶ誤った前提に基づいています。

この考え方は、プロダクトマネジメントにおいて非常に危険です。世界中でこの考え方に基づいて多くのプロダクトが失敗してきました。なぜなら、あなたがいくら素晴らしいと思うプロダクトを作ったとしても、それが実際のエンドユーザーのニーズを満たしていなければ誰も使ってくれないからです。

この問題を避けるためには、エンドユーザーと直接対話を行い、彼らの実際のニーズを理解することが不可欠です。ユーザーの直感や推測に頼るのではなく、実際にユーザーと話し、彼らの課題や要求を直接聞くことが重要です。これは内部開発者ポータルのような内部向けのプロダクトであっても同じです。

エンドユーザーのニーズを正確に把握するためには、継続的なフィードバックループを確立し、仮説を検証し、必要に応じて方向性を修正していく必要があります。この過程では、単にユーザーの要望を聞くだけでなく、彼らが直面している実際の問題や課題を深く理解することが重要です。

5.2 ビジネス成果を見失うこと

プロダクトマネジメントの2つ目の重要な失敗モードは、ビジネス成果を見失うことです。スタートアップの世界では、これをプロダクトマーケットフィットの問題と呼んでいます。つまり、あなたが作っているプロダクトが、実際にビジネスにとって価値のある成果を生み出しているかということです。

最も美しいプロダクトを作り、最高のユーザーエクスペリエンスを提供し、非常に革新的な機能を実装したとしても、それが組織の求める成果を生み出していなければ、誰も気にかけてくれません。プロダクトマーケットフィットを見失うということは、そもそもなぜその取り組みを始めたのかという原点を見失うことを意味します。

例えば、Time to Marketの改善を目指していたのに、その目標を忘れて技術的な完璧さを追求してしまうことがあります。これは特にプラットフォームエンジニアリングでは陥りやすい罠です。私たちは常に、開発している機能やツールが実際のビジネス成果にどのように貢献しているのかを問い続ける必要があります。

ビジネス成果を見失わないためには、北極星指標（ノーススターメトリクス）に立ち返り、私たちの取り組みが実際にその指標の改善に貢献しているかを継続的に確認することが重要です。これにより、プロダクトの開発が組織の目標達成に確実に寄与していることを確認できます。

5.3 単一のエンドユーザーに焦点を当てすぎること

プロダクトマネジメントの3つ目の失敗モードは、単一のエンドユーザーに焦点を当てすぎることです。これは特に、二面市場（ツーサイドマーケットプレイス）の課題を考えるときに顕著になります。二面市場では、単一のペルソナのみに焦点を当てて他を無視してしまうと、決して問題を解決することはできません。両方のペルソナに対応する必要があるのです。

プラットフォームエンジニアリングにおいても、実は三つの重要なペルソナが存在します。まず、プラットフォームを実際に使用する開発者たちです。次に、SREやセキュリティチームなどの中央チームで、彼らには「信頼性を向上させよ」「セキュリティを確保せよ」といった大きな課題が与えられています。そして最後に、エンジニアリングリーダーシップです。彼らは個々のマイクロサービスの詳細は気にせず、ビジネス成果に焦点を当てています。

プラットフォームは、これら3つの異なるペルソナすべてのニーズに対応する必要があります。例えば、開発者は使いやすいツールを求め、中央チームは組織全体の施策を実現する手段を必要とし、リーダーシップは投資に対する価値を確認したいと考えています。これらの異なるニーズをバランス良く満たすことが、プラットフォームの成功には不可欠です。一つのペルソナに焦点を当てすぎると、他のペルソナのニーズが満たされず、結果としてプラットフォーム全体の価値が低下してしまいます。

5.4 段階的な価値提供ができないこと

プロダクトマネジメントの4つ目の失敗モードは、すべてを一度に構築しようとして、段階的な価値提供ができないことです。私たちはアジャイルの考え方について常に話していますが、この問題は依然として多くの組織で見られます。

最小限の実用的な製品（MVP）、あるいは私が好んで呼ぶ「最小限の価値のある製品」を見つけることが重要です。単に実用的なだけでなく、実際に価値を生み出すものでなければなりません。エンドユーザーに価値を示し、フィードバックを得て、それを基に製品を成長させていくことができるでしょうか？

プラットフォーム全体を一度に構築する必要はありません。例えば、2年かけてプラットフォームを構築し、その後でユーザーに提供するというアプローチは避けるべきです。代わりに、今日から提供できる価値の部分を特定し、段階的に提供を開始することが重要です。

このような段階的なアプローチを取ることで、ユーザーに価値を示し、フィードバックを得て、そのフィードバックを基に製品を改善していくという良好なサイクルを作ることができます。これにより、プラットフォームは確実にユーザーのニーズに応え続けることができ、長期的な成功につながります。

6. Platform-as-a-Productの実践

6.1 自動化とセルフサービス

自動化とセルフサービスの実践について、Platform-as-a-Productの観点から考えてみましょう。一般的な自動化とセルフサービスの取り組みでは、「これは摩擦ポイントだから自動化しよう」という考え方で進められることが多いのですが、それだけでは不十分です。

ビジネス成果との紐付けが重要です。例えば、私たちが市場投入までの時間を短縮したいと考えているとします。まず、「何が私たちの市場投入を遅くしているのか？」という問いから始める必要があります。おそらく、信頼性の面で私たちを遅くしている要因があるかもしれません。セキュリティの観点で遅延が生じているかもしれません。あるいは、標準化やベストプラクティスの適用が不十分で時間がかかっているかもしれません。

これらの摩擦ポイントを特定したら、それを自動化やセルフサービス化の対象として検討します。しかし、単に摩擦があるからという理由だけで自動化するのではなく、それが本当にビジネス成果の達成に貢献するのかを見極める必要があります。これにより、自動化の取り組みがより明確な目的を持ち、より良い成果を生み出すことができます。

このアプローチにより、開発者のエクスペリエンスを大幅に向上させることができます。例えば、セルフサービスの仕組みを通じて、開発者は必要なリソースや権限を迅速に取得できるようになります。これは単なる利便性の向上ではなく、組織全体の目標達成に直接貢献する取り組みとなります。

6.2 クロスファンクショナルなパートナーシップ

クロスファンクショナルなパートナーとの緊密な協働は非常に重要です。ここでの重要なポイントは、プラットフォームチームがSRE、セキュリティ、クラウドインフラなど、他の専門チームと密接に協力する必要があるということです。なぜなら、これらのチームはすべて同じエンドユーザー、つまり開発者にサービスを提供しているからです。

例えば、SREチームと協力することで、信頼性とオペレーショナルレディネスの要件をプラットフォームに組み込むことができます。これにより、開発者が新しいサービスを立ち上げる際に、信頼性の要件を最初から満たすことができます。セキュリティチームとの協力も同様で、セキュリティ要件をプラットフォームのデフォルト設定として組み込むことができます。

私たちの役割は、これらの専門チームが掲げる大きな目標をプラットフォームを通じて実現できるようにすることです。例えば、SREが「信頼性を向上させよ」という課題を与えられた場合、プラットフォームチームはその目標達成を支援するツールや機能を提供します。セキュリティチームが「セキュリティを確保せよ」という課題を持っている場合も同様です。

このような協働により、各専門チームはプラットフォームのチャンピオンとなり、自分たちの目標達成のためにプラットフォームを活用するようになります。これは、プラットフォームの価値を高め、組織全体のエンジニアリングエクセレンスを向上させる重要な要素となります。

6.3 3つのペルソナへの対応

先ほど述べたように、プラットフォームエンジニアリングには3つの重要なペルソナが存在します。プラットフォームを効果的に提供するためには、これらのペルソナそれぞれに対して適切に対応する必要があります。

まず1つ目は、実際にプラットフォームを使用する開発者たちです。彼らは日々のタスクを効率的に実行できる環境を必要としています。開発環境のセットアップ、デプロイメント、モニタリングなど、開発のライフサイクル全体をサポートする必要があります。

2つ目のペルソナは、SREやセキュリティなどの中央チームです。彼らには「信頼性を向上させよ」「セキュリティを確保せよ」といった大きな組織的な課題が与えられています。これらのチームはプラットフォームを通じて、自分たちの目標を達成する必要があります。彼らに対しては、目標達成を支援するツールや機能を提供する必要があります。

3つ目のペルソナは、エンジニアリングリーダーシップです。彼らは個々のマイクロサービスの詳細には興味がなく、むしろビジネス成果に焦点を当てています。「私が投資しているこのプラットフォームは、実際にどのような価値を生み出しているのか？」という視点で見ています。このペルソナに対しては、投資対効果を明確に示し、ビジネス目標との整合性を確保する必要があります。

このように、プラットフォームは3つの異なるペルソナのニーズに対応しながら、組織全体のエンジニアリングエクセレンスを向上させていく必要があります。これは簡単な課題ではありませんが、Platform-as-a-Productのアプローチを通じて実現することができます。

7. ステークホルダーとの協働事例

7.1 SREチームとの協働

SREチームとの協働は、プラットフォーム構築における重要な事例の一つです。まず、SREチームの主要な関心事は、アプリケーションが稼働しているか、信頼性が確保されているか、そしてカスタマーダウンタイムによるコスト発生を防げているかということです。

信頼性向上の取り組みを実現するために、プラットフォームがSREチームを支援する方法は複数あります。例えば、問題が発生した際に、チームが新しいバージョンを迅速にデプロイしたり、ロールバックを実行したり、必要に応じてスケールアップを行えるようにする必要があります。SREは、プラットフォームを通じてこれらの機能を開発者に提供することができます。

自動化されたランブックの作成も重要な協働領域です。プラットフォームはSREチームが定義した修復手順を自動化できるように構築される必要があります。これにより、問題が発生した際の対応時間を大幅に短縮することができます。

特に重要なのが、ゴールデンパスの確立です。新しいサービスやインフラストラクチャのための標準的なパスを提供することで、信頼性要件を最初から満たすことができます。例えば、日々のメトリクス収集、自動化機能、可視性の確保などが、プラットフォームのデフォルト設定として組み込まれます。

このような協働により、SREチームはプラットフォームの強力なサポーターとなります。彼らは開発者に対して「SREのサポートが必要な場合は、プラットフォームチームが提供するスターターテンプレートを使用してください。それが最も迅速に、かつ確実にプロダクションに到達する方法です」と推奨することができます。

7.2 セキュリティチームとの協働

セキュリティチームとの協働も、プラットフォームの重要な事例です。特に、開発者のセルフサービスワークフローにおいて、最もよく目にする例の一つがJust-in-time認証情報の提供です。例えば、セキュリティチームが「データベースへのアクセスを完全にオープンにはしたくない」という要件を持っている場合、プラットフォームを通じて15分間の読み取り専用アクセスを提供するような仕組みを実装できます。

このようなセルフサービス体験を構築することで、セキュリティチームもプラットフォームのチャンピオンとなります。彼らはプラットフォームを通じて、セキュリティ要件を開発者フレンドリーな形で提供できるようになります。

ゴールデンパスについても同様のアプローチを取ることができます。例えば、開発者が独自にプロジェクトを開始した場合、本番環境に移行するまでに2週間のセキュリティレビューが必要になりますが、プラットフォームチームが提供するスターターを使用した場合は、それが不要になり、1日の確認で済むようになります。これは、プラットフォームのデフォルト設定に必要なセキュリティ要件が組み込まれているためです。

また、セキュリティチームは承認のボトルネックになることを望んでいません。「リスクがあるので止めなければならない」「すべてをフリーズしなければならない」という立場に立つことを避けたいと考えています。そのため、プラットフォームを通じて承認プロセスを自動化し、セキュリティ要件の遵守を効率的に確認できるようにすることが重要です。これにより、セキュリティチームは開発の促進者となり、組織全体の効率を向上させることができます。

8. 成功の測定

8.1 ビジネス成果とエンジニアリングメトリクスの紐付け

プラットフォームエンジニアとして、私たちの最も重要な成果は、ビジネス成果の達成を妨げているボトルネックを実際に削減できているかどうかです。私たちは、カスタマーエクスペリエンスを本当に改善できているのか、コストと効率性を向上させているのか、そして市場投入までの時間を短縮できているのかを測定する必要があります。

これらの主要なビジネス成果を具体的なエンジニアリングメトリクスに落とし込む必要があります。例えば、市場投入までの時間に関して、私たちはPRのサイクルタイムが長すぎることを発見しました。CIが遅い、ビルド時間が長すぎる、レビュープロセスが非効率、PRが大きすぎるなど、具体的な問題点を特定しました。これらの問題を解決するための自動化を構築することで、組織の北極星指標（ノーススターメトリクス）に直接貢献することができます。

このように、エンジニアリングインテリジェンスメトリクスを活用することで、サイクルタイムやDORAメトリクスなどの具体的な指標を通じて、ボトルネックを特定し改善することができます。最も粒度の細かいエンジニアリングメトリクスから、組織が重視するビジネス成果まで、明確な関連性を持たせることが重要です。これにより、私たちの取り組みが実際にビジネス価値を生み出していることを示すことができます。

8.2 定性的フィードバックと採用率

成功を測定する上で、定量的なメトリクスだけでなく、定性的なフィードバックも重要です。プラットフォームの本質的な目的は開発者の生産性を向上させることですから、開発者からの直接のフィードバックは非常に重要な指標となります。

特に注目すべき指標として、プラットフォームの採用率と開発者の生産性があります。これには、プラットフォームを使用している開発者の割合や、オンボーディングの状況などが含まれます。開発者エクスペリエンスの観点から見ると、プラットフォームが実際に開発者の生産性を向上させているかどうかを測定することが重要です。

実際のところ、プラットフォームの価値は、それがどれだけ開発者の日々の業務を効率化し、組織の目標達成に貢献しているかによって決まります。そのため、定期的に開発者からフィードバックを収集し、プラットフォームの改善に活かしていく必要があります。

プラットフォームの採用率と開発者の生産性は、組織が投資している価値が実際に実現されているかを示す重要な指標となります。これらの指標を継続的に測定し、改善することで、プラットフォームの価値を最大化することができます。

9. 内部開発者ポータルの重要性

9.1 可視性の確保

プラットフォームが成長していく中で、組織の可視性を確保することは非常に重要です。私が見てきた多くの組織では、最初は巨大なスプレッドシートから始まります。「組織の現状を理解し、ボトルネックを見つけよう」という意図で作成されたスプレッドシートが、やがて6つのフォークに分かれ、それぞれが異なる用途で使用されるような状況になっています。

このような状況は、組織が少数のチームで少数のサービスを運用している段階では機能するかもしれません。しかし、組織が成長し、その可視性をスケールアップする必要が出てきた時、内部開発者ポータルの重要性が明確になってきます。

内部開発者ポータルは、プラットフォームエンジニアリングの基盤となります。先ほど話したオーナーシップとアカウンタビリティ、信頼性、運用準備態勢、これらすべてを実現するためには、まず組織の現状を可視化する必要があります。つまり、どのようなサービスが存在し、どのようなデータパイプラインが稼働し、どのようなインフラストラクチャが使用されているのかを把握する必要があります。

この可視性があってはじめて、私たちは組織の品質を評価し、改善のためのベースラインを設定することができます。結局のところ、測定できないものを改善することはできないのです。そのため、まずはカタログを整備し、組織の現状を可視化することから始める必要があります。

9.2 ベースラインの定義

カタログから始まる可視性の次のステップは、ベースラインの定義です。これはスコアカードを通じて、インフラストラクチャやサービスの品質を評価する基準を設定することを意味します。なぜなら、私たちは何かを改善したいと思っても、それを測定できなければ改善することはできないからです。

スコアカードを使用することで、私たちは「良い状態」とはどのような状態なのかを定義することができます。これにより、発見したボトルネックが実際にどの程度の問題なのかを評価し、それをどのように改善できるかを検討することができます。

品質基準の設定は、組織全体のエンジニアリングエクセレンスを向上させるための基盤となります。どのようなメトリクスを使用し、どのような基準を設けるかは、組織の目標や状況に応じて決定されます。重要なのは、これらの基準が測定可能で、改善の進捗を追跡できるものであることです。

このように、内部開発者ポータルを通じてベースラインを定義し、それを継続的に測定・改善していくことで、組織全体のエンジニアリング品質を向上させることができます。これは単なる技術的な指標ではなく、最終的にはビジネス成果の達成にも直結する重要な要素となります。

9.3 セルフサービスワークフローの統合

内部開発者ポータルの第三の重要な側面は、セルフサービスワークフローの統合です。ここで重要なのは、私たちが構築しているツールをユーザーが実際に見つけることができ、使用できるようにすることです。なぜなら、最後に私たちが望むのは、プラットフォームが16の異なるツールに分散し、10の異なるアプリケーションに分かれてしまうような状況は避けたいからです。

開発者は必要なツールや機能を単一の場所で見つけることができる必要があります。内部開発者ポータルは、単なるカタログやスコアカードの表示だけでなく、開発者が日々使用するツールやワークフローを発見し、アクセスできる場所となるべきです。このような統合されたユーザー体験を提供することで、プラットフォームの価値を最大限に引き出すことができます。

私たちは、ポータルがプラットフォームエンジニアリングの機能を集約する場所となるように設計する必要があります。これにより、開発者は必要な機能を簡単に見つけ、使用することができ、結果として組織全体の効率性が向上します。

このような統合されたアプローチにより、内部開発者ポータルはプラットフォームエンジニアリングの基盤として機能し、エンジニアリングエクセレンスを実現するための重要な要素となります。これは私たちがCortexで実現しようとしている、まさにその目標です。