※本記事は、AWS re:Invent 2024で行われた「Platform engineers as product managers: Boost your team's productivity (DOP102)」の内容を基に作成されています。講演の詳細情報はAWSのイベントページ（https://go.aws/reinvent ）でご覧いただけます。本記事では、講演の内容を要約しております。

登壇者のGanesh氏は、内部開発者ポータルを提供するCortex.ioのCTOおよび共同創業者です。Cortexは、プラットフォームエンジニアリングの実践を支援するAWSパートナー企業です。同氏は、プラットフォームエンジニアリングにプロダクトマネジメントのマインドセットを導入することで、開発者中心の高impact な取り組みへと変革する方法について、自身の経験と知見を共有しています。

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

1. イントロダクション

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

プラットフォームエンジニアリングという役割や肩書きは比較的新しいものですが、その概念自体は長年存在していました。私たちは長い間これらのアイデアについて学んできましたが、今こそそれらの考えを一つにまとめ、プロダクトマネジメントのマインドセットについて本格的に議論する時が来たと考えています。

なぜプラットフォームエンジニアリングにプロダクトマネジメントのマインドセットが必要なのでしょうか。この問いは、プラットフォームエンジニアリングの本質的な役割と深く関係しています。プラットフォームエンジニアリングは、エンジニアリングエクセレンスを実現するための基盤を構築する役割を担っています。これには、開発者エクスペリエンス、開発者のセルフサービス、そしてプラットフォームの基礎となるインフラストラクチャーの全てが含まれます。

このように、プラットフォームエンジニアリングは組織全体のエンジニアリングエクセレンスを実現するための基盤となるため、従来のエンジニアリングの考え方だけでなく、ユーザー（この場合は内部の開発者）のニーズを理解し、それに応える製品を作り上げていくプロダクトマネジメントの考え方が不可欠となってきています。

1.2 講演者の紹介

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

今日は、なぜプラットフォームエンジニアリングにプロダクトマネジメントのマインドセットが必要なのか、そしてそれがどのようにチームの生産性を向上させることができるのかについて、具体的な例を交えながらお話ししていきたいと思います。

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

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

まず、プロダクトマネジメントの本質について説明させていただきます。プロダクトマネジメントの根本的な目標は、顧客のニーズを解決することです。顧客は内部の場合もあれば外部の場合もありますが、プロダクトマネージャーとしての基本的な役割は、顧客のニーズを解決することにあります。

しかし、これは単なる顧客ニーズの解決にとどまりません。重要なのは、それが主要なビジネス成果に紐づいていることです。例えば、消費者向けアプリのプロダクトマネージャーであれば、月間アクティブユーザー数（MAU）や日間アクティブユーザー数（DAU）、収益などの指標を北極星として設定することになります。これらの主要な指標が、顧客のニーズをどのように解決するかという具体的な取り組みにつながっていきます。

エンジニアリングの観点からも、ビジネス成果を意識することは重要です。私たちは常に「ビジネスが重視する成果は何か？」という視点から考え始め、それをエンジニアとしての日々の業務にどのように落とし込んでいくかを考える必要があります。

2.2 ビジネス成果の3つの柱

ビジネス成果は主に3つの大きな領域に分類できます。

第一に、イノベーションと市場投入時間です。より多くのものを、より早く出荷し、競争力を維持することが重要です。競争優位性を失わないためにも、イノベーションは非常に重要な要素となります。

第二に、品質とカスタマーエクスペリエンスです。これは多くの組織に当てはまりますが、特に金融機関やアプリケーションなど、1分のダウンタイムが数百万ドルの損失につながるような高いSLAが求められる場合には、非常に重要な要素となります。信頼性や顧客体験の質は、ビジネスの根幹を支える要素です。

第三に、特に現在の環境において最も重要視されているのが、コストと効率性です。これは直接的に顧客ニーズに応えるものではないかもしれませんが、ビジネスにとって重要な指標の一つとなっています。

