main image

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

株式会社NTTドコモ
2022.9

EasyEat は NTT ドコモが提供しているモバイルオーダーシステムで、多くの飲食店が利用しています。イートインとテイクアウト両方に対応し、モバイルで決済まで完結するという点で他とは一線を画すものになっています。前編では POS と連携するための同期の仕組みや、会員登録なしで決済する際のフォローアップ、飲食店特有のオペレーションへの対応について聞きました。

前編はこちら

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 エンジニア

高いセキュリティ要件をクリアする

―― インタビューの前にみなさんに回答してもらった事前アンケートに、たしか個人情報の管理も大変だったという話がありました。

髙橋 そうなんだ。

花岡 そこは伊佐くんですね。

伊佐 そうですね。大変というか、当時は自分が経験したことがなかったので勉強になったという話なんです。 注文に関する個人情報はデータベースに保存する際に暗号化していまして、それを検索したいという話があったんです。

インタビューの様子

例えばユーザーさんから問い合わせがあったり、リクエストがあって削除したい場合ですね。 今回は完全一致で検索できるようにしたかったんですが、最初どうやったら良いか分からなくて。 セキュリティ人材の会で相談したんです。それで僕があまり分からず初期化ベクトルを固定したらいけそうなんですけどって言ったら「それはだめだよ」と指摘いただきまして。

マッチさせるだけなら、一方向ハッシュ化しておいて、その値を比較すればいいんじゃないかというアドバイスをもらいました。

―― そういえばそういう話をしていましたね。パスワードのマッチと同じような考え方ってことですよね。

伊佐 はい。実装に悩んだタイミングで相談できたのは良かったです。

―― セキュリティ人材の会が機能してますね。良かったです。
セキュリティ関連だと、事前アンケートで WAF(Web Application Firewall)からボディを返すというメモがありました。これはどういうことなんですか?

坪井 それは僕が書きました。 AWS WAF にはブロックした際に任意のレスポンスを返すカスタムレスポンスという機能があり、そのことについてですね。

―― リクエストが特定のルールにマッチした時に、あらかじめ設定したレスポンスを返すことができるというものですか?

坪井 そうです。それを利用して許可した IP アドレス以外のアクセスは、「オープンまでお待ち下さい」というメンテナンス画面を容易に出せるようになりました。サービスオープンの際は WAF の設定を変えるだけで良かったので、この機能に感動しました! AWS で新しく入ったりアップデートのあった機能を EasyEat で試すことも多かったです。

―― おお、他にはどういった機能を試したんですか?

坪井 あと印象に残っているのは……これはアップデートというわけではないんですが、レジストラを移管しました。 セキュリティ要件として、DNS キャッシュポイズニングに対応しなければならなかったんです。 DNS キャッシュポイズニング対応として DNSSEC(DNS Security Extensions)を使いたかったのに、AWS では jp ドメインが対応していませんでした。

―― え、AWS は対応していないんですね。どこに移管したんですか?移管先も指定されていたんですかね。

坪井 AWS でも機能としてはあるものの、jp ドメインが対応してなかったんです。 対応しているところを探して、JPDirect に移管しました。

―― JPDirect。なるほど。このセキュリティ要件は ドコモさんのレギュレーションなんですか?

坪井 そうです。開発するプロダクトに応じて、ドコモさんの方で細かくセキュリティ要件が決まっていました。

―― さすがですね。

坪井 ええ。でもそれらすべてに対応するのは非常に大変でした。

―― 内容的にはどんなものだったんですか?

坪井 最初、見たときは「これ全部やるの?」って思いましたね。

インタビューの様子
―― 違う違う(笑)。そういう感想じゃなくて。どういった要件の内容だったかですね。

坪井 そういうことですか。まずセキュリティ要件は、ドコモさん側でサービス仕様に応じてレベルが設定されていました。 EasyEat の場合、当初の仕様だと個人情報を取り扱っていなかったので、比較的セキュリティ要件が低かったんです。低かったわけではないな(笑)。比較的、厳しくはなかったというか。

ただ、テイクアウト機能の導入に伴って個人情報も取得するようになったので、セキュリティ要件が上がりました。ドコモさんの中でのレギュレーションでも最も高いレベルまで上がったんです。それに伴って個人情報の暗号化や、情報資産にアクセスする際の証跡ログなども整備していきました。

―― おお、さすが。しっかりしていますね。

坪井 さすがでした。ただ、大変でしたね(笑)。 「こういう場合はこういうところまで実施すること」というようなチェック項目があり、その一つ一つを満たしているかを調べていくのが大変でしたね。 百数十ぐらい……もっとあったかな。すごく多かったです。

―― いやあ、大変そうですね。セキュリティの話だけじゃなく、ここまでの話も含めて。
ただ、良い大変さというか。「それ意味あるの?」みたいな話ではなくて、注文の話も POS との連携も、現実の世界に対応するための難しさですよね。

