main image

【前編】店舗の POS と連携し、モバイルで決済までできるモバイルオーダーシステムを実現する数々の努力

株式会社NTTドコモ
2022.9

EasyEat は NTT ドコモが提供しているモバイルオーダーシステムで、多くの飲食店が利用しています。イートインとテイクアウト両方に対応し、モバイルで決済まで完結するという点が他とは一線を画す特徴です。それを実現するための努力について Da Vinci Studio の EasyEat チームに聞いてみました。

yoshikawa
吉川 崇倫(インタビュアー)
Da Vinci Studio 代表取締役
tuboi
坪井 昭憲
Da Vinci Studio SRE
takahashi
髙橋 真実子
Da Vinci Studio デザイナー
naga
長嶺 澄
Da Vinci Studio エンジニア
hanaoka
花岡 采加
Da Vinci Studio エンジニア
isa
伊佐 大佑
Da Vinci Studio エンジニア

業界でも珍しい “一気通貫” のモバイルオーダーシステム

―― 今日は EasyEat プロジェクトです。まずは自己紹介をお願いします。
では、インタビュー参加経験のある方からいきましょうか。

坪井 坪井といいます。インフラ基盤部で SRE をやっています。今日は何を話したら良いか……。

―― 坪井さん、もしかして前回のインタビューと一字一句合わせに来てます?

坪井 ちょっと何を話したらよいか分かりませんが頑張りたいと思います!

―― これは仕込んで来ていますね……はい、ありがとうございます。

髙橋 EasyEat のデザインを担当していました。デザイン部の髙橋です。 私はプロジェクト開始からではなくて、途中から担当するようになりました。今日はよろしくお願いします。

―― よろしくお願いします。ではここからインタビュー初参加のみなさんですね。リーダーからいきましょうか?

花岡 花岡采加です。サーバー部のユニットリーダーをしています。 EasyEat では途中からプロジェクトリーダーを受け継ぎました。

―― 受け継いだと聞くと、なんだか秘伝のタレみたいですね(笑)。
続いては新卒同期の二人ですね。どちらからいきますか?

伊佐 (伊佐・長嶺二人で顔を見合わせて)えっと今、完全に長嶺さんが格上の感じだったので、僕からいかせていただきます(笑)。

サーバー部の伊佐大佑と申します。新卒で Da Vinci Studio に入社して、初めてしっかりアサインされたのが EasyEat プロジェクト でした。 そこから 2 年くらいずっと触っているので、苦楽を共にしたプロジェクトです。 今日はよろしくお願いします。

―― 今の一瞬で格付け勝負をしたんですね(笑)。はい、よろしくお願いします。2020卒も仲良しですね。

長嶺 サーバー部の長嶺です。私も EasyEat プロジェクトに途中から参加して、花岡さんのご指示のもと、サーバサイドを開発しています。

―― ご指示(笑)。長嶺さんは花岡さんのことをすごく尊敬しているみたいですね。いつかこの二人のエピソードも聞いてみたいです。

では改めて EasyEat について聞かせてください。まずはどんなサービス・プロダクトですか?

髙橋 EasyEat は、一言で言うとお店で注文ができる Web サービスです。飲食店に行くと通常は店員さんを呼ぶ「注文」というアクションを Web サービスを介してできるようにするというものです。いわゆるモバイルオーダーシステムですね。

モバイルオーダーシステムとして特徴的なところは、POS レジシステムと連携をしているところかと思います。 みなさん、何か補足があればぜひお願いします。

坪井 あとはモバイルで決済まで完結するという部分も特徴的だと思います。

―― ありがとうございます。最近は飲食店でモバイルオーダーを導入しているところも見かけるようになりましたよね。他のモバイルオーダーシステムだと POS との連動や決算まで対応しているところが少ないんですか?

花岡 そうですね。POS と連携しているのがそもそも珍しいみたいです。

坪井 決済も珍しいと思いますね。

髙橋 少なくとも利用したものの中では見たことがないですね。

―― なるほど。その POS や決済が珍しいというのは、実現にあたって何か難しい部分があるからですか?

