こんにちは。取締役兼ACS事業部の責任者の上林です。
「プラットフォームエンジニアリング」は2022年度、ガートナーの3つのハイプサイクルの黎明期に現れ、5年以内に80%のソフトウェアエンジニアリング組織が使うことになるといわれている概念です。本記事は、今注目されつつあるその概念について「なにそれ？という方」「興味を持って調べたけどわかりづらい、という方」に理解しやすい記事を目指しつつ、「DevOps」を推進したい方々に向けて、最後に少しだけ考察を行っています。なにかのお役に立てば幸いです。
なぜ注目されているの？
デジタルビジネス推進に必要なアジャイルやDevOpsの組織的な推進をしていくうえで一つの突破口として期待されています。DevOpsやクラウドネイティブは難しいです。トップレベルのスキルを持たない組織はなおさらです。そういった組織がその難しさに立ち向かう一つの解としてPlatform Engineeringが発展してきています。
正式な定義は？
標準化団体がいる状況でもなく、色々な文書の中で多少のブレがあります。思い切って一言で表現すると「開発者体験と生産性を高める各種機能を、セルフサービスのプロダクトとして提供する分野」と言えます。わかりづらいので後段でもう少しわかりやすく解説していきます。なお、各種定義を参考までに記載しますが、同様にとっつきづらさはあるかなと思います。
・「Gartner」の定義
https://www.gartner.com/en/articles/what-is-platform-engineering
・コミュニティ「PlatformEngineering.org」の定義
What is platform engineering?
※プラットフォームエンジニアリングという言葉自体は世界的に先進技術を発信しているthoughtworksさんのTechnology Radarで2017には登場しています。本格的に認知され始めたのはDevOpsの組織論Team Topologiesの影響と感じています。
具体的にはどんなものを使うの？
上記の通りプラットフォームエンジニアリングは概念であり、技術やツールそのものではないのですが、かなり広い概念なので、解像度を上げるためにあえて最初に具体的な利用ツール群を記載します。
・IDP(内部開発者プラットフォーム)関連 ←ここが中心になります
・k8sやパブリッククラウドそのもの※
・IaCツール群※
・CI/CDツール群
・メッセージングツール群
・ログやセキュリティツール群
・DBやストレージ関連
※正確にはIaCコントロールプレーンやk8sコントロールプレーン
おやっと思いませんか？ そうクラウドネイティブでインフラを作ることにも感じられます。
プラットフォームエンジニアリングでないもの
ここでは理解を深めるために、定義外のものを把握していきます。
①「IDPとかは良くわからんけど、これはクラウドネイティブ技術を領域としたインフラエンジニアリングのことなの？」と感じた方もいらっしゃるかと思います。これは近しいがイコールではありません。もちろん技術的にクラウドネイティブとの親和性が高く外せませんが、クラウドネイティブでインフラを作ることそのものではありません。この違いこそがプラットフォームエンジニアリングのポイントです。後述します。
②「DevOpsを推進するってことはSREのことなの？」と思う方もいらっしゃると思いますが、これは明確に異なります。この話だけで1テーマになりますので、今回は割愛します。
③IT業界では古来から、インフラエンジニアのことをプラットフォームエンジニアという呼称することがあります(弊社や顧客で見聞きした私の経験です)。例えば今でもパブリッククラウドのことをプラットフォームとおっしゃる方や記事も多いと思いますのでその延長で利用される言葉かと思います。もちろん使い方として間違いというわけではないのですが、このような文脈で使われるプラットフォームエンジニアの定義もプラットフォームエンジニアリングとは異なる場合が多いかと思います。プラットフォームエンジニアリングはもう少し狭義な定義です。
プラットフォームエンジニアリングの理解の解像度を上げる
では単純にクラウドネイティブ技術を利用して環境を構築・運用することとなにが異なるのでしょうか？ 定義から以下の4つの要素が浮かび上がってきます。「①誰に」「②どんな価値を狙って」「③どんな体制で」「④どのように提供するか」。この4つのポイントこそが上述した違いです。解像度を上げるために一つ一つ見ていきたいと思います。
「①誰に？ ＝ 開発チームに」
プロダクトやサービスの「開発者チーム」が対象です。開発者であること、そしてそれ以上にチームであることが重要です。開発チームが重要である理由はDevOpsの第一人者が書いた組織論「Team Topologies」で様々に述べられていますが、ここでは重要であることに記載を留めます。
「②どんな価値を狙って？ ＝ 開発チームの体験と生産性向上を狙って」
開発チームが持つ顧客価値に直結しづらい(煩わしい)作業を担うことで開発チームの体験と生産性を向上します。具体的には「環境構築など手間を取られる作業」「シニアアーキテクトが実施する若手育成」「セキュリティなど組織としては担保が必要な社内調整」「他チームからのアプリ連携の問い合わせ」などなど様々に存在します。
またプラットフォームエンジニアリングを導入作ることで、開発組織に必要な高度なインフラスキルなどのハードルを下げ、開発組織をスケールしやすくします。
「③どんな体制で？ ＝ プラットフォームエンジニアリングチームとして」
複数の開発チームを顧客として、上記の価値を提供することをミッションとしたプラットフォームエンジニアリングチームを組成して実現します。属人化と車輪の再開発を防ぐためです。また、この領域は下記のCNCFのLandscapeにもある通り、非常に技術発展のスピードが速く難易度の高い専門性のある領域でもあるので、専任化がいると言う側面もあります。なお、従来のインフラエンジニアチームとは別種のものであり、名前だけ変更してプラットフォームエンジニアリングチームとするのはアンチパターンの一つです。
「④どのように提供するか？ ＝ セルフサービスのプロダクト型で」
プラットフォームエンジニアリングはいつでも開発者が使えるようにセルフサービス型で提供されます。パブリッククラウドをイメージしてもらうとわかりやすいと思います。開発者がパブリッククラウドでサーバを立ち上げようと思った場合、マニュアルや組織としての設定が準備されていれば、webでぽちぽち作業するだけで完了します。これがセルフサービス化です。
そして、パブリッククラウドは使い勝手に不満があり要求しても、すぐに直してはもらえないと思います。これがプロダクト型での提供です。プラットフォームエンジニアリングチームは要望をなんでも受け入れるのではなく、顧客(開発チーム)のニーズを把握しつつ繰り返され再利用できる作業にフォーカスし機能をつけ足したり改修します。
以上のようなセルフサービスのプロダクト型環境を実現することを考えていくと、クラウドネイティブ技術が必要とされてきます。言い方を変えればクラウドネイティブ技術が本来目的にしていた「①誰に」「②どんな価値を狙って」「③どんな体制で」「④どのように提供するか」を明確にした概念がプラットフォームエンジニアリングとも言えるかもしれません。
ボリュームが多くなってきたので、次回は、世界や日本でプラットフォームエンジニアリングがどのような状況かを少しご紹介したいと考えています。
終わりに考察 プラットフォームエンジニアリングは日本にこそ重要
プラットフォームエンジニアリングという新しい流れ、いかがだったでしょうか。
アプリケーション開発の歴史は抽象化を繰り返してきました。この流れは開発組織の中の新たな抽象化への新たな発展と見ることもできますし、組織の自律の為の標準化・分散化のバランスを考えた組織論としても発展していると見ることができ、各界の英知と苦労が結集した進化中の概念として興味深いです。
DevOpsやクラウドネイティブ技術が発展を続け、あらゆる組織で必要となると言われるものの、誰しもがすべてを体得できない。プラットフォームエンジニアリングはそんな矛盾した状況を解決するため発展してきた概念ですので、必要な要素として説得力があり、特に日本においてこそより重要な概念であると注目しています。
なぜなら日本においてもこれだけDXが語られ、企業の内製化という文脈が進んでは来ているものの、これまでのSI構造から考えた場合、内製化に挑戦するユーザ企業の人材やスキルは限定的になるのは間違いないからです。
我々は、クラウドネイティブ技術・Team Topologies・プラットフォームエンジニアリングなどを活用した、技術/組織/プロセスにおける内製化の支援を実施しております。我々としては、このプラットフォームエンジニアリングも内製化推進の重要なファクターになっていくものだと考えており、活用することでその発展に貢献していきたいと考えています。
