エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン
  • TOP
  • キーパーソン
  • 旬ネタ
  • コラボ
  • ノウハウ
  • 女子部
  • キャリア

ヤフー連携の裏にあった2年半越しの「下準備」とは?トレタ増井雄一郎氏に聞く、企業間コラボの極意【特集:1を100にする開発戦略】

2015/05/20公開

 

株式会社トレタCTO・最高技術責任者の増井雄一郎氏

真に優れたイノベーションが実社会で確固たる地位を確立するには、2つの段階を経る必要がある。まず「ゼロから1」を生み出すフェーズ、そして「1を100」へと成長させるフェーズだ(参照記事)。

今回、エンジニアtypeが特集するのは、ゼロイチで生み出されたプロダクトが“100”へとスケールするために必要な開発戦略。その戦略をヒト・モノ・コラボの3つの観点で捉え直し、成長へのヒントを探り出していく。

ここでは、業界最大手のヤフーとともに、飲食店を悩ませるWeb予約の革新を目指すトレタの事例から、企業間コラボによってサービスを成長させるために必要なノウハウを学ぶ。

Web予約の便利さが生んだ、飲食店を取り巻く「3つの課題」

「ここ数年で、飲食店の予約をWebで行うことが急速に普及してきました。しかしその裏で、これまでとは違った『負担』が飲食店を悩ませているんです」

飲食店向け予約台帳アプリ『トレタ』の開発責任者である増井氏は、浸透しつつあるWeb予約の問題についてこう切り出した。

ここで言う「違った負担」とは、テーブルの予約オペレーションにまつわる負担の増加を指す。消費者からすれば便利なWeb予約も、実は店舗スタッフの多大な作業負担との引き換えによって実現されていたというのだ。

「Webでの予約を受け付けている店舗でも、予約管理は紙で行っているところが少なくありません。電話や店頭で予約を受けることもありますし、常連客がスタッフ個人に対して席の確保を依頼したりすることもあるからです。そこで、各窓口に寄せられた予約情報を集約するため、マスターとなる予約台帳への転記という作業が必要になるわけですが、手作業を前提にしている以上、どうしても転記漏れや誤記が生じてしまいます」

飲食店の評判を著しく損なうオーバーブッキングや予約漏れを防ぐには、テーブルが埋まった段階で、即座にすべてのチャネルで予約受付を停止しなければならない。

しかし、小規模な飲食店にとって、接客や調理を同時に行いながらアラートメールをチェックすることすら難しいというのが現実だ。チャネルごとに用意されている管理画面を開き、刻々と変化する予約状況に対応しながら座席在庫をコントロールするのは、店舗にとって大きな負担なのだ。

「これとは別に、グルメサイト上では満席と表示されている店舗にダメ元で電話してみたら、あっさり予約が取れたりすることがあります。これは店舗側がWeb予約用に割り当てていた一部の座席が埋まっただけで、実は割り当て以外のテーブルが空いていたという時に起こる現象です。これなどは、店舗が座席在庫をうまくさばけていない典型例といえます」

つまり、Webでの予約を受け付けている飲食店の多くは、オペレーション工数の増加と予約事故のリスク、そして効率の悪い座席管理という3つの課題に直面しているのだ。

コラボ戦略で、飲食店が抱える課題を一気に解消

2015年4月、こうした3つの課題解消のため、約2800店の飲食店が導入する予約台帳アプリ『トレタ』と、大きな送客力を持つ『Yahoo!予約 飲食店』が公式に手を結んだ。

2015年4月15日より『TORETA』と機能連携を開始した『Yahoo!予約 飲食店』

『トレタ』を使って予約管理をしている店舗の空席情報をヤフーのサーバと連携させることで、店舗スタッフの手を煩わせることなく、リアルタイムでミスのない予約管理を実現するためだ。

このサービスは、トレタのユーザーであれば月額基本料のみで利用することができる。

「この連携によって店舗側のスタッフは、Web予約にまつわる煩雑なオペレーションから開放され、本来の業務に集中することができるようになります。また消費者にとっては、24時間好きな時に空席がある店を見つけ、簡単かつ確実にテーブルを押さえることができる。これまで横行していた飲食店予約の矛盾や課題を、一挙に解消することができるんです」

予約オペレーションを改善する取り組みは、『トレタ』と『Yahoo!予約 飲食店』の取り組み以外にも、『ebica予約台帳』を提供するエビソルや、『TableSolution』のVESPERなどがグルメサイトからの予約取込機能を提供するなど、各社がしのぎを削る状況が生まれている。

「それだけ店舗側のニーズが大きいということ。以前から、予約メールの自動取り込み機能や、サイトコントローラによるオートパイロット機能を使ったソリューションが存在していましたが、これらはあくまでも簡易的な対策に過ぎません。トレタは企画段階から外部サービスと連携することを念頭において設計をしていたので、APIによる本格的なサービス連携に素早く対応することができました」

飲食店とユーザー。視点が異なれば「情報設計のあり方」も大きく変わる

システム面から今回の提携の裏側について語る増井氏

とはいえ、ヤフーとのサービス連携を実現する上でまったく苦労がなかったわけではない。飲食店側の立場を代弁するトレタと、メディアであるヤフーとでは、情報設計の考え方に大きな違いがあったからだ。

「簡単な例を挙げましょう。飲食店は予約で埋まっているテーブルを詳細に管理する必要があります。しかし、メディア側はユーザーに空席情報を提供できればいいので、テーブルが空いているかどうかさえ分かればよかったわけです」

