こんにちは。プラットフォーム開発部 EMのchikaです。

今回は、最近話題沸騰！らしいですが、個人的にちらほらと目にすることになった「プラットフォームエンジニアリング」(Platform Engineering) について気になったので、ざっと調べてみた内容と、知る過程で疑問に感じたところや面白いと思ったところをまとめてみます。

もしかしたら一部理解に誤りなどあるかもしれませんが、見つけたら優しくこっそり教えてください。笑

プラットフォームエンジニアリング(Platform Engineering) とは
ここが気になるプラットフォームエンジニアリング、4つの疑問
それでもプラットフォームエンジニアリングに関心を惹かれるところ３つ
さいごに
We are hiring!

プラットフォームエンジニアリング(Platform Engineering) とは

雑に紹介すると

はい、このへん見ればだいたいわかります。

30分ほど（倍速すれば15分ほど）で分かった気になれる素晴らしくまとまった内容です。

...と、これを紹介すればこの記事は終わりにしても良いくらいですが、それならTwitterもといXでシェアすれば終わるので、せめて上のリンク先を読んでみる気にできる程度には説明して、自分がなぜ興味を持ったのかを共有してみるべく、書いてみます。

ちなみに、日本語で記事を書く中でカタカナと英語どちらで扱ったら読みやすいか悩ましいところですが、一旦日本語表記で統一しておきます。

話題になっているって？いつから？

半年以上も前に開かれた上記Meetup #1のアーカイブで、のっけから「話題ですよね！」と言われているのを「お、おぅ…」と言うしかない自分がそこにいたのですが、スイカゲームの存在を先月まで知らなかった自分のアンテナではキャッチできなかったのは当然なので仕方ありません。笑

プラットフォームエンジニアリングは 2023年初頭から注目されるようになったキーワードですが、2022年度、ガートナーの3つのハイプサイクルの「黎明期」に現れ、5年以内に80%のソフトウェアエンジニアリング組織が使うことになるといわれている概念です。

（Gartner、「先進テクノロジのハイプ・サイクル：2022年」を発表に掲載されている図に一部追記）

定義されている言葉なの？誰が？

はっきりとした定義はまだない様子ですが、とりあえず、ガートナーやPlatformEngineering.orgでは以下のように書かれています。

ガートナーより

• Platform engineering is the discipline of building and operating self-service internal developer platforms (IDPs) for software delivery and life cycle management.

プラットフォームエンジニアリングは、ソフトウェアの提供とライフサイクル管理のためのセルフサービスの内部開発者プラットフォーム (IDP) を構築し、運用するための分野です。（Translated by みらい翻訳）

出典： https://www.gartner.com/en/articles/what-s-new-in-the-2022-gartner-hype-cycle-for-emerging-technologies

PlatformEngineering.orgより

Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application.

プラットフォームエンジニアリングは、クラウドネイティブ時代のソフトウェアエンジニアリング組織のセルフサービス機能を可能にするツールチェーンとワークフローを設計および構築する分野です。プラットフォームエンジニアは、アプリケーションのライフサイクル全体の運用上の必要性をカバーする「内部開発者プラットフォーム」と呼ばれる統合製品を提供します。（Translated by みらい翻訳）

出典：https://platformengineering.org/blog/what-is-platform-engineering

つまりどういうこと？

両者の定義をまとめると、「開発者体験と生産性を向上させるために、セルフサービスで利用できるツールチェーンとワークフローを設計・構築・運用するエンジニアリング領域」といったところです。

もう少し別の言葉で説明を試みるなら、開発者が価値あるソフトウェアを素早く届けることに集中できるようにするために、認知負荷を下げ、開発者体験と生産性を向上させる仕組み、基盤などを開発・運用していく取り組みのことです。

気になった（この記事を書こうと思った）きっかけ

ちなみに今年初めごろから話題になってたというのにずいぶんと遅まきながらですが、私がプラットフォームエンジニアリングのことにはっきりと興味を持って調べようと思ったのは、ポッドキャスト fukabori.fm 第104回で、冒頭のMeetupの「Platform Engineeringへの招待」を講演された @jacopen さんがゲスト出演しプラットフォームエンジニアリングについて話されているを聞いたのが直接のきっかけです。

最初に雑に紹介した Platform Engineering Meetup は既に今年5回も開かれているようです。全部は見ていませんが、これらのアーカイブは大変参考になりました。

https://platformengineering.connpass.com/event/295048/

platformengineering.connpass.com

また、「プラットフォームエンジニアリング」が分からない、と言う物議をかもす記事タイトルを見かけたのも、この話題に興味を持ったきっかけの一つでした。

