207はどのように事業を思いつき、そして、検証・失敗してきたのか

207株式会社

2022年3月7日 18:12

いつでもどこでもモノがトドク、世界的な物流ネットワークを創りたい、207株式会社のイナバです。

実は、弊社の1つの事業である「スキマ便」を一時停止することになりました。
そこで今回は、「スキマ便」を例に挙げて、「どのように事業アイデアを思いつき、そして、検証・失敗してきたのか」というお話をご紹介します！

なお、本記事公開と連動し、「事業で経験した失敗について、話せる限りの事をご共有します」という弊社代表の高柳さんとのカジュアル面談を公開しました！

少しでも「この記事よかった！」と思って頂けた方はぜひ、ラフにお話でもさせてください！

アイデアを思いついた背景

今回お話しする事業・「スキマ便」は一言で言うと、配送初心者のギグワーカーを使った配送サービスです。

従来のデリバリーサービスとの大きな違いは、2点。

1つ目は、フードデリバリーに関わらずeコマースの軽貨物も配送している点。
2つ目は、配送員としてギグワーカーをアサインしている点。

です。

Uber Eatsなどのフードデリバリーにギグワーカーをアサインする仕組みは一般的になってきましたが、eコマース（軽貨物）の配送にギグワーカーを採用するサービスは見当たりません。

ということで、スキマ便は「一般のeコマースの配送にギグワーカーのリソースをうまく充てることができれば、配送業界の人材不足を解消できるのでは？」という仮説を実証するために開始したサービスです。

まずは、この事業アイデアを思いついた経緯からご紹介します！

どんな経緯でアイデアを思いついたのか

207のメイン事業として「TODOCUサポーター」というサービスを展開しています。
TODOCUサポーターは配送の効率化を支援するサービスです。

TODOCUサポーターを使って配送員が荷物を運ぶことで、

・どの配送ルートが最適か
・〇〇さんは13:00頃に家にいる

などのデータが蓄積されます。

そこで、2019年の夏頃、「このデータを使うことで、配送初心者でも効率的な配送を実現できるのではないか」と構想しました。

単にギグワーカーを使用した配送サービスを行っても、配送に関する知見がないので、非効率が否めません。

一方で、207はTODOCUサポーターの提供を通して配送効率化データを得られるので、ギグワーカー×配送というモデルが成り立ち、配送業界の人材不足を解消できると考えたわけです。

そこで思いついたのが、ギグワーカーの「スキマ時間」を使って配送する「スキマ便」というサービスでした。

また、TODOCU事業は「配送効率化」というマーケットしか対象としていなかったのに対し、スキマ便は「配送」という、より大きなマーケットが対象となります。

この点もスキマ便のスタートに踏み切った理由でした。

ちなみに着想当初、スキマ便はTODOCU事業が完全に軌道に乗ってから開始するつもりでいましたが、2020年初頭に新型コロナウィルスの感染拡大によって配送（特にeコマース）への需要が急増。

「このタイミングを逃してはいけない」と思い、当初の予定から1〜2年前倒しでスタートしました。

…

どのように検証したのか

スキマ便の検証は2パターン実施しました。

検証① フードデリバリーと軽貨物を組み合わせる
検証② 軽貨物のみを扱う

早速、それぞれについて、検証方法と検証結果を紹介していきます。

検証① フードデリバリー×軽貨物を組み合わせる

フードデリバリーは昼食と夕食のタイミングで配送が集中します。その空き時間（例：14:00~17:00）に軽貨物を運ぶことで、配送リソースを適切に配置できて、黒字が出やすい体質になるのではないかと仮説を立てて検証しました。

検証結果①

結論、オペレーションコストがハンパじゃなかったです！

フードデリバリーの荷物は需要予測が困難です。急に依頼がきて、15分以内や30分以内で届ける必要があります。

そのため、配送リソースが足りなくなったら、配送をストップするなど、需給のマネジメントが求められました。

このオペレーションが煩雑！！！
かつ、属人化される！！！！！

