※本記事は、AWS re:Invent 2024のセッション「Platform engineers as product managers: Boost your team's productivity (DOP102)」の内容を基に作成されています。この講演は、Cortex（AWSパートナー）のCTOおよび共同創業者であるGanesh氏によって行われました。セッションの完全な内容はAWSのイベントページ（https://go.aws/reinvent ）でご覧いただけます。

本記事では、講演の内容を要約し、プラットフォームエンジニアリングにおけるプロダクトマネジメントマインドセットの重要性について解説しております。なお、本記事の内容は講演者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講演をご視聴いただくことをお勧めいたします。

AWS re:Inventの他のセッションや関連コンテンツについては、AWSのイベントページ（https://go.aws/3kss9CP ）やAWSのYouTubeチャンネル（http://bit.ly/2O3zS75 ）もご参照ください。

1. イントロダクション

1.1. プラットフォームエンジニアリングの定義

プラットフォームエンジニアリングは、役職や職種としては比較的新しい概念ですが、その根底にある考え方は長年にわたって存在してきました。プラットフォームエンジニアリングは、様々な既存のアイデアや実践を統合し、体系化したものと言えます。

特に重要なのは、プラットフォームエンジニアリングにおけるプロダクトマネジメントのマインドセットです。このマインドセットが必要とされる背景には、プラットフォームエンジニアリングが組織全体のエンジニアリング効率を向上させる重要な役割を担っているという認識があります。プラットフォームエンジニアは、開発者エクスペリエンスとDevOpsの専門知識を持つ技術者でありながら、組織全体の課題を解決し、ビジネス成果を導く必要があります。

このような背景から、プラットフォームエンジニアリングには、従来の技術的なアプローチだけでなく、プロダクトマネジメントの考え方を取り入れることで、より効果的に組織の目標達成に貢献することが求められています。プラットフォームエンジニアリングは、エンジニアリングエクセレンスを実現するための基盤として位置づけられ、その実現には体系的なアプローチが必要とされています。

1.2. プレゼンターとCortexの紹介

プレゼンターのGaneshは、Cortexの共同創業者であり、CTOを務めています。Cortexは内部開発者ポータルを提供する企業であり、エンジニアリングエクセレンスのためのプラットフォームとして位置づけられています。

Cortexは、プラットフォームエンジニアリングの実践において、特に内部開発者ポータルの重要性に着目しています。このポータルは、エンジニアリングチームの生産性を向上させ、組織全体のエンジニアリング品質を高めるための基盤として機能します。Ganeshは、プラットフォームエンジニアリングの実践において、プロダクトマネジメントのマインドセットが不可欠であると考えており、この考えがCortexの製品開発の根幹となっています。

2. プロダクトマネジメントの基礎

2.1. プロダクトマネジメントの目的

Ganesh：プロダクトマネジメントについて、まずその定義から明確にしておきたいと思います。プロダクトマネジメントの目的は、根本的に顧客のニーズを解決することです。この場合の顧客は、内部の顧客であっても外部の顧客であってもかまいません。しかし、ここで重要なのは、その解決が必ずビジネスの主要な成果に結びついていなければならないということです。

例えば、消費者向けアプリのプロダクトマネジャーであれば、MAU（月間アクティブユーザー）やDAU（日間アクティブユーザー）、あるいは収益といった指標を北極星メトリクス（主要な指標）として考えることになります。このような明確な指標に向かって、どのように顧客のニーズを解決し、望ましい成果を生み出すかを考えていくのです。

プロダクトマネジメントの本質は、顧客のニーズを理解し、それをビジネス成果につなげることです。この考え方は、プラットフォームエンジニアリングにおいても同様に重要です。プラットフォームエンジニアとして、私たちは組織内の開発者という顧客のニーズを理解し、それを組織全体のエンジニアリング効率の向上というビジネス成果につなげていく必要があります。これが、プロダクトマネジメントの基本的な目的であり、プラットフォームエンジニアリングにおいても同様のアプローチが求められるのです。

