https://product.st.inc/entry/2025/12/11/181447

この記事は STORES Advent Calendar 2025 の 11 日目の記事です。 STORESでWebアプリケーションエンジニアやってる染谷(somezi)です。現在はモバイルオーダーを開発しています。

STORES モバイルオーダーでは2025年4月時点で下記の課題を抱えていました。

店舗スタッフさんが注文を見て商品を提供するためのキッチンディスプレイに機能が足りておらずキッチンの課題を解決できてない
テイクアウト注文のみ対応していたので、飲食店の中でも狭い市場の中での課題解決に留まっている

ところで皆さん2025 秋アップデート見ましたか？？上述の課題を解決し、モバイルオーダーチームは少人数ながら2025年4月から秋にかけて多くの機能を追加しました。

店舗スタッフさんが利用するキッチンディスプレイに多くの機能を追加して様々なお店のオペレーションに対応
テイクアウトだけでなくイートインが登場

などなど他にも多くの機能が追加されています。2025 秋アップデートにモバイルオーダーの動画も載っているのでぜひアクセスしてみてください。

本記事は、モバイルオーダーチームがどうやって多くの機能や成果を出したのかの紹介です。

※筆者がすべて作ったかのように見えますが、そうではなくチームでやり遂げたことです。

前提: モバイルオーダーを構成するアプリケーション

STORES モバイルオーダーは大きく3つのアプリケーションによって成り立っています。

※POSレジは2025年秋にリリースしたイートイン機能から連携するようになりました。

購入者が注文するときに使うストアフロント(Ruby on Rails/Next.js)
注文を見て調理を開始するキッチンディスプレイ(Android/iOS)
イートインのお会計をするPOSレジ(iOS)

STORES全体のシステム構成図はこちらへ。

product.st.inc

2025年4月時点の開発チーム状況

当時はテイクアウトしかできず、イートインがまだ存在しなかったのでお客さまが注文するストアフロントとお店が注文を管理するキッチンディスプレイの2つだけでした。

チーム体制はストアフロントがWebエンジニア8人、キッチンディスプレイは別チームに依頼する形式で動いていました。
また、Webエンジニア8人はネットショップとモバイルオーダーの2つを見ており、2週間スプリントのスクラムで動いていました。

開発の問題としては下記がありました。

ネットショップとモバイルオーダーでそれぞれやりたいことがあるのでモバイルオーダーだけを優先的に開発することはできない
キッチンディスプレイは別チームなのでコミュニケーションが取りづらい
セールスやPdMとの距離が遠く、どこに課題があるのかエンジニアチームが知らない

このようにモバイルオーダーに集中できないし、課題がなにか把握もできていないという状況でした。
成果としても導入数や注文数は雀の涙で厳しい状況が続きました。

ターニングポイント

モバイルオーダーの成果が出ないし開発も集中できないなと思っている時に転機は起きました。

EM「モバイルオーダーはPdM1人とエンジニア3人で頑張ってもらうから」 (意訳)

みたいなことをRubyKaigi中に言われたのを覚えています。来月からかなーくらいに思っていたのですがRubyKaigi明けにすぐ新体制になって早いなと驚きました。

これによってPdM1人、Webエンジニア2人、Androidエンジニア1人の計4人のスモールチームでモバイルオーダーを集中開発していくことになりました。
週2,3回出社して顔を突き合わせながら「社内ベンチャーだね」といいつつ始まりました。
セールスは1人だったのでよく来て商談しているのを聞いたり、オーナーさんの課題を聞かせてくれました。

今は人数が増えて机も増えてますが、最初は机1.5台くらいの大きさから始まりました。旧部室と呼ぶ奥まったところにあって好き。

新体制編

新体制になってから以前の体制を引き継いだままでは同じだと思い開発速度を高める工夫や、お店にディープダイブしてどう使われるか知るようにしたので紹介します。

開発速度を高めた工夫

