問題解決のための二つのキーワード: 抽象化と類推

生産管理であれロジェクト・マネジメントであれ、およそマネジメントと名のつく行為には『問題解決』がつきものである。どんなに精緻な計画を立てたって、実行段階に入れば、予期せぬいろいろな問題が生じてくる。物事が全て計画通りにいくならば、そもそもマネジメントなど不要であろう。だれかがメクラ判を自動的に押していればよい。マネジメントなる職務が必要になるのは、遂行途上で解決しなければならない問題が生じるからだ。

『問題』とは、自分達が(意識的であれ無意識にであれ)期待していた状況と、現実との間に生じるギャップのことを指す。これに対して、『課題』とは、あるべき姿と、現実のあるがままの姿のギャップをいう。問題が受動的に発生してくるのに対し、課題は能動的に作り出すものだ。ここで取り上げたいのは、問題の方である。これは、
 問題=(期待)-(現実)
という式に書くことができる。とうぜん自分達が抱いていた期待が高ければ高いほど、問題はより大きくなる。また、最初に抱いた期待が荒唐無稽であったり、あるいは漠然と無意識のまま願望だけをもってスタートしたりすれば、普通の状況でさえ、大きな問題に感じられる。つまり、問題の半分は、自分の側(の期待のあり方)にあるのである。

では、問題解決は、どのようなプロセスで進めるべきだろうか。少なくとも、PDCAサイクルでないことだけは確かだろう。問題をPlanする人間など、いないからである。だとすると、第一歩は、問題の発見でなければならない。現実を見て、それが自分達の期待と異なっていることを見いだす。「現実を見て」とかるく書いたが、チームでやる仕事ではけっして簡単ではない。仕事の状況をモニタリングし把握する仕組みがなければ、問題も見えてこない。おまけに、現実の組織の中では、しばしば“問題の抱え込み”も起きる。担当者が自分一人で抱え込んで、チームに報告してこない現象だ(これは根の深い事象なので、いずれ項をあらためて別に論じたい)。いずれにせよ、「問題の発生にすぐ気づく」のは、優秀なマネジメント能力の証左である。

さて、問題に気づいたら、その問題構造を掘り下げて、原因を見極める必要がある。原因分析である。これも単純そうに見えるが、やってみると案外難しい。最近は「なぜなぜ5回」が喧伝されているが、これなど注意して使わないと、とんでもなく筋違いな“原因”を摘発することになる。たとえば品質不良の原因をさぐっていくと、→ローコストな外注先の採用 →調達予算の不足 →元々が安値受注だった →不況が続いているため、といった調子でいつの間にか、誰もすぐには解決できない「不況」が根本原因になってしまったりする。これではマネジメントの役には立たない。問題構造の掘り下げには、案外きちんとしたスキルが必要とされるのである。

つぎに、解決策を考えるステップが来る。つまり「問題を解く」段階だ。ここが一番大事なことは言うまでもない。誰かが過去、同じような問題を解いていたら、それに習うことが出来る。だが多くの場合は、ここで何か新しい方策を考える必要が生じる。つまり、一種の発明である。

世間では、問題に気づく段階では『見える化』を、また問題構造の掘り下げ段階では『なぜなぜ5回』を頼りにするケースをよく見かける。どちらもトヨタの造語だ。ところが、解決策を考える段階については、(少なくともわたしは)手頃なトヨタ用語を思いつかない。たぶん世間も、同様であろう。

では、解決策の発明の段階では、どうすべきか。ここでわたしは、別の用語をお教えしたい。それは『抽象化』と『類推』である。問題を抽象化し、その上で類推をつかって、解決策を得る。これがわたしのお薦めの方法である。

この二つのキーワードを知ったのは、学生時代のことだった。小さな本屋で立ち読みした、新書版の本の中で見つけたのである。問題解決と発明がテーマの本だった。その著者名もタイトルも忘れてしまったので、今は探しようもない。しかし、その表紙の写真は決して忘れないだろう。表紙には、水平な板の上に卵を立てた写真が載っていた。ただしコロンブスのように、下側をつぶして立てたのではない。なんと、釘を打って立てていたのだ。五寸釘が、卵の上下を貫通して、下の板に打ち付けられている。おかげで卵はしっかり立っている。そういう写真だった。

