この記事は、Platform Engineering Advent Calendar 2023 の16日目のエントリーとして、昨今話題となっている Platform Engineering を自社において実現したいとお考えの、企業・団体ではそれなりの地位におられる方々が、 Platform Engineering を実践する Platform Team をどのように立ち上げたらいいのかなあ、と迷われたときの一助となることを企図するものであり、【前編】に引き続くものです。

【前編】の振り返り

前編では、概ね以下のことについて論じたつもりです。

この記事が役に立ちそうな方々は、マジ限られていると思う。っていうか、ポエムだし
アプリの日々の開発と運用を支えるもの、それを指して Platform と呼ぶこととして論じる
Platform Team に欠かせないロール(役割)として Platform Champion、 Platform Engineer、そして Product Manager の3つがある
他にも想定可能なロールがいくつかあるが、まああんまし考えなくていいんじゃないの

・・・薄っ！

というわけで、後編もはりきってまいりましょう。

Platform Team を立ち上げるということ

Platform Team の立ち上げにあたっては、 Platform にどんな製品を使うべきかという「モノ」の面、 Platform にどれくらいのコストをかけるべきかという「カネ」の面、これらはもちろん重要な準備項目となります。そして何よりも悩ましいのが、Platform Team にどういう人を連れてくるべきかという「ヒト」の面ではないでしょうか。
前編において、 Platform Engineer と Product Manager がどういう役回りを演じるのかを縷々説明しました。それぞれのロールに期待される役割は異なりますので、どういう人にそれぞれの役割を担ってもらうか、その人選のあり方は自ずと異なってくるのではないかと思います。

Platform Engineer の探し方

↑単なる挿絵です。本稿との内容とは関係ございません

前述の通り、Platform Team における主役ともいうべきエンジニアたちなわけですが、アプリ開発を行うエンジニアとは異なる技術領域のスキルやノウハウが求められる一方で、日々著しく進化する技術動向に追従し、昨今の目まぐるしく変化するビジネス環境に立ち向かうことも求められる、思わず「そんなヤツいねえよ！」とでも言いたくなるロールです。

正直な話、最初からいっぱしの Platform Engineer を担えるような即戦力人材は、社内から見つけ出すのはおそらく困難だと思いますし、新たに雇うにはかなりの厚遇が求められることを覚悟すべきとも思います。

ではどうするか。

基本は、社内の既存のエンジニアリングチーム、すなわち、アプリ開発チームやITインフラチーム、CCoE(Cloud Center of Excellence) チームなどから、それぞれの専門性をもったエンジニアを招き、そしてじっくりと時間（と、おカネ）をかけつつ、エンジニア個人としてというより Platform Team として育てる、という戦略が妥当だろうと思います。

例えば、Platform として「全社共通のCI環境を、社内クラウド上で提供する」というマイルストーンをまず目指すのだとすれば、アプリのテストやビルドのあり方に精通したアプリ開発チームのエンジニアと、社内クラウドの運用と提供のあり方に精通したITインフラチームのエンジニアを、まずは Platform Team に招くべきだろう、ということです。
あるいは例えば、Platform として「バーストトラフィックに堪えられる全社共通の映像コンテンツ配信基盤を、パブリッククラウド上で提供する」というマイルストーンをまず目指すのだとすれば、映像コンテンツのエンコーディングに精通した制作チームのエンジニアと、パブリッククラウドにおけるCDNの活用やストレージのあり方に精通したCCoEチームのエンジニアを、まずは Platform Team に招くべきだろう、ということです。

そうは言っても、社内にいい人材が見つからない、あるいは、見つかったけど今の仕事が忙しくて引き剥がせない、というようなケースは多々あるでしょう。それでも、Platform Team を早期に立ち上げたい、そのような場合にはやむを得ず外注先からエンジニアを招くことも選択肢に入ってくると思います。ただ、これはあくまでも次善の策として考えるべきでしょう。最近目にしたこの記事にて様々なデメリットが挙げられています。特に 外部から参画しているメンバーは必ずしもプロダクトの成功に対するインセンティブがない というデメリットが非常に痛いところです。社内の有為な人物を探し続ける努力は怠らない必要があると思います。

なお、新人のエンジニアを Platform Team 立ち上げ時に連れてくるのは、個人的には避けたほうがよいと思います。むしろ、既存のエンジニアリングチームにおいて、いずれかの技術領域の専門性を身に付けてもらうことを優先したほうがよいのではないでしょうか。Platform Team が成熟し、エンジニアの育成にも力を割けるくらいの余裕が生まれればその限りではありませんが、Platform Team に余裕があるという状況は相当レアだとも思います。

Product Manager の探し方

↑単なる挿絵です。本稿との内容とは関係ございません

前編において、「Product としての Platform (Platform as a Product) の権化として、社内に Platform と Platform Team の存在を象徴し、Platform Team におけるチーム内外のコミュニケーションの主軸を担う」のが Product Manager であると紹介しました。
この役割を Platform Team 発足当初から完璧にこなせる人物なんて、いるはずはないと思います。Platform Team の成熟は、すなわち Product Manager の成長であると言っても過言ではないのではないでしょうか。

Product Manager として迎え入れるべき人物としての資質としては、以下の3つが挙げられると思います。

仕事を進めるにあたってのコミュニケーションの重要性や難しさを理解し、工夫しようとしている
新しい技術や仕事の進め方に強い関心と興味を持って学び続け、自社のビジネスに役立てようとする姿勢、情熱を持っている
Platform Champion が抱える問題意識や事業戦略に賛成し、実現しようとする意欲を持っている

