10月22日と23日にEnterprise Engineering Summit 2025に参加し、ギブズの省察サイクル（Gibbs' Reflective Cycle）を使って今回の経験を振り返ることにしました。

記述

10月末に、同僚数名とともに大企業におけるプラットフォームエンジニアリングの実践に焦点を当てた2日間のカンファレンスに参加しました。他社でプラットフォームエンジニアリングがどのように導入されているかを学び、自社のプラットフォームチームの取り組みを改善するための知見を得ることが目的でした。

イベントでは、業界のエキスパートによる多彩な講演やパネルディスカッションが、以下の3つのトラックに分かれて行われました。

• プラットフォームエンジニアリング
• デベロッパーエクスペリエンス
• オブザーバビリティとSRE

私は主にプラットフォームエンジニアリングのトラックに参加し、以下のセッションを聴講しました。

感情

サミットには好奇心と期待を抱いて臨みました。私たちのプラットフォームチームでもいくつかの有用な共通ソリューションを構築してきましたが、他社がプラットフォームエンジニアリングをどのように構成し、運用しているかから学ぶべきことは多いと感じていました。

講演を聴く中で、共感と同時にもどかしさも感じました。多くの講演では、成熟したプラットフォームチームが確立されたプラクティスを持ち、プラットフォームをプロダクトとして管理する専任の役割を置くなど、潤沢なエンジニアリングリソースを抱えている様子が紹介されていました。私たちが直面している課題の多くが他社にも共通していることが分かり安心する一方で、自分たちがまだ大きく遅れをとっている現実にもどかしさを覚えました。ただ、他社が実践しているソリューションには大いに刺激を受け、それらのアイデアを自チームに持ち帰りたいという意欲も湧きました。

サミットを後にしたときは、謙虚な気持ちとこれからへの期待が入り混じっていました。プラットフォームチームを進化させるために、現実的に取り組める次のステップを考えていました。

評価

一部の講演は私たちの状況にはあまり当てはまらないと感じるものもありました。特に、厳しい規制のある業界や、豊富なリソースを持つ超大規模エンタープライズの事例は、参考にしづらい部分がありました。

一方で、さまざまなアプローチが紹介されたのは非常に興味深く、組織の規模や業界を問わず、成功しているプラットフォームチームに共通する根本的な考え方を見出せたのは収穫でした。

特に、各社がプラットフォームチームの成果をどのように指標で測っているのか、また限られたリソースでレガシーシステムを運用している企業の事例は、とても参考になりました。

分析

私は2023年に書いたブログ記事で、プラットフォームチームが抱える課題について取り上げましたが、今回その内容を振り返ってみると、サミットのテーマと重なる点が多いことに気づきます。

優先順位付け

その記事では、優先順位付けの難しさについて書きました。異なるプロダクトチームからの競合する要望のバランスを取りつつ、プラットフォームの取り組みをより広いビジネス目標に沿わせることの難しさです。

サミットでは、プラットフォームをプロダクトとして扱うことの重要性を強調する講演が複数ありました。ユーザーのニーズを理解し、それに応じて優先順位を付けることに特化した役割を置くという考え方です。例えば、TescoでHead of Product for Engineering Effectivenessを務めるBruno Suárez Laffargue氏は、開発者からのフィードバックとビジネスへのインパクトに基づいて、どのようにプラットフォーム施策の優先順位を決めているかを語りました。

エンジニアリングチームにproduct mindsetを根付かせることも繰り返し語られたテーマでした。単に機能を作ることにとどまらず、ユーザーに価値を届けることに目を向ける必要性が強調されていました。

専任のプロダクト担当を置けるだけのリソースを持つ組織もありますが、私たちの規模では、既存の役割の中にこのマインドセットをどう組み込んでいくかを模索する必要があるでしょう。

効果的な優先順位付けのためには、アンケートや指標を活用して開発者からフィードバックを集め、プラットフォーム施策の効果を測定することも重要だと指摘されていました。よく使われていたのがDXというツールで、私たちもMintelで以前導入を検討したことがあります。また、DORAメトリクスやデザインシステムの導入状況を示す指標を自作ツールで収集する取り組みも行ってきました。

スケジューリングと早すぎる共有

タイミングの難しさについても書きました。明確なニーズが生まれる前に早すぎる段階で作り始めてしまうリスクと、逆に遅すぎてプロダクトチームの足かせになってしまうリスクの両方です。

いくつかの講演では「ノーと言う」ことの重要性が強調されていました。それはプラットフォームエコシステムにおいて健全な慣行だというのです。プラットフォームチームはボトルネックになることを避けなければならず、時には全体の目標に合致しない要望や、プラットフォームに適さない要望を断ることも必要になります。

また、チームの自律性を促すことも共通するテーマでした。プラットフォームのガイドラインの範囲内で、プロダクトチームが自ら判断し、ソリューションを構築できるようにすることです。これによりプラットフォームチームへの依存を減らし、開発のスピードを上げることができます。

