「Platform Engineeringへの招待」、開発者の生産性を高めるプラットフォームを作り、運営していくための考え方とは（前編）。Platform Engineering Meetup #1

急速に注目を浴びつつある新しいムーブメント「Platform Engineering」についてのコミュニティイベント「Platform Engineering Meetup #1」が3月9日に都内でオンラインとオフラインのハイブリッドで開催されました。

Platform Engineeringとは、クラウドネイティブ時代においてソフトウェアエンジニアリング組織にセルフサービス機能を提供するためのツールチェーンやワークフローを設計し構築する技術分野とされています。

その最初のセッションとして行われた、イベントの主催者である草間一人氏の「Platform Engineeringへの招待 - Platform Engineeringって何？ 何故今注目なの？」の内容を紹介しましょう。

記事は前編と後編に分かれています。いまお読みの記事は前編です。

Platform Engineeringへの招待

草間と申します。インターネット上では@jacopenという名前でよく出てきますので、よろしくお願いします。

普段はHashiCorpという会社で仕事をしています。

Cloud Native Daysというカンファレンスを青山くん（@amsy810）と一緒にやっていたり、PaaSに関する勉強会をやったりもしています。

もともと国内の通信事業者でCloud FoundryというオープンソースPaaS（Platform as a Service）を利用したサービス開発をやっていたのですが、その流れからCloud Foundryの開発元であるPivotalという会社に転職しました。

その後PivotalはVMwareに買収されたので、VMware社員としてKubernetesやCloud Foundryを用いた製品をお客様にデリバリーする仕事や、プラットフォームチーム作りを支援する仕事をやっていました。

なんだかんだで私はプラットフォームに関わる仕事をやって10年以上経ったんですね。

そのあたりの知見も踏まえてお話できればと思っています。

Platform Engineeringって何だろう

「Platorm Engineering」が突然話題になってますよね。

面白かったツイートがあったのでちょっと貼ってみましたが、これはDevOpsと言っていたみんなが急にPlatform Engineeringへ流れ始めているよね、と。

そこで、そもそもPlatform Engineeringって何だろう、という話をさせてください。

Platform Engineeringという考え方は突然出てきたのではなく、以前から使われていた用語でしたし実践されてる方も多かったんです。

ただ、世の中に広がり始めたきっかけはガートナーのハイプサイクル2022で左下のあたりの、まさにこれから盛り上がっていくぞ、みたいなところに登場したのが大きかったのかなと思っています。

参考：米ガートナー「先進テクノロジーのハイプサイクル2022年」を発表。分散IDやWeb3は過度な期待、機械学習によるコード生成、デジタルヒューマンなどは黎明期

それによると2026年までに、ソフトウェアエンジニアリング組織の80%がPlatform Engineeringのチームを結成し、そのうち75%はセルフサービス開発者ポータルを取り入れる、と書いてあります。

ただ、Platform Engineeringには、今のところ決まった定義はありません。

ガートナーが出している定義もあれば、PlatformEngineering.orgというWebサイトがあって、そこで書かれてる定義などもあります。

これらに共通するところを抜き出すと、Platform Engineeringとはこういうことだと言えるのかな、というのを書いてみました。

「Platform Engineeringとは、開発者体験と生産性を向上させるために、セルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野」

Platform Engineeringが注目される背景

Platform Engineeringが注目されるようになった背景について考えてみましょう。

クラウドが登場する前からITのシステムはありました。

その時代は開発者（Dev）とシステム管理者（Ops）は別の組織になっていて、開発者はシステム管理者に、環境を構築してくださいとお願いしたり、アプリケーションをデプロイしてくださいとお願いしたりしていた。これが一般的だったわけです。

ただこのスタイルでは問題がありました。DevとOpsはそれぞれサイロ化しやすく、組織から組織に仕事を依頼する形になるので、どうしてもコミュニケーションのコストが大きくて、そこがボトルネックになってしまう。

システム管理者が忙しすぎてソフトウェアがデリバリーできない、といったことが起きていたわけなんです。