2.2. ビジネスの主要な成果指標

Ganesh：エンジニアリングの観点から見た主要なビジネス成果について、私は3つの大きな領域に分類したいと思います。

まず1つ目は、イノベーションと市場投入時間です。私たちは、より多くのものを、より速く出荷し、市場に投入する必要があります。競争力を維持し、優位性を失わないためには、イノベーションが極めて重要です。

2つ目は、品質とカスタマーエクスペリエンスです。これは多くの組織で普遍的に重要ですが、特に金融機関やアプリケーションなど、1分のダウンタイムが数百万ドルのコストにつながる場合、高いSLAが求められます。信頼性、つまり顧客体験の品質が本当に重要になってきます。

3つ目は、特に今日の環境において最重要課題となっているコストと効率性です。これを特に取り上げたのは、今日のビジネスにおける重要な指標の一つだからです。必ずしも顧客ニーズに直接サービスを提供するものではありませんが、ビジネスとして、多くの組織が考慮している重要な指標の一つです。

これらの要素は相互に排他的ではありません。多くの場合、これらは相互に関連しています。信頼性に投資することで、カスタマーエクスペリエンスを向上させ、同時に市場投入までの時間を短縮できます。なぜなら、バグの修正などに費やす時間が減少するからです。このように、これらの指標には多くの重複する部分があります。しかし、核心として、これらが私たちがビジネスとして気にかけている3つの主要な成果なのです。

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

3.1. エンジニアリングエクセレンスの構成要素

Ganesh：エンジニアリングエクセレンスは広範なトピックですが、すべての組織が可能な限り高いレベルでエンジニアリング組織を運営することを考えています。私は、エンジニアリングエクセレンスをいくつかの重要な領域に分類して考えています。

まず最も基本的な要素は、オーナーシップとアカウンタビリティです。誰が何を所有し、誰が何に対して説明責任を持つのかを明確にする必要があります。これは非常に重要な出発点です。なぜなら、いくらベストプラクティスを定義し、イニシアチブを推進しようとしても、誰も責任を持たなければ、それは単なる空虚な叫びに終わってしまうからです。

その上で、信頼性、運用準備態勢、セキュリティとコンプライアンス、標準化とガードレールといった要素が重要になってきます。これらの要素は、私が「エンジニアリングエクセレンス」と呼ぶものの異なる柱を形成しています。

組織が成熟していくにつれて、これらの要素はそれぞれ個別の領域に分かれていきます。例えば、セキュリティとコンプライアンスには専門のチームが置かれ、信頼性にはSREチーム、標準化とガードレールにはプラットフォームチームやクラウドインフラチームが担当するというように、それぞれのイニシアチブが個別のチームや重点領域に分かれていきます。

これらの要素に投資することで、組織としてのビジネス成果を達成することができます。つまり、エンジニアリングエクセレンスの各要素は、最終的にはビジネスが気にかける成果につながっているのです。

3.2. プラットフォームエンジニアリングの役割

Ganesh：それでは、これらのエンジニアリングエクセレンスの要素が重要だとして、何がそれらを実現可能にするのでしょうか？エンジニアリング組織としてこれらの要素を大切にし、それらがビジネス成果の達成に役立つということに同意したとして、そもそもこれらのイニシアチブを可能にする基盤は何なのでしょうか？

私は、それこそがプラットフォームエンジニアリングだと考えています。プラットフォームエンジニアリングは、組織全体のエンジニアリングエクセレンスのイニシアチブを可能にする基盤を構築することです。これには、開発者エクスペリエンス、開発者のセルフサービス、プラットフォームの基盤など、すべてが含まれます。これらの要素が、組織全体のエンジニアリングエクセレンスのイニシアチブを実現可能にするのです。

つまり、プラットフォームエンジニアは、エンジニアリングエクセレンスの基盤を構築する役割を担っています。この基盤があってこそ、先ほど述べた各要素に取り組むことができ、最終的にビジネス成果の達成へとつながっていくのです。プラットフォームエンジニアリングは、組織のエンジニアリングエクセレンスを実現するための不可欠な基盤として機能しているのです。

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

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

