業務アプリの海外活用事例③DoorDash
こんにちは、クエリアの開発チームです。前回に引き続き日本ではまだ知名度が低い業務アプリの活用方法を、海外事例を用いて説明していきたいと思います。今回ご紹介するのはフードデリバリーサービスを提供しているDoorDashです。
DoorDashについて
DoorDashは2020年12月に684億ドルの時価総額でIPOを果たした、デリバリーサービスを提供するスタートアップです。2013年に設立され、米国におけるフードデリバーリー市場でのシェアは2020年11月時点で50％。２位のUber Eats(23%)に大きく差をつけています。
Uber Eatsとアプリの内容はほとんど変わらないものの、Uberが米国の500都市で展開されているのに対して、DoorDashは米国の3000以上の都市でサービスを展開しており、39万の商店・1800万人のユーザー、そして100万人のドライバーを抱えています。
2019年の時点で2,600人の従業員を抱え、売り上げは8億8500万ドル、売上総利益は3億3500万ドルに達しました。また、2020年9月末の時点では、9か月間での売り上げが19億ドル、売上総利益は9億4400万ドルと、コロナ渦でのフードデリバリー市場の急激な拡大を受けて、劇的な成長を記録しています。
配送ネットワークの構築は難航
DoorDashにおいて顧客、配達員、およびレストランはれぞれ独自の懸念と優先順位を持っているため、配送ネットワークの構築を成功させることが、物流ビジネスの成功の鍵になっていました。配達員のルートを視覚化したり、地図を描いたり、異なるレストランでの業務を毎回管理するのは煩雑な作業でした。
それぞれのチームが、DoorDashのインフラストラクチャに負担をかける非効率的なプログラムをサーバー上で実行していました。ただ配達員のステータスを「配達可能状態」に設定する、といった基本的な操作ですらも、手動で入力する必要があったhhのです。
配達員チームはそれぞれの配達員の成果に応じて報酬を与えるのですが、記入にはスプレッドシートが使われており、すべて手動で入力されていました。それらのデータはエンジニアリングチームに手渡され、都度専用のプログラムを実行して支払い処理が行われていました。そのためこのプロセスは頻繁に崩壊し、データの入力ミス、ハンドオフの失敗、および想定外のエラーが頻発していました。
フルスクラッチで作った管理画面は拡張性に欠けていた
DoorDashは配達員のルートを可視化したり、地域を管理するツールを構築するのに数ヶ月を費やしました。しかしフルスクラッチで管理ツールを作成しても、最初はDjangoのアドミンフレームワークを使っていたため、拡張性が不足していました。
効率ばかりを追求した結果、管理画面上で社員に対して過度な権限を与えてしまい、予期しない膨大なクエリが生み出され、それが原因で度々サイトがダウンしていたようです。また、それらの原因を救命するすべも当時はありませんでした。
さらに、スプレッドシートに大量のデータを手動で入力し、それらのデータをエンジニアリングチームに渡し、毎週スクリプトを実行する、といったフローでは、データ入力のミスをはじめとするヒューマンエラーを頻繁に誘発していました。
にも関わらず、カスタマーサポートチケットの解決から、新しいパートナーのオンボーディング、サプライサイド管理まで、スケーラブルな業務アプリ構築の優先順位は長い間低いままでした。
業務アプリで業務効率化を実現
DoorDashはすでに自社で管理画面を持っていましたが、ローコードツールで管理画面を作るという意思決定をしたことで、ユーザー管理と権限において、Django管理者が抱えていた権限の問題を回避することができました。さらにそれまで業務アプリの構築にかかっていた1〜2ヶ月の時間を30〜60分に短縮することができました。
業務アプリ作成においてローコードツールを使用すると必要なツールを思いついた場合に「その日中にツールの準備ができている」という状態を作ることができ、営業、運用、サポートの各チームがマーケットプレイスの運用を拡大するために必要なバックオフィスアプリをすばやく構築できるようになりました。
また、ローコードツールを使って業務アプリを作成する文化はDoorDash内に自然に広がっていったようです。業務アプリを作成するチームがそれについて何もメールをしなくてもエンジニアが業務アプリの構築について互いに話し合うときはいつでも、ローコードツールが登場し、新しいチームがそれを試していました。
ローコードツールを導入したことで、DoorDashの社内には40以上もの業務アプリができました。これはそれぞれのチームがバックエンドのエンジニアに頼ることなく自分たちに必要な業務アプリを構築することができたことで社内のデータやプロセスが民主化されたからだと言えます。
これまで、業務アプリの構築はエンジニアリソースと業務効率化のトレードオフでしたが、ローコード化することにより、このトレードオフを解決し、業務アプリの持続可能な開発を可能にしました。そしてオペレーターとエンジニアリングの時間を数え切れないほど節約し、組織は急速に成長していきました。
まとめ
DoorDashのようにすでに社内で業務アプリを作っている場合でも、それらをローコードで作成していくことでビジネスを大きくスケールさせていくことができます。
クエリアの優先テスターの方の中には、すでに管理画面を保有しているも関わらず、今後さらなる機能拡張が求められることを見越して導入を決めてくださっている方もいます。
また、メインの管理画面をローコードで置き換えるのではなく、まずは周辺の後回しになっている業務アプリや、優先度が高いにもかかわらず着手できていなかったオペレーションに対してツールを構築する、そんなタイミングでローコードを導入するというのも賢明な選択でしょう。
クエリアでは引き続き、有用な情報を発信していきます。
業務アプリ構築のローコード化に興味をお持ちいただけた方はこちら
Twitterで最新情報をcheckしたい方はこちら
その他の記事はこちら