約4か月でMVPを公開し、追加開発まで継続支援｜飲食店向けチップ送付サービス

対象：飲食店向けサービス運営事業者カテゴリ：Webシステム・モバイルアプリ

来店した利用者がアプリからチップを送り、スタッフは通知、店舗管理者は履歴を確認するサービスを開発しました。初期MVPを約4か月で公開し、その後の追加開発・運用保守まで担当しています。

プロジェクト概要

項目	内容
対象	飲食店向けサービス運営事業者
カテゴリ	Webシステム・モバイルアプリ
開発区分	開発支援
使用技術	AWS AppSync・DynamoDB・Lambda・EventBridge・Stripe

サービスには、チップを送る来店客、受け取るスタッフ、履歴を確認する店舗管理者が関わります。利用者が送付できる画面だけを用意しても、店舗側が内容を確認できなければ運営につながりません。初期開発では、それぞれの立場で必要になる操作と記録を一つのサービスとして扱いました。

たとえば利用者が送付した後、スタッフは通知を受け取り、管理者は店舗の履歴から対象の送付を確認します。これは業務の利用例です。同じ取引について表示する情報がつながっていることが、利用者向けアプリと管理機能を組み合わせるうえで重要になります。

利用者はアプリからチップを送ります。支払い結果が送付履歴へ反映され、スタッフは受取通知を確認します。店舗管理者は管理画面から送付・受取の履歴を把握します。

問い合わせに対応する際も、支払い状態と履歴を確認できます。利用者と店舗側がそれぞれ必要な情報を参照する構成です。

初期MVPは約4か月で公開しました。短期間で初期版を用意することに加え、決済結果、通知、履歴を後から追える関係を設計しています。決済はStripe、サービス内のデータ管理はAWS側が担うため、外部決済の結果と内部の記録を区別して対応させる必要がありました。

公開は支援の終点ではありません。その後の追加開発と運用保守まで継続して担当しています。MVPの開発からサービスを維持・改修する段階まで関わったことを、本件の実績として示しています。新規サービスを立ち上げた後も、決済と店舗業務の接点を扱い続ける支援です。

Stripeとの決済連携では、支払い結果を受け取ってシステム内の状態へ反映しています。履歴との対応を持たせ、店舗側が支払いと受取の状況を追えるようにしました。

メール送信と集計は非同期処理に分け、通知や管理画面の更新を連携しています。利用者の操作からバックエンドの処理までを横断して設計した案件です。

決済にはStripeを利用し、外部で処理された結果をWebhookで受け取ります。受信した結果をシステム内の状態へ反映し、送付・受取の履歴と対応させています。

DynamoDBでは、関連する状態と履歴をトランザクションでまとめて扱っています。これはDB内の更新をそろえるための処理です。Stripeでの支払いとDBへの反映は別の処理なので、外部の決済を含めて一度に確定する設計ではありません。

この役割を分けることで、支払い結果を受け取る接点と、店舗が参照する履歴の関係が明確になります。フロントエンドからバックエンドまで横断して関わり、結果をどの段階で扱うかを整理した案件です。

メール送信と集計にはEventBridgeを使い、非同期処理として扱っています。また、AppSync Subscriptionで通知や管理画面の更新を反映し、利用者の操作と店舗側の確認をつないでいます。

非同期の処理では、利用者の操作が終わった時点と、通知や集計が反映される時点が同じとは限りません。担当者が状態を確認するためには、送付結果と通知・集計がどの取引に対応するかを追えることが重要です。

開発では、フロントからバックエンドまでの処理を可視化し、障害時に調査する箇所を追えるようにしています。アプリの表示だけを見るのではなく、その結果を支える処理との関係まで扱っています。

業務整理・要件定義、アーキテクチャ・DB・API設計、モバイルアプリと管理画面の実装、テスト、MVP公開、追加開発、運用保守を担当しました。PL・アーキテクトとして、フロントエンドとバックエンドを横断して開発をリードしています。

要件定義から約4か月で初期MVPをリリースしました。公開後も追加開発と運用保守を担当し、立ち上げから継続的な改善まで関わっています。

短期間の初期開発に加え、運営を続けるためのアプリ・管理画面・バックエンドの保守を支援した実績です。

業務システムの改善や新しいサービスの開発をご検討の際は、現在の業務と実現したいことをお聞かせください。要件整理から開発・運用までご相談いただけます。