dinii と POS 連携
こんにちは、株式会社 dinii で VP of Technology をしている @karszawa です。
この記事は dinii プロダクトアドベントカレンダー n 日目の記事です（ただし n は自然数とします）。
本日は 10X 社と Chompy 社の POS 連携の記事に触発されて ※1 ダイニーの POS 連携について語ってみたいと思います。
まず初めに断っておかなければならないことがあります。それは、上述の2社と違い、私たち dinii はそれ自体が POS を開発しており、「dinii と POS 連携」という言葉は「私たち dinii 側が POS という立場でそれ以外のサービスと連携する」ということを意味します。
それならわざわざ2社を引き合いに出す必要もないのでは？と思われるかもしれませんが、そういった大前提の違いがあるにも関わらず dinii の連携開発と上述2社（特にドメインも異なるはずの 10X 社）の連携開発は面白いほど似通った部分があります。
というわけで dinii の連携開発について、上述2社との関連を交えつつ解説を試みたいと思います。
なぜ自分たちで POS を開発しているのか
飲食のドメインでサービスを開発するにあたって POS を無視することはできません。
「自社開発する」
「連携開発する」
これ以外の選択肢は無いのです。
dinii は、サービス開始当初はそれらの選択肢のどちらが適切なのかを判断しきれず、両方の手段に同時並行でリソースを投下していました。ですが、最終的には外部 POS 連携を諦め、自社の POS の開発に全リソースを集中するという意思決定を行いました。
外部 POS 連携を諦めた理由はいくつもありますが、簡単にまとめると下記のとおりです。
連携すること自体は顧客価値とは遠く離れたところにあるにも関わらず、開発や会社同士のコミュニケーションの面で非常にコストフル
とりあえず連携することで得られる顧客価値とは、飲食のドメインで言えば「注文できる」「会計できる」といった当たり前のことだけです。私たちが顧客に提供したい価値はそんなところは大前提とした上で成り立つものでした（こちらはまた別の記事で紹介できれば…）。
市場を支配している POS がレガシー（開発が大変）、かつ大企業（コミュニケーションが大変）なので、大きなパイを狙いたければ茨の道を突き進むしか無い。
外部 POS との連携が前提だと、対応する POS を導入している店舗にしか導入できない
サービスとしての市場戦略が「外部 POS の連携先を増やしていく」ということになってしまい、これまた顧客価値への投資ができない。
メニューマスターと売上データという飲食において最も基盤的なデータを他社に依存してしまう
dinii はモバイルオーダーを作りたいのではなく、モバイルオーダーを入り口としてすべての人の飲食体験を一新したいと考えているのにコアとなるデータを抑えていないのはおかしい、と考えている。
もちろん、自社開発にも新規参入を拒む相応の厳しさがあり、どちらの選択肢を取るべきかの事業的な意思決定は簡単なものではありません。自社開発の難しさも紹介しておくとこんなところでしょうか。
レガシー POS が50年かけて構築してきた「当たり前品質」が機能面でも非機能面でもシビアに存在しており、それらの開発に投資しなければならない時間は外部 POS 連携開発に必要な時間に勝るとも劣らない
モバイルオーダーという新しいオペレーションをプラスアルファで導入するわけではなく、既存 POS で成立していたオペレーションを塗り替える必要がある = より競争が激しい
dinii と外部連携
（ただし BI まで顧客情報が流れていない）
というわけで自分たちで POS を作っているわけですが、もちろん一切の外部連携から開放されているわけではありません。むしろシステムとしての一丁目一番地を抑えているため、ありとあらゆる周辺サービスとの連携を求められてしまいます。
とはいえ、自分たちがデータを提供する側なので、開発の主導権を握ることができたり、周辺サービスの仕様を把握することで今後の新規プロダクトの方向性を検討することもできています。とにかく、中心を押さえることのメリットは大きいです。
現時点で連携している周辺サービスは、種別としては BI, 予約, 勤怠（開発中）で、特に BI システムとの連携需要は大きいです。この記事でも BI との連携について解説します。
飲食 BI の特徴
まず、飲食のドメインにおける BI とは何を指すのかを説明します。一般的に BI といえば Looker や Tableau などの製品に代表されるような汎用的なデータ分析のツールが想起されると思います。
飲食では大きく事情が異なり、そういった汎用的なツールが使われることはほとんど無く、飲食店の経営に特化した専用の BI が広く流通しています。
飲食専用の BI の市場は大きく、導入店舗数数千という大きなプレイヤーが 3,4 社で、それ以下の小中規模のプレイヤーが乱立しているという状態です。個人的には、飲食店業務の多様さと、それに適応するためのカスタマイズに対するニーズの大きさからこのような形態になっていると予想しています。
ツール自体の要件は突き詰めるとシンプルです。具体的には下記のような機能が BI としては要求されます。
売上としてメニューの出数・時間帯と支払い情報が確認できる
コストとして仕入れと勤怠（勤怠・シフト管理ツールと一体化していることも多い）の情報が連動している
曜日・時間帯ごとやメニューごとのパフォーマンスが確認できる
BI との連携基準
上述の通り、飲食の BI ツールは無数にあるため、それらすべてに愚直に対応していくというのは現実的ではありません。ではどうするかと言うと、基本的には飲食店側の要望に従って連携を増やしているのですが、そこで厳格な基準を設けています。
まず、上述の導入店舗数数千という大きなプレイヤーはすでに連携しているか、連携の話を進めているので、基準が適用されるのは比較的小規模な BI のみです。小さなプレイヤーに対しては顧客獲得のアップサイドと開発工数のダウンサイドを比べた上で合理性を判断し連携を開始します。ある時期以前は、その時々の開発リソースの空き具合で何となく連携先を判断していたのですが、それだと開発しても数店舗にしか使われず新規顧客の見込もない（その一方でメンテナンスコストは永続的に発生する）という状況に陥ってしまっていました。
現在の体制では、開発組織として無制限に工数を割かないようにしつつ、完全に連携をシャットアウトするという状況も防ぐため、連携開発のみに集中する専用の小規模なチームを編成しています。小規模なチームなので、少しでも不測の事態が発生すると予定していた開発日程を達成できない（計画の弾力性、縦深性に乏しい）のですが、そこは逆にハードなデッドラインの連携は初めから受注しないというところでバランスを取っています。
ダイニーとしての価値は顧客データを元にした飲食店の売上の向上であり、それに対する BI 連携の貢献は正直なところ大きくは無い（そもそも一般的な BI には dinii として面白みのある顧客データが一切連携できない）ので、売上向上の方にプロダクトを尖らせるため一定以上のコストを割かないという方針を取っています。
具体的な開発工数に関しては、該当 BI が飲食業界で広く流通している ●●● 社フォーマットという飲食業界のデファクトスタンダード的なフォーマットに対応しているかどうかが大きな分岐点となります。その BI が ●●● フォーマットに対応していれば開発工数は低く抑えることができ、そうでなければフルスクラッチのため工数は大きくなります。ちなみに現状では ●●● フォーマットが 5 BI (見込み 7 BI) でそれ以外が 2 BI (見込み 3 BI) 対応しています。
BI 開発の流れ
前提の説明が多くなってしまいましたが、ここから連携開発の流れについて説明します。
飲食業界に ●●● フォーマットというデファクトスタンダードが存在しているのは非常に大きなメリットです（本当にありがとう ●●● さん）。
とはいえ基本的にはカラムレベルの定義があるのみ、かつ自由なフォーマットのカラムもあるので、そこに何を入れるかは POS 次第かつ BI 次第です。具体的には A という BI ではカラム X と Y の合計値が一致している必要があったとして、別の B という BI では何の制約もない（そもそも利用すらしていない）という事態は日常茶飯事です。異なる BI 間のインンピーダンスミスマッチがどれぐらいあるかは経験則でしか語れませんが、少なくとも何の問題もなく連携できた BI は存在しません。
BI 開発は dinii の既存データを用いて「取り込み試験」を行うところからスタートします。取り込み試験では dinii 流 ●●● フォーマットの CSV を BI 会社に渡して実際に取り込めるかどうかをテストします。一発では間違いなく取り込めないので、微調整を繰り返しつつ dinii フォーマットと該当 BI フォーマットの差分を明らかにします。仕様書が整っていればそんな面倒なことをしなくても良いのではと思われるかもしれませんが、世の中には仕様書に書き下ろされない仕様というのが必ず存在します。実際に連携してみることで分かることは多いです。
無事に連携できるフォーマットを特定できたらその仕様でプロダクト側の実装を進めます。ここで重要なのは、発見された差分が ●●● フォーマットとして標準的なもので単に dinii が対応していないだけのものなのか、それともその BI 独自の仕様なのかということです。
その仕様が ●●● フォーマットとして標準的なものであれば、それ以外の ●●● フォーマットの BI にもフィードバックする必要があります。既存の BI は連携の実績があるとはいえ、正しく反映できていなかったデータを既存顧客がたまたま参照していなかっただけという可能性もあります。というか経験則的には9割方 ※3 はそういった事情です。
ある特定の BI の修正内容の影響範囲が他の BI にも及ぶということは、それらすべてで取り込み試験を再実施する必要があるということです。現状では5社に対応しているので、これから新しい BI を追加したい際は既存5社でも取り込み試験を実施する必要があるのです。
もちろん、そういった対応がコストフルであるというのは確定的に明らかなのですが、これまでの顧客がたまたま利用していなかったデータ（これからの顧客が利用する可能性のあるデータ）に対応しつつ、コードの分岐を減らしメンテナンスコストを下げられるというメリットには変え難いです。
具体的な試験方法
上述の取り込み試験に加え、更にいくつかの層でのテストを実施しています。実際の売上を用いてスナップショットテストを実施したり、連携試験用の仮想的な店舗を契約してアップロードのテストを行ったりといった具合です。
それぞれ長短があり、特性としては以下のとおりです。
取り込み試験
フォーマットの確認には最適だが、外部 BI 会社との人間的なコミュニケーションが必要で時間がかかる
先方の都合もあり取り込めたかどうかの確認に時間がかかることもある
スナップショットテスト
変更がないことは確かめられるが、変更されたものが取り込める保証にはならない
テスト店舗でのアップロード試験
取り込めるかどうかまでは確認できるが、そもそも FTP での連携なのでシステム的にエラーを拾うことができない
BI の Web コンソールからデータが反映されているかを人力で確認するため面倒くさい
値が妥当なものであるかどうかは各種 BI の知見が薄く、実際に店舗を運営しているわけでもないので数値の妥当性を網羅的に確認するのは難しさがある
連携開始後のメンテナンス
ここまでで確認できたのはアップロードに際してエラーが発生しないことと、それらしいデータが表示されることの BI 会社側での確認のみです。本当に適切なデータが連携され、利用できる状態になるかどうかは、実際に運用してみなければ分かりません。
また、実運用を開始するとファイルの連携は FTP で行われるため、ファイルの中身に関するエラーレスポンスを受け取ることはできません。これが HTTP API での連携であればどれだけ楽だったか…。実は取り込み試験に際して BI 会社での確認が必要なのも連携が FTP で実施されるからです。FTP はあくまでファイルアップロードのプロトコルであって、そのレスポンスは「ファイルのアップロードが成功したか否か」のみなのです。
運用を開始してからも状況は変わらず、本当に正しいデータを顧客が確認できているかどうかは顧客のみが知っています。計算や表示のロジックは当然ながら BI 側にも存在しているため、BI も含めたトータルのシステムとして正常に稼働しているかを dinii が知る術はないのです。
とはいえ、顧客に ●●● BI 対応といって販売している以上、連携に自信の無い BI を強く推すことはできません。このジレンマを解消するため dinii では BI ごとの連携実績を店舗数 x 日数でスコアリングしランク分けしています。
Rank A: 安定
送信実績 N 件以上 & 法人数 M 以上
Rank B: 経過観察中
送信実績 N’ 件以上 & 法人数 M’ 以上
Rank C: 試験運用中
送信実績 N’’ 件未満 & 法人数 M’’ 未満
といった具合です。
今後の展望
上述の通り、完璧な試験方法は存在しないため、各方法の短所を補うように複数の試験を行う必要があります。そして残念ながら、現時点で dinii で実施している試験方法では確認が不十分な観点が存在します。それは、「飲食店にとって重要な指標が妥当な範囲に収まって表示されているかどうか」です。試験用のデータを使う都合上、どうしても恣意的なパターンのみの確認になってしまい、複雑な条件が絡んだ場合に出力される指標が妥当かどうかを判断し難いのです。
じゃあどうするか、という話ですが、今後はベータ店舗を活用してはどうかと考えています。ベータ店舗というのは dinii 加盟店のうち数十店舗が選定された本番環境とは隔離された環境であり、それ以外のすべての店舗に先んじて機能が公開されます。技術的には Google Cloud の Project ごと分離してすべての変更を1週間早く行うという愚直な仕組みです（ベータ店舗の取り組みについても別の記事で紹介できれば…）。
ベータ店舗に各種 BI ツールを使ってもらう上で以下のようなハードルがありますが、原理的にどうしても無理というレベルの課題では無いような感覚はあります。
少数店舗の法人が多い ※3 ので BI を導入するメリットが薄い
→ 利用料を dinii で支払い、タダで使えるようにする
店舗の特性と BI の特性の組み合わせで最適解が異なり、どうしても適していない BI がある
→ 取り込み試験の確認コストは BI ごとに比例で増えていくため、一部の BI だけでしか実現できないテスト方法でもトータルの工数は着実に削減できる
まとめ
そもそも dinii 自体が POS なので POS 連携すること自体は事業のコアになり得ない
なので、事業的には投資を控えるという判断をしているが、ある程度はやっておかないと顧客獲得がままならないという厄介なトピックでもある
他社との連携という完全にエンジニアリングだけでも解決できない要素がありハンドリングの難易度は高い
逆に言えば、ソフトウェアに関するエンジニアリングとして珍しく、費用対効果をかなり厳密に計算できる嬉しさはある（なのでチームとして人員予算を計上できている）
以上です。複数社感での連携を取りつつ売上をバンバン積み上げていくことに興味のあるエンジニアは今すぐ dinii にジョイン！
※1 触発されたにしては書き始めるのが遅すぎたし何ならアドベントカレンダーのプレッシャーが無ければ書けなかったという説もある。
※2 各社 BI の機能が非常に多様で顧客がそれらを使いこなしていない = 同一 BI でも顧客によって利用機能に差分が大きいということです。
※3 大規模な法人をベータ店舗に選定してしまったらカナリーテストとしての意味がなくなってしまいます。