プラットフォームエンジニアリングの現状と今後：Gartner Insights Pickup（351）
モダンなソフトウェアアーキテクチャの多くは、他のチームやクラウドプロバイダーによって構築された複雑な分散システムのため、開発と運用が交わる領域で問題を引き起こす。この問題に対する新しい解決策が、プラットフォームエンジニアリングだ。本稿では、プラットフォームの4つの特性と現状、今後の展望について紹介する。
新しい問題ではないが、モダンなソフトウェアアーキテクチャは、多くの独立したサービスで構成される複雑な分散システムとなっており、構成コンポーネントが他のチームやクラウドプロバイダーによって構築されていることも多い。Kubernetesはこうしたサービス群を管理するが、さらなる複雑化を招いてしまい、その克服が必要だ。
これは、開発と運用が交わる領域で厄介な問題を引き起こす。開発者は、専門外の複雑で難解なサービスやツールを幾つも運用しなければならないと、フラストレーションを感じる。運用担当者は、専門外の開発者が基準に満たないインフラを構築すると、フラストレーションを感じる。開発者は「運用担当者のせいで仕事が遅れる」と不満を述べ、運用担当者は「開発者がプッシュするコードがレジリエンス（強靭〈きょうじん〉性、回復力）に欠ける、コンプライアンスに違反している、安全でない」と不満を述べる。
この問題に対する新しい解決策がある。それはプラットフォームエンジニアリングだ。オペレーティングプラットフォームは、エンドユーザーと、エンドユーザーが依存する支援サービスの間に位置する。専門チームによって構築された社内向けのソフトウェアプロダクトであり、厳選された再利用可能なコンポーネント、ツール、サービス、知識を提供する。これらは、簡単に利用できるようにパッケージ化されている。下図のように、このプラットフォームは、開発者と面倒で複雑な運用間の抽象化レイヤーとなる。
個々のプラットフォームによってコンポーネントや機能は大きく異なる。結局のところ、プラットフォームは開発チームのニーズに応じてどんなものにでもなる。プラットフォームチームの仕事は、そのプロダクトを作ることにある。だが、各プラットフォームはそれぞれ固有であるかもしれないが、全てのプラットフォームが以下の特性を持っている。
- プロダクト化されている：プラットフォームはプロダクトだ。ユーザーからのフィードバックがプロダクト戦略を方向付ける
- ユーザー中心：プラットフォームは、運用担当者の問題ではなく、ユーザーの問題を解決する。例えば、開発者は、仮想マシン（VM）を迅速に構築する方法は求めていないだろう。インフラのことは何も考えたくないからだ
- セルフサービス：開発者は、チケットを開いたり、電子メールを送ったり、リクエストを提出したりすることなく、単一のソース上にある必要なあらゆるものにアクセスできる
- 一貫性があり、コンプライアンスを満たしている：標準プラットフォームが組み込まれており、ユーザーは仕様外のコードや安全でないコードを提供できない
プラットフォームは、いわば「舗装された道路」であり、ガイドライン（推奨される走行方法）とガードレール（ユーザーが越えてはならない厳格な境界）の両方がある。プラットフォームは、コンプライアンスをガードレールで強制するかもしれない。例えば、「デプロイ（展開）する前にセキュリティ体制の自動テストを実行する」ことを必須とする仕組みが作り込まれている可能性がある。だが、特定のワークフローについては提案するだけかもしれない。「これらのユースケースには次のツールを推奨する」といった具合にだ。
プラットフォームエンジニアリングの新しさ：DevOpsの約束の実現
プラットフォームエンジニアリングをこれまでの取り組みと区別することは重要だ。自動化は新しい試みではなく、開発者と運用担当者のコラボレーションの強化も同様だ。プラットフォームは、既存の技術やツールの単なる組み合わせではない。新しいソフトウェアプロダクトであり、固有の顧客、ライフサイクル、ユーザー契約を持ち、高い期待を寄せられる。
プラットフォームエンジニアリングは、DevOpsの最先端を体現している。当然のことながら、そのためにプラットフォームエンジニアリングは、一気にこの分野で最もホットな話題となり、固有のユーザーコミュニティーやカンファレンスが生まれている。Gartnerは、プラットフォームエンジニアリングを2023年、2024年の戦略的テクノロジーのトップトレンドの一つに選び、2026年までに大手ソフトウェアエンジニアリング企業／組織の80％が、プラットフォームエンジニアリングチームを設置すると予測している。
今、何が起こっているか：プラットフォーム革命の始まり
IT部門は、既にプラットフォームチームを置き始めている。ほとんどのチームは、最初に社内開発者ポータルを構築する。オープンソースプロジェクトの「Backstage」を使用する場合が多い。Backstageを使って構築されたポータルは、一元的なサービスカタログであり、かつドキュメントリポジトリでもある。また、自動化やデリバリーパイプラインのためのグラフィカルユーザーインタフェース（GUI）にもなる。このポータルのユーザー体験は、開発者が自前で構築したソリューションよりも格段に優れているだろう。開発者をオンボーディングによってポータルに習熟させようとするのではなく、開発者が使いたくなるポータルを構築しなければならない。
プラットフォームは開発者の生産性を向上させる。自分の業務環境を構築する負担から解放するので、開発者は不要な統合やカスタマイズの作業を避け、価値を生み出すコードを書くことに集中できる。プラットフォームの価値を測定するときや、プラットフォームを構築するためにビジネスケース（投資対効果検討書）を作成するときは、生産性に対するプラスの影響に注目するとよい。デプロイ率は向上し、エラー率、インシデント、例外、手戻り、価値創造までの時間はいずれも減少するはずだ。
次に何が起こるか：プラットフォームの拡充と展開
プラットフォームは小さくスタートする。多くの場合、当初はドキュメントとサービスカタログしか整備されていない。だが、それでも価値がある。開発者はチケットを開いたり、電子メールを送ったりする手間が省けるからだ。プラットフォームは時間の経過とともに、機能が拡充されていく。プラットフォームエンジニアリングの究極のビジョンは、プラットフォームの独自のAPIセットを用意するというものだ。開発者は、これらのAPIを介してプラットフォームの機能を利用するコードを作成し、その抽象化によってアプリケーションのワークロードが処理される。
プラットフォームは、他のユーザー向けに拡大することもできる。その中には、例えば、データサイエンティストや業務の自動化を目指すビジネス部門などが含まれる。こうしたユーザーも、どこでも活用できるプラットフォームに価値を見いだすだろう。プラットフォームチームが提供するビルディングブロックがすぐに役立ち、認知負荷が適切で、過度な制約もなく、これまでと違う仕事のやり方を押し付けることもなければ、そのチームは現在も将来も価値を提供する。
出典：What’s new, what’s now, and what’s next in platform engineering（Gartner）
※この記事は、2024年3月に執筆されたものです。
Copyright © ITmedia, Inc. All Rights Reserved.