※本記事は、AWS re:Invent 2024で行われた「The value of product thinking for platform teams (DOP103)」セッションの内容を基に作成されています。このプレゼンテーションは、AWSパートナーであるCircleCIによって提供されました。

登壇者のRob Zuber氏は、CircleCIのCTOとして、プラットフォームチームとプロダクト思考の融合に関する豊富な知見を持っています。本セッションでは、予算と人員が限られる中で価値提供を最大化しようとする組織におけるプラットフォームチームの役割と、その成功に向けたアプローチについて解説しています。

本記事は講演の内容を要約しておりますが、より詳細な情報や正確な文脈については、AWS re:Inventの公式サイト（https://go.aws/reinvent ）をご参照ください。また、AWSの他のイベント情報（https://go.aws/3kss9CP ）や、AWS関連の動画コンテンツ（http://bit.ly/2O3zS75 ）もご覧いただけます。

なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性がありますので、ご了承ください。

1. プラットフォームチームの基本概念と進化

1.1. "You Build It, You Run It"文化からの発展

多くのソフトウェア組織において、プラットフォームチームの進化は自然な流れでした。この進化は、"You Build It, You Run It"文化の構築過程で生まれたものです。私たちはDevOpsへの移行を経験し、エンジニアがソフトウェアを構築し、そのソフトウェアを運用する時代へと移行しました。

この移行の過程で、私たちは製品チームの認知負荷を大幅に増加させてしまいました。「あなたはソフトウェアを書くのが得意だと思っているかもしれませんが、システムの運用や、データベースの理解も必要です。そして、オンコール対応もお願いします」と、我々は製品チームに要求しました。

この認知負荷の増大は深刻な問題となりました。ソフトウェアエンジニアに対して、開発スキルだけでなく、運用スキル、インフラストラクチャーの理解、24時間体制の保守対応など、多岐にわたる能力を求めることになったのです。これは製品チームにとって大きな負担となり、本来の製品開発に集中することが困難になるという課題を生み出しました。

このように、"You Build It, You Run It"文化への移行は、エンジニアリング組織に大きな変革をもたらしましたが、同時に新たな課題も生み出すことになりました。この課題に対応するために、プラットフォームチームという新しい組織構造が生まれることになったのです。

1.2. 現状の課題（Kubernetes導入の例）

製品チームの認知負荷増大という課題に対応するため、私たちはプラットフォームチームを設立しました。その本来の目的は、製品チームが理解し管理しなければならない要素を減らすことでした。

しかし、多くのプラットフォームチームが取った施策は、実際には逆効果となりました。典型的な例が、Kubernetesの導入です。プラットフォームチームはKubernetesをデプロイし、製品チームに対して「はい、これで良くなりましたよ。今度はKubernetesも理解する必要があります」と告げました。これは製品チームにとって、全く役に立つものではありませんでした。

つまり、プラットフォームチームは製品チームの認知負荷を減らすという本来の目的に反して、新たな複雑性を追加してしまったのです。製品チームは既存の開発・運用の負担に加えて、Kubernetesという新しい技術スタックの習得と管理も求められることになりました。これでは、プラットフォームチームが設立された本来の目的である「製品チームの負担軽減」は達成されず、むしろ状況を悪化させる結果となってしまいました。この問題は、プラットフォームチームが製品チームのニーズを本当の意味で理解せずに、技術主導のソリューションを押し付けてしまったことに起因しています。

1.3. プラットフォームチームの本質的な役割

私はCircleCIのCTOとして、プラットフォームチームが真に進化すべき方向性について、3つの重要な視点から考えています。

まず第一に、プラットフォームチームは製品チームを最も重要な顧客として位置づける必要があります。私たちがKubernetesのような技術を導入する際、その目的は製品チームのサポートにあり、技術自体の導入が目的ではありません。プラットフォームチームの存在意義は、製品チームが直面している問題を解決し、彼らの業務を効率化することにあります。

