19 Apr 2020

Steve Yegge の Google Platform Rant をもう一度読む

2011 年の文章だけど、今でもかなり示唆深い。

以下は気になったポイントを引用しつつ、行間を読みつつまとめたもの。個人的な解釈も入っているので注意してください。

プロダクトとプラットフォーム

まずシステムを “プロダクト” と “プラットフォーム” に分け、それらが根本的に違うと言っている。

プロダクト	プラットフォーム
特定のセグメントに価値を届けるシステム (垂直統合的) 特定のセグメントに機能を素早く提供できる完璧な要件定義をし、それをリリースするのが理想	機能を組み合わせて利用可能なシステム (水平統合的) より広いセグメントのニーズに答えられる再利用可能な機能郡を準備し、その上にキラーアプリが誕生するのが理想

プロダクトは特定のセグメントに対して価値を届けるシステムで、垂直統合的な作り。

一つのプロダクトで、全ての人にとってふさわしいものを作り上げることはできない

反対にプラットフォームは、再利用可能なサービスを組み合わせることができるシステム。

ともかく、 Bezos が気づいた最初の大きなポイントは、本を売り、出荷し、色々とやる仕組みが、素晴らしいコンピューティングプラットフォームに再利用でき得るということだ。

なぜプラットフォームなのか

プラットフォームはなぜそのような作りで、それがなぜ大事なのか。それはひとつのプロダクトでは対応できない多様なニーズに答えられるため。文中ではそれを「アクセシビリティ」と呼んでいる。狭義には障碍を持つ方への技術的な配慮というイメージだが、ここではより多くのユーザー（マーケティング用語の “セグメント”）のニーズを満たすという意味合いで使っている。

Facebook が成功したのは、彼らがすばらしいプロダクトを作ったからだって言う、まあ実に近視眼的なものの見方の結果として生まれたものだ。でももちろん彼らが成功したのはそんな理由じゃ無い。 Facebook は他の人たちにも何かをさせてあげられる、プロダクトの美しい集合全体を作り上げたから、成功したんだ。

一つのプロダクトは、プラットフォームに比べて相対的にに狭いニーズしか満たせない。仮にすべてのニーズを満たす完璧な仕様のプロダクトがあればよいが、経験則でそれは不可能だと考えられる。

もう一つ、彼が理解した大きなポイントは、常にいつでも正しい、そんなものを作ることはできないということだ。

”ニーズ” とは特定の時点での要求だけでなく、時間の経過によって変わっていくものでもある。そう考えると「すべてのニーズを完璧に予想し提供することは不可能」という主張は納得感がある。

問題なのは、僕らが、人々がほしい物を予測して、それを提供しようとしているということだ。そんなことは出来ないんだよ。現実的にはね。確実にやる方法なんてない。

結局の処、それは愚かさに他ならない。全ての人にとって完璧なプロダクトなんて、無いんだ。

ある時点でのあるセグメントのニーズをよく満たすプロダクトがあったとして、そのセグメントが縮小したり、そのニーズが変化したりした際に、より早く対応できるのはプラットフォームに乗ったプロダクトだ。なぜなら、プラットフォームは機能群を再利用可能な形で提供しているため、開発生産性がより高いはずだから。

プラットフォームが無ければ、プロダクトなんて使い物にならない。いやもっと正確に言うならば、プラットフォームの無いプロダクトは、いずれ同等の機能を持ったプラットフォーム化されたプロダクトに、取って代わられる。

Facebook はより早くユーザーのニーズを捉え成功してきたが、それはプラットフォームの上にプロダクトを作っているからだと書かれている。

Facebook そのもの（つまり、 wall やら friends やらなんやらというデフォルトの機能）が、 Facebook プラットフォームのキラーアプリだ。そして、 Facebook アプリが、 Facebook プラットフォーム無しで成功できると結論づけるのは、深刻な誤りだと僕は思う。

プラットフォームの作り方

良いプラットフォームがあるだけでその事業が成功するわけでは無い。その上に乗るキラーアプリが成功には必要だ。

皮肉にも、 Wave は偉大なプラットフォームだった。冥福を祈りたい。でもプラットフォーム的な何かを作るっていうことは、そのまますなわち成功を意味するって訳じゃあ無い。プラットフォームにはキラーアプリが必要だ。 Facebook そのもの（つまり、 wall やら friends やらなんやらというデフォルトの機能）が、 Facebook プラットフォームのキラーアプリだ。

プラットフォームそのものがキラーアプリになることはない。プラットフォームはその土台となるアクセシビリティを提供するものだ。

僕らはプラットフォームを理解していない。プラットフォームを持っていない。アクセシビリティを理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームがアクセシビリティを解決するからだ。プラットフォームがアクセシビリティなんだよ。

そのためプラットフォームを作るのには相当な覚悟が必要だ。プラットフォームがあるからと言って成功するとも限らないし、短期的な売り上げが増えることもない。長期的なアクセシビリティのための必要条件・先行投資。Amazon でも利益率の低下というプレッシャーの中で舵を切ったという記載がある。

Amazon もまたプロダクト企業だった。だから。 Bezos にプラットフォームの必要性を理解させるのには、外部の力が必要だった。その力ってのはどんどんと蒸発していく利幅だった。彼は追い詰められて、脱出方法を考えなければならなかった。でも彼の持ちえたものは、エンジニア達とコンピュータの群れだった。そこからどうにかマネタイズするには…？。結果論だけれど、そうして彼は AWS にたどり着いたわけだ。

