プラットフォーム エンジニアリング機能モデル

  • 20 分

プラットフォーム エンジニアリングは開発段階です。 一般に、大規模で即時的な実施を試みたり、トップダウンの命令のみに依存するよりも、段階的で反復的なアプローチの方が効果的です。 実用最小限の製品 (MVP) から始める段階的な進歩により、チームは途中でフィードバックを取り入れながら、時間をかけてアプローチを微調整することができます。

プラットフォーム エンジニアリング ライフサイクルは、プラットフォームの信頼性、スケーラブル、継続的な改善を保証するための構造化されたアプローチです。 このライフサイクルには個別の段階があり、それぞれがプラットフォームの長期的な成功に貢献します。

ライフサイクルの重要な要素は、 プラットフォーム エンジニアリングの取り組みを評価、計画、実装するための包括的なフレームワークを提供するプラットフォーム エンジニアリング機能モデルです。 このモデルは、成熟度レベル、ベスト プラクティス、ライフサイクルの各段階で必要とされる重要な機能を概説し、組織の目標やユーザーのニーズとの整合性を確保します。

このモデルでは、 初期、 反復可能、 定義、 管理、最適化の 5 つの段階にわたる成熟したプラットフォーム エンジニアリング プラクティスの進行状況 を概説します。 初期段階では、組織の構造は限られており、アドホック プロセスとプラットフォーム機能への投資は最小限です。 反復可能な段階に進むにつれて、基本的なプロセスが出現しますが、導入とガバナンスは一貫性が保たれます。 定義済みのステージは、明確な標準とプロセスの確立を示し、ユーザーは意図的にプラットフォーム ソリューションを採用し始めます。 マネージド ステージでは、プラットフォームが積極的に管理され、リソースが効率的にプロビジョニングおよび管理され、標準化されたインターフェイスを通じてユーザーの対話が一貫しています。 最後に、 最適化 ステージでは、堅牢なフィードバック メカニズム、測定された結果、ユーザーのニーズと組織の目標に合わせたアダプティブ機能によって、プラットフォームが継続的に改善されます。

このモデルは、リソースと資金の割り当てを反映した 投資という 6 つの機能に基づいて評価されます。ユーザーの検出と使用率に重点を置いた 導入。 ガバナンス、リソースのアクセシビリティ、コスト管理、およびデータ/IP 保護の確保。 プロビジョニングと管理、リソースのデプロイと保守方法の定義。 インターフェイス。プラットフォームとのユーザー操作に対処します。と 測定とフィードバック。パフォーマンス メトリックとユーザーの分析情報を通じて継続的な改善を強調します。 これらの機能は、 Cloud Native Computing Foundation のプラットフォーム エンジニアリング成熟度モデル で概説されている重要な領域と密接に連携し、組織のプラットフォーム エンジニアリングの成熟度のレベルを反映しています。

プラットフォーム エンジニアリング機能モデルを使用するには、まず、6 つの機能分野それぞれにおける組織の現在の状況を評価します。 この評価は、手動で実行することも 、プラットフォーム エンジニアリング機能モデルの調査を完了することもできます。 現在の段階を確認したら、将来の成長目標を設定し、機能ごとに組織の進捗状況をグラフ化します。 すべての機能を一度に進歩させる必要はありません。 組織にとって最も意味のある分野に重点を置きます。

プラットフォーム エンジニアリング機能モデルの主要なドライバーとステージを示す図。

投資

