く〜る〜、きっとくる〜、バグがくる〜

「バグ」

それはITの現場とは切っても切れない関係を持ち、常に技術者をはじめとした関係者を悩ます魔物である。

発生する場所はさまざまであり、いつ姿をあらわして人々を恐怖のどん底に叩き込むかは、その瞬間までわからない。もし事前にわかったとしても、それは具体感のない「気持ち悪さ」であったり「言葉にできない不安」といった漠然とした先触れにとどまっている。

「今進めているコードにバグがあるのではないか」という不安は、開発者にとって共通のものだろう。その不安はストレスとなり、開発者の身体と心を緩やかに蝕んでいく。一方で「まったくバグを恐れる必要はない」と常日頃から考えている人もいるだろう。そういった人は、いざ巨大なバグがその姿をあらわしたとき、心の平静を保つことはできるのだろうか。

バグによって引き起こされるのは、単なるプログラムの動作の不具合だけではない。目に見えるイレギュラーな動作であればまだ良いほうで、表面上はまったく問題がないのにもかかわらず出力されるべき情報のごく一部が間違っているケースなどは非常に深刻だ。

その影に潜んだ病魔に気づけなければ、いつか問題が露呈したときの被害は大きくなる。最終的な結果として、プロジェクトの遅延や中止、かかわったスタッフの責任問題など、深刻な未来が待っている場合も数多い。

自分が手がけるプログラムの中身を「わかっている」という自負から、実際の障害に目を背けてはいないだろうか。「バグに遭遇するのが怖い」からといって、進む道を間違えてはいないだろうか。

趣味でプログラムを手がけるサンデープログラマであれば、バグ取りもまた楽しい作業といえるかもしれない。いってみれば「幽霊屋敷」と呼ばれている場所に、物見遊山で見物にでかけるようなものだ。それは「恐怖」も「楽しみ」の1つである、と割り切れている場合だろう。

しかしビジネスの現場では「楽しむ」ことは難しい。「バグはなくて当然」「バグは解消できて当然」という認識の上で作業が進んでいくからだ。同じ幽霊屋敷に行くとしても、そこで求められるのは「除霊」であり「悪魔祓い」といった結果なのである。

さらに、バグと対峙した技術者は、病気の治療にあたる医者であるともいえる。患者から求められるのは病状の回復であり、その原因の特定と根絶だ。しかもあてずっぽうではなく、経験に裏打ちされた技術と正しい知識を持ち、さらにそれを持っていることで患者に安心感を与えることまでが、求められる。

…と、ここまで書いたようなことは、開発者の方であれば常に感じていることであり、「言われなくてもわかってる！」といわれるかもしれない。しかし、それでも「バグ」は発生するのである。

本連載「本当に怖いバグ話」では、筆者らが遭遇した体験談を基に再構成したバグ話を通じ、開発者がバグに立ち向かうためのポイントについて伝授していく。その話の中で注目するポイントは3つある。 次のページ