自社専用のデリバリーサイトを手軽に作成し運用できる「DeDirect」

―なぜ「DeDirect」を作ることになったのですか？

大枝：

加盟店さまの目線と出前館の目線での理由があります。まず出前館としての目線では、加盟店が9.5 万店舗(2021年10月時点)まで増えており、マーケティング部門がどれだけ力を尽くしても、出前館の正面玄関までしか集客しきれないという問題が有ります。その結果、どうしても有名店や人気店にお客さまが集中し、個人経営の加盟店さまが出前館では売上を上げることが難しい課題が有りました。

しかし、その中でも成功している個人経営の加盟店さまをリサーチした結果、イートインで来店して頂いた、お客さまにデリバリーで注文できることを宣伝していることがわかりました。

他にも、店舗のSNS等で積極的に発信するなど、様々な集客への工夫が見られます。

飲食店さまがデリバリーで売上を上げるためには、自らお店への集客が大切で、それを実現しやすいサービスとして「DeDirect」を作ることにしました。

企画、営業、エンジニアの連携で始動

―「DeDirect」の企画・開発は、どのように進めたのですか？

大枝：

もともとASPという形で古くから存在していましたが、ここ数年間は手つかずで、営業も売ることに注力していませんでした。

注力して売らないから、ASPをもっと良くしようという企画や開発にも至らない。

加盟店さま自身で集客を頑張っていただくために、ブラッシュアップし、リブランディングし、販売も強化していこうと思いました。

もともとあったASPをモダンで使いやすいものにしていくというのが、最初の着想です。

曽我：

メンテナンスがされていなかったこともあり、出前館のサービスとの乖離が多く存在し、

利用中の加盟店さまから、何で同じ出前館なのに決済方法がこんなに違うのか等、色々なご指摘を受けました。

そこで、まずは加盟店さまからのご指摘を解消する開発を進めました。

古いシステムでしたので、ドキュメントも少なく、コードを解読しながら処理を解析しましたが、開発当初は、プロジェクトオーナーと営業、企画、開発の各セクションから1名ずつというミニマムなチームで、多くの開発権限が与えられていたので、開発自体は迅速で快適なものでした。

スピード感が命！プロダクトにかける各セクションの思いが交錯する

―苦労した点はありますか？

曽我：

手探りの状態から始めて、かつ短い期間でローンチしなければならなかったのですが、加盟店側は複数のASPカートを契約できないので、ビジネスとしては1つの椅子の取り合いになる。その上、ASPカート機能を持っている全米No.1の競合サービスがすでに仙台に上陸してきており、このプロジェクトは、加盟店さまに動いているシステムを提案できる状態にする必要が有りました。

大枝：

自社サイトをASPの形で提供し加盟店さまが主体的に集客してくれることで、"コストを抑え、売上に繋げる"そのようなビジネスを競合が先に展開し始めていたので、「このまま行かれるとマズイ」とものすごく急いでいました。

曽我：

今回良かったのは、ビジネスの要件がわかった上で開発できたこと。

例えば、このサービスを10ヶ月かけて、作ったとしても加盟店さまが、既に他のASPサービスと契約していしまっていたら、成果を上げることができません。

やはり、他のチームと連携できたことが、本当に良かったと思っています。

―各セクションの思いがぶつかることもあったのでは？

大枝：

100点のものを出したいけど、早さを重視すると、どうしても諦めざるを得ない部分も出てきます。どこが譲れない部分で、どこを後から改善するのかという優先順位付けについて、各セクションからの意見を出し合ってたくさんディスカッションしました。このプロジェクトの特徴的な部分でもありますね。

営業的にはこれだけは絶対譲れないというのもあるし、エンジニアとしてはあまり抜け漏れのあるものを出したくないし。どこの優先度を高く持ってくるのか、必ず3方向――企画、エンジニア、営業で、しっかり話し合うことを意識しています。営業としては、作られたものをただ売ってくるという立場ではなく、実際にサービスを活用するのは加盟店側なので、使う側＝加盟店さまの意見を反映するために、しっかりと主張するのが営業部であるという意識でやっています。