https://ascii.jp/elem/000/004/157/4157089/

ascii.jp

ここが気になるプラットフォームエンジニアリング、4つの疑問

ここまで、まずはざっくりとした定義だけを説明しましたが、次にこのキーワードに引っかかった人みんなが最初に気になるんじゃないかと思うところを、私が感じたことも交えて４つ挙げます。

1. ここでいうプラットフォームや基盤ってどんなもの？

プラットフォーム自体が広い概念なので具体的に示すのは難しいですが、この話題で頻出するキーワードとして、IDP（Internal Developer Platform）という単語が登場します。

IDPは、いわゆる「プラットフォームチーム」が作る、開発者がセルフサービスで利用できることを可能にする基盤のことを指します。

なんのこっちゃ、イメージがわかないのでIDPに含まれるであろうものの例を挙げます。

k8sなどのコンテナ基盤
IaCツール
CI/CD関連ツール
メッセージングツール
ログ関連ツール
セキュリティツール
DBやストレージ関連

（参考：https://techblog.ap-com.co.jp/entry/2023/01/18/170829）

クラウドネイティブな開発に必要なインフラ関連の技術スタックという印象ですが、ちょっとした使い捨てのアプリやPoCでない限り、これらツールを素の状態で各自が扱って運用に乗せるというのはさすがに非効率です。

標準的な使い方やテンプレートを整備して各ツール間の連携も取れるようにし、できれば複数チームで共通に使えるように構築して提供するという活動をすることになると思います。

こうして各現場に合う開発環境づくりをする活動のことだと捉えておけばイメージとしては概ね合っているんじゃないでしょうか。

このプラットフォームの説明では一般的なInfrastructure周りのツールを中心に説明されていますが、サービス特有の専門性の高い技術を要する機能を、程よく抽象化したAPIとして利用可能にするといったものもプラットフォームが提供するものに含まれるものと思います。

2. インフラやSREのこと？

並んだリストを見て、インフラやSRE（これらも同義ではないですが）の仕事じゃない？と思われた方も多いかと思いますが、これは違います。

SREはサイト（プロダクト）の運用におけるソフトウェアエンジニアリングを推進する活動であり、その活動はサイトを利用するユーザーに向けた信頼性向上のためのものです。

プラットフォームエンジニアリングは先の定義の通り、「開発者体験と生産性を向上させる」のが目的なので、顧客は開発者となります。

「インフラチーム」という役割の場合も含めて、インフラを対象領域にしているとどうしても開発環境周りの構築・運用も彼らの仕事であると思われがちですが、本来のチームミッションはプロダクトの運用環境に対する課題解決であるはずなので、プラットフォームエンジニアリングはその意味でSREとは別の活動であり、より狭義のインフラ周りが対象領域となります。

とはいえ、インフラやSREがプラットフォームを構築しているケースは非常に多いと思います。私達の現場でもプラットフォームエンジニアリングを担っているのは現状SREであるのが実態なので、この領域を早く整備して本来のSRE領域にリソースを割きたい、という思いはあります。

3. これって「共通基盤」のこと？

じゃ、あれだ。いわゆる「共通基盤」ってやつでしょ？と思ったあなた、正解です。

こういった取り組みや概念は急に生まれたわけではなく、ある程度大きな規模のプロジェクトや複数プロダクトを取り扱うサービスなどでは特に立ち上がり初期に一般的に行われてきたものだと思います。

では、それらとプラットフォームエンジニアリングは何が違うのでしょうか？

ひょっとして、同じだけど名前がついたことでリブランドされただけなのでしょうか？

端的に言えば、作ろうとするものは同じですが、作って終わりでなく、開発者にとって価値ある・使われ続けるプラットフォームを開発・提供し続けるための活動だということです。

4. PaaSを利用した自前脱却主義の話？

開発をする前に立ちはだかる開発環境構築、ビルド・デプロイのパイプライン構築・運用などについては、プロダクト開発チームが自前で諸々考えてやるのは面倒くさいし、なかなかプロダクトに集中できないよね、集中できるようにするまでが長いよね、というのは分かる方も多いかと思います。

これらペインを解消して効率化するためのサービス群として、PaaS（Platform as a Service）があります。PaaSといえばHeroku、Salesforce、GAE...というのはもう感覚が古いかもしれませんが、これらは動くプログラムを作ることに集中して、ビルド・デプロイ・運用などの面倒から解放してくれるサービスです。最近で言えばAWSに開発者体験を上げるマネージドサービスが多数ありますし、GitHubもできることがかなり増えています。

なので、最初はプラットフォームエンジニアリングとはこれらの悩みを解消するマネージドサービスのPaaSが競争激化してきた話なのか？と思っていましたが、それは少し違いました。