髙橋 やっぱりエンジニアリングが大変なのかなと思っています。詳しい説明はエンジニアに譲りますが、Web サービスと POS と決済という、違う形の複数のサービスを連携しなきゃいけないのが複雑ですね。

もちろんデザイナーとして、技術的な困難性に応じてユーザー体験を設計しなければいけない場面はありましたけど、調査から対応策までエンジニアにお任せの状態だったので、やっぱりエンジニアが一番大変だったんじゃないかなと思います。 だから、これ以上は私がしゃべらない方が良いですね、勝手にしゃべり始めちゃいましたが(笑)。

―― すごい喋っちゃってますね(笑)。技術的な困難性であれば、まずはエンジニアに聞いてみましょうか。

オンプレミスの POS と AWS 間で通信・同期する上での苦労

―― POS と連携するとなると、レジといった物理的なシステムとの連携であったり、POS と通信するところのプロトコルであったり、POS のデータ構造とも合わせていかなきゃならないですよね。
ということは、POS のシステムを自社で持っているか、あるいは持っているところと組むなりしないと実現できないのか。

花岡 そうですね。今回はドコモさんが NEC さんの POS を利用してモバイルオーダーシステムを作るというプロジェクトでした。

おっしゃるとおり、 POS との連携部分は大変でした。まずは EasyEat から POS につなぐところを坪井さんがすごい頑張ってくださって。

―― ネットワークの部分ですね。坪井さん、どういったところが大変でした?

坪井 まず NEC さんのデータセンターと AWS を接続するところからでしたね。 結果的に AWS Direct Connect を使って接続する形にしたんですが、ここは技術的な困難性というよりは三社間での協力が必要不可欠でした。

そもそもどう実現するのかから始まって、仕様の確認・設計の段階からドコモさん、NEC さんと密に連携して進めていきましたね。

―― オンプレミスとの連携というのは、カワスイ(川崎水族館)のプロジェクトでもありましたね。やっぱり大変だったんですね。
ちなみに何のプロトコルで通信してるんですか?

※カワスイ(川崎水族館)についての記事はこちら

坪井 今回は SOAP でやってます。そうですね、SOAP 通信をするための経路を作ったんですが、これはしんどかったですね。 そもそも Direct Connect を使う機会が自分自身、初めてだったというのもあります。

―― なるほど。通信に関しては、アプリケーションレイヤーでは何が大変でした?

花岡 大変だったこと……たくさんありすぎて思い出せないですね(笑)。

伊佐 データの同期が大変でした。POS がメインのデータを持っている一方で、EasyEat 側でもレジ側でも支払えるんです。

だから EasyEat はその決済の状態を同期する必要があり、そこがすごく大変でした。

―― なるほど、それぞれから支払えるんですね。それは大変そうだ……。
実際にはどのように同期してるんですか?

花岡 EasyEat でも POS 側と同じような支払い状態のステータスを持っていて、前回 POS にアクセスしたときとステータスに変更があるかをチェックしています。

―― データのバージョニングですね?

花岡 そうです。他には、例えば支払いが済んだら POS 上で卓(テーブル)情報がクリアされて消えてしまうのですが、EasyEat 側ではデータがあるけれど卓情報が取得できなくなったらレジで支払われたと判断するといったような対応を入れていました。

―― いわゆる楽観的ロックみたいな考え方ってことですね。POS のデータのバージョンが進んでいて齟齬があったら、無効と判定する。
逆に EasyEat の方が進んでいるケースはどうするんですか?例えば EasyEat で決済完了しているのに POS 側に反映できない場合とか。

伊佐 EasyEat から POS の情報を更新する際は、POS 側の API を使って更新しています。通信に失敗したときのリトライ処理はあるとはいえ、どうしても更新できないときは店員さんを呼んでもらうという運用にしました。イートインの場合はお客さんもお店にいますし、お会計のタイミングで基本的にはレジに、つまり POS の前に行くのでそこで整合性を取ります。

髙橋 店員さん呼んでください画面をデザインしました。

―― なるほど、言われてみればそうですね。レジに行けばいいのか。

イートインとテイクアウトの違いと決済にまつわるフォローアップ

