ソフトウェアの問題解決

皆さん、いかがお過ごしでしょうか。
マウザックです。

実は私、産業カウンセラーだとか、
心理学の話をしてきたのですが、
本業はソフトウェアエンジニアなのです。

かれこれ6年目ぐらいになるのですが、
今だに難しいなぁと感じるのが不具合解析です。

メーカーから私の会社に不具合の連絡がきて
原因調査する市場不具合や試作の段階での
不具合の調査を実施するものもあります。

不具合調査というのは、
まず何処が原因かわからない場合が多いので、
様々な切り口から原因をどこが問題かを
探す必要があり、そこを間違えると永遠に
問題が見つからなくなります。

良く言われているプロセスが
原因の特定(どこどこ)→問題の追求(なぜなぜ)→対策(どうやって)→その後の監視
の4プロセスです。
細かいことは抜きにして大体の問題解決の
本にはそう記載されています。

僕はこの6年、エンジニアとして不具合解析を
やってきた中で一番重要だと感じたことは
ずばり、原因の特定です。

良くトヨタ方式でなぜなぜが取り立たされますが、
問題がどこにあるのかわからないまま、なぜなぜ
をやっても全く上手くいきません。

まずは可能な限り切り口を出し、
全体の地図を作り、その中のどこに問題があるのか
論証をつけて潰していってください。

組み込みソフトウェアで例えると、
静的ならば、ハードの切り口だと
マイコンか、統合ICか、ソフトの切り口だと
ピン出力部分か、コンポーネントか、ユニットか
動的ならば、マイコンのリセットタイミングか
通常のrunか等、切り口をあげていって
何を調べて問題ないとしたのかどんどん
まとめていってください。
そこで原因が特定出来たら、やっとなぜなぜの
登場です。そこまではなぜなぜしても、
無駄な時間に終わってしまいます。

どこどこのイメージは下記の本の
図1-7がわかりやすかったので、
是非読んでみてくださいね(回し者ではないですよ)
https://www.amazon.co.jp/%E5%95%8F%E9%A1%8C%E8%A7%A3%E6%B1%BA%E2%80%95%E2%80%95%E3%81%82%E3%82%89%E3%82%86%E3%82%8B%E8%AA%B2%E9%A1%8C%E3%82%92%E7%AA%81%E7%A0%B4%E3%81%99%E3%82%8B-%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%83%91%E3%83%BC%E3%82%BD%E3%83%B3%E5%BF%85%E9%A0%88%E3%81%AE%E4%BB%95%E4%BA%8B%E8%A1%93-%E9%AB%98%E7%94%B0-%E8%B2%B4%E4%B9%85/dp/4862761240

以上です。