🙋‍♂️

「Platform Engineeringがわからない」を読んで

2023/09/22に公開

私は最近、Platform Engineering Meetupにオンライン参加して話を聞いたり、CNCFの『Platforms White Paper』を読んで、その所感をZennのエントリーにしたり、所属する会社の勉強会でPlatform Engineeringについて同僚とディスカッションしたりする中で、「Platform Engineeringってこういうものなのかな？」というのが最初の頃よりは明確になってきました。

そこで、上記の記事を読んだ上で、私の理解に基づく意見をこのエントリーに書きます。なお、私はPlatform Engineeringをメインにやっている人ではないので、理解が行き届いていない部分や誤解も多々あると思います。一方で、この話題に利害関係がほとんどない点はバイアス排除の面で有利だと思います。

Platform Engineeringがなぜ必要なのか

Platform Engineeringは、企業や組織を取り巻くIT環境がクラウドネイティブ化し、DevOpsやSREと言ったモダンな開発・運用手法と文化が進展する中で生まれてくる「副作用（課題）」に対応するために生まれた補完的な概念です。そのため、Platform Engineeringが必要かは、後述する副作用（課題）がどれだけ当てはまるか次第です。言い換えると、Platform Engineeringが必要となるくらい副作用（課題）が発生しているならば、その組織はクラウドネイティブ組織としてかなり成熟度が高いと言えます。

DevOpsやSREの文化が浸透した組織というのは、システムの安定稼働を重視しつつも、市場の変化に対応し、競合組織との競争に打ち勝つためにも、機能のリリース速度や頻度を特に重視するという考え方が企業経営の中心に据えられています。そのような組織にとって、コストは依然として重要な要素ではあるものの、開発スピードとテクノロジーによる差別化は大きな関心事です。

DevOpsやSRE以前は、アプリケーション開発者とインフラ担当者が完全に分割され、機能リリースと安定稼働というそれぞれの評価指標が対立関係を生むという構図が発生していました。市場の変化への対応スピード向上を重視する組織はこの問題に対して、情報共有と相互尊重を行うOne TeamとしてのDevOpsチームの組織化や、SREのエラーバジェットの考え方の導入などを行い、システムの稼働は重視しつつも、開発速度や機能改善の向上をはかる取り組みを図ってきました。

この時期にITテクノロジーにも大きな変化が発生しました。それは仮想化、コンテナ、IaCといったテクノロジーの進展と、パブリッククラウドの普及に代表されるマネージドサービスの活用です。以前は物理ハードウェアの調達とデータセンターへの搬入からスタートするのが一般的だったのが、非常に多くの領域においてSoftware DefinedでITシステムを構築・管理できるようになってきました。物理的な作業を伴わないため、ソフトウェアエンジニアでも担当できる領域が増えてきています。

DevOpsチームやSREチームのソフトウェアエンジニアが、Software Definedな環境で担当できる領域が徐々に増え、チーム内で最適なツールを選定して簡易に活用できるようになったことは、プロジェクトの特性に応じた開発環境の最適化という意味では大きなメリットです。一方で、以前はアプリケーションコードとCI/CDパイプラインにだけ集中していればよかったものが、コンテナオーケストレーション環境のプロビジョニングや、Observabilityやセキュリティツールの組み込みなど担当する領域が拡大してきました。それらの領域において、複数のツールの中からチームにとって最適なツールを選定し、自分たちで設定を行うことはソフトウェアエンジニアにとっては負荷であり、一人一人の人間の能力の限界に到達しようとしています。この負荷を「認知の負荷（Cognitive Load）」と言います。

アプリケーションコードを開発でき、機能リリースに貢献することが期待されているソフトウェアエンジニアの「認知の負荷」を軽減し、その組織にとっての中心的な関心事である「開発スピードの向上」を如何にして実現できるか、という課題に対応するアプローチとして必要性が提唱されたのがPlatform Engineeringです。そして、これらの課題は、DevOpsやSREの手法・文化が十分に組織に適用し、ビジネスをグロースさせるために開発速度の向上が何よりも重要と考える組織だからこそ切実に感じる問題だと言えます。こういった問題意識がない状態では、Platform Engineeringがなぜ必要かは実感が十分にわかないと思いますし、その状態でPlatform Engineeringの考え方を適用しようとしても挫折する可能性が高いと思います。

Platform Engineeringとはなにか

CNCFの『Platforms White Paper』が簡潔にまとまっていますので、このエントリーでは割愛します。私が読んだ所感はこちらに書きました。

「 Platform Engineeringがわからない」の疑問点への回答

開発者ポータルは必要なのか