これら3つの要素は相互に排他的なものではありません。むしろ、多くの場合において相互に関連しています。例えば、信頼性に投資することで、顧客体験が向上し、同時に市場投入までの時間も短縮できる可能性があります。なぜなら、バグの修正などに費やす時間が減少するからです。このように、これらの要素は密接に結びついており、相乗効果を生み出すことができます。

2.2 ビジネス成果の3つの柱

エンジニアリングの観点から、私たちが重視するビジネス成果は大きく3つの領域に分類することができます。これらは組織の目標を達成するために不可欠な要素です。

第一のイノベーションと市場投入時間については、より多くの価値を、より早く市場に届けることが重要です。競争力を維持し、優位性を失わないためには、継続的なイノベーションと素早い市場投入が不可欠となります。これは単なるスピードの問題ではなく、市場での競争力を維持するための戦略的な要素です。

第二の品質とカスタマーエクスペリエンスは、多くの組織にとって重要ですが、特に金融機関やミッションクリティカルなアプリケーションにおいては、1分のダウンタイムが数百万ドルの損失につながる可能性があります。高いSLAが要求される環境では、信頼性とカスタマーエクスペリエンスの質が直接的にビジネスの成否を左右します。

第三に、特に現在の経済環境において最も注目されているのが、コストと効率性です。これは必ずしも直接的に顧客ニーズを満たすものではありませんが、ビジネスにとって重要な指標の一つとなっています。これは組織の持続可能性と競争力を維持するために不可欠な要素です。

これらの3つの領域は互いに排他的なものではありません。むしろ、多くの場合において相互に関連し、強化し合う関係にあります。例えば、信頼性への投資は、カスタマーエクスペリエンスを向上させるだけでなく、バグ修正などに費やす時間を削減することで、市場投入までの時間を短縮することにもつながります。このような相互作用を理解し、バランスの取れた投資を行うことが、全体的なビジネス成果の向上につながります。

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

3.1 所有権と説明責任

エンジニアリングエクセレンスは広範なトピックですが、全ての組織がどのように最高レベルで運営できるかを考えています。エンジニアリングエクセレンスの基盤となるのが、所有権と説明責任です。

所有権と説明責任は、エンジニアリングエクセレンスの取り組みの出発点となります。なぜなら、誰が何を所有し、誰が何に対して説明責任を持つのかを明確にしない限り、他のすべての取り組みが空回りしてしまうからです。最高のベストプラクティスを定義し、重要な取り組みを推進しようとしても、誰も説明責任を持たない状況では、それは単に虚空に向かって叫んでいるようなものです。

ベストプラクティスの実装においても、所有権は重要な役割を果たします。誰かがそのプラクティスの所有者となり、その実装と維持に責任を持つことで、初めて組織全体に定着させることができます。この所有権と説明責任の確立から始めることで、他のエンジニアリングエクセレンスの取り組みも効果的に推進することができます。

このように、所有権と説明責任は、エンジニアリングエクセレンスを実現するための基盤となる要素であり、これなしには他のどんな取り組みも成功することは難しいのです。

3.2 エンジニアリングエクセレンスの主要コンポーネント

エンジニアリングエクセレンスは、いくつかの重要なコンポーネントから構成されています。その主要な要素として、信頼性、運用準備態勢、セキュリティとコンプライアンス、そして標準化とガードレールがあります。これらの要素は、エンジニアリングエクセレンスを構成する異なる柱として機能します。

組織が成熟していくにつれて、これらの要素は個別の専門領域として発展していきます。例えば、セキュリティとコンプライアンスについては、専門のセキュリティチームが形成されます。信頼性に関しては、SREチームが担当します。標準化とガードレールについては、プラットフォームチームやクラウドインフラチームが責任を持つようになります。