技術的なスキルやノウハウ、社会人としての経験の多さは、もちろん持っているに越したことはありませんが、Product Manager として迎え入れるための条件としてはあまり重要ではないと思います。むしろ、上に挙げたような資質は、比較的若手の方のほうが持っている可能性が高いかもしれません。
People Manager のようにチームの他メンバーを査定するような立場ではなく、エンジニアたちと対等な立場で役割に徹しますので、年齢のギャップがあまりないほうが好ましいと言えます。

ただ一点、重要だと思うのが、Product Manager を外注先など社外から迎え入れるべきではなく、社内から選出して Platform Champion の部下とするべきだろうという点です。
前述の通り、経営層を始め社内の数多のステークホルダと関わる Platform Team におけるコミュニケーションの主軸を担うこのロールを社外の人物に任せると、守秘面を気にしてコミュニケーションが円滑に進まなかったり、自社のビジネスを Platform として支えようとするモチベーションが得られにくいなど、デメリットが非常に大きいと言えます。

理想的な Platform Team の規模と体制

よし、どんな人物を Platform Engineer や Product Manager　に据えればよいのかは、まあわかった。
それで、それぞれ何人揃えればいいんだ？

当然の疑問だと思います。
ズバリ、絵で示しましょう。以下の通りです。

Platform Engineer が6名、Product Manager が2名。この8名のチームを暖かく見守る Platform Champion が1名。

なぜこの人数か。Amazonの創業者兼会長であるジェフ・ベゾス氏が提唱した Two-Pizza Team Rule に基づいており、すでに広く知られ実践もされていますが、筆者自身の実感としてもこれくらいのチーム規模が妥当だと思います。これよりも少ないと Platform Team としての業務が回らなくなるでしょうし、これよりも多いとチーム内のコミュニケーション負荷が高まり非効率になるだろうと考えられます。

また、なぜそれぞれ偶数なのか。これは、私が所属している VMware Tanzu Labs (旧Pivotal Labs)が提唱するペアプログラミングのようなペアでの作業が、生産性を大きく高めるためです。Platform Engineer ペア間でメンバーを日々シャッフルすることによって、チーム内でのスキルやノウハウの属人化を防ぐことができるほか、さらに Product Manager ペアと Platform Engineer ペア間でもシャッフルを行うことで、Product Manager が技術知識を高められることも期待できますし、総じてメンバーの急な不在の際にもチームとしての機能を失わずに済みます。

なお、Platform Team 発足当初から上記のような規模でチームメンバーを集めることは、おそらく非常に難しいと思います。

では、どうするか。

【※これよりプロモーションの内容を含みます】
例えば、私が所属している VMware Tanzu Labs が提供するサービスの一つである Platform Development を活用するという手があります。
このサービスの典型的な形態においては、お客様側から Platform Team 立ち上げメンバーとして Product Manager を1名、Platform Engineer を2名選出いただき、VMware Tanzu Labs 側からは、Product Manager を1名、Platform Engineer を2名提供し、最低でも1ヶ月以上の期間 Platform Team を組みます。そして、VMware Tanzu 製品(あるいは他の製品との組み合わせ)を用いた Platform の構築、定着、管理運営を、技術面だけではなく Platform Team の育成と運営の面においても支援します。
VMware Tanzu Labs の期間が終了後は、習得したスキルやノウハウをペア作業を通じて新たに加わったチームメンバに展開し、あるべきチーム規模に拡大していきます。

絵で表すと以下のような感じでしょうか。

1つの Platform Team に与える役割

前編にて Platform Engineer が担う役割として「Platform の設計、構築、機能の維持や拡充のための開発、導入する製品や運用手法の模索と選定、アプリ開発チームの実用に堪えうる Platform の運用に加え、Platform の使い方に関するドキュメンテーションや社内に対する技術的な説明、社内からの技術的な問い合わせや要求に対する対応など」があると書きました。

Platform 自体の規模や機能が増大すると、Platform Team は日々の Platform の運営に忙殺され、新たな改善要望に応えられないような状況に陥る可能性があります。こうなると、Platform が陳腐化して Product としての魅力がなくなり、全社への Platform 展開がままならなくなってしまいます。

Platform Team の業務が逼迫しそうになった場合には、その Platform Team から一部の業務を切り出して別チームに担当させるか、 Platform 自体を機能的に分割して複数の Platform Team が各々の Platform を運営する体制に移行する必要が生じるでしょう。ただし、そもそも全社展開を目指している Platform 自体を機能分割することは、なかなか至難の業だと考えられます。現実的には、前者の「一部の業務を切り出して別チームに担当させる」方針をとらざるを得ないのではないでしょうか。

Platform Team から切り出せそうな業務としては、例えば以下のようなものが挙げられるでしょう。

Platform の使い方に関するドキュメンテーションやハンズオンイベントの開催など Platform の利用普及業務
Platform に新たに導入するべき製品や運用手法の模索と選定を行う Research 業務

いずれも Platform Team とは依然として密接なコミュニケーションが必要な業務ですが、何しろ日々の Platform の運営と改善という Platform Team のコア業務を疎かにしないチーム編成を行うことが肝要だろうと考えられます。

おわりに

いかがだったでしょうか。字ばっかりでつまらないポエムだと思われたかもしれないですね。

しかし、Platform Engineering って、組織運営の三要素「ヒト」「モノ」「カネ」の中で言えば、「ヒト」の問題を解くことがメインなのではないかと、常に感じてきました。
その想いを、このところいろいろあった中でも、吐露することができました。

来年、 Platform Engineering を取り巻く状況は、どのように変わっていくのでしょうか。
各社から「Platform Engineering の諸問題を解決するのは、この製品です！」みたいなリリースが相次ぐのでしょうか。

私は言いたい。

Platform Engineering の諸問題を全て解決する銀の弾丸など、この世に存在しようはないと。

おしまい