プラットフォームエンジニアリングでは開発者ポータルが万能薬のように思えるが、これは正しいのか？あるいはJiraやGitHub、既存のCI/CDツールでは、こうした開発者ポータルのような役割は果たせないのだろうか？

開発者ポータルは、Platform Engineeringチームが提供するPlatformにおいて、利用者（DevOpsチームなど）に対して一貫したインタフェースのセルフサービスを提供するためのツールです。CNCFのプロジェクトでは、Backstageが代表的なツールです。

Internal Developer Platformコミュニティによると、アクセス制御の柔軟性やコスト管理能力などが必要な場合は開発者ポータル製品の導入検討が必要ですが、そうでなければHerokuなど既存のツールを使うことが合理的である（開発者ポータル専用製品の導入はオーバーキルである）ということです。また、DevOpsチームの規模が15人以下の小規模な組織で既存メンバーで十分に回っている組織や、扱っているITシステム環境がモノリシックであったり、一つのパブリッククラウドだけ使っている場合も、あえて導入する必要性は少ないと言えます。

そのため、開発者ポータルは必要ない場合もあると言えます。前述の『Platforms White Paper』でも、最もシンプルなPlatformは、標準導入手順書へのリンクを張ったWikiページと言及があり、ポータルの導入が必須とは言えません。ただし、GitHubやJIRAなどはSource Code RepositoryやIssue Trackerであり、Platformとしてどのような機能を誰に提供するかをコントロールすることに最適化した製品ではありません。Platformの利用者が増えてきた時に、Platform Engineeringチームが個別の要求に都度応答するのはスケーラビリティ上の制約になるので、セルフサービス型で利用できる専用の開発者ポータル製品を導入するのが合理的な段階は必ず来ると思います。

これまでの共通基盤と何が違うのか

プラットフォームエンジニアリングと既存の手法との違いが開発者ポータルくらいしか思いつかない。

ここでの「既存の手法」というのは「これまでの共通基盤」という意味ですが、これはAPCさんのスライドにある「大事にすること」「標準化の考え」の違いが一番のポイントです。これまでの共通基盤は、「品質、ガバナンス、コスト、効率化」を重視し、「トップダウンの効率化」を図ってきたものに対して、Platformというのは「信頼性を確保しつつ、開発者体験とリリース頻度の向上」を目指し、「開発者が選択的に構成可能」であることが性格的な一番の違いです。

この性格の一番の違いが最も顕著に現れるのは、「開発者はPlatformが提供している機能を使うことを強制されない」ということです。一般的に共通基盤がある組織は、その共通基盤の投資コストを回収するために、共通基盤の利用が要件として課せられ、使わない場合も「使わない合理的な理由」を説明し、例外承認を得ることが必要になります。しかし、Platformは使わないでもいいのですから、メリットが無ければ開発者は使いません。Platform Engineeringチームとしては、せっかくPlatformを提供していても利用者がいないのであれば自分たちの存在意義はないので、使ってもらえる機能をPlatformとして提供しようと改善に努力します。これはProduct Management（PdM）的な考え方であり、Platform EngineeringにおけるPlatformが「Platform as a Product」と呼ばれる特徴です。

この「これまでの共通基盤」と「Platform」はどちらが良いとか悪いとか言う話ではありません。「これまでの共通基盤」は、半強制利用が必要であるゆえに、個々の開発チームの要件と多少ギャップがあっても無理やり使わざるを得ず、開発者体験を損なうこともあります。半強制利用だから利用者の意見を聞かないというわけではないと思いますが、コスト重視の考え方から少ない運営費用での投資回収が優先であり、継続的改善に十分なコストをかけられないかもしれません。一方で、ある程度の利用数が想定できることで投資計画が立てやすく、導入のビジネス上の意思決定が取りやすいこと、半強制的であるゆえに全体最適でツールを選定し、ITシステムの一貫性やガバナンスを確保できる点に大きなメリットがあります。その意味では、記事中に登場するセントラルキッチンの例は、Platform Engineeringではなく、共通基盤のトップダウン型の考え方の代表例という理解です。

一方、Platformは利用が確約されないため、利用者（開発者）の需要に即して、継続的に使いやすいものを提供しなければなりません。うまくいけば開発者体験は向上するかもしれませんが、Platform Engineeringチームに費やしたコストが十分に回収できるか事前に計画することは難しいでしょう。また、機能が使われるかは分からないので、共通基盤では期待される開発環境の標準化推進の効果などは得られるとは限りません。さらには、Platformの目指す「開発者体験やリリース頻度の向上」は、利用者（開発チーム）側の成功を通じて得られる間接的な価値であり、Platform Engineeringチームが評価を得るには、自分たちのチームの価値を社内のエグゼクティブに証明しないといけない点に難しさがあるとGartnerは指摘しています。