もちろんPaaSを使って解消できるペインは大きいので、自分たちのチームのIDPにPaaSを含めるケースは多い（というか、確実に何らかは使う）と思いますが、PaaSを導入すればすべて解決するわけではなく、プラットフォームエンジニアリングでは自前のツール、OSSも含めてトータルに最適解を考えます。

それでもプラットフォームエンジニアリングに関心を惹かれるところ３つ

ここまでの説明で、やはりこれは新しい概念ではなく、どうやら昔からあるものに新しい名前が付いたという方が実際の感覚に近いと思います。

それでもこのトレンドに多くの人がきょうみを示すのは、ただのリブランドではない何かがあるからです。それが何かというのは人によってさまざまだと思いますが、私がこのプラットフォームエンジニアリングの存在価値を感じて興味を持ったところを３つほど挙げます。

1. それがプロダクト開発現場のリアルな課題であること

プラットフォームエンジニアリングが生まれた背景には、DevOpsが進んできた結果の副作用として開発者が扱わなければならない技術も増えてしまい、結果的に生産性が上がらないという課題があるのですが、「これこれ！」と、まさに今開発現場で起きていることだと共感度MAXな課題だったので首がもげるほど頷きました。

Platform Engineeringへの招待 - Speaker Deck (P.14)

開発チームのタスクのかなりの割合を、環境周りの整備やCI/CDに関する作業が占めてしまうということも珍しくないと感じます。実際に「最近Terraformばかり書いている」とちょっとした愚痴をこぼすメンバーの声を聞くこともあります。

開発チームの認知負荷が高くなった結果、ツール類を使いこなせるごく少数のメンバーがチームの中でOps担当として一手に引き受けてオペレーションをするようになるというのも、思わず「あるある」と言ってしまうほどやりがちなパターンです。

Platform Engineeringへの招待 - Speaker Deck (P.16)

2. あまり語られることのなかったプラットフォームづくりの難しさが伝わってくること

冒頭のMeetupの講演では、「そのプラットフォーム、上手くいきましたか？」という問いから、プラットフォームづくりの難しさを説明しています。

Platform Engineeringへの招待 - Speaker Deck (P.33)

基盤もといプラットフォームを作ろうとする取り組みはあちこちの現場で行われますが、「そのプラットフォームが使われ続けているか、開発者に価値を提供し続けているか」を思い起こしてみると、良くない意味で心当たりが色々と浮かんできます。

認知負荷を下げて開発を高速化するためのプラットフォームなのだが、APIで提供されているものが少なく、インテグレーションにそれなりの工数を要してしまう
プラットフォームの提供するAPIを利用するためのお作法的な手順や準備が面倒で、直接アクセスしてしまう亜種を生み出してしまう
プロダクトローンチ後の運用に入ってからはプラットフォームを開発する動機が続かないため専任チームを配置できず、誰がプラットフォームチームの担当なのかがよく分からなくなる（利用している複数チーム間で押し付け合いになる）

これらはそれぞれの開発現場ではよく起こっていたことなのですが、ここに焦点が当たって問題提起されたことに意味があります。

3. プラットフォームをプロダクトとして開発する (Platform as a Product) という考え方

では、作って終わりでなく使い続けてもらえるよう継続的に開発するには？という疑問に対する考え方として、プラットフォームをプロダクトとして開発していく（Platform as a Producrt）こと、そのためにはプロダクトマネージャーをアサインする必要があるということ、ということが講演でも言及されていました。

Platform Engineeringへの招待 - Speaker Deck (P.37)

これには思わず膝を打ちました。

というのも、私たちのサービスでもプラットフォームにあたる部分について、テクニカルPOが必要かもしれないねという話をつい先日していたところだったからです。

一般的に基盤やプラットフォームと呼ばれる部分については、これまでプロダクトオーナー（PO）を立てるという考えはなかったと思いますが、例えば社内の開発者に向けて各種ツールを作りやすいようにAPIを整備したり、共通的な技術負債への対策を継続的に行う活動・仕組みなど、「ビジネスとして行いたいこと」に直結はしないけれど絶対に必要なことは確かに存在します。

これらを優先順位を立てて着実に実行していくためには、プラットフォーム自体を開発者向けのプロダクトと捉えて課題を進める専任のPOとチームが必要です。

ただ、このチームを専任で継続させることに会社として投資することと、アプリケーションと違ってかなりテクニカルな領域に強いPOを採用すること、この2つは難易度がかなり高いと思いますが、これは今後のプラットフォームエンジニアリングの認知度向上に伴って少しずつ難易度が下がっていくと期待しましょう。