"問題発見 → 問題解析 → 問題解決" こそが仕事の核 ......

　今回の技術的作業のとある問題点は、いくつかの複数の要因が絡まって発生していたのだと言える。
　先ずその一つは、自分側の "情報不足" だ。当該の領域についての基本情報が不足しており、まさに "見えない" という難点があった。むしろ、そんな状態でよく問題を問題として掌握できたものだったと振り返るくらいである。
　詳細な問題解析に入り込む前に、当該領域のノーマルな通常状態について実感的レベルで精通している必要がある、と痛感した次第である。
　二点目は、参考資料への "過信" だということになりそうだ。とかく、 "見えない" 領域に関しては、何かに頼ろうとするものだが、今回はその失敗例となりそうだ。確たる根拠があったわけではないにもかかわらず、参考資料を過信したことが、解決を遅らせてしまったからである。しかも、結果的には、その参考資料の情報自体を "修正" することになった。それらが間違っていたわけではなかったが、決定的に "不十分" であったがために問題が発生していたのであった。
　こうした点を目の前にしてみると、何か問題が発生した際には、すべてに対して一様に "嫌疑" をかけるという姿勢が望まれる。仮に、 "マニュアル" のようなものでさえも、ひょっとしたら記載ミスがあるのかもしれない、と考える必要があるのかもしれない。

　次に、問題解決に至るプロセスでの対処法についてである。
　先ずは上記の二点の "裏返し" ということになるが、基本情報を即刻補充して、ノーマルな状態がどうあるのかを体感し納得すること、そして、参考資料などへの評価をとりあえず相対化することが必要となる。
　次に、原因と思しき問題箇所を限定していく作業となるが、そこでは、 "仕分け" というか "消去法" とでもいうか、何のどこまではノーマルであり、どこからが不明であるのかを順を追って確認してゆくことになる。
　こうしたプロセスを踏んでゆくと、次第に "仮説" めいた発想が、イメージ的に "発酵してくる" ようである。たとえば、ハードであれソフトであれ、 "これこれこうした機能を果たす部品" が破損しているのではないか、欠落しているのではないか、あるいはそうした部品というものが、自分は知らないとしても然るべきところに存在するのではないか......、と。
　ここまで詰めの作業が熟してくると、後は結構、短兵急に進みがちとなる。今朝の動きはまさにこのようだったのである。

　どんな仕事においても、こうした局面、つまり "問題発見 → 問題解析 → 問題解決" が含まれているものであろう。いや、これらの集積なのかもしれない。そして、これらを手際よくこなしていくことがプロの仕事師のはずである......　(2009.03.04）