本記事は enechain Advent Calender 6日目の記事です。
はじめに
こんにちは！Platform Engineering Desk(以降PED)でEMをしている大隈（@kumashun88）です。今年1月に入社した自分の立場から、PED発足後一年半の道のりを振り返ろうと思います。
振り返りは、先日の Cloud Native Days Winter 2025 プレイベント で登壇した内容をベースにしています。詳細は以下の資料をご覧ください。 speakerdeck.com
2024/06 PED発足
CTOの須藤が書いたブログにある通り、SREがインフラの何でも屋さん状態になっていた問題を打破するために、異なるミッションを持った別チームとして分割したのがPEDの始まりです。チーム分割によって、開発者の業務の一部をパッケージ化したプラットフォームを提供することで、開発者体験の向上を目指すという、Platform Engineeringの思想を取り入れたことになります。
| チーム | ミッション | チームタイプ | インタラクションモード |
|---|---|---|---|
| SRE Desk | 全プロダクトのReliability向上に責任を持つ | イネイブリングチーム | ファシリテーション（定常時）, コラボレーション（プロダクト開始時や重要機能実装時） |
| Platform Engineering Desk | プラットフォーム領域において、各開発チームの開発者体験の最大化に責任を持つ | プラットフォームチーム | X-as-a-Service |
発足当初の効果として、チームごとに明確なミッションを持つ状態になったことで、将来像を描いた上で、先を見据えた判断ができる状態になりました。
2025/01 直面していた課題
自分がPEDにjoinしたのは発足から半年後です。兼任を除くとチーム初の正社員として、メンバーがより良い環境で働ける体制を整えるべく、現状の課題を洗い出すことにしました。日々の業務や定例会議でのメンバーの振る舞い、開発者向けヒアリングを通じて、大きく2つの課題が見えてきました。
- ユーザー目線の欠如
- PDCAを回せていない
ユーザー目線の欠如
チームとして半年間いくつかの施策を実施していましたが、プロダクトチームに対して「なぜやるのか」という目的が十分に伝わっていませんでした。
またプロダクト向けのガイドラインが少なく、意思決定の経緯も見えにくい状態でした。プロダクトチームからすると、どんな機能を提供しているのか分かりにくく、プラットフォームの価値を届けきれていないという問題が生じていました。ヒアリングの結果を抜粋していますが、すでにプラットフォームとして提供しているインフラコード管理の仕組みについて、方針やベストプラクティスが伝わっていなかったことが分かります。
PDCAを回せていない
提供しているプラットフォームに対して、フィードバックや意見を集める習慣がありませんでした。継続的に評価する指標もなく、プラットフォームをプロダクトとして捉えたときのPDCAサイクルが回せておらず、継続的な開発者体験向上に貢献できていませんでした。
チームの方向性として開発者体験の向上という領域に舵を切れていたものの、現場でのPlatform Engineeringの実践は十分に行えていない状態だったのです。
~ 2025/09 課題へのアプローチ
課題へのアプローチとして、チームトポロジーからプラットフォームのベストプラクティスを汲み取り、対応する施策を計画しました。導出の流れは冒頭に載せたスライドをご参照ください。
| 課題 | ベストプラクティス | アプローチ |
|---|---|---|
| ユーザー目線の欠如 | プロダクトチームと密接に関わる | アンケートを継続し、オフィスアワーを開催 |
| 作ったものを実際に使い、手本を示す | 自分たちがユーザーでもあるプラットフォームの改善から始める | |
| 新技術採用における責任を明確にする | 意思決定フローの見直し、チーム内外向けストック情報の整備 | |
| PDCAが回せていない | プロダクトチームを巻き込んで、FBループを回す | 早い段階からプロダクトチームを巻き込んで施策を進める |
| 定期的にユーザビリティを評価する | 簡単な指標からチームの目線を揃える |
いくつかピックアップして紹介します。
意思決定フローの見直し / チーム内外向けストック情報の整備
意思決定におけるユーザー目線の欠如を解消すべく、過去のプラットフォーム領域の意思決定を棚卸ししました。プロダクトチームに経緯を説明できないものについては、現状をもとにArchitecture Decision Record (ADR)を作成し、方針を再定義しました。いわゆる「歴史的経緯」で存在する暗黙のルールを放置しないマインドです。
新規の意思決定については、開発組織全体に影響しそうなADRの場合プロダクトチームにもレビューを依頼し、積極的に意見を取り入れるようにしています。
また、それらがベースにもなるストック情報の整備も行いました。弊社はドキュメント管理にNotionを使っているのですが、プロダクト開発者向けの資料とプラットフォーム開発者向けの資料で置き場所を分け、認知負荷の低減を図っています。加えて、Notion WikiのVerifation機能を使って有効期限を設定することで、情報の陳腐化を防ぐ運用をしているのもポイントです。
早い段階からプロダクトチームを巻き込んで施策を進める
施策の目的と効果を事前に説明し、プロダクトチームの納得を得てから取り組むようにしました。その際、単に作業内容を伝えるだけでなく、リリース速度向上やレイテンシ改善といったユーザー体験・ビジネスへの影響を示すことで、プロダクトチームに作業が必要な場合でも積極的に施策を進めてもらえるように意識しています。
今年取り組んだShared VPC移行という施策は、全プロダクトチームを巻き込んだインフラ作業でした。コンテキストが全くない開発者にもWhyが伝わるように、かつBefore/Afterとしてどんなプラスの影響があるのかをまとめた資料を展開しました。
施策完了後は振り返り会でKeepやTryを創出し、再現性の高いものはチームOKRの進め方に組み込みました。例に挙げたShared VPC移行での振り返り会にて、この(事前にコンテキストを伝え、メリットを伝えてから進めるという)取り組み自体がKeepとして評され、以降PEDで施策を進める際の振る舞いの標準になっています。
簡単な指標からチームの目線を揃える
開発生産性の評価指標としてFour Keysなどが挙げられますが、計測の仕組みがいきなり用意できるわけではありませんし、開発組織の現状に適した指標であるかを考慮する必要があります。 そこで改善サイクルをまず回すために、プロダクトチームからの問い合わせ数や傾向のような、現状から簡単に取れる数字、データを追いかけることにしました。
具体的には、チームの週次定例で直近一週間来た問い合わせを振り返る時間を設けました。同じような問い合わせが毎回リストされる場合にはNext Actionを創出し、問い合わせ件数の削減を図っています。また問い合わせによっては対応が属人化しているものもあるので、この場でナレッジシェアをしたり、自動化の検討について議論することもあります。
EMとして意識したこと
アプローチ以外にも、EMとして意識したことを紹介します。
チーム内では、先ほどのアプローチを実践できる体制を整えました。期待する振る舞いを明確に伝えることが、全員への浸透には欠かせません。そのため、メンバー間でフィードバックし合えるカルチャーの醸成にも取り組みました。定例会議のアイスブレークを当番制にしたり、定期的なレトロスペクティブを実施することで、特定のメンバーだけが発言する状態を避け、チーム内のコラボレーションを円滑にしました。
また、定期的なチームビルディングの開催など、オフラインコミュニケーションの場を積極的に設けています。特にPEDは正社員と業務委託の方の混合チームなので、オフラインで交流する機会を少なくとも四半期に一度必ず作っています。柔軟な働き方を尊重することが前提ですが、メンバー同士が直接顔を合わせる機会の有無は、普段のコラボレーションのしやすさに大きな差をもたらすはずです。
そうした取り組みの結果、業務形態に関係なく、多様な意見がチームで生まれています。直近開催したハッカソンでは、事前のアイデア出しで全員の意見が出揃うようになるなど、チームとしてフラットな雰囲気を醸成できました。
チーム外では、個別ヒアリングや偶発的なコミュニケーションを大切にし、建設的な意見をチームで取り組むべき課題へと昇華させることを意識しています。こちらもオフラインコミュニケーションは大事にしていて、ラフにランチや1on1で意見交換する機会も多いです。
ちなみにenechainには、オフィスで2人以上集まるとオフィスにあるドリンクで「ちょい飲み」できる制度があります。ちょい飲み文化のおかげで、壁ができがちなプロダクトチームとプラットフォームチーム間のディスカッションをラフにできる機会に繋がっています。
2025/11 アプローチの結果
アプローチを続けて半年ほどですが、チーム体制は徐々に改善されました。
ユーザー目線が欠如しているという課題がありましたが、導入前の説明や導入後のガイドライン整備を徹底する進め方がチームに定着し、プロダクト開発者の目線を持ってプラットフォームの価値を届けるサイクルができました。
PDCAについては、個人の頑張りではなく、チームとして改善サイクルを回すカルチャーが定着したことで、開発者体験向上につながる改善を継続して実施できています。メインの施策を進めてきた結果もあるのですが、実際チームへの問い合わせ数は減少傾向にあり、日々の改善業務の成果だと思います。
2025/12 次のフェーズへ
自分の入社以降、優秀なメンバーのjoinが続いたことも後押しとなり、チームとしては次のフェーズ、非連続的なプラットフォーム開発に取り組む準備を始めています。象徴的な取り組みを2つ紹介します。
Golden Pathの強化
弊社では元々簡素なGolden Pathとして、テンプレートベースのシェルスクリプトで初期インフラコードを生成するツールは存在していました。それをIDPライクなサービスカタログモデルにリアーキするプロジェクトが進行中です。開発者がより操作しやすく、かつ多彩なパラメータ設定によって、シェルスクリプトよりも柔軟に必要なインフラコードを生成できるように開発を進めています。
詳細については、先月PED所属の遠藤がアーキテクチャカンファレンス2025で登壇した資料をご覧ください。
IngressからGateway APIへの移行
enechainは古くからGKEクラスタ上でプロダクトを運用しており、標準的なインフラ構成は普遍的なものになっています。ロードバランサーを担うコンポーネントとしてはIngressを利用していますが、これを次世代版のGateway APIに刷新することで、現在では実現できない高度なトラフィック制御を可能にさせる予定です。
ほぼ全てのプロダクトで利用されているコンポーネントであるため、先ほど例に挙げたShared VPC移行同様、プロダクトチームと密にコミュニケーションをとり、段階的な移行計画を立てています。
おわりに
体制面の話が中心ではありましたが、PED発足後の一年半を振り返りました。今回紹介したアプローチに加え、採用も順調に進んだことで、非連続的なチャレンジができる状態が整ってきました。2026年はPEDにとって、さらに飛躍の年になると確信しています。
弊社には、大胆に発想し挑戦することを指す「Fly High」というValueがあります。今後もユーザーである開発者の目線を常に意識しながら、Fly Highを体現するプラットフォーム開発を進めていくので、アウトプットの発信を乞うご期待ください！
もちろん、SREやPlatform Engineering領域での挑戦を一緒に取り組んでくれる仲間も募集中です。要項は以下からご確認ください！
enechain Advent Calender 6日目、最後まで読んでいただき、ありがとうございました。明日7日目はkonatu_pさんの、デザインシステムのアップデートをしやすくするMCPサーバに関する記事です。お楽しみに！
