製品開発は仮説思考である


昨日のLOGOSWAREチャンネルに出演しました谷中です。
メルマガ
放送の録画

放送では、「顧客に真摯に向き合う」方法として、
・顧客の声を正しく受け止める
・顧客のビジネスを理解する
を説明しました。

その中で、「製品開発は仮説思考である」とサラッと述べました。
主旨から外れるので深く言及をしませんでしたが、ここで補足します。
****************************************************************************************

仮説思考とは、まず結論を仮定する考え方です。
「結論を仮定し(=仮説)」、その仮説に基づいて実行し、検証し、修正するという方法です。
対立するのは「積み上げ思考」です。

製品開発における仮説思考は、「顧客が求めているのは○○だ」から開始することになります。
積み上げ思考では、「顧客が求めていることをすべて調べ上げて、リスト化して・・・」ということになります。

仮説思考の最大のメリットは「スピード」です。
仮説思考では、“ただ1つの実行すること”を検討するので、消費した時間はすべて“実行すること”に注がれます。
一方、積み上げ思考では、99.9%実行しないものを延々と調査するわけですから、時間というコストが無駄になります。

製品開発においては、“スピードが命”ですから、仮説思考が最適な手法であることは言うまでもありません。

1.仮説思考と思いつきは違う
「顧客が求めているのは○○だ」だけでは、これは「思いつき」というものです。
思いつきで実行したのでは、積み上げ思考よりも悪い結果になります。
仮説思考には「仮説を補強する」というプロセスが必要です。このプロセスがないものは仮説とは言えません。
「顧客が求めているのは○○だ。なぜならば、○○だからだ。」の「なぜならば」が必要です。

2.「仮説思考に網羅性は不要」は誤解
たまにこの誤解を耳にすることがあります。この誤解を持ったまま製品開発をすると、やはり悪い結果になります。
「網羅性が何についてのものなのか?」を誤解してはいけません。
仮説思考は“結果を仮定”しますので、“ありとあらゆる結果の可能性を考える”という網羅性は、最初から切り捨てています。この意味では、“結果の網羅性は不要”というのは正しいです。
しかし、“仮説を補強する証拠集め、論理の組み立て”には、網羅性が必要です。さもないと、「思い込みを補強するような都合の良い証拠を集めて、都合よくつなげた理屈」になってしまいます。
仕様検討の会議に参加するメンバーは、ここを理解する必要があります。“仮説を立てる段階”では網羅性は不要です。時間を無駄にする害悪です。しかし、一旦仮説を立てたら、その仮説については網羅的に検討をする必要があります。

3.仮説思考は、検知システムである
実はこれが一番言いたかったことなのですが、正しく仮説思考で製品開発をすると、この思考プロセスが「検知システム」の役割を果たします。
「検知システム」とは、仮説の真偽を判定する仕組みです。精度が高い検知システムならば「仮説と現実が少し乖離しているかな?」を察知することができます。
1で述べたように、仮説には「なぜならば」が付随します。製品リリース後の“顧客の声”に、この「なぜならば」に該当するものが全く存在しなければ、“仮説を修正すべきである”という警報になります。
もし、「思いつき」で製品を作ってしまったら、この警報は鳴り響くことはありません。いつまでも「なんで売れないんだろう?」と首をひねっていることになります。
2で述べたように、仮説には「網羅的な証拠、論理」が付随します。製品リリース後の“顧客の声”の一言一句を丁寧に読むと、この「証拠と論理」に合致しているのかどうかが明白になります。ちょっとした顧客との会話の中でも、充分に確認ができます。「仮説の証拠」が詳細であり、網羅的であるほど“会議室では気づかなかったこと”がはっきりと見えてきます。これが精度が高い検知システムということです。
もし、恣意的な証拠集めしかしていなかったら、“自分たちが何について気づいていなかったのか”を知ることはないでしょう。

****************************************************************************************
私たちはベンチャーですので、絶対的なスピード感が最大の武器です。
大切なのは、“どこに時間をかけるのか?”です。
LWでは多くない社員数の中で、品質部門を作ったり顧客アンケートを実施したりなど、さまざまな品質に関する取り組みをしているのは、“品質には時間をかけるべきだ”と考えているからです。
私たちが、「顧客の声を正しく受け止める」「顧客のビジネスを理解する」を重要視しているのは、このような考えに基づいているものだとご理解をいただけたら幸いです。

The following two tabs change content below.

谷中

システム開発チームと検証チームのマネージャー。 「疎結合 小さなクラス 分業制」 を裏スローガンとし、これが実現できてこそ、幸せな開発者人生を過ごせるという確信のもと、上流から設計まで口を挟んだり挟まなかったりしています。

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>