ホワイトレーベルか、自社で予約エンジンを作るか

見積もりが届き、金額はまだ払えなくはない水準です。信頼している開発者が予約エンジンを値付けしました。検索、結果一覧、決済、管理画面がひとつ、期間は三か月。数字自体は法外ではありません。自社システムが欲しいと思い始めてから二年が経っています。ホワイトレーベルか自社で予約エンジンを作るかという問いが実際に決着するのはこの瞬間で、たいていは誤った根拠で決着します。二年目の形ではなく、初月の価格で決めてしまうのです。

その見積もりは誠実です。ただし、目に見える範囲の作業しか含んでいません。

開発見積もりが本当に値付けしているもの

手元に届く見積もりのほとんどは、表面に値段をつけています。検索フォーム、結果一覧、搭乗者情報の画面、決済ステップ、管理画面の予約一覧。その作業は実在しますし、力のあるチームならきちんと仕上げます。しかしそこは、すでに汎用品になった側の半分でもあります。同じ路線を売る二社が決して競争しない半分です。空席画面の行間が良かったからその会社を選んだ客は、いまだかつて一人もいません。

もう半分は、ブラウザからは見えない接続の向こう側にあります。年月が消えていくのはそちらです。

コストは画面ではなく接続の本数で決まる

supplier に接続を申し込んでも、返信メールに API key が入っていることはありません。届くのはテスト環境、certification の手続き、法人ごとに発行される認証情報、ルール文書、そして自分の都合で返事をする担当者一名です。そこからその supplier 固有の方言と付き合うことになります。static rate はこちら、live availability はあちら。free-sale の隣に release period 付きの allotment。エンジンが必ず守らねばならない cut-off。変更に手数料が発生するかを決める fare rule。そして誰の目録とも一致しない ancillary のカタログ。これを、顧客が当然持っていると思っている supplier の数だけ掛け算してください。

接続ひとつはプロジェクトです。六つになれば部署であり、しかも終わりません。その六社のうち一社として、変更をやめると約束していないからです。

見積もりに実際に並んでいる画面の裏側にも、同じ罠があります。検索は一機能に見えますが、二社の航空会社が同じ行程を別の価格で返してきた瞬間、どちらを客に見せるかをコードの中で決めねばなりません。払い戻しはボタンひとつに見えますが、fare rule は違約金と言い、supplier はバウチャーと言い、客はカードに戻せと言います。markup は設定画面の数値ひとつに見えますが、同じ運賃の上で法人顧客に一つの規則、大阪の sub-agent に別の規則、店頭に来た客に三つ目の規則を当てたい日が必ず来ます。

その算数こそ、開発見積もりが落としている部分です。UI と比べた端数の誤差ではなく、それ自体が製品です。ホワイトレーベルのプラットフォームでは、その作業はすでに終わっていて、担当者も付いています。supplier のコンテンツは一件ずつ署名する契約ではなく supplier group を通じて店舗に届き、サイトは実際に売っているものに応じて航空券、ホテル、ツアー、入場券を有効にします。

二年目まで生き残る比較表

この表は買い手ではなく運用者として読んでください。どの行も問いは同じです。誰が背負うのか。

このうち二行は自社開発に味方します。慰めの賞ではありません。売っているものが十分に特殊なら、その二行が上の全部を上回ります。

判断を誤ったときに払うもの

自社開発エンジンの失敗は、崩れ落ちるプロジェクトではありません。崩れるものは目に見えるし、痛くても乗り越えられます。高くつくのは、動いていたシステムがじわじわ止まっていく形です。

書いた開発者は転職し、次の担当者は小さな変更のたびにリスク込みで見積もります。そのコードを通して読んだ人間が誰も残っていないからです。supplier は自分の都合で endpoint を廃止し、予約は監視より先に顧客が気づく形で失敗し始めます。一年目に正しく実装した fare rule は二度と見直されず、その後に来る ADM は委託先ではなく自社の IATA 番号に請求されます。決済の認証情報は期限切れになります。証明書も期限切れになります。二世代遅れたフレームワークは、一週間すら確保していなかったセキュリティの議論に変わります。

どれも請求書の形では届きません。だからこそ、人が実際に行う比較には一度も登場しないのです。それは注意力という形で届きます。火曜日を壊れた PNR に費やした経営者は、その火曜日に何も売っていません。自社開発のあと静かになった会社が静かになった理由は、ソフトウェアが壊れたからであることはむしろ稀です。仕事を取ってきていた人が、いまや仕組みを守る人になったからです。

自社開発が本当に正しい場合

正しい場合は確かにあり、条件は自分と照らし合わせられる程度には具体的です。

• ソフトウェアそのものが差別化要因である場合。旅行ではなく他の旅行事業者に技術を売っているなら、料金を取っている当のものを外部に委ねることはできません。
• すでに技術者がいて、二人目の予算も組んである場合。作る人ではなく、最初の一人が辞めたあとに引き継ぐ保守担当者のことです。後継計画のない自社開発は、手順が増えただけの賃借です。
• 誰もモデル化していない業務を回している場合。自社で客室を押さえ、団体 PNR をビザの進捗に結び付ける巡礼ツアーの事業者は、汎用エンジンがぴたりと合う仕事をしていません。

どちらでもない道もあります。店舗は買い、本当に自分のものである部分だけを作るやり方です。プラットフォームが航空とホテルの API を開いているのはまさにそのためですが、利用はセルフサービスの鍵ではなく相談から始まります。全面開発を決める前に、この折衷案を値付けしてみてください。本当に握りたかったのは、たいていエンジン全体ではなく業務フローひとつです。

そして事業が sub-agent の上で回っているなら、そこもきちんと値付けしてください。与信枠と settlement の請求はここでは一級の概念であって、日曜に誰かが突き合わせる表計算ではありません。自社開発では、最初の見積もりに誰も入れなかった二つ目のプロジェクトになります。

両者に同じ質問をひとつ

何かに署名する前に、開発者とプラットフォームの双方へ同じ問いを投げてください。来年三月にある supplier が certification を変えたら、その作業は誰がやり、誰の期限に合わせ、私はどうやって知るのか。返ってくる答えは似ていないはずで、その差こそが実際に選んでいる対象です。

書類二枚を並べるより、動いている店舗と見積もりを突き合わせるほうが正直な試験になります。確約の前に何が用意されるのかを見たいなら、ウィザードでサイトをひとつ立ててみてください。カードは求められませんし、渡されるサブドメインは自社ドメインを接続したあとも永続的に残ります。