大谷イビサのIT業界物見遊山 第52回

メディア向けの勉強会に呼んでもらったのだが……

プラットフォームエンジニアリングがわからない

　先週、エーピーコミュケーションズによるプラットフォームエンジニアリングについての勉強会に参加したのだが、全然理解できなかった。理解した前提のレポート記事は無理なので、せめて解説のどこで詰まって、なにがわからなかったのかくらいは理解しておきたい。勉強会の模様を追いながら、自身の思考を追いかけていくことにする。

もう5回目となるPlatform Engineering Meetupは現地参加も満員

とにかくグローバルでは注目が集まっているらしい

　勉強会を行なったエーピーコミュニケーションズ（以下、APC）はNeoSIerを標榜するエンジニア集団。2023年1月現在で社員は430名で、AWSやAzureの有資格者が各100名以上在籍している。DockerEnterpriseを買収したミランティスとJVを設立したり、最近話題になったネットワーク機器のカプセルトイ（関連記事：「手のひらネットワーク機器」のサンプル入手！　企画元にも開発秘話を聞いた）を手がけたり、ユニークな取り組みを行なっている会社でもある。今回は同社の取締役兼ACS事業部長の上林大洋氏がプラットフォームエンジニアリングについて記者向けに説明してくれた。

　「プラットフォームエンジニアリング」という用語が登場したのは2022年。調査会社のガートナーが発表した「先進テクノロジーのハイプサイクル」の黎明期に登場し、5年以内に80％の開発組織が利用するということで、話題になった。同時期にこれだけ短期間に導入が進むとみられているのは「OpenTelemetry」や「クラウドサステイナビリティ」くらい。2023年度には「Top Strategic Technology」として適応型AIやメタバースと並んでプラットフォームエンジニアリングが選出されている。

　ここまでだとガートナーが提唱した概念で終わってしまうのだが、2022年には初のカンファレンスである「PlatformCon」が開催され、登壇数は78本、参加者は6000人にのぼり、2023年は登壇数169本、参加者2万2000人に拡大したという。日本でもコミュニティである「Platform Engineering Meetup」が始動し、APCの神田オフィスを会場に、多くのエンジニアが参加したという。とにかくグローバルで注目が集まっているのは間違っていないようだ。

　プラットフォームエンジニアリングとはなんなのか？がわからないまま、なぜ必要かという話に進む。

　もともとプラットフォームエンジニアリングは、開発・運用を手がけるDevOpsチームを拡大する難易度が高いという課題が元になっているという。現在のクラウドネイティブなアプリケーション開発は多かれ少なかれGoogleをモデルとしているが、こうしたメガテック企業であれば、大きな予算を優秀なフルスタックエンジニアを雇用できる。しかし、一般企業ではフルスタックエンジニアを確保するのはなかなか難しい。上林氏によると、「DXで遅れをとっている一般企業こそプラットフォームエンジニアリングは必要だが、むしろテック企業側で採用が相次ぎ、両者の差は広がる一方」だという。

DevOpsチームをスケールさせるのは大変という課題（APC提供）

　続いて勉強会では、ここから経産省のDXレポートについての話、攻めのDXの必要性などが語られる。効率化中心の「守りのIT」から付加価値を生み出す「攻めのIT」が必要だが、中位シナリオでも2030年に45万人という深刻なエンジニア不足がある。そもそも、米国と日本では労働人口、IT人口に絶対的な開きがあり、人材の質も不足している状態。もちろん、IT人材の絶対数を上げるにはリスキリングも有用だが、いわゆる市民開発者がプロ開発者になるためには高いハードルがある。

　こうしたIT人材の量と質を補うのに有効なのが、プラットフォームエンジニアリング。上林氏曰く、プラットフォームエンジニアリングは「既存業務（守りのDX）の人材効率を最大化」しつつ、「新規事業（攻めのDX）に対応可能な組織にシフトする」するという両輪の課題を満たすアプローチだという。