このように、組織の成長に伴って各イニシアチブが個別のチームや専門分野として分化していく過程は自然な発展です。しかし、これらの取り組みに投資することで、私たちが重視するビジネス成果の達成に貢献することができます。各要素は独立しているように見えますが、全体として組織のエンジニアリングエクセレンスを支える基盤となっているのです。

このような組織的な発展と専門化は、プラットフォームエンジニアリングが提供する基盤があってこそ可能になります。プラットフォームエンジニアリングは、これらのエンジニアリングエクセレンスのイニシアチブを可能にする土台を構築する役割を担っているのです。

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

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

プラットフォームエンジニアリングは、3つの重要な実践が交差する地点に位置しています。その一つ目の柱が開発者エクスペリエンスです。

開発者エクスペリエンスは、組織が重視する様々なイニシアチブを優れた体験へと変換する重要な役割を果たします。具体的には、私たちが追求する開発者の生産性向上のための取り組みを、開発者が実際に使いたくなるような優れた体験へと昇華させることが重要です。

例えば、開発者がビジネスにとって正しいと分かっているプラクティスを自然に採用できるようにすること、そしてそれを通じて開発者が業務を効率的に遂行できるようにすることが求められます。これは単なる機能の提供ではなく、開発者が実際に使いたいと思える体験を作り出すことを意味します。

開発者エクスペリエンスの設計においては、開発者を「内部顧客」として捉え、彼らのニーズや行動パターンを深く理解することが不可欠です。これにより、開発者が自然に受け入れ、日々の業務の中で積極的に活用したいと思えるような体験を提供することができます。優れた開発者エクスペリエンスは、最終的に組織全体の生産性向上につながるのです。

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

プラットフォームエンジニアリングの2つ目の交差点は、プロダクトマネジメントのマインドセットです。私たちには内部の顧客がおり、その内部顧客のために製品を構築する必要があります。これは単なる技術的なソリューションの提供以上の意味を持ちます。

プロダクトマネジメントのマインドセットにおいては、内部の開発者を顧客として捉え、彼らのニーズを深く理解することが重要です。私たちは、これらの内部顧客が業務を遂行する上で直面している課題や、彼らが必要としている機能を理解し、それに基づいて製品を開発していく必要があります。

従来、開発者ツールやプラットフォームの開発者は、技術的な側面を重視する傾向にありました。しかし、プロダクトマネジメントのマインドセットを持つことで、技術的な実装だけでなく、実際のユーザーニーズに基づいた機能の優先順位付けや、ユーザー体験の向上にも焦点を当てることができます。

このアプローチにより、組織全体の課題を解決するために、プラットフォームエンジニアとしての技術的な専門知識を持つ人々に、より大きな視点からの問題解決を任せることができます。これにより、技術的な実装の excellence だけでなく、実際のビジネス成果に直接的に貢献する製品開発が可能となります。

4.3 DevOpsマインドセット

プラットフォームエンジニアリングの3つ目の要素として、従来のDevOpsマインドセットがあります。これは、私たちがこれらのイニシアチブをどのように実現するのか、自動化やツーリング、その他の技術的な側面をどのように構築していくのかという点に焦点を当てています。

DevOpsのマインドセットは、プラットフォームエンジニアリングの技術的な基盤を形成する重要な要素です。このマインドセットは、開発者エクスペリエンスとプロダクトマネジメントの考え方を技術的に実現するための方法論を提供します。自動化とツーリングは、組織の効率性を向上させ、開発者の生産性を高めるための具体的な手段となります。

例えば、インフラストラクチャーの自動化、継続的インテグレーション/デリバリーのパイプライン構築、モニタリングツールの実装など、DevOpsの実践は、プラットフォームエンジニアリングの技術的な側面を支える重要な役割を果たします。これらの技術的な実装は、プラットフォームエンジニアリングの一部として吸収され、より包括的なアプローチの中で活用されています。

このように、DevOpsマインドセットは、開発者エクスペリエンスとプロダクトマネジメントのアプローチと組み合わさることで、プラットフォームエンジニアリングの完全な姿を形作っているのです。

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

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

