近年「プラットフォームエンジニアリング(Platform Engineering)」というワードを耳にする機会が増えました。ガートナーが定めた「2024年の戦略的テクノロジのトップ・トレンド」でも取り上げられており、2026年までにソフトウェアエンジニアリング企業の80%がプラットフォームエンジニアリングチームを結成すると予測されています。
本記事では、CNCFによるホワイトペーパーを参考に、プラットフォームエンジニアリングの概要を確認しつつ、陥りやすい罠について考えていきます。
プラットフォーム登場の背景
開発プロセスの改善や技術の進歩により、プロダクトチームのアジリティは大幅に向上しました。その一方で、開発者はインフラや開発ツールの責任を負い、多種多様な技術を習得しなければなりません。
これまで開発業務はコーディングやCI/CDパイプラインに注力していましたが、セキュリティやオブザーバビリティ、さらには開発とは直接関係が薄い調整業務など徐々に考慮すべき領域が拡大し、チームの認知負荷が大幅に高まったのです。これはプロダクトの価値創出以外のいわゆる差別化につながらない作業に時間を取られるようになったことを意味します。
プロダクトチームを本来の中核業務に集中させるため、クラウドネイティブコンピューティングを活用したプラットフォームを導入する必要性が高まりました。企業がプラットフォームに投資することで、以下のようなメリットが期待できます。
- 製品チームの認知的負荷を軽減し、開発・デリバリーを加速
- プラットフォーム機能の専門家を配置することで、製品の信頼性と回復力を向上
- 複数チームでツールと知識を再利用・共有することで開発を加速
- プラットフォーム機能とプロセスにガバナンスを組み込むことでリスクを低減
- パブリッククラウドなどの外部サービスを効果的に活用しつつ、ユーザー体験を制御
プラットフォームエンジニアリングの目的
プラットフォームエンジニアリングとは、企業内の開発者やデータサイエンティストといったユーザーに対して、プラットフォームを適切に提供するためのプラクティスです。
プロダクトチームの認知的負荷を軽減し、開発効率を向上させ、ビジネス価値をより早く顧客に提供することが、プラットフォームエンジニアリングの目的であると考えます。
またSRE(Site Reliabirity Engineering)と混同されがちですが、SREが「顧客に対するサービス品質の向上」を目的としていることに対し、プラットフォームエンジニアリングは「開発者の体験向上」と、誰を対象としているのかが異なると考えます。
プラットフォームの構成要素
大原則として「Platform as a product」という考えがあります。プラットフォームはユーザーの要件を満たすために存在し、その要件に基づいて設計する必要があります。またプラットフォームは、プロダクトチーム全体で最も一般的なユースケースをサポートするために必要な機能を提供する必要があり、提供される価値を最大化するために、単一のチームでのみ使用される特定の機能よりも優先されなければなりません。
ホワイトペーパーでは、プラットフォームを形成する要素について以下の通り紹介されています。
出典：CNCF Platforms White Paper
| 要素 | 説明 | 技術/ツール例 |
|---|---|---|
| Webポータル | ドキュメント、サービス カタログ、プロジェクトテンプレートの公開 | Backstage, Skooner, Ortelius |
| API(およびCLI) | 機能を自動的に作成、更新、削除、監視するためのフォーマット | Kubernetes, Crossplane, OperatorFramework, Helm, KubeVela |
| テンプレートとドキュメント(ゴールデンパス) | 迅速なプロジェクト開発のために適切に統合されたコードと機能のテンプレート | ArtifactHub |
| ビルドとテストの自動化 | プロダクトのビルドおよびテストの自動化 | Tekton, Jenkins, Buildpacks, ko, Carvel |
| デリバリーと検証の自動化 | サービスデリバリーの自動化および監視 | Argo, Flux, Keptn, Flagger, OpenFeature |
| 開発環境 | ホスト型IDEやリモート接続ツールなど | Devfile, Nocalhost, Telepresence, DevSpace |
| オブザーバビリティ | 機能、パフォーマンス、コストの観測を含む、メトリクスとダッシュボードを使用したサービス | OpenTelemetry, Jaeger, Prometheus, Thanos, Fluentd, Grafana, OpenCost |
| インフラサービス | コンピューティングランタイム、プログラム可能なネットワーク、ブロックおよびボリューム ストレージなど | Kubernetes, Kubevirt, Knative, WasmEdge, CNI, Istio, Cilium, Envoy, Linkerd, CoreDNS, Rook, Longhorn |
| データサービス | データベース、キャッシュ、オブジェクトストアなど | TiKV, Vitess, SchemaHero |
| メッセージングとイベントサービス | ブローカー、キュー、イベントファブリックなど | Strimzi, NATS, gRPC, Knative, Dapr |
| アイデンティティとシークレットサービス | サービスとユーザーのアイデンティティと認証、証明書とキーの発行、静的な秘密の保存など | Dex, External Secrets, SPIFFE/SPIRE, Teller, cert-manager |
| セキュリティサービス | コードと成果物の静的分析、ランタイム分析、ポリシーの適用など | Falco, In-toto, KubeArmor, OPA, Kyverno, Cloud Custodian |
| アーティファクトストレージ | コンテナイメージ、言語固有のパッケージ、カスタムバイナリとライブラリ、ソースコードの保存 | ArtifactHub, Harbor, Distribution, Porter |
なお上記はあくまでも一例であり、開発者の需要やプラットフォームチームのケイパビリティに応じて、どの要素をどこまで採用するのか優先付けを行う必要があります。
こうして見ると、これまでクラウドサービスでよく目にする「責任共有モデル」において、お客様側の責任範囲とされていた領域が、プラットフォームエンジニアリングの文脈では、さらに開発者とプラットフォームチームに分離されているように感じます。
出典：責任共有モデル
プラットフォームチームの役割
プラットフォームチームには主に次の3つの役割が期待されています。
-
プラットフォームユーザーの要件調査とロードマップの策定
ユーザーインタビュー、ハッカソン、イシュートラッカー、サーベイ、利用状況の直接観測などを通じて、ユーザーの要件を継続的に把握します。 -
プラットフォームの価値についての広報と支持獲得
プラットフォームの価値をユーザーに広く伝え、プラットフォーム活用を促進するための内部マーケティング活動を行います。 -
ポータル、API、ドキュメント、テンプレートなどのインターフェース開発および運用
実際のサービスそのものを開発・運用するのではなく、ユーザーがサービスを簡単に利用できるようなWebポータル、API、テンプレートなどのインターフェースとユーザー体験を提供します。
プラットフォームチームは、必ずしもコンピューティング、ネットワーク、ストレージ、その他のサービスを直接実装するわけではありません。基本的に外部のマネージドサービスを利用し、他に代替手段がない場合に限り、独自に機能を構築、管理することが推奨されています。
プラットフォームチームは、プラットフォームが提供するインターフェイス(GUI、CLI、APIなど) とユーザーエクスペリエンスに最も責任を負うこととなり、開発者向けのインフラ構築や運用は可能な限り手を出さないということです。とはいえマネージドサービスもすべてをカバーできるわけではないため、IaCのテンプレートやコンテナイメージ、ガードレール設定など、実際の詳細な利用シナリオに基づき、ツールを構築・運用する必要はあると考えられます。
効果の測定方法
プラットフォームが適切に価値を提供できているかを判断するために、継続的に利用者からフィードバックを収集し、ユーザアクティビティを測定する必要があります。
注意点として、過度な調査と分析は不必要な労力をかけることとなり、またプラットフォーム自体の直接的な価値の向上にはつながらない可能性があります。適度なバランス感覚を持って、計測方法を検討すべきです。
ホワイトペーパーでは以下の指標が例として提示されています。
| カテゴリ | 指標 |
|---|---|
| ユーザー満足度と生産性 | ・プロビジョニングされた機能の数 ・アクティブユーザー数 ・離脱ユーザー数 ・ネットプロモータースコア(NPS) ・SPACEフレームワークに基づく開発者の生産性スコア |
| 組織の効率 | ・環境のリクエストからデプロイまでの所要時間 ・新規サービスの構築から本番環境へのデプロイ時間 ・新規ユーザーが最初のコード変更を送信するまでの時間 |
| 製品と機能のデリバリー | ・デプロイ頻度 ・変更のリードタイム ・障害時のサービス復旧時間 ・変更の失敗率 |
またプラットフォームエンジニアリングの浸透具合を評価する成熟度評価モデルがCNCFより提供されており、こちらも参考になります。
導入事例
実際にプラットフォームエンジニアリングを採用している企業の事例を見てみます。
-
ニンテンドーシステムズ株式会社（リンク）
内部開発者プラットフォーム（IDP）を構築し、アプリケーションの実行基盤にAmazon ECS on AWS Fargateを採用 -
株式会社バンダイナムコスタジオ（リンク）
セルフサービスや自動化APIを備えたプラットフォームの構築計画 -
みずほリサーチ&テクノロジーズ株式会社（リンク）
AWS CDKを活用したマルチアカウントのプラットフォームをスクラムで構築 -
株式会社リクルート（リンク）
全社的な部署横断型のデータ分析に特化したプラットフォームを提供 -
LINEヤフー株式会社（リンク）
ヤフー社内におけるKubernetesを利用したWebアプリケーション向けのプラットフォームを提供 -
Sansan株式会社（リンク）
R&D部門における必要最低限の機能を提供するプラットフォームの構築 -
GO株式会社（リンク）
SREチームがKubernatesをベースにした社内プラットフォームを構築
アンチパターン
ここまでの内容を踏まえ、プラットフォームエンジニアリングにおいて陥りがちな罠について考えてみました。
1. 実装方法ばかりに意識を取られてしまう
プラットフォームを構成する要素やその実装方法に目が行きがちですが、組織体制や制度の変革も意識しなければいけません。いわゆるDX関連のプロジェクトにありがちですが、最新のサービスを導入したものの、承認のプロセスが冗長となってしまい、結果思ったほど利用が進まないといった問題があります。プラットフォーム利用のシナリオを詳細に策定し、障壁となりうる要素を潰していく必要があります。
2. 提供側の都合を利用者に押し付けてしまう
プラットフォームの目的は「開発効率の向上」であり、開発者をカスタマーと捉えサービスを提供する意識を持たなければなりません。「開発業務の標準化」や「セキュリティやガバナンスの向上」などをプラットフォームのメリットとして謳っても、開発者にはあまり響きません。逆に抵抗や不満を招く危険があります。プラットフォームを提供する管理者側の一方通行的な想いを押し付けないよう、いかに素晴らしい開発体験を提供できるかという点を重視する必要があります。
3. 時間をかけて重厚長大な環境を作ろうとする
AWSをはじめとするクラウドサービスは毎日のようにアップデートが発表されているため、数年かけて一生懸命完成させたプラットフォームが、実はすでに時代遅れになっていたという恐れがあります。まずは汎用的な領域から小さく開始し、徐々にアップデートやフィードバックをもとに機能を追加・改修すべきです。
4. 利用者の悩みを解決したか評価をしない
プラットフォームの導入自体が目的となってしまい、効果を評価・計測していないケースが当たります。「次世代」「業務を効率化を実現」「クラウドネイティブ」などといった抽象的なスローガンを掲げているプロジェクトにありがちで、結局導入して意味があったのか厳しい指摘を受けることが想像できます。構想策定の段階から、具体的かつ計測可能な課題を設定し、導入後も定期的に利用者からのフィードバックを収集、改善できるような仕組みを整備することが重要です。
5. 開発者に選択の余地を与えない
いわゆる共通基盤的な提供方法では、環境の標準化は実現しますが、各システムに求められる個別要件を満たさずギャップが生じる可能性があります。プラットフォームでは、セルフサービスで環境を利用することが推奨されています。ユースケースに沿ったテンプレートをカタログ化し、開発者が自らカスタマイズして利用できることで、開発者体験が向上するはずです。
6. 経営層へのアピールが中途半端
プラットフォームの価値や投資効果は経営層にきちんと示すべきです。経営層の後ろ盾を得ることで、安定した予算の獲得を見込めます。注意が必要なのは、プラットフォームを単なるITインフラとしか認識されていないケースで、価値を認められないと最悪コストや人的リソースの削減を求められる危険があります。先に述べた効果の測定方法を参考に、プラットフォームの導入効果を適切にアピールしなければなりません。
最後に
プラットフォームエンジニアリングは、DevOps文化の成熟と従来型の共通基盤の反省から生まれた方法論であると考えます。海外では、GAFAMに代表されるテック企業を中心に生まれ、近年では一般的なエンタープライズ企業にも広まりつつあります。
日本では、開発体験を重視する企業(特に内製開発が活発な企業)で積極的に採用を始めていることが、今回事例を整理する中で分かりました。今後大手企業でも検討が進むと思いますが、自社でエンジニアを抱えず、外部ベンダーに委託している場合、硬直的な契約関係や組織構造が壁となり、普及するにはまだ時間がかかりそうです。まずは一部の部門やプロジェクトから小さく導入を進め、成功事例を積み重ねていくアプローチが現実的ではないでしょうか。
参考
- プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜（リンク)
- ちがいからみる Platform Engineering（リンク)
- Platform Engineering on Serverless（リンク)
- プラットフォーム エンジニアリングのキャリアを積むための基盤づくり（リンク)
- 組織のクラウドオペレーションをいかにモダナイズするか（リンク)
- 「共通基盤」を超えよ！ 今、Platform Engineeringに取り組むべき理由]（リンク)
- 役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方（リンク)
- 独りよがりのプラットフォーム / For Whom that Platform Runs（リンク)
- 「Platform Engineeringがわからない」を読んで（リンク)
- Google Cloudで始めるプラットフォームエンジニアリング（リンク)
- しみじみ語る Microsoftの考える プラットフォームエンジニアリング（リンク)