第二に、プラットフォームチームの真の目的は、製品チームが本来の価値提供に集中できる環境を作ることです。私たちの役割は、製品チームがインフラストラクチャーやシステム運用の複雑さに煩わされることなく、顧客価値の創造に専念できるようにすることです。プラットフォームチームは製品チームをサポートし、彼らが組織にとって真のヒーローになれるような環境を整える必要があります。

最後に、プラットフォームチームの究極的な目標は、ビジネス全体の成功に貢献することです。私たちは製品チームの能力を最大限に引き出すことで、組織全体の価値提供を加速させる必要があります。これは単なる技術的なサポートを超えて、製品チームが顧客に価値を届けるプロセス全体を最適化することを意味します。

このように、プラットフォームチームは技術提供者としての役割を超えて、製品チームの真のパートナーとして機能する必要があります。私たちの成功は、製品チームの成功を通じて実現されるのです。

2. 優れたプロダクトを構築するための3つの要素

2.1. プロダクト思考の重要性

優れたプラットフォームを構築するためには、まず何がプロダクトとして優れているかを理解する必要があります。プラットフォームチームと呼ばれているかもしれませんが、実際には組織内の他のエンジニアのためのプロダクトを開発しているのです。

プロダクト思考を実践する上で心強いのは、すでに多くのリソースが存在することです。おそらく、皆さんの組織でも、エンドカスタマー向けのプロダクト開発について、優れたプロダクトを作るための考え方が確立されているはずです。これらの既存のプロダクト開発の知見を、プラットフォームチームの活動にも適用する必要があります。

私は製品開発に関する複数の優れたリソースから学びを得ています。Melissa Perriの「Build Trap」、Marty Caganの「Inspired」、そしてTeresa Torresの「Continuous Discovery Habits」といった著作から得られる知見は、プラットフォームチーム運営にも直接適用できます。これらの著者たちが提唱する顧客中心のアプローチ、問題発見と解決のフレームワーク、継続的なフィードバックの重要性は、プラットフォーム開発においても不可欠です。

しかし現実には、多くのプラットフォームチームは単にものを作って、エンジニアに投げつけ、それを使うだろうと想定しているだけです。これは、強力なプロダクト組織が確立してきた優れたプラクティスとは対極にあります。プラットフォームチームも、エンドユーザー向けプロダクトと同じように、顧客である製品チームの問題を深く理解し、その解決に焦点を当てる必要があります。

2.2. 成功のための環境作り

プラットフォームチームが変革を遂げ、組織のニーズに適応するためには、適切な環境づくりが不可欠です。私が最も重要視する反パターンの一つが「マンデート（強制）」の存在です。Frank氏の言葉を借りれば、「人々が外圧なしにどのように行動するかを理解したいなら、地域のDMVに行けばよい」のです。（カリフォルニアのDMVは最近かなり改善されていますが）

組織内の全員にプラットフォームチームが構築するものの採用を強制すると、プラットフォームチームは自分たちの好きなものを作るようになってしまいます。これは本来の目的ではありません。私たちは組織の問題、製品チームの問題を解決しようとしているのです。

マンデートの影響を受けると、まず第一に、18ヶ月もの期間をかけて何かを構築することになりますが、その過程で問題は何も解決されません。第二に、構築したものは顧客の問題を解決しないにもかかわらず、人々はそれを採用することを強制されます。結果として、製品チームの実際の問題は何も解決されないまま、新しい技術（例えばKubernetes）の理解という追加の負担だけが課されることになります。

競争の存在は必要です。私たちはよく「舗装された道路（paved roads）」について話をしますが、興味深いのは、顧客が同僚エンジニアである場合、それはシェフのためにレストランを開くようなものだということです。料理が気に入らなければ、彼らは自分で作ってしまいます。高いレベルのパフォーマンスが求められるのです。ほとんどのソフトウェアエンジニアは、残念なことに、自分たちでより良いものを作れると信じています。その結果、組織内に散在する複数のソリューションやオーバーヘッドという課題が生まれますが、もし私たちが本当に彼らの問題を解決できていないのであれば、彼らは自分たちで解決策を見つけ出し、私たちにより良いものを作ることを強制するでしょう。

