【U】 頭脳労働へのヒント



ドキュメント履歴: 2003-08-xx 初回アップ

U−4.不具合検討の仕方について

 新製品の開発過程で不具合が発生して、設計の意図通りに働かない。
こんな新製品の開発過程ではよくある光景に直面したときに、新製品開発のアイデア捻出の場面と同じ位にその人の技術的能力が試される。殊にその不具合現象がごく希にしか発生しないような現象だったりすると、ますますその傾向が強くなる。何回でも繰り返し発生する不具合なら、若干の理論だけがあればトライアンドエラーの繰り返しでも対策案を立案できる。しかし何百回に一度起きるか起きないか、しかも何が要因で発生するか分からない不具合ではこうはいかない。不具合を再現させるところから推論が始まる。ソフトウェアバグかノイズかはたまた信号のチャタリングかといった大きな切り分けから、ソフトウェアバグならどこが原因か、ノイズなら静電気かその他の原因かまたそのノイズはどこに飛び込んでいるのか、といった細部にわたって全ての可能性を洗い出し、もし原因がこうであるとするなら不具合と同じ現象はどうすれば再現させられるかといったレベルから論理的思考力が要求される。

 私の経験ではこうしたときの脳ミソの働きは以下の通りである。
まず幾つかの現象をみてそれらの現象を誘起せしめている要因をすべてリストアップする(観察力)。次にもしそのそれぞれの要因によって現象が発生しているのなら、その要因を取り除くことによって不具合現象が治まるか、逆に要因を積極的に印加することによって発生が確認できるかを考える(推論要因の実証)。しかしここで問題はいかにその要因を直接的に除去/印加するかその具体的方法である。この要因の除去/印加方法を幾通りも考え、その中からある時は一番簡単に確認できる方法を優先して実施し、別の場合はより精度の高い方法をとる。場合によっては消去法的観点から、要因リストの中の特定の要因を除去する検証を優先することもある。しかも、もし一通りの確認結果がある要因の関与を否定する結論を導き出したとしても確認方法が適切でない可能性をも考えて、場合によってはさらに裏付けをとるためのもう一つの別の検証方法を考えて実施してみて、推論と合致しない点があれば再び推論に戻って繰り返す。そして解決のための新しい糸口が見えたときにはそこに集中的にパワーを投入する。
 こうした時には新しいアイデアの創出過程と同じく、会社を離れて食事をしているときでも、風呂に入っているときでも、あるいは寝ていても、ふっと問題解決の糸口が見えてくることがある。こんなときは、翌朝食事ももどかしく会社に行って、確認実験をすることになる。生涯忘れられないような難しい問題の解決過程では、何度かこうした経験をすることになる。そしてその間はほとんど、ともすればあきらめそうになる自分との戦いであり、しかしいつも終わってみれば解決できない問題というものはないのであって、そのことが次にまた困難な問題にぶつかったときには希望と自信になってくれる。
 要は推論し、実証し、観察し、その結果が再び推論を呼ぶという問題解決の論理的ストーリーをいかに頭の中で展開できるかということであり、しかも実験と共に目の前で生じている現象を見つめながら脳ミソをフル回転させ、問題解決フローを時々刻々と変化させることができるか否かが大切である。こうした場合によく要因展開をして計画を立ててから実験をして検討する場面を目にするが、この方法は余程簡単な不具合か、さもなければ不具合現象を再現させられない場合に備えて、全て要因は考え尽くしたが解決できませんでしたと言うときの言い訳に役立つに過ぎない。何度も言うが机上で要因を考えても脳ミソは活性化されていない。脳ミソが活性化されていないときのストーリー展開に従って多くの時間を費やすのは愚の骨頂というほかない。
 別の言い方をするなら、不具合を解決しなければいけないという問題意識の上に観察力と直感力と知識が渾然一体(カオス状態)となった脳ミソの励起状態を作り、そこから解決の糸口を探り出して真の要因を手繰り寄せる精神力プラス論理力の勝負とでも言うべきだろうか。

著作権は Y.Nakajima に属します。 無断転載は禁じます。

Access Counter:  総アクセス数