仮説に仮説を積み重ねるのはもうやめよう -事象ファースト-
複数daysインターン「あるある」
夏インターンもひと段落すると、ジョブやインターンでこんな気持ちになった経験が生まれたのではないでしょうか?
もちろんみんなで「正しそう」な結論が出た時点で、他チームと比べて優秀なチームだったかもしれません。ですが、上記の感想が出てくるような案に自分の資金/時間をフルベットできるでしょうか?
あらゆる制約を排除してビジネスのことを考えるなら、「確実にユーザーが使ってくれる・反応してくれる」と一定の確信を得られる事業案/施策案を作りたいですよね。
でも大体出てくるアウトプットには確信がない。もしくは確信していたけど最終発表の質問の回答を準備しているときに半ば自分を信じ込ませるようにロジックを書いている。そんな事象を自他ともに目撃してきました。
そんな事象を経験したことのある皆さんには有益になるであろうtipsを、自分の思考の整理と体系化のためにドキュメントに落としてみました。
「あるある!」と思うようなワークのプロセスやアウトプット例も2つ挙げています。
お手隙の際にご興味があれば、ぜひご覧ください。
「正しそうだけど腹落ちしない」理由
この事象が起こる理由はもちろん時間的/資金的な制約にあります。
しかしその制約があると踏まえた上でも、チームメンバーの「仮説思考」や「イシュードリブン」という知的生産プロセスに対する理解の浅さも一定この事象に影響していると考えています。
とはいえ僕らはまだただの学生。テニスラケットとストロングゼロを握るくらいしかやったことがないですよね。
そこで学生でもできる効果的なイシュードリブンの考え方、「事象思考」について自らの考えをまとめます。記述内容的に、ある程度コンサルのジョブや複数日数インターンを踏んだ人向けになってしまったかもしれません。
この記事を書いている人
お分かりの通り、このドキュメントは「学生のご高説」です。決して信じることなく、自分としては全力で今考えていることをぶつけに行くので、「これは違うな」「これはそうだわ」というような感じでご自身の思考の種にして欲しいです。本来ならここで「MBB内定」「外資系含め9社に内定 / 有益な情報を発信中」みたいな権威づけをするべきなんですけど(笑)
仮説は検証するまで妄想である
大前提なのですが、仮説というのは乱暴に言ってしまえば妄想です。
これらは全て妄想、「お気持ち」です。
そしてこの「お気持ち」は現実世界ではほぼ外れます。
仮説は検証して初めて効果があります。
一見「上出来」 でもダメな仮説検証の進め方
ここまで読んだ読者の方は
と考えると思うのですが、個人的には上記のような雑な理解が腹落ちしないアウトプットの原因なのではないかと考えています。
ここにいわゆる「上出来」だけどダメ(だと自分では思う)なチームのアウトプットまでのプロセスを書いておきます。
「ダメ」というのは、これは本気で事業について向き合うならば良くないプロセスだということです。
具体的にどの部分がそうなのか、ぜひ考えながら読んでみてください。
優秀そうなチームですし、自分もこのようなプロセスでワークをして満足していた時期もあります。
ですが、この「転職プラットフォーム」、本当に使ってくれるでしょうか?
さて、このサービスを(ひいては、あなたがこれまでインターンやジョブで提案してきたあらゆるサービス/施策案を)実現させるためにあなたは全資産を投げ打って&個人名義で借金できるでしょうか?
もちろんこの問いに「はい」と答えられるような案を数日の議論のみで作れるわけありません。
しかし、「細かいところはまだわからないけど、もう少し検証したら高確率でイケそう、そのために数十万 (社会人のみなさんへ:学生基準、これは高い額なのです) くらいなら投げ打ってもいい」という感覚を得るところまでは目標にしたいところです。
「正しそうな妄想」のワナ
上記のプロセスの真に問題な部分はどこか。
それは「論理のコアな部分から仮説を排除できていない」
ことにあると考えています。
例えば、先例で「サービスの提供価値」はどうやって考えていったでしょうか?
チームでネットサーフィンして調査結果を概観し、「課題の仮説」として設定して、そこからヒアリングを行って実際にその課題が存在しそうなことがわかったので、その「課題を解決する仮説」を考え、これらの仮説を補強するデータを取ってくるというようなプロセスでした。
でもこれは「正しそうな妄想」という範疇を超えていません。
「仮説検証」の「検証」の意味合いを踏み違えています。
仮説を検証せぬまま前に進むチーム
では、どのようなものがあれば仮説は「検証」されうるのでしょうか?
答えはめちゃくちゃシンプルで、
「仮説に直接答えている事象」が必要です。
「これがユーザーにとって課題なのではないか」という仮説に対しては、
等の直接的な事象が、
「この価値があるものは使われるのではないか」という仮説に対しては、
等の直接的な事象がそれぞれ本来は対応するはずです。
それなのに、
くらいの間接的な事象を「仮説」と紐づくように「解釈」して、その後のチームの方針を実質的に決定してしまうようなプロセスが散見されます。
その「解釈」がたまたま上手くいっていたかどうかが最終的なアウトプットの納得感を左右する超絶運ゲーを、業界未経験、ビジネス経験も乏しい学生チームで仕掛けているような例が本当に多いです。
※何度も言いますがチームの頭の良し悪しは関係ないです。
この現象はプロフェッショナルワークでは「命取り」
この現象と似たようなものが、就活ガチ勢の方が大好きな『イシューからはじめよ』でも解説されています。
二次情報から情報を得て「解釈」して、「なんか正しそう」状態で、課題や提供価値に対する確信がないまま、方針の実質的な決定を行ってしまう。
インターンではロジックがいい感じなら高評価かもしれませんが、成果を強く求められるプロフェッショナルワークでは「命取り」。
そんな事象を防ぐために、何の武器も持たない我々はどう戦えばいいのでしょうか。いよいよこのnoteで整理したかった方法論の話に入ります。
「事象ファースト」のススメ
一次情報にこだわる、二次情報は懐疑的に
一次情報というのは、定義はいろいろあるでしょうが、ここでは、「今その場で起こっていることで、誰の解釈も挟まれていない情報」と捉えます。
既に人の「解釈」が挟まれているものを二次情報といい、報告書や記事のほか、アンケートによる調査もこれに該当すると考えています(「答える」ということと、「考えている」ということは同じではなく、そこに回答者の解釈が挟まる)
物事は「解釈」を挟むと急に現実から離れていきます。
恐縮ながら、また『イシューからはじめよ』から引用させていただくと、
二次情報を元に仮説をつくるということは、既に第三者の解釈が挟まった情報を元に、さらに我々で「課題」や「提供価値」の仮説をつくるわけですから、その仮説は限りなく実態から離れていきます。
そうして「仮説」に「仮説」を積み上げ、納得感がなくなっていきます。
そもそも学生チームでは難易度が高い
よい「仮説」をつくるためには、
ことが必要で、そもそもこれが学生チームで数日間でこなすには難易度が高そうだということが自分の肌感でわかってきました。さらに、この仮説を検証するためにもそれなりの時間と資金が必要になります。
なぜなら、「検証」というのはその仮説に直接的に答える事象を取りにいくのがベストであり、「それらしい二次情報」の寄せ集めでは終わらないからです。そのためには実際にMVPや広告の展開や、本腰を入れたヒアリングが必要になることもあるでしょう。
つまり、
ことが、アウトプットの質を下げる一つの原因なのではないかと考えています。
もちろん「仮説」を設定して考えるやり方はメンバーの共通言語として、事業づくりや戦略策定に必要不可欠なのですが、仮説検証という道具のみで戦うのは激ムズな土俵を選んでいないか、ということです。
事象からはじめよ
このハードモードを避けるために、仮説検証の方法論として、もっと手を動かして、現在起こっている強い事象を見つけて、その事象の本質的な部分を客観的に見つけてからでも「仮説」≒お気持ちを設定するのは遅くないんじゃない?という考え方を、「事象ファースト」と呼んでいます。
「事象ファースト」とは、
考え方です。
何言ってるかわからないと思うので、具体的な思考フローについても紹介します。先ほど紹介した「あるある」の3daysインターンの例と比較しながら、何がどう違うのかを考えて見てほしいです。
ロジックの核からお気持ちを排除せよ
上記の思考フローの中で最も重要な点は、
新規戦略/施策提案におけるロジックの核が、一次情報から理解を得た事象のもとに立脚している
という点です。
ここでいう核とは、新規事業/施策のコアバリューや、既存の成功事例から転用する部分、ユーザーが抱えている真の課題などが該当します。
この核の部分が事象に立脚しているかどうか、ここまでにどれだけ仮説を排除できているかが事業/施策の蓋然性を高めてくれます。
「事象ファースト」を実践しよう
目線を揃えたら、概念的な議論は不要。とにかく最初は手を動かせ!
先ほどの2つの画像を比較すると、「みんなで議論」の部分に取り消し線があるのがわかります。
そうです。「仮説をできるだけ排除する」「泥臭く一次情報を取りに行く」という作業において、素人学生の空中戦的な議論は必要ありません。
議論で事象は見つかりません。議論で今起きていることは分かりません。
とにかく、事象をとらえるために、僕らが当事者の一次情報を取りにいけるものを領域として選定して、ユーザーの中で今起こっていることの奥底に潜りに行くために時間をかけましょう。
「インサイト」という言葉も一人歩きしがちですが、ここまでスタンスを切って初めて得られる洞察だと思います。
悪い例で見る
ここで微妙な例を出すと信頼性が薄れるので書きたくないのですが、ここまでの話を具体例で見て理解を深めてみます。
頭が良いみなさんならツッコミどころしかないと思いますが、
実際僕が観測した範囲では、こうした案を3daysでいい感じに二次情報で補強したりツイートをポロポロ拾ってきたりでスライド作れたら良い方だと思います。
しかし、そもそも「転職市場」や「IT人材」を概念的に理解し、彼らの生の動きや感情を事実ベースで理解していないために、コアとなる課題やそれが起きる要因、提供価値が全て仮説ベースになっています。
ロジックを裏付けて「いそう」な根拠もツッコミどころが多くあります。
学生ごときが1分セルフツッコミするだけでもこんなに出るので、もっとボロは出るでしょう。連想ゲームに近しいところがあります。
3段も仮説を挟んでいる上にユーザー理解度もほぼ皆無なので、これが当たる確率は天文学的確率というかゼロです。最終的に出てくるプロダクトを見て「チームでいい感じに議論したけど、うーんこれ使うのかな?笑」と本音では思っている、そんな進め方です。
良い例で見る -それでも新たなモノを生み出すために、「仮説」が最後に必要-
では「新規戦略/施策提案におけるロジックの核が、一次情報から理解を得た事象のもとに立脚している」例を見てみましょう。
めちゃくちゃダサい言い訳をしておくと、以下の「事象」は全て妄想なので参考にしないでください。
最初の考え方、探し方、進め方の時点で差が出ているのは見て取れると思います。
もしこれを社会人の皆さんが見ていたら死ぬほど恥ずかしいしアマちゃんが方法論語ってんじゃねーよとなると思いますが、
学生が何もないところから仮説で砂の城を立てるよりも納得感が高いことが伝われば幸いです。
仮説を挟むタイミングも、成功の要因やMVPで実装するバリューといった議論の核からは排除しながらも、
実行ベースでは独自の仮説を打ち出して、現地適合の戦略をとり、競合に勝てる可能性を高めています(ここら辺の仮説の筋の良さはセンスというか経験なんやろなあとか思ってます)
おわりに
いち学生なりに、今までのインターンの学びを書いたら10,000字になってしまいました。
ここまで読んでくれた方、ありがとうございます。
改めてこのnoteに起こすにおいて『イシューからはじめよ』や『仮説思考』を読んだら、マジで全部書いてありました。
以前自分が線を引いていたところとは全く別のところで「あーこれはそういうことなのか」と腑落ちすることも多かったので、サマーインターンがひと段落したこの機会に好きな本を再読するのが良いのではないでしょうか。
さて、このnoteを書いたのはめちゃくちゃ小規模な鍵垢就活アカウントです。ここまで書いたのに誰も見てくれないと悲しいので、ぜひリンクで共有してくださると幸いです。
(もし気になればアカウント (@Workinonit_25) にフォロリクください)