私は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の登壇者が、各組織でこのバランスをどう管理しているかを議論しました。印象的だったのは、あらゆるものをサポートしようとすると、プラットフォームの抽象化が基盤となるツール自体よりも複雑になってしまい、開発者の認知負荷を下げようという本来の目的が損なわれてしまうという指摘でした。

実際に使われるものを作る

作ったものが結局使われないリスクについても書きました。ユーザーのニーズを満たしていないか、チームが自分たちで独自のソリューションを作ることを好むために起こることです。

これは先に述べた優先順位付けの論点ともつながりますが、普及曲線（adoption curve）に関する興味深い指摘もありました。いくつかの講演で、プラットフォームソリューションが実際のニーズを満たすように、開発者を設計・開発の段階から巻き込む「共創（co-creation）」の重要性が強調されました。

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ツールを活用して開発者生産性を高めるために、私たちのプラットフォームソリューションがどのようにそれを支援できるかを考えるのは興味深いことです。SOKのNiko Kivelä氏とJacob Lärfors氏は、Backstageのような既製品を使うのではなく、AIコーディングツールとの統合をより良くサポートするために、自社独自のInternal Developer Portalを構築する計画について語りました。

AIコーディングツールは生産性向上について大きな期待を謳いますが、その主張をどのように測定し、検証するのでしょうか。David Graça氏は、AXAでAIツールのインパクトを測定するために開発者生産性メトリクスをどのように活用しているかを紹介しました。

結論

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

• プラットフォームをプロダクトとして扱うことは、効果的な優先順位付けと開発者への価値提供に不可欠です。専任のプロダクトエンジニアリングの役割がなくとも、既存の役割の中にプロダクト思考を組み込む方法を見つける必要があります。
• 開発者からのフィードバックを集め、メトリクスを用いてプラットフォームのインパクトを測定することは不可欠です。プラットフォーム開発のためだけでなく、AIコーディングツールへの投資効果を測るためにも、これをより効果的に行うためのツールやプロセスを模索すべきです。

アクションプラン

私にとっての次のステップは以下の通りです。

• この考えをチームのメンバーと共有する
• 開発者フィードバックの収集方法やプラットフォームのインパクト測定のあり方を見直し、それらを優先順位付けのプロセスにより組み込む方法を探る
• チーム横断のコミュニティやコラボレーションをより促進する機会を見つける