プロダクトとプラットフォームでは、作るにあたって大切にすべき価値観が違うはずだ。そのためプロダクト企業がプラットフォーム戦略へ舵を切るのは非常に難しいと思われる。なぜならプロダクトに機能を足した方がより早く、安全に要件を達成できる。面倒なプラットフォーム化の優先度が上がるはずもない。

僕らを一斉に目覚めさせて、ユニバーサルにサービスを始めるのを期待したりもした。アドホックな、中途半端なやり方じゃなくて、多かれ少なかれ Amazon がやったようにだ。一度に全てを。マジで。偽りなしに。今その瞬間から最優先事項として扱うというように。でも、そうはなっていない。10番やら11番めくらいのプライオリティだね。いや15番かも？。知らないけど、とにかく低い。多くのチームに、彼らのデータと処理に対してプログラマティックにアクセスできるような、ちょっとしたサービスを提供させるのだって大変だ。

プロダクトからプラットフォームへ転換には文化的な改革が必要だと書かれている。またそれは Google でも困難だったようだ（少なくとも当時は）。そのため、プラットフォームに投資すると決め、それにコミットする必要がある。全員がその優先度を理解し取り組む必要がある。

僕らがキャッチアップを始めるには、めざましい文化的な改革が必要だ。僕らは内部的にもサービス指向なプラットフォームを持っていないし、同じように外部的にもそうだ。この「自分のものにしていない」感じは、まさに会社全体を覆う風土病だ。 PM は分かってない。エンジニアも分かってない。プロダクトチームも分かってない。誰も分かっていない。たとえ一個人で分かっている人間がいたとしても、もしそれが君だとしても、僕らがそれを総力を挙げて緊急事態として扱わなければ、これっぽっちも意味が無いんだ。僕らはプロダクトをローンチして、それを後から魔法のように美しい外部拡張可能なプラットフォームに成長させられる、そんなふりをし続けることを、やめなければならない。何度もやって、だめだったじゃないか。

優先度に加え、ドッグフードを食べることにも言及されている。

プラットフォームの黄金律ってのは、自分のドッグフードを食えってことだ。 Google+ プラットフォームってのは惨めなまでに後知恵だ。ローンチ時には一つたりとも API が無かった。そんで最後にチェックしたときには、僕らが提供してたのはわずかばかりのほんのちっぽけな API さ。

自社開発のプロダクトも、サードパーティと同様の条件でプラットフォーム上に構築されるべきだと書かれている。

3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。

プロダクトを早く出し、改善を繰り返すことで強くすることは、今では半ば常識になっていると思う。プラットフォームのもっとも近く大きいユーザーは同じ社内のプロダクトということになる。ドッグフードを食べなければ、良いプラットフォームが作れないということだろう。

Bezos が命令を出してから僕が離れるまでの間に、 Amazon は全てにおいてまず最初にサービスを考える企業へと文化的に変化していった。確かに SOA のアプローチには長所も短所もあるし、短所を書き出してみたら切りが無い。でも全体として、 SOA ドリブンのデザインというものこそが、プラットフォームを可能にする、これは正しいことだ。

全員がプラットフォーム化の優先度を認識すること。プラットフォームの上に自社プロダクトを作ること。この言葉にそれらが端的に示されている。

「プラットフォームから始めろ。そしてそれをなんにでも使え」

方法論

方法論の部分は Microservices や SOA といったキーワードでより網羅的に調査することができそうだが、記事中でもいくつか言及されていた。

プラットフォームはひとつのシステムではなく、複数のシステムが協調して動作することになる。そのことによる難しさ。

問題時の影響が掛け算で増えていく。

ポケベル通知（ pager escalation ）はどんどん難しくなった。だってチケットの本当の持ち主がわかるのに、20回は行ったり来たりしないとならなかった。もしあるチームからの一回の応答に15分かかったとしたら、正しいチームがそれを受け取るまでに何時間もかかってしまう。たくさんの前準備と測定としっかりしたレポーティングをやるようになった。

連携先システムが増えることで、信頼性の低い通信相手にあたる確率が増加する。クオータ・スロットル重要性があがる。

周りの全ての同僚チームが、突如 DOS アタッカーになりうるようになった。誰も手が付けられなかった。全てのサービスに、かなり真剣なクォータとスロットルをかけるようになった。

システムモニタリングが高度化する。QA と呼べるレベルにまで磨き込む必要がありそうだ。

モニタリングと QA は同じことだとわかった。大規模な SOA に挑戦するまで、考えもつかないかも知れない。でも、君のサービスが「オッケーすよ、大丈夫っすよ」って応答したからといって、単にサーバにおける「オッケーオッケー大丈夫です大丈夫です」って陽気なロボ声で応える機能だけがかろうじて動いているのかもしれない。サービスが本当に応答しているのか、個別に調べないといけない。問題は再帰的に継続してしまう。モニタリングによって、サービスとデータの全体について包括的なセマンティックチェックが行われるようになり、その時点で自動化された QA と区別がつかなくなった。そう、これらは連続しているんだ。

サービスの数は増えるので、そのディスカバリーの仕組みが必要になる。

何百というサービスがあるから、君のコードはそれらのサービスを通じて他のグループのコードと通信しなくちゃならない。当然、サービスディスカバリの仕組みが無ければサービスを見つけられないだろう。もちろん、サービス登録の仕組みもだ。そしてそれもまた、ある別のサービスだ。そんなわけで、 Amazon はユニバーサルなサービスレジストリを持つに至った。そこではリフレクティブに、プログラマティックに、全てのサービスを探し回ることができた。 API はどんなで、今稼働しているのかどうか、そしてそれはどこにあるのか。

開発環境の作り方も簡単ではなくなる。