私の役割
プラットフォームと顧客獲得の取り組みで、プロダクト戦略、ロードマップの優先順位、要件、実行を主導しています。共通基盤の方向性を定義し、連携計画、正とするデータの所在、内製・外部導入の比較を進めました。
KabuK Exchange · プロダクトとプラットフォームの統括
ホテルの供給を、世界の流通へ。
B2B2Bの取引基盤を支えるプロダクトづくり。仕入先連携、ホテル情報の統合、条件に合う供給元の選定、パートナー別の取引・予約フロー。
取り組みの概要
利用条件を満たすホテルとの直接契約の供給とグローバル在庫を、よりシンプルな流通接続にまとめる。同時に、供給を実際に使うためのルール、ホテル情報、取引条件を維持する。
事業全体を横断して
Exchangeは、供給・営業チームと、開発、運用、財務、分析、経営の関心をつなぎます。私は方向性、要件、連携計画、投資分析、部門間の合意形成を担当。実装とパートナー運用は、チーム全体で担います。
プロダクトの方向性と提供範囲。 リリース状況は、機能、市場、施設・パートナー、接続ごとに確認します。v2.1の多くの機能は状況の確認待ちで、PlatformのPMSは「計画中」です。
仕入れにおけるトレードオフ。
Exchangeの構想は、旅行流通事業者が抱える課題に応えるものです。ホテルとの直接契約は、直接の関係やネット料金へのアクセスを得やすい一方、契約や供給元ごとの接続管理が必要です。卸事業者を介せば接続や取引関係を簡素化できますが、料金条件や流通経路でのホテル情報の扱いをコントロールしにくくなります。
Exchangeは、条件を満たす直接契約の供給とグローバル在庫を、単一の流通関係にまとめる構想です。料金、施設、利用権限をすべて同じものとして扱うことなく、アクセスを簡素化することが課題です。
直接契約
ホテルとの関係と個別の取引条件。供給元ごとに契約・接続の作業が必要。
卸事業者からの仕入れ
接続と取引関係を簡素化。料金条件やコンテンツは供給元に依存。
Exchangeの構想
共通APIとパートナー別の条件を通じ、対象となるホテルのネット料金とグローバル在庫を提供。
1つのExchange、異なる供給経路。
参加ホテルは、ホテル向けのPlatform基盤から接続します。グローバル供給はそれとは別の経路でExchangeへ入ります。需要側はOTA、旅行会社、卸事業者、旅行プラットフォームです。
ホテル向けの基盤
参加ホテル
客室、料金、空室状況
KabuK Platform導入支援、対象範囲内の管理、可視化
ホテル側の追加販路
HafHOmakastayグローバル供給
アジアを主軸とする供給に加わる在庫
取引基盤
KabuK Exchange
- 供給元ごとの情報を1つのホテルに統合
- 条件を満たす供給元を選定
- パートナーの取引条件を適用
流通
パートナーのプラットフォーム
- OTA
- 旅行会社
- 卸事業者
- 旅行プラットフォーム
流通事業者の視点
流通事業者は、合意した供給と業務フローを利用するためにExchangeへ接続します。参加ホテルの供給とグローバル在庫は別々に入り、外部供給をPlatformで管理する図ではありません。
v2.1資料を基にした概念モデルです。経路は利用資格、接続の準備状況、合意条件によって異なります。本番アーキテクチャ図ではありません。
拡大して見る複数の供給元情報を、1つのホテルへ。
Exchangeの概念レイヤーは、供給元ごとの複数の情報を1つのホテルにまとめ、利用条件を満たす供給元を選び、流通パートナーの取引条件を適用するという3つの要素で構成されます。
これが「1つの接続」の裏側にあるプロダクトの詳細です。同じ施設が複数の供給元から届いても、流通事業者には一貫したホテル情報が必要です。供給元の選定では利用資格や条件を守る必要があり、安く見える料金が必ずしもそのパートナーに販売可能な料金とは限りません。
ホテルを統合する
供給元の情報を、それが表す施設にひも付ける。
供給元を確認する
対象の供給、市場、料金条件を考慮する。
パートナー条件を使う
取引条件を流通パートナーとの関係にひも付ける。
合意した範囲を提供する
パートナーと確認した在庫・予約業務を支える。
v2.1の構想を基にした概念的な流れです。本番のアルゴリズム、APIエンドポイント、実装の詳細を示すものではありません。
ホテルのブランドとコンテンツも構想の一部です。施設名、所在地、説明、画像、設備、ポリシーには、合意した利用権が適用されます。データモデルとパートナー体験では、商品とともにこれらの条件を維持する必要があります。
接続の裏側にある判断。
プラットフォーム全体の仕事では、APIによる供給元・パートナー連携、データ正規化、サービスの境界、正とするデータの所在、内製・外部導入の分析を扱います。Exchangeでは、これらを旅行流通の文脈で具体化しています。
条件を失わずに、接続を共通化する
判断の対象
連携計画では、供給元やパートナーごとに異なるデータを共通基盤に取り込みます。同時にExchangeの構想では、利用資格とパートナー条件を維持します。
なぜ重要か
共通接続が役立つには、利用するパートナーにとって情報の意味が保たれている必要があります。
トレードオフ
連携を簡単にするために、料金制限、コンテンツの権利、予約に影響する違いを黙って落としてはいけません。
ホテルの識別と、商品の供給元を分ける
判断の対象
プロダクトのモデルでは、複数の供給元情報をホテルに統合したうえで、ルールに従って対象の供給元を選定します。
なぜ重要か
旅行者が認識する施設と、流通事業者が予約する供給元は、関連していても異なる概念です。
トレードオフ
一貫したホテル情報と、供給元別の空室状況、料金条件、取引上のアクセス権を共存させる必要があります。
共通APIを約束する前に、範囲を定義する
判断の対象
合意した在庫・予約フローに単一のExchange接続を提供する構想です。対応機能と本番アクセスは技術レビューで確認します。
なぜ重要か
何にアクセスでき、何を予約でき、問題が生じたらどう対応するのかについて、流通事業者との共通認識が必要です。
トレードオフ
分かりやすい取引説明によって、業務上の制限、接続準備、運用責任が見えなくなってはいけません。
機能を投資として評価する
判断の対象
内製・外部導入を分析し、技術・事業双方の関係者とともに、基盤への投資を事業目標に整合させます。
なぜ重要か
旅行商品の接続方式は、実装作業、継続的な費用、体験のコントロール、将来の流通に向けた柔軟性に影響します。
トレードオフ
外部機能は初期の提供を速める一方、長期的な依存を生みます。内製機能には、開発費と運用費を正当化する明確な事業上の根拠が必要です。
接続には、運用上の合意も必要。
技術レビューでは、API資料、対応業務、アクセス要件と環境、在庫・コンテンツの範囲、料金制限、予約条件、エラー対応、運用責任を確認します。
これらは技術の詳細であると同時に、プロダクトの要件です。パートナーが何を提供でき、何を自分で解決でき、どこで基盤側の支援が必要になるかを決めます。
供給と市場の適合性を定義
対象市場と、パートナーの顧客構成を理解する。
取引・技術の範囲に合意
流通モデルと、対象の供給・必要な業務を結びつける。
接続準備を確認
アクセス、連携要件、環境、責任範囲を確認する。
合意した範囲を有効化
双方が支えられる範囲について、稼働開始の計画に合意する。
v2.1資料の導入フレームワークです。順序と時期はパートナーごとに合意します。
取引条件の明確さも、プロダクトの明確さ。
v2.1の取引構想では、初期設定料や継続的な連携費用は設けず、パートナー別の取引量に応じた条件を想定しています。取引手数料、請求のタイミング、支払い、精算の規定は個別に合意します。
プロダクト計画では、アクセスと取引条件の関係が重要です。市場、料金の利用資格、コンテンツ権限、連携範囲、運用責任を取引関係と一致させる必要があります。各供給元・業務へのアクセスは、合意した範囲に結びつきます。
方向性と、ローンチの準備状況。
Exchangeは継続中のプラットフォーム・流通の取り組みです。v2.1の確認時点では、アジアを主軸とする供給、グローバル在庫、対象の直接ネット料金、ホテルコンテンツ、共通API業務について、パートナーごとの提供範囲を確認する必要があります。
提供内容を定義し、供給モデルとパートナー業務をつなぎ、ローンチ準備を明確にすることが、この取り組みの中心です。
成功のために確認すべきこと
パートナーが合意した供給にアクセスし、条件を理解し、対象の業務を完了でき、明確な責任分担で接続を運用できること。
この流通の方向性を、KabuKで担当する共通基盤のロードマップ、連携計画、関係者の要件、投資判断につなげることが、私のリーダーシップの役割です。