競争は、それが内部競争であっても、私たちをより一生懸命考え、真に問題を解決しようと努力させる良い刺激となります。また、競争は外部からもたらされる可能性があります。既製品で製品チームの問題を解決できるのであれば、それは素晴らしいことです。なぜなら、私たちは次の問題に取り組むことができるからです。単に何かを構築することが仕事だと信じ、何も構築していなければ問題を解決していないと考えるのは誤りなのです。

2.3. パートナーシップの構築

プラットフォームチームと製品チームとのパートナーシップ構築は、組織全体の成功にとって極めて重要です。プラットフォームチームの仕事は製品チームをヒーローにすることであり、彼らが組織のために提供しようとしているすべての機能と価値を、より簡単に届けられるようにすることです。

私が常に話題にする「舗装された道路（paved roads）」の概念について、マウントシャスタを例に説明させてください。ある人は「Interstate 5を使ってマウントシャスタを通り過ぎたい」と考え、別の人は「マウントシャスタに登ってスキーで下りてきたい」と考えるかもしれません。製品チームが自分たちの仕事はソフトウェアを作ることだと信じ、技術への理解を広げて面白いものを作ることだと考えているなら、彼らはプラットフォームチームが作る舗装された道路に魅力を感じないでしょう。たとえそれが彼らの問題を解決するものだとしても、彼らの関心は自分のレジュメを充実させ、クールなツールを作り、技術で遊ぶことにあるからです。

しかし、製品チームがビジネスのために価値を届けることに真に重点を置いているなら、彼らはプラットフォームの機能をより多く求めて叫び始めるでしょう。「なぜこの技術の部分に私たちが対処しなければならないのか、あなたたちが解決できたはずではないか？」と。最初は静かに、丁寧に叫ぶかもしれませんが、彼らが望むのは「自分の仕事をより良くするためのサポート」なのです。

もし製品チームに顧客への価値提供に対する説明責任がない環境であれば、プラットフォームチームは失敗するでしょう。組織の一つの領域に経営陣の投資やリーダーシップの投資を行うのであれば、全員が何を達成しようとしているのかについて、その方向性を合わせることに投資すべきです。そうすることで、私たちは製品チームの本当の問題を解決することに成功できるのです。

3. プロダクト思考の実践

3.1. Build Trapの回避（Melissa Perriの知見）

Melissa Perriの著書「Escaping the Build Trap」から、私は重要な洞察を得ています。彼女はBuild Trapを「組織が成功をアウトプットではなくアウトカムで測定することにおいて行き詰まってしまう状態」と定義しています。これは、チームが自分たちの仕事は「ものを作ること」であり、顧客の問題を解決することではないと考えてしまう状態を指します。

私たちが経験してきたこと、そして皆さんの組織でも経験されているかもしれませんが、顧客の問題を解決していなければ、ビジネスは失敗します。ここで重要なのは、このような考え方をプラットフォームチームにも適用する必要があるということです。プラットフォームチームが解決しようとしている問題に対しても、同じ思考を適用しなければなりません。

Build Trapに陥らないためには、プラットフォームチームは単に機能を追加したり、新しい技術を導入したりすることを目的とするのではなく、製品チームが直面している具体的な問題に焦点を当てる必要があります。例えば、新しいKubernetesクラスターを導入することは「アウトプット」に過ぎません。真に重要なのは、その導入によって製品チームの作業効率が向上したか、開発サイクルが短縮されたか、運用の負担が軽減されたかといった「アウトカム」なのです。

プラットフォームチームが成功しているかどうかは、製品チームの成功によって測られるべきです。単にプラットフォームの機能が増えたことや、新しい技術が導入されたことではなく、製品チームがより効率的に価値を提供できるようになったかどうかが真の成功指標となります。これこそが、Build Trapを回避し、真の価値を生み出すための核心なのです。

