私の役割
プラットフォームと顧客獲得の取り組みで、プロダクト戦略、ロードマップの優先順位、要件、実行を主導しています。共通基盤の方向性を定義し、連携計画、正とするデータの所在、内製・外部導入の比較を進めました。
KabuK Platform · プロダクトとプラットフォームの統括
ホテルの流通を、もっと見えるものに。
流通、販売者の可視化、対象範囲内の在庫管理を支えるホテル向け基盤。事業全体に必要な共通機能が、その裏側を支えます。
取り組みの概要
販路、可視化、対象範囲内の管理をまとめたホテル向けプラットフォームをつくり、旅行エコシステムの共通基盤を確立する。
事業全体を横断して
開発、財務、運用、供給、営業、分析、経営の各チームと協力しています。方向性と要件が私の担当であり、実装やサービス運用は各領域の協力によって成り立ちます。
プロダクトの方向性と提供範囲。 リリース状況は、機能、市場、施設・パートナー、接続ごとに確認します。v2.1の多くの機能は状況の確認待ちで、PlatformのPMSは「計画中」です。
課題の出発点は、ホテル。
Platformの構想は3つの問いから始まります。誰が客室を販売しているのか。宿泊者にはいくらと表示されているのか。販路を増やすと、どれだけ作業が増えるのか。必要なのは、分断された画面を増やすことではなく、判断に使える情報と管理機能です。
流通の可視化
参加する販売者と宿泊者向け料金を、一緒に理解できること。可視化の範囲は、接続済みパートナーと取得可能なデータに依存します。
運用の負担
販路が増えると、接続、契約、管理作業も増えます。1つのホテル導入基盤から、合意した範囲の販路を有効化する方向性です。
料金の判断材料
自社料金は、地域の適切な条件と比較することで役立ちます。意味のある絞り込みと、他施設のプライバシーへの配慮が必要です。
私の担当領域では、これらのホテルのニーズを、料金、在庫、コンテンツ、予約、仕入先管理、社内ツールにつなげます。ホテル向け機能の裏側には、一貫したデータと明確な責任範囲が必要です。
大きなエコシステムの中にある、ホテルの基盤。
PlatformとExchangeは、異なる利用者の関連する課題を解決します。Platformはホテル側の基盤、Exchangeは流通パートナーへの経路です。HafHとOmakastayも、構想上はそれぞれ独立した流通機会です。
ホテル向けの基盤
参加ホテル
客室、料金、空室状況
KabuK Platform導入支援、対象範囲内の管理、可視化
ホテル側の追加販路
HafHOmakastayグローバル供給
アジアを主軸とする供給に加わる在庫
取引基盤
KabuK Exchange
- 供給元ごとの情報を1つのホテルに統合
- 条件を満たす供給元を選定
- パートナーの取引条件を適用
流通
パートナーのプラットフォーム
- OTA
- 旅行会社
- 卸事業者
- 旅行プラットフォーム
ホテルの視点
Platformは、参加ホテルの導入、可視化、対象範囲内の管理の土台です。HafHとOmakastayは別の販路候補であり、Exchangeの下流にあるものとしては示していません。
v2.1資料を基にした概念モデルです。経路は利用資格、接続の準備状況、合意条件によって異なります。本番アーキテクチャ図ではありません。
可視化を、判断につなげる。
参加する販売者と宿泊者に提示する料金を、1つの画面で確認する構想です。情報の鮮度が重要な制約であり、更新は日次を想定しています。対象範囲は、パートナー接続と取得可能なデータによって異なります。
管理の範囲には、ホテル料金、空室、割当在庫、Platform経由でのパートナー・チャネル単位の有効化と無効化が含まれます。一部の変更には承認が必要な場合があります。何を変更でき、その後どうなるのかが分かるよう、要件と体験にこの違いを反映する必要があります。
拡大して見るプロダクトとしての問い
ホテルは、自社在庫を誰が流通させているかを理解し、情報の鮮度と対象範囲を確認し、実際に与えられた管理権限の範囲で行動できるか。
競合を特定せずに、役立つ市場情報を。
競合比較（コンプセット）の構想では、他施設を匿名化・グループ化して比較します。宿泊日、客室条件、キャンセル条件、比較対象とする地域を設定できます。
単に安い料金を表示することとは異なる課題です。料金の判断に役立つには、同等の条件で比較する必要があります。この構想の対象は、KabuKが施設を扱う市場に限られます。
拡大して見るプラットフォームの裏側にある判断。
担当する仕事には、基盤の範囲・要件の定義、連携計画、投資判断があります。ホテル向けの構想を支える主な判断領域です。
共通機能と、明確なサービスの境界
判断の対象
料金、在庫、コンテンツ、予約、仕入先管理、社内ツールを横断する、基盤のプロダクト方針を確立しました。
なぜ重要か
ホテルの管理機能や販路は、複数の領域の連携に依存します。境界を明確にすることで、どの機能が変更に責任を持ち、どのチームが依存するかを議論できます。
トレードオフ
広いビジョンには、提供内容を理解できる境界が必要です。集約は、責任範囲とインターフェースが明確であってこそ役立ちます。
データの整合性と、正とする情報
判断の対象
分断されたシステム間の正規化、整合性、正とするデータの所在を含む連携計画を主導しました。
なぜ重要か
同じホテル、料金、在庫、予約が複数のシステムに現れます。受け渡す情報に一貫した意味を持たせる要件が必要です。
トレードオフ
共通モデルは、意味のある仕入先ごとの差異を捨てたり、利用可能なデータの限界を隠したりせず、共通の動作を支える必要があります。
内製か、外部導入か
判断の対象
旅行テクノロジーの機能や外部サービスを、スピード、費用、コントロール、長期的な柔軟性で評価します。
なぜ重要か
最も速く機能を追加する方法が、将来の料金、運用、流通の選択に影響する依存を生む場合があります。
トレードオフ
実装速度だけでなく、継続的な費用、所有権、変更のしやすさも考慮します。
流通経路と、製品ごとの範囲
判断の対象
Platformは社内運用と外部連携を支え、将来のB2B・B2B2B流通も対象とする方向性です。
なぜ重要か
HafH、Omakastay、Exchangeの目的は異なります。共通基盤によって、それぞれの違いが見えなくなってはいけません。
トレードオフ
再利用と同時に、販路の利用条件、市場差、パートナー権限、個別に確認した準備状況を維持する必要があります。
基盤の方向性を、事業の優先順位へ。
プラットフォームと顧客獲得の領域で、戦略、ロードマップ、要件収集、実行を主導します。技術的な実現性と、財務、運用、供給、営業、分析、経営のニーズを整合させる仕事です。
事業の検討と技術計画は密接につながっています。一貫性が必要な情報、優先すべき機能、外部への依存が将来の選択肢に与える影響、投資がレポートや判断をどう支えるかを考えます。
進捗、範囲、そして次の一歩。
これまでに整えたもの
基盤のビジョンと方向性、主要領域の運営モデル、連携計画、投資分析。
機能の提供準備
v2.1の確認時点では、販路、可視化、在庫管理、競合比較、ホワイトラベル提供の利用可否は確認が必要です。PMSは「計画中」とされています。
ホワイトラベルでは、ホテル独自の予約エンジン、Webサイト、ロイヤルティプログラムへ構想が広がります。各製品固有の範囲と取引条件を維持し、施設、接続準備、合意内容に応じて有効化します。
目指すのは、新しいプロダクトラインを支えながら、ホテルに分かりやすい情報と対象範囲内の管理を提供する基盤です。画面の先にある、定着、業務効率、判断の質を重視しています。
基盤の方向性に関する公開投稿を読む