プラットフォーム エンジニアリングにまつわる、さらなる 5 つの誤解: プラットフォームが対処すること、対処しないこと

※この投稿は米国時間 2024 年 6 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

前回のブログ投稿では、プラットフォーム エンジニアリングにまつわる根強い誤解を解消すべく、プラットフォーム エンジニアリングとは一体なのか、そして皆様がすでに行っているプラットフォーム エンジニアリングのコアタスクの実施方法について説明しました。今回はさらに 5 つの誤解を取り上げ、プラットフォームがどう構築されているか、何を行い、何を行わないかについて説明します。

6. 誤解: プラットフォーム エンジニアリングはインフラストラクチャ チームを不要にする

地球上で最も優れたデベロッパー プラットフォームを確保できたとしても、プラットフォームは複雑なインフラストラクチャを基盤に稼働するものなので、インフラストラクチャを理解しているスペシャリストによる継続的なメンテナンスが常に必要となります。結局のところ、誰かがインフラストラクチャの設計、管理、スケーリング、トラブルシューティング、最適化に対処しなければなりません。どれだけ頑張ってみても、プラットフォーム エンジニアリングを導入する前と同じようにインフラストラクチャで障害が起こり続けるでしょう。よくある間違いは、インフラストラクチャ チームを廃止して、まったく新しいチームにその埋め合わせを求めることです。インフラストラクチャ チームのメンバーは、インフラストラクチャ関連の職務に対処するための専門知識をすでに得ているため、プラットフォーム エンジニアの有力候補になります。基盤となるインフラストラクチャに関する体系化された知識を備えたチームを採用すれば、現在のシステムを実用的なプラットフォームに設計し直せる可能性が高くなります。

一方、プラットフォーム エンジニアリングでは、インフラストラクチャ スペシャリストが障害に備える方法も障害に対処する方法も変わってきます。その理由は、プラットフォーム エンジニアリングのロールはプラットフォーム開発を重視したものであり、手動による反復作業はあまり重視されないためです。プラットフォーム エンジニアリングはインフラストラクチャ関連の作業の本質を変えるものの、これらの作業を完全に不要にするわけではありません。これまでと同じく、デベロッパーがアプリケーションをデプロイする際に選択できるよう、ゴールデンパスのセルフサービス カタログを作成しなければなりません。そのカタログを文書化して改良を加え、組織内で支持を得て、新しいエンジニアに紹介する必要があります。プラットフォームに加えた改善を既存のテナントにロールアウトする必要もあります。スケーリングとセキュリティは常に新しい問題の原因になります。どの IT スタッフの中でも、インフラストラクチャのエキスパートは極めて貴重なメンバーです。ソフトウェア デリバリーの成功を目指す組織にとって、インフラストラクチャのエキスパートが自らの知識を体系化してプラットフォームに適用できるようにすることが不可欠となります。

最後に指摘する点として、最も成熟したプラットフォームに、自動化の対象範囲外のコンポーネントがあるとしても、そのコンポーネントを担当するのはインフラストラクチャのエキスパートです。それはそれで問題ありません。インフラストラクチャのエキスパートはこうした作業を直接理解しているので、プラットフォーム エンジニアリングのプロダクト バックログに追加する機能に効果的に優先順位を付けることができます。新しいシステムがオンラインで利用可能になって進化し、クラウド プロバイダがサービスを拡大しても、プラットフォームが不要になることは決してありません。

7. 誤解: プラットフォーム エンジニアリングの導入は人件費に大きな影響を与える

プラットフォーム エンジニアリング チームを結成する一環として、組織内の DevOps スキルに優れた人材を選抜して、新しい組織構造に進化させます。これにより、より少ない人数でもセルフサービスによる自動化とゴールデンパスを使用して、チームと組織がより効果的に DevOps の原則を適用できるようになります。

一般的な懸念としては、プラットフォーム エンジニアリング チームに多数の追加人員が必要になることが挙げられます。プラットフォーム エンジニアリング チームにスタッフを配属する必要があるのはもちろんですが、配属するスタッフは既存の運用チームやソフトウェア エンジニアリング チームから手配できます。共有サービスのメリットを利用することで、プラットフォームはやがて、採算が合う以上のものになるはずです。つまり、プラットフォーム エンジニアリング チームは、既存の社内チームを資金にできる投資と言えます。検討すべきモデルの一つとしては、Google SRE の劣線型スケーリングの歴史があります。これは、可用性の確保を担当するチームが、それぞれが運用するシステムよりも低い成長率で人員を増やすための目標を設定するというものです。