Ganesh：プラットフォームエンジニアリングには、3つの中核的な実践があります。名称としてのプラットフォームエンジニアリングは比較的新しいものですが、その考え方は長年存在してきました。

その第一の柱が開発者エクスペリエンスです。これは、組織として重要だと考えているイニシアチブを、開発者にとって優れた体験に変換する方法を考えることです。開発者が満足し、ビジネスにとって正しいことを実現できるようにすることが重要です。

この開発者エクスペリエンスは、プロダクトマネジメントマインドセットやDevOpsマインドセットと深く結びついています。組織が必要とする機能や施策を、開発者が実際に使いたくなるような形で提供することが求められます。つまり、開発者エクスペリエンスは、技術的な機能提供だけでなく、その使いやすさや有用性を含めた総合的な体験として設計される必要があります。私たちは、このような開発者体験の最適化を通じて、組織全体のエンジニアリング効率を向上させることを目指しています。

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

Ganesh：プラットフォームエンジニアリングの2つ目の柱は、プロダクトマネジメントのマインドセットです。このマインドセットは、内部の顧客に向けたプロダクトを開発し、組織内のニーズを把握して優先順位をつけていくことを意味します。

私たちには内部の顧客がおり、その顧客のために製品を作る必要があります。これは、開発者エクスペリエンスとDevOpsのスキルを持つ技術者が、組織全体の大きな課題を解決する必要があるということを意味します。これは非常に重要な変化で、様々なリスクも伴います。なぜなら、従来は製品マネージャーではない人々に、製品マネージャーとしての考え方や役割を担わせることになるからです。

しかし、このプロダクトマネジメントマインドセットは、プラットフォームエンジニアリングの成功には不可欠です。単なる技術的な実装だけでなく、組織のニーズを理解し、それに応えるソリューションを提供することが求められます。これは、開発者エクスペリエンスを向上させながら、ビジネス目標の達成を支援する上で重要な要素となります。

このマインドセットを持つことで、プラットフォームエンジニアは組織の目標と開発者のニーズの両方を理解し、それらを効果的に結びつけることができます。

4.3. DevOpsマインドセット

Ganesh：プラットフォームエンジニアリングの3つ目の柱は、従来のDevOpsマインドセットです。これは、組織がこれらの施策をどのように実現するのか、どのように自動化とツーリングを構築し、継続的な改善を実現するのかという技術的な側面を担っています。

このDevOpsマインドセットは、プラットフォームエンジニアリングに取り込まれた伝統的な技術的側面を代表しています。これは単なる自動化の実装ではなく、プラットフォームエンジニアリングの技術的な基盤として機能します。開発者エクスペリエンスとプロダクトマネジメントのマインドセットと組み合わさることで、より効果的なプラットフォームの構築が可能になります。

このように、プラットフォームエンジニアリングは、開発者エクスペリエンス、プロダクトマネジメントマインドセット、そしてDevOpsマインドセットという3つの実践の交差点に位置しています。プラットフォームエンジニアは、これらの要素を組み合わせることで、組織全体の課題を解決し、エンジニアリングエクセレンスを実現する基盤を提供することができます。

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

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

Ganesh：プロダクトマネジメントの失敗パターンについて説明したいと思います。私が最初に注目したい失敗パターンは、エンドユーザーのニーズを勝手に想定してしまうことです。これは、「私はエンドユーザーのことを知っている。だから、私が彼らに必要だと思うものを作れば、彼らは必ずやってくる」という考え方です。

この「作れば来る（If you build it, they will come）」という考え方は、プロダクトマネジメントにおいて最も危険な思い込みの一つです。世界中でも、このような直感的なユーザー理解を持っている人は極めて稀です。そのため、ほとんどの場合、まずはユーザーと直接対話することから始める必要があります。