飲食店の現場を想像してデザイン

―― ここまで技術的な困難性について話してきましたが、デザインはどうでした?

髙橋 そうですね。最も印象的だったのは、飲食店側の管理機能ですね。業務の中で使っていただくにあたって、落ち着いて画面を触れられないスタッフに向けてのインターフェイスを作るのが難しかったです。

―― 落ち着いて触ることができないというのは?

髙橋 例えばこれまで一般的な管理画面を作るときは、デスクワークしている方を想定して作ることが多かったんです。飲食店の方だとバタバタと他の作業をしながら管理画面を触るとか、他の業務をしているので管理画面を見ていないということが頻繁に起こるということですね。

―― なるほど。お店で働いているスタッフが対象だから、ということですね。

髙橋 そうなんですよ。例えば注文が入ったことをスタッフに知らせるときも、最初は管理画面に新着情報のアラートを表示するという UI を考えたんですが、「普段、画面を見てないんですよ」と言われてしまいました。話を伺うと、POS から注文情報がプリントアウトされ、それを見ているということだったんですね。

じゃあ注文が入ったら POS 経由でプリントアウトすれば良いのかというと、そうでもありませんでした。テイクアウトの場合は注文が入ったその瞬間ではなく、 受け取りから逆算してちょうど良いタイミングでプリントアウトされるのが理想だと。

お話を伺うとそのとおりだなと思いました。どういうユーザーが使うのかをちゃんと想像しないといけないことを改めて実感しました。

―― プリントアウト!そうそう、今またアルバイト時代の記憶が蘇りました。
注文が入ると、据え置きの端末からピーという音がしてプリントアウトされるんですよね。
ピークタイムのときは、どんどん注文が入るから紙が伸びていって風になびき始めるんです。
インタビューの様子
ただ、紙ってすごいなと感じるのが、これ組み替えたり持ち運んだりできるんですよ。
小さなトレーに水を張ってその中に置くと飛ばないし、注文の種類ごとにまとめたりできるんです。

さらに水に濡れているからホールの人にわたすときにペタっと貼り付けられたりもします。
飲食店の現場では、紙っていう情報媒体はすごく便利だった記憶があります。

髙橋 面白いですね。この話を最初に聞いておけばよかった。一番最初にユーザーインタビューすべき人が実は近くにいましたね(笑)。 意外だったエピソードだと、キーボードを出すのが億劫という話もありました。

―― キーボード?

髙橋 はい。タブレット端末のキーボードですね。 iPad を利用しているお店は多いだろうとは想定していたんですが、考慮できていなかったのが、お店で使う前提だとキーボードを出して文字入力するのが煩わしいということなんです。

言われてみれば確かに、と感じましたね。だから、例えば人数を入力するときは左右をタップすれば人数を増減できるようなUIにして、忙しいスタッフの方々の入力が簡単になるような UI に配慮しました。

―― なるほど。それは言われて想像してみたら確かにそうですね。
やっぱり自分たちが普段よく使うデバイス、使い方でイメージしがちなのは危険ですね。

髙橋 そうなんですよね。それこそ使う方の IT リテラシーだけではなく、使っている状況がそもそも違う点が、これまでの案件とはかなり異なっていました。 PCが 置いてあったとしても、その部屋自体がすごく狭いと聞きましたし。

―― 従業員用の執務室ですよね。休憩室とかも兼ねてたりして、すごく狭い。

髙橋 本当に良い経験になったと思います。 とにかくユーザーに対する自分の想定が足りてないんだなということが、このプロジェクトを通じてよく分かりました。あと全体を理解していないと、デザインってできないなと改めて痛感しました。

私はこのプロジェクトに途中から参加したこともあって、最初は POS との連携あたりをまったく理解していなかったんですね。 一般的な Web サービス同様に、Web サーバー上で完結すると思っていたら「このデータは取得できないので画面に表示できない」と指摘が入るなど、エンジニアに何度も聞くことになってしまいました。背景から説明してもらって、やっと全容を理解できました。

これまでのプロジェクトだと、全体を分かっていなくても、都度エンジニアに聞けば大丈夫かなぐらいで思っている部分もあったんです。 けれど、こういう複雑なシステムだとデザイナーが理解していないことによるロスは大きいと、このプロジェクトで強く感じました。

インタビューの様子
―― デザインの中でもプロダクトデザインのレベルになると、コンピューターサイエンスをきちんと理解してないとできないっていいますしね。

髙橋 本当にそうです。理解していないとできない。私が甘かったです(笑)。

花岡 でも私は今回、本当に髙橋さんに助けられていました。 レシート機能は特に髙橋さんのデザインに救われたなと思ってます。

伊佐 そうそう、すごく実装しやすかったです。 Figma 上のデザインがとにかく分かりやすかったですね。

