ChompyとPOS開発
これは、Chompy Advent Calendar 2023 19日目の記事です。
ご無沙汰しております、zaq1tomo です。
最近は、自宅で手挽きのコーヒーを淹れることにハマっています。Chompyをきっかけにスペシャリティコーヒー系の飲食店の方々と関わらせていただく機会が増え、お店に伺うたびにコーヒー豆を購入しています。浅煎りでフルーティー系のコーヒーが好みです。
この記事では、Chompyが開発するPOSである「Chompy Studio」についてご紹介します。以前、10XのyamakazuさんやChompy CTOのyagitatsu3が、外部POS連携に関する記事を書かれていましたが、実は、Chompyは、内製のPOS開発も行っています。
Chompyは、2023年5月を以って、祖業であるフードデリバリー事業を終了しました。「フードデリバリーが終了していたけれど、最近のChompyは、何をやっているの？」と気になる方向けに、最近のChompyは、飲食店向けのバーティカルSaaSをゴリゴリ作っているよ、ということをお伝えできると嬉しいです。
Chompy Studioとは何か
Chompy Studioは、飲食店に特化したレジ × ハンディ × CRMツールです。
既にいくつかの飲食店で導入されており、直近、数十店舗クラスの飲食店でも複数導入予定です。
単なるPOS（販売時点情報管理＝Point of Sale）の枠を超え、飲食で働く方々の働き方をアップデートしていけるようなプロダクトにしたいという願いを込め、「Studio / スタジオ」という名前をつけました。
社内のコードネームでは、レジ・ハンディ・CRMツールなど、複数の機能を持つプロダクトにフォルムチェンジできるという意味で「rotom / ロトム」と呼ばれています。ちなみに、モバイルオーダー・公式アプリは、飲食店ごとに合わせた姿に進化するという意味で「eevee / イーブイ」と呼ばれています。
Chompy Studioは、飲食店特化だからこその単体プロダクトとしての体験の良さはもちろん、モバイルオーダーやKDS（キッチンディスプレイシステム）など、Chompyが既に展開する他プロダクトとのシームレスな連携によって実現される新しい体験が大きな強みです。
飲食店の「注文データ」や「顧客データ」を中心に複数のプロダクトを提供し、スマホ/タブレット時代の新しい飲食体験の実現を目指す、コンパウンドスタートアップとしてのChompyのコアになるプロダクトだと感じています。
「コンパウンドスタートアップって何？」という方は、ALL STAR SAAS FUNDのtatsuyakozakiさんやLayerXのfukkyyさんの記事がわかりやすいので、ご覧ください。
コモディティになったPOS
日本の飲食業界で、POSは、1900年代後半の大手チェーンの成長とともに導入が進み、2000年代初頭のタブレット・クラウドの普及によって中小の店舗まで浸透しました。2023年現在では、POSは、多くの飲食店にとって、使うことが当たり前のツールになっています。既存のプレイヤーも多く、なぜ、Chompyが新しくPOSを作る必要があるのか、疑問に思う方も多いでしょう。
数十年の歴史の積み重ねがあるPOSは、一朝一夕には開発できません。
Chompyは、2021年初頭から、フードデリバリー・モバイルオーダーを主な価値提供領域としてきたため、前述の通り、外部POS連携を主な選択肢としてサービス提供を行ってきました。しかし、飲食店の方々と対話を重ねる中で、既存POSの課題が明らかになってきたため、2023年初頭に内製のPOSを作ることを決めました。
「POSレジについてもっと知りたい！」という方は、スマレジさまやSTORESさまの記事がわかりやすいので、ご覧ください。
既存POSの課題とChompy Studio
①：ホリゾンタル・グローバルなPOSの限界
一つ目の課題として、飲食に限らず、アパレルや小売など、複数の業界向けに開発されてきたホリゾンタルなPOSや、複数の国向けに開発されてきたグローバルなPOSでは、日本の飲食店のニッチなニーズを満たすことが難しいという点が挙げられます。
＜飲食ならではの複雑なオプション＞
例えば、コーヒー・サラダ・カレーなど、Chompyが主なターゲットとしている日常利用性が高い飲食店では、複数のオプションを自由にカスタマイズできるようにすることで、多様な商品バリエーションを実現しています。
しかし、ホリゾンタルなPOSの多くでは、複雑なオプションの設定をサポートしていないため、無理矢理オプションとして登録することで、オプション選択画面のスクロールが非常に長くなったり、オプションとして登録できず、商品選択画面のスクロールが非常に長くなったり、分析が困難になるという課題がありました。
＜日本ならではの軽減税率＞
日本では、10%に引き上げられた消費税に関して、「酒類・外食を除く飲食料品」など、特定の品目の税率が8%に据え置きになる「軽減税率」という制度があります。
グローバルな一部のPOSでは、軽減税率をサポートしていないため、イートインとテイクアウトで別の商品として登録する必要があり、商品選択画面のスクロールが非常に長くなったり、マスタデータの管理が煩雑になるという課題がありました。
＜1分1秒でも早く＞
飲食店は、ピークとオフピークの需要差が大きく、ピーク時のキャパシティが1日の売上のボトルネックになりやすいという特性があります。
Chompy Studioでは、上記のような既存のPOSの課題を解決するために、飲食店に最適化されたデータ構造やUI、注文内容を決済完了前にKDSへ事前連携するなど、細かな工夫の数々によって、飲食店の会計・調理時間を1分1秒でも早くすることを実現しています。
②：フードデリバリーやモバイルオーダーの普及による業務・データの煩雑化
二つ目の課題として、日本の飲食店では、コロナによる来店客の減少や人手不足の影響を受け、フードデリバリーやモバイルオーダーなど、新しい注文方法が急速に普及した一方で、それぞれのシステムが個別に導入されたため、業務やデータが煩雑化しているという点が挙げられます。
＜ホールでの課題＞
例えば、ホールでは、口頭注文とモバイルオーダーが混在することにより、座席ごとのステータスの把握が困難になるという課題がありました。
飲食店によっては、店内注文の90%以上がモバイルオーダー経由になったというケースもありますが、ご高齢の方など、モバイルオーダーの利用を好まないお客さまも一定数いらっしゃるため、100%の注文をモバイルオーダーにすることは難しいのが現状です。
これにより、口頭注文とモバイルオーダーの混在が発生しますが、それぞれ個別に導入したシステムを利用している場合、座席ごとの注文ステータスを把握するためには、ホールスタッフの方々が、都度、2つのシステムの確認が必要になります。
モバイルオーダーがテーブル決済をサポートしている場合、座席ごとに退店時の決済ステータスが異なるため、ステータスの把握は、さらに困難です。
Chompy Studioをハンディとして利用することで、口頭注文とモバイルオーダーの注文データがChompyに一元化され、Chompy Studioを見るだけで、座席ごとのステータスを簡単に把握することが可能になります。
＜キッチンでの課題＞
キッチンでも、複数のチャネル・時間軸の注文が混在することにより、調理の優先度の判断が困難になるという課題がありました。
フードデリバリーやモバイルオーダーを導入すると、イートイン・テイクアウト・デリバリー、3つのチャネルからの注文が同時に発生するため、キッチンスタッフの方々が、お客さまや配達員の到着時間を考慮して、調理の優先度をリアルタイムに判断することが必要になります。
プラットフォームが予約注文をサポートしている場合、優先度の判断は、さらに困難です。
また、複数のプラットフォームを利用している場合、複数台のタブレットやプリンターが必要になることが一般的で、キッチンスタッフの方々の確認のコストはもちろん、タブレットやプリンターを複数台用意するための金銭的・スペース的な負担も発生していました。
Chompy Studioをレジとして利用することで、レジ注文とモバイルオーダーの注文データがChompyに一元化され、ChompyのKDSを見るだけで、調理すべき注文を簡単に把握することが可能になります。
また、Chompy Studioは、デリバリー注文一元管理サービスとの連携も進めており、近い将来、外部のデリバリープラットフォームの注文もChompyのKDSに一元化できるようになる予定です。
＜レジでの課題＞
レジでも、フードデリバリーやモバイルオーダーで発生した注文を既存のPOSに二度打ちする必要があるという課題がありました。
フードデリバリーやモバイルオーダーが普及した現在でも、依然として、飲食店の注文のほとんどは店内で発生しており、その注文データは、POSに記録されています。
データを一元管理するため、フードデリバリーやモバイルオーダーでの注文データも、最終的には、POSに記録されることが一般的ですが、日本のレジ業界では、スマレジなどの一部のレジを除いて、APIを解放していないことが一般的なため、外部から注文データを自動連携することが困難です。
その結果、レジスタッフの方々が、フードデリバリーやモバイルオーダーの注文内容をタブレットや伝票で一つ一つ確認しながら、POSに二度打ちする必要がありました。
ある飲食店では、デリバリープラットフォームからの注文が多く、POSへの二度打ちが追いつかないため、ピークタイムにも関わらず、一台のレジを止めて二度打ち専用にし、店頭では行列が発生してしまっているというケースも発生していました。
前述の通り、Chompy Studioをハンディ・レジとして利用したり、Chompy Studioがデリバリー注文一元管理サービスと連携することで、全ての注文データがChompyに一元化され、二度打ち業務が不要になります。
③：スマホ/タブレットを前提として飲食体験を再設計できる可能性
三つ目の課題として、既存のPOSでは「いつ・何を」注文したかのデータは収集できている一方で、「誰が」注文したかのデータは収集できていないという課題がありました。
従来の飲食店では、「誰が」注文したかのデータが収集できていないため、Web業界では当たり前であるファネルやコホートを基にしたデータドリブンな意思決定を行うことができず、経営者の勘を基にした属人的な意思決定が行われていることが一般的でした。
Chompyのモバイルオーダーでは、これらのデータを可視化することができますが、スターバックスやマクドナルドなど、モバイルオーダーを強く推進している大手の飲食店でさえも、モバイルオーダー経由の注文は全体の半分以下であることが多く、モバイルオーダーのデータのみでは、全体感を持った意思決定を行いづらかったり、施策の対象が限られてしまったりします。
Chompyでは、「誰が・いつ・何を」注文したかのデータや、飲食店起点でアクション可能なお客さまとのデジタル接点のことを、飲食店の方々が所有するデジタル上の資産という意味で「デジタルアセット」と呼んでいます。
Chompy Studioでは、レジでの会員証QRの読み取りなど、注文とお客さまを紐づけるための方法を複数サポートし、レジ・ハンディ・KDS内でお客さまの情報を可視化することで、デジタルアセットの効率的な収集や、オフライン・オフライン双方での活用を支援し、スマホ/タブレットを前提とした飲食体験の再設計に挑戦しています。
大変だったこと・工夫したこと
①：現場目線での使いやすさを理解すること
まず、大変だったことは、現場スタッフの方々の目線での使いやすさを理解することです。
POSは、日常生活の中では、ほとんど触ることがないプロダクトのため、社内のメンバーの主観では、どの画面にどの情報を表示するべきか、ボタンや文字はどれくらいのサイズが適切か、判断に迷う場面が多々ありました。
スタッフの方々にヒアリングしたり、店舗に赴いて実際の業務の様子を観察することはもちろんですが、「業務体験」という形で、導入候補の飲食店にお邪魔させていただき、開発メンバー自身がホールやキッチンの業務を行うことで、スタッフの方々の気持ちを少しでも理解できるように努めました。
また、ソフトウェアの開発に慣れていない飲食店の方々にとって、テキストやモックベースで実際の使い勝手を想像し、正確なフィードバックいただくことは難しいため、「デモ会」という形で、未完成でも、出来る限り本番に近い動くプロダクトを提示し、スタッフの方々からのリアルな声をもとに、作っては壊すことを繰り返しました。
何度も作り直したChompy Studioには、細かな工夫が散りばめられており、デモ会の中では、使いやすさに感動の声をいただくことも多く、現場目線で使いやすいプロダクトを作ることができたという手応えを感じています。
②：要件が膨大で、広く深いドメイン知識が必要なこと
既存のPOSは膨大な数の機能を提供しているため、どの機能が初期リリース時点から必須なのか、それぞれの仕様はどうあるべきか、判断に深いドメイン知識が必要なことも大変でした。
POSを提供するためには、注文・決済を行えるだけではなく、商品・割引・座席などのマスタデータ管理や、売上分析の機能も必要です。
注文・決済の仕様検討においても、「標準税率と軽減税率の商品が混在する注文を割引した場合、支払い金額はどうあるべきか」など、専門的な知識が要求される場面が多々ありました。
POS内の機能だけではなく、決済端末・プリンター・ドロワー・バーコードリーダーなど、周辺機器との外部連携も必要です。
これらの機能を初期リリース時点から全て開発するのは時間がかかりすぎてしまうため、スタート段階で最終的に実現したいゴールや、ゴールに至るまでのマイルストーンを飲食店の方々に共有し、マイルストーンごとに、二人三脚でプロジェクトを進められるように工夫しました。
例えば、初期リリース時点では、マスタデータ管理はスプレッドシートとスクリプトを使っていたり、売上分析はLooker Studioなどの外部ツールを使っていたりします。
とはいえ、POSは、アルバイトの方々を含め、さまざまなステークホルダーによって利用され、仕様変更の周知コストが高いため、アジャイルな検証が難しく、ある程度まとまった形でのリリースが必要でした。
③：基幹システムとして、高い信頼性が求められること
POSは、飲食店の運営に必要不可欠な基幹システムのため、フードデリバリーやモバイルオーダー以上に高い信頼性を求められることも大変でした。
POSの運用を開始するためには、数百件のマスタデータを正確に登録しておく必要があります。
POSの運用を開始すると、飲食店の全ての注文データが記録されるため、フードデリバリーやモバイルオーダーでは経験していなかったような大量のトラフィックが発生します。
POSは、フードデリバリーやモバイルオーダーのようにプラスαの売上を作るサービスではなく、飲食店の売上を記録するために必要不可欠なサービスのため、障害発生時のインパクトが非常に大きいです。
一方、前述の通り、Chompy Studioは、複数のプロダクトとのシームレスな連携が強みのプロダクトです。逆にいうと、プロダクト同士の連携を前提としているため、単体のプロダクトよりもシステムの安定稼働を保証することが難しいです。
Chompy Studioの初期導入時には、上記の要求に応えるための体制が十分に整っておらず、登録ミスやシステム障害が発生し、飲食店の方々にご迷惑をおかけしてしまったこともありました。
今後取り組んでいきたいこと
①：システムの信頼性向上
上記のように、POSには、高い信頼性が求められます。Chompy Studioは、直近、数十店舗クラスの飲食店でも複数導入予定のため、求められる信頼性はさらに高まっていくでしょう。
テストや監視の体制拡充はもちろんですが、プロダクト的にもアップデートが必要だと感じています。
具体的には、インターネットに依存せず、ローカルネットワーク内でプロダクト間の連携が行えたり、オフラインでも取引が完結できる仕組みを整えていきたいです。
②：オンボーディングの効率化
前述の通り、POSの運用を開始するためには、数百件のマスタデータを正確に登録しておく必要があります。
一方、現状は、マスタデータを効率的に管理できる仕組みが整っておらず、社内メンバーの工数を圧迫してしまっています。
今後、導入店舗数をスケールさせていくためには、飲食店の方々がアプリや管理画面からマスタデータを簡単に管理できるようにしたり、複数店舗横断でマスタデータを効率的に管理できる仕組みが必要だと感じています。
③：デジタルアセットの更なる収集・活用
前述の通り、Chompy Studioは、単なるPOSの枠を超え、飲食で働く方々の働き方をアップデートしていけるようなプロダクトになることを目指しています。
現状のChompy Studioで提供できている機能は、会員証QRの読み取り等での注文とお客さまの紐づけ、紐付けたお客さま情報の可視化、レジでもアプリ内の特典が貯まる/使えるなど、ほんの一部です。
今後は、更なるデジタルアセットの効率的な収集や、さまざまな形での活用を活用を支援し、スマホ/タブレットを前提とした飲食体験の再設計に挑戦していきたいと考えています。
以下は、今後実現していきたいアイデアの一部です。
・行列待機中に注文内容を決めておくと、レジで注文内容を引き継いで会計できる
・アプリに支払い情報を登録しておくと、レジで会員証を読み込むだけで決済できる
・お客さまに注文した商品のこだわりやストーリーを伝えることができる
・お客さまごとに合わせたニュースやクーポンを届けることができる
・お客さまごとに合わせた店頭接客やコミュニケーションができる
・スタッフの方々がデータドリブンに店舗運営を改善できる
最後に
長くなりましたが、最近のChompyは、飲食店向けのバーティカルSaaSをゴリゴリ作っているよ、ということをお伝えできたでしょうか。
Chompyでは、仲間を大募集中です。
この記事を読んで「面白そうかも！」と思っていただけた方は、自分の Twitter など含めて、お気軽にご連絡ください。
最後までお読みいただき、ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？