道具はいつも使えるとは限らない

http://d.hatena.ne.jp/hyoshiok/mobile?date=20080824
http://www.nurs.or.jp/~ogochan/essay/archives/1363
からネタをいただいたので書いてみる。

僕もデバッガを使うデバッグはあまり重要視していない。デバッガというのは、使えない場面も結構あるからだ。

バグを見つけたら、まず原因の仮説を立て、ソースを確認し、最後に仮説が正しいことの検証データを取得するためにデバッガを使う。というのが、僕の理想とするデバッグ方法だ。
頭の中にソースコードを全部ぶちこんで思考を繰り返すのだ。デバッガは頭の中身と実際が一致していることを確認するために使う

アプリケーションのデバッグならデバッガが使えるかもしれないけど、例えばOSそのものをデバッグしたいとき、デバッガもOSから見ればアプリの一つなので、デバッガで出来ることには何かと制約が多い。
タイミングが重要で、少しでも実行時間が異なると挙動が変わるプログラムも、あまりデバッガ向きじゃない。

もうひとつ、開発ターゲットに関係なくデバッガが使えない場面がある。
デバッガは、バグが再現してくれるときにしか使えないのだ。正常動作しているプログラムの中身をいくらデバッガで覗いてもバグは取れない。

再現しませんでした。の一言で済むのならともかく、普通はそんな呑気なこと言っていると仕事がなくなってしまう。

昔僕がある装置の開発を引き継いだときの話。
アメリカにある客先では、うちの製品と競合他社の製品が混在して稼働しているという状況。両社の製品の機能に大きな差があるわけじゃなく、１つこけたらみなこけた、なんて状況を回避するために2社の製品が共存して動いている、ということ。
共存、は少し不適切かな。シェアは約７：３でうちの製品が負けていたからｗｗ
バグが多いうえに修正まで時間がかかる、ということで不評だった。
何しろ報告を受けながら、再現しないと放置しているバグが運用に支障のない細かいものも含めると3ケタもあるのだ。もう少し何とかしようがありそうなものだけど、客先固有の事情があってソフトウエアのスタッフが現地にいって直接調べることが出来ないので前任者はほとんど投げ出していたらしい。

そんなハンディを背負って僕のチームの開発がスタートしたんだけど、間もなく部長に呼ばれた。
曰く「競合他社はバグの連絡を受けてから3日で修正版を持ってくるのに当社は3日でようやくバグと認めるだけだと客先からクレームが来ている。何とかしろ」と。
要するにクレーム担当窓口からソフト担当である僕のところに連絡が来る頃には、競合他社はもう修正、リリースが終わっているというのだ。
何とかしろといわれてもタイムマシンでもないと無理でしょ?と思いつつも周囲にも協力をお願いし、当面はうちの品質を上げるとともに、テストを担当する関連会社と打ち合わせを繰り返し、まずこれ以上バグを漏らさないための作業をこなしてた。

とはいえ、引き継ぎ製品なので、すでにリリースされてしまっている製品に多分含まれているであろう潜在バグに対する決め手がない。いつ破裂するかわからない爆弾を抱えて開発しているようなものだ。

そんなときに一つの情報をテスト担当会社の人からもらうことができた。アメリカの客先に常駐しているフィールドサポートエンジニアの一人が3日間だけ日本に戻って来るというのだ。

幸い、その人と会うことができ、いろいろと話をすることができた。
競合他社が3日以内に修正版をリリースできる理由も考えた。二人の結論はこうだ。
客先は不具合らしきものを見つけたからといって、いきなりバグだと言ってくる訳じゃない。ちゃんと検証をして間違いなく製品の問題だと確認できたときだけバグの連絡をしてくる。そういう正規のバグと判明する前の、いわばバグの卵のような情報は本当は非公開のはずなんだけど、客先の担当者と懇意にしているとフィールドサポートまで漏れてくることもある。おそらくその段階で先行調査、正式なバグの連絡が来る前に修正を終わっているのだろう、と。

うちもそうしよう。
もともと彼は、現地のスタッフに受けのいい優秀な人なので、アメリカに帰ると、さっそく情報を送ってくれた。どうも個人的に現地スタッフに情報を回してくれるようお願いもしてくれたらしい。
それでも、正規ルートの情報じゃないので、やっぱり足りないところは出てくる。こちらの環境ではまったく再現しない。億の値段がする上、オプションがやたらある製品なのですべてのオプションの組み合わせで再現試験を行うということは最初から不可能だった。当時はシミュレータもなかったし。
いくつもの推論を重ね、少しずつ範囲を絞り、「こちらの推定が正しければ客先はこういう構成で運用をしているはずで、その場合こういう現象が起こる筈だ。確認できないか?」と聞いてみて、一致すればさらに先に進む。意図的にバグを入れたソフトをつくって比較データを採る、なんてことまでやってみた。
ある程度まで範囲を絞り込んだら、後はソースコードの机上チェック。バグを見つけたら、それは公式には「自力で見つけた」とアナウンスをして修正を行った。

バグの卵のいくつかは、本物のバグに「孵化」し、修正依頼が来たけど、すでに手元のソースは修正、検証が終わっていたので、（3日は無理だったけど）1週間以内にはリリースできた。

修正内容を詳細に検討している過程で、再現しないと言われていた3ケタのバグについても現象が説明が出来るようになって来た。
極端に品質の悪いいくつかのソースは全面的に書き換えを実施し最終製品をリリースした後は再現しないと言われていたバグもすっかり直っていた。

お客さんには、かなり好評だったらしい。
営業さんからも「去年のお客さん主催のクリスマスパーティーはケーキとクッキーだけだったけど、今年はワインとトリがでたよ」ってメールが来たからねｗ

実際当時の職場でもデバッガに頼りきってデバッグしているプロジェクトの方が多かったし、ぶっちゃけ平均的な品質に有意な差は無かったんだけど、バグを見つけてから修正するまでの平均時間が短いとか、そういうデータは出ていた。なんでっていう、理由まではわからないけどね