これが変わり始めたのが、クラウドの登場ですよね。

クラウドが登場したことで、APIドリブンで環境を払い出せるようになりました。そして、開発とシステム管理の垣根をなくしてDevOpsを実現し、ソフトウェアのデリバリーを継続的にやっていこう、みたいな機運も出てきました。

このどちらが先かは諸説あるんですけども。

そこで「真のDevOps」と書いたのですが、自動化のためのツールチェーンなどが出来上がってくれば、その気になれば開発者が開発もテストもデプロイも、やろうと思えばできるわけです。

やろうと思えば。

ですが現実問題として、どうですか。皆さん、やりますか？ 実は多くの組織にとって、これは現実的ではないんです。

ツールやフレームワークがありすぎる

なぜかというと、特にクラウドネイティブの時代になってからは、たくさんツールなどを使いますよね。

KubernetesやDockerだけでなく、いろんなフレームワークやツールがあって、とにかくいろんなツールを組み合わせてアプリケーションの開発やデプロイをしています。

これを1人の開発エンジニアや1つの開発組織で全部やっていくのはしんどいわけです。

「認知負荷が高い」という言い方をしたりしますが、とにかくいろんなソフトウェアやツールやサービスに気を使わなくてはいけないので、1つのことに集中できず、結果として生産性が高まらない。

2010年頃にHerokuとかCloud FoundryなどのPaaSによって認知負荷は減るのかな、という流れはあったのですが、その後のクラウドネイティブの時代になると、いろんなツールがあふれかえってきて、認知負荷はもう右肩上がりです、というのが現状だったりします（参考：Platform Engineering 101: What You Need to Know about This Hot New Trend - InfoQ）。

どうするか：よくあるアンチパターン

じゃあどうするか。

かつてのDevとOpsが分かれていた時代に戻したくはないですよね。

そこでDevとOpsがサイロ化しないようにと考えた結果、開発チームのそれぞれにOpsを担う人材が出てくる。チームの中にKubernetesのManifestを書くのが得意な人がいて、その人にお願いしてしまうとか。

特定の人がチーム内のOps担当みたいになって、そうした仕事が集中してしまう。

多くの場合、そうしたOpsもできる有能な開発者は知見も豊富なハイパフォーマーであることが多くて、その人にOpsの仕事が集中してしまうとすれば、チームの生産性が最大化できているのかというとそうではないのではないか、となります。

DevとOpsがサイロ化しないように考えたのに、これはアンチパターンになってしまうんですね。

そこで出てくるのが「Internal Developer Platform」というもので、これはPlatform Engineeringを調べるとよく出てくる単語だと思います。

社内向けのプラットフォーム：Internal Developer Platform

Internal Developer Platformは、「プラットフォームチーム」というチームが作っていく開発者がセルフサービスで利用できる基盤です。

いろんなツールを組み合わせる形で構成されていて、あんまり抽象化しすぎることなく、開発者の認知負荷を軽減していく、といったものです。

この辺りの考え方、つまりチームを分割してプラットフォームチームに切り分けて、そこでX-as-a-Serviceみたいな形で連係していくのは2～3年前から話題になっている「Team Topologies」（書籍：チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計）の考え方も影響が大きいのかなと思っています。

Team Topologiesは、価値のあるソフトウェアを素早く届けるようにしていくための組織設計の考え方を示しています。

そこでは4つのタイプのチーム「ストリームアラインドチーム」「イネイブリングチーム」「コンプリケイテッド・サブシステムチーム」「プラットフォームチーム」があって、チーム間の連携としては3つ、「ファシリテート」「コラボレーション」そして「X-as-a-Service」があります。

Platform Engineeringは、ストリームアラインドチームに対してプラットフォームチームがX-as-a-Serviceで関与する、というパターンが近いのかなと思いつつ、実際のところはもう少し複雑だったりするかもしれません。

≫後編に続きます。後編では、「Platform as a Product」という考え方について紹介します。