cover image
🚀

新サービスづくりってむずかしい - 仮説検証という沼

カテゴリ
BizDev
書いた人
Taiki Abe
URL
公開日
2021/09/30
 
どうもこんにちは。
株式会社diddyworksでCPOとして働いてる阿部大樹です。
 

仮説検証

仮説検証とは「ある現象を合理的に説明するために、仮に立てる説」(辞書引用文)。 簡単に言うと、こうかもしれないぁと思う疑問や予測を数値や事実確認を提示して答え合わせをすること(ネット引用文)。
むずい。そもそも文章としてむずい。(俺の頭では)パッと見わかんない。
普段、自分たちは仮説検証なんて意識しないでやってると思います。 例えばプログラミングをしててバグったときは、「〇〇あたりが原因かも」という仮説を立てて、本当に〇〇が原因でバグっているのか、実際に見て動かして、検証を通してバグの原因を突き止めます。
このような工程を色んなシーンで普段無意識でやっているからこそ、あえて意識して言語化しようとする(新サービスをつくる上で当然のことなんだろうがw)と、これがめちゃくちゃ難しかった。
現在、弊社の新サービスをつくるために日々試行錯誤して進めているのですが、その中で「新サービスをつくり始める前に、課題や解決方法の仮説を出してちゃんと言語化し、検証してからつくり始めよう!」みたいなフェーズがあって、皆で試行錯誤しまくった日々がありました。そんな日々を経て、自分が感じたことを書いていこうと思います。

lissスポーツ施設管理システムにおける仮説検証

そもそも「新サービスをつくり始める前に、課題や解決方法の仮説を出してちゃんと言語化し、検証してからつくり始めよう!」となったきっかけとして、弊社では過去に「lissスポーツ施設管理」というサービスをつくりました。
当時は、つくり始める前に一切仮説検証をした記憶がなく(仮説の言語化すらしてない)、ある程度考えたレベルでつくり始めたサービスだったため、結果色んなことで失敗しました(もちろん良かったこともある)。
そういった経験があるため、次同じような失敗はしないぞ!というきもちで本腰を入れ、新サービス「PJX(プロジェクトXという仮名)」の仮説検証(期?)に入りました。

スポーツにおけるコーチングの課題を解決するサービス「PJX」における仮説検証

コーチングの課題は最初から割とはっきり見えていました。
しかし、その課題に対する解決方法を探る段階で沼に入った気がします。どんな方法で解決するのが適切か?とばかり考えていたので、アイディアは無限にでてきてたけど、その場合以下のようになりがちでした。
例えば、Aという解決方法(仮説)が本当に適切なのかを検証中に、Bという解決方法(仮説)が出てきて、目移りしてしまい、Aの仮説検証に対する熱が冷め、結局検証せずに終わる。これをA→B→Cみたいな感じでやたら繰り返してました。
例えば、Cの解決方法を検証しようとしてるけど、これって面白いかな?や、本当にやりたいことなのかな?サービス化しても続くのかな。など、想像してしまったり。
つまり羅列したアイディアの時点で順に検証しようとしていたので、そこには「こうやって解決したい!」のような熱量が乗っておらず、右往左往して沼化しました。

課題の解決方法(仮説)はやりたいことベースで考えるべき

どんな方法で解決するのが適切か?と考えるとアイディアが無限に出てきます。
しかし、その時点で仮説検証に入ろうとしてはいけないということを学びました。適切な解決方法ばかりを模索してしまい、本来何をしたかったのかを見失います。
そうではなく最初から、そもそも自分は、これらの課題をどんな方法で解決したいのか?という考え方をしていれば、そのアイディアには自然と熱量、自信、愛着が乗っかってきます。それらの感情が乗ったアイディアであれば、仮説検証〜サービス化までブレずに進められると思います。
ある程度客観視することは大事ですが、自分の感情を見ないフリして進めると後々辛くなる、ということがわかりました。
自分の思いつきのアイデア自体には価値はないのでそこには思い入れは持ちません。愛着も必要ない
こんな考え方もあるっぽい。 本当に価値はないのかな? そもそも自分で「価値はないかも」と思っているものを検証することに価値はあるのかな?
こと白紙の状態からサービスを考えるフェーズに関しては、この考え方ではうまくいかないんじゃないかな。と今でも強く思います。
 
 
とまあ頭がカオスってきたところで脳ミソを切り替えて仕事します。 切り替えがとっても下手くそ。
今俺の脳ミソはこんなかんじ。
 
最近宮城はめっぽうさむいですなあ。しかし。