Publickeyで公開されていたPlatform Engineering Meetup #1のまとめがとてもよかった。
スライド中でも書かれているように、共通のプラットフォームを作るのがめちゃくちゃ難しいというのは同意。
自分が今年の1月ごろに書いた記事とも若干関連があると思っていて、やはりいい開発組織はプラットフォームという形をうまく扱っているし、その組織構造の結果としてマイクロサービスがアーキテクチャに現れる。
詳細はボカすが、かつて僕が働いていた会社でも当時流行っていたチーム・トポロジーの輪読会を経て、プロダクト開発組織の中でいわゆるプラットフォーム・チームというものが組成されたことがある。これは、当時分割されていた個々のマイクロサービスに対してオーナーシップを割り当てる形でチームを再組成し、既存のバックエンドにある認知不可を低減させようという取り組みを包含していた。いわゆる逆コンウェイの法則の適用にあたるもの。
そのプロダクトでは早期からマイクロサービスがチームとは関係ない軸*1で分割されていて、バックエンドの開発者は機能開発の際に複数の（ある程度複雑な）マイクロサービスを横断的に扱うことが要求されていた。このようなマイクロサービスとチームの不整合性が、開発時の認知的負荷を増やし品質の低下やバグを引き起こしているのではないかという説が議論に上がっており、その解決策としてオーナーシップを個別のチームにアサインしてみようという結論になった。そして、そのチームのことを「プラットフォーム・チーム」と呼んだ。
「プラットフォーム・チーム」はただ単にマイクロサービスごとの機能開発を担うだけではなく、名前の通り生産性向上のためのリファクタリングや改善の取り組みも同時に行なっていたのだが、チームに対して複数のゴールが存在することで優先度の問題が影響を及ぼした。マイクロサービスにおける機能開発とプラットフォームという立場で生産性向上の取り組みを兼務しているため、優先度の競合によりバックエンドがなかなか完成せずフロントエンドの開発を前に進められない状況が以前よりも多く起きるようになったのを覚えている。そもそものマイクロサービス分割軸の都合上、チーム間でのコミュニケーションコストの増加を避けることもできなかった。
当時の僕はチームの組成や結果に対しては妥当なものだと思っていたが、今改めて振り返ってみればこの組織における「プラットフォーム・チーム」は全くプラットフォームとは言えなく、どちらかと言えばバックエンド開発のためのチームでしかない。
反省と言っていいのか分からないが、正しくPlatform Engineeringの文脈でものを考えるならば、また別でマイクロサービスに対して生産性向上を担う抽象度の高いフレームワークや共通の基盤を専門で行うチームのことを「プラットフォーム・チーム」と呼称するべきだったと言える。通常の機能開発とプラットフォームとしての開発をひとつのチームで共存させるべきではない。
あるいは、プラットフォームという名を冠することがそもそも間違いだったのかもしれない。
*1:どちらかといえば技術的な都合によるものだった
