マイク・ガンダロイの「Painless Project Management with FogBugz」への序文

From The Joel on Software Translation Project

Revision as of 18:28, 13 September 2006 by Aoki (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Joel Spolsky / 青木靖 訳
2005年2月11日 金曜


11PPM.PNG

ニューヨークの私の住んでいる所の近くにイザベラの店というレストランがあって、その店はいつでも客でいっぱいだ。

下の階も上の階も道ばたのカフェも、人でいっぱいだ。外には幸せそうなヤッピーたちが大勢いて、通りの向こう側に並んでいる申し分ないレストランには空いた席がたくさんあるというのに、テーブルが空くのを45分も待っている。

いつ行くかは関係ない。日曜のブランチは満席だ。金曜の夜? もちろん満席だ。静かな水曜の夜の11時だったら? いくぶんか早くテーブルに着けるだろうけど、店は相変わらず基本的に満席だ。

料理のためだろうか? そうじゃない。ニューヨークタイムズの非凡なるレストラン批評家ルース・ライカルは、こう言い捨てている。「料理はたいしたことない」

では値段か? 誰も気にしてないと思う。ここはジェリー・ザインフェルドが買った、2つの公園を眺められるアイザック・スターンの部屋の近所なのだ。

競争がないんだろうって? 本気?マンハッタンだよ、ここは!

イザベラの店がうまくいっているヒントをあげよう。私は10年間近所に住んでいて、必ずそこへ戻っていく。いつだって。そこへ行くのをやめる原因になるようなことを、彼らはしたことがないのだ。

これは実はすごくたくさんのことを物語っている。

アートで飾り立てられた、とある作りもののイタリアンレストランには決して私は行かないが、それは、あるとき食事をしていて、ウェイターの態度が無礼さを通り越して残酷なほどだったためで、彼は私たちの主菜の選択をあざ笑い、チップの少なさに文句を言って、文字通り通りまで追いかけてきたのだ。

私は別の薄暗いピザ・パスタ・ビストロにも行かなくなったが、それは食事しているときにオーナーが私たちのテーブルにしばらく居座って、コンピュータのことで頼みごとをしてくるからだった。

赤い長椅子とシマウマ模様の装飾が頭痛を起こしそうな地元のカレーレストランの出す料理が私は本当に好きだ。あのカトリチャットが食べたくてたまらない。地下のトイレから立ち上るアンモニア臭さえ、喜んで見過ごしてやるつもりだ。しかし料理が出てくるのにいつも1時間もかかり、店がガラガラのときでもそうで、そのため私は行かなくなった。 しかし10年通っていて、イザベラの店で不愉快な経験をした記憶は一度もない。

ただの一度も。

これがそんなにも客の入っている理由なのだ。人々は何度も何度も戻ってくる。それはイザベラの店で食事するときには、けっしてまずいことが起らないからだ。

イザベラの店は、徹底的かつ完全にデバッグされているのだ。

そのことに気付くためには10年かかる。それはレストランで食事するとき、ほとんどの場合何も問題が起きないからだ。そのカレーレストランに行くと、どんなに早く出かけても映画を見損なうということに気付くのには2、3年かかる。それからその店を見限る。

だからマンハッタンのアッパーウェストサイドでレストランをやるつもりなら、そして生き残ろうと思うなら、すべてを注意深くデバッグする必要がある。

誰か客を出迎える人間がいつもいるようにする必要がある。この人間は客を席に案内するために案内役のデスクを離れてはいけない。そうでないと次の客が来たときに出迎える人間が誰もいないことになるからだ。かわりに誰か別な人間が、客を席へと案内するのだ。そしてメニューをすぐに出し、彼らのコートを預かり、飲み物の注文を聞く。

レストランは一番いい客が誰か分かっている必要がある。それはレストランが比較的暇な平日の夜に来てくれる地元の人たちだ。そして彼らは金曜の夜でも素早くテーブルに案内してやらなきゃいけない。街の外からやってくる客を多少長く待たせることになっても。

すべてのグラスの水がいつも満たされているようにするための手続きが必要だ。

誰かが不愉快な思いをするとき、それはバグなのだ。それを書きとめておくこと。それに対処する方法を考え出すこと。それをトレーニングマニュアルに追加すること。同じ過ちを決して繰り返さないこと。

イザベラの店は非常に高収益で成功したレストランとなったが、それは料理のためではなく、デバッグされていたからだ。私たちプログラマが「エッジケース」と呼んでいるものをただ正しく扱うことで、人々は店に通い続け、友達にも勧め、ニューヨークタイムズの料理は「たいしたことない」というレビューだってはねのけられるのだ。

素晴らしい製品が素晴らしいのは、徹底的にデバッグされているからだ。レストランであってもソフトウェアであっても、それは変わらない。

素晴らしいソフトウェアであるためには、奇妙でめずらしいことをした場合でもクラッシュしてはいけない。誰でも何か奇妙なことをするものだからだ。

Microsoftの開発者のラリー・オスターマンは、DOS 4の開発をしていて、めずらしいバグを見つけた。彼はDOSのアーキテクトのゴードン・レトウィンに言った。「でも、それが起きるのは100万回に1回くらいのものです」

レトウィンは何と返事したか? 「我々のビジネスではね、100万分の1というのは来週の火曜に起こるってことだ」

素晴らしいソフトウェアはユーザが誤解した場合でも助けてくれる。ユーザがファイルをタスクバーのボタンにドラッグしようとすると、Windowsは基本的には「それはできないよ!」という内容のメッセージをポップアップさせ、さらにユーザがおそらくやりたかっただろうことがどうすれば実現できるか教えてくれさえする(試してみて!)

素晴らしいソフトウェアがポップアップするメッセージは、デザイナがユーザの取り組んでいる問題について、おそらくはユーザよりもよく考えているだろうことを示している。たとえばFogBugzでは、ユーザがあるメールに返信しようとしており、別な人も同時に同じメールに返信しようとしているとき、警告が表示されるようになっている。その場合のユーザの反応は、どういうことか確認できるまでは送信しないというものだろう。

素晴らしいソフトウェアはみんなが期待するように振る舞う。私はウィンドウを閉じるときに、[x]ボタンをクリックするのでなく、ウィンドウの左上隅をダブルクリックしている、おそらくはもはや残り少なくなった人間のひとりだ。なぜそうするのか自分でもわからないけど、素晴らしいソフトウェアではいつもうまくいく。私の使っているソフトウェアの中にはそれほど素晴らしくないものもあって、それは左上隅をダブルクリックしても閉じない。私はいらいらさせられることになる。これにはたぶんたくさんの人がいらいらさせられ、たくさんの人が不平を言ったことだろう。しかしそのソフトウェアを開発した人はバグトラッキングしておらず、そのバグを修正せず、今後修正することもないだろう。

素晴らしいソフトウェアに共通しているのは徹底的にデバッグされているということで、そしてソフトウェアを徹底的にデバッグする唯一の方法は、バグトラッキングすることだ。

バグトラッキングデータベースは単なる記憶の助けでもスケジューリングツールでもない。それで素晴らしいソフトウェアを作るのが簡単なことになるわけでもない。素晴らしいソフトウェアを作ることが可能になるのだ。

バグトラッキングしていれば、すべてのアイデアはシステムに入る。すべての不具合はシステムに入る。テスタがユーザインタフェースについて誤解したことはすべてシステムに入る。誰かが考えついた改善案はすべてシステムに入る。

バグトラッキングソフトウェアは、あなたのソフトウェアをより優れたものへと進化させる遺伝子変異を引き起こす宇宙線を捉えるのだ。

そして絶えず評価し、優先度付し、優先順を決め、分別し、不具合を人に割り当てることで、ソフトウェアは進歩していく。それは改善され続ける。より奇妙な状況を、より多くの勘違いしたユーザを、より多くのシナリオを扱えるようになる。

そうして魔法のようなことが起きる。ソフトウェアは機能の寄せ集め以上のものとなる。突然、それは信頼できるものとなる。信頼性があるというのは、ひどいことには決してならないということだ。それを使っていてユーザは決して腹を立てることがない。ユーザが他のを買えば良かったと思うことが決してない。

そしてこの魔法こそが成功の鍵なのだ。レストランであろうと、ソフトウェアであろうと。


(オリジナル: Foreword to Painless Project Management with FogBugz, by Mike Gunderloy)

戻る

Personal tools