投資機能が各段階を通じて進化するにつれて、予算と人員配置、スコープ管理、投資収益率 (ROI) の測定に重点を置きながら、プラットフォーム能力に人員と資金をどのように配分するかに重点が置かれます。

  • 初期 (任意):プラットフォーム機能は、個々のエンジニアが任意で当面の戦術的なニーズに取り組むことによって、必要に迫られて出現します。 予算と人員は最小限で、通常、資金はなく、既存の責任と並行して行われます。 ソリューションの範囲は狭く、特定の問題が対象で、チーム間での知識の共有は限定されています。 ROI は、当面の要件がいかに効果的に対処され、コア プロジェクトの成果にどのような影響を与えるかによって測定されます。
  • 繰り返し可能 (アドホック コントリビューション):専任チームは、一貫性のないプロビジョニングやセキュリティ ギャップなど、繰り返し発生する課題への対処を開始しますが、その取り組みは依然としてかなり事後対応型です。 予算と人員配置は組織横断的な関心事に限られており、組織全体への権限の付与は制約されています。 スコープ管理は、広範なプラットフォーム全体の視点を持たずに、特定の問題に重点を置きます。 ROI は、バックログの削減など、主要な課題への対処の改善によって評価されます。
  • 定義済み (運用可能 - 専任チーム):資金を一元的に管理するプラットフォーム チームが出現し、ソフトウェア配信を加速させ、技術面の要件に対応することに重点を置きます。 リーダーシップは、コラボレーションを促進し、初期の DevOps プラクティスの実装を開始しますが、チームの価値の測定には課題が残ります。 技術的なニーズを満たすため、中央チームの予算と人員配置が形式化されます。 ソリューションの幅が広がり、チーム全体に共通する課題に対処できるようになりますが、焦点は依然として短期的なものです。 ROI は配信速度の向上で測定されます。
  • マネージド (スケーラブル - 製品として):共感と製品主導のアプローチを重視するリーダーシップによって、開発者を顧客として扱う文化的移行が起こります。 プラットフォーム チームは、開発者、製品マネージャー、ユーザー エクスペリエンスの専門家で構成される製品チームのように活動します。 スコープ管理は、製品のロードマップと適合し、組織全体のニーズを満たすためにエンジニアリング チームと共同で確認されます。 ROI は、継続的な改善とユーザー ニーズとの整合性を反映した、開発者の満足度の向上によって評価されます。
  • 最適化 (有効なエコシステム):投資はイノベーションに重点が置かれ、組織全体への貢献が奨励されるプラットフォームの妥当性が維持されます。 プラットフォーム チームは、セキュリティやパフォーマンス強化などの高度な機能を導入し、製品チームは一元化されたバックログに依存せずに構築できるようになります。 予算は中央チームの枠を超え、組織全体で資金調達できるようになります。 スコープ管理は、迅速で組織全体で知識を共有できることに重点を置いています。 ROI は、開発者の満足度を持続的に向上させることを通じて測定されます。

養子縁組