3.2. 発見と提供の二軸（Marty Caganの理論）

私の好きな製品開発に関する参考文献の一つに、Marty Caganの著書「Inspired」があります。この本で彼は、製品提供における二つのトラックについて論じています。

第一のトラックは「発見（Discovery）」です。ここでは、私たちが解決しようとしている問題が何なのかを見極め、それをどのように解決できるかを検討します。同時に、その問題を解決することの潜在的な価値とリスクを評価します。これは単なる要件定義ではなく、真の問題の本質を理解するプロセスです。

第二のトラックは「提供（Delivery）」です。ここでは、発見フェーズで特定した問題に対する解決策を実際に構築します。ただし、これは一方通行のプロセスではありません。継続的なフィードバックを受けながら、解決策を進化させていく必要があります。

強力な製品組織は、この二つのトラックの重要性を理解し、実践しています。しかし、プラットフォームの世界では、私たちはまだ何かを作って、エンジニアに投げつけ、それを使うだろうと想定しているだけの段階にとどまっています。つまり、発見のプロセスを適切に実施せず、エンジニアが必要としているものを本当に理解しないまま、ソリューションの提供を始めてしまっているのです。

3.3. 週次カスタマータッチポイントの確保（Teresa Torresの手法）

「Continuous Discovery Habits」の著者であるTeresa Torresは、顧客との関係について重要な指摘をしています。彼女は、製品チームは最低でも週に1回は外部の顧客と接点を持つべきだと主張しています。これは、私たちが行っていることについてのフィードバックを得て、正しい方向に進んでいることを確認するために不可欠だからです。このタッチポイントは非常に小規模なものでも構いません。調査は軽量でも、自動化されたものでも、様々な形態を取ることができます。重要なのは、定期的にフィードバックを得ることです。

プラットフォームチームにとって素晴らしいのは、顧客が同じ建物内にいることです。実際の建物でなくても、比喩的な意味で「建物内」にいます。つまり、製品チームはSlackで連絡が取れ、おそらく彼らのことを知っており、場合によってはランチルームで会うかもしれません。Zoomコールで顔を合わせることもあるでしょう。顧客へのアクセスは非常に容易なのです。

多くの製品チームが直面する大きな課題の一つは、顧客へのアクセス方法を見つけ、フィードバックを提供する動機付けをすることです。しかし、プラットフォームチームの場合、顧客は隣の机に座っているかもしれないのです。このため、プラットフォームチームにとって、この週次のフィードバックループを確立することは、外部顧客を持つ製品チームよりもはるかに容易なはずです。

4. 組織環境の最適化

4.1. マンデート（強制）の問題点

私が多くのプラットフォームチームで見てきた最も大きな反パターンの一つが「マンデート（強制）」です。Frank氏の言葉を借りれば、「外圧なしで人々がどのように行動するかを理解したければ、地域のDMV（車両管理局）に行けばよい」のです。確かに、カリフォルニアのDMVは最近かなり改善されていますが、この例えは組織における強制の問題を端的に表しています。

組織全体に対してプラットフォームチームが構築するものの採用を強制すると、二つの深刻な問題が発生します。

第一に、プラットフォームチームは18ヶ月もの長期間をかけて何かを構築することになりますが、その過程で実際の問題は何も解決されません。なぜなら、彼らは自分たちの好きなものを作るだけで、途中で製品チームからのフィードバックを得る必要性を感じないからです。

第二に、構築されたものは顧客の問題を解決しないにもかかわらず、組織内の全員がそれを採用することを強制されます。この状況では、製品チームの実際の問題は何も解決されず、新しい技術やプロセスを学ぶという追加の負担だけが課されることになります。

