以下の記事は、CNCFのプラットフォームホワイトペーパーをGeminiで翻訳したものです。
原文: https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
Cloud Native Computing Foundation (CNCF) プラットフォームワーキンググループ発表
バージョン 1.0.0 | 2023年10月31日リリース
1. はじめに (Introduction)
CNCFの初期の「プラットフォーム定義ホワイトペーパー」は、クラウドコンピューティングのための内部プラットフォームとは何か、そしてそれが企業にもたらす価値について説明しています。しかし、これらの価値を達成するためには、組織は自らに影響力のある結果と実践を熟考し、意図的に追求する必要があります。すべての組織は、たとえそれがサードパーティサービスの使用方法に関する文書に過ぎないとしても、自組織のために精巧に作られた内部プラットフォームに依存していることを心に留めておくべきです。この成熟度モデルは、そのような熟考のためのフレームワークを提供し、すべての組織が改善の機会を特定するのに役立ちます。
2. プラットフォームエンジニアリングとは何か？ (What is platform engineering?)
DevOpsが約束したクロスファンクショナルな協業に触発され、プラットフォームとプラットフォームエンジニアリングは、その協業の明示的な形態として企業内に登場しました。プラットフォームは、共通の能力、フレームワーク、および経験を選別し、提示します。本ワーキンググループおよび関連刊行物の焦点は、製品およびアプリケーションチームのような内部ユーザーの業務を促進し、加速するプラットフォームにあります。
プラットフォームエンジニアリングは、これらのコンピューティングプラットフォームを開発者とユーザーに計画し提供する実践であり、プラットフォームのすべての部分と能力（人、プロセス、ポリシー、技術、およびそれを推進するビジネス成果）を網羅します。完全な文脈を把握するためには、まずCNCFプラットフォーム定義ホワイトペーパーをお読みください。
3. このモデルの使用方法 (How to use this model)
過去数年間でプラットフォームエンジニアリングが台頭するにつれて、いくつかのパターンが明らかになりました。これらのパターンと観察結果を漸進的な成熟度モデルとして整理することで、プラットフォームチームが直面する可能性のある課題と、目指すべき機会を案内することを目指します。
各側面（Aspect）は、各レベル内で異なるチームや組織の特性を示す連続体として説明されます。読者はこのモデルで自身の位置を見つけ、隣接するレベルで機会を特定できるでしょう。
注意事項:
- 成熟度レベルが高くなるほど、より多くの資金と人員の時間が必要になります。したがって、最高レベルに到達すること自体が目標となるべきではありません。
- 読者は、必要な投資に対して、自身の組織と現在の文脈がそのレベルの特性から利益を得られるかどうかを考慮する必要があります。
- 各側面は独立して評価し、発展させるべきです。しかし、これらは複雑に相互に関連しており、ある側面を改善するためには、他の側面でも最低限のレベルに到達する必要があるかもしれません。
- 組織の現在のクラウドネイティブ移行状況を評価してください。これには「Cloud Native Maturity Model」を活用することをお勧めします。
マーティン・ファウラーは次のように述べています。「成熟度モデル評価の真の結果は、あなたがどのレベルにいるかではなく、改善のために取り組むべきことのリストです。現在のレベルは、次に習得すべきスキルのリストを決定するための中間作業に過ぎません。」
4. この作業の背景 (Context behind this work)
対象読者 (Intended audiences)
- CTO、VP、技術担当役員: デジタルトランスフォーメーションと開発者生産性向上への道を計画するリーダー。
- エンジニアリングマネージャー: エンジニアが少ないオーバーヘッドと高い効率性で価値を提供できるよう能力を付与しようとするグループ。
- エンタープライズアーキテクト: 技術的な問題に対して価値とソリューション中心の視点を求める個人。
- プラットフォームエンジニアおよびプラットフォームプロダクトマネージャー: プラットフォームの構築者とユーザーのために最高の体験を創造しようとするチーム。
- 製品ベンダーおよびプロジェクトメンテナー: ユーザーがプラットフォームを通じて成功できるよう、ツールとメッセージを設計しようとする組織。
- アプリケーションおよび製品開発者: 内部プラットフォームから何を期待できるかを詳細に理解したいユーザー。
レベルの理解 (Understanding the levels)
このモデルは、組織を完全に「レベル1」または「レベル4」に分類するためのものではありません。各側面は独立して考慮されるべきです。番号の低いレベルはより戦術的な（Tactical）ソリューションで構成され、番号の高いレベルはより戦略的（Strategic）です。これは一般的なデジタル製品開発プロセスに似ています：問題認識 → MVP開発 → 反復と適合性確認 → 拡張と最適化。
5. モデル要約表 (Model table)
| 側面 (Aspect) | レベル 1: 暫定的 (Provisional) | レベル 2: 運用的 (Operational) | レベル 3: スケーラブル (Scalable) | レベル 4: 最適化 (Optimizing) |
| — | — | — | — | — |
| 投資 (Investment) | 自発的または一時的 | 専任チーム | 製品として管理 | 活性化されたエコシステム |
| 導入 (Adoption) | 不規則 | 外部からの圧力 (Push) | 内部からの引き込み (Pull) | 参加型 |
| インターフェース (Interfaces) | カスタムプロセス | 標準ツール化 | セルフサービスソリューション | 統合サービス |
| 運用と測定 (Operations & Measurement) | リクエストによる処理 / 場当たり的 | 集中追跡 / 一貫した収集 | 集中活性化 / インサイト導出 | マネージドサービス / 定量的および定性的測定 |
## 6. モデル詳細 (Model Detail)
6.1 投資 (Investment)
従業員と資金をプラットフォームの能力にどのように配分するか？
- レベル 1, 暫定的 – 自発的または一時的: 能力は、計画的または意図的な資金提供なしに、必要に応じて構築されます。一時的に割り当てられた人員やボランティアによって維持され、ユーザーの即時的な戦術的ニーズに依存します。
- 特徴: 緊急要件処理のための「タイガーチーム」運営、改善作業は「あれば良いもの」と見なされる。従業員は本業以外の業務量により燃え尽き症候群を訴える。
- レベル 2, 運用的 – 専任チーム: 継続的なサポートのために予算と人員が割り当てられます。ソフトウェア提供速度を向上させるために共通の能力を提供する任務を負います。主に反応的な技術要件に集中し、コストセンターとして扱われ、価値の流れへの影響は測定されません。
- 特徴: 技術汎用専門家で構成され、チーム予算にインフラコストが含まれ、予算議論の中心となる。ユーザー調査を実施する時間や経験が不足している。
- レベル 3, スケーラブル – 製品として: 外部販売用製品のようにプラットフォームに投資します。プロダクトマネジメント（PM）およびユーザーエクスペリエンス（UX）に明示的に投資し、データ駆動型の指標とフィードバックループを使用してリソースを配分します。
- 特徴: PM、UXなど伝統的な技術チームにはなかった役割の配置、内部ロードマップの公開。機能削除（Feature removal）も重要な議論のテーマとなる。
- レベル 4, 最適化 – 活性化されたエコシステム: プラットフォームチームは、基本的な能力を超えて組織全体の効率性を最大化する方法を探します。コアメンテナーは、セキュリティ、パフォーマンスの専門家がプラットフォームフレームワークに直接貢献し、機能を拡張できるよう支援することに集中します。
6.2 導入 (Adoption)
なぜ、そしてどのようにユーザーは内部プラットフォームを発見し、使用するのか？
- レベル 1, 暫定的 – 不規則: 共有プラットフォームの採用が散発的で一貫性がありません。組織全体の戦略がなく、チームは内部ツールよりも外部ツールの方が効果的だと考えています。
- 特徴: 一回限りのツールが乱立、クラウドサービスが標準ポリシーなしにそれぞれ使用される、ツールの発見は口コミに依存。
- レベル 2, 運用的 – 外部からの圧力 (Push): 組織が共有プラットフォームの価値を認識し、導入を奨励します。人事評価や資金調達条件のような外部の指示が、使用を強制したりインセンティブを提供したりします。
- 特徴: 能力活用が断片的、ユーザーはプラットフォーム学習意欲が低く、ヘルプデスクに大きく依存。
- レベル 3, スケーラブル – 内部からの引き込み (Pull): ユーザーは、認知負荷の軽減と高品質という明確な価値のために、自らプラットフォームを選択します。
- 特徴: 導入が自生的に起こる、一つの能力に満足したユーザーが他の能力を探し始める。ゴールデンパスのテンプレートとセルフサービスポータルが迅速な使用を可能にする。
- レベル 4, 最適化 – 参加型: ユーザーがプラットフォームエコシステムに参加し、直接貢献（Contribution）します。既存の機能を修正したり、新しいユースケースのための機能を直接追加したりします。
- 特徴: イシューボードやPRを通じて非同期的に機能強化、開発者エバンジェリストが内部コミュニティをサポート。
6.3 インターフェース (Interface)
ユーザーはプラットフォームの能力とどのように相互作用し、消費するのか？
- レベル 1, 暫定的 – カスタムプロセス: 一貫性のない多様なプロセスが存在し、手動介入に依存します。知識は個人間で口頭で共有され、標準化が不足しています。
- レベル 2, 運用的 – 標準ツール化: 広範な要求を満たす一貫した標準インターフェースが存在します。文書やテンプレートの形で「舗装された道（Paved roads）」または「ゴールデンパス」が提供されます。
- レベル 3, スケーラブル – セルフサービスソリューション: メンテナーのサポートなしにユーザーが自律的に使用できます。ガイド付き内部言語などを通じて複雑性を抽象化した「ワンクリック」実装を提供します。
- レベル 4, 最適化 – マネージドサービス: プラットフォームの能力が、チームがすでに使用しているツールやプロセスに透過的に統合されます。可観測性やID管理はデプロイ時に自動的にプロビジョニングされます。必要に応じて深いカスタマイズが可能なビルドブロックの形で提供されます。
6.4 運用 (Operation)
プラットフォームの能力をどのように計画、優先順位付け、開発、および維持管理するか？
- レベル 1, 暫定的 – リクエストによる処理: 製品チームからの散発的なリクエストに応じて反応的に開発されます。初期の提供にのみ集中し、継続的な維持管理やセキュリティパッチの計画がありません。
- レベル 2, 運用的 – 集中追跡: 能力は中央で文書化され、発見可能です。サービスごとの所有権が明示され、中央チームがバックログを管理して維持管理状況を追跡します。
- レベル 3, スケーラブル – 集中活性化: プラットフォームチームは組織の幅広いニーズを理解し、優先順位を付けます。誰でもソリューションに貢献できる標準プロセスが存在し、継続的デリバリー（CD）を通じてアップデートが展開されます。
- レベル 4, 最適化 – マネージドサービス: すべての能力のライフサイクルが標準化され、自動化された方法で管理されます。アップデートはユーザーに影響を与えることなく継続的に提供され、明確な「責任共有モデル」が存在します。
6.5 測定 (Measurement)
フィードバックと学習を収集し、反映するプロセスは何か？
- レベル 1, 暫定的 – 場当たり的 (Ad hoc): 使用量や満足度指標がほとんど収集されず、決定は断片的な要件と不完全なデータに基づいています。
- レベル 2, 運用的 – 一貫した収集: ユーザーフィードバックを構造的に収集することを重視します。アンケートやフォーラムが標準化され、ユーザーエクスペリエンスがデータで計測されます。
- レベル 3, スケーラブル – インサイト導出: 特定の戦略的インサイトを得るために、洗練された方法でデータを収集します。業界フレームワーク（DORAなど）を活用してパフォーマンスを測定し、ロードマップに反映します。
- レベル 4, 最適化 – 定量的および定性的測定: フィードバックと測定が組織文化に深く統合されます。データが民主化され、すべての利害関係者が仮説の構築と検証に参加し、定性的な変化が定量的な指標改善とどのように関連するかを把握します。
7. 結論 (Conclusion)
プラットフォームとそのメンテナーは、アジャイルなデジタル製品開発のための基盤を提供します。これらは、効率的なソフトウェア開発と改善を可能にする一貫した能力の集合体を提供します。この成熟度モデルは、皆様のプラットフォームエンジニアリングの旅の地図となるでしょう。
コメントを残す