外部プラットフォームと内部プラットフォーム: そのリスクと方針
ある程度組織が大きくなってくると、プラットフォームの必要性が叫ばれます。一方で、プラットフォームに関わったことがある人は少ないようです。
プラットフォームエンジニアリングは本当に必要なのでしょうか？
この記事ではプラットフォームで混同されがちな概念を説明し、(内部)プラットフォーム作成のヒントを解説します。
- 外部プラットフォームとは
- 内部プラットフォームとは
- 内部プラットフォームの典型例
- プラットフォームのリスク
- 必要なのか？
- 立ち上げ方針
まずは混同されがちな外部プラットフォームと内部プラットフォームの違いからです。
外部プラットフォーム a.k.a プラットフォームビジネス
外部プラットフォームとはビジネス的なプラットフォームを指します。
Amazon.co.jpで探せるプラットフォームが題名にある書籍のほとんど、プラットフォームビジネスで出てくるほうです。エンジニア以外がプラットフォームと発話したらこれです。プラットフォームを提供する主体はプラットフォーマーと呼ばれます。よく外部にAPIを提供していますね。
プラットフォームを作ったときには想像もしていなかったようなことを、プラットフォームユーザーが生み出すことができます。新たなビジネスが生まれ、エコシステムができるかもしれません。
Amazon社のプラットフォームが有名です。フライホイールの図は見たことある人も多いでしょう。
プロフィットセンターであり、組織としては限界まで投資可能です。
ユーザーは組織外がほとんどです。顧客や協業先が代表的。
積極的に使ってもらうことに価値があり、そのためDevExやDevRelが効果的です。
ここのゲームプレイに関しては別稿に譲ります。
内部プラットフォーム≒プラットフォームエンジニアリング
いわゆる共通基盤です。組織内部のサービスを共通化することで無駄を省きます。内部のQCD改善が目標です。
コストセンターであり、どこまで投資するか難しい判断が求められます。(無駄をなくす目的なのにあまりにも多くの人員を割いたら本末転倒です。)
ユーザーはほぼ内部顧客です。組織内の別のサービスであることが多いでしょう。
Team Topologyのplatform team が扱うものです。DevExは欲しいところですが、現実的にはそこまで工数をかけられないでしょう。内部限定でありハイコンテキストを前提とすれば、完全なドキュメント等がなくても組織内でカバーできます。
内部プラットフォームの典型例
認証認可基盤 ユーザー基盤 決済基盤 ログ基盤 測定基盤などが代表的です。
開発生産性(development productivity)向上系のものもあります。CI/CD、IaCなど。
内部プラットフォームのリスク
「同じものが2つ以上あると非効率だから共通化しよう！」「今後必要になりそうだから共通化できそうなところを切り出しておこう！」
その通りなのですが、なかなかそううまくはいかない現実があります。
単一障害点になる
プロダクトAとプロダクトBが同期リクエスト形式で依存するプロダクトPがあるとして、プロダクトPが障害になったら全部障害です。
プロダクトAに高信頼性が求められるなら、プロダクトPはそれを遥かに上回る信頼性が必要です。
複雑化する
共通部分を切り出したら見落としがよくなるように見えます。
しかし、長く時間経つとプラットフォーム側が複雑になり、見通しが悪化することがよくあります。特にビジネス優先（クライアント優先）だとプラットフォーム側にロジックを寄せることがありがちです。
改修速度が落ちる
その領域に特化したチームを用意したのだから開発速度が上がりそうですが、悪化することはよくあります。
何につけても多数の影響範囲を確認しながら作業する必要があるからです。影響範囲が存在するならクライアント側それぞれの事情を加味して調整が必要です。特にクライアント側の対応が発生するときが一大プロジェクトになります。
純粋に開発速度で負けることもあります。ゴールデンイメージとしてAWSなどをラップしたものを作ったものの、その改善速度についていけないといったことです。大手プロバイダーとはその部分にアサインできる人数に差がありますね。IaCの社内共通モジュールが化石化しがちです。
外部の基盤に不足している機能を補うべくOSSや社内ツールが生まれ、外部基盤側が新バージョンでその機能を追加したので不要になるが、そのツールに依存してしまい乗り換えできず、新バージョンが使えなくなり非効率となるというサイクルを歴史的に見てここ数十年繰り返していますね。なにもしなかったらいつも最新バージョンが使えるので悲しいことです。
そしてソフトウエア開発において速度の悪化はコストや品質の悪化を招く要因の一つです。
優先順位がつけられない。不満がたまる
さまざまなクライアントからの改修要望についても優先順位をつけるのも大変で、優先順位を調整する作業だけでも工数が多くかかります。
優先順位をつけるメカニズム例として、話し合い方式、トークン方式、HiPPO方式、先着順、声が大きい人優先などがあります。
どうしてもクライアントのチームとは優先順位が異なるためプラットフォームに対する不満は増える一方です。
改修スケジュールが見えないので、結局クライアント側でその機能を作り、それが二重三重にもなることも。
(その機能要望ですか？最速で3年後に着手開始です)
共有地の悲劇
n+1や重いクエリのような非効率なプラットフォームを呼び出す処理があったとしても、各クライアントには改修する動機があまりありません。自分のチーム内なら確認するでしょうが、他チームはそもそも影響が見えないし見方もわからないでしょう。
そしてプラットフォームが障害になり、そのまま全プロダクトが大障害になることも。
プラットフォーム内はお互いに無関係
プラットフォーム内の各サービスについて、「共通」という部分は共通点がありますが、扱っているドメインはバラバラです。
会社組織をバックオフィスでくくったとして法務と税務、HRやファイナンスはやることが違いすぎるでしょう。分類するときに「その他」になんでもかんでも放り投げているイメージです。
特にプラットフォーム部門で組織目標や方針を立てるときに影響します。
需要がない
新プロジェクトで必要な機能について、共通基盤側で作ると効率的に見えます。今後他のチームでも使うかもしれないですよね。
しかし、新プロジェクトが消滅したり、優先順位が変わることでその基盤部分が不要になることは時折あります。手を付けていれば残念ながら貴重な工数と特に時間を無駄にしたことになります。仮に1年延期だとしても一手無駄にしていますね。特にスタートアップだと厳しい状況に。
需要があるという仮説が検証されないまま作ってしまったプロダクトです。使う予定や使いたいという言葉と、実際に使っている状態では天と地ほどの差があります。
QCDが悪化
QCDを改善するはずが、長年経つとむしろQuality Cost Deliveryが悪化しているように外から見えます。遅い高いおいしくない状態です。
内部プラットフォームは必要なのか？
プラットフォームの存在意義で致命的なところは共通部分ということです。組織内部のサービスで共通ということは、組織の外部でも共通であり、トレンドを見渡せばコモディティ化が進みます。陳腐化済みのものを開発するメリットはありません。
特化した外部SaaSなら同じ領域でもプロフィットセンターとなり、プロダクトマネジメント、デザイン、DevExに投資できます。プロダクト品質にも差が出ます。
エンジニアの立場からすると、内部プラットフォームはすでに世の中にあるものを作るだけなので面白みに欠けることがあります。例えば決済に関心があれば決済のSaaSにいったほうが面白い問題に取り組めます。もしくは自分たちで新しくプロダクトを立ち上げるか。(そういうスタートアップもよく見かけます)
ただ、現在、プラットフォームを代替できるようなSaaSはコスト面で不利です。ユーザー数や利用量課金のため、最終的に自分たちで作成したほうが人件費を加味しても安くなる傾向にあります。
また、同様の機能が多数存在すると、セキュリティ、コンプライアンス面で効率が悪くリスクが高くなることは否めません。デザイン/UX面でも強い一貫性を保ちたいところです。
組織の規模がハイパースケーラーレベルなら外部SaaSより難しい問題にエンジニアが取り組めるかもしれません。残念ながら日本企業でそのレベルに到達できた企業は厳し目に見て存在しません。
もちろん適切に作成できた基盤は使い回しが容易でプロダクト立ち上げがスムーズになります。Meta社のThreadsが約5ヶ月でローンチしながら、高いスケーラビリティやセキュリティ、品質を担保できたことはプラットフォームがあるからこそです。
プラットフォームの立ち上げ方針
既存の主プロダクトからサービスを抽出し分離する
主プロダクトから抽出すれば、その部分は需要があることが既に証明されています。主プロダクトは肥大化しがちなので分離できるとお互いにメリットがあります。
人を集める
エンジニアリング難易度は高く、組織内で最高のアクセス量や高信頼性が求められます。そのような分野に関心がある方を募集しましょう。プラットフォームは関係者が多く調整も難しいですが、それを逆手に取って難易度が高いことを歓迎する人材がよいですね。
なるべくプロダクトとして扱う
せっかく作っても使われなかったら意味がありません。乗り換えのメリットを打ち出していきましょう。
通常のプロダクト同様、プロダクトマネジメントとして内部のドキュメント、デリバリ、マーケティング、ヒアリング、UX(DevEx)改善をしていきましょう。測定も忘れずに。工数は限られていますがここにも投資しましょう。
コピーアンドペーストの勝利(?)
内部でレジストリを作成してバージョン管理してコンポーネントを再利用できるようにする…というのは理想ですが、現実はクライアントはバージョンアップしませんしバージョン上げるとおかしくなるでしょう。(言語やフレームワークを常に最新化できている組織なら心配ありません。)
ライブラリやIaC周りはサンプルだけ提供して真似してもらうほうがよいです。個別に進化してもらい、フィードバックをもらい反映しましょう。
shadcnのようなイメージ。
本当に内部の需要が多いことが証明されたらコンポーネント化し、サービス化を狙っていくのもよいですね。
障害時の動作を検討する
中央集権型だと障害時に全滅するため、レプリケーションによる分散という方法もあります。一方、データ同期やstale cacheといった難しい問題が生まれます。
なるべくイベント型で非同期にしたほうが障害に強いものの、データ復旧といった部分には違った難しさがあります。
Everything fails
ということで分散システムでは必ず部分が壊れるため対応を検討しましょう。
リソース不足で要求に答えれないときは要求元からのレンタルを検討する
要求元が人員を貸し出し、要求先の一員として同じ基盤上に同じ開発スタイル、開発スタックで作成するとスムーズに進みます。
(Away Team)
https://pedrodelgallego.github.io/blog/amazon/operating-model/away-team-model/
Limitation
この記事ではPlatform Engineering自体は説明していません。チーム組成やKPIの難しさはプロダクトとはまた別にあります。
Conclusion
組織によってはエンジニアの数十パーセントがプラットフォームが占めることがあります。プラットフォーム自体が負債になりえるのでうまく計画しましょう。
