ソフトウェアの問題を解決するデバッグ作業時の5つのヒント

最新特集【一覧】

EPUB生成ツール「ReVIEW」について達人出版会の高橋氏に聞いてみた

1つのソースでEPUBとPDFを生成できる「ReVIEW」を試す

Snow Leopard探索記 最終回：線路は続くよどこまでも

　クライアントから情報を手に入れるのが難しいことは珍しくない。そんな状況でもソフトウェアのデバッグに役立つ5つのヒントを紹介する。

　クライアントから情報を手に入れるのに苦労したことがあるだろうか。クライアントはほんの少しの手間で、その情報を提供できるはずなのに。

　「壊れたんだけど」とクライアント。

　「壊れたって、どんなふうにですか？」

　「するはずの動作をしてくれないのさ」

　「するはずなのに今していないのはどんな動作か、説明していただけますか？」

　「えーとね、普通にコンパイルされるのに、実行すると止まるんだ」

　「どんなふうに止まるんですか？」

　「エラーが出て終了するのさ」

　「どんなエラーメッセージが出てますか？」

　「メモしなかったんだけど」

　もちろん、わたしのテストシステムでは問題が再現されないので、少なくとも「クライアントの」システムにアクセスできるように、クライアントに手配してもらう必要がある。ただしクライアントは、そんな手間はかけたくないと思っている。問題が解決されればいいのだ。口に出して言わなくても、「このソフト屋はあの製品をテストしたことがあるのか？ユーザーの面前で大恥をかくためだけに大金を払っていたのに、今度は直させるためにもっと金を使うのか！」と考えているだろう。クライアントはソフト屋を助けることにはまったく気乗りがしていないが、こちらがクライアントを助けるつもりならば、本当にいくつかの情報が必要なのだ。というのも、クライアントのシステムで試してみても問題が再現されないのだ。

　「エラーメッセージが表示されるまでに実行した手順を正確に知る必要があるんですが」

　クライアントには、わたしが責任を回避しているように聞こえる。この問題が起きる前にどんな手順を実行したか、彼らにはまったくわからないからだ。

　わたしのクライアントの多くはソフトウェア開発会社だが、大きな干し草の山から針を探すようなものなのに、多量のコードをポンと渡され、問題を見つけろと言われることが多いのには困ってしまう。多くの場合、「teach a man to fish」（魚を与えるより、魚の釣り方を教えろ）という格言のように、役立つ問題解決の手法を教えようとするのだが、抵抗を受けて驚くこともある。まあ、請求できる時間数が増えるだけなのだが。