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

そんなエラい方々が、こんな場末の Qiita 記事なんて読むのかなあ。まあいいや。
なお、標題からお察しの通り、例のごとく、何かしらの技術を学ぶための記事ではございませんので、何とぞご了承くださいませ。

特に誰向けの話か

この件に関しては、 Platform Engineering に関わる皆さん全員が悩む必要はないと思うのです。すでに成功の途上にある Platform Team の方々は、今進んでいる道を迷わず惑わず突き進んでいただきたい。

成功への道筋が見えない。あるいはそもそも、そういった道があるのかどうかすら知らない。

そういった状況に置かれている、例えば以下のような方々を、主なオーディエンスとして想定しています。

内製、外注を問わず、多くのアプリケーションエンジニアを抱えて自社の製品やサービスを提供している、もしくはしようとしている、中〜大規模な企業・団体の方

メンバー数が10人に満たないような小規模な企業・団体、もしくは、Platform に載せたいアプリが数えるほどしかないような企業・団体においては、大々的に Platform Engineering に取り組む必要はないと思います。
Platform Team を立ち上げてアプリ開発チームと役割を分担させようとしたところで、そもそも Platform Team の人数が揃えられなかったりするのではないでしょうか。むしろ、 Platform Engineering の知見をもった方が、アプリ開発チームの中に入って業務を進めた方が、効率がよかったりするだろうと思うからです。

経営層から Platform Champion に任命されている方、もしくは将来そのポジションに就くことを予定もしくは希望している方

そもそも Platform Champion って何？と思われた方は、こちらの記事をご一読いただければと思います。

社内、特に経営層から、 Platform Engineering を実現したいのでよろしくと無茶振りされているが、特に人材の面でどうしたらいいのか途方に暮れている方

こちらは、 Platform Champion ご自身以外に、そのような上司の方に指示された部課長クラスの方々も含まれると思います。

この話を読むにあたっての前提条件

この記事の標題を見て「よし、その答えがはっきり書いてあるんだな。とっとと結論を出せ」などと思った方もおられるかもしれません。
残念。世の中そんなに甘くはありません。赤の他人に答えを求める前に、以下に示す3つの条件全てに当てはまっているかどうか、まずはご自分の立ち位置をしっかり確認されることを強くオススメいたします。

Platform Engineering とは何かということは、少なくとも何となくは理解した

まだの方は、これまでに開かれた Platform Engineering Meetup の各発表を、ひと通りご覧いただくのがよろしいかと思います。YouTubeチャンネルもありますよ。

自社に Platform Engineering を導入する必要性を、少なくとも何となくは感じている

むしろ、ウチには要りそうにないなあ、などと少しでもお考えならば、この記事を引き続きお読みになることはオススメいたしません。
Platform Team の立ち上げや持続的な運営は、そんな生易しいものではないと思うからです。

自社に Platform Champion と呼べそうな方がすでに存在している、もしくは近いうちに出現しそうな雰囲気がある

この記事を読んで、へー、と思うだけでは、毒にも薬にもなりません。あなたは実行に移さないといけないのです。
それなりのコストをかけて Platform Team に連れてきたい人を見つけ、人事権や購買力を行使して実際に連れてくるということが実行可能な状況になっているかどうか、そのカギは Platform Champion の存在如何にかかっていると思います。

そこまでオーディエンスを限定して大丈夫なのか。誰も読めないことになるんじゃないのか

はい、おっしゃる通りです。
だから、ほら、この記事のタグに「ポエム」って入れてあるでしょ？

こんな場末の Qiita 記事を鵜呑みにしていただきたくないのです。飽くまでも数多ある Platform Engineering 関連記事のうちの一つとして、ご自分の頭で考えていただく参考になればいいかな、いや、こりゃ参考にならないんじゃかな、そんな程度の駄文なのです。
玉石混交の Qiita にひっそりと佇むそこらへんの石、 Qiita の貴重なサーバリソースを食い潰すだけのゴミデータ、広大なインターネットの片隅に漂う小さなデブリ、と言っても過言ではないのかもしれません。

それでもよろしければ、引き続き読み進めてくださいませ。

ここで言う Platform とは

