「高級フードデリバリー」×「タクシー」アプリ立ち上げの産みの苦しみとやりがい

Satoshi TSUBOI

2021年12月8日 11:23

これはプロダクトづくりのための挑戦とその成功・失敗談を綴るアドベントカレンダー powered by プロダクト筋トレの9日目の記事です。
※本記事は個人の活動による記事であり、会社の公式見解とは異なる場合があります。

こんにちは！
株式会社Mobility Technologies（MoT）プロダクトマネージャーの坪井です。会社名は馴染みがない方もいるかもしれませんが、タクシーアプリ「GO」を提供している会社です。

しかし、本記事では「GO」ではなく、2021年5月にリリースされた日本初の”タクシーデリバリー専用アプリ”「GO Dine」の立ち上げからリリース後に至るまでをまとめています。

今回は自分自身としての振り返りとして、またプロダクトマネージャーとして日々邁進されている方へ少しでも参考となる話ができればとアドベントカレンダーに参加しました！

ちなみに立ち上げの経緯から書いており長文となっています。プロダクトマネジメント関連のトピックは後半にありますので、お好きなところから読み進めてください。

特に以下の内容に興味がある方に、より面白く読んでいただけるかなーと思います。

・フードテック、フードデリバリーサービスに興味がある/関わっている人
・リアルとデジタルが重なり合う領域でのプロダクトマネジメントに興味がある人
・スタートアップ内(かつ統合間もないカオスな状態)で立ち上がる新規事業での働き方・チーム体制に興味がある人

「GO Dine」とは？

「GO Dine」は前述のとおり、「タクシー」でのフードデリバリーサービスです。Uber Eatsや出前館のタクシー版と思い描いていただけるとイメージしやすいかと思います。

他サービスと最も異なる特長は「高級料理のデリバリー」に特化している点です。
世界的グルメガイドで星を獲得している銘店から新進気鋭の人気店に至るまで幅広いジャンルで80店舗程度（2021年12月現在）を独自の基準で審査・加盟いただいています。

そんな高級店・有名店のできたてのお料理を、タクシーアプリ「GO」の運営で築き上げたタクシー車両とのリアルタイムネットワークを活用することで、実績あるタクシー乗務員が安心・安全にお届けすることが可能となっています。

最近では、おせちやクリスマスケーキの提供も開始してます！冷凍ではなく生で新鮮な状態ですぐ食べられるのは「GO Dine」ならではかと思います。

事業検討〜リリースまでのステップ

コロナ禍でのニーズ急騰＆急速な法整備

ではなぜタクシーアプリの会社で、フードデリバリーアプリを立ち上げることとなったのか。一番大きな要因はコロナ禍での緊急事態宣言の発令です。

皆さんもご経験されたかと思いますが、当時人々は家から一歩も出られない。そのため飲食店には人が来ず、タクシーで移動する人も消えました。
そのため「皆困っているなら”タクシーは人しか乗せてはいけない”ルールを変えよう！」と急速に法整備が進捗。

2020年4月、有償貨物運送という特例措置の発表を受けて事業検討を開始。2020年9月に正式に有償貨物運送の実質恒久化が決まったため、MoTとして事業化に向けて急ピッチで準備を進めました。
ちなみに通常、このあたりの法律の施行までは実証実験から最低2年はかかるのが通例なので、非常に異例とも言えるスピードです。

このあたりの経緯の詳細、事業検討に関する記事はこちらの記事もぜひご覧ください。

見えてきた「課題」と「機会」

プロダクト検討においては日本交通様で先行実施されていたタクシーデリバリーでの実績が非常に参考になりました。

特に大きな課題は以下の3点です。特例措置から非常にわずかの期間で実施しているため、システム開発をする余裕もなく、全てをオペレーションでやりくりする状態。飲食店・事業者・ユーザーの3者すべてにおいて利用負荷の高いサービスとなっていたのです。

①集客機能を持たないため、期待したほどの注文が入らない
基本的には店舗側での告知・集客面しか持たなかったため、新規顧客の獲得には繋がりづらい状態でした。
②アナログなオペレーション運用による運用トラブルの多さ
ユーザーからの予約を受け付けてから、タクシー手配は店舗がタクシー会社へ電話連携を行うという方法のため、伝達ミスなどのヒューマンエラーが発生していました。
③決済手段が「タクシー車内」での決済という煩わしさ
ネット決済の仕組みを持たない店舗も多いため、ユーザーにタクシー車両まで決済のために来てもらわなければならない場合がありました。

