問題と前提を区別する

ただ、ある状況の打開策を検討するといった場合、

問題として捉えるもの、前提条件として押さえておくもの、
この２つを区別することが重要です。

たとえば、業務上のある問題解決を目的とした
プロジェクトとしてスタートしているとします。
期限もスコープ（対象範囲）も当然決まっています。

その中で、問題を解決する策を検討する場面では、
問題と前提を明確に区別する必要があります。

その段階で、「ゼロベース」で考えましょうとして、
「そもそも論」を言い始めたら、収集が付かなくなります。

仮に「製品の納期を短縮する」という目的が
あったとします。

製品が9時から18時までの稼働をしている工場で作られている場合、
ゼロベースで考えたら、「稼働時間を伸ばす」
という発想は、容易にできると思います。

ただ、既に「稼働時間の延長は様々な理由から困難で変更しない」
と確認してあるのであれば、
工場の可能時間は9時から18時という「前提」の上で、
納期短縮を可能にし得る機会点を、製造工程、物流、発注プロセスなどで
発見していくよう議論を進めていく必要があります。

それを、前提を明確にしないままプロジェクトメンバー間で議論が進み、
「そもそも工場の稼働は9時から18時だけでないとだめなの？」
と始まると、
では工場の稼働時間を増やすために、要員のシフト時間をどう組むか、
深夜要員の採用をどうするか、機器のメンテナンス時間をどうするか
など、結果として実現不可能なことに無駄な時間を費やしてしまいます。


問題解決を議論するとき、「前提」を明確に示し、
これは議論してもしょうがない部分を決めた方がいい。

議論すべき「問題」と、すべきでない「前提」をはっきりさせる。
その「前提」条件のもと、取組むべき課題、解決する方法に
時間とエネルギーを注力すべきです。

ところが、これが意外と出来ていないケースをよく見かけます。

「そもそもなんで・・・なの？」
というのは、視点を広げるためにいいときも多いですが、

「そこは触れない」という前提を置いた方が、
実行可能性の高いアイデアを多く発想できる。

何となく、自由な発想で、制約なく、ゼロベース思考で
というのは素晴らしいアプローチで聞こえがいいですが、
すでに実行段階にあるプロジェクトに置いては、
実は「罠」だったりもするのです。。

それは、「前提」なのか「問題」なのか、
具体的な議論は、ここを意識することからスタートしましょう。