髙橋 自分で言うのもなんですが、 Figma 好評なんですよ、すごく(笑)。 まぁ、とても心がけている部分でもあるので。伝わるといいなと思ってはいますが、分かりづらい点はどんどん言ってくださいね。

エンジニアの皆さんも、すごくいろいろなところに気づいてくださるんですよね。 デザインが足りていない部分や、エラー時の対応など。

セキュリティと同様、ドコモの方もエラーハンドリングはすごく厳しく見てくださるんですよね。 さっき長嶺さんがいろんな異常ケースに対応していったという話、長嶺さんの方からこういうエラーとこういうエラーのデザインが足りていないですというのを教えてくれるんです。 そういう面でもお互いの努力によって実現してきたなと感じます。

―― 良い経験になったみたいですね。

振り返ってみて、またトライするとしたら

―― 髙橋さんが良い感じに学びについてしゃべってくれたので、最後に皆さんの学びについて聞かせてください。
坪井さんはどうですか?

坪井 そうですね、先ほどの jp ドメインの話題のように、サービスのドメインを決定するフェーズから、セキュリティ的な観点でその意思決定で良いのかというのを考えたいですね。 結局、今回は後からドメインを移管することになってしまいました。

あとは私自身が初挑戦のこともあって、例えばネットワークに関しては当初 POS との接続をすることばかりに気が向いていて、Direct Connect の冗長構成などは後回しになってしまっていました。そういう部分まで加味した設計を、あらかじめできるようにしておきたかったです。

―― 良いですね。今回ので結構引き出しも増えたと思いますし、次のプロジェクトに期待ですね。
花岡さんは?

花岡 カンニングしていいですか?実は昨日、みんなで書いたんですよ。

―― すごい、準備しっかりしてますね。さすが花岡組。

髙橋 さすが。参加すればよかった。

花岡 大変だったことというか、やり直すならという視点ではこの後に改修しやすいコードになっているかというのを意識して整理するような改善を入れられたら良かったなと思っています。

今日、話してきた通り仕様が複雑なので、コードも複雑で条件分岐も多いんですよね。 そのためどこかに改修を入れると、別のどこかで変更や考慮が漏れてしまったりということが多かったなと感じるんです。

―― 今日の話だと、当初の開発チームのみんなが見えていないユースケースや使い方もあったりしましたよね。

花岡 そうなんです。開発しながら見えてきたことも多いので仕方ない部分もあるものの、当時はその場をしのぐ対応にならざるを得ないことも多かったんです。 なので、定期的にそういう整理をやれたら良かったなと感じます。

―― そうですね、ある時点ではきれいな設計になっていても、その後に開発が進むと変わってくる部分もありますからね。
長嶺さんはどうですか?
インタビューの様子

長嶺 私は今からやり直すなら最初から React を導入したいですね。 例えば、メニューをドラッグアンドドロップで並び替えができる機能がありまして、この機能はイートイン版では素の JavaScript で実装されていたんです。

ここのテイクアウト版を実装するときに React を採用していたら大分、楽になったんですよね。 先ほども出た管理画面やキーボードをあまり出さないといった UI の部分も含めて、最初から React を導入しておけばもっと序盤から動きがあって使いやすい UI にできたかもしれません。

花岡 微妙に共存していた時期が一番、辛かったですね。画面の上部は素の JavaScript で動いているのに、画面の下部は React で実装されていたりしていました。私の前任の方が思い切って導入してくれたんで、そのおかげで今みんなが楽をできているなと思います。

髙橋 確かに。そのあたりは汲み取りながらデザインやってましたよ。

花岡 本当に助かっていました。ありがとうございます。

―― なるほど。みんな React には大分、慣れたみたいですね。
Da Vinci Studio でも使い始めた初期こそ皆おっかなびっくりだった印象がありますけど、今では他のプロジェクトでも、かなり増えましたし。

花岡 確かに最初はちょっと怖かったですが、慣れると便利ですよね。

伊佐 自分が反省点として今後、考えなきゃなと思ったのはユーザーの使い方をしっかり理解することですね。それ自体は当然のことではあるものの、今回それが不十分だったなと感じています。

例えば POS で操作した後に EasyEat の管理画面からシートを発行するというフローがありまして、当初は自分は EasyEat の画面からの操作だけしかイメージしていませんでした。POS の方まで含めた想像が働いていなかったんです。

そのため実際の使われ方と乖離が出てしまったこともあり、使われ方をリアルにシミュレーションしないといけないなと痛感しました。

―― さっきの髙橋さんの話と通ずる部分ですね。ユーザーファーストで重要なのは、まさにそこですよね。
ちゃんとユーザーのことを見て、しっかりと使い方を想像する。これも良い経験ですね。

みなさん今日はどうもありがとうございました!

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