マンデートの存在は、プラットフォームチームが組織の真の問題を理解し、解決しようとする動機を失わせます。代わりに、彼らは自分たちの技術的な興味や好みに基づいて決定を下し、それを組織全体に押し付けることになります。これは結果として、組織全体の効率性を低下させ、製品チームの不満を増大させる原因となります。

4.2. 健全な競争の必要性

プラットフォームチームの世界で、私たちはよく「舗装された道路（paved roads）」について議論しますが、競争の重要性を見落としがちです。プラットフォームチームの顧客が同僚エンジニアである状況は、シェフのためにレストランを開くようなものです。もし料理が気に入らなければ、彼らは自分で作ってしまいます。

このような状況では、非常に高いレベルのパフォーマンスが求められます。ほとんどのソフトウェアエンジニアは、残念ながら、自分たちでより良いものを作れると信じています。その結果、組織内での重複や非効率が生じる可能性がありますが、もし私たちが本当に彼らの問題を解決できていないのであれば、彼らは自分たちで解決策を見つけ出し、それが私たちをより良いものを作ることへと駆り立てるのです。

競争は、それが内部からのものであっても、私たちをより一生懸命考え、真に問題を解決しようと努力させる良い刺激となります。また、競争は外部からもたらされることもあります。既製品で製品チームの問題を解決できるのであれば、それは素晴らしいことです。なぜなら、私たちは次の問題に取り組むことができるからです。

重要なのは、単に何かを構築することが仕事だと信じ、何も構築していなければ問題を解決していないと考えるような思考から脱却することです。競争の存在は、私たちに継続的な改善と創造的な問題解決を促し、最終的には組織全体にとってより良いソリューションをもたらすのです。

4.3. 製品チームとの目標共有の重要性

組織において、プラットフォームチームと製品チームの間で共有された目標を持つことは極めて重要です。プラットフォームチームもしくはそのチームを作るエグゼクティブやリーダーにとって、組織的なサポートと社会的資本には限りがあります。これを「マンデート」に使うのではなく、より重要な課題、つまり製品チームとプラットフォームチームの目標共有に活用すべきです。

私が「舗装された道路（paved roads）」の概念を説明する際、マウントシャスタの例を使うことがあります。ある人は単にInterstate 5を使ってマウントシャスタを通り過ぎたいと考え、別の人はマウントシャスタに登ってスキーで下りてきたいと考えるかもしれません。同様に、製品チームが自分たちの仕事はソフトウェアを作ることだと信じ、技術への理解を広げて面白いものを作ることだと考えているなら、プラットフォームチームが作る「舗装された道路」がどれほど素晴らしくても、彼らはそれに魅力を感じないでしょう。なぜなら、彼らの問題は解決されていないからです。

しかし、製品チームがビジネスのために価値を届けることに真に重点を置いているなら、状況は大きく変わります。彼らはプラットフォームの機能をより多く求めて声を上げ始めるでしょう。「なぜこの技術的な課題に私たちが対処しなければならないのか、プラットフォームチームが解決できたはずではないか？」と。最初は静かに、丁寧に要求するかもしれませんが、そこには「自分の仕事をより良くするためのサポート」を求める明確な意思があります。

このような環境を作り出すため、プラットフォームチームのリーダーは、製品チームがビジネス価値の提供に対して説明責任を持つような組織文化を醸成する必要があります。そうでなければ、プラットフォームチームは失敗するでしょう。もし組織の一つの領域に経営陣の投資やリーダーシップの投資を行うのであれば、それは全員が何を達成しようとしているのかについて、その方向性を合わせることに使うべきです。そうすることで、私たちは製品チームの本当の問題を解決することに成功できるのです。

5. 効果的なパートナーシップの構築

5.1. フィードバックループの確立

これらの基盤が整っていれば、次は製品チームとプラットフォームチームの間で真のパートナーシップを構築することが重要です。ここで私たちには素晴らしい利点があります。プロダクトについて考えるとき、顧客を探し回る必要がないのです。彼らは私たちの周りにいて、フィードバックを提供することをいとわないでしょう。

