背景・課題

一休.com 宿泊には、いくつか重要な業務が存在しますが、その1つに「宿泊料金・ポイントの計算処理」があります。

各ホテル・旅館が設定した料金
サイトを閲覧しているユーザー（会員）の状態
ユーザーが指定している検索条件（日付、人数など）
期間限定で実施しているポイントX倍、のようなプロモーション

などの情報に基づいて、宿泊料金を算出したり、予約で得られるポイント数を計算する処理です。この料金・ポイント計算処理は、以下のような背景・課題がありました。

歴史的経緯から、料金・ポイント計算ロジックが複数のシステムに分散して存在している
（複数システムに分散しているため）ロジックの変更を行う際に、複数のシステムに対して同じ変更を繰り返し実施する必要がある
「今年の冬は、こういうポイントアップのプロモーションを実施したい」というビジネスのニーズに対して、必要以上に対応コストがかかってしまう

昨今、ECをはじめとするWebサービスにおいてポイントやクーポンといった販促・インセンティブ機能はビジネス上も重要な要素となっており、一休.com 宿泊においても例外ではありません。

これを踏まえて、各システムで実施している料金・ポイント計算処理を整理し、本来あるべき姿を検討して改善を進めることにしました。

料金・ポイント計算処理の現状整理と課題、改善策

本来あるべき形を検討するにあたり、まずは現状の料金・ポイント計算処理がどうなっているかを整理するところから始めました。整理については

料金・ポイント計算をどこで、どんな業務で使っているか
それぞれの業務で、料金・ポイント計算にどんな特徴・違いがあるか
本来あるべき料金・ポイント計算ロジックの姿と、現状のギャップは何か（課題）
本来あるべき姿に向けて、現状からどう改善していくか

という4ステップで考えて進めました。

前提）宿泊システムでの料金とポイント計算

ホテル、旅館の宿泊料金は以下のように決まっています。

ホテル・旅館
部屋タイプ
宿泊プラン
宿泊日

この4つの要素の組み合わせごとに料金が設定されています。

ホテル・旅館	部屋タイプ	プラン	宿泊日	料金	補足
ホテルA	スタンダードツイン	朝食付きプラン	2025/12/11	25,000
ホテルA	スタンダードツイン	朝食付きプラン	2025/12/12	30,000
ホテルA	スタンダードツイン	朝食付きプラン	2025/12/13	40,000	同じ内容でも日付ごとに料金が異なる（土曜は高い）
ホテルA	スタンダードツイン	朝食付きプラン	2025/12/14	25,000
ホテルA	スタンダードツイン	朝食付きプラン	2025/12/15	20,000
ホテルA	デラックスダブル	素泊まりプラン	2025/12/11	-	料金が設定されていない日もある
ホテルA	デラックスダブル	素泊まりプラン	2025/12/13	60,000

こんなイメージです。

また、ポイント計算は以下のような要素が絡んできます。

ユーザーの会員ランク（会員ランクによってポイント付与率が変わる）
ポイントアップキャンペーン（期間限定でポイント付与率が変わる）
クーポン利用（クーポン利用時の割引額を考慮する必要がある）

一休.com宿泊では「予約で付与されるポイントを、その場で使える（ポイント即時割引）」という機能があるため、ユーザーには

元の宿泊料金（値引き前）
即時割引のポイント数（ポイント付与率）
実際に支払う料金（値引き後）

の3つをわかりやすく表示する必要があります。

1. 料金・ポイント計算をどんな業務で使っているか

初手として、各システムが料金・ポイント計算処理をどこで、どんな業務で使っているかを整理しました。

(a) 検索を高速に行うためのデータ作成・更新業務
- 後続の検索業務に必要なホテル・旅館の料金を確定するために必要な情報を非正規化して作成・更新する *1
(b) 検索業務
- ユーザーが指定する条件に合わせて予約可能なホテル、旅館や宿泊プランを抽出して画面に表示する
(c) 社内でのマーケティング用途向けのデータ作成・更新業務
- 社内でのデータ分析業務に必要な宿泊プランの料金情報を作成・更新する
- ユーザーに送る販促メールなどに掲載する宿泊プランの料金を計算する
(d) 予約業務
- 最終的にユーザーが選択した宿泊プランのリアルタイムな料金を計算し、予約を確定する
(e) ポイント、クーポンなどの割引計算業務
- 検索、予約どちらでも、指定条件に対して適用できるポイント、クーポンを抽出・計算する