プラットフォームエンジニアリングの鍵は「開発者ポータル」？

　ここまでハードルが上がった段階で、次にようやくプラットフォームエンジニアとはなんなのか？という説明に進む。正直、ここまで長かった。

　ガートナーによるプラットフォームエンジニアリングの定義は、「アプリケーションの配信とアプリケーションの価値を生み出すペースを加速できる新しいテクノロジーのアプローチです。プラットフォームエンジニアリングは、自動化されたインフラストラクチャ運用によるセルフサービス機能を提供することで、開発者のエキスペリエンスと生産性を向上させます。開発者のエキスペリエンスを最適化し、製品チームの顧客価値の提供を加速することが期待できるため、トレンドになっています」となっている（Chrome翻訳）。正直、ふわっとしていてわかりにくいが、「開発者体験を向上させることで、顧客価値を提供する速度の向上が可能になる」ということだ。日本語での説明も出ているので、詳細はこちらをご覧いただきたい。

　従来の開発体制はインフラチームがハブとなり、開発チームの作業を人手で支援していたという。インフラチームがDevOpsツールを扱ったり、インフラを設定・運用したり、ナレッジを蓄積することになる。良くも悪くも、インフラチームのパフォーマンスにより、開発の効率性が決まっていたということだ。

　では、プラットフォームエンジニアリングではどうやって開発者体験を上げ、顧客価値に結びつく価値の提供をスピードアップするのか？　ここで登場するのが「開発者ポータル」というツールとそれを扱う「プラットフォームチーム」になる。発表会では米Spotifyが開発したBackstageというツールが挙げられていたが、この開発者ポータルをハブとして、開発者はセルフサービスでインフラ、ツール、ナレッジを扱う。

プラットフォームエンジニアリングの概要（APC提供）

　これにより、エンジニア一人あたりの効率は上がり、信頼性と回復性のあるリリース速度は向上するという。「成熟すると、一人のプラットフォーム担当で100名の開発者をカバーできると言われています」と上林氏は語る。

料理の鉄人たちのレストランを全国展開する例

　プラットフォームエンジニアリングの概念やメリットの話にようやく行き着いたが、正直いって既存の開発体制となにが違うのかあまり理解できない。そこで上林氏は、「料理の鉄人によるレストランを全国展開する」という例でプラットフォームエンジニアリングについて説明する。ごくり。

　料理の鉄人は言うまでもなく、凄腕料理人によるチームで、鉄人は料理もすごければ、チームの職人たちへの指示も適切。料理道具もすごい。この鉄人のレストランを、とある企業が全国展開しようと考え、まずは鉄人自らが厨房を指示する東京店をオープン。ここでの成功をベースにセントラルキッチンを標準化し、食材調達や下処理などを一括で行なうことにする。また大阪店の鉄人に対しては、東京の鉄人がレシピや器具の使い方、食材の仕入れなどを伝授する。そのため、理屈としては東京店と同じモノが大阪店でも出せるようになるはずだ。ここまではいわゆるDevOpsチームをスケールするという状況をイメージしたのであろう。

　しかし、開店した大阪店は苦戦に陥る。東京店と同じものをセントラルキッチンで用意しているが、そもそも配送に時間がかかる。また、人材不足で、大阪店では経験の浅い職人しか集められなかったため、東京と同じレベルで素材や器具を扱えない。結果として、東京店と同じように料理は仕上がらず、料理自体も大阪の顧客の舌にあわなかった。大阪店の鉄人は大阪向けのメニューを開発し始めるが、新メニューを職人に教えるのも大変で、素材の発注も異なってしまう。セントラルキッチンを従来のインフラチームだと考えると、各店の鉄人にあたる開発者に満足いくインフラ、ツール、ナレッジを与えられていないことが課題だと考えられる。

