仮説検証

一言でいうと

確かではない前提を、確かめられる形の仮説として書き出し、小さな手段で試して、結果にもとづいて次の判断を決める進め方です。

提唱者と登場年

仮説を立てて確かめるという手順そのものは、科学の方法に由来します。事業づくりの手順として体系化した代表的な文書は、起業家で研究者のSteve Blankが2005年に刊行した『The Four Steps to the Epiphany』です。Blankは同書で「顧客開発」と呼ぶ方法を示し、初期の事業は顧客、機能、販路、価格などについて未検証の仮説を抱えていると考えました。仮説ごとに実験を設計し、社外の顧客のもとで確かめ、結果から仮説を採るか、捨てるか、修正するかを決めます。

この方法は、Eric Riesが著書『The Lean Startup』などで広めたリーンスタートアップの土台になりました。BlankはHarvard Business Reviewの2013年5月号で、事業計画を書いて投資家に売り込むという従来の手順に代わる方法として、これを紹介しています。

何を解決するか

新しい事業や機能は、顧客が実際にその課題を抱えているか、その解決策にお金を払うかといった、確かめていない前提の上に立っています。前提を確かめないまま開発に時間と予算を使うと、完成した後で誰も使わないとわかります。

仮説検証は、前提を1つずつ取り出し、最も安く確かめられる方法を先に試します。前提が誤っていれば早い段階で方向を変えられるため、失敗にかかる費用を小さく抑えられます。

前提として、結果によって方針を変えてよいという合意が組織にあることが必要です。結論が先に決まっている場では、検証の結果が判断に使われません。

実際の進み方

まず、前提を書き出します。「この業務の担当者は、月に何時間をこの作業に使っている」のように、確かめられる形の文にします。

次に、確かめる手段と判断の基準を決めます。顧客への聞き取り、試作品での利用テスト、申し込みページへの反応など、費用の小さい手段を選び、どの結果が出たら仮説を採るかを先に決めておきます。

そのうえで実施し、結果を記録して判断します。仮説が支持されなければ、捨てるか、条件を変えて次の仮説を立てます。

導入でよくある失敗

• 判断の基準を後から決める。どんな結果も都合よく解釈でき、検証の意味がなくなります
• 仮説を大きなまま試す。複数の前提が1つの実験に混ざり、何が外れたのかがわかりません
• 検証を担当者任せにし、結果を意思決定の場に持ち込まない。検証はしたのに計画が変わりません

求人票にこの語がある場合に読み取れること

計画を固めてから作るのではなく、確かめながら方向を決める組織だと読み取れます。プロダクトマネージャーや新規事業の求人でよく使われます。

候補者の経歴に「仮説検証を回した」とある場合は、何を仮説とし、どの手段で確かめ、結果を受けて何を変えたかを聞いてください。調査や実験を実施した経験と、その結果にもとづいて方針を変える判断まで担った経験は別のものです。

隣接手法との違い