メタデバッグ

今回はメカAGさんのブログからご寄稿いただきました。

メタデバッグ

「メタデバッグ」という言葉を聞いたことがあるだろうか。多分ないだろう。たったいまオレが作ったw。でも長年それなりの規模のソフト開発をしている人間ならわかってもらえるのではなかろうか。

デバッグをするには再現手順を確立する事が大事。よくエンドユーザがレポートしてくる「ときどきおかしくなる」では、デバッグができない。具体的にどういう手順でどう操作した時にそうなるかを、調査しなければならない。その不具合を確実に生じさせる方法。それがわかれば、あとはひたすらコードを追いかけていけば、バグは取れる。

しかし実際にはこの再現手順の調査が難しい。微妙なタイミングがあったり、メモリの解放ミスやポインタ操作のミスは、その場では直ちに不具合が起きず、全然ほかの箇所にひっそりと悪影響を与えている事が少なくない。すると不具合が起きた箇所と、その原因がぜんぜん違う場所というのも珍しくない。

昔に比べれば、そういうデバッグしにくいバグが生じにくいようにシステムやプログラミング言語も改良が加えられているが、それでもゼロにはならない。

　　　*　　　*　　　*

で、そういう時はひたすらコードを追いかけていても、埒が明かなかったりする。いわば推理小説の名探偵並みのひらめき・推理力が必要。そういうものに頼らなくてはいけないのが、そもそも工学として失格なのだが、どうしようもない。

推理というのは結局はデータの分析力で、重要なのはデータを集めること。仮説を立ててもしそれが原因なら、現象としてこうなるはずだから、操作してみ実際にそうなることを確認せよ、と。この場合も確実に再現するなら1回やれば十分なのだが、再現性が悪いと、数をこなさなければならない。大勢のテスターの人を動員して操作してもらう。人海戦術。

この時怪しい箇所も1箇所ではないから、複数の仮説を立てておくことが重要で、たとえば1つの仮説の証明が3日でできるとすると、3つの仮説の証明もやはり3日になることが多い。つまり1度に複数のテストをした方が格段に効率がいい。もしこれを順に1つずつ検証していくと、3日x3回で9日もかかってしまう。

　　　*　　　*　　　*

さてここからがポイント。この手のデバッグに慣れてない人は、一番怪しそうな箇所を思いつくと、それだけしか意識が行かなくなる。それが当たればいいのだが、外れると2番目に怪しそうな箇所を考えて、それをテストする。それがダメだと3番目。結果的に3回も人海戦術を導入しなければならず、時間もコストも効率が悪い。

最初から怪しそうな候補を複数あげ(上記の例なら3つ)、同時にそれをテストしてもらうべきなのだが、人間の思考というのは難儀なもので、なかなかそれができないんだよね。推理小説でも「こいつが怪しい」と思うと、ほかの人間が犯人である可能性が考えられなくなる。

人間のこの思考の習性をりようして「どんでんがえし」が演出されるわけですな。序盤で怪しそうな人物が登場し、読者の注意をそっちに向けておく。中盤でその人物も殺されてしまい、読者は「あれ！？」と混乱する。最後に真犯人が語られ、それまでの布石がちゃんとあったことが示される。「ほら、ちゃんとこの人が犯人だというヒントは書いておいたでしょ」と。読者は「まいった」というしかない。

　　　*　　　*　　　*

推理小説を読むならそれで楽しいんだけど、デバッグの場合、予想が覆されるのは全然楽しくない。人間のこの習性は、現在自分が持っている情報の中で、ベストな答えを出そうとするためだと思うのだよね。

でも実際の事件や事故の報道を見ても、第一報とかは結果的に誤報だったということが少なくない。不具合報告も、報告者の勘違いだったり、全然別な原因のバグがひとつのバグとして認識されてたりして、必ずしも信憑性は100%ではない。

間違った事実を含む情報に必要以上に固執して、それを満たすベストな答えを考えてしまうと、結論が間違ってしまう。

常に一つ一つの情報は「間違ってるかもしれな」「覆されるかもしれない」という意識が必要。たとえば条件が3つあったとして、3つを満たす無理な正解を考えその一発に賭けるのではなく、そのうち2つぐらいを無理なく満たす正解を考え、それをしらみつぶしにチェックした方が、結果的に正解に早くたどり着いたりする。

つまり3つの不具合報告の中の1つは不具合報告そのものが間違っている可能性をも考慮しなければならない。バグ報告自体にバグが存在する可能性を疑う…すなわちメタデバッグ。そういう視点をもつことが大切、と。

執筆：この記事はメカAGさんのブログからご寄稿いただきました。

寄稿いただいた記事は2014年03月12日時点のものです。