クックパッドが新サービスのリリースまでに捨てた10のこと　ミニマムな仮説検証を繰り返して精度を上げる

リリースに至るまでの価値検証のプロセスについて

長野佳子氏（以下、長野）：クックパッドマートのアプリはつい数日前にリリースされたのですがそこに至るまでに数々の価値検証を回してきたので、私からは「リリースまでに捨てた10のこと」と題して、そのプロセスの話をしたいと思います。

最初に簡単に自己紹介をさせていただきます。私は長野佳子と申します。2010年にクックパッドに入社して、ずっとクックパッドのレシピサービスの開発をやってきています。

おもにWebのデザインとかフロントエンドを実装するところから、だんだんサーバーサイドも書くようになって、デザイナー兼エンジニアという職種でサービス全般の開発に携わっています。

今年の初めから、買い物領域を対象とした新規事業の立ち上げというかたちで、今日司会をしている勝間と、先ほどお話しさせていただいた福崎と3人でチームを発足し、クックパッドマートの開発をしています。

今日お話しするのは、「リリースしたサービスのかたちに至るまでの価値検証のプロセスについて」ですが、この「リリースしたサービスのかたち」というところを、先ほど福崎が話した内容と重複しますが、少しおさらいさせていただきます。

クックパッドマートが解決したい課題の1つは、「おいしい食材を新鮮な状態で手に入れることの難しさ」です。

近所のスーパーに買いに行くしか選択肢がないとか、こだわりの食材を扱う専門店も街にはあると思うんですが、そもそも知らないとか、行く時間がとれないとか。お肉屋さんと魚屋さんといろいろ回って買い物をするのはけっこう時間がかかりますよね。

そこまで買い物に時間や手間をかけられないというのが今多くの人が抱える課題だと思います。

また、「まとめ買いをせざるを得ない環境と仕組み」というのも、クックパッドマートが解決しようとしている課題です。普段忙しくて、週末に1週間分買いだめするとかもよくある話です。あとは買い物の手間を省くためにECサービスを使うとしても、最低注文金額が何千円と設定されていることが多く、一度にたくさん買ってしまって、結局冷蔵庫で鮮度を落としてしまうという状況があると思います。

そのような課題に対してクックパッドマートは、「アプリから簡単に注文できる生鮮食材ECサービス」というかたちで解決策を提供しようとしています。

扱う商品はこだわりの新鮮食材を扱う専門店からの商品だけに絞り、1品からでも送料無料で購入できる仕組みを構築しようとしています。

買い物を代行すれば毎日の料理を楽しめるのではないかという仮説

ですが、始めからこの解決手段にたどり着いていたわけではなくて、ここに向けてずっと開発してきたかというとそうではないです。

チーム発足時、最初に設定したサービスの仮説は、「誰かが普段の買い物を代行してくれることで、手間やストレスが減り、毎日の料理が楽しみになる」というものでした。1対1の買い物代行のサービスというイメージです。

最初の仮説を設定して、じゃあ誰かが日々の買い物を代行してくれることに本当に価値を感じてもらえるのかというのを検証するために、実際に社内でサービスを試してみました。

最初のプロトタイプは本当にミニマムで、実装したのはスプレッドシートだけです。スプレッドシートで注文を受け付けて、それを実際自分たちで買いに行き、オフィスで渡すみたいなサービスをつくって実践しました。

その時使ったスプレッドシートはこれなんですが、商品名が並んでいて、価格があって、注文数を入力してくださいと。注文数を入力すると価格が計算されて、チームのメーリングリストに共有したら注文完了みたいな感じです。

社内テストの一環で、実際に専門店などで買い物を代行した

社内でけっこうPRして、初日だけで20名以上の注文を受けました。注文を受けてしまった以上、買いに行くしかないので、カーシェアで車を借りて3人で買い出しに行きました（笑）。

実際買い出しに行った先は、武蔵小山にある「二葉フードセンター」というところで、八百屋さんとかお肉屋さんとかお魚屋さんみたいな専門店が集まっていて、比較的安くて新鮮な食材が多いのが特徴です。

プラス、もう1店舗は品川にある巨大なイオンです。