　ここで作られたのが、いわゆるプラットフォームチームにあたる、新店舗支援チームだ。新店舗支援チームは各店舗のニーズでスキル状況を把握し、食材発注をボタン一つで行なえるようセルフサービス化し、レシピや器具の使い方をマニュアル化した。これにより、鉄人たちのボトルネックが解消し、職人たちもいきいき活躍でき、企業としても成長し、めでたしめでたしというのが上林氏のたとえ話だ。

Platformチームと新店舗支援チームの対比

　勉強会では、このあと北米トヨタやスタートアップでの海外事例、そしてエーピーコミュニケーションズでのプラットフォームエンジニアリングへの取り組み、開発者ポータルのBackstageを手軽に試せる「ちょこっとBackStage」（関連記事：コマンド1つで使える「ちょこっとBackstage」がオープンソースとして公開）が紹介されたのだが、ここでは上林氏が説明してくれたプラットフォームエンジニアリングの話に戻らせてもらう。

現時点ではプラットフォームエンジニアリングは疑問だらけ

　いくつか理解できたことがある。クラウド上での開発では、開発チームの拡大が課題になっているということ。これに対してプラットフォームエンジニアリングは、インフラチームの役割を自動化した開発者ポータルでセルフサービス化することで、開発者の満足度を上げ、顧客の価値を提供するまでのスピードを速くすることができるということだ。プラットフォームエンジニアリングについて説明する記事としては、ここまで読んでもらえば十分だと思う。

　逆に言えば、わかったことはそれくらいだ。ここまで聞くと、プラットフォームエンジニアリングと既存の手法との違いが開発者ポータルくらいしか思いつかない。たとえば、プラットフォームエンジニアリングでは開発者ポータルが万能薬のように思えるが、これは正しいのか？　あるいはJiraやGitHub、既存のCI/CDツールでは、こうした開発者ポータルのような役割は果たせないのだろうか？　その意味では既存のDevOpsやCI/CDなどとの関係も理解できていない。あと、DevOpsチームとインフラチームとやりとりが課題のようだが、実際に現場ではどのような問題が発生しているのだろうか？　

従来のインフラチームとプラットフォームチームの違い（APC提供）

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

　正直、料理の鉄人の例えもピンと来ていない。そもそも一般企業では鉄人のようなフルスタックエンジニアが雇えないという課題が前提でプラットフォームエンジニアリングが提唱されたと理解しているので、たとえ話に鉄人が出てくるのはミスキャストな気がする。セルフサービス化とマニュアル化で各店舗のボトルネックがここまで劇的に解消するのかも疑問。あと、エンジニア不足という課題に対して、質が上がるのか、少ない人数で済むのか、プラットフォームエンジニアリングがどのように作用するのかもわからなかった。

　せっかく説明していただいたエーピーコミュニケーションズや読者には申し訳ないが、レポート記事を書くには今の自分は疑問だらけだ（一応、当日は質問もしたのだが）。「そもそもエンジニアでないので」という言い訳はあるが、自分にとって現時点でのプラットフォームエンジニアリングは理解しがたい。おそらく上林氏も普段エンジニアに話している内容を園児レベルにかみくだいて説明してくれたのだろうが、9年前（2014年）のJAWS DAYSで「Immutable Infrastructure」について初めて聞いたときのポカンぶりを久しぶりに思い出した。

　とはいえ、新しい概念や技術を説明されて、理解に苦しんだら、まず自分の勉強不足を反省し、先達の意見に耳を傾けるのが正しい姿勢だろう。少なくとも自分はそうやってきた。せっかく覚えた言葉なので、いまは各所の記事を読んでいるところだ。
 

大谷イビサ

ASCII.jpのクラウド・IT担当で、TECH.ASCII.jpの編集長。「インターネットASCII」や「アスキーNT」「NETWORK magazine」などの編集を担当し、2011年から現職。「ITだってエンタテインメント」をキーワードに、楽しく、ユーザー目線に立った情報発信を心がけている。2017年からは「ASCII TeamLeaders」を立ち上げ、SaaSの活用と働き方の理想像を追い続けている。