スクラムを辞めた

以前は2週間単位でスプリント組んでおり、前週の金曜日にスプリント計画で1日使って2週間なにをやるのか決めてから開発していました。リファインメントは次スプリントの計画のためにやっていました。

対して、新体制ではスクラムを辞めました。スプリントというリズムは取りつつもイベントは廃止し、単位は1週間にしました。

理由は作りたい機能がたくさんあること、2週間ごとに要件を固めてから開発着手ではスピード感が遅いからです。イベントを廃止した代わりに必要があれば都度会話して要件を固め、本当に必要な機能をつくるようにしていました。

そのため朝会を毎日30分取っていましたが1時間に延びることもありました。もちろん朝会以外でも話しているのでもしかしたら会議時間は以前よりも増えているかもしれませんが、無駄な時間ではなく使われるプロダクトをつくる上で必要な時間でした。

素早い意思決定

ドキュメントに残すよりも口頭やホワイトボードでのやりとり重視して素早い意思決定をしていました。
スクラムイベントを待たずにすぐPdMと会話してどう解決していくのか密に話して本当に必要なものをつくっていきました。

一方で仕様が複雑になると大変だったり、フェーズが拡大してくるとその人しか詳しい仕様知らないという属人化問題が出つつありますが当時のフェーズでは効果的でした。

仕様が複雑になって大変だった思いもしましたが技術で乗り越えたものもあります。

product.st.inc

お店にディープダイブ

毎回ではないですがエンジニアも訪問(営業やモバイルオーダーの導入準備)についていくようになりました。その中でオーナーさんがどんなことに困っているのか、今のSTORES モバイルオーダーなら解決できるのか、できないならどういった開発が必要になってくるのかを一次情報として知ることができました。

また、運用初日はオーナーさんの店舗にお邪魔してなにかあったらすぐにデバッグできるようにスタンバってました。実際に使っていただいたお客様からの声や店舗スタッフさんからの声をその場で聞き、その場で画面を見せながらどうですかと素早い改善サイクルを回せてとても楽しかったです。

実際に現場に居ると「商品を見つけられないお客様が居るようで」と声を頂きました。before画像のように丁度カタログ*1が見切れていると続いていることがわからない状態だったのです。
矢印があればスクロールできるとわかるのではないかと考えてすぐにプロトタイプを実装し、見せて「すごくいい！」とお墨付きをもらってリリースしました。

どう使われているかを知らないと中々気づけないですね。

また、当時のストアフロントはカタログごとにURLが別れており、違うカタログをクリックするとURLが変わって商品一覧が見れる方式を取っていました。

上述のようにカタログがまだあるのかわかりにくい問題と、他社のモバイルオーダーを触っていると縦スクロールですべてのアイテムが見れる構造のものがあり、スクロールできた方がユーザ体験が良いだろうとエンジニアで判断しました。

2日程度でつくってチームメンバーに見せて「やっぱりスクロールで勝手にカタログ切り替わった方が見逃さないから便利だよね」と満場一致だったのでリリースしました。

このようにディープダイブすることによってエンジニア起点で改善をどんどん回すことができました！

成果

こうやって開発をしてきたよとプロセスを書いてきましたが成果はどうだったでしょうか？詳細なデータは見せられないのですが導入も増え、注文数も爆伸びしました🎉
開発だけでなくセールスや営業にも行くPdMのおかげです！

初期は当たり前機能が少なかったので導入してもらってもほぼ使われていませんでした。
しかし、ターニングポイントを経て集中開発するようになってから機能をたくさんつくり、今では充実したものになりました。セールスやPdMに「機能不足で競合に負けなくなった」と言われた時は「つくってきたものは間違ってなかったんだな」ととても安心しました。

また、実際にオーナーさんから「モバイルオーダーを導入したことで過去最高の売り上げを達成できた」との声も頂き頑張った甲斐がありました😊