注文されたものが欠品するというリスクをなるべく避けるために、とにかく全部ここでそろうという点で、この2店舗を買い出し対象にしました。

そして3人で二葉フードセンターとイオンの二手に分かれて買い出しをしました。これは八百屋さんでかごいっぱいに野菜を入れて大変なことになっている写真、こっちは私がイオンで牛乳とか納豆とか、日常の買い物を全部受けて買い出ししている様子です。

レジ袋にしたら20袋以上の量になっていると思います。そして買ってきたものを会社のラウンジのテーブルに広げてみんなで仕分けをするという感じでした。

私は初日イオンで5時間過ごしました（笑）。めっちゃ寒かったです。フードコートで遠隔でミーティングして、何が足りない、こっちで買ってみたいなコミュニケーションをしながら、いろいろ買ってきました。

買ってきたものはこんな感じで注文した人ごとに保冷バッグに詰めて、実際にお渡ししました。

社内なんですがもちろんお金もいただいていて、手数料を少し上乗せしたような金額で注文を受けて、その場でSquareでクレジット決済をするみたいな感じでやりました。

実際にやってみて多くのヒントが得られた。1対1の買い物代行の仮説を捨てた

こんなすごいミニマムで泥臭いテストをした結果、かなりたくさんの知見が得られました。

そこから今に繋がっているものでいうと、普段自分では買えないとか、買いづらいような商品が届くことで、すごく喜んでもらえるという発見がありました。普段買うものよりおいしかったとか、そもそも生の魚は普段買えないとかがあるので、そういうものが届くとうれしいという声がありました。

また、2つの店舗で買い出しをしてみて、複数店舗で買い出して、そこから集荷して拠点に届けるというルート配送の仕組みというのは、店舗が増えても成り立つし、コストにも見合う仕組みができそうだというヒントが得られました。

あとは、実際買ってきたお魚に対して、これはこういう食べ方をするとおいしいですよというのを、福崎が自分の経験を踏まえてアドバイスをつけて提案したところとても喜ばれて、買っただけで終わらない買い物体験というのがすごい価値があるのではないかという仮説も得られました。

一方で、いいことばかりではなくて、この検証を経て捨てたものもいっぱいあります。まず、早々に最初の仮説である「日々の買い物を誰かが1対1で代行する」というコンセプトを捨てました。

普段買っているスーパーと同等のものを届けても、あまり喜んでもらえないこともわかりました。

1対1の買い物代行というのは、そもそもスケールが難しいというのもあって、もう少し違う仕組みを考えてもいいんじゃないかなという話になりました。

あと、この時はユーザーごとに個別に包装して渡したんですけれども、ここもけっこうコストがかかるということがわかって、保冷の心配もありますし、さまざまな食材を一緒に袋詰めするのはけっこうスキルがいるんです。人によって詰め方は違うし、トマトの上には何かを乗せてはいけないみたいなこととか、そういうスキルを統一してうまく回すのはけっこうなコストがかかるよねという話になって、もう少しスマートに解決する方法がないか検討する方向に進みました。

また、この時点で家まで届ける戸別配送というのも捨てています。戸別に家まで届けるとなると、本当に大規模な物流システムを構築しなければいけないので、そういうモデルは本当に最初の段階では現実的ではないんじゃないかという話になりました。オフィスに届けるのでもけっこう喜んでもらえる部分もあったので、最初は戸別配送は諦める方向で進むことになりました。

仮説を変更してプロトタイプを作成

そして仮説を立て直しています。

本当に価値となる部分を大幅に書き換えていて、「普段買いに行けないようなおいしい食材を注文でき、日常的にオフィスで受け取れたら、毎日の料理が楽しみになる」と設定しました。

こうなると、おいしい食材を日常的に手軽に手に入れられる状態をつくってテストをする必要が出てきます。

そこで、スプレッドシートはさすがに卒業。次につくったのはWebアプリケーションでのプロトタイプです。ここでは専門店の商品だけを扱って、ルート配送の仕組みを構築して、毎週火曜日と木曜日の配送を定常的に行うことで、本当にいつでも注文ができるような状態をつくりました。

