プラットフォームエンジニアリング (Platform Engineering) とは？
TL;DR
昨年、2022 年頃から急激に注目を集め始めバズワードとなっている "Platform Engineering" については、Zenn を見ている方たちの多くも注目をしているのではないかなと思います。
日本国内でも関心の高まりはいたるところで目にするようになってきているので、どういうものなのか簡単に "製品ベンダーの中の人" の目線から説明してみたいと思います。
注釈
"製品ベンダーの中の人" の目線と書いたように、ぼく自身は決して Platform Engineer ではありません。そのため、実践した経験をもとに Platform Engineering について説明しているわけではないことを了承していただければと思います。
どうしても、Platform Engineer のコンセプト的に製品ベンダーの人が話す内容と、実践している Platform Engineer の視点とは現実味が異なると思います。今後、ぼく自身も Platform Engineering を実践されている人たちの話を聞きたいな、と思い期待しています。
Platform Engineering が注目する背景
DevOps という土壌があったからというのは、まず大事な要因だと思います。
DevOps については、もはや細かな説明が不要なくらい浸透していると思います。
- ✅ 基盤エンジニアリング - 運用エンジニア - 開発エンジニア をつなぐための取り組み
- ✅ Infrasturecture as Code や テスト自動化など様々な自動化の実践
- ✅ パイプラインを用意し開発工程の様々な作業の連携
などといった取り組みでした。
つまり、DevOps の浸透とともに基盤・開発・運用を 1 つとして考える土壌が整ってきていたということがまずあります。
そして、Platform Engineering が注目を集めたのは、2022 年のガートナーのよるハイプ・サイクルの発表でした。
黎明期の技術要素として、Platform Engineering が登場しました。この黎明期というのは、おおよそ 5 年以内に 80 % の組織が使い始めることになると言われるが技術要素です。
ここでとりあげられ、様々なメディアで扱われるようになり広がったことはあると思います。とはいえ、ここでとりあげられた Platform Engineering の内容自体はすでに実践され広まっていたからこそ、ここに名が上がってきているわけです。どのようなことが実践され、Platform Engineering と言われているか、まずガートナーが伝えている内容を見てみたいと思います。
Gartner: What Is Platform Engineering?
ます最初に次のように言っています。
Platform Engineering は、アプリケーションの提供を加速し、アプリケーションがビジネス価値を生み出すペースを速める新しいテクノロジーアプローチです。
ここで掲げられているメッセージ自体は、DevOps でもよく語られているメッセージです。
また、実践内容と注目を集めている理由についても、次のように書かれています。
Platform Engineering は、自動化されたインフラストラクチャ操作でセルフサービス機能を提供することにより、DeveLoper Experience (DevEx) と生産性を向上させます。Platform Engineeringは、DevEx を最適化し、製品チームによる顧客価値の提供を促進するという約束があるため、トレンドになっています。
ここでも、自動化されたインフラストラクチャや、DeveLoper Experience という DevOps の中でもうたわれているキーワードが目に付きます。
しかし、ここに DevOps を Platform Engineering とするキーワードが 1 つ隠されていることを覚えていてください。
- 製品チームによる顧客価値の提供を促進する
DevOps の中では、自動化や効率化の価値について厳密に考えられてはいなかったのではないでしょうか。開発と基盤に関わるエンジニアが効率的な作業ができるようになり、結果として価値が生まれていたという状況ではなかったでしょうか。
Platform Engineering では、明らかに 顧客 を意識しています。それも、プラットフォームを扱う製品チーム (プラットフォームチーム) にとっての顧客 (利用者) を意識しています。
つまり、プラットフォームの上で動いているアプリケーションを利用するエンドユーザーはもちろんですが、プラットフォーム上のアプリケーションを開発する開発エンジニアを顧客とみなしています。
アプリケーションの要件に優先付けをして開発を行うように、プラットフォームチームは使用する開発者のニーズを理解し、優先付けを行ってプラットフォームへの実装を行い開発者のためのプラットフォームを構築していくのです。また、ユーザーに対する Enablement を実施することも重要です。プラットフォームに対して価値を見出してもらい、プラットフォームを製品として使ってもらうようにするからこそ、プラットフォームチームを "製品" チームと呼んでいる所以でもあります。
それが、Internal Developer Platform (IDP) (内部開発者プラットフォーム) と呼ばれるものです。
Internal Developer Platform (IDP)
IDP と略されるものに、Internal Developer Portal と Internal Developer Platform があることに注意して欲しいです。詳細にはまた別途説明したいですが、文字通り目に見えているUIな部分なポータルと、様々な自動化や実行環境として整備されるプラットフォームと考えておくとよいと思います。
プラットフォームエンジニアリング について
それでは、話を戻して Platform Engineering についてです。Platform Engineering では、顧客に対する価値を意識します。つまり、ある組織や企業にとっての理想的なプラットフォームは、別の組織にとっては約には立たないかもしれません。組織が違えば、顧客 (ユーザー/開発者) が異なり、ニーズが異なってくることがあります。
Platform Engineering の目標は、開発者の生産性を高めることが最重要とされています。そのためのプラットフォームが求められます。このプラットフォームを通して、開発者はパイプラインやさらに低レイヤのインフラストラクチャを意識しなくてよくなります。
つまり、Platform Engineering とは:
- アプリケーションのライフサイクル全体の運用上の必要性をカバーする「Internal Developer Platform (IDP) (内部開発者プラットフォーム) と呼ばれる統合製品を提供
- IDP レイヤーと対話する個々の開発者の好みの抽象化レベルに一致するゴールデンパスを提供
- 開発者は自分の好みに応じてアプリケーションやサービスを実行するための適切な抽象化レベルを選択することが可能
- プラットフォームに顧客に対して製品としての価値を追加するプロダクトマネジメント
- 利用者に対する Enablement
- 問題点の理解と解決
など、顧客を意識した上での製品を育て上げていくというところが、DevOps に追加されている観点ではないかなと思います。
Key Takeaways
Platform Engineering は、まだまだ世界的にもあたらしい分野です。多くの人やベンダーが取り組みながら形作っています。また、この Platform Engineering が何たるかを定義する団体もありません。それは、今日も記載したように組織ごとに求められるプラットフォームへのニーズが変わってくるため、定義付けが難しいということもありからかもしれません。
だからこそ、ぼくのような製品ベンダーの中の人間が発信する Platform Engineering の考えとは別に、実際にプラットフォームに関わっているエンジニアな皆さんからの Platform Engineering についての声が今後聞けるといいなと期待しています。
Discussion