Platform Engineeringとチームトポロジー
──組織の話をふまえ、ぜひチームトポロジーとの関係についてお聞かせください。中島さんの発表でも、チームトポロジーにおけるチーム間の連携方法（インタラクションモード）として「コラボレーション」の形態から始めたことは戦略として正しかったという話が印象的でした。こう判断した経緯や想いなどを教えてください。
中島：「コラボレーション」は狙ってやったことではないのですが、振り返るとそのような動き方をしたからこそ今があると思っています。なぜコラボレーションが良かったかについては、プラットフォームにとってプロダクトマインドがすごく大事だと思うからです。
開発者がどういうものを欲しているのか考え、求められているものをちゃんと作ることが、プラットフォームでは重要です。世の中には、さまざまなプロダクトマネジメント、課題発見、仮説検証などのさまざまなメソッドがありますが、一緒に働いて何に困っているのかを実感するのが一番早いと思っています。
最初から、プラットフォームと開発者で、役割に応じた別々のことをやっていこう、と言ってしまうよりは、例えば「マイクロサービスのマイグレーションを一緒にやりましょう」と、一緒に取り組むのです。一緒に取り組むことで、開発者が何が一番辛いのか、どこを直せばいいのかが、プラットフォームのエンジニアもすぐに分かるし、開発者にとってもプラットフォームのエンジニアが近いところにいるからこそ「ここが困っているよ」とすぐに言いやすくなる。コラボレーションしながら働くことによって、本当に必要とされているものを作るということが、スピード感を持ってできたことがあるかなと思います。
これは組織が大きくなった今でも重要だと感じています。プラットフォームにもたくさんのチームができると、プロダクトチームとはある程度の距離ができてしまいます。そうなると、今度はプロダクトチームが今、何に困っているのかっていうのを吸い出しにくくなってくるんですよ。だからこそ、僕らはその課題をメインで抱えているチームと一緒に、プロジェクトを立ち上げて課題を解決しようとします。例えば、そこで局所的にコラボレーションして新しく何かツール作っていく、というのは今でもやりつつあります。課題を吸い出すって意味ではこの形が一番うまくいきます。
あと、マイグレーションの観点でも、コラボレーションの形で動くと、プロダクトチームが、新しいツールやプロセスに最初に移行してくれるので、プラットフォームとしても実績ができることから他に展開をするにも動きやすくなります。そういう意味でも、立ち上げからある程度大きくなってからも、コラボレーションは重要です。
──x-as-a-serviceの形態に成長したとしても、プラットフォームを使う開発者が何に悩んでいるのか、一緒に働く過程で得ていくことが重要ということですね。目的は、みんなが何が欲しいかを見極めることで、ある意味営業の基本のようで泥臭い部分ではありますが、そこをしっかりやることにコラボレーションの真髄があるのだと思いました。
中島：そうですね。だから、プラットフォームエンジニアは最初は一緒に働いていたとしても、いずれここから抜けていくんだ、という気持ちは大事ですね。
草間：そのあたりのプラットフォームチームと開発者の、近すぎず遠すぎずなバランス感覚が必要になってくるように思いました。そのあたりの判断はご自身がされているんですか？ それとも他の方が判断されるのでしょうか？
中島：初期は僕がやっていましたが、最近はそれぞれのチームで判断しています。今となっては、Platform Engineeringが独立した組織として立ち上げられているので、プロダクトのチームから戻ってこれないようなことは起きにくくなっていると思います。初期はしっかり整っていたわけではないので、厳密に「ここまでやったら抜けます」と決めていたと思います。一番分かりやすいところで言うと、「サービスのオンコールに絶対に入りません」と決めていました。オンコールに入っちゃうと抜けられなくなるので（笑）。
草間：なるほど、よく分かります（笑）。
──ここを少し掘り下げると、プラットフォームチームの役割をどう明らかにしていったのでしょうか。例えばオンコールのような運用体制もそうですし、アプリ開発側からこういうものをプラットフォームとして作ってほしいという要望があったときに、どこまで対応するかはどの会社でもある悩ましいところだと思います。
中島：これは難しい問題ですね。本当はもっと深く入り込んで解決していきたかった。例えばメルカリだとGoをメインに使っているのでGoのためのフレームワークを作っていきたいという想いはあったのですが、正直サービスによってニーズが違いすぎてあんまり踏み込めなかったんですよ。
今でもそれは課題で、解決しようとしてはいるのですが、プラットフォームチームの初期の段階では、そこまで踏み込めずアプリケーションの実装の抽象化には手を入れていません。テンプレートプロジェクトだけ用意して、あとはそれを参考に開発したり、カスタマイズしてもらったりするようなことまでしかやれなかったところはありますね。
逆にうまくいった例で言うと、メルカリのマイクロサービスがある程度進んだ後にメルペイの立ち上げが始まり、プラットフォームチームが入っていってコラボレーションしながら動くフェーズがありましたが、メルペイはメルカリと比べてセキュリティ要件が高いので、それに合わせて基盤のセキュリティを強化していくという話になりました。メルペイのために必要な高いセキュリティ要件は、メルカリも同様に必要だよねということで、メルカリとして共通化できたといううまくいった例もあります。
──新規サービスの固有のニーズだと考えずに、これは汎用的なものだと判断できたのであれば、思い切って取り込むということですね。例えばWindowsにない機能がフリーソフトで出ていたものが、Windowsの次のバージョンでは標準になっているような。
中島：そうですね。作ろうとしている機能は全体にも意味があるようであれば、それはプラットフォーム全体向けの機能として作っていますね。プラットフォーム外でとあるツールが作られていて、このツールはみんなが使えるものだから、プラットフォームの機能として提供しようと、プラットフォームチームでメンテナンスするようになった話は、ちょくちょくあります。
後半では、メルカリがPlatform as a Serviceをどのレベルで体現できているかといったことや、Platform Engineeringの今後への期待といった話題でお話が続きます。インタビュー後半もぜひお楽しみに。