通常、エグゼクティブは投資の費用対効果を厳密に管理しようとするため、共通基盤に比べるとPlatform Engieeringの導入は経営意思決定上のハードルが高いと思います。それが、問題の実感がない組織ではPlatform Engineeringの導入は難しい、と私が上述した理由です。スポンサーとなるエグゼクティブの確保がPlatform Engieering導入のキーポイントになる部分であり、『Platforms White Paper』が、企業リーダーの説得に利用してもらい、と書かれている理由だと思います。

Platform Engineeringチームは何をやるのか

「1人で最大100人の開発者をカバーできる」と謳うプラットフォームチームの役割もなぞだ。そもそもプラットフォームチームは、開発者ポータルを運用する立場なのか。従来インフラチームが人手で担っていたような作業は、そんな簡単にツールで代替できるのか？開発者の体験を上げるための環境作りを実現するのは、かなりスキルや人望が必要になるのでは？

Platform Engineeringチームの役割は、利用者である開発チームの「認知負荷の軽減」のためのアクションです。利用者がどのような問題に直面しているかをインタビューし、それを解決あるいは問題を軽減するための最小限の対応策を提示するのが仕事です。

『Platforms White Paper』でも明確に言及がありますが、Platformは共通基盤のようにシステムを運営・提供することを目的としていません。むしろ、サードパーティのマネージドサービスをできるだけ活用し、Platform Engineeringチームはシステムをできるだけ自分たちで持たないことが推奨されています。開発者ポータルを導入している時には、そのポータルの運用は必要かもしれませんが、それ以外のシステムは持たず、キュレーションサービスをメインに据えるやり方は一つの形だと言えます。Platform Engineeringチームは実体のシステムを持たないので、共通基盤と併存も可能なはずです。共通基盤利用への導線として、Platform Engineeringチームを組織する方法もあり得ると思います。

Platform Engineeringは人材不足の解決につながるのか

そもそも一般企業では鉄人のようなフルスタックエンジニアが雇えないという課題が前提でプラットフォームエンジニアリングが提唱されたと理解しているので（中略）エンジニア不足という課題に対して、質が上がるのか、少ない人数で済むのか、プラットフォームエンジニアリングがどのように作用するのかもわからなかった

Platform Engineeringは分業化を促進することで、開発チームは開発作業に専念できることで、フルスタック性は必要なくなった（＝開発だけできれば良くなった）という話になると思います。スキルエリアが狭まれば、ITエンジニアの確保や育成は以前よりも容易になりますし、質の向上も期待できます。

上述したようにSoftware Definedな世界が広がる中で、コード開発とCI/CDパイプライン設定だけでなく、コンテナ環境のプロビジョニングや監視・セキュリティ周りの設定など幅広いスキルが求められるようになり、ITエンジニアにはフルスタック性が必要になってきました。しかし、Platformとして選定されたツールの中で標準手順に従って選定する前提においては、そのようなインフラ周りのスキルは必須ではないので、コードだけ書ける人でも活躍できる余地が生まれます。

この場合、Platform Engineeringチームの方にはインフラ領域を専門とするITエンジニアは必要となるのですが、そのITエンジニアはアプリケーション開発が必ずしも出来なくても大丈夫かもしれません。また、Platformで提供する機能は複数のDevOpsチームで共通して使われる機能となるため、各チームごとにその機能を扱えるITエンジニアを抱えるよりも要員の集約効果はあがります。

このPlatform Engineeringの話は、アプリケーション開発チームとシステム運用チームがDevOpsチームに集約された後に、再びアプリケーション開発チームとPlatform Engineeringチームに分散されたみたいな構図に見えます。もちろん、単純に以前の状態に戻ったわけではなく、集約に伴う課題を意識し、ITシステム環境の進化にも対応して、違った形に分散（分業）された形と言えます。一般的に仕事の単位が小さくなると、多くの人がその仕事をできるようになるので、Platform Engineeringは幅広い高度なスキルを求めないという点で、人材不足の解決に一定の効果はあると思います。

Platform Engineeringについて同僚と会話した際も、これが必要となるステージに至るまで（＝Platform Engineeringで解決したい課題が発生するまでクラウドネイティブ化が進むまで）が多くの企業・組織にとっては大変だよね（もっとがんばっていかないといけないよね）、という話になりました。

クラウドネイティブやDevOps、SREの推進の先に、Platform Engineeringが必要となる課題として意識しつつも、まずは自社のIT環境のモダナイズや文化の醸成をしっかり推進していくことが大切だと思います。そして、Platform Engineeringが本当に必要なステージにいるのか確認し、必要なのであれば導入検討をすることが重要だと考えています。