受け取りも決済をオンライン上で済ませるようにすることで、セルフで受け取れる状態にして、気軽に持って帰るだけという状態をつくりました。

実際につくった画面がこんな感じなんですけれども、商品一覧があってそこから詳細にいって買えるというだけのシンプルなECサービスです。

受け取りはこんな感じの番号がついたロッカーみたいな受け取りボックスのプロトタイプを木製本棚とプラダンでそこにいるメンバーがコツコツつくって、何番と何番のボックスから商品を取ってくださいという案内をして、自分で取ってもらう形式にしました。

この結果、毎週配送が行われるようになったので、普段の買い物の手段の1つとして使ってくれる社員が出てきて、リピート率は7割を超えるような感じでした。毎回注文するヘビーユーザーもいて、日常的に使ってもらえるようになりました。

食材の温度を基準以下に保つため保冷配達の実験を繰り返した

ユーザーはおいしい食材を日常的に手に入れられるというところに価値を感じてくれたのですが、一方で、日常的においしい食材を鮮度を保って届けるというオペレーションにはすごくいろいろな課題があることがわかってきました。

まず1個目に保冷。ちょうどこのテストをしていたのは4月か5月ぐらいだったんですけれども、暑くなってくる時期で、このボックス無理じゃない？　みたいな感じで（笑）。これじゃ夏を越えられないよねということで、プラダン製の受け取りボックスの卒業を求められました。

このロッカー形式のボックスの保冷力を高めるという選択肢もあったんですが、実際見積もりをとってみるとオーダーメイドでこういうものをつくるとすごく高くて、コスト面でのデメリットも多いし、納期もけっこうかかるので、サービス開発のスピードが落ちてしまうという懸念がありました。

じゃあ実際の受け取りの仕組みを見直して解決できないか検討し、このタイミングから商品にラベルがつくようになりました。ラベルに書いてある番号を案内し、ユーザーに受け取ってもらうという仕組みです。

先ほどのボックスは、実は24個のスロットしかないんです。商品は24種類しかなくて、そこから何番と何番の組み合わせみたいな感じで商品を用意していました。それだとユーザーさんの受け取りも楽だし、店舗が用意する商品数も絞られるので、店舗側のオペレーションも楽だよねという話で24スロットになっていました。

ですが、実際にやってみると、店舗側は普段いろいろな商品を売っているので、商品数が増えることの負担というのはあまり大きくないということがわかってきて、ユーザー側の負担は何番と何番のボックスから取ってくださいと言われるのと、ラベルの何番を取ってくださいと言われるのとでそんなに変わらないので、ラベル方式を採用することにしました。

ラベル方式を採用することで、既製品のクーラーボックスを利用できるようになり、一時期は会社のラウンジに大量のクーラーボックスが並ぶ時代がありました。

冷蔵の生鮮食品は10度以下は必ずキープしなければいけないので、そこをちゃんとクリアできるように、保冷剤の種類や置き方をいろいろ変えて毎回の配送時に繰り返し検証をして、保冷の精度を高めていきました。

ただ、実際リリース時にはクーラーボックス受け取りもやめています。現在の受け取り形式は冷蔵庫ですね。始めから冷蔵庫にしないのかよと思うかもしれないんですが、実際に冷蔵庫を置くには電源がいるので、受け取り場所での電源確保を必須にすると、サービスのスケールの障壁になると考え、当初はあえて採用していませんでした。サービス開発と並行して、受け取り場所の開拓が進んできて、受け取り場所での電源確保が現実的になったタイミングで、冷蔵庫に切り替えたという感じです。

ただ、これまでの検証で得た電源なしで保冷するための知見は、運搬時の保冷対策に今も活かされています。

販売者との関係づくりに注力

ようやく保冷問題の解決が見えてきて、日常的に食材を届けることができるかなというところなんですが、まだ卒業しなければならないことはあって、その1つは「スタッフによる買い出し」でした。

オペレーションを回すために当初はけっこうスタッフ稼働があったんです。まず、生産者や販売者から商品が配送員に渡る工程で、最初はスタッフが販売店からお客さんとして商品を買って、それを配送員に渡すということをしていたんです。

それだとスケールしないので、実際に配送員が直接店舗から商品を受け取れるような仕組みをつくる必要がありました。

