こんにちは。スマートバンクでプロダクトマネージャーをやっているinagakiです。
直近で新規事業の立ち上げにプロダクトマネージャーとして携わる機会があり、初期の仮説検証を最速で行う必要があったため、”開発しない”検証を行っていました。
エンジニアによる開発をほとんどせず、外部ツールなどを駆使して2週間程度で実際にユーザーへ提供する爆速検証を行った際の、仮説を小さく検証する工夫や学びについて書いてみようと思います。
経緯
とあるテーマについて、既存ユーザーに向けた新たな価値提供とビジネスの可能性を検証するという目的のもと立ち上がったプロジェクトで、プロダクトマネージャー（PM）とデザイナーを中心に、必要に応じてBizDevやエンジニアがサポートするというチーム体制でした。
大きな仮説はあるものの具体的にはわからないことが多かったため、ターゲットユーザーの課題仮説を探索するリサーチから始め、ソリューション仮説をもとにコンセプトを行った上で、実際に提供するものの方向性を固めていきました。
開発しないから検証しやすい
今回、開発しないで検証した理由はいくつかありますが（ちょうどエンジニアの手が空いてなかった…も含まれますが）、主に以下3つの観点で選択しました。
1️⃣0→1フェーズだから少しでも早く検討や判断の材料を集めたかった
0→1フェーズにおいてはわからないことの方が多いため、最初から”正解”を当てづらく、学習とチューニングを繰り返す必要があります。そのスピードを上げるためにも、1ヶ月かけて開発してその間何もわからないより、すぐ出して少しでも情報を得られる方が、仮説検証プロセスの精度も上げやすいのではないかと考えたからです。
2️⃣負債化しないようにするため
プロジェクトとしての不確実性が高い状況においては、中長期的な構想が見えてない場合も多く、どうしても近視眼的な設計になってしまいがちです。こうしたフェーズで安易に実装をする考え方を持ってしまうことが、結果的に負債が溜まりやすいプロダクト開発になってしまうのではないかと思います。
3️⃣できることに制約がある方が検証しやすい
開発リソースが潤沢にあり、最初から開発して検証できる状況にあると、どうしても欲が出てしまうのではないでしょうか。ユーザー体験を少しでも良くしたいからこだわってしまうのがPMの性（さが）で、結果的に検証したいことよりも少し”贅肉のある”プロダクトが仕上がることで、仮説検証の精度が落ちてしまう可能性があります。
検証目的から逆算するMinimum Verifiable Productを見極める
今回の検証を考える上で、Minimum “Verifiable” Product（検証できる最小単位のプロダクト）という視点で検証設計をしてみました。検証目的から逆算して、最低限できれば良いことは何かをシンプルに捉えることで、開発しないでも検証可能な方法を考えることができました。
ここで言うMVPは筆者の造語ですが、一般的な「MVP（Minimum Viable Product）：実用最小限のプロダクト」とほぼ同義ではあるものの、PM目線で何が検証目的かを明確化するためにあえて表現として使っています。
従来のMVP（Minimum Viable Product）を考える際、大元の価値仮説から、実際はさらに細かい検証・仮説に分解され、それら組み合わせによってMVP（Minimum Viable Product）が出来上がるのではないでしょうか？
これらの細かい検証・仮説を明示的に整理しながら、「今、本当に検証したいことは何か？」を突き詰めて考えることによって、本当はもっと小さくできる”MVP”はないか探すという発想が、Minimum “Verifiable” Product（検証できる最小単位のプロダクト）で意図したいことです。
「価値が伝わる実用最小限のプロダクトは何か」という従来のフォーマットで考えるよりも、「仮説を検証するための最小限のものはなんだろう」と考えた方が、さまざまな局面で開発しないで検証する手法を見つけやすいのではないかと思います。
罠にハマらないための工夫
さて、今回開発しないで検証する中で、いくつかの罠がありそうだなと感じました。 それらの罠とそれに対する工夫についても考えてみました。
💡「結局検証できない」を防ぐために、デザイナーとコンビで進める
開発しないで検証する場合、ともすると荒削りな仕上がりになる可能性があります。
今回の検証においても部分的なLPやGoogleフォームなどを組み合わせる形で提供していたのですが、もちろんなめらかな体験とまではいかず、ところどころ粗のあるものでした。
そういった粗が検証を阻害しないようにするためにも、検証目的に合わせた情報設計は最低限担保する必要があります。そのために、デザイナーとコンビを組んで進めるのがおすすめです。
検証目的の検討から情報設計、ビジュアルやテキストの調整まで、デザイナーを巻き込むことでより精度高い検証を最小限のプロダクトで実行しやすくなります。
💡ダラダラ検証を防ぐために、終わりを決める
開発しないで検証する場合、機動性が高いがゆえに、ともすると惰性でダラダラと続けてしまう場合があります。一つ目の検証を終えて、次の検証へと、検証をひたすら繰り返すうちに「検証をすること自体」が目的になってしまう状態です。
どこかのタイミングで検証モードから本格的に開発をしていくモードに切り替えていく必要があるのですが、それが難しくなるのは（一般的には）次のモードへ移るために開発リソースの確保が必要になるからだと思います。
開発リソースを確保することは会社全体の配分調整から必要になることが多いため、すぐに可能になるとは限りません。そのため、予め「いつまでに」検証の結果「何が証明できたら」次のモードに移れるかを、経営・ビジネスサイドと握ることが重要になります。
検証期間の期限が明確になることで、それまでに検証すべきことを検証しきるという意識になれると、より検証のスピードが上がるという側面もありそうです。
💡燃え尽きないために、モメンタムコントロールをする
今回の検証の際もそうでしたかが、開発しないチームであるためどうしても人数が少ない体制になります、その結果、ともすると全社内での注目度も高くなく、取り上げられづらい存在になりがちです（幸い弊社ではカルチャー的にも然りフィーチャーして応援してくれました）。また、0→1フェーズということもあり最初から簡単に上手くいくこともなく、産みの苦しみと向き合う必要もあります。
その結果として、開発しないで検証するチームは精神的につらくなりがちです。
一方で、不確実性が高いからこそ、チームの「なんとか成功させてやる」という気概こそが成功の秘訣という側面もあり、モメンタムを作る動きが重要になってきます。
チーム内の小さな成功をしっかり祝うことや、メンバーがトライしたことへの賞賛、そして重要な一歩を歩めた時に大きく祝うなどの、モメンタムを作って維持する動きをすることで、検証活動のスピードも一段と上がるように思います。
💡思考を止めないために、PMが手作業し過ぎないようにする
開発をしない場合、非エンジニアのPMができることは多くなります。昨今さまざまなツールが増えてきたこともあり、組み合わせることでユーザーの利用に耐えうるそれなりのクオリティのものが作れるようになってきました。
一方で、その結果として細かい作業や運用オペレーションをPMがすべて抱えてしまう状況にも陥りがちです。今回の検証ではまさにそのようなことになり、大量の作業で時間が過ぎた結果、検証自体の精度を上げる改善活動に思考や時間をかけきれなかったという反省がありました。
手動のオペレーションが増えてしまうという性質がある以上仕方ない部分はありますが、分担したり作業が減る設計にするなど、PMが責任を持つべき領域に責任を全うできるような動き方をすべきだったと思います。
検証可能な最小単位から考えつつ、検証開始後も検証精度を上げ続けるための運用オペレーションを下げる工夫も初期で考えられると良いでしょう。
さいごに
まだまだ最適なやり方には至っていませんが、開発しないで最速で検証する手法を磨いていければと思っています。みなさんが取り入れている工夫や考え方があればぜひ教えてください！
スマートバンクでは0→1のプロダクトづくりも含め、ユーザーが本当に欲しかったものを見つけて届けるためのプロダクトづくりを行なっています。そんなプロダクト作りに興味がある方は、ぜひカジュアルにお声かけください。