導入機能は、サービス、ツール、テクノロジ検出、選択、使用によって反映され、ユーザーがプラットフォーム エンジニアリングの解決策とその提供物を検出し、使用する方法に重点を置いています。 組織が成熟するにつれて、導入へのアプローチは、非公式で散発的な利用から、ユーザーが積極的にプラットフォームに関与し、その進化に貢献する、より構造化された参加型モデルへと移行します。 この進行状況は、ユーザーの検出、意思決定、利用方法が、最初の非公式な検出からプラットフォームの開発への完全な参加まで、時間とともにどのように進化していくかを反映しています。

  • 初期 (非公式):組織全体で調整することなく、各チームが独自にプロセスを改善しているため、導入に一貫性がありません。 内部ツールよりも外部ツールの方が優先される場合が多くなります。 プラットフォームは、主に口コミや偶発的な発生を通じて非公式に検出され、エンジニア チームは特定のニーズに基づいてサービスを選択します。 各チームは、独自の要件に合わせた固有のスクリプトとツールを維持します。
  • 繰り返し可能 (必須):組織では共有プラットフォームの使用が必須ですが、機能はよくある使用例に制限されているため、特殊な要件に対応することは困難です。 ユーザー検出は、多くの場合、内部ドキュメントやディレクティブを通じて、プラットフォーム チームのガイダンスに依存しています。 各チームは、プラットフォーム チームとの非公式なディスカッションにより、必須のサービスを選択できます。 プラットフォーム標準を中心にプロセスが構築されているにもかかわらず、チームがそれを完全に導入しなかったり、結果に満足できなかったりする場合があります。
  • 定義済み (アドバタイズ済み):プラットフォーム機能は、チームのニーズに合わせて積極的に推進されます。 プラットフォーム チームは、エンジニアリング チームと共同作業を行い、運用のオーバーヘッドを削減する高品質なサービスを提供します。 ただし、期限切れのプラクティスや技術的負債に依存しているため、依然として ROI が低いチームも存在します。 チームは一般的なユース ケースをカバーするディレクティブを通じて機能を検出し、プラットフォーム チームはコラボレーションを通じて利用を促進します。 プラットフォームのアドボケイトは、チーム アンバサダーを通じて非公式に行われることもあります。
  • マネージド (価値主導型):製品チームは、コグニティブな負荷を軽減し、高品質のサービスを提供するという明確な価値により、プラットフォーム機能を認識し、選択します。 プラットフォームは、豊富なドキュメント、人間工学に基づくインターフェイス、迅速なプロビジョニングのためのセルフサービス UX によってサポートされています。 現在、各チームは、自前でのソリューション構築や外部のプロバイダーへの依存よりも、内部プラットフォームを好んで利用しています。 チームはテンプレート、フォーラム、ドキュメントを使用して、プラットフォームの導入を完全にサポートすることで、検出と意思決定が効率化されます。
  • 最適化 (参加型):製品チームは、新しい機能や修正を提案することで、プラットフォームの機能向上に積極的に貢献しています。 ユーザーが要件を特定し、貢献に向けた共同作業を行うためのプロセスが整備されています。 開発者のアドボケイトとアンバサダーが社内コミュニティを育成し、共同作成者にプラットフォームの所有権を拡大します。 プラットフォーム エンジニアは、製品チームと密接に連携してニーズを理解し、新しい機能を提案します。また、ユーザーが pull request を送信し、レビューに参加できるようにします。

ガバナンス

ガバナンス機能が進化するにつれて、その焦点となるのは、コスト、データ、知的財産を管理しながら、ユーザーが必要なリソースや機能に確実にアクセスできるようにすることです。 この進歩は、ポリシーとフレームワークの定義、ポリシーの実装、コンプライアンスの監視と軽減、アクセスの管理など、いくつかのカテゴリに基づいて評価されます。 ガバナンスは、手作業の事後対応型プロセスから、一元的な制御と進化を続けるニーズへの適応的な管理のバランスが取れた統合された予測システムに進化します。

  • 初期 (独立系):ガバナンスは手作業で行われ、一元的な制御とゲートキーピングに依存しているため、スケーラビリティの妨げになります。 開発者とセキュリティ チームは、ポリシー違反に対して事後対応し、独立して作業します。 コンプライアンスは最小限の基準によって維持され、セキュリティ対策は後付けされる場合が多くなります。 アクセス許可は、標準化されたプロセスなしで、即時の必要性に基づいて付与されます。
  • 繰り返し可能 (文書化済み):組織は、ポリシーを文書化して共有を開始しますが、それらは基本的なものにとどまり、一貫して適用されません。 ポリシー レビューを管理するために、発券システムのようなガバナンス ツールが導入されていますが、プロセスは依然として手作業で時間がかかります。 監査プロセスは確立されていますが、まだ事後対応型です。 一部のロールとアクセス許可は標準化されていますが、その適用にはばらつきがあります。
  • 定義済み (標準化済み):ガバナンスが一元化され、標準化されることで、すべてのチームの一貫性と効率性が向上します。 ポリシーは文書化され、一元管理されており、実装プロセスもある程度自動化されています。 開発チームは依然としてポリシー変更を限定的にしか制御できませんが、主なガバナンス基準は定期的な監査を通じて維持され、アクセス制御は正式な RBAC システムによって自動化されています。
  • マネージド (統合):セキュリティとコンプライアンスがワークフローにシームレスに統合され、自動化によってシステムやチーム全体に一貫したポリシーが適用されます。 リアルタイム監視と高度な分析により、ガバナンスのギャップを検出して防止します。 ポリシーは CI/CD パイプラインに組み込まれ、アクセス管理は自動化されたレビューによる最小特権の原則によって管理され、ガバナンスに対して事前対応型の統合的なアプローチが行われるようになります。
  • 最適化 (予測的):ガバナンスは動的かつコンテキスト対応型で、条件の変化に対応し、アクセス制御を最適化します。 予測分析は、潜在的なリスクを事前に特定し、予防的に軽減できるようにします。 ポリシーは高度な分析を使用して継続的に改善され、アクセス制御はユーザーの場所やアクセス時間などのリアルタイムの要因に基づいて動的に調整されます。