アプリの日々の開発と運用を支えるもの、それが Platform である、という定義でお話を進めます。アプリはアプリチームが Platform を活用しながら開発と運用を行い、 Platform は Platform Team が日々開発と運用を担います。
拙記事「Platform Team と社内政治〜出でよ、Platform Champion 〜」にて示した以下の図のイメージで捉えていただければよろしいかと思います。

Platform Team における3つのロール

私が所属している(いた？) VMware Tanzu Labs においては、Balanced Teams というプラクティスを提唱しています。
下の絵に示すように、アプリ開発チームは、 Product Owner のもとに Product Manager / Product Designer / Engineer の3つのロールのいずれかを担当するメンバーから編成しようと言っています。
一方、 Platform Team は、 Platform Champion のもとに Product Manager / Engineer の2つのロールのいずれかを担当するメンバーから編成します。

Platform Engineer

Platform Team における主役ともいうべきエンジニアたちです。
Platform の設計、構築、機能の維持や拡充のための開発、導入する製品や運用手法の模索と選定、アプリ開発チームの実用に堪えうる Platform の運用に加え、Platform の使い方に関するドキュメンテーションや社内に対する技術的な説明、社内からの技術的な問い合わせや要求に対する対応などを本来業務として担います。

如何にしてこのエンジニアたちに、本来業務に集中してもらい、最高のパフォーマンスを発揮してもらうことで、Platform の維持・改善とあらゆるアプリ開発チームへの普及、更には全社の生産性向上に結びつけるのかが、 Platform Team のチームビルディングにおける大きな課題となるわけです。

Platform Champion

Platform Engineering の実現にあたっては、導入する製品や運用手法の模索と選定も重要ですが、それと同等あるいはそれ以上に、Platform Engineer たちが触れたくもない、社内政治的な課題の解決が欠かせません。そういうややこしい課題をカバーし、 Platform Team が Platform の安定運営や機能改善に集中して取り組めるようにするために必要な存在です。

Platform Champion のあるべき姿については、拙記事「Platform Team と社内政治〜出でよ、Platform Champion 〜」をご一読いただくなり、Platform Engineering Meetup #2 における不肖私のプレゼンをご覧いただくなりしていただくのがよろしいかと思います。

Product Manager

Product としての Platform (Platform as a Product) の権化として、社内に Platform と Platform Team の存在を象徴し、Platform Team におけるチーム内外のコミュニケーションの主軸を担う、 Platform Team には欠かさざるべき方です。

Platform Team は技術を担当するのだから、エンジニアだけの集団としておけばよいのだ、などとお考えのそこのあなた。 Platform Engineer が純粋に技術だけ追い求めればよいのなら、彼らは専ら自分たちだけの都合で謎の技術開発を進め、何にも役に立たないモノを Platform だと称して成果を主張する無能の集団と化してしまいますが、それでよろしいのでしょうか。
あるいは、 Project Manager ってのがタスク管理だの予実管理だのをやってくれて、納期までにきっちり構築完了するように管理してくれるから、あえて Product Manager などというロールは要らないのだ、などとお考えのそこのあなた。「Platform Engineering とは何かということは、少なくとも何となくは理解した」んじゃないんですか。Platform の構築と運営は、中長期的、継続的に改善され提供されるべき Product と捉えて管理するべきであり、時限的な Project と捉えるべきではない、って口を酸っぱくして言ってるでしょうに。

顧客が社内のアプリ開発チームであるからこそ、さらに経営層を始め社内の数多のステークホルダと関わるからこそ、Platform Team のコミュニケーション負荷というのは Platform Engineer たちの本来業務を圧迫しがちです。
口下手なエンジニアたちをコミュニケーション負荷軽減の面で強力にサポートしてほしい。そして、エンジニアたちが真にビジネスに貢献する Platform を提供し続ける道筋を照らしてほしい。Product Manager が Platform Team に欠かせないのは、そんな切なる願いがあるからこそなのです。

Platform Team における Product Manager のあり方については、Platform Engineering Meetup #5 において Saho さんに素晴らしいプレゼンをもって語っていただきましたので、是非ご覧ください。

その他のロール

