プラットフォーム・エンジニアリングの概要を自分なりにまとめてみた
はじめに
近年のトレンドであるプラットフォーム・エンジニアリングが出現したため、自分なりの解釈を入れながら、概要をまとめてみました。本プログに記載している内容は、筆者の主観が入っているため、必ず正しいものではございません。
プラットフォームエンジニアリング
では、プラットフォーム・エンジニアリングとは何か。この章で、概要と自分なりの解釈を入れて説明します。
概要
ガートナーによれば、
プラットフォーム・エンジニアリングは、インフラストラクチャ・オペレーションの自動化とセルフサービス機能により、開発者エクスペリエンスと生産性を向上させます。開発者エクスペリエンスを最適化し、プロダクト・チームによる顧客価値のデリバリを加速させることが期待できるため、大きく注目されています。[1]
とのことである。
[1] プラットフォーム・エンジニアリングとは何か？ | ガートナー
成果
プラットフォーム・エンジニアリングの成果は、「 開発者エクスペリエンスと生産性の向上」である。ただ、これだと曖昧な定義だと思うので、CNCFのホワイトペーパーから紐解いてみたい。CNCFでは以下の記載がある。
製品チームの認知的負荷を軽減し、それによって製品の開発と提供を加速します。[2]
[2] CNCF Platforms White Paper | CNCF TAG App Delivery
近年、技術の発展により、プラットフォームとしてコンテナやKubernetesの普及であったり、TektonやArgoCDなどCI/CDツールの進化など、アプリケーション開発者は違う領域の技術のキャッチアップが必要になってきた。日々、プロダクトの価値をエンドユーザに届けるために、開発者はプロダクト開発する中、これらのキャッチアップを行い、実際にプラットフォームとして使い、価値をデリバリーしている。
このような状況下で、プロダクト開発者は本当にプロダクトの価値を届けるために、それらの技術をキャッチアップするために多くの時間を費やすことができるのだろうか。おそらく多くの場合は、キャッチアップに労力がかかっている状況だと思う。そのため、プラットフォーム・エンジニアリングにより、プロダクト開発者の認知負荷を下げることで、プロダクトの開発と提供を加速させることが成果になるのではないだろうか。
手段
では、プロダクト開発者の認知負荷を削減する手段は何があるだろうか。現在、認知され始めた手段としては以下である。
- Platform as Product
- プロダクトマネジメント
- セルフサービス化
- 内部開発者プラットフォーム (IDP: Internal Developer Portal)
戦略として、プラットフォームをプロダクトとみなし、それをプロダクト開発者に提供するPlatform as Productがあるようだ。戦略をとる手段として、従来のプロダクトマネジメントやセルフサービス化、多くのベンダーが提唱し出したIDPが含まれている。おそらく数ヶ月経てば、新たな手段が出現するのではないだろうか。
最後に
多くのIT組織がプラットフォーム・エンジニアリングをキャッチアップしている最中だと思う。ただ、私は特定の技術を使ったプラットフォームの提供やIDPのみ取り組むことだけは避けたい。プラットフォーム・エンジニアリングを始める組織が、プロダクトマネジメントの組織文化や組織体制などを検討し、実践していくことが大切なのではないかと思っている。