また、メディア側には季節ごとのイベントやコースの特徴、プレゼントなどの特典の有無、店舗の利用用途など、集客プロモーションに役立ちそうな項目がいくつも立てられているが、トレタは飲食店向けソリューションゆえ、そこまで細かい項目は用意していなかった。

「つまり、同じ 『飲食店予約』という分野でも、立場が違えば必要とするデータ項目はまったく異なるわけです。そのため、お互いの違いを理解し、その差を吸収するための情報設計には、多くの時間を費やす必要がありました」

ただ、今回の提携では、こうしたプロセスもさして大きな障害にはならなかったと増井氏は語る。ヤフーとトレタは、双方のサービスが企画段階だったころに、今日のサービス連携につながる青写真を共有する間柄だったたからだ。

「実は2013年、ちょうど『トレタ』がサービス提供を始める1年前に、ヤフーさんと飲食店予約のあるべき姿を話し合っていた時期がありました。途中、サービスのブラッシュアップのためそれぞれ独自の道を歩んだ期間はありましたが、サービス開始から約1年半が経過し、我々もヤフーさんも、このタイミングなら当初目指していたWeb予約の理想形を実現できると考えたのです。そこで、昨年夏からデータ連携の実現に向けた取り組みに再チャレンジすることになりました」

互いの立場を理解することで、ゴールを共有

仕切り直しから約9カ月。『トレタ』と『Yahoo!予約 飲食店』は、構想から2年半を経てサービス連携を果たす。

リリース直後のため効果が出るのはこれからだが、『俺のフレンチ・イタリアンAOYAMA』や『Eggs ‘n Things』、『恵比寿焼肉kintan』など、これまで大手グルメサイトでは予約できなかった店舗が続々と導入を決めている。

増井氏は、上々のスタートを切れた理由を次のように考えている。

「協業プロジェクトはゴールの共有が一番難しいといわれますが、我々が幸運だったのは、この関門をすぐにクリアできたことです。ヤフーさんとは(トレタの)創業以前から関係がありましたが、ゴールを共有し立場の違いを乗り越えられたのはそれだけが理由ではありません。双方に、相手の専門性や知見に対する信頼がなければ、うまくいかなかったはずです」

トレタとヤフーが共有していたゴールとは、サービス連携を行う際の設定項目を極力減らし、飲食店側の作業負担を可能な限り削ぎ落とすことだった。つまり飲食店の立場を代弁するトレタ側に、ヤフーが歩み寄った形になる。

「ヤフーさんには、仕様変更や追加開発などで、いろいろとわがままを聞いていただきました。彼らが我々の意向を尊重してくれたのは、飲食店側のオペレーションを熟知しているトレタの知見やノウハウを信頼してくださったからです。

一方、トレタ側もこのプロジェクトを通じて、メディアの先にいる消費者が何を求めているのか知ることができたのは大きな収穫となりました。企業間コラボを成功させるには、自分たちの立場や強みを明確にしつつ、相手の専門性に信頼を寄せられるかどうかが重要です。これは相手が大企業であれ、スタートアップであれ、おそらく変わることはないでしょう」

設計に時間を費やすのは「投資」になる

過去3度の起業経験から、スタートアップが将来の「コラボ戦略」をすばやく具現化するための押さえどころを学んだという

最後に、未来あるスタートアップが開発力や資本力に優れた大企業とともに自社のサービスをスケールさせようとした時、注意すべき点を増井氏に聞いた。

「先ほど挙げたゴールの共有と、信頼関係の醸成以外の面で重要なことといえば、サービスづくりを急ぎすぎないことだと思います。確かにサービスを迅速にリリースすることは重要ですが、先送りにしていいものと、先送りにしてはいけないものがあるのは知っておくべきでしょう」

中でも外部連携を想定した設計が重要だと増井氏は言う。

「認証方式やAPIの仕様については、設計段階で注意深く検討すべきだと思います。むろん実装は先送りにしても構いません。ただ、作り急いでしまったがために、いざサービスをスケールする段階になって外部連携にオープンな技術が使えなかったり、いびつな認証方式を採用せざるを得なかったりするという問題は、設計段階で想定していれは避けられるものです」

開発したサービスを一気にスケールさせたければ、ゼロイチの段階で外部のパートナーの力を借りることを前提としたシステムを設計することをお勧めすると増井氏は続ける。

「これは認証方式やAPIに限った話ではありません。もし将来的に営業やサポートなどの実務を外部に委託することが考えられるなら、最初から使用権限を割り振れるようにしておいた方がいい。サービスが成長すれば、現在とは違った状況になるのは確かです。もしそうなった時に正しい対応ができるよう、特に社外との連携を想定しておくことが、『1→100』の成否を分けるポイントになると思います」

設計の初期段階で、将来を見据えたシステムのあり方を時間をかけて検討することは「停滞」ではなく、前向きな「投資」と考えれば、増井氏の言葉に合点がいくエンジニアも多いはずだ。

「僕は過去3度の起業経験で、インフラ部分の設計を先送りにしてかなり痛い目を見ていますからよく分かるんです。もし自分の手で生み出したプロダクトを『100』に成長させたいのなら、設計に十分な時間を費やしてから手を動かしてみるべき。実装はそれからでも決して遅くありません」

取材・文/武田敏則(グレタケ) 撮影/桑原美樹


新着記事

編集部からのお知らせ

エンジニアに人気の求人

エンジニアtype姉妹サイト