曽我：

特に、ぶつかるといったことはなかったと思います。

私達エンジニアは、直接加盟店さまと向き合っているわけではなく、大枝さんが加盟店さまからの要求をうまくまとめて伝えてくれていたため、私はその要求をいつまでに、ソフトウェアとして具体化するだけでしたので、開発はしやすい環境でした。

大枝：

会議は本当に真剣に行っていますね。コミュニケーションの量を多くとるようにしていますし、しっかり意見を発します。「それは絶対にイヤだ」とか、「これは絶対に違う」とか。思うことをしっかり言えるのは信頼できるメンバーだからこそですね。あまりにも縦割りだと関わりも少なくなってしまうので、横の連携をしっかりとるように意識してディスカッションしています。

曽我：

少人数でスタートしたプロジェクトでしたので、意思決定のスムーズで、少しせっかちな私には、非常に面白いお仕事ができたと思っています。

実際の運用効率と保守性を担保

―設計や実装で心がけたことはありますか？

曽我：

今回のプロジェクトは、クライアントサイド・サーバサイドともにTypeScriptを選択しました。

その理由は、多少異なるとはいえ、クライアントサイド・サーバサイドにも共通言語を利用することで、次のメリットを期待してTypeScriptを採用しました。

開発に携われるエンジニアを確保しやすいこと
クライアントサイドとサーバサイドの共通処理をNPMパケージ化できること

また、プロジェクトの処理からCI/CDを整備して余計な作業を軽減し、開発に集中できる環境を整えました。

アーキテクチャは、保守性を担保するために、フロントエンドでは、処理と表示で責務分割することで、可読性を高める工夫をし、サーバサイドでは、クリーンアーキテクチャを採用。

インフラは運用する人的コストを軽減するために、サーバレスの環境で構築しました。

―開発に関して営業からのオーダーはありましたか？

大枝：

飲食店さま向けのデリバリーサイトなので見た目やデザインはもちろん、操作のしやすさ、クレジットカード決済など、"加盟店側からみた気になるポイント" は、エンジニア側と細かく摺合せをしました。

曽我：

それが非常にありがたいことでした。私はエンジニアなので技術の部分にこだわりはあるけど、そこにこだわって作ったところで、世の中で使われないと意味がないじゃないですか。なので、加盟店さまの意見をヒアリングしてフィードバックしてもらえたことは、非常に助かりました。

作って終わりじゃない！今後「DeDirect」はどうなる？

―今後の展望などをお聞かせください。

大枝：

「DeDirect」は、加盟店さまのお店専用のデリバリーサイトです。飲食店さまのホームページの一部なので、テイクアウトの注文やイートインの予約もできたら便利ですよね。今後は、顧客管理やリテンション施策等も含めて、Webのマーケティングの全部ができるという位置づけになっていけたらいいなという構想はあります。ただ、スピード重視で動いている中、一度にそんなにフルスペックの機能をつけることはできないので、どのニーズが一番高いのか、営業しながら議論しながら決めていくという感じです。

次に実装するのはイートインの予約機能を予定しています。営業的には、「この機能がついていたら売りやすい」という意見もあれば、開発的には「その順番で出すのは危ない」というような事情もあるので、それぞれの立場からの意見を出し、話し合って納得した上で決めていきます。誰が誰に対しても一方的にならないようにしています。

曽我：

今後の展開については絶賛検討中です。目標はプロジェクトとして加盟店さまの売上機会を最大化することなので、トラフィックがより購買につながるようなアイディア出しや、分析に力を入れていこうと思っています。

何がしたいかわからないものを作るより、何がしたいかわかっているものを作るほうが具現化しやすいですね。事業やプロジェクトの目的がちゃんと理解できれば、保守しやすくも目的を損ねずに機能を実装していけます。同じ目標に向かって、エンジニアサイドからも提案していけるのが面白いところです。プロジェクト内で他のセクションのメンバーと密にコミュニケーションをとっているので、不明瞭な部分がなく仕事がやりやすい。エンジニアとして出前館で仕事をする魅力の一つだと思います。