これは非常に基本的なことのように聞こえますが、プラットフォームエンジニアリングにおいて特に重要です。なぜなら、私たちは技術者として自分たちの理解や経験に基づいて判断しがちですが、実際のユーザーニーズは私たちの想定とは異なることが多いからです。ユーザーと直接対話し、彼らの真のニーズを理解することなしには、真に価値のあるプラットフォームを構築することはできません。

5.2. ビジネス成果を見失う

Ganesh：プロダクトマネジメントの2つ目の失敗パターンは、ビジネス成果を見失うことです。最も美しいプロダクトを作り、最高のユーザーエクスペリエンスを提供し、非常に革新的なものを作ったとしても、それがビジネス成果を生み出さなければ、誰も気にかけてくれません。

スタートアップの世界では、これを「プロダクトマーケットフィット」と呼んでいます。つまり、あなたが提供しようとしている価値が、そもそもこのイニシアチブを開始した理由と合致しているかどうかということです。プラットフォームエンジニアリングの文脈では、私たちが構築するプラットフォームが、組織が目指すビジネス成果に直接的に貢献しているかを常に問う必要があります。

ビジネス価値との紐付けがない場合、どんなに技術的に優れたプラットフォームを構築しても、それは単なる技術的な実験に終わってしまう可能性があります。プラットフォームエンジニアとして、私たちは常にビジネス成果への貢献を意識し、それを測定可能な形で示していく必要があります。

5.3. 単一のエンドユーザーに焦点を当てる

Ganesh：プロダクトマネジメントの3つ目の失敗パターンとして、1つのエンドユーザーだけに焦点を当て、プロダクトを消費する他のすべてのペルソナを無視してしまうことがあります。

例えば、これは双方向のマーケットプレイス問題に似ています。マーケットプレイスを構築する場合、片方のペルソナだけに焦点を当て、もう片方を無視することはできません。そうすれば、決して問題を解決することはできないでしょう。同じことは、あらゆるプロダクトにも当てはまります。

プラットフォームエンジニアリングの文脈では、複数のペルソナが私たちのプロダクトを使用する場合、その1つだけに焦点を当てて他を無視することはできません。例えば、実際のプロダクトを使用する開発者、SREやセキュリティなどの中核となるチーム、そして「細かい詳細は気にしない、個々のマイクロサービスには興味がない、ビジネス成果だけが重要だ」と考えるエンジニアリングリーダーシップなど、異なるペルソナが存在します。

バランスの取れたアプローチとは、これらすべてのペルソナのニーズを理解し、それぞれに価値を提供できるプラットフォームを構築することです。プラットフォームエンジニアとして、私たちは異なるペルソナ間の相互作用を理解し、それぞれのニーズを満たすソリューションを提供する必要があります。

5.4. 一度にすべてを構築しようとする

Ganesh：プロダクトマネジメントにおいて最後の失敗パターンは、一度にすべてを構築しようとすることです。私たちはこれについて、アジャイルの文脈で常に議論していますが, 本質的な問題は、最小限の実行可能な製品、あるいは私が好んで呼ぶところの「最小限の価値のある製品」をどのように見つけるかということです。単に実行可能なだけでなく、実際に価値を生み出すものである必要があります。

私たちは、エンドユーザーに対して段階的に価値を提供できているでしょうか？プラットフォーム全体を一度に構築する必要はありません。私が考えるところでは、プラットフォームの異なる側面に対して、段階的に価値を提供し始めることができます。これによって、ユーザーに価値を示し、彼らをその旅に巻き込んでいくことができます。

このアプローチには素晴らしい効果があります。ユーザーに価値を示すことができれば、彼らは自然とフィードバックをくれるようになり、さらに何が必要かを教えてくれます。これにより、素晴らしいフィードバックループが生まれ、プラットフォームの継続的な改善が可能になります。つまり、一度にすべてを構築しようとするのではなく、インクリメンタルな価値提供を通じて、ユーザーとともにプラットフォームを成長させていくことが重要なのです。

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

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

