こんにちは。飲食店向けモバイルオーダーシステム「食べログオーダー」のエンジニアリングマネージャーを務めています福田です。 今回は、エンジニアリングマネージャーとして、食べログオーダー開発で最もこだわっている「絶対に止めない」という取り組みについてお話しします。
目次
はじめに
私達が開発している飲食店モバイルオーダーシステムは、飲食店での入店〜注文〜提供〜会計という飲食店オペレーションの中心となるシステムです。このシステムが店舗様と来店されたお客様の双方にとって飲食体験全体に深く関わる、非常に大きな責任を持つものだと考えています。 モバイルオーダーシステムが使えなくなるということは、飲食店にとっては営業が止まってしまうに等しい非常にクリティカルな問題です。そのため、食べログオーダーの開発チームは「店舗オペレーションを絶対に止めない」ということをミッションに開発をしています。
飲食店モバイルオーダーシステムを取り巻く状況
一言で「店舗オペレーションを止めない」と言っても、その領域は多岐にわたります。 モバイルオーダーシステムはシンプルなwebサービスという領域だけでなく、POSシステムや予約システム、キッチンプリンターやハンディ端末など、さまざまな外部システムと協調しながら店内のオペレーションを回します。 また、利用者も飲食店に来店したお客様、ホールや調理を担当する店員さん、店舗を運営する店長・オーナー様などいろんな利用者がいるシステムです。
そんな中で「システムを絶対に止めない」ではなく「店舗オペレーションを絶対に止めない」というところにこだわって開発しているという事例として、 店内オペレーションのインターフェースの中心となるPOSシステムとプリンター連携という観点、また、店舗オペレーションに問題が発生したときに迅速に対応するためのトレーサビリティに焦点を当てて解説します。
外部接続周りの戦略
POSシステムとの連携
モバイルオーダーシステムと販売管理や決済処理を行うPOSシステムとの連携は、店舗オペレーションとしては切っても切り離せません。POSシステムとのシームレスな連携が、店舗でのモバイルオーダーシステムの利便性を左右します。
そんなPOSシステムとの連携だからこそ、システム上の不都合に対して以下のことを念頭において開発しています。
一例として、情報の不整合が発生してしまうことについて、それぞれどういう段階を踏んで考えているかという例をご紹介します。
POSシステムとはWebAPIを経由して連携していますが、非同期通信によるタイミングのズレや、POSシステム側の処理遅延により、データの齟齬が発生することがあります。 食べログオーダーでは、大きく分けて3つのアプローチを取っています。
- データ齟齬の発生を減らす
- データ齟齬が発生した状態での、クリティカルな操作を防止する
- データ齟齬を認識しつつ、オペレーションを継続する
1.の「データ齟齬の発生を減らす」や2.「のデータ齟齬が発生したまま運用上クリティカルな操作をさせない」については、 モバイルオーダーシステムに限らず、どのようなシステム・サービスでも真っ先に思い浮かぶアプローチだと思います。
1.の例としては、システム的なポーリングに基づくデータ取得とユーザーアクションを起点としたデータ取得の両方を組み合わせる手法を用いています。
店員さん目線でのテーブル一覧表示部分は定期的な自動更新に任せある程度のリアルタイム性で使い勝手を重視、
お客様目線での会計金額の表示というような齟齬を許容できない部分は同期的にデータを再取得することで確実なデータを表示する、といった具合です。
2.の例としては、POSシステムとモバイルオーダーシステム間で金額にズレが生じた場合は、預かり金額に齟齬が発生したまま決済に進むと大きなトラブルに繋がるため、
バリデーションエラーとして店員さんに解消を促すような作りにしています。
そして、特に3.の「データ齟齬を認識しつつ、オペレーションを継続する」に関しては、仕様策定や設計の腕の見せ所となります。
業務システムの場合、データ齟齬が発生した際には、2.のようにユーザーアクションをもって解消するのが基本です。しかし、店内オペレーションの効率化を重視するプロダクトでは、オペレーションの続行を優先するケースもあります。
例えば、何らかの要因でPOSシステムと食べログオーダー間でメニューマスターのデータ齟齬が発生した場合、通常はエラーとなります。しかし、実際にはお客様の注文が通り、調理や配膳も進んでいる状況で、システム上のエラーによってオペレーションが停止すると、お客様や店員さんに大きな影響を与えてしまいます。
そこで「注文調整差分」という特殊なデータ処理を行います。「注文調整差分」とは、POSシステムに存在しないメニューの注文が発生した場合、その注文を特殊なデータ形式に変換し、エラーを回避しながらお会計金額の整合性を保つ仕組みです。これにより、メニューマスター連携に問題が生じている状況でも、店内オペレーションを止めずに続行できます。例えば、POSにしか存在しない新メニューが店員さんによって登録された場合でも、この仕組みにより会計処理が正常に行えます。
こうした仕様は、システム的な整合性と店内オペレーションの円滑化の両面からエンジニアの提案で決めていく必要があります。
iOSアプリとプリンターの連携
もう1つ、店内オペレーション上で重要なインターフェースとして、iOSアプリと接続されているキッチンプリンターからの印刷物があります。 店員さんは印刷された伝票を元に調理や配膳・会計処理などを行うため、店内オペレーション全体の司令塔と言っても過言ではありません。つまり、本来印刷されるべきものが出てこなかった、逆に重複して印刷されたということが発生すると、店内オペレーションとして間違った司令を出すこととなり、プロダクトとしては致命的です。
しかし、iOSアプリケーションと店内ネットワークで接続されたキッチンプリンターとの接続方式上、愚直に実装するとどうしても多重印刷や印刷欠損を発生させやすくなってしまいます。 印刷欠損については、プリンターへの接続失敗やプリンター起因でのトラブルなどイメージがつくと思いますが、 今回は多重印刷発生のメカニズムを例に上げながら、対策についてご紹介します。
食べログオーダーの印刷シーケンス
- iOSアプリが注文の通知を受け取る
- iOSアプリがプリンターを検索し印刷指示を投げる
- プリンターからの印刷完了通知を受け取って、印刷完了ステータスに変更する
- 次回印刷モード表示時に未印刷の伝票が残っていれば自動でリトライを試す
例えば、上記のシーケンス中でステップ2や3のフェーズで、iOSアプリケーションの画面遷移を行ったり、アプリがバックグラウンドに回ったりした際に問題が発生します。
実際には伝票が印刷されているにもかかわらず、アプリ上のステータスでは未印刷のままになってしまうため、
そのまま再度アプリを立ち上げると、再印刷が実行されて二重印刷が発生してしまいます。
実際に食べログオーダーの初期段階のアプリではこの状態に陥り、多重印刷が発生したり、
連続する伝票の一部だけ失敗してしまったがために、一連の伝票がすべて再印刷されるというような事象が発生してしまいました。
その失敗から、現在ではアプリの画面状態とプリンターへの印刷指示は独立して動作するようなアーキテクチャーに変更しました。 また、食べログオーダーでは、1つの注文に対して複数の伝票が別々のプリンターから印刷されることがあります。そのため、各プリンターへの印刷指示をシリアルキューで管理しつつ、特定のプリンターだけで印刷が失敗した場合でも、再印刷時に他のプリンターで伝票が重複しないように改良しました。そうすることで、端末上での状態変化やネットワークトラブルによる多重印刷問題を防止しています。
そして、不具合の発生条件がタイミングや環境に依存するものが多いため、印刷周りについてはiOSエンジニアとQAエンジニアによって涙ぐましい検証と対策が行われています。 印刷中にWi-FiをオフにしたりLANケーブルや抜いてみるといったことはもちろん、大量の印刷データをサーバー上に用意した状態でオンラインに復帰させたり、動作中にDHCPでのIPアドレスの再リースを行ったりと、想定されるエッジケース1つ1つ地道に潰していく作業も大切です。
とはいえ、これらの手を尽くしたとしてもなお、店舗の環境では想定していない事態が発生してしまうこともあります。 その場合は、実際に開発エンジニアも飲食店に出向いてネットワーク調査を行ったり、プリンター製造メーカーにも協力してもらいプリンター内のログを解析したりして対応しています。
店内オペレーションのトレーサビリティ
店内オペレーションを止めないという目標を達成するためには、システムが稼働しているかどうかだけでなく、飲食店の中で使われているという指標を持って確認していくことが必要です。 そのために食べログオーダーでは、エンドユーザーに対してシステムが正しくレスポンス出来ているかだけでなく、クライアント側で問題なく使われているかということを指標に置いています。一般的なwebシステムと同様に、クライアント側でのエラーが発生していないかのトレースはもちろん、印刷開始・印刷完了まで一定時間内で完了しているかどうかまでをメトリクスとして確認できるようにしています。
加えて、前述のようにシステム的な不備が無いことを確認できても、店内オペレーションが止まっていないことは確認できません。 事実、設定を意図せず変更してしまい利用できなくなったり、想定した運用から外れてしまって一時的にモバイルオーダーの利用自体を停止してしまっていたりということも過去にありました。 特に、プリンターの設定に関しては、店員さんが深く理解しないまま誤った設定に変更してしまうということも発生しやすいという実態もあります。 そのため、カスタマーサクセスやコールセンターから店舗のプリンター設定内容を遠隔で確認出来る仕組みや、過去の設定と現状の設定を比較しサポート出来るような仕組みを組み込んでいます。
このようなトレーサビリティ・サポートの仕組みは非機能要件として、ビジネス・カスタマーサクセス要望で実装するだけでなく、 開発エンジニアが店舗内のオペレーションの維持に間接的に責任を持つためにも必要になってきます。
伝えたいこと
以上の実例を踏まえた上で、私達がモバイルオーダーシステムを開発する上で最も重要だと考えていることが「仕様や設計・実装は常にワーストケースを中心に考えること」「システムではなく飲食店体験を開発している」という2点です。
例えば、店舗が忙しい繁忙時間帯こそ、店員さんは早くオペレーションを完了させたいはずです。また、お客様は「食べログオーダー」が使いたくてお店に来ているのではなく、飲食体験を通してその飲食店で満足がしたいわけです。 そう考えると、繁忙時間帯でアクセスが多いからレスポンスが遅くなっても仕方ないよね、ではなくむしろ繁忙時間帯こそ早いレスポンスが価値につながっているということを理解する必要があります。お客様も、食べログオーダーを通して食べたいものをストレスなく提供されることで、満足感を得られます。それがお客様、ひいては飲食店様への価値につながることを忘れてはいけません。
私が入社してすぐに当時の上長から教わった教えとして、技術は手段であって目的ではないという考え方を今でも大切にしています。 そして、プロダクト開発も同様で、システムは1つの手段であって目的ではないということを実感しています。 食べログオーダーの価値とはシステムという手段を使って、いかに店内オペレーションを効率的にするか、飲食体験を向上させるかが本当の目的です。 このことをしっかり理解して開発に臨むことこそが、上で書いた「仕様や設計・実装は常にワーストケースを中心に考えること」「システムではなく飲食店体験を開発している」に繋がることだと考えています。
まとめ
「絶対に店舗オペレーション止めない」という目標のもと、食べログオーダー開発チームが意識していることについてご紹介しました。 POSシステムやプリンター連携など、システム的に私達がコントロール出来ない範囲も含めて、 食べログオーダーとしては飲食店体験を提供しているということを大切にしています。 そのためにも、食べログオーダーの開発チームはこれからも、ワーストケースを中心に考えながら開発して行きたいと考えています。
実際食べログオーダーとしては、リリースから今までの約3年間、店舗で運用が止まるようなトラブルや障害を起こさずに運用を続けることが出来ています。 また、トラブルや障害が起きていないということ自体が、営業や商談の中でプロダクトの1つの強みとして押し出すことも出来ています。
本記事が、プロダクト開発に携わる皆様や、今後食べログオーダーに関わる皆様にとって、少しでも参考になれば幸いです。また、本記事を通して、飲食店に関わる皆様に食べログオーダーにご興味を持っていただければ幸いです。
最後までお読みいただき、ありがとうございました。