プロビジョニングと管理

プロビジョニングと管理機能では、ユーザーがリソースを作成し、デプロイし、管理する方法に重点を置いています。 このプロセスは、手作業でサイロ化された運用から、柔軟性とガバナンスのバランスを保ち、コンプライアンス要件を満たしながらリソースの効率的なプロビジョニングを保証する、適応型で自動化されたシステムに進化します。 この進行状況は、プロビジョニング プロセスの定義、要求への対応と管理、リソース割り当ての監視に分類されるステージに及びます。

  • 初期 (手動):開発者は、IT チームやアーキテクチャ チームからのガイダンスに基づいて手作業でインフラストラクチャを設定するため、不整合や遅延が発生します。 標準化されたプロセスがなければ、要求は手作業でレビューされ、エラーが発生するリスクが高まります。 このアプローチは、需要が拡大するにつれて持続不可能になり、サイロ化した業務によって非効率が生じます。
  • 繰り返し可能 (組織的):組織は、発券システムを使用してインフラストラクチャ要求を管理することにより、プロビジョニング プロセスの一元化を開始します。 手作業による承認はまだ必要で、ある程度エラーは削減されましたが、ボトルネックは残っています。 チームはリソースの監視に標準的なツールを使用し始めますが、ビューはサイロ化され、プロジェクト固有のままです。
  • 定義済み (機能強化):プロビジョニング プロセスは、コードとしてのインフラストラクチャ (IaC) を使用して組織全体で形式化され、テンプレートとツールが標準化されています。 要求は構造化されたワークフローを通じて処理されますが、プラットフォーム チームは需要の増加に苦慮する場合があります。 一元化されたダッシュボードは、リソースの割り当てを監視し、より優れたパフォーマンス インサイトを提供します。
  • マネージド (自動化):プロビジョニングは自動化され、CI/CD パイプラインに統合されるため、手作業を最小限に抑え、一貫性のあるデプロイを実現します。 ガバナンスとコンプライアンス チェックは、ワークフローに組み込まれています。 自動化されたセルフ サービス機能により、ユーザーは制御されたパラメーター内でリソースをプロビジョニングできます。 スケーリングは、使用パターンに基づいて自動化され、パフォーマンスを最適化します。
  • 最適化 (適応型):プロビジョニングは適応型になり、インテリジェントなシステムを使用してインフラストラクチャのニーズをリアルタイムで予測します。 このアプローチにより、ガバナンスとコンプライアンスを維持しながら、効率的なリソースを割り当てられるようになります。 システムは、柔軟性とガバナンスのバランスを取りながら要求に事前に対応し、パフォーマンスとコスト効率は予測分析によって最適化されます。

インターフェイス