一方で、実際に体験された方からはポジティブな意見も多く、そこに事業化のヒントがありました。

【飲食店より】
・大切なお客様への料理を託せる安心感。プロのドライバーに運んでもらえるのが良い。
・タクシーで届けるので、大量配送・遠距離配送に対応可能。
・空調の効いた車両に断熱バックに入れた形で、お届けできるので衛生面でも安心できる。

【ユーザーより】
・見知らぬ誰かではなく、身なりも整ったタクシー乗務員さんが運んでくれて安心できる。
・子どもが小さくてお気に入りのお店に行けないが、宅配であれば家で落ち着いて食べられる。
・家族や両親とのちょっとした記念やお祝いの際に、これまでの出前にはない特別な料理を食べられる。

そこで「特別なシーンで使うことのできる高級価格帯のフードデリバリープラットフォーム」の提供が決定しました。

既にフードデリバリーサービスは競争が激化していますが、高級価格帯で優位性を持っているプレイヤーはまだ不在。

そこに「GO」で培ってきた街なかを走る十分なタクシー在庫に対して、リアルタイムに配車をかけられるアセットを持っているMoTとして、十分に参入の事業機会はありました。

前例のない「タクシー×高級デリバリー」

方針が決まったところで、MVPの開発に向けた検討をBizDevチームと協働して進めました。

当時の体制は、BizDev3名に加え、プロダクトサイドからはPdMの私とUXデザイナーの2名。
私とUXデザイナーとで、ユーザー・飲食店・乗務員（＆タクシー事業者）にまたがる複数プロダクト群のWhy/Whatの整理を進めました。

バリュープロポジションキャンバスで全体像を整理
具体的なユーザー体験・業務フローの精緻化のために、ユーザーストーリーマッピングやフローチャートをゴリゴリまとめては修正してを繰り返す
並行して要件定義を進めながら、デザイナー・エンジニアも参画してDetailを詰める
プロトタイプを作成し、想定ユーザーに近いと思われる方々へヒアリング

このあたりの手法・ノウハウは他記事・書籍でも多数参考になるものも多いと思うので割愛しますが、私個人としては完全に0→1のプロダクトに関わることが初めてだったので、一つ一つ基本をインプットで固めながら実際の業務でアウトプットする日々。

また詳細は後述しますが、フードデリバリーアプリとしての先行サービスは既に多数世に出ているためもちろん参考としつつも、やはり「タクシー」で「高級価格帯」である特徴を踏まえた必要があります。
この独特な要素を捉えた上で、いかに既存のオペレーションに不便益を生むことなく、自然に溶け込ませていくか。

自分のプロダクトマネジメントの力量の無さを痛感しつつも、やはり実業務で使うことが一番の修行であり、教科書だなと今振り返っても感じます。

会社統合間もないカオスな環境での開発

MoTは2020年4月に、タクシーアプリで競合だった会社/事業（JapanTaxi社・DeNAオートモーティブの一部）が合併してできた会社です。

実は「GO Dine」の事業・プロダクト検討をしている真っ只中で、会社全体としてはその両社のプラットフォームを統合し「GO」アプリを絶賛開発しているところでした。

そのため本来はより初期から主要の開発メンバーも含めて進めたい気持ちはありつつ、リソースはなかなか割けない状況。ようやく2020年9月1日の「GO」アプリリリースに伴い、徐々にエンジニアが合流しました。

そんな中開発フェーズで最も苦労したのはチームビルディングでした。

全く文化の異なる２社が統合して間もないため、新会社としての組織・文化醸成は不完全
かつ、目まぐるしく状況の変わる新規事業のプロダクト開発
にもかかわらず、事業上のリリースターゲットは割とタイト（あるある）
とどめは緊急事態宣言に伴う出社禁止/非推奨のため、対面コミュニケーションの制限

と、複数の要素が絡み合い、なかなかハードモードな状況でしたが、なんとかエンジニアのリーダー・PjMとともに踏ん張りながらプロダクトを前に進めていきました。

