FogBugz 4.0への道: パート1
From The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳
2005年3月28日 月曜
それは前のオフィスにかかってきた一本の顧客の電話で始まった。
私たちの顧客の多くは、ありがたいことに、ここFog Creekでの考え方を理解してくれている。つまり、私たちは既成のパッケージソフトを作っており、顧客は必要な機能を備えたものを低価格で購入でき、それで要求が満たせない場合、まあ、私たちは喜んで話を聞きはするが、しかし99ドルという値段でカスタマイズバージョンを提供してあげることはできない。悪しからず。
けれども顧客の中には依然私たちが大きなエンタープライズソフトウェア企業であるかのように思っている人たちもいる。電話をかけて3ヶ月もセールス担当と交渉すれば、会計年度の最後の日に、50万ドルの契約と引き替えに長い新機能のリストを飲ませることができるだろうと考えるのだ。
それは結構なのだけど、しかし私たちはセールス担当を置いてはいないし、そういうベンダであるわけでもない。私たちの顧客は値段の安いことを気に入ってくれているが、彼らがみんな、そのことの帰結を理解しているわけではない。彼らの本部へと飛んで行き、開発チームにソフトウェアのデモをするように依頼してくる。彼らは機能の長いリストをスプレッドシートにして送りつけてきて、サポートしている機能をチェックしろと言う。彼らはRFP(ぞーっ)を送って寄こしさえする。RFPというのは"Request for Proposal"(提案依頼書)の略だ。これは大きな企業が小さな会社に特注の提案をするよう求めるものだ。小さな会社は3週間狂ったように働いて200ページの提案書を作ってレーザープリンタで印刷し、高い費用を払ってFedExで送り届け、最後の最後になって提案書はゴミ箱に放り込まれるのだが、それは大企業にはお気に入りのベンダがいて、そのベンダは彼らをブラックジャックとストリップ付きのアトランティックシティへの視察にヘリコプターで連れて行き、中身には関係なく契約は決まるからだ。しかし購買部門の誰かが何かよくわからない理由で、おそらくは昇進を目指しているためか、その提案には「競争入札」の機会が開かれているべきだと主張し、小さな会社が犠牲として提案をするように選ばれるのだが、それで採用される可能性はなく、ただ提案プロセスが腐敗していないように見せかけるだけのためなのだ。あなたのところがそういう小さな会社であるなら、そんな罠にははまらないようにして、契約の取れることがすでに分かっているのでもない限りRFPに応じて時間を無駄にしたりしないことをお勧めする。
とにかくさ。
そういう顧客のありがたいところは、FogBugzにどんな機能を追加すべきかフィードバックを与えてくれるということだ。ここFog Creekで私たちは「競合ではなく、顧客に耳を傾けよ」というマントラを掲げている。だから大きな潜在顧客から電話があったときには、取りあえず話は聞くことにしている。
FogBugz 4.0の計画段階の初期に、大きな非営利組織から電話を受けた。彼らは非常に多くの本数のFogBugzを導入することを考えており、部門のマネージャたちが自分の部門のバグケースを一カ所で見られることを必要としていた。部門は複数のプロジェクトを管理している場合もあった。
手っ取り早い解法は、データベースに部門のテーブルを追加して、レポートが部門ごとに分類されるようにすることだ。しかし私たちはパッケージソフト会社であり、何かをするときには、多くの顧客にとって有用であるような一般的な仕方でやりたいと思っている。だから私たちは少し時間をかけて、より一般的な機能をデザインし、1つの機能で顧客の問題の大きなクラスを解決できるようにした。部門ごとに案件を整理したいという顧客のほかに、コンサルティングをしていてクライアントごとに案件を整理したいという顧客もいた。これらの顧客は多くの場合、クライアントはFogBugzにアクセスできるが、他のクライアントのバグは見ることができないというプライバシー機能を欲しがっていた。一方、私たちの顧客にはユーザが10人か20人という小さな会社が多く、そういう会社では部門とかクライアントとかプライバシー機能とかいったものを気にかけていないので、それを必要としない顧客にはまったく影響がないように機能を実装する必要があった。FogBugzを、用もない機能や入力フィールドがたくさんあるでかくて扱いにくいものだけにはしたくなかった。
だから、この特定の顧客に機能を送り届けるのにはちょっと時間がかることになった。その顧客から電話を受けてから新機能を入れたアルファリリースを納入するまでには約12ヶ月が経過していた。それは主として私たちがメジャーリリースを1年半ごとにしていることによる。そういうスケジュールにしている理由は、アーティクル『Picking a Ship Date』の中で示している。
私たちが2005年2月22日にリリースしたFogBugz 4.0の他の機能の多くもまた、顧客からのフィードバックに基づいている。私たちは顧客からバグレポートにスクリーンショットを添付するにはどうすればいいのかと聞かれることがよくあって、こんな風に答えていた。「ああ、それなら簡単です。Alt+PrtScを押し、ペイントを立ち上げて、貼り付けたらファイルをどこかに保存し、ブラウザを起動してFogBugzのホームページを開き、メニューの"New Case"をクリックしてバグについて入力し、ファイルを開くボタンをクリックして、さっき作ったファイルを指定すればいいんです」。こんな簡単なことはないよね?
ただもう少し簡単にできるかもしれない。
最後にはこう考えた。「タスクバーアイコンを用意して、クリックするとスクリーンショットが撮られ、そのためのバグレポートが作成されるようにするには、どれくらい手間がかかるかな?」。そんなに難しくなさそうだ。
私はWindows版を、おなじみの「週末」に作り上げた(つまり、1回の週末で動くようにすると、それから2週間でバグ修正し、Internet Explorerのパッチで発生したバグを回避するためにさらに1週間かけて書き直した)。ダニエル・バーリンジャーがREALbasicを使って2週間でMacintosh版をサッと作り上げた。そして今や画面上で見ているバグを入力するのは2回のクリックですむようになった。
素晴らしい。
私は自分の入れているバグレポートの30%はスクリーンショットだけで十分に説明できることに気づいた。次に挙げるのは、私が月曜に入力したバグレポートの全体だ。
赤い四角はスクリーンキャプチャソフトに組み込まれたハイライトツールで付けたものだ。私が入力した「wha?」という言葉(画面の白い部分の2行目)は、たぶん余計だろう。タイトルなしのバグレポートで構わないなら、バグレポートは4回のクリックとドラッグだけで作成できる(「Four Clicks and a Drag」は何かバンドの名前みたいだ。あるいは私が今考えているFog Creekの開発チームの名前か)。
私は競合にはあんまり注意を払ってはいないのだが、私の知る限りでは、よそのどこもこの機能を持っていない。
競合のどこかがこの機能をクールだと思ったなら真似することもできるわけだが、それにはしばらく時間がかかるだろうし、ことに彼らが私のサイトで読んでリリースを18ヶ月おきにしているのならなおさらだ。
競合に耳を傾けていたならスクリーンショット機能を付けようとは思わなかっただろう。私たちの顧客が付けてくれと直接言ったわけではないが、彼らがスクリーンショットを添付する方法をよく聞いてくることに気付いたので、その機能を付けることにしたのだ。
明日のパートIIではドッグフードの話をしよう。
(オリジナル: The Road to FogBugz 4.0: Part I)
