ハードウェアスタートアップ「スマートルアー」のプロトタイプを用いた価値検証

Takehisa Gokaichi

2021年5月2日 21:31

普段はGoodpatch Anywhere目線でnoteを書くことが多いですが、今回は私がジョインしているスタートアップ「スマートルアー」での価値検証について書いてみます。

※この記事は2年前に某社にて開催した勉強会の内容を編集したものです
※記事内に紹介されているプロダクトやアプリは実際の製品とは異なります

スマートルアーとは？

スマートルアーは釣りに関するIoT系スタートアップです。センサー入りルアーで水中の状態を計測し、釣りのための分析軸を見える化するサービスを提供します。

プロダクトはセンサーの入ったルアーと分析軸を見える化するためのアプリです。

なぜ水中の状態を計測する必要があるのか？

上の写真は釣り人が何を観察するか示した一例です。釣り人は魚の状況を予測するために自然環境を多角的に観察します。

たとえば虫が近くにいそうな水辺には魚が餌を求めてやってきます (ベイトがいる、なんて言い方をします)。障害物は魚にとって隠れ家であることが多いため、障害物はキャスト時に狙い目になります。

水中環境や、ルアーの動かし方も魚の状況を知るための重要な要素です。ルアーが通った深さは？水温の境目は？濁り具合は？これらの要素は普通に釣りをする限り見えません。観察することも計測することも難易度が非常に高いです。

※釣り人の目線を疑似体験したい方はこちらをどうぞ↓

このように、数多ある自然の情報を読み取って釣りの最適解を導き出すのはとても難しく、釣り人は勘や経験、誰かのおすすめに頼らざるをえません。

自然環境や水中の状態を簡単に計測できれば、釣り人は勘や経験に頼らず、データに基づいた新しい釣りを楽しめるようになります。データによって釣りは新しい世界に突入するはずです。

リーンに開発するのは難しい

スマートルアーはハードウェアスタートアップです。スタートアップといえば、検証可能な必要最低限のプロダクトを素早く世にリリースし改善を繰り返す、いわゆるリーンスタートアップの手法をとることが多いかと思います。

私達もリーンに進めたい気持ちはありましたが、ハードウェアの開発をリーンに進めるのは無理でした。

ソフトウェアであれば自分たちで「最小」を定義して開発できますが、ハードウェアはどうがんばっても自分たちで開発を完結できませんし、最小のコストがソフトウェアに比べて大きくなります。もちろん開発するための時間もお金も大きい単位で必要になります。

ということで、Product-Market Fitまでたどり着くために必要な「最小」の定義がソフトウェアに比べて大きくなってしまうのがハードウェアスタートアップ。いわゆるソフトウェアのリーンスタートアップ的進め方でプロダクトを開発するのは難しいだろうと私たちは考えました。

そこでスマートルアーでは、ハードウェアの開発に着手する前に市場へのアンフィットリスクを可能な限り減らすべく、Problem の見直しと Problem-Solution Fit に対して重点的にリソースを投入しました。

スマートルアーの Problem-Solution Fit プロセス

1. 仮設設計
2. UIプロトタイプ作成
3. インタビュー設計
4. Problem-Solution Fit スプリント
5. その後
…というプロセスで進めました。

1. 仮設設計

こちらは琵琶湖のメンバーに向けてリモートでリアルワークショップをした狂気的取り組み。2018年だったかなと思います。

ワークショップから手に入れたメンバーの知見や見立てをバリュープロポジションキャンバス、メタファー、As-Isのカスタマージャーニーマップ、釣り人としての学びのステップなどをまとめました。そこからコアバリューとサブバリューを分けてプロダクトの役割を仮説としてまとめました。

※コアサービスとサブサービスの定義は近藤隆夫先生の授業「サービス・マネジメント論」を参照のこと

2. UIプロトタイプ作成

検証ポイントのUIプロトタイプを制作しました。XDを使った触れるプロトです。検証するのはユーザビリティではなくProblemの有無とSolutionの適切さなので、ユーザーが使い方を想像できるようなプロトタイプを作成しました。合わせて、検証に向けて何をするプロダクトなのかざっくりと伝えるパンフレットも作成しました。