対応策として、例えば、フードデリバリーシステムとスキマ便システムをAPI連携して、「一定の注文以上は受け付けない」といったシステム化ができれば良かったのですが、

TODOCUに割くエンジニアリソース
スキマ便に割くエンジニアリソース

の両方を採用する事はスタートアップとして、かなり、ハードルが高いものでした。

ちなみに、エンジニアリソースだけでなく、そのAPI連携を可能にするためにフードデリバリーシステムサイドとも折衝しなくてはならないので、ビジネスサイドのリソースも不足していました。

検証② 軽貨物のみを扱う

そこで次に挑戦したのが「軽貨物のみを扱う」という戦略です。

軽貨物だけを配送する場合、フードデリバリーのような緊急性の高い配送がありません。
そのため、前日までに荷物数がわかり、それに合わせてギグワーカーをアサインすればよいというわけです。（つまり需要予測が可能！嬉しい！！）

軽貨物だけを扱うサービスの検証を小さな地域（例：目黒区・品川区の中の一部地域のみ）で検証しました。

…

一旦、ここでCMです！

207ではあらゆるポジションで絶賛採用募集中です！！！！！！

本noteを読んで「ちょっとこの会社の事を調べてみようかな」と思って頂けた方はまずは、コチラの動画を見ていただけると会社の事がよくわかるかもしれません！（1:55:15~）

よろしければ、カジュアルに面談でもしましょう。

もちろん、直接の採用応募も、とっても嬉しいです！

...

......

以上、CMでした！！それでは続きをどうぞ！！！

検証結果②

結論、小さい地域だけでは難しかったです。

まず、荷物獲得するときの営業が非常に難しい。

荷主さんが日本全国に配送する企業の場合、小さな地域のみを207が受け持っても全体の極々一部になってしまうため、多少配送料が安くなってもメリットを感じづらく、スイッチングコストが勝ってしまいます。

ということで、「目黒の1丁目~4丁目だけを担当させてください」といった交渉がかなりハードでした。（「東京都全体を見てくれるなら良いんだけどねぇ」となってしまう。）

次に、小さな地域ではオペレーションコストを下げるロジックが働かないという点も課題でした。

スキマ便を検証したエリアの単位を1とするならば、207のオペレーターが担当できるエリアは10エリア分くらいあるのです。

喩えると「ロケットでコンビニに行っている」というようなオーバースペック感が否めず、対応地域を広げないと規模の経済が働かないという事が分かりました。

一方で、そもそも小ロット（〇〇区△△丁目という単位）で配送業者を切り分けている荷主さんからは支持を獲得できたのが、この検証で得られた知見でしょうか。

つまり、必要な投資をして規模を拡大すれば事業として成り立つという手応えを得ることに成功しました。（だけど、スタートアップとしてそれをやるのが超超超超超たいへん！！）

スキマ便の反省点

ということで。

検証①に関しては、リソース不足でした！

逆に、しっかりとリソースを確保して、必要な条件を揃えたうえでスタートすれば事業として展開できるという手応えも得ました。

検証②に関しては、一定規模のエリアを獲得できるような投資が必要でした！

事業所や配送リソースを事前に準備して、荷主さんが仕分けているロット数に沿った範囲で展開するのが合理的です。

以上がスキマ便の検証から失敗までの過程なのですが、本事業のポテンシャル（＆記事では明かしていない足らない要素）を確認できたので、リソースを確保して、いずれ再度チャレンジしたいと思っています！

今後の展開（ピボット）

今後は「スキマ便」というサービスは一旦ストップして、スキマ便のリソースをTODOCU事業にスライドします。

が！引き続きスキマ便のオペレーションは残す予定です。

自社で配送リソースを持つことはTODOCUというプロダクトの改善サイクルを早める事に役立っているためです。

ということで、全社的にTODOCU事業へフォーカスを当てているのですが、このプロダクトが現在、急成長しています！！！人が圧倒的に足りません！！！！

ということで、全職種大大大募集中です！本記事を少しでも良いかも、と思っていただけた方は、カジュアルに面談でもしましょう！