下の図はこれを模式的に表現している。
ここで言う上流側の「問題発見」は「白紙の上に枠を定義する」ことであり、その下流に位置する狭義の問題解決とは「『決められた枠』の中を最適化する」ことである。その境目が問題という「枠」の定義である。
たとえば携帯電話の開発で言えば、「携帯電話の開発」という問題(What)が与えられた後に、最高の性能や機能を持った携帯電話を開発する(How)というのが、「与えられた問題を解く」ということである。
「さらに多機能かつ高性能の携帯型の移動端末が求められている」という顧客のニーズ(Why)を新たに発見して、「スマートフォン(やタブレット)という新たなカテゴリーの製品の開発」という新しい問題(What)を定義してそれを具現化するのが、問題発見→問題解決という広義の問題解決の流れになる。
言い換えれば、Whatが与えられたときにそれをHowに落とすのが問題解決で、WhyからWhatそのものを導きだすのが問題発見である。
別の例としてシステム開発・導入を考えてみる。顧客から「こういうシステムを作りたい」という要望(What)があった後に、それを詳細仕様に落として具現化する(How)のが問題解決型の業務で、経営課題や真のニーズ(Why)から「そもそもこういうシステムが必要だ」(What)と逆提案するのが問題発見型の業務と言える。
無料会員登録はこちら
ログインはこちら