RESTfulなクラウドインフラが宿泊業界を変える。

ProfFUMI

2018/01/12 17:00

Cb

RESTfulなクラウドインフラが宿泊業界を変える。

エルソウル株式会社は2018年1月に Gsuite 及び Google Cloud パートナーになることができました。
クラウドアーキテクトを学ぶ上で、IT導入により恩恵を受けやすい業界が宿泊業界にあることに気が付きました。

多くの人には理解されないかもしれませんが、できる限りリアルな情報(政治的、感情的観点ではなく、あくまで技術的な観点。)を伝えられるように情報を発信し続け、実現していきたいと思います。

 

 

宿泊業界にあるIT化の課題

現在の宿泊業界ではほとんどの宿泊施設が自社の在庫情報をOTA(ホテル予約サイト)などの外部で管理している。

そのために90%以上の宿泊施設がデータベースを複数点在した場所に持っている。

(日本でのクラウド化は全体の5%しか進んでいない)

これによりどのような問題が起きるかというと

欲しいデータまでの距離が遠い。データを探すコスト、データを管理するコスト、

様々なコストが産まれている。データベースを操作したことのない人では想像しにくい領域なのでそのコストを数値に置き換えて考えていきます。

 

 

ケース①

 

課題:2020年4月21日の801号室の料金を500円安くしたい。

 

(1)現状のケース

ログインページに移動 → ID&PW入力 → 部屋管理トップ → 在庫料金一括 → 2020年4月を選択 → 4月21日を選択 → 料金を500円低く書き換え → 更新

8回行動が起こります。

これを 数値8 とします。

もし在庫連動システムを入れていない場合は手動での動作数が

(OTAにより数値が若干上下します)

8  ✕  OTA数

複数店舗ある場合は

8  ✕  OTA数  ✕ 店舗数

と膨大に膨れ上がります。

仮にOTA数を3とし、店舗が5店舗あるとすると

数値120

数値120とします。

※在庫連動システムがある場合でもRESTではない場合、バックグラウンドで同じ回数動作しています。

 

(2)RESTful構成の場合

「2020年4月21日の801号室の料金を500円安くしたい。」という情報を持ったデータを送信 → 完了

数値2

たったこれだけで済みます。

同様にOTA数を3とし、店舗が5店舗だとしても

欲しい情報のデータを一つにまとめて送ることができるので、

数値は変わらずに数値2のままです。

つまり、すべての情報が一度投げかければ返ってくる。これがREST構成のイメージです。

OTA数3, 5店舗という同じ取扱データ量にもかかわらず

数値118の差が開いています。

これは日本全体で膨大な不要なコストを産み続けていることになります。

 

OTA問題の1番よく聞く根本的な問題点として、

手数料が高い

という大きな問題がありますが、(相場では15% ~ 25%などのコミッション)

クラウドアーキテクトの構成をRESTに変えることでコストの数値を大きく減らせることがわかります。

 

このRESTな構成を制御するのがAPI(アプリケーション・プログラミング・インターフェイス)と呼ばれるものです。

フォーマットに沿って質問を投げてくれれば必要なデータを1回で返してくれるものです。

様々な便利なAPIが現在では提供されています。

例として楽天市場では在庫管理のためのAPIを有料で公開しています。

 

ここでふと思います。

APIを使うには使用料を払うのが一般的です。(現在ではほとんどが無料提供)

ところが宿泊業界ではどうなっているでしょう。

データの根源は部屋の在庫。その在庫のデータを1番最初に持っているところは宿泊施設の現場。

ホテルからデータは湧き出ているのです。

現状はどうのような流れになっているかというと、

部屋の在庫のデータが様々なOTAにデータが流れ、そのデータを使うために手数料を支払っている状態になっています。

もし、すべてのデータを一つのクラウドで管理し、サーバーレスでRESTfulなインフラを作ることができれば、

「規則に沿ったフォーマットでリクエストをくれれば部屋の在庫を提供してもよいよ。」と。

データの一般的な取扱の流れに沿えば、楽天市場のようにAPI使用料を逆に宿泊施設が受け取っていてもおかしくはないインフラ環境になります。

 

アフィリエイトで言えば、

自社の商品をどこかのブロガーが紹介して売ると、

紹介料として数十円支払いが行われますね?

 

自社の商品は部屋の在庫です。

ここでデータの流れに違和感を感じました。

 

流れが逆になるんじゃないか。と。

 

上記で述べた数値の差分の「負のコスト」を持ち続けるよりは、RESTな構成に変えたほうが、

より健全な日本の宿泊施設の在庫データ構成がとることができ、

日本全体でインバウンドの活性化につなげることができるのではないかと考えています。

2020年 東京オリンピック、ますます国際化が早まる社会の中で、

データインフラを整えることは避けて通れない。

REST化が日本で進むまでには数十年以上かかるかもしれないし、一瞬で変わるかもしれない。

弊社では「RESTfulな構成を如何にに低コストで提供できるか」についてコミットしていきます。

次の章では実際にRESTfulな構成を取るには何が必要か?など

より詳しく触れてみたいと思います。

 

※RESTfulとは

REST - REpresentational State Transfer (REST)

RESTは、インターネットそのものやWebアプリケーションなどの、

分散・ネットワーク化されたシステムやアプリケーションを構築するためのアーキテクチャのスタイルの1つです。

リレーショナルデータベースの動作は主に4つです。

・作成(Create)

・取得(Read)

・更新(Update)

・削除 (Delete)

これらの動作をCRUDと呼びます。

 


 

 


Prof
FUMI

得意な技術:バックエンド。データベースデザイン。オートメーション(自動化)。 主なスキル:Golang / Python / Ruby / Node.js / PHP / JavaScript / AWS / GCP

コメント