プラットフォーム エンジニアリングを導入する際のアンチパターンは、運用スタッフやデベロッパーの人数が直ちに減ると期待することでしょう。プラットフォーム エンジニアリングの導入で功を奏するのは、既存のインフラストラクチャ チームを再トレーニングすることです。既存のチームはビジネスニーズをすでに十分理解していて、基盤となるインフラストラクチャが直接公開されているか、プラットフォームを介して公開されているかにかかわらず、インフラストラクチャで多くの経験を積んでいるからです。実際、私たちが目にしている事例では、チームのメンバーが活用できるプラットフォームがあれば、プラットフォーム エンジニアリングを導入したチームは最終的に、ほとんどの作業を同じメンバーで実施できることに気付く結果となっています。

プラットフォーム エンジニアリングを適切に実装すれば、次の理由から効率が高まり、運用上のオーバーヘッドが減ります。

• デプロイ パイプライン、インフラストラクチャ、構成の自動化により、手動による作業が削減されます。

• セルフサービス モデルでは、必要となる運用チームによる介入が最小限に抑えられるため、ボトルネックが減ります。

• ワークフローが効率化され、チームが同じ（あるいはより少ない）リソースでより多くの作業を行えるようになります。

最初に人員のスキルアップや採用が必要になることもありますが、プラットフォーム エンジニアリングに移行して、プラットフォームの専門知識を組織全体に適用すれば、やがては長期的な効率性を実現できます。

8. 誤解: 今すぐプラットフォーム エンジニアリングを導入すれば、大きな頭痛の種となっているあらゆる問題がすぐに解決される

複雑な環境ではほぼ常に、手っ取り早い解決を期待するのは甘い考えです。変革には時間がかかります。組織の制約事項と、関連するソリューションのキュレートをどれだけ迅速に行えるかを特定する際は、変革のタイムラインを考慮に入れる必要があります。

また、プラットフォーム エンジニアリングには、すべての状況に適用できる万能のアプローチというものはありません。したがって、組織の特定のニーズを満たすようにカスタマイズする必要があります。そうは言っても、結果を出すまでの時間を短縮することは可能です。それには、実用最小限のプラットフォーム（MVP）を構築し、最初はユーザーベースのサブセットによる高速フィードバック ループを作成します。

既製の MVP を出発点にするとチームに弾みをつけるのに役立ちます。ただし重要なのは、完全に構築されたプラットフォームを導入すれば「不利な状況を切り抜けて」、直ちに状況を改善できるという誤った考えを持たないことです。ここで進むべき正しい道は、投資、調査、内省です。MVP から開始して、先行ユーザーのフィードバックに基づく機能を追加すれば、すばやく価値を実現するプラットフォームを反復的に構築できます。5 年計画で完璧なプラットフォームを設計しようとはしないでください。

要するに、プラットフォーム エンジニアリングとは、開発および運用に対する考え方の転換、プラットフォームを活用する文化への転換、開発プロセスでの摩擦に対処するためのツールが必要となる取り組みなのです。考え方の転換、文化の転換、ツールのいずれにしても、正しく実装するには時間がかかります。

9. 誤解: どのアプリケーションにもプラットフォーム エンジニアリング手法を適用すべきである

プラットフォーム エンジニアが積極的に分析して特定するタスクやプロセスは、開発チームと運用チームに高い認知負荷を生じさせるため、その負担を軽減するためのアクションが必要になります。だからと言って、ソフトウェア デリバリー組織内のすべてのタスクとプロセスがそうであるとは限りません。

したがって、プラットフォーム エンジニアリングを適用する対象としては、デベロッパーの手には負えないほどインフラストラクチャが複雑なアプリケーションや、運用チームが絶えず摩擦に直面するようなアプリケーションを検討してください。こうしたアプリケーションでは、ゴールデンパスのアプローチで開発と管理を合理化できます。合理化には通常、適切なクラウド サービスの選択、デプロイの自動化、標準化された構成の確立が伴います。

