飲食店とのネットワークにより実現できる体制。「delico」はなぜ顧客の要望を最短“翌日”にリリースできるのか？
現在、のべ20万店舗以上の飲食店がデリバリー・テイクアウトにチャレンジをしており、そのうち約10万店舗が利用するデリバリーサービスごとに複数のタブレットを保持していると言われています。端末をひとつにまとめたいというニーズを解決するため、株式会社フードテックキャピタルはフードデリバリー注文一元管理システム「delico」を提供しています。
今回は、サービス立ち上げにおいて重要な役割を担った取締役の中村英樹と、技術の側からサービスを支え続ける取締役兼CTOの南里勇気にインタビュー。開発において重視したことや、可用性・信頼性を向上させるためのエンジニアリングの工夫などを聞きました。
中村 英樹
株式会社フードテックキャピタル 取締役
2005年大学在学中に株式会社subLimeの創業に参画。2008年株式会社ベンチャー・リンク入社。2009年株式会社subLimeの取締役副社長に就任。その後10社以上のM&Aを重ね450店舗、年商300億円まで成長。 現在はファンド傘下でGYRO HOLDINGS株式会社と関連子会社の取締役を現任しつつ、フードテックキャピタルの取締役を務める。
南里 勇気
株式会社フードテックキャピタル 取締役CTO
慶應義塾大学経済学部卒。在学中から株式会社MEDICAでシステム開発、大手調剤薬局チェーンと共同研究で論文発表。2015年株式会社FiNCに新卒入社してAndroidチームマネージャーとしてアプリ改善、GooglePlayベストオブ2018「自己改善部門」大賞受賞。同年米国シリコンバレーでFiNC Technologies USオフィスを立ち上げる。2019年から中国でハードウェアを開発、テックリードとしてプロダクトをローンチ。2020年6月Bison Holdingsを創業
開発の優先順位は「早い、うまい、安い」
――まずは「delico」のサービスコンセプトをいかにして構想したのかを伺います。
中村：ソフトバンクのビジョン・ファンドが日本円にして125億円をOrdermark社に出資したニュースを2020年の末に目にしたことが、「delico」のサービスコンセプトを立案したきっかけになっています。Ordermarkはフードデリバリーのアグリゲーションサービス*やバーチャルレストランのフランチャイズなどの事業に取り組んでいる海外のスタートアップ企業です。
*…複数の企業が提供するサービスを集積し、1つのサービスとして利用できるようにしたサービス形態。
当時はフードデリバリーサービスが日本でも徐々に普及しており、アグリゲーションサービスのニーズも確実にあると考えました。そこで、2021年上旬にボードメンバーを集めて開発プロジェクトを本格稼働しました。プロジェクト最序盤では、国内外の各種フードデリバリーサービスやアグリゲーションサービス、POSレジや注文管理システムなどをいくつも調査して「delico」の要件を決めていきました。
南里：中村さんの存在は、「delico」のサービス開発において不可欠だったと考えています。中村さんはこれまで、株式会社subLimeや株式会社ベンチャー・リンク、GYRO HOLDINGS株式会社*といった飲食店の経営を支援する企業で働いてきました。そのため、飲食店の業務内容を深く理解しており、かつ事業の将来性も判断できます。
*…GYRO HOLDINGS株式会社はグループ合計で450店舗の飲食店を経営する。傘下のブランドに「ひもの屋」「北の家族」「WIRED CAFE」などがある。
中村：フードテックキャピタルへの参画を決めたのも、これらの企業での経験が影響しています。私はGYRO HOLDINGSの業務を通じて「飲食業界の利益率を向上させなければ、業界の未来を救うことができない」という危機感を覚えていました。
改善のためのキーワードは「テクノロジー」と「マーケティング」だと考え、数えきれないほどの施策に取り組みました。その過程で、テクノロジーを活用して飲食業界を変えるには、開発を外部のシステム開発会社にアウトソーシングするような形態では難しいと思うようになりました。
内製の開発組織で、機動性高く動ける小規模なチームを組成し、コミュニケーションを密に取りながらプロダクト開発を進める必要があります。その考えが、自社開発を推進するフードテックキャピタルの魅力を感じた理由にもなっています。
――「delico」のMVP*を作成するにあたり、どのような基準で盛り込む機能とそうでない機能の判断をしましたか？
*…Minimum Viable Product。顧客に価値を提供できる最小限のプロダクト。
南里：中村さんが挙げたのが「早い、うまい、安い」の順番で機能開発するという判断基準でした。可能な限り、早くリリースすることを大前提に機能開発をする。たとえば「delico」で飲食店のメニューを取り扱えるようにするならば、機能開発に数か月ほどかかってしまいます。これは「早い」に反しているので、機能を落とそうと決めました。
初期リリースでは「注文の一元管理」の機能にフォーカスしたことが伺える。
中村：通常であれば、システム開発会社は「顧客に提供するプロダクトなのだから、初期リリースの段階でもある程度ニーズを満たせるように、機能を充実させておこう」と考えます。しかし、それでは機能提供のスピードがどうしても遅くなってしまいます。
私たちフードテックキャピタルはこれまで財務コンサルティング事業やキャピタル事業を通じて、外食企業・店舗とのネットワークを形成しています。それらのつながりを前提として、「最小限の機能のみを実装したプロダクトを、すでに関係を構築できている企業にスモールスタートで導入する」という施策ができます。最初からすべての飲食店の業務を完璧にデジタル化する必要はないわけです。
――他の指標である「うまい」と「安い」は何を意味するのでしょうか？
南里：私たちはプロダクトのUXを向上させることに注力しており、これが「うまい」を意味しています。現場の方々にとっての使いやすさを追求することが、LTV*に寄与するかというと、必ずしもそういうわけではありません。しかし、金銭的なインパクトとして可視化しづらい部分こそ、コツコツ積み上げて投資していくことが重要です。
数年のスパンでみたときに、他社と比較しての大きな競合優位性になる部分だと考えています。これを実現するには、プロダクト開発の予算を惜しまないことが重要だと考えているため「安い」の優先度は一番低い、という意味合いです。
*…Life Time Value。日本語では「顧客生涯価値」と呼ばれる指標。特定の顧客が自社と取引を開始してから終わるまでに、もたらす利益の総額。
「顧客になるべく早く価値を提供する」ためのdevOps
――サーバーの運用はどのような方法を採用していますか？
南里：サーバーの運用に関しては、AWSをうまく活用しており特に難しいことはしていません。コストやセキュリティを意識したうえで、最小限の構成にしています。
データ分析基盤や外形監視なども、初期段階では最低限です。あとからトラッキングできるようにAmazon S3にデータを格納したり、Amazon CloudWatch上で監視したりできる状態だけは構築しています。また、緊急のアラートに関しては自動通知の仕組みを構築しながら、すぐ対応できる運用にしています。
「delico」の運用の特徴として、toBの事業であるため店舗数が予測できること、そして利用シーンが決まっているためトラフィックの予測がしやすい点が挙げられます。具体的には、以下のような傾向があります。
11:30〜13:00、18:30〜20:00頃だけトラフィックが急増する
1店舗で処理できるピーク時のスループットが決まっている（1注文を2〜3分で扱えるとしても、店舗が捌けるのは1時間あたり20〜30注文)
そのため想定外のトラフィックは起こりにくいですが、とにかく可用性・信頼性が重要になるシステムであるため、インフラ運用も含めたdevOpsには注力しています。
――とはいえ、どれほど可用性を高めてもシステム障害は必ず起きてしまいます。そうした場合にはどのような対応をとっていますか？
南里：エンジニアがシステムの復旧を行うだけではなく、障害を検知できたタイミングで「delico」の導入店舗に対してカスタマーサクセスのメンバーが連絡します。飲食店のスタッフが障害に気づくのと、カスタマーサクセスから連絡がきて対応方法を教えてもらえるのとでは、飲食店側の業務の負担やサービスに対する印象が全く違いますよね。こういった対応によって、障害が起きても関係性を守り、信頼してもらえるよう注力しています。
――開発のサイクルやdevOpsの体制はいかがでしょうか？
南里：私たちの開発スタイルの特徴として、顧客に本質的な価値を提供するための機能を開発するチーム（メインストリーム）と、短期的なスパンでの改善を行うチーム（タスクフォース）という2種類のチームが存在していることが挙げられます。前者のチームは2週間を1スプリントとして運用するスクラム開発を採用しています。後者のチームはより高頻度に、週に複数機能の開発とリリースを行います。
――なぜ、それぞれのチームで担当する機能の粒度が異なるのですか？
南里：私たちは「delico」のトライアル導入の制度を設けています。これは、特定店舗で1か月ほど「delico」を試しに利用してもらい、気に入っていただければ本格的に導入を行う制度です。2週間のスプリントでスクラム開発を推進すると、トライアル導入の間にユーザーが「プロダクトが改善した」と実感できるタイミングが2回しかありません。
そこで、営業やカスタマーサクセスのメンバーが飲食店の要望を拾い上げ、後者のチームが細かな機能改善に対応することで、多いときには1週間に複数回のデプロイを行っています。これにより、ユーザーの方々は「かなりのスピードでプロダクトが改善している」と実感されています。また、デプロイ数が多いこととトレードオフになりやすい安定的なデリバリーを担保するために自動化・仕組み化に注力しています。
この体制構築にも、中村さんの築き上げてきたアセットが相当に活きています。これまでの事業のなかで飲食店との強固なネットワークを構築しており、「delico」をそれらの店舗に導入しています。店舗との関係性があるからこそ、システム導入やヒアリングをスムーズに行うことができています。
他に、飲食店との関係性があるからこそ実現できるdevOpsの体制としては、開発環境やプロダクション環境に加えて、エクスペリメンタル環境を設けていることです。これは、プロダクション環境へのリリース前に、新機能などを実店舗で試すために設けている環境です。
自社の運営店舗やフードテックキャピタルとの関係性がある店舗の協力を仰ぎ、「delico」を導入していただいています。特定環境のみで起こる不具合やデータに依存して起こる不具合などがあれば、エクスペリメンタル環境で検知することで、ユーザーへの影響を最小限にとどめることができます。
また、私たちはキッチン付きのオフィスを保有しており、自社でバーチャルレストランを運営しながら「delico」を検証しています。
プロダクト開発の初期フェーズでは、エンジニアやプロダクトマネージャー、デザイナーなどからなるチームがこのオフィスに集まり、アイディア出しや仕様決め、開発を進めてきました。現在でも、エンジニアの開発拠点としてこのオフィスを活用しており、「delico」のユーザビリティ検証や注文テストなどを、実地環境を用いて行うことができます。現場ならではの発見などが得られる場になっています。
注文一元管理だけではない。統合的な食のプラットフォームへ
――事業の今後の展望についてもお聞かせください。
中村：私たちが取り組みたいのは、フードデリバリーの注文情報一元管理だけではなく、飲食店のありとあらゆる業務の最適化です。たとえば、飲食店の顧客情報や発注・在庫情報といった、多種多様なデータを統合的に扱えるプラットフォームを構築したいと考えています。
それを実現できれば、さらには食品の原材料を担う農業や畜産、水産業の最適化にも結びついていく。フードテックキャピタルを、食の世界を入り口から出口まで扱う会社へと変えていきたいと考えています。
南里：食というドメインは、それくらい大きな可能性がありますからね。「衣食住」と言われる、人間に必要な3要素のうちのひとつですから。最終的には、飲食に関連するどのような事業も私たちのシステムで支援できるようになりたいです。
だからこそ、今後はソフトウェアエンジニアリングだけではなくて、IoTやデータ分析・機械学習、生化学の専門家とのコラボレーションなど、さまざま要素を取り扱うことになるでしょう。誰もやっていない領域にチャレンジしたいエンジニアにとっては、非常に楽しく働ける環境です。自分のエンジニアリングの専門性を高めつつも、ユーザーに価値を提供することにフォーカスできるような人が、活躍できる職場だと思います。
フードテックキャピタルでは、各職種を絶賛採用中です！記事を読んで興味を持ってくださった方々は、お気軽にご連絡ください。Meetyにてカジュアル面談の機会も設けております。