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

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

Takehisa Gokaichi

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

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

スマートルアーとは?

画像1

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

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

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

画像2

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

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

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

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

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

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

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

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

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

画像3

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

画像5

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

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

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

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

1. 仮設設計

画像5

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

画像6

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

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

2. UIプロトタイプ作成

画像7

画像8

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

3.インタビュー設計

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

画像9

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

4. Problem-Solution Fit スプリント

画像10

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

画像11

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

画像12

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

画像13

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

画像14

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

画像15

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

画像16

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

画像17

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

画像18

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

画像19

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

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

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

画像20

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

Problem-Solution

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

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

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

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

Soution-Problem

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

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

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

ダメなプロトタイプの例

画像21

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

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

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

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

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

答えよりヒントや洞察を

画像22

当然ですが「何が欲しいですか?」という問いをそのままプロダクトにしても良いものにはなりません。フォード氏の言うとおり、Problem-Solution Fitの段階ではヒントや洞察を得るためにプロトタイプを活用しましょう。

※有名な逸話ですが、フォード氏はこんな発言をしていないという話を勉強会で聞きました。

まとめ

画像23

この写真は「4か月間、1匹も魚が釣れない」という悲しい釣り体験をしたという代表・岡村の水中データ取得実験の写真です。この頃は支笏湖でコツコツとデータ集めをしていました。

こんな感じで、ソフトウェア系スタートアップのようにアクセル全開で前に進むことはできませんでしたが、スマートルアーは地図を見ながら着実に前へ進んできました。

画像24

そして、ついに最初のプロダクト「smartLure Model Zero」を先日発表しました!もうすぐ釣り人のみなさまへプロダクトを届けることができる見込みです!!

TSURIHACKTechCrunchAXIS Web Magazineにも取り上げられたました!わーい!!

現在、クラウドファンディングサイトKickstarterでsmartLure Model Zeroの予約を受け付けています。おかげさまでProject we loveにもピックアップされました。みなさまご興味あればぜひポチってくださいませー!

Kickstarter
https://www.kickstarter.com/projects/1942670366/smartlure-model-zero

日本語訳
https://labs.smartlure.co/2021/04/26/smartlure-model-zero_pre/

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
Takehisa Gokaichi
Goodpatch Anywhere デザインマネージャー / リモートワークファシリテーター / UXデザイナー。