Ganesh：プラットフォームをプロダクトとして考えるにあたり、まずセルフサービスの体験について説明したいと思います。プラットフォームエンジニアリングで最も一般的なことの一つは、セルフサービスの体験を考えることです。「ここに摩擦ポイントがあるから、それに対するセルフサービスを構築しよう」、あるいは「これが摩擦だと思うから、それに対する自動化とセルフサービスを構築しよう」というアプローチをよく見かけます。

しかし、私が重要だと考えるのは、最初のスライドに戻って考えることです。私たちがビジネスとして気にかけている成果は何でしょうか？例えば、より速く市場に出ることを目指しているとします。そうであれば、まず問いかけるべきは「現在、何が市場投入を遅らせているのか？」ということです。おそらく、市場投入を遅らせている要因は多岐にわたります。

その要因を特定したら、それらをエンジニアリングエクセレンスのイニシアチブに変換します。信頼性の面で私たちを遅らせているものは何でしょうか？セキュリティの面では何が遅延要因になっているでしょうか？標準化やベストプラクティスの観点では何が課題になっているでしょうか？これらの要因を特定し、それらを逆算することで、構築すべきセルフサービス体験の範囲を絞り込むことができます。

このアプローチを取ることで、私たちが取り組もうとしているビジネス成果に直接的に貢献するセルフサービス体験を構築することができます。これにより、プロダクト体験をより効果的に設計することが可能になります。

6.2. クロスファンクショナルパートナーとの協働

Ganesh：クロスファンクショナルパートナーとの協働は、プラットフォームエンジニアリングの成功に不可欠です。特に重要なのは、SRE、セキュリティ、クラウドインフラなど、他の組織と密接に連携することです。これらの組織はそれぞれが独自のイニシアチブを持っていますが, プラットフォームチームの役割は、これらの組織と協力して、エンドの開発者にサービスを提供することです。

というのも、これらの組織はすべて同じエンドユーザー、つまり開発者にサービスを提供しているからです。そのため、もしこれらの組織が一緒に集まり、開発者のユースケースを共同で解決できれば、はるかに効果的な結果を生み出すことができます。

エンドユーザーのニーズに焦点を当てながら、各組織の専門知識を活かして共通の目標を達成することが重要です。これにより、組織全体としてより効果的な成果を上げることができます。プラットフォームチームは、これらの異なる組織を結びつけ、共通の目標に向かって協力するための触媒としての役割を果たします。

このような協働は、単なる技術的な統合以上のものです。各組織の目標と課題を理解し、それらを調整して、開発者にとって価値のある統合されたソリューションを提供することが必要です。この協働的なアプローチにより、組織全体のエンジニアリングエクセレンスを向上させることができます。

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

Ganesh：プラットフォームエンジニアリングのマインドセットにおいて、私たちは3つの異なるペルソナについて考える必要があります。これらのペルソナは、それぞれ異なるニーズと期待を持っています。

1つ目のペルソナは、実際にプロダクトを使用する開発者です。彼らは私たちのプラットフォームの直接的なユーザーであり、日々の開発作業の中でプラットフォームを利用します。

2つ目のペルソナは、SRE、セキュリティ、そして私たちプラットフォームエンジニア自身のような中核となるチームです。これらのチームは「信頼性を向上させよ」「セキュリティを改善せよ」といった大きな課題を与えられています。しかし、彼らは直接これらの改善を実施することはできません。代わりに、開発者に影響を与え、これらの改善を実現するように導く必要があります。

3つ目のペルソナは、エンジニアリングリーダーシップです。彼らは「細かい詳細は気にしない、個々のマイクロサービスには興味がない、ビジネス成果だけが重要だ」と考えています。つまり、私たちが投資しているものが実際にどのようなビジネス成果をもたらしているのかに関心があります。

私たちのプラットフォームは、これらすべてのペルソナに対してサービスを提供できる必要があります。各ペルソナは異なる視点と要求を持っており、プラットフォームはそれぞれのニーズを満たしながら、全体として調和のとれたソリューションを提供しなければなりません。これは、プラットフォームの設計と実装において常に意識すべき重要な観点です。

