1年がかりの大プロジェクト「 Google で予約」の連携開発を成し遂げた4名の精鋭チーム

人々の生活から、「めんどくさい」をなくす。

というミッションを掲げ、”予約”を切り口にビジネスオーナー・エンドユーザーへ様々な価値を提供しているクービック株式会社。

今年7月、自社プロダクト Coubic が「 Google で予約 ( Reserve with Google ) 」に正式に参画したことを発表しました。スピード勝負でリリースに至った Zoom 連携とは対照的に、今回のテーマは1年近くに及ぶ長期のプロジェクト。まだ日本ではトレタさんやぐるなびさんなど、当時は1桁ほどの企業しか実装していない先進的な事例です！

創業メンバーも含めたエンジニアチームの4名にZoomで集まってもらい話を聞き、 Coubic のよりテッキーな側面を暴いています。ぜひご覧ください！

クービック株式会社

<写真左から順に>
 齊藤 真人
 韓 松煕 (ハン ソンヒ)
 岸本 優一
 伊藤 薫人

「 Google で予約」の価値が未知だったときから早期に開発スタート

ー「 Google で予約」の開発は1年以上の長期プロジェクトと聞きました。そもそもこれはどんな機能の開発なんでしょうか？

齊藤：ユーザーが Google マップから直接店舗を選択し、そのままオンラインで即予約を完結できる機能です。大手メディアから予約するのとは異なり、ユーザーは予約システムの Coubic の存在を意識せずとも Google から直接予約を完結できます。ビジネスオーナーにとっては、 Coubic を利用していれば自動的に Google 検索という有力な集客経路を増やせることになります。（※詳しくは、代表の倉岡が過去のインタビューで語っています。）

ハン： Google と最初に話したのは2018年末くらいでしたね。

齊藤：そのころは、日本では Google マップからの直接予約は広まらないのでは？という懸念もありました。「 Google マップ経由の予約は今月1件だけ」「A店を Google マップから予約したら B 店に予約が入っていた」といった細かいトラブルが聞かれていまして。しかし、それを凌駕するくらいに Google マップの利用数も口コミの件数も爆増していました。

ー中長期的なトレンドを読んだ上での決断だったんですね。

齊藤：ビジネスオーナーであるお客様の引き合いが強かったのも大きいです。 Google 予約対応の話をすると、「すごく興味あります」「ぜひやりたいです」といった前向きな声をたくさんいただきました！最後はその後押しがあって、開発をスタートしても大丈夫だと確証が得られましたね。

バックエンド部分のAPI切り出しという課題解決が、 Google 連携で一気に加速

ー実際の開発はどんなふうに進めたんですか？

ハン： Coubic の既存システムと Google を自動連携させる開発は、大きく3つの構成になっています。

① Feed ： Coubic 内の予約空き時間の在庫情報を Google にアップロードする

② Booking Server ： Google マップ上で入った予約申込を Coubic 内で受付処理 をする

③ RTU ( Real Time Updates )： Coubic 側で Google 以外の経路で埋まった予約情報をリアルタイムで通知する

齊藤：中でも②の Booking Server が一番のコアなところです。そのアーキテクチャデザインや技術選定を岸本が担当していました。

ー開発の手始めにポイントとなったのはどんな点でしたか？

岸本：「 Google で予約」の話が持ち上がる前から、プロダクトのマイクロサービス化が課題になっていました。 Coubic はそれまで6年間ずっと Rails のみで作られていて、バックエンド部分を API として切り出したいと考えていました。

ハン：予約機能のコアロジックがすべて Rails に乗っかっていて、かなり複雑化していたんです。徐々にそれをバックエンドに持っていきたいと考えていたとき、タイミングよく「 Google で予約」の話が持ち上がりました。

岸本：これを機に予約の基盤部分を新しいAPIで作ることになり、それをさっきの①〜③のシステムと連携させる形になりました。

ハン： API は Go で書いていますが、岸本さんがチームにいなかったら Rails でそのまま乗せちゃってたんじゃないかと思います。

ーそこの技術選定は岸本さんの裁量で決まったんですか？

岸本：そうですね。マイクロサービスの基本的な考え方ですが、ある程度サービスごとにそこの選定は自由でいいと思っていて。 Go にした理由は、単純に HOT だったことと、パフォーマンスと保守性のバランスがよかったことですかね。 Ruby とか他の言語の選択肢もありましたが、バックエンド開発には静的な型付けの言語の方がいいと考えました。

ハン： Rails だけの状態では、1行書き換えるだけで全体が壊れちゃうようなバグが起こるリスクがありました。「 Google で予約」の開発を機に、割とキレイにAPIで切り出せたのはよかったですね。

独自に追求してきたものが、国境を超えて確信につながった瞬間

ーこの開発で面白さを感じた点は？

岸本：「 Google で予約」に限らず、いろんなことをゼロベースで考えられて、自由度が高い点です。けっこう大きいシステムになってきて一定の資産もありつつ、1から構成しないといけないことも多い。

伊藤：どうやってログをちゃんと出すか？とか、その辺もまだあまり決まっていないので、そこを自分で考えるのも面白いですね。

ーハンさんはいかがですか？

ハン：基本的に私たちは、6年間自分たちのプロダクトしか扱ったことがなくて。「予約」を扱うデータの持ち方は自分たちで工夫をしてきました。それが、初めて Google との連携にあたりデータやドキュメントを開示しあってやりとりしたときに、その型がすごく似ていたのが面白かったです。