まず、プロダクトマネジメントの失敗モードから始めたいと思います。なぜなら、何が間違いうるのかを理解することで、成功への道筋もより明確になるからです。

最も一般的な失敗モードの一つは、エンドユーザーのニーズを想定してしまうことです。「私はエンドユーザーのことを知っている。だから、彼らが必要とするものを私が考えて作れば、きっと使ってくれるはずだ」という考え方です。「作れば、ユーザーは来る（If you build it, they will come）」というのは、プロダクトマネジメントにおいて最も危険な思い込みの一つです。

実際のところ、世界中でこのような直感的なユーザー理解ができる人は極めて少数です。ほとんどの場合、まずユーザーと対話を行い、彼らのニーズを直接理解する必要があります。これは、内部の開発者を顧客とするプラットフォームエンジニアリングにおいても同様です。

私たちの経験では、プラットフォームエンジニアが自身の技術的な理解や経験に基づいて機能を実装しても、実際の開発者のニーズとずれていることがしばしばあります。このずれを防ぐためには、実際のユーザーである開発者との継続的な対話が不可欠です。彼らが直面している具体的な課題、日々の業務での摩擦ポイント、そして理想とする開発体験について、直接的なフィードバックを得る必要があります。

5.2 ビジネス成果を見失う

プロダクトマネジメントの2つ目の重要な失敗モードは、ビジネス成果を見失うことです。最も優れた製品を作り、最高のユーザー体験を実現し、革新的な機能を実装したとしても、それがビジネス成果に結びついていなければ、誰も気にかけてくれません。

これは、スタートアップの世界でいうところの「プロダクトマーケットフィット」に似ています。つまり、あなたが提供しようとしている価値が、そもそもの取り組みを始めた理由となるビジネス成果を本当に達成しているのかという問題です。プラットフォームエンジニアリングの文脈では、作り上げたプラットフォームが組織の目標達成に実際に貢献しているかを常に評価する必要があります。

例えば、市場投入時間の短縮が目標であれば、開発されたプラットフォームの機能が実際にデプロイメントサイクルを高速化しているか、あるいは品質向上が目標であれば、プラットフォームの導入によって実際にバグやインシデントが減少しているかを継続的に評価する必要があります。

このように、プラットフォームの価値は常にビジネス成果との関連で評価されるべきであり、その評価プロセスは継続的に行われる必要があります。単に技術的な優位性やユーザー体験の向上だけでなく、それがビジネスにとってどのような価値を生み出しているのかを明確に示せることが重要です。

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

もう一つの重要な失敗モードは、単一のエンドユーザーに焦点を当ててしまうことです。これは、例えば二面市場の問題に似ています。二面市場のプロダクトを構築する場合、一方のペルソナだけに注目して他方を無視してしまうと、プロダクトの成功は望めません。

プラットフォームエンジニアリングにおいても、同じ課題が存在します。製品に複数のペルソナが関わる場合、一つのペルソナのみに焦点を当て、他のペルソナを無視することはできません。もし単一のペルソナにのみ焦点を当てると、その問題を完全に解決することはできません。

特にプラットフォームエンジニアリングでは、プラットフォームを使用する開発者、ビジネス成果を求めるエンジニアリングリーダーシップ、そして信頼性やセキュリティを担当するような中央のチームなど、複数のペルソナが存在します。これらの異なるペルソナは、それぞれ異なるニーズと期待を持っています。

したがって、すべてのペルソナのニーズを理解し、バランスの取れたアプローチで対応することが重要です。これは時として難しい判断を必要とするかもしれませんが、プラットフォームの真の成功のためには不可欠な要素となります。

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

アジャイルの考え方について、私たちは常に議論していますが、プロダクトマネジメントにおいて最も重要な失敗モードの一つは、一度にすべてを構築しようとすることです。私たちは、どのようにして最小限の実用的な製品（Minimum Viable Product）、あるいは私が好んで呼ぶところの最小限の価値のある製品（Minimum Valuable Product）を見つけ出すことができるでしょうか。