そこで販売者さんとの関係づくりとか、お金をどうやり取りするかとか、どの商品をどこに持っていけばいいかというのをいかにわかりやすく伝えるかみたいなところの問題を徐々に解決していって、スタッフ稼働によるオペレーションのプロトタイプからスタッフ稼働のないリリース版のオペレーションに進んだという感じです。

さらに、スタッフ稼働でプロトタイプしていたオペレーションがもう1つあって、集荷したものを受け取り場所に配置する時にスタッフによる仕分けが発生していたんです。

スタッフが商品にラベルを貼って配置するということをずっとやっていたんですが、ここも外部化する必要がありました。

販売店で商品ラベルをお店の人に貼ってもらって、コンテナに詰めてもらって、それを配送員が持っていくだけというオペレーションを実現するために、いろいろマニュアル化したり、販売店さんとの関係づくりをした上で少しずつ実現していったという感じです。

オフィスではなく好きな場所で受け取れるという価値に置き換えて検証

いよいよ日常的に届けるというところが可能になってきたわけですが、最後に、オフィスで受け取りでいいんだっけ？　みたいなところの仮説検証が残っていました。

実際社内でも使ってくれる人はたくさんいたんですけれども、持ち帰りの負担に関する意見もなくならなくて、家が遠いから使えないみたいな話もずっとありました。ここは社内では検証しきれないところだったので、社外のユーザーさんを呼んでプロトタイプを使ってもらうユーザーテストを実施しました。

実際に社外のユーザーさんに聞いてみるとオフィス配送への懸念の温度感がよくわかりました。比較的近距離に住む社員がクックパッドは多いので、外の人のほうが通勤時間に対する懸念が強かったり、勤務先がオフィスビルじゃなくて配送拠点にならないだろうみたいな話が出てきたり、会社の雰囲気的に買い物をしている姿を見られたくないみたいな話があったりしました。そのあたりを踏まえて、オフィス配送へのフォーカスというのは考え直したほうがいいねという話になりました。

そして最後に立て直した仮説が、「普段買いに行けないようなおいしい食材を注文でき、日常的に好きな場所で受け取れたら、毎日の料理が楽しみになる」というものです。これが今回リリースしたサービスの最新の仮説です。

仮説検証を繰り返し、仮説の確度を上げていく

ようやく自分たちが信じられる仮説にたどり着いたところで、最後に捨てたのはこれまでのプロトタイプのWebアプリです。コードやデザインはもちろんなんですが、システム設計からすべてリニューアルするかたちで進めています。

サーバーサイドはそのまま使うという選択肢もなくはなかったんですが、検証とか改善をどんどんやっていると、どうしても不要なコードとか要件に合わない設計みたいなものが残るので、このタイミングでごそっと捨てようという判断をしました。

そして無事リリースされたのが現在のアプリです。

最後にまとめですが、クックパッドマートは様々な検証を繰り返して、仮説の確度を上げていくプロセスを泥臭くやり続けて、今のサービスのかたちに至っています。

その過程で捨てる判断というのがけっこう重要で、筋の悪い仮説はさっさと捨てる。最初のコンセプトを捨てたり、オフィス配送へのフォーカスを見直したりというところです。

あとは実現スピードが落ちそうな理想はいったん捨てる。ユーザーごとに梱包するとか、今後できたら本当はいいのかもしれないけれど、そこはいったん捨てないとスピードが落ちそうだよねという部分はいったん捨てる判断をしています。家まで届けるというところも同じだと思います。

さらに、検証を終えたプロトタイプは潔く捨てる。数々のプロトタイプ、アプリケーションはもちろん、実際の受け取り方法だったり、オペレーションのところのプロトタイピングも時が来たら潔く捨てる。そうすることによって、スピード感を維持してサービスづくりを進めてくることができたと感じています。

リリース後も検証と改善はずっと続いていくので、今は学芸大学駅近くだけなんですが、もしみなさんのおうちの近くに受け取り拠点ができたら、ぜひサービスを使ってみて、フィードバックをもらえたらなと思います。

少し長くなりましたが以上です。ご清聴ありがとうございました。

（会場拍手）