6.4. インクリメンタルな価値提供

Ganesh：プラットフォーム全体を一度に構築する必要はありません。インクリメンタルな価値提供について、私たちは2つの重要な側面に着目しています。

1つ目は、段階的な機能リリースです。プラットフォームの異なる側面から、価値の提供を開始することができます。つまり、プラットフォーム全体を一度に構築しようとするのではなく、最も価値の高い機能から順次リリースしていくアプローチを取ります。これにより、ユーザーは早い段階から具体的な価値を享受することができます。

2つ目は、フィードバックループの構築です。価値を提供し始めると、ユーザーは自然とフィードバックを提供してくれるようになります。彼らは何が必要かを教えてくれ、それが次の開発サイクルへの入力となります。このフィードバックループが確立されると、プラットフォームの継続的な改善がより効果的になります。

このアプローチは、プラットフォームエンジニアリングにおいて特に重要です。なぜなら、プラットフォームは組織の成長とともに進化し続ける必要があるからです。インクリメンタルな価値提供により、私たちは常にユーザーのニーズに応じて方向性を調整し、最も価値のある機能を優先的に提供することができます。

6.5. ベストオブブリードのケイパビリティ集合体としてのプラットフォーム

Ganesh：プラットフォームについて考えるとき、それを1つの大きなものとして考えないようにすることが重要です。プラットフォームは1つの巨大なプラットフォームではなく、実際にはベストオブブリードの機能の集合体として考えるべきです。

プラットフォームは、インフラストラクチャのプロビジョニング、サービスカタログ、オーナーシップ、セキュリティ、自動化など、様々な要素で構成されています。これらの要素は、組織ごとに異なる摩擦ポイントや課題に対応するために、それぞれ異なるコンポーネントとして設計される必要があります。

単に「プラットフォームのベストプラクティスに従おう」というアプローチでは、十分な成果は得られないでしょう。代わりに、私たちが本当に気にかけている成果は何か、組織特有の摩擦ポイントは何か、そしてそれらをプラットフォームを通じてどのように解決できるかを考える必要があります。

このように、プラットフォームを個別の機能の集合体として考えることで、組織固有のニーズに柔軟に対応し、最適なソリューションを提供することができます。最終的には、これらの機能がエンドユーザーに届けられ、組織全体の効率性と生産性の向上に貢献することになります。

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

7.1. SREチームとの協働

Ganesh：SREチームとの協働について、具体的な事例を紹介したいと思います。SREは信頼性とSRE（Site Reliability Engineering）を担当しており、アプリケーションが稼働し、信頼できる状態にあるかを気にかけています。ダウンタイムは非常にコストがかかるため、私たちは優れた顧客体験を提供する必要があります。

SREは、チームが新しいバージョンを迅速にデプロイし、ソフトウェアをロールバックし、必要に応じてスケールアップできるようにすることを求めています。ここで、プラットフォームチームが構築しているものとSREが気にかけていることとの間に明確な関連性が見えてきます。SREは、プラットフォームが提供するツールがなければ、開発者に対してこれらの機能を提供することができません。

実践例として、ランブックの自動化があります。プラットフォームは、SREが実際に修復手順を自動化できるように構築される必要があります。また、ゴールデンパスの提供も重要な例です。これについては多く議論されていますが、特に重要なのは、新しいサービスや新しいインフラストラクチャのためのゴールデンパスを提供することです。

しかし、単に素晴らしい開発者体験を提供し、簡単に始められるゴールデンパスを作るだけでは不十分です。SREが本番環境で気にかけるすべてのベストプラクティスに従ったものを提供する必要があります。つまり、初日から適切なメトリクスが事前に設定され、適切な自動化が組み込まれ、適切な可視性が確保されている必要があります。

このように、SREはプラットフォームチームが構築するセルフサービス機能の重要なチャンピオンとなります。彼らは「SREのサポートが必要な場合は、プラットフォームチームが構築したものを使用してください。彼らはプロジェクトのための優れたブートストラップスターターを提供しています」と言うでしょう。これが、製品を可能な限り早く本番環境に移行するための最良の方法となります。

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