重要なのは、単に実行可能なものを作るだけでなく、実際にエンドユーザーに価値を提供できるものを作ることです。プラットフォーム全体を一度に構築しようとするのではなく、段階的に価値を提供できるようにすることが重要です。例えば、プラットフォームの特定の機能を実装し、それがユーザーにとって価値があることを確認してから、次の機能の開発に進むというアプローチです。

このような段階的なアプローチには、いくつかの重要な利点があります。まず、エンドユーザーに早期に価値を示すことができます。また、ユーザーからのフィードバックを得て、それを次の開発フェーズに活かすことができます。そして、このフィードバックループを通じて、プラットフォームの価値を継続的に向上させることができます。

これは特にプラットフォームエンジニアリングにおいて重要です。なぜなら、プラットフォームは多くのコンポーネントから構成される複雑なシステムになりがちだからです。一度にすべてを完璧に構築しようとするのではなく、価値のある最小限の機能セットから始めて、段階的に機能を追加していく方が、はるかに効果的なアプローチとなります。

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

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

プラットフォームエンジニアリングにおける最も一般的な実践の一つが、自動化とセルフサービス体験の構築です。しかし、これらの取り組みを始める前に、重要な質問をする必要があります。「何が私たちをより速い市場投入の実現を妨げているのか？」という視点からスタートすることが重要です。

まず、ビジネスにとって重要な成果は何かを考えます。例えば、市場投入の時間を短縮したいという目標があるとします。その場合、現在何が市場投入を遅らせているのかを具体的に特定する必要があります。そこには、信頼性の面での課題かもしれませんし、セキュリティの観点での遅延かもしれません。あるいは、標準化されたプラクティスの欠如が原因かもしれません。

これらの摩擦ポイントを特定したら、それをエンジニアリングエクセレンスのイニシアチブに変換します。例えば、信頼性の面で遅延が生じているのであれば、それを改善するための自動化を検討します。セキュリティの面での遅延があれば、セキュリティチェックの自動化やセルフサービス化を検討します。

このように、自動化やセルフサービス機能の開発は、具体的なビジネス成果に紐づけて考える必要があります。そうすることで、プラットフォームを通じて提供する製品体験をより適切にスコープすることができ、より効果的な解決策を提供することができます。単なる自動化のための自動化ではなく、具体的な価値を生み出す自動化を実現することが重要です。

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

クロスファンクショナルパートナーとの緊密な協働は、プラットフォームエンジニアリングの成功に不可欠です。早い段階で、SRE、セキュリティ、クラウドインフラなど、様々な組織のステークホルダーを巻き込むことが重要です。

これらのパートナーとの協働が重要な理由は、プラットフォームチームの役割が、これらの組織を支援し、彼らがエンドユーザーをより効果的にサポートできるようにすることだからです。結局のところ、私たちは全て同じエンドユーザー、つまり開発者にサービスを提供しているのです。

例えば、各専門チームは、独自のイニシアチブと目標を持っています。SREチームは信頼性の向上、セキュリティチームはリスクの軽減、クラウドインフラチームは効率性の改善を目指しています。プラットフォームチームとして、これらの目標を理解し、それぞれのチームが目標を達成できるような機能をプラットフォームに組み込む必要があります。

このような協働アプローチを取ることで、各チームのニーズを満たしながら、統合された一貫性のある解決策を提供することができます。これにより、すべてのステークホルダーが同じ方向を向いて取り組むことができ、最終的にはエンドユーザーである開発者により良い体験を提供することができます。

6.3 3つのペルソナ

プラットフォームエンジニアリングの観点から、私たちは3つの重要なペルソナを考慮する必要があります。これらのペルソナは、それぞれ異なるニーズと期待を持っており、プラットフォームはこれらすべてに対して価値を提供する必要があります。