正直なところ、チーム内でのハレーションが起こることもしばしばありつつ、、なんとか今年の5月に「GO Dine」を正式にリリースすることができました。
本当に多くの人の助けがあってこそ、リリース日を迎えることができたことに本当に感謝しています。

「GO Dine」ならではのプロダクトマネジメントの制約・苦悩

さてプロダクトマネジメントという観点で、改めて「GO Dine」ならではの産みの苦しみややりがいなどを整理したいと思います。

既存事業への影響を考慮した実装・調整

「GO Dine」は新規サービスではあるものの、配達部分は「GO」の車両ネットワークをフル活用することで、より迅速・確実なデリバリーが可能となっています。乗務員（配達員）側のプロダクトを０から作る必要がなかったのは大きなメリットでした。

一方で、統合して間もない両社がそれぞれ持つ機器構成に従った仕様理解・要件定義が必要不可欠です。かつ「GO」アプリに関連するプロダクト群のPdM/エンジニアなど多くのステークホルダーを巻き込みながら、タイトな期日でPJを前に進めて行くのは非常に苦労しました。

そのため、PJを進める上でも以下は特に注意しました。本来であれば避けるべき選択肢であったかもしれないですが、QCDのバランスを見ながら品質を多少犠牲にしてでもスピードを優先する意思決定をしたこともあります。

提供価値を損なわない程度での最小限度の機能の見極め
実装期間とQA期間を重複させ、期日短縮　※本来は避けたかった

また一般的には「MVP開発のためにはアジャイルな開発体制を構築すべき」とも言われます。しかしその会社でのコアプロダクトの周辺領域で立ち上げる新規事業・サービス（機能）については一概にそうではなく、プロダクトのフェーズ・性質に応じて適切な体制・プロセスを採択することは重要だなと実感しました。

「GO Dine」もリリース前後で大きく変更しており、フェーズに応じて適切な体制を組成できるよう定期的に見直しています。

リリース前：
ウォーターフォール型(に近い)体制で、エンジニアを含む最大数十名ほどの
PJ管理を推進。必要最低限の機能に削ぎ落としてミニマムでローンチ。
リリース後：
アジャイルでスクラムチームを組成。Client/Serverあわせ10名前後のチームで、２週間スプリントでリリースを繰り返す。

ちなみにリリース前、PjMが正式にアサインされるまでは、自分でPJ管理も並行で進めていましたが、数十名規模のPJを進めることは初めてのためPdM/PjMとしての振る舞いの違いに苦しんだ時期もありましたｗ

PdM/PjMを兼務しながら双方の価値・意義を追求しようとすると対立事項多すぎて精神崩壊しねえ？
— TSUBOI /「GO Dine」Product Manager (@sato_satox) November 20, 2020

このあたりの記事は何回も読み返してました。

統合直後でのチームビルディング

上述したとおり、全く異なる文化の会社が統合して間もなく出来上がったチームです。試行錯誤しながらエンジニアのリーダーとも改善に努めましたが、特に以下の点は特に重要だと思います。

自分の強み・弱みの開示をして入念にコミュニケーションを取ること。特に私は開発経験がないため、より複雑な技術要件や仕様策定はエンジニアに任せた方が品質・スピードも上がると割り切り、その代わりにエンジニアがなるべくコア業務以外に時間・意識を割かないよう自分が主体となって動く、という役割分担をしていたのは良かったと思います。
マインドセット。個々人の強み/弱みに合わせて適材適所に配置することは重要ですが、前提として特に新規事業において全メンバーが事業・プロダクトの成功に対して同じマインドを持っているかが肝要だと身に沁みました。

なお、当時の意思決定は難しかったかもしれませんが、例えば週に1日は出社推奨日を設けて、対面で話して解決する粒度の課題を迅速に解決したり、コミュニケーションを図るための機会創出ができれば、よりスムーズにチームビルディングできたな、と感じることは多かったです。

実際、一部のスタートアップではコロナ禍であっても、あえて出社することを推奨する企業も見受けられ、個人的には納得します。今後リモートワークが主体となったとしても、特に新規フェーズのプロダクトに関わるチームの働き方では対面を重視する方が良いでしょう。

複数の事業領域での法令・商習慣の考慮

