FogBugz 4.0への道: パート2

From The Joel on Software Translation Project

Jump to: navigation, search

Joel Spolsky / 青木靖 訳
2005年3月29日 火曜


ずっと以前に私は「この国では犬はどんな仕事をしているの?」という題の記事で、自分のドッグフードを食べることの利点について書いた(自分のドッグフードを食べるというのは「自分の製品を自分で使うこと」を意味する奇妙な言い回しだ)。

私たちは自分のソフトウェアを使うという考えを可能な限り忠実に守っている・・・私の書くものはすべてCityDesk(みんな怒り狂うようなすごく不安定な開発者ビルドだ)を使っているし、開発はもちろんすべてFogBugzで計画し、トラッキングしている。カスタマサービス作業もすべてFogBugzでサポートし、トラッキングしている。それがあなたの出したメールに必ず返事のある理由だ。

まあ、ほとんどいつもということだ。

一年ほど前、私はメールしてくれた人にときどきレスポンスが行かないことがあるのに気付いた。

これはよろしくない。

私はFogBugzの中から彼らのメールを探した。

それは「スパムとして解決」となっていた。カスタマサービスに来たメールを処理した誰かが、そのメールをスパムと判断して、返信せずにクローズしたのだ。

よく調べてみると、そういうのはたいてい件名がスパムみたいか、あるいは空白なためなのだが、前に言ったような単なるオペレータのミスの場合もあった。

その頃私は個人的なメールについてはSpamBayesを使っていた。これは最良のスパムフィルタアルゴリズムと思われるベイジアンフィルタの実装としてたぶん最良のものだ。ベイジアンフィルタはポール・グレアムによって考案され、「スパムへの対策」という文章で2002年8月に公開された。ベイジアンフィルタは経験から学習する。メールをスパムかスパムでないか分類するのに誤りがあったとき、それを訂正してやると、ベイジアンフィルタはメールメッセージの中から手がかりを見つけ、その後の分類をよりうまくやるようになる。

大学出の人間にメールをチェックしてスパムかどうか判定させてみたら1%のメールを間違ってスパムと判定したが、私の経験では、このベイジアンフィルタと呼ばれるアルゴリズムを使った場合の誤判定率は遥かに低いものとなる(誤ってスパムとするのは0.01%くらい)。スパムフィルタに顧客からの重要なメールを誤って削除されやしないかとみんな心配しているようだが、実際は、たくさんのスパムがある場合、うまく実装されたベイジアンフィルタよりも、人間の方がずっと本物のメールを削除しがちなものなのだ。

ベイジアンアルゴリズムについてもう1つ言うと、これはメールサーバではなく、メールクライアントに実装する必要がある。このアルゴリズムは、特定の人が受け取る本物のメールがどのようなものなのか教えてもらう必要があるからだ。たとえばFog Creekでメールを受け取るとき、メール本文に"FogBugz"という語があるのはそのメールがスパムでないことの強い証拠となり、一方で本文中にある"mortgage"(抵当)という語はそのメールがスパムであることの強い証拠となる。しかし不動産屋や銀行であれば、mortgageという語は本物のメールの中にたぶんしょっちゅう現れることだろう。そのため、ベイジアンフィルタは、ユーザがどんなメッセージをスパムとして削除するのか、また、どういう疑わしいメールを救い出しているのかが分からなければ、機能しないのだ。メールサーバを作っているIpswitchの連中は、彼らの元にあるのがサーバだったので、サーバの方にベイジアンフィルタを実装しようとしたのだが、率直なところそのシステムはうまく機能していない。

スパムフィルタリングはクライアントで行われる必要があり、FogBugzはメールクライアントなので、私たちはFogBugzでスパムフィルタリングをする必要があると判断した。

さて、確率うんぬんの話は私には難しすぎるので、サマーインターンのベン・カメンズにやってもらうことにした。ほんの数週間で、彼はベイジアンフィルタの高速で素晴らしい実装を作り上げ、FogBugzの中で実行できるようにした。

ベイジアンフィルタは、ずっと昔から確立している、トレーニングに基づいて文書分類を行うAIアルゴリズムを特殊化したものに過ぎない。それなら、アルゴリズムをもっと一般化して、やってくるメールを「スパム」「嫌疑あり」「ハム」に分類するだけでなく、ハムをさらに「セールス」「テクニカルサポート」「求職」といった山に分けられるようにしたらどうかと考えた。

