プラットフォームエンジニアリングの成熟度モデル

イントロダクション

CNCFの最初の プラットフォームホワイトペーパーでは、クラウドコンピューティングのための内部プラットフォームとは何か、そしてそれが企業に提供する価値について説明しています。しかし、その価値を実現するためには、どの組織も自組織のために作られた内部プラットフォームに依存していることを念頭に置きながら、組織にインパクトのある成果やプラクティスを熟考し、意図的に追求する必要があります。それが、サードパーティ製サービスの使用方法のドキュメントに過ぎないとしてもです。この成熟度モデルは、その熟考のためのフレームワークを提供し、あらゆる組織に対して改善の機会を見つけるための手助けをします。

プラットフォームエンジニアリングとは何か

DevOpsによって約束される部門横断的な協力に触発され、プラットフォームやプラットフォームエンジニアリングが、企業においてその協力の明確な形として登場しました。プラットフォームは、共通の機能1、フレームワーク、および体験を収集、整理し提供します。このワーキンググループおよび関連文書の文脈では、プロダクトチームやアプリケーションチームなどの 内部ユーザーの作業を促進し、加速するプラットフォームに焦点を当てています。

プラットフォームエンジニアリングとは、開発者やユーザーに対してそのようなコンピューティングプラットフォームを計画し提供するプラクティスです。これには、プラットフォームおよびその能力の総体、つまり人、プロセス、ポリシー、テクノロジーに加え、それらを推進するために望まれるビジネス成果も含まれます。

最初に、完全な背景を理解するために、 CNCFプラットフォームホワイトペーパーをお読みください。

このモデルの使い方

プラットフォームエンジニアリングがここ数年で注目されるようになると、いくつかのパターンが明確になってきました。これらのパターンと観察を漸進的な成熟度モデルにまとめることで、 プラットフォームチームが直面するかもしれない課題や目指すべき目標へと向けることを目指しています。 各特性は、その特性の各レベルにある個々のチームや組織の特徴の連続体として説明されます。読者は、このモデルにおいて自身がどのレベルに位置するかを見極めるとともに、隣接するレベルの目標を把握することが期待されます。

特筆すべきこととして、より高いレベルの成熟度ほど、より多くの資金と人々の時間が必要とされます。したがって、最高レベルに達すること自体を目標とすべきではありません。各レベルは、その段階で現れるべき品質を表しています。読者は、自らの組織と現在の状況において、必要な投資に対してこれらの品質から利益を得られるかどうかを検討する必要があります。

各特性は独立して評価され、進化することを意図していることを念頭に置いてください。しかし、どんな社会技術システムでも同様に、これらの特性は複雑で相互に関連しています。したがって、ある特性を改善するためには、別の特性でも最低限のレベルに達している必要があるかもしれません。

プラットフォームの実装が組織ごとに異なることを認識することも重要です。 あなたの 組織のクラウドネイティブへの変革の現状を評価することを確実に行ってください。この評価に活用できる素晴らしいリソースは、 クラウドネイティブの成熟度モデルです。

最終的にこのモデルは組織に対して、意図的な計画を通じて、プラットフォームエンジニアリングの規律と、成果としてのプラットフォームを成熟させることを奨励しています。このような計画と規律自体が、成熟したプラットフォーム開発と継続的な進化に必要です。

一般的に、組織をモデルにマッピングすることは、現状を把握し、漸進的な反復と改善を 可能にする ために行うということを忘れないでください。 マーティン・ファウラーはこの点についてうまく言及しています。「成熟度モデル評価の真の成果は、あなたがどのレベルにいるかではなく、改善のために取り組む必要がある事項のリストです。あなたの現在のレベルは、次に獲得すべきスキルのリストを決定するための中間作業に過ぎません。」その意味で、モデルの中で自分自身を見つけ、隣接するレベルでの目標を特定するように努めてください。

本文書の背景

文書がどのような背景で書かれたかを理解することは価値があります。以下のセクションでは、モデルの背後にあるいくつかの背景と、読者であるあなたに対して期待する点を説明します。

想定読者

各読者は独自の文脈を持ち、このモデルから独自の学びを得るでしょう。以下に、我々が想定するいくつかのペルソナと、このモデルに対するそれぞれの動機を示します。

  • CTO、VP、技術部門のディレクター: デジタルトランスフォーメーションと開発者の生産性向上への道筋を描くことを目指すリーダーたち
  • エンジニアリングマネージャー: エンジニアがより少ないオーバーヘッドと高い効率で価値を提供できるよう支援を求めるグループや個人
  • エンタープライズアーキテクト: 現代の技術環境を先導し、技術問題に対して価値志向かつソリューション志向の視点を求める個人
  • プラットフォームエンジニアおよびプラットフォームプロダクトマネージャー: プラットフォームの構築者と利用者にとって、最良の体験を構築しようとするチームや個人
  • プロダクトベンダーおよびプロジェクトメンテナー: ユーザーがプラットフォームと機能で成功を収めるために、ツールを設計したりメッセージを届けたいと考える組織やエンジニア
  • アプリケーションおよびプロダクト開発者: 内部プラットフォームに対して何を期待できるかをより詳細に理解しようとするプラットフォームユーザー