Platform Team に入れるべきかどうか悩ましい感じのロールについて、4つほど挙げて論じてみたいと思います。

Product Designer

上の絵に示した2つのチームを見比べて、誰もが疑問に思いますよね。
あれ？ Platform Team には Product Designer はいないんだねえ。

Platform Team に Product Designer は必要なのか。

Platform as a Product を標榜している以上、Platform は Product であり、Product には Design すなわち設計というものが必要です。
さらに言えば、アプリ開発における User Experience すなわち Developer Experience を、この会社ではどう提供していくべきか、仮説を立てて実装し、実際に提供してみてフィードバックを得ることで検証を進めるのは、Platform Team においてもアプリ開発チームと同じような進め方となるはずです。

とは言え、そもそもこのアプリはどういう顧客を想定し、どういう価値をアプリとして届けるべきか、ゼロから考え始めなければならないアプリ開発チームにおける Product Design とは異なり、Platform の顧客と提供すべき価値は、Platform の構築開始の時点までには概ね固まっているはずです。その点で、すでに構築され運営が開始された Platform においては、その Platform の存在理由が大きく揺らがない限り、Product Designer の出番はあまり求められない可能性が高いと思います。
（※個人の意見です）

Agile Coach, Scrum Master

Platform Team においてもアジャイル開発やスクラム開発の手法を導入し、漸進的にプラットフォームを維持改善していくことは、正しい戦略であると言えます。
そのような手法についてのノウハウや知見が Platform Team にない場合は、数週間から一年程度に期間を区切って Agile Coach や Scrum Master を迎え入れ、チーム全体で手法を確立するというやり方も考えうると思います。

ただし、Agile Coach や Scrum Master を Platform Team に恒久的に所属させる必要性は薄いように思います。チームの文化としてそういった手法が定着してしまえば、そのような方々の助けなしで自律的にチーム運営が進むのではないでしょうか。
例外として、Platform Team が、Platform の使い方をアプリチームに伝授する活動を行う傍で、アジャイル開発やスクラム開発の手法導入を支援する任務も負うような場合は、その限りではないのかもしれません。

People Manager

人選の立案や人事評価に関与する People Manager を Platform Team のメンバとするのは、正しいのかどうか。

Platform Team に限らず、アジャイル開発手法を導入したチームの一般論について、最近発見した記事に、はっきりと「基本的には悪手なので避けたほうがいい」などと書いてありますが、私も概ね同感です。
日々のタスク管理などはチーム全体として自律的に行えるようになるべきですし、人事評価というパワーを持つ人がチームの内部に居る状況でチームメンバー間の心理的安全性というかバランスを保ち続けるのは少し難しいと言えそうです。

Platform Team が日々楽しく仕事を進めてゆくことを外側からそっと見守っていただきながら、ときどき 1 on 1 などで各チームメンバの状況を把握しつつ、ときには容赦なく人選を見直す、といった動き方をしていただくのがよろしいのではないかと思います。

Assistant

機能開発やシステム運用などといった Platform Team としての本来業務ではない業務領域を、 Platform Team メンバーからのリクエストに応じてサポートしていただくような方を指しています。
そういった秘書的あるいは庶務的な役割をもつ方がチーム内にいることは、他のチームメンバとしてとても助かることは事実ですが、Platform Team に専任で配置のは贅沢すぎると思います。
後に改めて言及したいと思いますが、一つの Platform Team のメンバー数は 10 名に満たないことを想定しています。従って、別の業務チームも併せた複数チームを担当する形で配置することでよいのではないかと思います。

あるいは、秘書的あるいは庶務的な役割をもつ方々のみからなる専門チーム（いわゆる庶務課的なやつ）を立ち上げ、他チームからのリクエストをチームとして引き受ける形が、よりモダンな感じがいたします。もはや Platform Engineering ではなく、チームトポロジーの議論の範疇かもしれないですが。

おっと、ここでお時間が参ったようでございます

ここまでで案外長文となってしまいました。
この後のお話は【後編】として、日を改めて続けたいと思います。

後編の内容は以下を考えています。

Platform Engineer の探し方
Product Manager の探し方
理想的な Platform Team の規模と体制
1つの Platform Team に与える役割

それはまた次回の講釈で