興味深かったのは、自律性とガバナンスのバランスを扱ったパネルディスカッションでした。Saxo Bank、SOK、Cycloidの登壇者が、各社でのバランスの取り方を語りました。印象的だったのは、「何でもサポートしようとすると、プラットフォームの抽象化が基盤となるツール自体よりも複雑になり、開発者の認知負荷を下げたいという本来の目的が損なわれてしまう」という指摘でした。

本当に使われるものを作る

作ったものが結局使われないリスクについても触れました。ユーザーのニーズに合っていない場合や、チームが自分たちで別のソリューションを作ることを好む場合です。

これは先に述べた優先順位付けの話ともつながりますが、普及曲線に関する示唆も興味深いものでした。いくつかの講演では、プラットフォームソリューションの設計・開発に開発者を巻き込む「共創」の重要性が強調されていました。そうすることで、実際のニーズに合ったものを作れるからです。

Ionut Craciunescu氏は、Utility WarehouseでマネージドなKafkaサービスへ移行する際に、プロセスの早い段階でRFCを活用し、開発者からフィードバックを集めて合意形成を図ったと語りました。この手法により、ソリューションがユーザーのニーズを満たし、導入も進みやすくなったといいます。

レガシーシステム

レガシーシステムを改善・保守するのではなく、新しいソリューションで置き換えようとする誘惑と危険性についても指摘しました。

このテーマを扱った興味深い講演がいくつかありました。Donovan Thomson氏は、Utility Warehouseで物理的な郵送からデジタル請求書への切り替えにあたり、A/Bテストを導入して効果を検証した事例を紹介しました。効果を数値で示すことで、ステークホルダーを説得できたといいます。

GroupOnのNick Simmonds氏は、GroupOnにおけるレガシーへの現実的なアプローチについて語りました。段階的な保守とコスト削減に焦点を当てる考え方です。同氏は、信頼性はeconomic decision（経済的な判断）であることや、障害が発生しても最も価値の高い機能に影響を与えずに済むcrumple zones（クランプルゾーン）をレガシーシステムの中に見極めるというアイデアについて話しました。

知識のサイロ化

最後に、プラットフォームチームがサイロ化し、他チームがプラットフォームを利用する際に日々直面する課題から切り離されてしまうリスクについても書きました。

いくつかの講演では、コミュニティを築き、チームを越えたコラボレーションを育むことの重要性が語られました。定期的な横断的コミュニティやミートアップの開催です。中には、社内のエンジニアを集めて知識やベストプラクティスを共有する独自の社内デベロッパーカンファレンスを開いている企業もありました。

チーム異動やエンジニア交換も、プラットフォームチームとプロダクトチームの間で共感と相互理解を深める有効な手段として紹介されていました。Daniel Gittins氏は、Fordでは年に一度、開発者が翌年にどのチームで働きたいかを選択できるイベントを開催し、ビジネスのさまざまな領域を経験しながらチームを越えた関係を築いていると語りました。DKBのStephane Di Cesare氏は、開発者のニーズやペインポイントを理解するための発見手法としてシャドーイングを活用していると話しました。

AIとLLM

以前の記事では触れなかったものの、今回の講演で共通して取り上げられていたのが、AIや大規模言語モデル（LLM）がプラットフォームエンジニアリングに与える影響でした。

私たちのプラットフォームソリューションが、開発者の生産性向上のためにAIツールの活用をどう支援できるかを考えるのは興味深いテーマです。Niko Kivelä氏とJacob Lärfors氏（ともにSOK）は、Backstageのような既製品ではなく、AIコーディングツールとの連携をより適切にサポートするために、自社独自のInternal Developer Portalを構築する計画について語りました。

AIコーディングツールは生産性が大幅に向上すると謳われていますが、その主張をどう測定し、検証するのかも課題です。David Graça氏は、AXAで開発生産性の指標を用いてAIツールの効果を測定している取り組みを紹介しました。

結論

他社がプラットフォームエンジニアリングにどう取り組んでいるかを聞けたことは、私にとって非常に貴重な経験でした。特に印象に残ったポイントは以下の2点です。

• プラットフォームをプロダクトとして扱うことは、効果的な優先順位付けと開発者への価値提供に不可欠です。専任のプロダクト担当がいなくても、既存の役割の中にプロダクトマインドセットを根付かせる方法を見つける必要があります。
• 開発者からのフィードバックを集め、指標を用いてプラットフォームの効果を測定することは欠かせません。プラットフォーム開発だけでなく、AIコーディングツールへの投資効果を測るためにも、より効果的にこれを行うためのツールやプロセスを検討すべきです。

アクションプラン

私の次のステップは次のとおりです。

• この内容をチーム全体で共有する
• 開発者からのフィードバック収集やプラットフォームの効果測定の方法を見直し、優先順位付けのプロセスにより組み込む方法を探る
• チームを越えたコミュニティやコラボレーションをさらに生み出す機会を見つける