top of page

情報インフラを語る (1)

  • 6月12日
  • 読了時間: 4分

更新日:2 日前

ソフトウェアを情報インフラの主役に押し上げた「APIマンデート」


社会インフラとしての情報システムも、ダムや高速道路と同様、始まりはハードウェアを主役とするものでした。コンピュータの巨人、IBMの時代についてはそのうち触れることにして、ここではソフトウェアが決定的にハードウェアを支配することになったターニングポイントについて語りたいと思います。


Windows95が一世を風靡した1995年を経て、インターネットバブルの時代がやってきます。ソフトウェアの役割は大きなものになっていましたが、それでもコンピュータ業界の主役はIBM、HP、Sun Microsystemsといったハードウェアメーカでした。日本でも富士通、NEC、日立製作所が不動の地位を獲得していました。ところがこの頃、ソフトウェアの生産性に革命を起こした出来事がアメリカで生まれます。「APIエコノミー」と呼ばれる新たなアーキテクチャはコンピュータ言語の進化ではありません。このアーキテクチャは当時、インターネットで書籍を販売していたAmazonで生まれました。


Amazonのインターネット書籍販売のシステムに限らず、大規模なシステム開発は数百人、数千人のエンジニアが協力して行います。エンジニアは役割を分担してチームで開発をしますが、チーム間がそれぞれ作ったプログラムをつなぎ合わせることに、最も大きな労力がかかります。10人でプログラムを開発する時の生産性と、1000人の時の生産性を比較すると一人あたりの生産性は半分以下になってしまいます。規模が大きくなればなるほど、つなぎ合わせることにかける労力は拡大し、開発失敗のリスクが高まってしまいます。いかに生産性を落とさずに、大規模なプログラム開発をやり遂げることができるかということが大手ソフトウェア会社の力の見せどころであり、大規模システム開発の方法論を学ぶことがソフトウェアエンジニアの王道でした。

AmazonのCEO(当時)、ジェフ・ベゾスのAPIマンデートとはこうした大規模開発の常識を真っ向から否定するものでした。Amazonの開発チームはピザ2枚と呼ばれる小さなチームで編成されています。小さなチームが全ての決定権を持って開発していくことがソフトウェア生産性を最も高めるというのがAmazonの考え方です。しかし大きなシステムを開発する際にはどうしてもチーム同士のすり合わせに時間がかかってしまいます。どうにかしてすり合わせを最小限に止める方策はないものだろうか。この考え方を突き詰めて打ち出された方針が「APIマンデート」でした。

① すべてのチームは、データと機能を例外なくサービスインターフェース(API)を通じて公開しなければならない

② チーム間の通信は、すべてこのインターフェースを通じてのみ行われる

③ いかなる直接的な結合も禁止する。(共有メモリ、データベースの直接参照、裏口を通じた他チームのデータ読み取りなどは一切認めない)

④ 技術プロトコルは何でもよい(HTTP、XML等)

⑤ すべてのインターフェースは、例外なく外部(インターネット)の第三者に公開可能なように設計・実装されなければならない

⑥ これに違反する者は、即座に解雇される


従来のソフトウェア開発は、ハードウェアの性能を最大限に引き出すため色々な方法を使ってプログラムにロジックを書き込んでいました。ソフトウェアが動くハードウェアの事情を反映したプログラムは、別のプログラムと組み合わせたときにすり合わせの労力がかかります。APIマンデートが要求しているのは、ハードウェアの事情をAPIに一切持ち込ませずに、ソフトウェアの仕様だけでAPIを使うことができるようにすることです。これによってAmazonは小さなチームが開発するソフトウェア(マイクロサービス)をいくつも組み合わせて世界最大のECサイトを開発する方法に道筋をつけました。


APIマンデートはAmazon社内のものでしたが、APIがシステムを構成していくアーキテクチャはテック業界へ一気に普及しました。そしてAPIエコノミーという言葉が生まれ、API越しに異なる企業のサービスが連携していくクラウドコンピューティングへとつながっていきました。Amazonが最初のクラウドサービス(AWS)を開始したのは決して偶然ではありません。


当時の日本はAPIマンデートの真価を理解していたとはいえないと思います。100人を超える集団を鍛えて誰にも負けないシステムを開発することを競っていた日本のIT開発にとって、魂を否定するような開発スタイルは邪道のように感じられました。APIマンデートはシステム開発を文化の問題から単純なビジネスの問題に置き換えました。100倍のソフトウェアを開発したければ、100倍のエンジニアを雇用すれば良い。かつてのようにエンジニア集団を軍隊のように鍛え上げる必要はなくなったのです。 続きを読む 情報インフラを語る (2) インフラを「サービス」へ進化させたExodus




 
 
bottom of page