Booking.comはすべての製品変更をA/Bテストで包み込む — 同時に1,000以上が稼働中

Booking.comが最大級の旅行マーケットプレイスの一つへと成長するにつれ、製品チームは機能を意見で決めてしまうリスクを抱えていた。同社は10年以上にわたりオンライン対照実験を実施してきており、製品マネージャーだけでなく全員が、アイデアを安価に、安全に、そして信頼できるデータで検証できるようにしたいと考えていた。

実験をデフォルトの意思決定システムにする。バグ修正であってもすべての変更はA/Bテストで包み込んで出荷し、誰もが実験を立ち上げ、履歴を読み、有害なテストを停止できるようにする。

エンジニアたちは、過去のあらゆる成功と失敗を検索できるリポジトリ、リクルーティング・トラッキング・メトリクス用の汎用API、2つの独立したモニタリングパイプライン、A/Aテストプール、そして事前登録や成功結果のピアレビューといった安全策を備えた社内実験プラットフォームを構築した。各部門には専任のサポートチームが付き、誰もが実験をエンドツーエンドで担当できるようになった。

モバイルアプリ、ホテル事業者向けツール、カスタマーサービスの電話回線、社内システムにわたり、1,000以上の実験が同時に稼働している。あらゆるリデザイン、インフラ変更、バグ修正がテストで包み込まれるため、製品の意思決定は意見から証拠へと移り、学びはチーム間で再利用される。

Booking.comでは、実験は一部のチームが使うツールではなく、会社が意思決定を行う方法そのものである。10年以上にわたり、この旅行プラットフォームは証拠に基づく製品開発を行っており、2017年までには各部門が、モバイルアプリ、ホテル事業者向けツール、カスタマーサービスの電話回線、社内システムにわたり、任意の日に1,000以上の同時実験を実行・分析していた。

意図された選択は民主化だった。実験プラットフォームは、最初の実験以来のあらゆる成功と失敗を検索できるリポジトリとして機能し、誰もが履歴を参照して新しい仮説を立てられる。汎用APIがリクルーティング、ランダム化、レポーティングを抽象化し、各部門には専任のサポートチームがあるため、テストの実行に製品マネジメントの許可は不要である。

信頼はエンジニアリングの規律から生まれた。別々に維持管理される2つのパイプラインが同じメトリクスを計算し、互いに照合して監視される。A/A実験のプールが統計を検証し、事前登録や成功結果のピアレビューといった安全策がpハッキングを抑止する。社内の誰もが、有害な実験を自ら停止する権限を与えられている。

その結果は、エンジニアたちが2017年の論文で書いたように、「全面的なリデザインやインフラ変更からバグ修正まで、あらゆる変更が実験で包み込まれる」会社となった。製品開発は一連の意見ではなく、測定された賭けの連続へと変わったのである。

実験を分散化することで、何千人もの人々が製品マネージャーによる優先順位付けを待つことなくアイデアを試せるようになった。

成功と失敗の検索可能な履歴により、チームは互いの学びを再訪し、その上に積み上げられる。

信頼できるインフラ（二重パイプライン、A/Aプール、事前登録）により、証拠が意思決定の裁定者として受け入れられるようになった。

実験プラットフォームをビジネスロジックから緩く結合させておくことで、勝利する変更の出荷は1つのAPI呼び出しを削除するだけで済むようになった。

誰もが有害な実験を停止できる権限を持つことで、安全性とスピードが両立した。

全員が安価で安全な実験を実行できるなら、意見について合意を得る必要はない。インフラと証拠の文化が意思決定をテストへと変え、失敗を共有され検索可能な学びへと変える。

2000年代半ばにアムステルダムのエンジニアたちが書いた社内フレームワークは、拡張されてきたが書き直されたことはない。2026年にSilicon Canalsは、Booking.comが依然として本番稼働中の予約ページで1,000以上の同時テストを実行し、年間累計数万件の実験を行っており、そこでは0.1%のコンバージョン変動が8桁の金額になることを報じた。このパターンは「実験文化」として業界全体に広がり、ベンダープラットフォーム、公開プレイブック、他のテック企業が、Booking.comが先駆けたのと同じ「デフォルトでテストする」モデルを採用した。