Ganesh：セキュリティチームとの協働についても、開発者のセルフサービスワークフローという観点から考えてみましょう。よく見かける例として、Just-in-Time認証情報の提供があります。セキュリティチームは、データベースへのオープンなアクセスを許可するのではなく、15分間の読み取り専用アクセスを提供するといった、より厳格なアクセス制御を実施したいと考えています。

このような要件に対して、プラットフォームチームは、セキュリティチームが望むセキュリティ要件を満たしながら、シンプルなセルフサービス体験を提供できるプラットフォームを構築する必要があります。これにより、セキュリティチームもまた、私たちが構築するプラットフォームのチャンピオンとなってくれます。

ゴールデンパスについても同様の例が当てはまります。開発者が独自にプロジェクトを開始し、独自のサービスを構築しようとすると、本番環境に移行するまでに2週間のセキュリティレビューが必要になるかもしれません。しかし、プラットフォームチームが提供するスターターを使用すれば、それらのセキュリティ要件は事前に組み込まれているため、1日程度のレビューで本番環境への移行が可能になります。

最後に、承認の自動化も重要です。セキュリティチームはボトルネックになることを望んでいません。「リスクがあるので、すべてを停止しなければならない」という悪役になりたくないのです。そこで、プラットフォームにセキュリティタスクを自動化する機能を組み込むことで、本当に重要な事項に集中できるようになります。このように、セキュリティチームと協力することで、より効果的な自動化を実現し、組織全体のセキュリティを向上させることができます。

8. 成功の測定

8.1. ビジネス成果とボトルネックの関係

Ganesh：成功を測定する際、プラットフォームエンジニアとして最も重要な成果は、ビジネス成果の達成を妨げているボトルネックを実際に削減できているかどうかです。私たちは、顧客体験の向上、コストと効率性の改善、市場投入時間の短縮といったビジネス成果を本当に実現できているでしょうか？

これらの主要なビジネス成果を取り、そのボトルネックを特定し、それらを具体的なエンジニアリングメトリクスに分解する必要があります。例えば、ビジネスが市場投入時間を重視している場合、私たちはPRのサイクルタイムが実際にはとても長いことを発見するかもしれません。CIが遅い、ビルド時間が長すぎる、レビューに時間がかかる、人々が大きすぎるPRを開いている、そしてそれらに対する自動化が不足しているといった具体的な問題が見えてきます。

このように、私たちは重要なエンジニアリングメトリクスを特定し、それをビジネスの北極星メトリクス（主要指標）に紐付けることができます。これにより、プラットフォームエンジニアリングの取り組みが実際にビジネス価値を生み出しているかどうかを明確に示すことができます。

8.2. エンジニアリングメトリクスの設定

Ganesh：このような観点から、エンジニアリングの効果を測定するための具体的な指標が必要になってきます。その代表的なものが、エンジニアリングインテリジェンスメトリクスです。例えば、サイクルタイムやDORAメトリクスといった指標を活用することで、プラットフォームの効果を定量的に測定することができます。

また、プラットフォーム固有の指標として、プラットフォーム開発者からの定性的なフィードバック、プラットフォームの採用率やオンボーディングの割合、開発者の生産性や開発者体験に関するメトリクスなども重要です。これらの指標を組み合わせることで、エンジニアリングの観点から最も細かいレベルで測定を行い、それをビジネスが気にかける成果に紐付けることができます。

私たちは、これらのメトリクスを通じて、プラットフォームエンジニアリングの取り組みが実際にどれだけの価値を生み出しているのかを、具体的なデータとして示すことができます。これにより、継続的な改善のサイクルを回し、プラットフォームの価値を高めていくことが可能になります。

8.3. 定性的フィードバックの重要性

Ganesh：数値的なメトリクスに加えて、プラットフォームエンジニアとして、私たちは顧客からの定性的なフィードバックを集めることも重要です。プラットフォームの利用者である開発者からの直接的なフィードバックは、プラットフォームの改善に不可欠な情報源となります。

