ソフトウェアのバグを見つけたときにやってはいけないこと

ソフトウェアのバグを見つけたときの対応には、プログラマとしてのセンスがけっこうあらわれると思っている。ぼくはセンスの無い人間の代表例みたいなものだから、ここにはぼくがよくやってしまう行動を思い返して書き、「ソフトウェアのバグを見つけたときにやってはいけないこと」とした。

バグを見つけたことを周囲に吹聴してはいけない

 

ソフトウェアにバグを見つけることや、ソフトウェアのバグを踏むことは、基本的に嫌なことだ。本当にそうだろうか。

有名なソフトウェアが不可解な挙動をするのを見たとき、周囲のひとびとをデスクに呼んで、

「いやー、このソフト、マジでクソですよ。こんなバグがあるんです。ほら、ひどいでしょ」

と毒づいているとき、ぼくは口を歪めながら、ある種のよろこびを感じている。それは、他者のプレゼンに対して不備を指摘するときのよろこびにとてもよく似ている。いうなれば「鬼の首を取ってやったぞ」という気分だ。

あら探しによろこびを感じるひとは少なくない。経験上、バグを見つけた側からそのことを周囲に吹聴するようなひとには、こうした傾向がある（ぼくがそうであるように）。そんなひとびとは「見つけたバグにどう対処するか」という生産的な思考がすぐにはできず、ソフトウェアの抱える不具合という「あら」につい矛先を向けてしまう。

これが悪化するとと、一度バグを踏んだだけで、だんだんそのソフトウェアを憎たらしく思えてくるようになってくる。ソフトウェアを敵視しがちになってしまう。しまいには、「俺の仕事がうまくいかないのも、全部このソフトのせいだ」なんていう被害妄想にすら発展することもある。

バグを見つけたと思ったら、周囲に話したくなる気持ちをぐっとこらえ、深呼吸をしよう。それでも収まりがつかないなら、テディベアにでも打ち明けてみればよい。

プログラマとしてのセンスとは、ソフトウェアを敵視しないことだ。

バグをすぐ直そうとしてはいけない 

 

バグを見つけたと思ったとき、「なんだよもう」 とぼやきながらソースコードをエディタで開き、問題のありそうな箇所にあたりをつけ、デバッグ文を仕込みーー。

それが、あなたのつくっているソフトウェアであって、時間が無尽蔵にあるのならばよい。しかし、そうではないのだとしたら。納期のある中、巨大なコードベースからなる著名なソフトウェアを前にしているのだとしたら。それは最善の選択ではないし、最悪の選択となってしまうことすらあるだろう。

もちろん、それが本当にバグだとわかったのなら、バグレポートを登録するぐらいは礼儀だと思う。しかし、ソースコードの修正までいくのは早計だ。ぼくらにとってバグを直すことは本来の目的ではない。

プログラマは手を動かし続けることが好きだから、ついつい問題が与えられると、それを解こうとしてしまう。目先の Yak-shaving に夢中になってしまう。Yak-shaving がどれだけ時間を奪うか、それを嫌というほど知っているにも関わらず、気がつけば Yak-shaving のなかにいる。

プログラマとしてのセンスとは、本来の目的を見失わないことだ。

バグを見つけたと思ってはいけない

 

そもそも、それはバグではないのかもしれない。

これまで、ぼくが「ソフトウェアにバグを見つけた」と思った経験のうち、実に半分以上は見事な思い違いだった。それは仕様だったり、ドキュメントを読んでいれば回避できる問題だったりした。「あのバグ、結局どうなった？」と同僚に聞かれ、勘違いだったとは言えずに赤面しながら言葉を濁した経験は枚挙に暇がない。

そんな恥をかかないためにも、まずバグを見つけたと思ったら、 そのことを疑ってみよう。ドキュメントをもう一度読んでみよう。そのソフトウェアに詳しいひとが周囲にいれば、恥ずかしがらずに聞いてみよう。こうした行為はもうひとつの視点を与えてくれ、それによって思い込みが正されることも少なくない。

プログラマとしてのセンスとは、思い込みを排除して、常に二つ以上の視点から問題に取り組むことだ。

免責

 

