Amela
機密保持のため、企業名・プロジェクト名・システム画像は仮名およびモックに置き換えています。
フードデリバリー運営企業様 新規プラットフォーム立ち上げストーリー

注文・調理・配達を、1基盤で同期

DineDash は、ユーザー・店舗・配達員の3つのモバイルアプリと共通APIを1基盤で運用する3面マッチング フードデリバリー基盤。準備ETA・リアルタイム位置・自動精算を統合し、待機時間と運用工数を最小化します。

「電話受注・店舗準備の不可視・顧客への配達状況不明・配達員の手作業精算」を解消するため、フードデリバリー運営企業様と共に、ゼロから14ヶ月で内製構築。

受注方法
電話 → アプリ
配達員手配
電話 → 自動
配達状況
不明 → 追跡
精算
手作業 → 自動
DineDash
配達中 ETA 12分
⚡ 配達員
注文 #4523
渋谷店 / 配達員: 田中さん
調理完了 ✓ → 配達中 → お届け予定 18:42
01
CLIENT
お客様について

地域密着型フードデリバリー「フードデリバリー運営企業様」。

数千店舗の飲食店をネットワーク化、ローカルレストランから家庭への配達を提供するフードデリバリー事業者。地域密着の店舗網と自社配達員チームで、当日注文の安定供給を実現。

従来は電話受注・配達員への個別電話手配で運用されており、受注ミス・配達員の待機・顧客への配達状況不明・経理工数増大が事業拡大のボトルネックとなっていた。

数千+
加盟店ネットワーク
3アプリ
統合 (ユーザー / 店舗 / 配達員)
5プロダクト
統合 (3App + CMS + API)
BUSINESS FLOW
STEP 01
注文
ユーザーアプリで店舗・メニュー選択
STEP 02
店舗確認 + ETA
店舗アプリで受注・準備時間を返答
STEP 03
配達員マッチング
準備ETAに合わせ自動マッチング
STEP 04
配達 + 精算
リアルタイム追跡 / 自動精算
02
CHALLENGE
解くべき設計課題

3面の体験と運用工数を変える4つの設計課題。

電話受注で店舗・配達員の連携が断絶
受注ミス・伝達ロスで注文キャンセル・クレームが発生、ピーク時の信頼を損なう。
店舗準備時間が見えず配達員が無駄に待機
配達員が店舗で10〜20分の待機、稼働率と収益を圧迫。
顧客に配達状況が見えず不安を生む
「いつ届くか」が分からず問合せ電話が殺到、CS工数とブランド信頼を消耗。
配達員の収益・精算が手作業
月次精算で数百時間の経理工数、配達員の支払い遅延クレームも発生。
03
ARCHITECTURE
共に築いた構成

3アプリ + 共通API + CMSを1基盤に。

React Native で3アプリを並行開発、NestJS API で全プレイヤーの状態を同期、Socket.io でリアルタイム位置、Redis で配達員マッチングキュー、FCM で全プレイヤーに同時通知。CMSで店舗・配達員・配達エリアを一元管理。

Amela
EXECUTION
14
ヶ月
126
人月
領域 ①
3面受発注
課題
電話受注・伝達ロス
解決策
3アプリ共通APIで状態同期
全プレイヤーが同じ情報を見る
領域 ②
マッチング
課題
配達員が店舗で長時間待機
解決策
準備ETAに合わせ自動マッチング
配達員の待機をゼロに
領域 ③
位置追跡
課題
顧客に配達状況不明
解決策
Socket.io リアルタイム位置 + ETA 表示
問合せ削減・安心体験
領域 ④
自動精算
課題
手作業精算・月数百時間
解決策
配達完了で自動収益計算・週次精算
経理工数1/10、配達員満足
TECH STACK
Mobile
React Native (×3 apps)ReduxTypeScript
Backend
NestJSTypeORMPostgreSQLReact CMS
Realtime
Socket.ioRedisFirebase FCM
04
IMPACT
プラットフォームが生み出す価値

3者の体験と運用が、次のステージへ。

注文キャンセル・問合せ電話の削減
電話受注の伝達ロスがゼロ、リアルタイム追跡で「いつ届くか」問合せが消失。
配達員の稼働率・収益向上
店舗待機ゼロで配達員1人あたりの配達件数が向上、収益も上昇。
CS・経理工数の大幅削減
追跡可視化で問合せ電話消失、自動精算で月数百時間の経理工数削減。
店舗加盟ネットワークの拡大
店舗アプリで参加ハードルが下がり、加盟店ネットワークが拡大しやすい構造に。
05
DEMO
3つのシナリオ (3面)

3面の視点で、構築後の体験を。