序文を読み、目次を読んで、その著者の主張の大筋はわかった。問題に直面したときは、その対象固有の事象に惑わされがちだ。そこで一歩問題から離れて、『抽象化』して考える。卵を立てたい。しかし、卵は丸くて細長く、不安定だ。その時には、「卵を立てる」問題から少し離れて、「モノを立てる」という抽象化した問題を考えてみる。

つぎに必要なのは『類推』の作用だ。たとえば、細長いモノを立てる例は他にはないか。ある。たとえば木材だったら、釘を打つ、接着する、はめ込むなどの方法がある。傘を立てるなら、周囲にサポートを置く、あるいはポケット型の受け口を用意する方法がある、等々。そういう具合に、類推で「モノを立てる」いろいろな方法を思い出すのである。そこから、元の問題に適用可能な方策を見つければよい。事実、表紙の写真以外にも、卵を立てる方法を10個くらい、文中にイラストで紹介してあった。

(むろん、“卵を立てるのに道具を使うのはずるい”という反論もあるだろう。その時には、「道具を使わずにモノを自立させる」問題を考えればいいだけだ。しかし、“卵を立てろ”という元の問題に、本当にそんな制約条件があるかどうかは、不明である。解決する自分の側で勝手に--無意識に--制約条件をつけて考えている場合が、じつは多いのだ)

その著者によれば、『抽象化』と『類推』の、たった5文字の言葉から、解決策の発明のための知恵が豊かにわいてくるのだという。あいにくこの本は買い損なってしまったが、この二つのキーワードは、単純かつ鮮烈だったために、記憶に残った。そして、やっかいな問題を考えるたびに、「抽象化して」「類推で」考えるくせが身についた。

ともあれ、解決策さえ思いつけば、あとはそれを実行に移す段階になる。まあ、しばしば実行段階でも、こまかな「サブ問題」が生じてくるのだが、それは同じ手順でつぶしていくことになる。かくして、解決策を実行したら、あとは結果を検証する段階に到達する。

だが、これで問題解決は終わりではない。仕事全体が完了した時点で、今度は発生した問題をふりかえり、再発防止のための「学び」をしなくてはならない。これでようやく、問題解決プロセスの終了である。以上をまとめると、
(1) 問題に気づく
(2) 問題を掘り下げる
(3) 問題を解く
(4) 解決策を実行する
(5) 結果を確かめる
(6) 問題に学ぶ
の6つのステップからなる行為だと言うことが分かるだろう。そして一番重要な「問題を解く」の段階では、『抽象化』と『類推』のキーワードをつかって、いきいきと頭を働かせることが必要なのである。

(参考エントリ) 「生産システムの性能を測る」 (この中で、抽象化と類推の一例を挙げています)
by Tomoichi_Sato | 2011-11-06 21:16 | 考えるヒント | Comments(4)
Commented by たばたまり at 2011-11-07 09:39 x
ご無沙汰してます。ちょうど、読んでいたやり手広告プロデューサー佐藤某さんの超整理術で響いた「問題を見極めるにはとにかく引いて見る」との箇所と通じるものがあるな~と思いました。
Commented by Tomoichi_Sato at 2011-11-07 23:58
お久しぶりです。コメントありがとうございます。「問題を見極めるにはとにかく引いて見る」=マクロな視点から(抽象化して)見る、という意味だとしたら、たしかに相通じるものがありますね。わたしも読んでみることにします。良い情報、ありがとうございました。
Commented by フェイスブック at 2011-11-08 15:58 x
世界最大級のSNS!フェイスブックの会員数は世界一!そんなフェイスブックだからこそ新たなチャンスは無限大なのです
Commented by IP Analyst at 2011-11-21 18:01 x
自らの気付きがその後の活動の基礎となっていることがよくわかる、良い記事だと思います。文中の「抽象化と類推」に関しては、おそらくはTRIZやUSITに関する本ではないでしょうか? この考え方はTRIZや、それを簡略化したUSITの基本的な考えです。
<< 神奈川の小さな通りを歩きながら考える 書評「Q-Japan」 飯塚悦功・著 >>