PlatformCon 2023のオンライン開催もそろそろ終了の時間となってきました。 ビデオそのものは引き続き公開されると思いますが、まとめての投稿はこれが最後になると思います。
最後に選んだセッションは「How to implement a developer platform in an organization with hundreds of existing services」です。
どういったことを解決したかったのか
多数のチーム
組織内は以下のような状況でした
- 100を超えるマイクロサービスが稼働
- 複数のチーム、エリア、ロケーションに分散して開発している
- 以下で紹介するペインがあった
技術スタック
異なる技術スタックが利用され以下のような状況でした。
- チームは技術スタックを選択する権限が与えられていた
- 初期のころはうまくいっていた
- 現在は阻害要因になっている
ドキュメント
さらにドキュメントにも課題がありました
- Confluence、GitHub Wikiなど様々なところにドキュメントが散乱していた
- 異なるドキュメント標準で記述されている
- 新規加入者のオンボーディングが課題に
どうやって解決したか
これらの課題について以下のような対応をしました。
多数のチーム
数多くのチームのプロダクトオーナー等と会話をし、様々なサーベイやワークショップ等を開催し、どういった課題があり、どういったプラットフォームを求めるかの議論を実施しました。
また、そのロードマップは次の通りとしました。
- Phase 1 : PoC
- Phase 2 : MVP
- Phase 3 : Release 1 ...
小規模にはじめ、フィードバックを得ながら改善を行っていきました。
技術スタック
技術スタックについては「Fellowship」の開催により解決しました。エンジニアは3〜6ヶ月のPlatform Engineering Fellowshipに参加しその中でPlatform EngineeringやIDPについて学び実査にいくつかの機能を実現します。 こうしたFellowshipにより、新しい技術の習得機会を得るとともにPlatformの中身の理解やPlatform Engineering communityへの参加など、継続的な貢献にも繋がりました。
ドキュメント
ドキュメントについてはGitHub上でStatic site generatorを使うようにしました。先のFellowship参加者がドキュメント化の主要な役割を果たすことになりました。
KPI
Devloper portalを運営するにあたり以下のようなKPIを定義し測定しました。
- 適用したチームなどの数
- 開発やオペレーションに関わる時間
- プロダクトのインシデント数
Developer portalによってこれらの数値が改善されているということを確認しました。
まとめ
今回の例では特に「Fellowship」という部分が効果的に機能したようです。 技術も大切ですが、それを使う人（エンジニア）や組織（コミュニティ）などの育成・醸成が重要なんだなと感じます。
大きな企業でこうした取り組みをするには様々な問題があったとは思いいますが、実際に実施した事例を聞くと、自分たちもできるはずと思えます。
大変参考になる事例報告だと思います。