定性的なフィードバックは、メトリクスだけでは捉えきれない利用者の実際の体験や要望を理解するための重要な手段です。これらのフィードバックを継続的に収集し、フィードバックループに組み込むことで、プラットフォームの価値を確実に高めていくことができます。

このプロセスは、単にフィードバックを集めるだけでなく、それを実際の改善アクションに結びつけることが重要です。フィードバックを通じて特定された課題や要望を、プラットフォームの改善サイクルに組み込むことで、継続的な進化を実現することができます。これは、プロダクトマネジメントのマインドセットを実践する上で重要な要素となります。

9. 内部開発者ポータルの役割

9.1. プラットフォームエンジニアリングの基盤

Ganesh：組織の可視性に関して考えると、時にはこのような状況から始まることがあります。巨大なスプレッドシートがあり、「組織の現状を理解しよう」「ボトルネックを見つけてそれを解決しよう」と考えます。そして、そのスプレッドシートが6つのフォークに分かれ、それぞれが異なるユースケースに対応しているという状況に陥ることがあります。

しかし、チームが少数のサービスを運用する段階から、より多くのサービスを扱う段階へと成長するにつれて、この可視性をスケールアップする必要が出てきます。ここで内部開発者ポータルの出番となります。

私たちは、内部開発者ポータルをプラットフォームエンジニアリングの基盤として位置付けています。オーナーシップと説明責任、信頼性、運用準備態勢など、これまで話してきたすべての要素を実現するためには、まず可視性が必要です。現在、組織にどのようなものが存在し、それらの品質をどのように評価し、どこにボトルネックがあるのかを把握する必要があります。

内部開発者ポータルは、この可視性を一元的に提供し、組織全体のエンジニアリング活動を統合的に管理する基盤となります。これにより、プラットフォームエンジニアリングの様々な取り組みをより効果的に展開することが可能になります。

9.2. 可視化とスコアカード

Ganesh：まず、カタログから始めて、サービス、データパイプライン、インフラストラクチャに関する可視性を確保する必要があります。しかし、単なる可視化だけでは不十分です。次のステップとして、スコアカードを通じて何が「良い」状態なのかのベースラインを定義する必要があります。

この点について、私はよく「測定できないものを改善することはできない」という言葉を引用します。スコアカードを通じて、インフラストラクチャやサービスの品質を評価し、そのベースラインを定義することで、私たちは見つけたボトルネックをどのように改善していくかを明確にすることができます。

このプロセスは内部開発者ポータルの重要な機能の一つとなります。ポータルを通じて、インフラストラクチャやサービスの品質をスコアリングし、それらのベースラインを定義することで、組織全体の改善の方向性を示すことができます。これにより、プラットフォームエンジニアリングの効果を具体的に測定し、継続的な改善につなげることが可能になります。

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

Ganesh：最後に、セルフサービスワークフローの統合についても説明したいと思います。これは、私たちが構築するツールの発見可能性を高めることに関わります。プラットフォームが16の異なるツールに分断され、プラットフォームが10個の異なるアプリに分散している状況は望ましくありません。

開発者には、必要なツールを1つの場所で見つけられる環境が必要です。ポータルは単なる基盤としての役割だけでなく、開発者が構築するツールを発見できる場所としても機能する必要があります。

スタートアップの世界でも同じことが言えます。私たちがこのカンファレンスに参加している理由の一つは、「私たちが構築しているものを見てください。これはとても素晴らしいものです」と伝え、その問題を抱えているユーザーを見つけることです。プラットフォームエンジニアリングでも同じです。問題を特定し、ボトルネックを見つけ、製品を構築したら、次はユーザーがそれを発見できるようにする必要があります。

このように、開発者ポータルを通じて統合された発見可能性を提供することで、プラットフォームの価値を最大限に引き出すことができます。これにより、エンドユーザーである開発者に対して、より効果的にツールを提供することが可能になります。