レベルについて理解する

このモデルは、組織やプラットフォームチームを「レベル1」や「レベル4」に完全に分類することを意図したものではありません。各特性は他の特性とは独立して検討されるべきです。つまり、各レベルにおける特徴はその特性における連続体をなしていますが、必ずしも同じレベルの他の特性と結びついている必要はありません。さらに、多くの組織では、チームや仕事に対して、1つ以上のレベルの特徴が当てはまるでしょう。というのも、どのレベルも本質的に良い悪いがあるわけではなく、チームの目標に対するコンテキストに依存するものだからです。

各レベルのラベルは、あなたの組織においてプラットフォームエンジニアリングがもたらすインパクトを反映することを意図しています。あるレベルであなたの組織を認識することで、次のレベルに続く機会への洞察を得られます。低いレベルはより戦術的なソリューションであり、高いレベルはより戦略的なソリューションです。

これは、他のデジタル製品開発と同様の、プラットフォーム開発と成熟のための潜在的なプロセスをもたらします。まず、問題と新しい解決策の必要性を認識し、次に仮説としての最小限の実用的な製品を開発し、第三に、問題をより良く解決し、顧客により適合するように反復を行い、最後に、多くのチームやユーザーの問題を解決するために製品を拡大し最適化します。

CNCFのクラウドネイティブの成熟度モデルと同様に、このモデルは、成功するビジネス成果は人、プロセス、ポリシーと技術をバランス良く組み合わせることによってのみ達成できることを強調しています。特に、このモデルは、しばしば単一の内部チームの範疇に完全には収まらない特性を導入しており、むしろエンジニアリング部門全体、そして多くの場合、さらに幅広い組織の協力を必要とします。

ですが、うまく当てはまるように思えません

それは全く問題ありません!すべての組織やグループには、それぞれ固有のダイナミクスやパラメータがあります。

この文書の目的は、厳格な公式を示すことではなく、自身の状況に適用できるフレームワークを提供することです。すべての言葉があなたにとって適切とは限りませんが、このコンテンツがあなた自身のプラットフォームの旅を振り返り、有益な部分を取り入れ、そうでないものは捨て置いていくきっかけになることを願います。

このモデルの目的は、プラットフォームエンジニアリングの実務者、ステークホルダー、その他の関係者が彼らの旅路を導くためのツールを提供することです。プラットフォームの設計と実装は厳密な科学ではなく、個々のプロジェクトや組織のニーズ、特定の時間や場所に依存します。

モデル表

特性
暫定的である戦略的であるスケーラブルである最適化している
投資プラットフォームの機能に対して、人員と資金がどのように割り当てられているかボランティアまたは一時的専任チームプロダクト活発なエコシステム
採用ユーザーはなぜ、どのようにして内部プラットフォームやその機能を発見し、利用しているか一貫していない外部からの動機づけ内発的な動機づけプロアクティブな参加
インターフェースユーザーがどのようにしてプラットフォームの機能と対話し、利用しているか機能毎に独自の手順標準ツールセルフサービスのソリューション統合されたサービス
戦略プラットフォームとその機能が、どのように計画され、優先順位がつけられ、開発され、維持されているかリクエストに応じて中央集権的な追跡中央集権的な支援マネージドサービス
計測どのようなプロセスでフィードバックと学びを収集し、取り入れているか?アドホック一貫性を持った収集洞察の獲得定量的かつ定性的

モデルの詳細



結論

プラットフォームとその管理者は、アジャイルなデジタル製品開発の基盤を提供します。これらは、効率的なソフトウェア開発とデリバリーを可能にする一貫した能力の集合を提供します。この成熟度モデルは、プラットフォームエンジニアリングの旅のための地図を提供します。


  1. 原文では、プラットフォームに含まれる個々の機能を「Functionality」、プラットフォームが提供するより大きな単位のサービス(例:CI/CDサービス、マネージドデータベースサービス)や全体的な開発者体験、価値を指して「Capability」という単語を用いています。本文書では、ほとんどの場合どちらも「機能」と表現していますが、両者を区別したい文脈においては、後者を「能力」と訳すことにします。 ↩︎