まず、使用される頻度が最も高く、トイルが大きい作業、つまり大きな認知負荷がかかり、頻繁に使用されるサービスの抽象化に注力します。これらのシステムを優先すれば、プラットフォームのメリットを実現するまでの時間を短縮できます。

抽象化によって価値をもたらし、適切なデフォルトを提供するだけでなく、特定の選択を行う際のガイダンスとその理由の説明も提供するようにします。必要に応じてプラットフォームの外部に踏み出すための「ブレークグラス」手法を用意することを強くおすすめします。少なくとも始めのうちは、幅広さではなく専門性のあるプラットフォームを構築するという観点で考えます。一般的なユースケースをできるだけ網羅して自動化してから、新しいユースケースに取り掛かります。

同様に、最も大規模で、組織にとって最も重要なサービスから取り掛かることはしないでください。ここでのアンチパターンは、経時的な利益を最大化するうえで「最も効果がある」アプリケーションを選ぶことです。チームが誕生したてのプラットフォームで時間をかけて自信を培う以前の状態であるか、あるいはプラットフォームにまだ必要な機能が揃っていないことから、失敗する可能性が高くなります。代わりに、小規模で要件が厳しくないサービスから始めてください。

チームがプラットフォームの導入時にすべてのサービスをデプロイする必要はありません。大部分のサービスをデプロイするよう目指すことはできますが、別のアプローチが必要になるような「異端児的」サービスは必ずあるものです。こうしたサービスについては、話し合いを続け、今後の再評価に備えて文書化する限り、あまり心配する必要はありません。

10. 誤解: すべてのクラウド サービスはプラットフォーム エンジニアリングに対応付けられる

プラットフォーム エンジニアリングの取り組みを始めようとする人からよく聞かれるのは、「このクラウド サービスはプラットフォーム エンジニアリングに対応付けられますか」という質問です。プラットフォーム エンジニアリングを実践するためにクラウド サービスを導入するという間違いは犯さないでください。この誤解は、効果的な実装を妨げるだけでなく、プラットフォーム エンジニアリングが実際に何であるかについて理解しきれいていないことを示唆します。プラットフォーム エンジニアリングでは、どのクラウド サービスでも使用できますが、重要なのは、プラットフォームを介してクラウド サービスをデベロッパー エクスペリエンスに統合する方法です。

クラウド サービスまたはプロダクトがプラットフォームに適しているかどうかを判断できるよう、プラットフォーム エンジニアリングのコアタスクとプロセスを簡単に振り返りましょう。

プラットフォーム エンジニアリングの次のステップ

このブログ記事でご理解いただけたように、プラットフォーム エンジニアリングは IT インフラストラクチャとソフトウェア開発の管理に対する新たなアプローチです。その目的は、デベロッパーにセルフサービス ツールとセルフサービス プラットフォームを提供し、複雑なインフラストラクチャの詳細を抽象化するとともに、反復作業を自動化して、ソフトウェア開発を合理化することにあります。プラットフォーム エンジニアリングは DevOps や自動化などの既存の手法に基づいたものですが、チームに最大限のメリットがもたらされるよう、プラットフォーム エンジニアリング固有の手法を検討する価値はあります。

重要なポイント:

• プラットフォーム エンジニアリングは DevOps の自然な進化であり、その目的は最新のソフトウェア開発に伴う課題に大規模に対処することです。

• これはあらゆる状況に適用できる万能のソリューションではなく、組織に固有のニーズに応じてカスタマイズされたアプローチが必要となります。

• 実用最小限のプラットフォームで小規模に開始し、価値の高いタスクを優先しながら、フィードバックに基づくイテレーションで、デベロッパーと組織に真の価値をもたらすプラットフォームを構築していきます。

この後は、ゴールデンパスに関する記事とプラットフォーム エンジニアリングでキャリアを積むための基盤づくりに関する記事をご覧ください。また、PlatformCon での講演の録画もご確認ください。最後になりますが、年に一度の DORA 調査にぜひご協力ください。

ー アプリケーション プラットフォーム担当 EMEA プラクティス ソリューション リード Darren Evans

ー Google、信頼性アドボケイト Steve McGhee