優先順位を決める
From The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳
2005年10月12日 水曜
FogBugz 4.0をいじり回すのをやめて、5.0に取りかかる時だった。私たちは大きなサービスパックをリリースし、誰も出会うこともないだろう細かいバグを山ほど修正し(そして誰も出会うこともないだろう新しい小さなバグを2つほど新たに作り)、何か本当に新しい機能を付け加え始める時になっていた。
開発に取りかかる準備ができた頃には、改良のためのアイデアはプログラマ1700人で何十年分になるくらいたまっていた。あいにくと私たちの元にいたプログラマは3人だけであり、来年の秋にはリリースしたいと思っていたので、やることの優先順位付けをする必要があった。
私たちが機能のリストを優先順位付けするのに使った方法のことを話す前に、やるべきでない2つの方法について話しておこう。
1番目。誰か1人の顧客に約束しただけのために何かの機能を実装しているのに気付いたなら、その時あなたの頭の中で危険の赤信号が点灯してなきゃいけない。1人の顧客のために何かしているのは、安請け合いのセールス担当がいるせいか、あるいはコンサルティングウェアへと向かう坂を下っているためだろう。別にコンサルティングウェアにまずいことがあるわけではない。それはくだり下りるには快適な坂だが、パッケージソフトほどの収益性はない。
パッケージソフトはソフトウェア開発における｢交渉なし｣モデルだ。あなたはソフトウェアを開発してビニールで包装し、そして顧客はそれを買うか買わないかだ。彼らはもう一つ機能を追加してくれたら買うよと持ちかけてきたりはしない。彼らが電話で機能について交渉してくることもない。Microsoftに電話してこう言うこともできない。｢Excelにあるタイ語で数字を表記できるBAHTTEXT関数は気に入っているんだけど、同じ関数の英語版が必要なんだ。その関数を実装してくれたらExcelを買うよ｣。なぜなら、あなたがMicrosoftに電話をかけたなら、彼らはこんな風に答えるからだ。
｢Microsoftにお電話頂きありがとうございます。所定の4桁のプロモーションコードお持ちなら、1を押してください。Microsoft製品のテクニカルサポートを受けたい場合は、2を押してください。Microsoftのプリセールス製品のライセンス、あるいはプログラムの情報については、3を押してください。話す相手を直接指定する場合は、4を押してください。この説明を繰り返して聞く場合は、アスタリスクを押してください｣
どう、気付いた? ｢買う前に製品への追加を希望する機能について交渉したい場合は、5を押してください｣という選択肢はないのだ。
カスタム開発というのはあいまいな世界だ。何を作るのか顧客が言い、あなたが｢本気ですか?｣と聞きくと、彼らはそうだと言い、それであなたは完璧で見事な仕様書を作り、そうして｢欲しいのはこれですか?｣と確認すると、彼らはそうだと答え、それであなたは彼らに消えないインクで、いや、血でサインするように求め、彼らはサインし、彼らの承認したものをあなたは速やかに、正確に、間違いなく構築し、そうしてできあがったものを見て彼らが愕然としてショックを受けているのを目の当たりにし、そしてその週の残りは自分の入っている過失怠慢責任保険であなたの巻き込まれることになった訴訟の費用をカバーできるか、それとも和解金にしかならないか調べるのに費やすのだ。あなたが本当に幸運であるなら、顧客は力なく笑みを浮かべ、あなたの作ったプログラムを引き出しの中に納め、二度とそれを使いもしなければ、あなたに電話をかけてくることもないだろう。
パッケージソフトとカスタム開発の中間のどこかにあるのがコンサルティングウェアで、そこではパッケージソフトを売っている振りをしているが、その実カスタム開発をやっている。コンサルティングウェアの仕掛けというのは次のようになっている:
- ある靴会社のためにプログラムを書く賃金奴隷として働いていて、
- その会社が靴磨きソフトを必要としていたので、
- 細々したJavaScriptと、Franz Lispと、ネットワーク上にある古いMacで動いているFileMakerデータベースを扱うAppleScriptを使い、靴磨きソフトをVB3.0で開発したところ、
- みんなそのソフトをすごくいいと言っているので、いつか自分のソフトウェア会社を立ち上げようと思っていて、もしかしたらビル・ゲイツになれるかもとか、あるいはラリー・エリソン止まりかなとかいつも夢想していたあなたは、
- 元いた会社からShoeShiner 1.0の権利を買い取って、VCの支援を得て自分の会社ShoeShiner LLCを設立し、靴磨きソフトのマーケティングをし始めるのだが、
- ベータテスターは誰もそのソフトを動かすことができず、それというのもAppleScriptへの奇妙な依存性があったり、ソース中にIPアドレスがハードコーディングされていたりしたためで、それぞれの顧客の環境にインストールするのにはひと月もかかり
- しかも顧客をなかなか得ることもできず、それはインストールコストの高さと、とくにSystem 7を動かせるビンテージもののMacintosh IIciをeBayでコンピュータ博物館から買い取る必要があったために製品がすごく高くなっていたせいで、VCはすごくイライラし始め、
- セールスの連中にプレッシャーをかけるようになり、
- そうするとセールスの連中は潜在顧客の中に靴磨きソフトは必要としてないが、ズボンプレスソフトを必要としているところがあるのに気づき、
- セールスガイがセールスガイの本領を発揮して、100Kドル分のズボンプレスソフトを売り込むことに成功し、
- 今やあなたはその顧客のために6ヶ月かけて1つの顧客にしか使われることのない｢ズボンプレスモジュール｣を書いているところで、
- 他の顧客がそれを必要とすることは決してなく、それが実質的に意味するのは、
- 丸一年を費やし、VC資金を得てやったことが、1つのズボン会社のためにプログラムを書く賃金奴隷として働くということなのだ。1に戻る。
スパーキー、可能な限り強くパッケージソフトの世界にしがみついていることを強く勧めないわけにはいかない。パッケージソフトには追加の顧客に対する限界コストがなく、同じものを繰り返し売ることでずっと多くの収益を得ることができる。それだけでなく、開発コストをたくさんの顧客に薄く広げることができるので価格を安くすることもでき、低い価格によってより多くの顧客を得ることができ、それは今や安価になっているあなたのソフトウェアには値段に見合う価値があることを急に多くの人が認めるようになるからで、そうやって人生は良く、すべてがうまくいくのだ。
それだから、1人の顧客に約束したというだけの理由で機能を実装していることに気付いたなら、コンサルティングウェアとカスタム開発の地へと流されているということであり、それがあなたの好きな世界だというならそこで働くのは結構だが、オフザシェルフの商用ソフトウェアが持つ収益のポテンシャルはそこにはない。
私は顧客に耳を傾けるなと言っているのではない。実際Microsoftは、世界経済にまだ参加してもタイ語を学んでもおらず、別な通貨で小切手を書いている人たちのために、BAHTTEXT関数の英語版を実装すべき時だと思っている。そして開発リソースを割り当てる最良の方法は大手の顧客に機能の｢競り｣をさせることなのだと信じたいというのなら、そうすることは可能だが、大手の金持ちの顧客が望む機能はマスマーケットが望む機能とは違っているということにすぐ気付かされることになる。バーツ通貨を扱うために追加する機能は、アリゾナのスコッツデールにある健康スパにExcelを売り込む助けにはならず、そうやって実際やっていることが何かというと、セールスの連中が個人的なコミッションを最大化するために開発者たちをこき使うということなのだ。
それはビル・ゲイツへと至る道ではない。
次に実装機能を決めるのに使うべきでない2番目の方法について話そう。不可避というだけの理由で物事をやらないこと。不可避というのはやるのを決める基準としては十分高くないのだ。ちょっと説明しよう。
Fog Creekの最初の年のことだが、私は何かの書類をファイルにしまおうとして、青のフォルダが切れているのに気付いた。
私は顧客関係のものは青いフォルダ、社員関係のものは褐色のフォルダ、レシートは赤いフォルダ、その他のものは黄色のフォルダと使い分けていた。私は青のフォルダが必要で、それが切れていたのだ。
それでこう考えた。｢どのみち青のフォルダは必要になるんだから、ステープルズに行って買ってこようかな｣
もちろん、これは時間を無駄にすることだ。
実際このことを後で考えてみて、私は昔から、｢いずれやる必要があるのだから今やっといた方がいい｣という理由でつまらないことをやっていたことに気付いた。
私はこの言い訳を、庭の草刈りに、壁の穴の修繕に、MSDNのディスクの並べ替えに(ディスクを色と言語ごとに番号順に並べるのだ)、その他諸々のことをするのに使っていた。そしてコードを書いたり、ソフトを売ったりするのに使うべき時間を無駄にしていた。この2つが、スタートアップが本当にする必要のあることなのだ。
つまり私はこんな風に考えていたのだ。必須なタスクはすべて同じように重要であり、どのみちやらなければならないわけだから、どんな順序でやっても一緒だ! ジャジャーン!
しかし正直に言って、私はただ難しいことを先延ばしにしていただけだ。
私はどうすべきだったのか? まず最初に、ファイルフォルダに正しい色を使うというようなフェチは克服した方がいい。何の違いもない。ファイルを色分けする必要なんかないのだ。
ああ、それにあのMSDNのCD-ROM! 大きな箱に放り込んでおきゃあいい。それで申し分ない。
さらに大事なのは、｢重要｣が2値ではないことに気付いているべきだったということだ。これはアナログ値なのだ。重要性にはあらゆるレベルがあり、すべてをやろうとするなら、何も成し遂げられなくなる。
だから何か成し遂げたいと思うなら、今成し遂げるべき最重要事項が何であるかを、いつの時点においても把握している必要がある。そしてあなたのやっているのがそれと違っていたなら、あなたはあたう限り速く進んではいないということだ。
ゆっくりと、私は先延ばししがちな傾向を直している。私はそれを重要性の低いことをやらないことによって実現している。ある素敵な保険会社の女性がいて、私達のポリシーを更新するために必要な何かのデータをよこすようにと2ヶ月くらいしつこく頼んできたが、私は彼女が50回目くらいに、あと3日で私達の保険が切れると厳しい警告をしてきたときになってはじめてそのデータを渡した。これはいいことなのだ。たぶん。そして私は、机をきれいにしているというのは、効率的でないことの徴かもしれないと思うようになった。
だから、セールスの連中が不用意に顧客に約束したことに基づいて作る機能を決めたりしないことだ。そして重要でない/楽しい機能を、｢どのみちやらなければならない｣という理由で最初に作ったりしないことだ。
FogBugz 5.0の機能の選択の話に戻ろう。以下は私たちが最初の優先順位付けをした方法だ。
まず5x8インデックスカードの束を用意して、1枚に１つずつ機能を書き出していく。それからチームで集まる。私の経験では、これがうまく機能するのは20人くらいまでで、部屋にできるだけ違った視点の人を集めるほど良い。プログラマ、デザイナ、顧客の対応をする人たち、セールス、マネジメント、ドキュメンテーションライター、テスター、そして顧客(!)
みんなにもミーティングまでに機能のアイデアを用意しておくように頼んでおく。ミーティングの最初のパートでは、それぞれの機能をごく手短に見ていき、機能がどういうものかについて大まかな共通認識があることと、それぞれの機能に対してちゃんとカードがあることを確認する。
このステージで重要なのは、個々の機能の長所とか、デザインとか、機能自体についてさえ議論しないということだ。ただそれが何かについて曖昧で大ざっぱなアイデアを持っておく。FogBugz 5.0の機能をいくつか挙げると、以下のようなものがあった。
- パーソナライズできるホームページ
- やさしいソフトウェアスケジュール機能
- 費用を請求できる作業時間の追跡機能
- バグレポートの分岐
- (そのほか46件･･･)
ごくごく曖昧なものだ。この時点ではそれぞれの機能がどう実装されるかとか、何が関わるのかとか知っている必要はない。ここでの目的は、開発を始める上で基礎になる大ざっぱな優先順位付けができればいいのだ。そうやって約50の大きな機能のリストができた。
次のパートでは、それぞれの機能を取り上げて、各人が賛成か反対か投票していく。議論も何もしない。単にそれぞれの機能に賛成か反対かを言うのだ。これによって、14個の機能はあまり支持されてないことがわかった。1票か2票しか得られなかった機能を捨てて、36個の機能候補が残った。
次に、それぞれの機能にコストを割り当てた。スケールは1から10で、1はすぐにできる機能、10は大きな怪獣みたいな機能ということだ。ここで重要なのは、機能のスケジュールをしているのではないということで、ちっぽけな機能と、中くらいの機能と、大きな機能とを分けるのが目的だ。私はただ機能を１つずつ上げて、開発者たちに｢小｣｢中｣｢大｣のどれかを言ってもらった。機能の実装にどれくらいかかるか分らなくとも、バグレポートの分岐が｢小さい｣機能であり、一方広くて曖昧な｢パーソナライズできるホームページ｣機能が大きいということは分った。コストの見積についてのコンセンサスに私自身の判断を加えて、それぞれの機能に値段を付けていった。
繰り返すが、これはごく粗い大ざっぱなものであり、それは別に問題ない。今日スケジュールを立てるというわけではないのだ。ただ優先順位付けしているだけだ。2つの中くらいの機能と、１つの大きな機能と、10個の小さな機能が同じくらいの時間でできるというレベルで合っていれば十分であり、正確さは必要ない。
次のステップでは、30の機能を｢コスト｣付きで並べたメニューを作る。チームの全員がこのメニューのコピーと、所持金として50ドルを持つ。各自所持金を好きなように割り当てて良いが、使えるのは50ドルだけだ。望むなら機能の半分だけ買うこともできる。あるいは同じものを2つ買ってもいい。｢費用を請求できる作業時間を追跡する機能｣が本当に気に入った人は、それに10ドルとか15ドル使うかもしれない。ちょっとだけ気に入ったという人は、自分では1ドルだけ払い、他の人が十分投資してくれることを期待するかもしれない。
次に、みんなが機能に払ったお金を加え合わせる。
最後に、購入額をコストで割る。
そしてその数字の大きい順にソートして、もっとも人気のある機能を見つける。
ジャジャーン! 作りたい機能をみんなが重要だと考える順に並べたリストが得られた。
さらにこれを洗練させることができる。たとえば、自然にまとめられる機能を一緒にする。ソフトウェアスケジュール機能があれば課金時間の追跡は簡単になるはずなので、たぶんこの2つは両方ともやるか、それとも両方ともやらないことにした方がいいだろう。それからこの優先順リストを見ていると、何かごたまぜになった機能があるのに気付くことがある。そういう場合は直せばいい! 何もまだ決まってはいないのだ。開発の過程で優先度を変えることだってできる。
しかし私が最も驚くのは、最終的にできたリストがFogBugz 5.0のための本当にいい優先順位付けになっていて、それぞれの機能の相対的な優先度についての集合的な意見をとても良く反映していたということだ。
優先順リストを手に、私達はリストの上の方から作業し、3月頃に機能の追加を止めて統合とテストフェーズに入るつもりだ。私達はそれぞれの(自明でない)機能に対し、実装の直前に仕様書を書く。
(BDUF対アジャイル美人コンテストのおしゃべりな記録係は、今やすごく混乱していることと思う。｢これはBDUFかな? それともアジャイルかな? 彼は何をしようとしているんだろう? どっちかに決めることはできないの?!)
このプランニングプロセス全体にかかったのは3時間だ。
幸運にも私達よりも頻繁にソフトウェアをリリースできるという場合でも(Picking a Ship Date参照)、あなたは依然リストを順にこなしていく必要がある。ただあなたはどの時点でも手を止めて頻繁にリリースすることができる。頻繁なリリースのいいところは、実際の顧客のフィードバックに基づく機能のリストの再優先順位付けを定期的に行えるということだ。しかしすべての製品にそのような贅沢が許されるわけではない。
このシステムはExcel 5の計画をしているときにマイク・コンテが教えてくれた。会議室に2ダースくらいの人が集まって2時間くらいでやることができた。このやり方をして良かったのは、時間がなくてやれない機能の50%は本当にくだらない機能だったということで、それがないことによってExcelはより良いものとなったのだ。
これは完璧な方法ではないが、ステープルズに青いフォルダを買いに行くのよりはいい。間違いないよ。
(オリジナル: Set Your Priorities)