花岡 初期バージョンでは決済の機能がなく、支払い時にはレジに行くフローだけだったのでシンプルでした。

とはいえ後から付けた決済機能も、EasyEat で決済してから完了画面を店員さんに見せてお店を出るので、基本的なフローは同じなんです。

当然、整合性を取るためのリトライやバッチ処理といった部分は大変ではあるものの、何か不具合が出たら店員さんに対応してもらえるので、イートインは割とまだ融通が利いたんです。 テイクアウトだと、そういったことができないので大変でしたね。

―― あーそうなんですね。テイクアウトのほうが大変だったんですね。
店員さんによるオペレーションの融通が利かない以外でも、難しい部分があったんですか?

花岡 例えば、支払い方法の中には d 払いのように EasyEat の外部のページに遷移してから支払うものがあります。

外部のページで支払いを中断してしまうと、EasyEat 側では決済が完了したかが分からないんですよね。

中断したならともかく、もし決済した後に画面を閉じたまま EasyEat に戻って来ないユーザーがいると、決済は完了しているのに注文は完了していない状態になってしまいます。 ですので定期的に外部の連携先に支払い情報を確認しにいって、必要があればキャンセルを走らせて返金する処理を入れました。 この辺りは、すごく苦労しましたね。

インタビューの様子
―― あーなるほど。そうですね、決済系だと出てくる話ですよね。

髙橋 EasyEat では、会員登録しなくてもテイクアウトを注文できるという仕様になっています。

ですので、その注文情報をユーザーが消失したときにどう確認するかが大変でした。 会員登録があれば、例えばメールアドレスなどの会員情報と紐付けて確認できますよね。ですが、 そういった会員情報はないので「代わりに注文番号を用意してユーザーに覚えてもらうのはどうだろうか」「いや利便性が売りのモバイルオーダーなのに本末転倒ではないか」というような議論をしていました。

―― 会員登録させずに決済までやってしまうから、ということですよね。

髙橋 そうです。決済が終わった最終的な注文完了の画面にはユーザーの注文番号を表示しています。

これさえ見せれば商品は店頭で受け取れるんですが、最悪の場合、ブラウザを閉じてしまうと、その注文番号すら分からなくなってしまいますよね。

一応、スクリーンショットを保存してくださいと注釈は記載しているものの、こういうケースのリカバリーをエンジニアリングでどうにかできないか、デザインで消失させないようにするにはなど、かなり議論しました。デザインはともかく、エンジニアリングに関しては私は本当に知識不足で、エンジニアのみなさんにいろいろな知恵をいただいてましたね。

―― 最終的には、どうしたんですか?

花岡 照会画面を作りました。電話番号と、自分で設定した照会番号。パスワードのようなものですね。

それを入力してもらうと注文情報を表示できるようにしました。 一応、注文が完了したらメールも送ってはいるんですが、メールアドレスを間違って登録していたら届かないので、完了画面を閉じてしまって、かつメールも届かないというユーザーのリカバリー策としての機能です。

髙橋 ただ、ここまで考えるとやっぱり会員登録があったほうがユーザーとしても良かったのかもしれないですね。

―― なるほど、メールもロストしている場合ですね。これが EC サイトだと、届けるための住所があるからまだしも、テイクアウトだとそれもないですもんね。他のサービスだとどうしてるんだろう?

髙橋 調査した中だと、会員登録が必須になっていましたね。カートに入れるまでは未登録でもできる、決済する段階では必要になるというサービスが多かったと思います。

―― 決済はそのタイミングだったり、今までの話にあるようなロストとの戦いですよね。

飲食店としての特性がもたらす制約に対応

髙橋 考えることが本当にたくさんありますね。ユーザーの手間や、その店の広さはどれくらいかなど。

―― 店の広さ?

髙橋 そうです。例えば、注文は卓の単位で管理していまして、その卓ごとに注文の上限を決めたいという要望が出たんです。お客さんがいたずらで 99 個注文したりすると、お店がすごく困るというリスクがあって。

―― なるほど……その視点はなかったですが、たしかにお店の目線に立つとそうですよね。