ぼくは残念ながらプログラミングを生業にすることができていない。趣味で十年近くプログラムは書いてきたが、いまだ上に書いたようなことをやらかしている。そういうわけで、この題材を選んだ。これは自戒の記事を出発点とするから、ごく個人的なことを、偉そうに一般化して書いてしまったきらいはある。許してください。

ひとと話をするとき、ぼくらが tf-idf に従っているということ

ぼくら技術者は基本的に技術の話が大好きなものだから、技術者同士で集まれば、ついつい技術の話をしがちだ。そんな調子で技術の話をはじめたとき、横で聞いていたひとりが、

「お前らは技術の話をやめろ。もっと一般のひとにもわかるような話をしろ」

と、諭すようにいって、はっとした。共通する話題は他にも多いのに、なぜぼくらは技術の話を選んだか。

帰り道、電車に揺られ名前も知らないひとびとの話にぼんやりと耳をかたむけているときふと思ったのは、

「ぼくらは tf-idf に従って話題を選んでいるのではないか」

ということだった。

tf-idf は情報検索の分野でよく知られた指標で、「ある文書における、ある単語の重要度」をはかる。その単語がその文書内に登場すればするほど重要度はあがり、その単語が他の文書に登場すればするほど重要度はさがる。ふたつめの点が面白いところで、これはつまり、「ある文書にとって、他のたくさんの文書に登場するようなありふれた単語は、あまり重要ではない」ということをいっている。

tf-idf で、文書をひとに、単語を話題に、置き換えてみる。すると tf-idf は、「あるひとにとって、ほかのたくさんのひとが持っているようなありふれた話題は、あまり重要ではない」ということを意味する指標に変化する。

技術を話題にできるひとは少ない。恋愛を話題にできるひとはそれよりも多い。天気を話題にできるひとはもっと多いことだろう。全世界あわせて７１億人のなかのひとりと話すとき、７１億人ができる話をしようと思うだろうか。貴重な話題を共にするひとに出会ったなら、せっかくの機会を活かそうとすることだろう。ぼくらは tf-idf に従っている。

そういう話を、どこか別の場所でした。ぼくはまだ技術から抜け出せそうにない。

研究のうまい見せ方

研究のうまい見せ方について話した。ぼくらのやっている高速化の研究は地味ではないか、とぼくが問題提起をして、先輩と二人で話した。そこで得た気づきがよかったので、ここに記す。

速度的な優位さをうたうとき、ぼくらは「○○倍の高速化を達成」と書きがちである。こうした高速化の数値は直感的でない。これは、研究の下手な見せ方だ。うまいひとは、それを具体的なことがらに結びついた数値に置き換える。例えば「カップラーメンをつくる際、従来方式では3分かかりますが、我々の提案方式をつかうと5秒ですみます」といった具合だ。これだけで、効果がぐっと訴えかけるようになる。数値の選び方にもコツがある。なるべく、聞き手にとって身近なことがらの数値をつかうのがよい。つまり、研究の見せ方は、聞き手にあわせて変えるべきものといえる。

研究内容が実際にシステムとして動くような場合であっても、ただそれを見せればよいというわけではない。むしろ、実際に動くものこそ、その見せ方には工夫が必要である。見せ方のテクニックのひとつに「対比」がある。これはやや即物的なフレームワークかもしれないが、有効と思ったので書く。まずやることは、自身の研究の応用例を、簡単にでもよいのでシステムとして実装することである。そのとき、自身の方式をつかったものと、過去の方式をつかったものの、ふたつを用意する。システムの用意ができたら、それらを並べて、同時に走らせる。そして、その様子を見てもらう。自身の方式をつかったものと比べ、過去の方式をつかったものの挙動がおかしかったり、のろまであったり、ぎくしゃくしていたりすれば、しめたものだ。それを見ているひとは、視覚的に、直感的に、ぼくらの方式の優位さを体験することだろう。

 

ぼくはこれまで「自身の研究のよさが一般のひとびとに伝わらないのは、研究が本質的に地味であるからだ」と考えがちであった。同じ思いを抱えているひとは少なくないだろう。そんなひとに向けて、この文章を書いた。