解①：不要な実験・開発をスキップする🏃‍♂️ - meepa試行錯誤@dotDの振り返り

前回の記事では、イントロとして背景情報を共有した上で、「どうすればもっと早く多く失敗できたか？」という問いを設定しました。

今回はその解の方向性①として「不要な実験・開発をスキップする」について書いてみます。

▼目次

• 「不要な実験・開発をスキップする」ってどういうこと？
• 1.ピボットはあえて大きく振る
• 2.褒め言葉は信じない
• 3.チームメンバーの手持ち無沙汰を恐れない
• 4.「競合がしょぼい」はダウト

「不要な実験・開発をスキップする」ってどういうこと？

詳細は前回の記事（https://note.com/kyamanaka/n/n99a0c4038843）に譲りますが、meepaは2年で3回のピボット・4回の実験を行いました。

当時は当時で一生懸命、高速で仮説検証をしようと頑張っていたわけですが、振り返ってみるとこの実験・開発はやらずに済ませられたのでは？と思うことがあります。

具体的に言うと、特にPoC#2が該当します。PoC#2には開発期間を含め半年強かけました。これが丸ごとスキップできていたらと思うと……

以下ではそう思うに至った理由や、ではどうすれば不要な実験・開発をスキップできたのか？を3+1つに分けて書いてみます。

1. ピボットはあえて大きく振る

まずは以下のスライドをご覧ください（社内のナレッジシェアに使われた資料そのまんまですw）。PoC#1（AIを用いた課外活動レコメンド）を開発含め半年強かけて実施した後に、PoC#2（課外活動コーチングチャットボット）に移行する判断を反省しています。

詳細はスライドに譲るとして、要するに、PoC#1が上手く行かなかった時点で、「AIを用いた課外活動レコメンドサービス（ユーザー課金・サブスク形式）を作ればみんな喜んで使ってくれるはずだ」という仮説が棄却されたと捉えるのではなく、もっと広く「AI的なものを用いて、何らかのアドバイス等をすることで親の行動を変えられるはずだ」という仮説が棄却されたと捉えるべきだったんじゃないかという反省です。

もちろん、論理に飛躍があるのはわかっています。ただ、ダメだった仮説の周辺でこちょこちょと可能性を模索するよりも、あえて大きく振ってみた方が、限られたリソースで世の中を変えるようなヒットに巡り合える可能性が高いのではないかと、今になって思うのです。

2. 褒め言葉は信じない

ややポジションをとったワーディングですが、次は、1で主張したピボットの大振りを、当時僕ができなかった心理的な障壁を取り上げます。

PoC#1の開発に着手する前に数十人のお父さん・お母さんにインタビューをさせてもらいました。その時の感触は抜群。たくさんのお父さんお母さんに共感してもらい、たくさんの心温まる応援コメントをもらいました。

そしてそれらがピボット判断の際にバイアスになってしまいました。「みんなあんなに賞賛してくれたんだから、やり方が間違っているだけ、方向性は正しいはずだ！」「みんなあんなに応援してくれてるんだから、この方向性を簡単に諦めちゃダメだ！」という心理です。これが大きく振ったピボットを妨げました。というか、当時は大きく振る発想さえ湧いてこなかったというのがより正確です。だって自分が取り組んでいるのは「素晴らしいサービスに決まってる」んですから。

3. チームメンバーの手持ち無沙汰を恐れない

もう一つの心理的障壁がこれです。

meepaは概ねスクラムに則った開発方法を採用していました。僕個人としては（たしか）2016年くらいからスクラムを勉強し始めスクラム／アジャイルに心酔し、meepaが待ちに待ったPO（プロダクトオーナー）デビュー戦でした。

スクラム／アジャイルを勉強する中で「開発業務の手が止まらないようにプロダクトバックログを供給し続けるのが良いPO」という趣旨の主張に何度か触れたことがあり、素直な僕はそんなPOでなければならないと（半ば無意識下で）思い込んでいました。

平時はそれで全然問題なかったのですが、ピボット判断をするにあたっても、開発メンバーを手持ち無沙汰にさせてはいけないというのが脳内をちらつきました。結果、時間をかけて深く考えることを避けてしまい、ピボットの仕方が表層的・地続き的になってしまったように思います。

4. 「競合がしょぼい」はダウト

4点目は、PoC#2からPoC#3に移行する際の仮説の立て方に関するものです。「不要な実験・開発をスキップする」という本記事全体のテーマからは逸脱してしまうのですが、今シリーズで他に入れるべきところがなかったのでここに書いておきます。

PoC#2（課外活動コーチングチャットボット）からPoC#3（課外活動EC）への移行は結構大きなピボットでした。そうできた点はよかったのですが、いま振り返れば仮説の踏み込みが甘かったように思います。

PoC#2からPoC#3への移行では、「AI的なものを用いて、何らかのアドバイス等をすることで親の行動を変えられるはずだ」という仮説を捨て、「どの保護者も習い事探しに苦労している。習い事をもっと簡単に見つけられるようにしたら、保護者に余裕が出て、一つの習い事を決めるまでに子どもに色んな体験をさせてあげられるようになるのでは？」という仮説に移行しました。

今思えば本当か？と首を傾げたくなる部分があるのはわかりますが、この仮説設定自体は今回は問題にしません。やってみなきゃわからないですから。ただ、この解決方法が踏み込み不足だったように思います。

PoC#3・#4のmeepaのイメージ（PoC#3はPoC#4の劣化版です：#3がGAS-スプシでバックエンドを構成　　していたのに対して、#4ではAWS環境でちゃんとバックエンドを開発しました）

習い事教室ホームページや既存の習い事検索サイトといった代替手段を使い倒してみて、不便だと思うところにメスを入れるような形で考えました。要は代替手段のデジタル化・イマドキ化です。結構いいサービスが作れたと自分では思います。でも、結果はついてきませんでした。

Googleには「10x」という言葉があります。「10%の改善ではなく、既存のものより10倍いいものを作ることを目指せ」という趣旨のキーワードです。

PoC#2から#3への移行にあたっては、代替手段のUXの悪さに着目し、それを潰し込んでサービスを作ろうとしたわけですが、「10%の改善」の範疇に留まってしまっていたのかもしれません。

代替手段の10%の改善で望む成果が得られる状況ならばこれで全く問題ないと思うのですが、meepaは習い事探しを少し便利にすることではなく、劇的に簡単にすることで保護者に時間・精神的な余裕を生み出し、たくさんの体験レッスンに行くこと（10倍）を目指していました。「競合がしょぼいから、ちゃんと作れば勝てる」的な発想は「10%の改善止まり」の罠にハマりやすいのかもしれません。

「解①：不要な実験・開発をスキップする」はこれで終わりです。
次は、「解②：開発を短期化する👩‍💻」です。