プラットフォームチームは、プロダクト思考の人のように考え始める必要があります。フィードバックを受け取ったとき、ただ言われたものを作るのではなく、彼らが解決しようとしている問題を理解し、一緒に解決策を構築していく必要があります。

多くの組織でよく見られるパターンは、製品チームが目標を設定し、ビジネスに価値を提供しようとする計画を立てた後で、プラットフォームチームが現れ、「四半期の計画は素晴らしいですね。ところで、私たちのシステムに接続するために、このYAMLファイルを17個目として追加する必要があります」と言うようなものです。これは製品チームの目標に焦点を当てていません。これはプラットフォームチームが自分たちの問題を解決しようとしているだけであり、製品チームはプラットフォームチームの問題に関心を持っていません。

もし製品チームが解決しようとしている問題に関連づけて説明できないのであれば、正直に言って、その作業は製品チームから取り除くべきです。もしすべての製品チームに代わって解決する必要がある本当の問題があるのなら、製品チームに依頼するのではなく、プラットフォームチーム自身でそれを解決する方法を見つける必要があります。誰かのバックログにJiraチケット（または好みのツール）を投げ込んで、「これもP0で、すぐに必要です」と言うことで、愛情が生まれたことは一度もありません。

5.2. "Kubernetes Death Star"の教訓

最近私は、あるプラットフォームチームのリーダーと夕食を共にする機会がありました。彼は、自身が新たに参画した組織について興味深い表現を使いました。それは「Kubernetes Death Star（クーバネティス・デス・スター）」です。彼が組織に入った時、プラットフォームチームは他のすべてのプラットフォームチームがやっているのと同じことをしていました。つまり、Kubernetesのデス・スターを構築し、他の全員にそれを理解して使用するよう要求していたのです。

この状況を改善するため、彼はプラットフォームチームに対して、次の四半期で特別な目標を設定しました。数値的な指標やDORAメトリクスは一切求めず、ただ一つの目標を掲げました。それは「10件の感謝の言葉を集めること」です。これは非常にシンプルですが、重要な意味を持っています。

この目標設定により、プラットフォームチームは自然と製品チームの実際の問題に目を向け、それを解決することに注力するようになりました。その結果、プラットフォームチームは信頼関係を構築し始め、製品チームから価値を認められるようになりました。

この事例は、過度に複雑なプラットフォームが引き起こす問題と、その解決策の本質を示しています。技術的な複雑さを追求するのではなく、まず製品チームの声に耳を傾け、彼らの実際の課題に焦点を当てることで、プラットフォームチームは本来の役割を果たすことができるのです。これは「Kubernetes Death Star」から脱却し、真に価値のあるプラットフォームを構築するための重要な教訓となっています。

5.3. 信頼できるアドバイザーとしての役割確立

パートナーシップを通じて、プラットフォームチームが成功したことを示す最も明確な指標は、信頼できるアドバイザーとしての地位を確立できたかどうかです。これは、製品チームが「問題が発生したとき、誰に相談すればよいだろうか？」と考えたときに、プラットフォームチームを思い浮かべる状態を意味します。

製品チームから「私たちは問題を抱えています。これを乗り越えるためにどうすればよいでしょうか？」という質問を受けるようになったとき、それはプラットフォームチームが深い知識と理解を持ち、チームの問題解決を手助けできる存在として認識されている証です。これは「このチームが邪魔をしている、どうやってそこを回避して価値を届けられるだろうか？」という状態とは完全に異なります。

私たちは、製品チームが困難に直面したときに頼りにできる、信頼できるパートナーになることを目指すべきです。彼らの敵と戦うために呼ばれる戦友のような存在、どのような比喩を選ぶにせよ、私たちは製品チームが課題を乗り越えるための支援者となる必要があります。

このような信頼関係を構築するには時間がかかりますが、これこそがプラットフォームチームが目指すべき究極の姿です。一度この信頼関係が確立されれば、製品チームは自発的にプラットフォームチームに相談を持ちかけ、それによってさらに効果的な問題解決が可能になるという好循環が生まれます。