第一のペルソナは、プラットフォームを実際に利用する開発者です。彼らは日々の業務でプラットフォームを直接利用するエンドユーザーとして、使いやすさと効率性を求めています。

第二のペルソナは、SRE、セキュリティ、そして私たちプラットフォームエンジニアのような中央チームです。これらのチームは大きなイニシアチブを任されています。例えば、「信頼性を向上させろ」「セキュリティを強化せよ」といった課題に取り組む必要があります。しかし、彼らは直接これらの改善を実施することはできず、開発者に影響を与えることで目標を達成する必要があります。

第三のペルソナは、エンジニアリングリーダーシップです。彼らは個々のマイクロサービスや詳細な実装の詳細には関心がなく、むしろビジネス成果に焦点を当てています。彼らは、「私が投資している取り組みが、実際にどのような成果をもたらしているのか？」を知りたいと考えています。

プラットフォームは、これら3つのペルソナのニーズをすべて満たす必要があります。開発者には使いやすい体験を、中央チームには彼らのイニシアチブを実現するためのツールを、そしてリーダーシップには明確な成果の可視化を提供する必要があります。このバランスを取ることが、成功的なプラットフォームを構築する上で重要な要素となります。

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

7.1 信頼性とSREチームとの連携

SREチームとの連携について、具体的な協働事例をお話ししたいと思います。SREチームは、アプリケーションが稼働しているか、信頼性は確保されているか、そしてダウンタイムによる顧客への影響は発生していないかを常に気にかけています。ダウンタイムは非常にコストがかかるため、私たちは優れた顧客体験を維持することに注力しています。

このような目標を達成するため、SREチームは開発者が素早く新しいバージョンをデプロイしたり、必要に応じてロールバックしたり、スケールアップできるようにする必要があります。ここで重要なのは、プラットフォームチームが構築するものとSREチームの目標との間に密接な関係があるということです。SREチームは、プラットフォームが提供するツールなしでは、開発者に必要なツールを提供することができません。

例えば、ランブックの自動化は良い例です。プラットフォームは、SREチームが実際に修復手順を自動化できるような方法で構築される必要があります。また、ゴールデンパスについても同様です。プラットフォームエンジニアリングでは、新しいサービスやインフラストラクチャのためのゴールデンパスを提供することがよくありますが、これは単に開発者が簡単に始められるようにするだけでは不十分です。

このゴールデンパスは、SREチームが本番環境で重視するすべてのベストプラクティスに従っている必要があります。例えば、適切なメトリクスが最初から設定されているか、必要な自動化が組み込まれているか、適切な可視性が確保されているかなどです。

このように、SREチームはプラットフォームチームが提供するセルフサービス機能の主要な支持者となります。彼らは開発者に対して「プラットフォームチームが構築したブートストラップスターターを使用すれば、SREのサポートをより早く、より効果的に受けることができます」と推奨することができます。これは、プロダクトを本番環境に可能な限り早く展開するための最適な方法となります。

7.2 セキュリティチームとの連携

セキュリティチームとの協働にも、同様の原則が適用されます。開発者のセルフサービスワークフローを考える際、よく見られる例として、ジャストインタイムの認証情報提供があります。例えば、セキュリティチームが「データベースへのアクセスを完全にオープンにするのではなく、15分間の読み取り専用アクセスを提供したい」というような要件を持っているとします。

このような要件に対して、プラットフォームチームは、セキュリティチームが目指す目標を実現しつつ、開発者にとって使いやすいシンプルなセルフサービス体験を構築することができます。これにより、セキュリティチームは私たちが構築するプラットフォームの支持者となり、開発者に対してプラットフォームの利用を推奨することができます。

ゴールデンパスについても同じことが言えます。例えば、開発者が独自にプロジェクトを開始し、サービスを立ち上げようとした場合、セキュリティレビューに2週間かかるかもしれません。一方、プラットフォームチームが提供するスターターを使用すれば、セキュリティ要件が事前に組み込まれているため、本番環境への展開に必要なセキュリティレビューは1日程度で済むことになります。

