Platform Engineering Maturity Modelってなに？
はじめに
先日、以下のイベントに参加しました。そこで「Platform Engineering Maturity Model」を知ったので、その概要をまとめ、実際にどのように活用するのかを考えてみます。
そもそもPlatform Engineeringってなに？
本題に入る前に一度初心にかえります。
私は「Platform Engineering」を曖昧に理解しています。DevOpsやSREなど、類似する概念の定義と重なる部分があり、境界が曖昧に感じるところがあるからです。また、組織やビジネス要件によって取り組んでいるPlatform Engineeringの範囲や目標は異なるため、厳格な定義はないように思えます。しかし、業界としてはある程度の共通理解はあるのかなと思います。
CNCF Platforms White Paperを参考にすると、Platform Engineeringを理解するには以下2つのことを知ると概要が把握できそうです。
- Platform Engineeringの目的
- 実際の活動・成果物
Platform Engineeringの目的
Platformの目的としては以下が挙げられます。
- プロダクトチームの認知負荷を軽減
- プロダクトの信頼性と回復力の向上
- プロダクト開発とデリバリーの加速
- セキュリティ、規制、機能面のリスクの軽減
他にもあると思いますが、大抵の目的は組織やプロダクトチームの生産性向上に寄与するようなものだと思います。これらを実現するためのエンジニアリング活動全般をPlatform Engineeringと呼べそうです。噛み砕いて言うと
「開発者が効率的にストレスなくソフトウェアを構築・デプロイできるようする活動」
そのような活動はすべてPlatform Engineeringになり得るのかなと考えます。
実際の活動・成果物
Platform Engineeringとは何なのかをより具体的に理解するために、CNCF Platforms White Paperを元に、実際にどのような活動をするのか、またその成果物を考えてみます。
活動例
- プラットフォームの設計・構築
- インフラの自動化
- CI/CDパイプラインの構築
- セキュリティ/コンプライアンスのインテグレーション
成果物例
- 内部開発者プラットフォーム（IDP）
- 共通のテンプレート：CI/CDのワークフロー、IaCモジュール
- 監視/可観測性のダッシュボード
- セキュリティ・コンプライアンスチェックの自動化ツール
他にも目的を実現するために行う活動や成果物は多くあるでしょう。これらを考えることで「Platform Engineering」とは何なのかが少し理解できます。
備考
DevOpsとSREの違いは以下の書籍で語られているのでぜひ（アフィじゃないよ）
Platform Engineering Maturity Modelとは
本題です。上記で言及したようにPlatform Engineeringのアプローチには様々なパターンがあります。「Platform Engineering Maturity Model」とは、それらのパターンを成熟度モデルとしてまとめたものです。この成熟度モデルには5つの特性と、それぞれに4つのレベルがあります。このモデルを使うことで、あなたの組織のプラットフォームのレベルを把握し、改善に向けた活動ができるようになります。
| 特性 | 説明 |
|---|---|
| 投資 | プラットフォームの機能に対して、人員と資金がどのように割り当てられているか |
| 採用 | ユーザーはなぜ、どのようにして内部プラットフォームやその機能を発見し、利用しているか |
| インターフェース | ユーザーがどのようにしてプラットフォームの機能と対話し、利用しているか |
| 戦略 | プラットフォームとその機能が、どのように計画され、優先順位がつけられ、開発され、維持されているか |
| 計測 | どのようなプロセスでフィードバックと学びを収集し、取り入れているか？ |
| レベル | 説明 |
|---|---|
| レベル1 | 暫定的 |
| レベル2 | 戦略的 |
| レベル3 | スケーラブル |
| レベル4 | 最適化 |
詳しくはこちらを参照していただきたいのですが、ここでは私が気になった2つの特性を抜粋して詳細を見てみます。
※ 注意点
プラットフォームにはあらゆる文脈やドメインが介在するため、このモデルが完全に当てはまるわけではありません。あなたの文脈に沿って、有益な部分を柔軟に取り入れることが重要です。まずは、あなたの組織のプラットフォームのレベルを確認し、問題を感じている場合はそこから成長させることを目指すのが良いでしょう。
採用について
ユーザーはなぜ、どのようにして内部プラットフォームやその機能を発見し、利用しているか
| レベル | 概要 |
|---|---|
| 1. 暫定的 | ユーザーはプラットフォーム機能を断片的に使う |
| 2. 戦略的 | 外部（指示・義務など）によってプラットフォーム機能の利用が促される |
| 3. スケーラブル | プラットフォーム自身の価値が認められ、ユーザーが自発的に使っていく |
| 4. 最適化 | ユーザー（あるいはアプリケーションチーム）がプラットフォームに貢献し、機能改善・拡張にも関わる |
この特性は、ユーザーがプラットフォームをどのように発見し、利用を開始するか、またその利用への動機づけがどれほど強いかを示します。レベル4において、実際の機能開発にまでアプリケーションチームを動かすことは難しいように思えますが、そんなことはありません。ユーザーには機能追加のリクエストやドキュメント改善など、小さなことから一緒に関わってもらい、共創してプラットフォームを作っていくのが良いと思います。そのためには、プラットフォームチームがアプリケーションチームのニーズを把握しながら歩み寄ることが重要だと考えます。
戦略について
プラットフォームとその機能が、どのように計画され、優先順位がつけられ、開発され、保守されているか
| レベル | 概要 |
|---|---|
| 1. 暫定的 | ユーザーからの要望に応える形で、プラットフォーム機能を追加・改善していく |
| 2. 戦略的 | 中央 (プラットフォーム組織) が機能要求をトラッキングし、優先順位を管理 |
| 3. スケーラブル | プラットフォーム機能・拡張を、組織的な目標やロードマップと照らし合わせながら支援的に運用 |
| 4. 最適化 | プラットフォーム機能が “サービス” のように提供され、継続的な最適化と運用が重視される |
この特性は、プラットフォームとその機能がどのように計画され、優先順位付けされ、開発・維持されているかを示します。レベル4は、組織が顧客に対してサービスを提供するように、プラットフォームチームがアプリケーションチームないしは組織に対してサービスを提供することです。その組織のステージによってはここまで必要ない場合もあります。
例として、Sansan株式会社のコンテナ基盤サービスのOrbitがあります。アプリケーションテンプレートの生成や、インフラリソースを生成してくれるそうです。便利そうですね。
モデルをどのように活用するか
ここからは私の妄想です。活用方法は2パターンあると思います。
プラットフォームチームがある場合
すでにプラットフォームチームが存在する場合、How to use this modelを参照し、そのまま実践すればよいでしょう。プラットフォームチームが今どの段階にいるのかを把握し、課題を見つけます。成熟度レベルが高いほど多くの資金と人々の時間が必要とされるため、無理に高いレベルを目指す必要はありません。
プラットフォームチームを導入したい場合
これからプラットフォームチームを導入したい場合、このモデルを指標とすることが優れたメトリクスになると思います。プラットフォームチームの導入によるメリットを経営層や上司に理解してもらうとともに、現在どのレベルにいて、どこを目指していきたいのかを具体的に示すことができます。
まとめ
「Platform Engineering Kaigi 2025」のイベントで、このモデルはまだ改善している的なことを言っていたような気がします。Platform Engineeringに絶対の正解はなく、業界としてまだ探り探りの状況だと思います。一つの指針として、このモデルを活用することは非常に意義がありそうです。
Discussion