No.92: 問題解決の仕方を教育できているか
prjmc staff
システムを開発している現場で、顧客先で発生した障害に対しプログラムを調査している技術者の作業状況を見守っていた時の話です。その技術者は、プログラム内のある関数の中で、ブロックの順序を入れ替えてみて動きがどうなるか試していました。プログラムの中で処理A、処理Bの順序になっていたものを、処理B、処理Aの順序に変更していたのです。
私は、なぜそうするのか聞いてみました。そうすると、その技術者からの答えは、「この順番がおかしいのかなと思ったので」ということでした。なぜその順番がおかしいと思ったのかと問いかけると、「試してみようと思った」ということでした。なぜそう思ったのかの答えになっていませんが、本人なりには何か気になるところがあったのでしょう。
話をわかりやすく簡略化していますが、問題に対してこの様なアプローチ、いわゆる闇雲なトライ＆エラーで解決しようとするケースをしばしば見かけました。
問題解決のアプローチが論理的でないのです。ロジックツリーやKT法など、問題を解決するためのフレームワークは諸々あってそれらを学ぶ必要もあるかも知れません。しかし、そもそもそれ以前に、まず事実を確認し、事実から原因となる可能性のあるものを考えて、それを一つずつ潰していくという様な、基本的な考え方ができていないのです。
こういった訓練や教育を受けずに来たプログラマ、エンジニアは現に存在します。考えるより先に手を動かしたがるのです。開発作業においても、設計してそれに基づいてモノを作るということをせず、早く成果を出したくて、初めにしっかり考えずにモノを取り敢えず作り始める、コードを書き始めるのです。
同様に、問題を解決しなければならないときも、勘を頼りにあちこち手を入れてみて、動くかどうか試してみることを繰り返します。そのどれかが当たって、無事解決することもあります。これまでもそうして解決してきたから、それを続けているのでしょう。
しかし、それで良いわけはありません。構造上の欠陥を把握したうえで修正しないと、問題解決したつもりでいても、将来新たな問題を引き起こす種を植え付けてしまうかも知れないのです。
本来の問題の原因は階層のもっと上にあったのに、下の階層で一部を変えてみたら不具合が解消したことで良しとしていると、根本的な問題を解決していないので、そのうち他のところでも不具合が発生します。
まず、問題の事実を確認し、どの様な条件で発生するのか把握し、条件と現象の組み合わせから考えられる原因を洗い出します。時間的な制約もある中、優先度を付けてそれらを一つ一つ潰していって原因を究明します。原因を究明できても、対策方法は一つと限りません。様々な影響を考慮しながら、最適な対策方法を選択します。そうして実施した対策によって、想定した通りの結果が得られているか、条件を変えながら検証する、という様に、手順を追って問題解決に当たるということを習慣として身につけて欲しいのです。
この様なアプローチで進んでいると安心しますが、そうでないと見ている側には不安が増すばかりです。
あなたの組織では、すべてのメンバの問題解決のアプローチに信頼が置けますか。教育できていますか。闇雲にトライ＆エラーを繰り返しているメンバがいないでしょうか。