さらに、プラットフォームを通じて承認プロセスを自動化することも重要です。セキュリティチームは、ボトルネックになることを望んでいません。「リスクがあるので、すべてを停止しなければならない」という立場に立ちたくないのです。そのため、プラットフォームにこれらのタスクを自動化する機能を組み込むことで、セキュリティチームの業務効率を向上させることができます。

7.3 ゴールデンパスの実装事例

ゴールデンパスの実装は、プラットフォームエンジニアリングにおける具体的な成功事例の一つです。我々がよく目にする例として、新しいサービスやインフラストラクチャのためのゴールデンパスの提供があります。しかし、これは単に開発者が簡単に始められるようにするだけでは不十分です。

ゴールデンパスを実装する際の重要なポイントは、プラットフォームが提供するスターターを使用すると、セキュリティやSREの要件が最初から組み込まれているという点です。例えば、独自にプロジェクトを開始した場合には2週間のセキュリティレビューが必要になるかもしれませんが、プラットフォームチームが提供するスターターを使用すれば、1日程度のレビューで本番環境への展開が可能になります。

このアプローチの利点は、開発者にとって明確な価値提案となることです。SREチームやセキュリティチームは、「プラットフォームチームが構築したこのスターターを使用すれば、最速で本番環境に展開できます」と推奨することができます。これは単なる標準化以上の価値があります。すべての必要な要件が事前に組み込まれており、適切なメトリクス、自動化、可視性が最初から確保されているため、開発者は本来の開発作業に集中することができます。

このように、ゴールデンパスの実装は、標準化とレビュー時間の短縮という直接的な利点に加えて、各チームの協力関係を強化し、組織全体の効率を向上させる効果があります。

8. 成功の測定

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

プラットフォームエンジニアリングの成功を測定する際の最も重要な要素は、私たちが実際にビジネス成果の達成を妨げているボトルネックを解消できているかどうかです。プラットフォームエンジニアとして、私たちは顧客体験の向上、コストと効率性の改善、市場投入時間の短縮という主要な成果に貢献しているかを常に評価する必要があります。

これらの主要なビジネス成果を、具体的なエンジニアリングメトリクスに紐付けることが重要です。例えば、市場投入時間に関して、私たちはPRのサイクルタイムが長すぎることを特定したとします。この課題の背景には、CIが遅い、ビルド時間が長い、レビュープロセスが非効率、PRが大きすぎるといった具体的な問題があるかもしれません。

この場合、私たちはこれらの問題に対処する自動化を構築し、その効果を測定可能な形で追跡します。これにより、北極星となるビジネスメトリクスと、日々の工学的な指標を明確に結びつけることができます。エンジニアリングインテリジェンスメトリクス、サイクルタイム、DORAメトリクスなどが、この文脈で重要な測定指標となります。

重要なのは、どのメトリクスを選択する場合でも、それが最終的にビジネス成果にどのように貢献するのかを明確に説明できることです。単なる技術的な改善ではなく、具体的なビジネス価値の創出につながることを示す必要があります。

8.2 主要な測定指標

プラットフォームエンジニアリングの成功を測定するために、私たちは複数の重要な指標を活用しています。エンジニアリングインテリジェンスメトリクスとして、サイクルタイムやDORAメトリクスなどの定量的な指標を活用します。これらの指標は、開発プロセスの効率性と品質を客観的に評価するのに役立ちます。

開発者からの定性的なフィードバックも重要な指標となります。プラットフォームの使いやすさ、機能の有用性、改善要望などについて、直接的なフィードバックを収集し、分析することで、ユーザー体験の向上に活かすことができます。

採用率とオンボーディングの割合も重要な指標です。どれだけの開発者がプラットフォームを使用しているか、新しい機能がどの程度採用されているかを測定することで、プラットフォームの価値提供が実際に開発者に受け入れられているかを評価できます。