インターフェイス機能では、ユーザーがプラットフォームのサービスや製品の運用方法や利用方法が最優先で検討されます。 その進歩は、標準の確立、ユーザーの自律性の向上、既存のワークフローへのプラットフォーム機能のシームレスな統合に重点を置いています。 このアプローチは、一貫性のない手作業によるプロセスから、ユーザー エクスペリエンスと業務効率を高めるセルフ サービスの統合システムに進化します。

  • 初期 (カスタム プロセス):ユーザーは、即時的な必要性に対処するものの標準化されておらず、一貫性のないさまざまなカスタム プロセスを通じてプラットフォームと対話します。 エンジニアは、同僚に相談したり、個人的なプラクティスに依存したりして独自に環境を設定し、確立されたガイドラインがないまま、アプリケーションの動作を診断するためのツールやプロセスを選択します。 知識の共有は非公式で、正式なプロセスがないため、サービスの提供にはプロバイダーからの詳細なサポートが必要になる場合が多く、スケーラビリティと効率性に限界があります。
  • 繰り返し可能 (ローカル標準):エンジニアとチームは、知識の共有を強化するために非公式に標準を定義し始めますが、個人のコミットメントに依存するため、一貫性には課題が残ります。 チームによっては、ドキュメントやコンテナーを使用してセットアップ プロセスを定義する場合もありますが、これらのプラクティスは時間の経過とともに乖離し、調整するのに労力を要します。 アプリケーションの動作の診断はチーム内で標準化され、デプロイされたリソースへのアクセスは DevOps チームまたは IT チームに依存します。 ローカル標準は出現するものの、その定義は緩く、チーム間で一貫性がありません。
  • 定義済み (標準化されたツール):標準化されたツールと文書化されたプラクティスの導入により、インターフェイスの一貫性が向上します。 中央チームは、テンプレートとドキュメント (別名: 舗装道路やゴールデン パス) を管理し、機能をプロビジョニングし、監視する方法をガイドします。 これらのツールやプロセスは、組織の幅広いニーズに対応していますが、それでも専門家のサポートが必要になる場合がよくあります。 チームはテンプレートを変更することができますが、変更が常に一元的に反映されるとは限らないため、一貫性の維持が非効率になる可能性があります。 アプリケーションの動作の診断は、デプロイされたリソースへのアクセスと分析のための標準化されたプラクティスに従うため、チーム全体の一貫性が向上します。
  • マネージド (セルフサービス ソリューション):このプラットフォームは、最小限のメンテナによるサポートでセルフ サービス ソリューションを提供することにより、ユーザーの自主性を向上させることができます。 ユーザーは、使いやすさを強化するユーザー中心の環境を作成し、テンプレートを検出および変更できる、一貫性のある使いやすいインターフェイスにアクセスできます。 アプリケーションの動作を診断し、リソースを監視するためのツールは、プラットフォームを通じてオンデマンドで利用できるため、ユーザーは外部チームに過度に依存することなく、必要なリソースを確保できます。 テンプレートの検出と変更を通じて知識の共有が促進され、プラットフォーム機能の価値が高まります。
  • 最適化 (統合されたサービス):プラットフォーム機能は、CLI や IDE など、チームが既に使用しているツールやプロセスにシームレスに統合され、ユーザーのワークフローに自然に組み込まれます。 一部の機能はユーザーのニーズに基づいて自動的にプロビジョニングされ、プラットフォームでは、詳細なカスタマイズが必要な高レベルのユース ケースのための柔軟な構成要素が提供されます。 プラットフォーム チームは、どの機能が最も効果的であるかを継続的に評価し、プラットフォーム オファリングの最適化のためのさらなる投資をガイドします。 このプラットフォームは、デプロイされたアプリケーションの監視を自動的に設定し、診断データへのリアルタイム アクセスを提供し、アプリケーションの動作の監視と管理のプロセスを効率化します。

測定とフィードバック