髙橋 ただ、やっぱり店舗ごとに一席あたり何名まで座れるというのも違いますし、そもそも注文の上限を決めたら課題を解決できるんだっけということも含め、何度も先方と協議したことが記憶に残っています。でも、こうした部分までしっかりコミュニケーションを取って合意できたのは良かったですね。

―― 結局、上限は設けないことになったんですか?

花岡 「放題予約」(食べ放題・飲み放題の予約)のときだけ上限があります。

―― それこそ無制限に頼まれることを防ぐってことですよね。

髙橋 放題予約の場合は、そういうリスクが高いということで、基準を設けましたね。

――  ケースバイケースというのは本当にそうだなと思いました。個人的な話なんですけれど、学生の頃に居酒屋の調理場でアルバイトしてたんです。
大人数の宴会でテーブルもつなげたりするケースだと、一つのグループで数十人の宴会というのはざらでした。

そこで、例えば焼き鳥のように一人に複数個の注文が出るようなメニューだったりすると、それこそ 100 を超えるケースもありますよね。

髙橋 そうですね。メニューによって制御を分けたり、1 回の注文ごとに上限をつけたりするのはどうかというアイデアもありました。 でも、先方からは「それこそ 20 人位で来店して、最初の食べ物と飲み物も含めたら、すごい数になりますよ」って言われ、なるほどと思いました。 現場の状況をちゃんと想像しないと、良くない結論を出しそうになるという場面は多かったですね。

―― 大事ですね。いやあ、大変だった話がたくさん出てきますね(笑)。

髙橋 個人的な経験上も、大変だったという意味ではかなり上位ですね(笑)。

インタビューの様子
―― 長嶺さんは何か印象に残っているエピソードはありますか?

長嶺 私は、良い意味でも悪い意味でも店舗コピー機能ですね。

―― 店舗コピー?

長嶺 EasyEat で表示するメニュー情報は、店舗の POS にある情報を元に、EasyEat だけで表示する情報を追加しています。

例えば EasyEat 用の料理の写真やアレルギー情報といったもので、各店舗が管理画面から入力できるようになっています。あるとき、チェーン店で「別の店舗のメニュー情報をまるっとコピーしたい」という要望が上がってきました。

これを受けて実装してみたものの、店舗ごとにマスターデータの形が微妙に違っていたり、ある店舗には存在するメニューが別の店舗では提供していなかったりと、イレギュラーなケースが多々あったのがしんどかったですね。 例えば「品川店からコピーしたメニューが本当は田町店でも表示されるはずなのに出てこない」ということがありしました。

―― チェーン店としては同じチェーン店なんだけど、例えば品川店と渋谷店ではマスターデータが違うみたいなこと?
それは大変そうですね。

長嶺 はい。だからそのマスターデータの整合性を取りつつコピーするというところが、すごく大変でした。

―― それはどうやってやってるんですか?気になります。

長嶺 どう説明しましょうかね……ちょっと工程が多すぎて(笑)。ざっくり説明すると、まずコピーする前に、店舗のマスターデータと EasyEat のメニューが一致しているかを調べるんです。

そこで一致していたらコピー可能だよねと判断してからコピーするというのが基本の流れですね。 このマスターデータも、常に POS に取りにいくわけではなくて、EasyEat 側のデータベースに取り込んでいるので、マスターデータが古い可能性もあるんですよ。

インタビューの様子
―― 店舗側で更新してしまっていて、EasyEat 側のデータが古いってことですね。

長嶺 はい。ですので、それもチェック前に最新のものを取得するなど、そうした工程を入れています。

花岡 POS から一部のメニューを削除してから店舗コピーしたら、削除したはずのメニュー情報がコピーされちゃうんだけど……という問い合わせがあって。 データをチェックしてるのに何故だろうと思ったら、そのタイミングでは最新のデータ取りにいってなかった!みたいなこともありました。

長嶺 あと、店舗の POS 自体は制御できないので、例えば本社で管理している方が管理画面で操作している間に、店舗側でデータが消されてしまうというケースもあって。 こういったチェックが大変なんです。

―― なるほどなあ。大変そう。地道な努力の積み重ねですね。

後編に続きます


Da Vinci Studioでは
一緒に働く仲間を募集しています。
詳細はこちら