問題発見の仮説立て→検証→問題の特定→問題解決の仮説立て
前回の記事で、仮説についての考えで「少しニュアンス的に伝わりにくい」、「間違って伝わる可能性がある」箇所があったので、補足します。
以下が問題箇所。
別に、最初の問題特定が完璧じゃなくていいんです。
仮説ベースで進めて、実際に検証の段階で間違いに気づいたら、もう一回問題を特定をすればいいだけの話です。
これだと、問題発見の仮説立てと問題解決の仮説立てを一気に済ませてしまうような印象を受けますが、実際は違います。
問題発見の仮説立てと問題解決の仮説立ては、分けて行うべきだと思います。
つまり、
問題発見の仮説立て→検証→問題の特定→問題解決の仮説立て→実行→検証…
というのが、あるべき一連の流れです。
なぜか？
それは、いくら解決策を考えたところで、その前提となる問題点が間違っていたら、解決策が当たる確率が格段に低くなるからです。
病院に行って、「話を聞く限り胃に腫瘍あるっぽいから、とりあえず腹切るわ」って言われたら怖いですよね？
そこはまずCTスキャンとかじゃないの？ってなりますよね。
問題解決も一緒で、まずは腹を切るべきかどうかをCTスキャンして見極めましょう。
（ここでいう「CTスキャン」は問題点の仮説検証手法で、「胃に腫瘍があるっぽい」というのが仮説そのものです）
ただ、「最初の問題特定は完璧じゃなくていい」と言ってるのはその言葉の通りです。
医者がCTスキャンして、やっぱり腫瘍がありそうだから腹を切ったけど、何もありませんでしたっていうのはなかなかマズイですが、ビジネスではそこまで取り返しがつかないようなことって、あんまりないじゃないですか。
むしろ、多少は間違っててもいいから解決策を実行して、違ってたら「再度問題特定→PDC」のサイクルを高速で回して、真因に迫っていく方がよっぽど効果的なわけで。
完璧な問題特定を目指してずっと考え込んで、何もしない方が罪です。
何もしなかったら、何も学べませんからね。
よって、問題発見と解決の仮説立てについての結論は以下の通りです。
問題解決の仮説立ては、問題発見の仮説を検証してから。
でも、最初から「絶対に100%何が何でも天に誓って間違いない」っていうレベルで問題を特定する必要はない。
ただ、「検証してみたけど、これでよさそう」っていうレベルまではもっていくべき。
