背景
Amazon は書籍のオンライン販売から始まり、多カテゴリ EC へ拡大した。ピーク時のトラフィック、在庫、決済、推薦を支える社内システムが巨大化し、同時に配送速度と在庫配置が顧客体験の差を決める局面が増えていた。
ベゾスが繰り返し置く目標は、地球上で最も顧客中心の企業を築くことである。品揃えや価格の改善は積み重ね可能だが、計算資源の調達摩擦や配送の物理制約が残ると、顧客への約束は頭打ちになる。小売サイトの改善だけでは届かない層が、インフラ側に残っていた。
制約・常識
2000年代前半、企業の計算資源は自社データセンターか固定契約のホスティングが中心で、API で分単位に増減する従量課金モデルは主流ではなかった。物流も、小売企業が自前のフルフィルメント網を競争優位の核にする発想は限定的で、「本業は商品を売る側」という境界意識が強かった。
組織文化の制約もある。四半期の売上と在庫に最適化されやすい現場では、汎用クラウドや長期の物流投資は「本業から遠い」と見なされやすい。顧客中心を掲げるだけでは、発明の優先順位と実行の速度は自動では上がらない。
非連続な一手
Amazon はオンライン書店としての事業定義を超え、クラウド（AWS）と物流・フルフィルメントを含む総合インフラへ転換した。S3 や EC2 のように社内で標準化しつつあった計算・ストレージを外販し、同時に配送網・倉庫・後には配送速度そのものを製品化した。固定のサーバー契約でも、書店のカタログ拡張だけでもない。
これは UI の微改善やカテゴリ追加の連続ではなく、事業境界そのものを動かす変化だった。小売の裏方だった計算と物流を、顧客体験を支える（そして外部にも提供しうる）インフラ事業として再定義した点が非連続である。
どう Resourcefulness が現れたか
Resourcefulness は、顧客 Obsession を基準に何を発明し何を捨てるかを決め、その判断を高速に実行へ落とした点にある。社内の拡張痛を API と運用プロセスに抽象化し、同じ投資を社内需要と外販の両方で回収する。物流では、在庫配置・配送オプション・当日／翌日配送など、顧客の摩擦を一つずつ製品要件に変換した。
資金・エンジニアリング・運用ノウハウを「自社サイト専用」に閉じず、開発者と買い手の両方が組み立てられる部品として再配置した。結果として、小売以外の収益源と、世界規模のインフラ学習ループが生まれ、発明のサイクルが短く回り続ける構造になった。
積み重ね可能な目標との接続
「地球上で最も顧客中心の企業を築く」は、単一カテゴリの EC 改善では完結しない。選択肢・価格・利便性を長期に拡張するには、計算と物流の両方で顧客の摩擦を取り除き続ける必要がある。AWS と物流インフラは、その目標を支えるレールであり、外部イノベーションの土台にもなる。
エピソードとしては、オンライン書店がクラウド・物流の総合インフラへ転換した局面であり、顧客 Obsession に基づく高速な発明と実行が、その転換を可能にした。クラウド上の AI・データ基盤や配送体験の高度化も、同じ目標への積み重ねとして読める。