などです。

2. 料金・ポイント計算各業務の特徴と違い

1の整理を踏まえて、各業務での料金・ポイント計算にどんな特徴があるかを見ていきました。結果として以下のような違い（特徴）があることがわかりました。

情報の鮮度に関する違い
- ある程度の精度・鮮度で料金を計算できればよい業務（検索）
- リアルタイムに正確な料金を計算する必要がある業務（予約）
扱うデータ量の違い
- 大量の宿泊プランのデータを一括で処理する業務（検索用データ作成・更新、マーケティング用途向けデータ作成・更新）
- 指定の条件にあった宿泊プランをリアルタイムに処理する業務（予約）
必要な情報の違い
- 検索では指定条件でトータルのポイント付与率、ポイント数がわかればよい
- 予約ではプロモーション単位でポイント付与率、ポイント数がわかる必要がある

これを抽象的に捉えると

バッチ処理として大量のデータを一括で処理する業務
リアルタイムに個別のデータを処理する業務

の2つに大別できることがわかりました。

また、各業務を整理する中で「料金」と呼んでいるものが複数存在していて、呼び名が統一できていないこともわかりました。

宿泊料金（ホテル・旅館が設定した基本料金）
ポイント値引き後の料金
クーポン・ポイント値引きなど、すべての割引を適用した後の最終的な支払料金

などです。これについては、料金の種類を整理してどこでどの料金を使う必要があるのかをまとめました。

3. 本来あるべき料金・ポイント計算ロジックの姿と、現状のギャップは何か（課題）

次のステップとして、それまでの整理をもとに、現状の課題を洗い出して本来あるべき姿を検討しながら、取り組む課題を明確にしていきました。

課題: 宿泊サービスの中で、料金・ポイント計算ロジックが複数のシステムに分散して存在している

長くサービスを運用しているため、新旧それぞれのシステムで料金・ポイント計算ロジックが実装されている状態になっている
- システム移行の過程では避けられない側面もあります
一方で、新しいシステムの中でもロジックは共有しきれておらず、用途によって分けたシステムごとにロジックが分散している状態になっている
- 検索用のインデックスデータとマーケティング用データの作成・更新処理がサブシステムに分かれており、ロジックが共有できていない等

これに対して、本来あるべき姿は、料金・ポイント計算ロジックは1箇所に集約し、各システムから共通で利用できる形にすることと考えて、ロジックの集約に向けた取り組みを行うことにしました。

4. 本来あるべき姿に向けて、現状からどう改善していくか

課題を踏まえて、本来あるべき姿に向けてどう改善していくかを検討しました。改善のステップとして、以下を考えて進めています。

新システム内でのロジック集約・共通化
- ステップ1: バッチ処理として大量のデータを一括で処理する業務内でロジックを集約・共通化
- ステップ2: リアルタイムに個別のデータを処理する業務内も含めてロジックを集約・共通化
システム全体でのロジック集約・共通化
- ステップ3（案）: 既存システムから新システムのロジックを呼び出し、システム全体でロジックを集約・共通化

現状と今後の展望

現在は、ステップ1として「バッチ処理として大量のデータを一括で処理する業務内でロジックを集約・共通化」を進めており、先に挙げた業務のうち

(a) 検索を高速に行うためのデータ作成・更新業務
- 後続の検索業務に必要なホテル・旅館の料金を確定するために必要な情報を非正規化して作成・更新する
(c) 社内でのマーケティング用途向けのデータ作成・更新業務
- 社内でのデータ分析業務に必要な宿泊プランの料金情報を作成・更新する
- ユーザーに送る販促メールなどに掲載する宿泊プランの料金を計算する

の2つの業務を扱うバッチ処理に対して、1つの料金・ポイント計算ロジックを使う形に改善を進めています。今月ようやくプロトタイプが動くようになり、来年1月頃のリリースを目指して進行中です。

リリース後は引き続き、ステップ2を進めていく予定です。