プラットフォーム エンジニアリングとは
プラットフォーム エンジニアリングは、安全で管理されたフレームワーク内の改善された開発者エクスペリエンスとセルフサービスを通じて、各開発チームのセキュリティ、コンプライアンス、コスト、およびビジネス化までの時間に関する価値を向上させることを目的として、DevOps 原則から構築されたプラクティスです。 製品ベースの考え方のシフトと、それをサポートするための一連のツールやシステムの両方です。
最近では、プラットフォーム エンジニアリングという用語に関して業界に多くの興奮が感じられます。 Gartner は、エンジニアリング組織の約 80% が、2026 年までにプラットフォーム エンジニアリング専用のチームを持つと予想しています。 これらのチームは、内部開発者プラットフォームと呼ばれるものを構築することに重点を置いています。 セールス (Microsoft Dynamics、Salesforce)、サービスのフルフィルメント (ServiceNow)、通信 (Twilio) などのドメインに関係なく、プラットフォームは本質的な性質により、スケールを達成し、ビジネス価値を提供するためにかかる時間を短縮するように設計されています。
開発者が使用または拡張するプラットフォームには、高度に最適化された開発者エクスペリエンスと簡素化された操作を使用して、開発プロセス全体で問題を排除する機能があります。 これらのプラットフォームには、次のツールが含まれます。
- 開発者が自立できるように支援する (スターター キット、IDE プラグインなど)
- 一般的なタスクを支援する
- 一般的なパターンとプラクティスを再利用可能な構成要素にカプセル化する
- 問題やセキュリティ リスクに関する早期のアドバイスとフィードバックを提供する
- 基になるインフラストラクチャとツールを管理して操作を簡略化する
内部開発者プラットフォームとは
内部開発者プラットフォームは、会社の内部開発プラクティスに重点を置いています。 運用に対して推奨およびサポートされている開発パスのセットを定義し、内部プラットフォームを使用して段階的に "舗装" します。
現実の世界に例えると、新しい道は多くの場合、未舗装の小道として始まりますが、使用する人が増えるにつれて、速度と処理能力を維持しながら安全性を向上させるために舗装されます。 内部開発者プラットフォーム内の舗装されたパスにも同様の目標があります。 開発者の配信速度を犠牲にすることなく、重要な要件と標準を開発者に案内するように設計されています。 これは、標準化され、セキュリティで保護されたスケーラブルなセルフサービス機能を開発チームに提供することで実現されます。 同時に、基盤となるインフラストラクチャとツールが効率的で、準拠しており、コスト効率が高く、運用と IT 組織にとって確実に容易になります。 一部のパスは部分的に舗装される可能性があります。完全に舗装されたゴールデン パスでは、関係するすべてのユーザーの認知的負荷が軽減されます。
開発者は、内部開発者プラットフォームの主要なコンシューマーまたは顧客です。 自動化と集中化により、効率的な運用が可能になり、コンプライアンスなどの利害関係者の要件が満たされます。
プラットフォーム エンジニアリングを使用すると、製品マインドセットと DevOps と DevSecOps からの学習を組み合わせて一連のツールを提供することで、この内部プラットフォームを作成できます。 これらのツールは、開発チームを自然に "成功の場に導く" 十分な自動化、追跡、ガバナンス、監視を提供します。多国籍マス メディア企業のプラットフォーム エンジニアリング リーダーは、次のように述べています。
プラットフォーム エンジニアリングは、製品を提供する速度またはベロシティを向上するために採用されました。 一元化されたチームでは、各チームがインフラストラクチャについて心配する必要がなくなり、効率が向上します... また、すべてが事前に定義されているため、安全性とセキュリティも強化され、エラーが減少します。 - Daniel、クラウド エンジニア、フォーチュン 500 メディア企業
内部開発者プラットフォームは、認知的負荷と手動の手順を減らすか、または排除することで、開発と運用のライフサイクル全体にわたって専門的な知識を一元化し、スケーリングするのに役立ちます。
セルフサービスと自動化に重点を置いて、開発者プラットフォームを段階的に構築する
成功したプラットフォーム エンジニアリング戦略を実装するには作業が必要ですが、その価値はあります。 個人が 20 人未満のチームが、何千人もの開発者と数百のプロジェクトをサポートできることは珍しくありません。
ただし、内部開発者プラットフォームの作成は長い道のりです。 "ビッグ バン" アプローチやトップダウン型の作業はお勧めしません。 プラットフォーム エンジニアリングの重要な側面は、開発者、機械学習の専門家、またはデータ サイエンティストを顧客として扱う製品マインドセットを適用することです。 あるテクノロジ企業の 1 人のプラットフォーム エンジニアは、次のように言います。
[私たちの] プラットフォーム エンジニアリング ツールが解決するように設計された 2 つの主な問題が [そこに] あります。 1 つ目は、セルフサービス モデルを使用してサービスのプロビジョニングを容易にすることでした。 … 2 つ目は、パフォーマンス メトリックやアプリケーションの可用性などの自動サポート システムを提供することでした。 目標は、開発者がアプリケーションのトラブルシューティングと最適化に必要なすべての情報を取得しながら、より迅速かつ効率的に作業できるようにすることでした。 - Alex、リード クラウド アーキテクト、大手テクノロジ企業
同じ企業は 2 社ないため、この取り組みを通じて段階的なコースをプロットする内部顧客の特定のニーズを検討してください。 時間の経過と共に組み立てる一連のコア構成要素を確立することで、開発チームがアドボケイトになり、途中で使用できるように、社内の開発者プラットフォームに十分な価値があることを確認できます。 この情報を使用して、最も実行可能な最も薄いプラットフォーム (プラットフォームの実用最小限の製品) を作成し、そこから拡張します。
重要なポイントは、これらの分野で行う投資を、プラットフォーム エンジニアリング体験の重要な構成要素として考えたいということです。 その後、すべてをゼロから構築するのではなく、カスタムの投資でまとまりのある glue を作成し、ビジネスに固有の価値を追加することに集中できます。