ベンはさらに何週間か研究を続け、トーナメントアルゴリズムを使うアイデアを考え出した。彼は大学のスポーツ選手なのだが、スポーツ選手というのは世界をトーナメントの言葉で考えるのだ。このアイデアは非常に上手くいった。24時間トレーニングすると、私自身の受信箱を、個人的なメール、Fog Creekへのメール、Joel on Softwareへのメール、Joel on Softwareの翻訳者の調整のメール、Subversionのチェックインコメント、バグ通知、セールスレポートに分類させることができた。率直に言って結果は驚くほど良く、全部同じ構造をしているチェックインコメントのような簡単なケースでは100%の精度で分類でき、個人的なメールとJoel on Softwareの読者のメールを見分けるというような難しいケースでも90%以上の精度で分類できた。

私は共和党支持者のメールと民主党支持者のメールを分類できるか試してみたくなったが、これは調子に乗りすぎだったようだ。

なお、夏の終わりにベンが書いた、彼のアルゴリズムを説明した論文がここにある(PDF)。「なんでバグトラッキングソフトの開発のためにそんなに優秀な人間を雇う必要があるんだ?」と、不快感をかろうじて隠してメールしてくる気難しい人たちに対して、この論文は究極の反論になると思う。

FogBugzにおけるスパムフィルタの実装のクールなところは、分類プログラムが間違っても構わないということだ。ただそれを訂正してやれば自分の生活に戻ることができ、プログラムは間違いから学ぶ。そしてこの学習の間にも、やってくるメールをしかるべき人宛に仕分ける手間の95%を節約してくれる。


スニペット

私たちはドッグフードを食べる経験から、FogBugz 4.0のための素晴らしいアイデアをもう1つ得た。

FogBugzがメールを受け取っている限り、Fog Creekに送られるカスタマサービスのメールは私たちの使っているFogBugzデータベースに入り、そのメールにFog Creekの誰でも回答することができる。

そのうち、顧客の中にときどき、私たちの返信を無礼だと感じる人のいることに気が付いた。よく調べてみると、別に無礼というわけではないのだが、私たちの送るメールが無礼に見えることがあり、それは通常きわめて簡潔で要点をついたものであるためだった。それで私たちは

ああ、その問題なら最新バージョンで修正されているよ。

というようなメールを送るかわりに、次のようなメールを送ることにした。

やあ、メールをありがとう。あなたが何の話をしているのか理解しているつもりだし、それは間違いなく私たちの製品のバグだ。いいニュースは、それが修正済みだということだ! オンラインストアhttps://shop.fogcreek.comに、注文IDとメールアドレスを使ってログインすれば、最新版をダウンロードできる。それでこの問題はこれっきり解決できるはずだ。注文IDが分からない場合は、そう知らせてもらえば調べてあげられる。あるいはFog Creekのオフィス(866-FOG-CREEK)に電話してもらってもいい。
私たちでお手伝いのできる方法が別にあれば知らせてほしい!
ではご機嫌よう。
(実際の人間の署名)

これは英語を日本語に翻訳するようなものだ。私は日本に行ったことはないが、言語学者である父から、東京駅であった話のことを聞いたことがある。そこではアナウンスは日本語と英語でなされる。あなたはノンストップの日本語を4、5分聞いた後、それの英訳が「大阪行きの列車が4番線についた」ということだと知ることになる。日本語では、簡単な話をフォーマルなエチケットで厳重にくるまずに語る方法が、単に存在しないらしい。同じことが、英語であってもメールの文面については当てはまる。この話の教訓は、内容的には同じメールを2通受け取ったとき、素っ気ないメールの方が無礼だと受け取られる可能性が高いということだ。しかし私たちが対応しなければならないメールの量から言って、カスタマサポートに来るメールの一通一通にエマーソンのような返事を書いている時間はない。

そうしてスニペットのアイデアが生まれた。わずかのキータイプで、返信メールに決まり文句を挿入できるようにするのだ。具体的には、「私たちでお手伝いのできる方法が別にあれば知らせてほしい」というようなスニペットを定義して、それに"2"みたいな短いコードに割り当てておく。すると、返信メールを書いているときに、ただ2を打ってからバッククオートキー`を押せば、ジャーン、それが目の前で即座に長いテキストに置き換わる。これは本当にクールで、非常に多くの時間を節約してくれ、誤解される可能性の低い冗長度の高い返信メールを作成することができる。私たちはあらゆる種類のFAQや一般的なメールの文章に使えるスニペットの網羅的なライブラリを作った。

「FogBugzへの道」の明日の回では、私たちの開発したASPからPHPへのコンパイラ/トランスレータであるThistleについて見ることにしよう。


(オリジナル: The Road to FogBugz 4.0: Part II)

戻る

Personal tools