API Mandateの紹介
ウェブの世界には面白い小話がたくさんあります。
雨宿りとWEBの小話、personalityのkeethです。
今日も一つ、興味深いお話をご紹介します。
今回の話題は、数十年前にAmazon創業者である
ジェフ・ベゾスが社員全員に送ったとあるメモ、
The API Mandate についてご紹介します。
冒頭にも言いましたメモですが、2002年に
ジェフ・ベゾスが書いた従業員向けのメモです。
メモって何度も言っていますが、
ぶっちゃけると命令と言ってもおかしくない。
それくらい強制力の強いものだったという話です。
マンデートという英単語ですが、
ちょっと馴染みなかったので調べてみました。
これは権限とか信任みたいな意味の単語ですが、
今回のケースは命令が適しているだろうと思います。
動詞にすると、何たらを義務付ける、
強制する、もしくは命令するという意味があります。
その3つの命令です。
本文に入っていきたいのですが、かなり短いです。
たった6個のメモがジェフ・ベゾスからメールで送られたらしいです。
英語なんですが、僕は英語苦手なので、
日本語翻訳したものを読ませていただきます。
1つ、全てのチームは今後サービスインターフェースを通じて
データと機能を公開する。
2つ目、チームはこれらのインターフェースを通じて
相互に通信しなければならない。
3つ目、直接リンク、
または他チームのデータストアの直接読み込み、
こういうメモリーモデル、バックドアなど、
その他のプロセス間通信というものは一切認めない。
唯一許されるのは、ネットワークを介した
サービスインターフェースの呼び出しによる通信のみである。
4つ目、使用するテクノロジーは問わない。
HTTP、コルバ、PubSub、カスタムプロトコル、どれでも構いません。
5つ目、すべてのサービスインターフェースは例外なく
外部化できるように一から設計しなければならない。
つまりチームはそのインターフェースを外部の開発者に公開できるように
計画設計しなければならない。これに例外はない。
最後6個目、これをしないものは解雇する、
というメッセージでした。
命令の内容と影響
6つ目、強いですね。
いや、Bezosだから言えることですけど。以上6つのことですね。
とにかく自分たちのチームの機能とかデータに関しては
サービスインターフェースを通じてのみ共有しますよという話です。
僕らもそれが取得したければ、それぞれのチームの
インターフェースを通じてAPI叩きなさいという感じですね。
これ、最初は見たとき、2002年にこれを書いた
Bezosの専権性がすごいなと思いましたけど、
そしてこれを一度は思ったことある人、エンジニアなら思ったことあると思いますけど、
かなり強いなと思います。プロダクト感。複数のプロダクトを
持っている企業がプロダクトの間で情報連携したり、
その機能を使いたくてアクセスがしたいっていうニーズが
ちょこちょこ出てくると思います。特にマルチプロダクトとかやり始めた
協賛はどこかで考えるはずなんで、そうなったときにどういう連携の仕方をするか
ということで、API化しましょうと。
このマンデート、多くのAPIプロフェッショナルにとって共感を呼ぶものだったとは
思います。実際、記事もそう書かれていました。なぜなら多くのAPIイニシアチブにおける
革新的なソリューションを構築するためにAPIを使いたいけど、
誰もAPIの構築に投資をしたがらないっていうような根本的な
ヘッドロックに対処したからですと。Vedosっていうのが、とあるときに
この状況を社内の組織内で発見をして、仕組みっていうのを考えて
命令として出したと。結局それで解決がしました。
これ、その組織の中だけではなくて、前者的にこうしていこうっていう風に
思って、前者に実際展開をしたっていう、そこの先見性ですよね。
これがどれだけメリットがあるかっていうのを、彼はそういうふうに考えた
と思いますけど。思っても、CEOだからといって
ドンと全員にやるって相当すごいなと、やっぱ思いますね。
でも実際このメモの結果として、いろんなAPIがバーッと作られるようになり、
今のAWS、Amazon Web Serviceとか、FBAですね、
Profilament by Amazonとか、あとAmazon Alexaみたいなものの基盤が
開発されたと。そういうことを聞くと、この命令っていうのはすごく
良かったんだろうなと思いますね。AWSなんて、これなしに
世界のシステムが動かないと言っても過言ではないと思いますので。
このAPI哲学っていうのが今の主流というか、Amazonの中では
根幹になっているっぽくて、実際Amazonって短期的な時間軸で
革新的な製品を構築することっていうのを、このAPI哲学から可能になった
わけですし、Amazonがスケーラブルなエコシステムと
プラットフォームビジネスモデルへ移行するってことも実現したという話なので、
かなり素晴らしかったんだろうなと思います。ビジネス的にも。
合案っちゃ合案だし、現場からするとボーってなって一気にいろんなものを
他企業への適用
考え直したり、すでに走っているプロタクスとかあると思いますけど、
そこにインターフェースを用意して、いきなり他からも叩かれるようにするっていうので、
テーブル構造もそうですし、何を公開して何を公開しちゃダメかみたいなところ。
インターフェースのドキュメントとかですかね。APIの、今だったらあるかわからないですけど、
昔もスワッガーとか使ってたんですかね。わからないけど。
定義したとかある気がします。いろいろ大変だったと思いますけど、
混乱、混乱だったのかなどうなんでしょうね。このジェフ・ベゾスの指示に従って、
みんながバッと。これ従わないと解雇ですからね。首になるので対応したんだと。
その結果今すごい高速に、かつ革新的な製品を生み出して、
世に出せるっていうのがもうファクトになりましたし。
また、AWSではですね、現在1日のデプロイ回数というものが、
そのチームとかプロジェクトの規模とか、採用しているDevOpsのプラクティスによって大きく異なるんでしょうけど、
週に30回以上デプロイを行うってことも珍しくないと。
各システムとかサービスとか全てをひっくるめて、Amazonではですね、
1時間に最大1000回もデプロイをするっていうようなお話も昔ありました。
にわかには信じがたいですけど、リインベントで実際そういうのの発表があったりしたということで、
1時間に1000回デプロイですよ。すごすぎるなと思いましたね。
規模がでかすぎてわけわかんないとか思いましたよ。
全世界でみんなが使っているようなクラウドシステムの中でそれを実現したっていうのもまたまたすごい話ですよね。
そんな感じで、このAPIマンデートっていうのは結果として大きな成功の要因になりましたけど、
じゃあこれを他企業が使ってみたらどうなんてやっぱり考えるんですけど、
Amazonがそれで機能したからといって、このAPIマンデートをそのまま自社に適用するのは早いというか早経というか、
しっかり考えてからやるのがいいと。それは当たり前ではありますけど、思いますね。
むしろAPI FirstとかAPI文化、もしくはAPI思考を導入する際の灯台みたいなものとして方向性を定めるもののに、
このマンデートっていうのを参考にすると良いんじゃないかなと。
いきなりもうそのまま全部バッてやるっていうのは、APIっていうものそのものをまず浸透させるところですよね。
理解していただくところからと思います。
我々エンジニアリングじゃないとAPIって何ってなると思いますよね。
アプリケーションプログラムインターフェースの略ですけど。
この自社のAPIマンデートっていうものは既存の環境と文化に合わせて調整する必要もあるっていうのは想像に固くないですが、
開発チームとかもしくはアーキテクチャーチーム、もしくはエコシステムおよびプラットフォームチームとかいるんですかね。
もし社内にいらっしゃったらそういうチームとか、外部のそういうアーキテクチャーとかを見てくれるようなコモンの方とかに
しっかりレビューしてもらったりする必要もあるかなと思いますし、
開発チームとかアーキテクチャーチーム、まさに開発をしている、プロダクトを開発している現場のチームにとっても
結構大きなものであり、必要な変化をもたらすことになるので、
多少ストレッチな内容にするのがいいんじゃないかなっていうふうに僕も思いましたね。
まずはワークするところですね。そのAPIマンデートに乗っかってやるんであれば。
それを実現してしっかり社内が回るところまでやって、
次にストレッチみたいな内容にするっていうのが、僕としてはいい気がしますけど、
参考にしている記事自体は、やるんだったら最初から挑戦的なストレッチの内容にすべきだっていうふうにもおっしゃっていて、
Amazonだからそれができたっていうふうに僕はちょっと感じてますので、
APIマンデートの概要
例えば僕ら上梨みたいなスタートアップだと、いきなり全部やってるどうなんだろうっていうのはありますが、
ただ規模が小さい分やりやすいっていうのはあったりしますし、難しいところですね。
ここは経営判断で、もしやるんだったらと思いました。
あとはですね、効果的なAPIルールっていうのを定義することは容易じゃないっていうのも、
僕らからするとそうだよねって話なんですけど、そのAPIの戦略考える際ですね、
マンデートからAPI戦略っていうのを考えたマティアス・ビールっていう方はですね、
この方はそのAmazonAPIマンデートの背後にある考え方とかコンセプトっていうのを詳細に解説した無料のミニ電子書籍っていうのを提供していて、
これらのアイディアを自社に適用するに役立つよっていうので、
ファンクを程度に見てくださいっていうことでした。無料ですのでね、とても良いかなと思います。
以上、ちょっと短いですけどね今日は、そんなものの紹介でした。
Amazonの技術とS3の進化
なかなか社内の組織っていうのをシステマチックに考える方々っていうのがすごくこの記事だけでも分かるなというか、
感じられて面白かったと思います。
はい、では今回そのところでエンディングトークに行きたいと思います。
最初これ読んだとき、僕はすごい好感触だったし、Amazonってさすがだなと思ったんですけど、
各プロダクトとかチームのデータだったり機能っていうものがAPI化されるということで、
もしかしたら社内組織ってどんな感じか今分かってないし、まだそれは調べてないんですけど、
なんとなくコンウェイの法則に従うものになるのかなって思ったりもしましたね。
でもSaaSやってるからそれは当然かもしれないですけど、
いわゆるそれぞれフィーチャーチームっていうのがあって、
アーキテクチャーとしてもそういうマイクロサービス化をしていってっていうことだと思いますけど、
ただ話からするとこれは逆コンウェイの法則っていう方が適してる気がしますね。
そういうアーキテクチャーにするぞと。
もともとなってなかったのかわかんないですけど、
こういうことをしていくぞっていうふうに号令を出さなきゃいけなかったっていう背景を考えると、
そういうアーキテクチャーにしていくっていうので組織も構造変化をしたんじゃないのかなと。
もともとでもそういう組織構造になっているんであれば、
お互いのプロダクト間の連携ってもっとズブズブの依存し合うような関係だったり、
そういう設計になってたのかな。
このAPIマンデートの紹介記事だけだとそこまでは読めなかったんで、
興味ある人はちょっと調べていただくといいのかなと思います。
Amazonの組織ですね。
でも今あれだけスピード感出るようになったってことは、
やっぱりチームとかプロダクト、マイクロサービスごとにパキッと分かれていて、
お互いに連携するときはAPIで連携してっていうことになってるんだろうと思いますね。
つまりフィーチャーチームを作ってマイクロサービスがそれぞれに接続しているという感じだと思います。
何にせよ結果としてAWSみたいなのが生み出されたという、
この背景というか要因の一つになっているのがAPIマンデートだったというので、
これが今から3年前に出されているということで、
ベゾスの頭の中とか今何を見ているのかってやはり気になりますね。
本当、彼のブログとかあったらマジで毎日読みたいなって思いました。
あと他にもですね、ベゾスは書籍とかをいくつか出されていたはずなので、
その辺の記事だったり書籍を読んで彼の考え方思考というものを少しでもね、
自分の中にインストールできたら物の見え方はもう少し変わっていくのかなって思いました。
僕今特にエンジニアリングマネージャーをしておりますので、
チームの体制とかどういうチームが強いチーム組織なのかっていうのをずっと考え続けているので、
ジェフ・ベゾスのそういうお話とかこれも一つの形として参考にしつつ、
パクれるところはパクっていきたいかなと思ったりもしました。
ちなみに余談ですけど、このマンデートが出たのが2002年で、
そこから先ですね、生み出されたサービス何かあるのかなってちょっと調べたんですけど、
びっくりしたのはS3ですね。
あれ2006年に実はスタートしてたらしくて、
その最初の仕様というのはすごい簡潔で、
インターネット用のマロック、Cプログラムの主要なメモリ割り当ての関数ですね。
一瞬IOSの勉強したことがあってよく見たなって感じですけど、
こういうインターネット用のマロックを求めていったらしくて、
その出発点からS3ってのは現在何兆ものオブジェクトっていうのを保存したり、
それらに対する毎秒何百万ものリクエストを処理するまでに成長したと。
未だに全世界でバケットどんどんどんどんみんな生やしてるでしょうし、
いろんなところからどんどんアクセスしてるはずなので。
フロントエンドも静的にビルドして、
最後デプロイ先行ってS3にデプロイしてる企業さんとかもまだまだたくさんいらっしゃると思いますので、
これを毎秒、今もう何百万で収まらないんじゃないかなと思いますけど。
そんなリクエストが来るようなサービスを、今もう13年?嘘つけ。
今年2025なんで19年。長っ。
これをずっと機能し続けてきて、可用性も担保しつつですね。
でも新しいストレージのオプションとかもできたし、新しい機能もできたり、
セキュリティコントロールもどんどん追加になるなど。
S3って本当にどんどん発展してきたっていうのを今から考えると、
その歴史を見ても面白そうだなと思いましたし、
未だに全世界のWebシステムの支え続けているっていうところで、
ちょっと感動しますね。
でも絶対これもそのAPIマンデッドに従った後の組織構造とか
システム構造の中で生まれているものですので、
いやすごい興味深いなと思いました。
はい、というところで、余談が過ぎましたのでここで終わっていきたいかなと思います。
それではクロージングです。
この番組面白かったよという方はぜひチャンネル登録もお願いします。
もし聞いていて気になることや話してほしいトピック、感想などありましたら
概要欄のフォームやXでハッシュタグウェブ小話でつぶやいてください。
Webはアルファベット、小話は漢字でもひらがなでも大丈夫です。
それではまた雨宿りしに来てください。
今回もお聞きくださりありがとうございました。
雨宿りとWebの小話、お相手はキースでした。さようなら。
あなたの声応募してみませんか。
対象には10万円ほか豪華特典も。
詳しくはpodcaster.jpをご覧ください。
ナンバーワンポッドキャストクリエーターは誰だ。
