http://sb-kimitsu.jp Just another WordPress site Tue, 27 May 2014 13:32:39 +0000 ja hourly 1 http://wordpress.org/?v=3.3.1 http://sb-kimitsu.jp/column/%e5%95%8f%e9%a1%8c%e3%81%ae%e5%8e%9f%e5%9b%a0%e3%82%92%e7%9a%84%e7%a2%ba%e3%81%ab%e8%a6%8b%e3%81%a4%e3%81%91%e3%82%8b%ef%bc%88%ef%bc%92%ef%bc%89.html http://sb-kimitsu.jp/column/%e5%95%8f%e9%a1%8c%e3%81%ae%e5%8e%9f%e5%9b%a0%e3%82%92%e7%9a%84%e7%a2%ba%e3%81%ab%e8%a6%8b%e3%81%a4%e3%81%91%e3%82%8b%ef%bc%88%ef%bc%92%ef%bc%89.html#comments Fri, 17 Jul 2009 13:42:56 +0000 sbkimitsu http://sb-kimitsu.jp/?p=385 プログラムの実行時に問題が発生し、社内ネットワークには問題がないと思われるとき、プログラム自身の問題に視点が移ります。ここでも消去法を意識して問題の原因を捜していきます。
まず同じプログラムを使用しているすべてのマシンで同じ事をしたときに同じように問題が発生しているのか、それとも特定のマシンで起きている問題なのかを、現場のオペレータに確認します。この確認がとても重要で確認しないと問題の原因発見に遠回りすることになります。
もしすべてのマシンで同じ問題が発生しているなら、実行しているプログラムの問題を疑うことになります。デバッグ環境で同じ動きを試み再現させます。もし自分のところで再現できない場合は問題を報告してきたオペレータに、どんな操作をしたのか詳しく聞いてみます。開発者はおのずと正しい操作方法をしてしまいます。すべてのプログラムのプロセスを知っているからです。でも現場のオペレータはそんなことを知らないので開発者の想定していない操作をしていることもあるのです。
もし自分の環境で再現できれば問題の原因を特定することは容易です。きっと見つけたときには「なんでこんなミスをしたのか」と気恥ずかしくなるでしょう。簡単にその部分を修正できますが、その後の処理が肝心なところです。つまりユーザに原因の説明と被害状況の説明とフォローです。ここでしくじると技術者としての信頼を失う恐れもあります。このことはまた次のコラムでお話しします。

]]> http://sb-kimitsu.jp/column/%e5%95%8f%e9%a1%8c%e3%81%ae%e5%8e%9f%e5%9b%a0%e3%82%92%e7%9a%84%e7%a2%ba%e3%81%ab%e8%a6%8b%e3%81%a4%e3%81%91%e3%82%8b%ef%bc%88%ef%bc%92%ef%bc%89.html/feed 0