3.インタビュー設計

本来であればインタビュー設計後にUIプロトタイプを作るのが正しいかと思います。このときはプロダクトの価値仮説がまだあやふやな部分があったため、UIプロトタイプを作りながらチームで価値仮説を磨き込んでいきました。

すごくざっくりと紹介すると上記のような内容でインタビューを設計しました。特に重点的に観察したかったのはProblemの「代替行動の発見」です。何をファクターとして釣り人は釣りをしているのか、データが取れない代わりに何をしているのか、データを頑張って取得している人は何をしていて、どんな分析をしているのか。さまざまな代替行動がある前提でインタビューを組み立てました。

4. Problem-Solution Fit スプリント

詳しくはお伝えできませんが、1つの価値を検証するために4サイクルのスプリントを回しました。

インタビューは基本リモートです。この頃はappear.inを使っていました。懐かしい…。

インタビューではたくさんの代替行動を教えてもらいました。

ペルソナは3回修正しました。

釣りに対するメンタルモデルのマッピングも3回修正しました。

UIも3回修正しました。あくまで検証用の修正です。

スプリントを終えた結果のまとめはスプレッドシートで。インサイトごとにダメージレベル✕利用頻度✕人数でスコアリングしました。

結果を受けてコンセプトをアップデート。

MVPとして必要な機能をNotionに記載しました。

提供価値が明確になったので、チームのビジョンを改めて見える化しました。

====
このような流れで価値検証を行うことで、スプリントの中でProblemの見直しと初期仮説のSolutionを変更し、ハードウェア量産前に市場へのアンフィットリスクを減らすことができました。

段階ごとのプロトタイプ活用方法

ProblemとSolutionの関係が適切か、SolutionとProductの間が適切かを知るために必要なプロトタイプのあり方は変わります。

Problem-Solution

この検証は、解決策が顧客の課題を最適に解決できるかを探すことを目的とします。そのためにプロトタイプは価値が正しく伝わる必要があります。

ひょっとしたら実際にプロトタイプが動くことは重要ではないかもしれません。その解決策がユーザーにとって意味があるかを探るためであれば、プロトタイプを動かすよりもカタログや説明入りのスクショを使って確実に価値を伝える方が適切な場合もあります。

なので、ユーザビリティテストと違ってユーザーがUIへのモヤモヤにぶつかったら基本的には救ってしまったほうがよいです。もちろん機能など何かの価値を期待した上でUIへのモヤモヤを感じている様子であれば、その価値を自分で語ってもらうまで泳が続けます。

検証は対話、インタビューが中心になるかと思います。

Soution-Problem

この検証は、顧客の課題を解決できる策が実際にワークするかを確認することを目的とします。そのためにプロトタイプは実際の利用体験に近い必要があります。

プロトタイプは開発段階に応じて細かく確認していくべきです。紙芝居レベルの段階、擬似的に動く段階、通信できる段階それぞれで確認するのが望ましいです。

検証は観察、ユーザビリティテストが中心になるかと思います。

ダメなプロトタイプの例

この写真は初期のプロトタイプに使っていた写真です。左側の写真はプロトタイプとして使ってはいけない写真でした。なぜでしょうか？

スマートルアーは現在バス釣りをメインにしたルアーを開発しています。ですが左側の写真に写っている魚はバスではありません。右の写真はバスなのでOKです。

インタビューをする釣り人はルアーの形や大きさで何が釣れるルアーなのか判断できます。アプリに掲載される写真とルアーのタイプにギャップがあると釣り人は「これはおかしい」と気づきます。私のように釣りに詳しくない人間にとっては些細なことですが、釣り人にとって魚種は非常に重要な情報です。このギャップのせいでインタビューが成り立たなくなってしまいました (内部のプレテストで気づきました)。

このように、コンテンツにリアリティが無いと価値を正しく想像できません。写真と同じくグラフにリアリティが無い場合も価値を想像しにくいでしょう。

同様に、その業界や領域で使われている言葉や表現の使い方が間違っていると、言いたいことが正しく伝わらないでしょう。