開発者の生産性と開発者体験に関するメトリクスも欠かせません。これらのメトリクスは、プラットフォームが実際に開発者の日々の業務をどの程度改善しているかを示す重要な指標となります。

これらの指標を組み合わせることで、プラットフォームの成功を多角的に評価し、継続的な改善のための具体的な方向性を見出すことができます。エンジニアリングの粒度で測定可能な指標を、ビジネス成果と明確に紐付けることで、プラットフォームの価値を組織全体に示すことができます。

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

9.1 可視性とカタログ化

プラットフォームの可視性を考える際、多くの組織では最初にスプレッドシートから始めます。組織の現状を理解し、ボトルネックを見つけ出そうとする際に、まずはスプレッドシートで情報を整理しようとするのです。しかし、このアプローチは時として6つの異なるスプレッドシートのフォークが作成され、それぞれが異なるユースケースに対応するという状況を生み出してしまいます。

数チームが数個のサービスを運用している段階では、このような管理方法でも機能するかもしれません。しかし、組織が成長し、可視性の要求が高まるにつれて、より体系的なアプローチが必要となります。ここで内部開発者ポータルの重要性が浮かび上がってきます。

内部開発者ポータルは、プラットフォームエンジニアリングの基盤となります。私たちは先ほど、所有権と説明責任、信頼性、運用準備態勢など、様々な要素について議論してきましたが、これらはすべて可視性なしには実現できません。現在、何が存在し、それらの品質はどうなのか、そしてどこにボトルネックが存在するのかを理解する必要があります。

このため、カタログから始めることが重要です。サービス、データパイプライン、インフラストラクチャの可視化を確立することで、組織全体の把握が可能となります。これは単なる情報の集約以上の価値があります。組織の現状を理解し、改善の機会を特定するための基盤となるのです。

9.2 スコアカードによる基準設定

カタログ化の次のステップとして、サービス、データパイプライン、インフラストラクチャの品質を評価するためのスコアカードの実装が必要となります。スコアカードを通じて、何が良好な状態なのかの基準を定義することができます。

私たちはよく「改善できないものは測定できない」と言います。そのため、まずベースラインを定義し、「これらがボトルネックです。そしてこのように改善していきます」という形で進めていく必要があります。内部開発者ポータルを通じて、インフラストラクチャやサービスの品質をスコアリングし、基準を設定することで、改善のサイクルを確立することができます。

スコアカードは、組織全体の品質基準を統一し、測定可能にするツールとなります。これにより、各チームは自分たちのサービスやインフラストラクチャの現状を理解し、改善に向けた具体的な行動を取ることができます。スコアカードは単なる評価ツールではなく、継続的な改善を促進するための重要な仕組みとなります。

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

内部開発者ポータルの重要な役割の一つが、セルフサービスワークフローの統合です。これは単なるワークフローの自動化以上の意味を持ちます。私たちが構築するツールの発見可能性を確保することが重要です。なぜなら、最も避けたい状況は、16の異なるツールが10の異なるアプリケーションに分散し、プラットフォームが断片化してしまうことだからです。

開発者は、必要なツールを一つの場所で見つけることができる必要があります。ポータルは単なる基盤としての役割だけでなく、開発者が構築しているツールを発見するための窓口としても機能しなければなりません。これは、スタートアップの世界でも同様の課題に直面します。私たちがこのカンファレンスに参加している理由の一つは、「私たちが構築しているものを見てください。これはとても素晴らしいものです」と、課題を抱えているユーザーを見つけることです。

プラットフォームエンジニアリングでも同じことが言えます。問題を特定し、ボトルネックを見つけ、製品を構築した後は、ユーザーがそれらを発見できるようにする必要があります。内部開発者ポータルは、エンドユーザーである開発者にこれらのツールを届けるための最適な方法を提供します。これにより、開発者は必要なツールを効率的に見つけ、利用することができ、結果として組織全体の生産性向上につながります。