ーデータの型、ですか。

伊藤：一般的な抽象化というか。予約という概念を何かしらのデータベースに入れるときに、どういう持ち方が最適かという話です。例えば予約の重要な概念の1つに「時間枠」があります。12時に始まって13時に終わる、みたいな。 Coubic ではそれを「タイムスロット」という概念として持っています。それが Google 側でもよく似た形で「スロットタイム」という名前が付けられていたりとか。ネイティブの人は「スロットタイム」なのか、と発見があった (笑)

齊藤：プログラムにおいて「名前」はすごく重要です。ファイル名とか、データベースのテーブル名とか。名前は、その業務プロセスをどう抽象化・切り出し・整理するかを如実に反映するので、定義はめちゃめちゃ慎重に時間をかけて行うんです。これは私の推測ですが、 Google が予約という概念を扱うにあたっては、アメリカで Coubic と似たような事業を行うパートナー企業の MINDBODY 社のプログラムを参考にした可能性が高いと思っていて。

ー Coubic の中だけで作ってきた型が、 MINDBODY 社の型 (恐らく) と偶然一致していたんですね。

齊藤：6年以上、国も言語も異なる環境で「予約」という概念の扱い方を別々に追求していたわけですが、フタを開けてみたら同じような形になっていた。これは非常に面白い体験でしたね。

ハン：自分たちが正しいと信じてきたことが間違ってなかったんだな、と思えた瞬間でした。さらに、ディテールで言えば異なる部分も多くありました。 Coubic のやり方よりも、もっと分かりやすい、もっと抽象化できる部分とかを学ぶことができたのも有意義でした。

アメリカの Google 本社と手探りのやりとり…

ー「 Google と一緒にやる」状況ならではの苦労はありましたか？

伊藤：私は、3つ構成があるうちの② Booking Server において、「 Google Mapsから入った予約を変換」「 Coubic 側でも予約確定できたら成功」「エラーになったら Google が決めた方法で返す」といった部分を作っていました。通常の開発はプラットフォーム側 ( Google ) から提供されるドキュメントを頼りに進めるんですが、このドキュメントがあまり信頼できない。そもそも「 Google で予約」自体まだ新しい仕組みで更新自体が活発で、ドキュメントの整備が追いついていなかったり。さらに検証環境が制限されていたので、こまめに自分の実装のフィードバックを得るすることができず、デバックには非常に苦労しましたね。

ハン：確かにテストは大変だったと思います。①〜③の構成それぞれを作るだけでなく、3つが互いに連携する部分もすべて正しく動かなければいけません。 Coubic の中でうまくいっても、 Google 側から NG が出ることもありますし。もらったドキュメントに書かれていない現象が起きることもしばしばでした。

齊藤：通常であれば Google の日本法人が窓口になるケースが多いのですが、今回は諸般の事情でアメリカの Google 本社とメールベースで直接英語のやりとりをしました。 Google 側のまだ発展途上の技術を使っているので、日本語・英語に関わらず正確な情報をキャッチアップするのがとにかく大変でした。ドキュメントの内容が微妙に古かったり、以前もらったものと微妙に挿し変わっていたり……暗黙的なものがいっぱい転がっていて、粘り強く1つ1つ検証して正解を探り続けました。

伊藤：私が2020年1月に入社したとき、この開発はもう走り始めていました。それまでプロダクションで Go を書いたことはなかったんですが、「来週からよろしく」みたいなかんじで渡されまして(笑)。初めはそれこそデバックの方法も訳が分からない状態でしたが、それが大変でもあり面白くもありました。 Go は言語仕様がシンプルなので、 Go 自体の経験に乏しくてもすぐに業務に入れるという点で、岸本の技術選定は正解だったと思います。

「 Google で予約」 はまだMVPでありスタート地点！

ー6年間育ってきたプロダクトの既存機能と、新規開発のバランスを取るのに工夫した点は？

ハン：要件定義の段階で、MVP（ Minimum Viable Product ：実現最小限の製品）というか、一番簡単に早く形にできるようにしました。決済機能やキャンセル待ちの機能など、「あったらいいよね」というプラスアルファの機能もいくつかありましたが、最初はとにかくそれらを切り落として、シンプルなものを早く出すことに集中しました。

齊藤：スタートアップの機能開発の基本として早く出すことは非常に重要なんですが、6年間かけて複雑化した既存機能を壊さないように慎重に考えなくてはいけないのは難しい点ですね。

伊藤：そうですね。連携の開発は、ユーザーさんが250万人を超えており影響範囲も大きいので、けっこう地道にちゃんと作らないといけない。そこをトラブルなく作ること自体もチャレンジングだと思います。

ーそうした意味だと「 Google で予約」は、まだシンプルなMVPとしてスタートしたばかりなんですね！

ハン：もちろんです。決済まで一気通貫で完結できるような改善もしていきたいし、Zoom と連携したオンラインレッスンの導線も Google とつなげていきたいな、とか。

岸本：手をつけられていない部分は多いです。モノリスな Rails 部分自体の改善ももっと加速していきたいし、マイクロサービス化の文脈で切り出すべきところも新しくゼロから作れるところが多く残っていると思います。まだまだやれること・やりたいことがたくさんあるので、引き続きチャレンジしていきたいと思っています。積極的に採用活動を行っているので、応募お待ちしています。