飲食業・タクシー業界ともに扱う法律・免許が幅広く、それらを考慮したプロダクト作りが必要です。元々タクシー業界の理解はあったものの、飲食業界については全くのド素人。キャッチアップに苦労しました。その一部をご紹介すると

■タクシー業界観点
・「人（旅客）」と「荷物（貨物）」で、適用される法律が異なる
旅客・貨物ではそれぞれ法令で定まった金額や手続きの方法（事前認可or事後届出）が異なるため、フードデリバリー特有の考慮が必要。

■飲食業界観点
・軽減税率＆総額表示対応
軽減税率：デリバリー／テイクアウト商品は原則対象だが、アルコールを含む場合など一部例外がある。
総額表示：リリース時期が義務化必須後となることが見込まれたため実装

・保有免許による提供可能なメニューの違い
飲食店営業許可以外に、お酒を提供する際には小売酒販免許、ケーキを提供する際には菓子製造業が必要。
加えて注文者側での調理・加工が必要だと、更に細かい免許が必要となる。

特に軽減税率・総額表示の部分は、カートの計算や決済部分の機能開発に直接的に影響するため、特に慎重に検討を進めました。軽減税率制度で考慮されていないユースケースの商品を扱うこともあり、判断が曖昧な時には自分から税務署に出向いたりもしました。

いずれにせよキャッチアップの際には、専門家に聞く・一次情報に触れることの積み重ねが重要だと感じます。

扱う商材・注文形式に伴う概念・設計の整理

従来のフードデリバリーサービスと最も異なる点が、「事前予約型」ということです。

「今頼めるもの」を注文するのであれば、今を起点としてその後の予測時間を考慮する設計でよいのですが、「その時頼めるもの」はその時点を起点として逆算していつまでに注文を締めて、配車をかけておくべきかを精緻に組み立てる必要があります。

主に影響のある変数には以下のようなものがあるのですが、「フードデリバリー」「飲食店予約」などで扱う変数とは異なる概念も多く苦労しました。

・予約時間帯：曜日・時間で頼める時間帯を管理
・注文受付期限：商品ごとに仕入れ・準備にかかる時間が異なるため、同一店舗の中でも複数の期限が存在する。
・提供不可日時：臨時休業日やイートインで貸し切りの際など、特定の日付・商品だけ提供不可な商品が発生する。
・店舗/お届け先までの時間の考慮：もちろん配達にどれくらい時間がかかるかがリアルタイムに変動しないと時間がずれてしまう。　などなど、、

そのため、ワークフロー整理の際は、フードデリバリーサービスはさほど参考にせず、ホテル予約サイトやECサイトなど行動様式が近い業界のサービスを特に参考にしながら設計・UIを作り込みました。

PdMとして、自分が関わる業界以外にもどれだけ幅広い引き出しを持っているかによって、Whatの選択肢が広がって来ると思いますし、日々いろんなサービスを使ってみることは大事だと改めて感じます。

なお現在はまだ実装できていませんが、本来は「その時頼める個数」を管理できると、店舗が準備できるまでの個数を上限として注文を受け付けられるため、より注文時点で予約可否が確認できるようになります。このあたりはよりよいユーザー体験につなげるために今後チャレンジしていきたいです。

「GO Dine」ならではのプロダクトマネジメントの工夫・やりがい

一方で「GO Dine」ならではの魅力や経験もさせていただきました。

最適解のまだ無い「タクシー」×「高級デリバリー」の試行錯誤

これまで記載してきたとおり、「高級価格帯×フードデリバリー」というのはまだまだ未知の領域です。飲食店側もこれまでデリバリーに興味はあっても、いろんな理由で導入できなかった方も多数。
一緒にあるべき形とは何かを模索しながらプロダクトを作っていくプロセスはとてもやりがいがあります。（店舗の皆さまと、そして日々相対しているBizDevメンバーには頭が上がりません。）

フードデリバリーサービス自体がここ1,2年で急速に浸透してきたサービスで、未だ飲食店側のペインもいろんな観点で残っている点も多いです。これからもいかに高級店の皆様に支えられるプロダクトとして磨き込んでいけるかはPdMとしての力量を試されていると感じます。

特に「GO Dine」は注文単価が万単位と、通常のフードデリバリーと比べても高価格帯であるがゆえに、ユーザー・飲食店ともに品質に対する目線がとても厳しいです。