6. 成功指標と評価

6.1. 感謝の言葉を指標とした実験例

先ほど私が述べたプラットフォームチームのリーダーの例に戻りましょう。彼は「Kubernetes Death Star」の問題に直面した組織に入った際、プラットフォームチームに対して非常にシンプルだが効果的な目標を設定しました。それは次の四半期で10件の感謝の言葉を集めることでした。

この目標設定は非常に興味深いアプローチです。数値やDORAメトリクスなどの定量的な指標は一切使用せず、「ありがとう」という言葉を10回集めることだけを求めました。これは特に、まだ関係性が構築されていない初期段階において、プラットフォームチームの成功を測る効果的な方法となります。

なぜなら、この目標は製品チームとの信頼関係を構築することに焦点を当てているからです。感謝の言葉は、プラットフォームチームが本当に価値のある問題を解決していることの直接的な証となります。また、この目標は製品チームから積極的にフィードバックを求め、彼らの本当の問題に耳を傾けることを促します。

これによって、プラットフォームチームは「この問題は私たちが取り除くべき負担だった」というような認識を製品チームから得られるようになります。この初期段階での成功体験は、長期的な信頼関係構築の基盤となり、より複雑な課題に取り組む際の協力関係を築くことができます。単純な目標設定ですが、組織全体の協力関係を促進する効果的な方法なのです。

6.2. DORAメトリクスと効率性指標

信頼関係が構築され、感謝の言葉が集まり始めたら、次はより客観的な指標を通じて評価を行う必要があります。私の経験から、このステージではDORAメトリクスや効率性の指標が重要な役割を果たすことがわかっています。

「ありがとう」という言葉を集めることからスタートし、その関係性が確立されてから、DORAメトリクスと効率性指標の測定に移行することが自然な流れとなります。これらの定量的な指標は、プラットフォームチームが製品チームの価値提供をどの程度加速させているかを測る重要な尺度となります。

また、これらの指標は一度構築された信頼関係をベースに、より客観的な評価を可能にします。DORAメトリクスは、デプロイ頻度、リードタイム、変更の失敗率、復旧時間などを測定することで、プラットフォームの効果を数値化します。これらの指標を通じて、プラットフォームチームの取り組みが組織全体のパフォーマンスにどのような影響を与えているかを把握することができます。

ただし、これらの指標は単独で評価するのではなく、常に製品チームとの関係性や信頼関係の文脈の中で解釈する必要があります。メトリクスは改善の方向性を示す道具であり、それ自体が目的となってはいけません。

6.3. エンドカスタマーへの価値提供の加速

最終的に、プラットフォームチームは自身の仕事がエンドカスタマーへの価値提供を加速させることを理解する必要があります。これは、製品チームが直面する問題を解決し、彼らがエンドカスタマーに価値を届けやすくすることを通じて実現されます。

そのためには、プラットフォームチームが単なる技術提供者としてではなく、ビジネスの成功に直接貢献する存在として機能する必要があります。製品チームとの信頼関係を築き、彼らの問題について深い理解を持ち、それを解決できる信頼できるアドバイザーとなることで、組織全体の価値提供能力を向上させることができます。

プラットフォームチームの成功は、まず「ありがとう」という言葉で始まり、その後DORAメトリクスなどの定量的指標で測られますが、最終的には組織全体がエンドカスタマーに価値を届ける速度と質の向上として現れます。これは継続的な改善プロセスであり、製品チームとの絶え間ない対話と協力を通じて実現されます。

つまり、プラットフォームチームが本当の意味で成功するためには、技術的な卓越性だけでなく、製品チームを真のヒーローとし、彼らがビジネス価値を最大限に提供できるよう支援することに焦点を当てる必要があるのです。これこそが、プラットフォームチームの存在意義であり、最終的な評価基準となります。