測定とフィードバック機能では、プラットフォーム エンジニアリング プラクティスの成功を評価するためのメトリックとフィードバックを収集し、分析して取り込みます。 その成熟度は、アドホックで非公式な方法から、フィードバックと分析情報が継続的な改善プロセスに統合され、戦略的な意思決定とプラットフォーム開発をガイドする、先回り型でデータ主導型の文化への移行によって反映されます。

  • 初期 (アドホック):初期段階では、測定とフィードバックのプロセスに一貫性がなく、断片的です。 組織の目標との明確な一貫性がないままメトリックが収集されるため、不完全で信頼性の低いデータになります。 フィードバックは非公式に収集され、多くの場合は参考程度ですが、利害関係者からの関与は最小限です。 その結果、限られた情報に基づいて意思決定が行われ、プラットフォーム エンジニアリングの実践の真の ROI を測定することは困難です。 フィードバックや結果の文書化は最小限にとどめられ、学習が把握されたり共有されたりすることはほとんどありません。
  • 繰り返し可能 (構造化されたプロセス):アンケートやフォーラムなどの基本的なフィードバック メカニズムは、ユーザー エクスペリエンスをより体系的に把握するために確立されていますが、このようなプロセスはまだチームによって異なります。 成功の測定は、多くの場合、デプロイやタイムラインなどのアクティビティベースのメトリックに重点が置かれており、パフォーマンスに関するある程度の分析情報は得られますが、より広範で結果ベースの視点が欠けています。 フィードバックは非公式でボトムアップのままですが、計画に影響を与え始めます。 利害関係者を関与させる取り組みはありますが、まだ限定的で、プロセスやフィードバックの初期ドキュメントが作成されていますが、包括的かつ一貫的に活用されているわけでもありません。
  • 定義済み (一致):フィードバックの収集がより形式化され、標準化されることで、ユーザーのニーズや主要なメトリックの詳細な分析情報を得られるようになります。 メトリックは、開発者の生産性など結果ベースの測定にシフトしていますが、財務パフォーマンスとの関連付けは課題として残っています。 フィードバック分析は、定性的な手法と定量的な手法の両方を使用して体系的に行われ、DORA (DevOps Research and Assessment: リード タイム、デプロイ頻度、平均復元時間、変更失敗率など、ソフトウェア配信パフォーマンスを測定する一連のメトリック) や SPACE (満足度とウェルビーイング、パフォーマンス、アクティビティ、通信とコラボレーション、効率性: これら 5 つの次元にわたって開発者の生産性を測定するために使用されるフレームワーク) のような標準的なメトリックが採用されます。 機能横断型チームとの定期的なレビュー セッションにより、利害関係者に積極的に関与できるようになります。 フィードバック プロセス、結果、得られた経験を包括的に文書化し、チーム全体で共有します。
  • マネージド (インサイト):この段階では、フィードバック メカニズムと測定フレームワークは強固であり、戦略的な事業成果に重点が置かれます。 データ ドリブン インサイトがプラットフォームの運用をガイドし、フィードバックはプラットフォームのロードマップに統合され、継続的な改善が推進されます。 高度な分析を使用して、収益成長などのビジネス成果に対するプラットフォームの影響を評価し、フィードバックをパフォーマンス メトリックと関連付けて、戦略的な改善のための主な分野を特定します。 組織全体の利害関係者がフィードバック プロセスに深く関与し、サイロ化を避けるために構造化されたコラボレーションが行われます。 リアルタイムの動的なドキュメントは、継続的なフィードバックと得られた経験を反映し、すべての利害関係者がアクセスできます。
  • 最適化 (予防型):フィードバックと測定のプロセスは、組織の文化に密接に統合されており、将来の課題や機会を予測し、それに適応するための積極的なアプローチを生み出しています。 予測分析と高度なメトリックは、将来のニーズと機会を予測するために使用され、条件の変化に応じてプラットフォームを継続的に進化させることができます。 フィードバックは、継続的な改善のサイクルに完全に統合され、組織のすべてのレベルにわたってフィードバックの文化が確立されています。 動的でリアルタイムのドキュメントは、継続的なフィードバックを反映し、継続的に更新されるため、得られた経験が共有され、すべての利害関係者がアクセスできるようになります。