アプリリリース前からもBizDevメンバーと企画する中でも特に意識し、
・アプリで掲載する料理写真はなるべく専任カメラマンに撮影してもらう
・お届け時間の細かな調整を行い、なるべくユーザーさんの希望する時間帯にちょうど届けられるようにする
など狭義のプロダクト以外の、オペレーションも含めたWhole Productとして改善していくのが大変でもあり醍醐味でもあります。

新規サービスならではの開発チャレンジ

どちらかというと開発観点にも関わりますが、今回新規で立ち上げるにあたり、なるべきモダンな環境で作ることを目指しました。

自分自身、他の運用歴が長いサービスに関わっていたとき、やはりどうしてもデータ構造がカオスになっていたり、技術的負債が残っていることに苦しめられた経験があります笑

それを反面教師とし、採択する技術スタックや特にサーバー側のアーキテクチャはエンジニアと協働して、ある程度時間をかけてでもじっくり検討しました。
アプリではFlutterを採用し開発プロセスを効率化したり、サーバーサイドではマイクロサービスを志向したアーキテクチャーにする、などなど。詳細はこちらもご覧ください。

またそれ以外には、「なるべくコアプロダクト以外は作らない」「自動化できるところは自動化する」という点も意識しました。

そのため社内の管理画面はリリース初期は必要最低限のものに留め、以下のような取り組みを実行しました。リソースが潤沢にない中、作らなくて良いものは作らないというのは非常に重要ですし、日々技術・ツール（ノーコード/ローコードなど）の最新トレンドをキャッチアップすることはアジリティを上げるためにも必要不可欠だと思います。

Airtableを活用した入稿フローを整備
WEB記事、アプリバナー管理はContentfulで管理
支払通知書などのドキュメンテーションをGASで自動化
QA業務の一部は、リリース後初期からAutifyを導入

Autify導入の詳細／効果に関しては、チーム内のQA担当が記事にしているのでこちらもぜひ。

個人的には以下に激しく共感しまして、やはりいきなりものを作るのではなく、人力or既存の仕組みを使って回せるものは回しつつ、理想のフロー・ユースケースから逆算してプロダクトを作ることはこれからも意識したいところです。

プロダクト開発の上手なチームは普通にやってることですが、PMFの前段階にはその質を決める「プロダクト開発前の勝ちパターン発見のフェーズ」があるという話を書きました。 https://t.co/mBnerY4Uv0
— 武政成彦 / プロダクトマネージャー (@takemasa_nori) October 31, 2021

リアルなオペレーションでは「非効率」が最適解（となることも）

リリース後、なるほどな〜と気づきを得たエピソードがあります。

サービスのフロー上、ユーザーが注文した内容に店舗が受けられない場合、画面上から「予約を非承諾」とすることができ、その旨はユーザーにももちろん通知される形となります。

しかし一部の店舗様では、キャンセルした後に追ってユーザーにお電話をするケースがありました。それはお客様に対してのお詫びの言葉を添えたい、代替案の提示をしたいという思いからでした。

どうしても自分の志向性としては「効率化」「シンプルな体験」に寄った要件にしてしまいがちです。一方、高級飲食店の目線では、いかに良いおもてなしができるか、そのためには非効率なことが最適解となるケースもあるのだということは（至極当たり前なことかもしれませんが）個人的にはとても示唆に富んだ体験でした。

その視点が生まれると、予約を非承諾とした後、店舗とユーザーを滑らかにつなぐことができるのか。結果として「電話をする」という着地点に落ち着くとしても、その思考を広げることでよりよいユーザー体験・飲食店体験になっていくと思います。

終わりに

長文となってしまいましたが、飲食店が抱える課題の広さ／深さはまだまだ大きく、「GO Dine」としてもやりたいことのスタートラインにようやく立てたかな、という感覚。タクシーフードデリバリーを足がかりに、よりよい飲食体験の創出に向けて尽力していきたいと思います。

Meety出しているので、ここに書ききれなかったエピソードや感じたことなど可能な限りお話できればと思います。特にPdMの方お話したいです！

なお弊社のプロダクトに関わるメンバーでのMeetyページもできていますので、こちらもご興味ある方どうぞ！

この記事が気に入ったらサポートをしてみませんか？