Joel on Software

Joel on Software   このページは"ジョエル・オン・ソフトウェア

 

※新しい翻訳はJoel on Software Translation Projectにあります。

その他の "Joel on Software" の記事(日本語)

その他の "Joel on Software" の記事(英語)

著者へのメール(英文のみ)

 

5つの世界


Joel Spolsky ジョエル・スポルスキ
翻訳: Yasushi Aoki 青木靖
2002/5/6

ある重要なことがプログラミングやソフトウェア開発についての文献でほとんど語られず、そのため私たちは互いに誤解する結果となっている。

あなたはソフトウェア開発者だ。私もそうだ。しかし私たちの目的や要求は異なっているかもしれない。実際、ソフトウェア開発にはいくつかの異なる世界があり、異なった世界ではルールも異なっている。

あなたがUMLモデリングの本を読んでも、それがデバイスドライバのプログラムを作るのには役立たないということはどこにも書かれていない。あるいは「(.NETに必要な)20MBのランタイムは問題ではない」というアーティクルを読んでも、それは当たり前のことに触れていない:あなたがROMが32KBの携帯電話のためのコードを書いているなら、それは十分に問題だ

ソフトウェア開発には、しばしば交わっているがたいていは分かれている、5つの世界があると思う。その5つとは:

  1. パッケージ
  2. インターナル
  3. 組み込み
  4. ゲーム
  5. 使い捨て

あなたがエクストリーム・プログラミングについての最新刊や、スティーブ・マッコーネルのすばらしい本や、あるいはJoel on Softwareや雑誌Software Developmentを読むとき、ソフトウェア開発をどう行うかについてのたくさんの主張を目にするだろうが、彼らがどんな種類の開発の話をしているのかについて言及していることはめったにない。世界が違えばする必要のあることも違うので、これは残念なことだ。

それぞれのカテゴリを簡単に見ていくことにしよう。

パッケージソフトはたくさんの人々によって「野生で」使われるソフトウェアである。それは携帯電話に入れられてCompUSAで売られるかもしれないし、インターネットでダウンロードされるかもしれない。それは商用かもしれないし、シェアウェアか、オープンソースか、GNUか、あるいはその他のものかもしれないが、ここで肝心な点は、それが数千あるいは数百万の人々によってインストールされ使われるソフトウェアだということだ。

パッケージソフトにはその2つの特質に由来する固有の問題がある:

  • 多くのユーザはしばしばそれの代わりとなるものを持っているため、平均よりも使いやすいユーザインタフェースが成功のためには必要である。
  • 非常に多くのコンピュータで実行されるため、コンピュータごとの違いに対する際立った柔軟性を持っている必要がある。先週ある人がCityDeskのバグについてメールしてくれたが、それはポーランド語版のWindowsでだけ起きるもので、右Altキーが特殊文字を入力するために使われているせいだった。私たちはIE 5.01、5.5、6.0がインストールされた、Windows 95、95OSR2、98、98SE、Me、NT 4.0、Win 2000、Win XPでテストを行っていたし、英語版、スペイン語版、フランス語版、ヘブライ語版、中国語版のWindowsでテストをやっていた。しかしポーランド語版ではまったくやっていなかった。

パッケージソフトには3つの大きな変種がある。オープンソースソフトウェアはしばしば開発費なしで開発され、そのことがダイナミクスを大きく変えている。たとえば、「楽しい」と思われないことがどのボランティアチームによってもなされない,ということがしばしば起こる。マシュー・トーマスが雄弁に語ったように、それはユーザビリティを損ないうる。地理的に分散して開発が行われることが多く、チームのコミュニケーションの質は非常に幅のあるものとなる。オープンソースの世界では、ホワイトボードを囲んで箱や矢印を描きながら、顔をつき合わせて会話するということがめったになく、そのため箱や矢印を描くのが助けとなるようなデザイン上の決定はまずく行われるのが普通だ。結果として地理的に分散したチームはデザインがほとんど、あるいは全然必要ない既存ソフトのクローンの開発においてずっとよい結果を出す。

コンサルウェアはパッケージソフトの変種のひとつで、多くのカスタマイズを必要とし、インストールには一群のコンサルタントが必要となり、法外なコストがかかる。CRMやCMSパッケージはしばしばこのカテゴリに入る。人は彼らが実際何もしておらず、ただ時間当たり$300になるコンサルタントの軍隊を送り込む言い訳をしているだけだと感じる。コンサルウェアはパッケージソフトの衣を着てはいるが、実装に要する高いコストは、それが実際にはインターナル・ソフトウェアにより近いことを物語っている。

Salesforce.comや、さらにありふれたeBayのような商用Webベースソフトウェアは、依然として、もっと使いやすく、より多くのブラウザで実行できるようになる必要がある。開発者は(少なくとも)配備環境データセンタのコンピュータについては、ある程度コントロールができるという贅沢を手にしているが、多くのバラエティのあるWebブラウザと多数のユーザとを扱えなければならないので、私はこれを基本的にはパッケージソフトの変種だと考えている。

インターナルソフトウェアは、ひとつの会社にあるコンピュータ上で、ひとつの状況において動きさえすればよい。このことにより開発はずっと容易なものとなる。あなたはInternet Explore、Microsoft Office、Windowsの特定のバージョンを前提とすることができる。グラフが必要ならExcelに描かせればよい。私たちの部門の人間はみんな Excelを持っているのだから(もしこれをパッケージソフトでやったとしたら、あなたは潜在的な顧客の半分を失うことになる。)

そのソフトウェアを使う必要のある人の数は限られており、彼らにはそれに関して選択肢はなく、それでやっていく以外にないため、ユーザビリティの優先度は低いものとなる。開発スピードがより重要である。というのは開発努力の成果はたった一つの会社にしか行き渡らないので、正当化できる開発リソースの量は非常に少ないからだ。Microsoftは1ユーザあたり平均$80しかしないオペレーティングシステムの開発に5億ドルを使うことができる。しかしデトロイト・エジソン(電力会社)がエネルギー取引プラットフォームを開発するときには、その投資をひとつの会社から回収する必要がある。妥当なROIを得るためには、パッケージソフトに対するような多くの費用を使うことはできない。そして悲しいかな、多くのインターナルソフトウェアがひどい失敗に終わる。

組み込みソフトウェアはハードウェアとセットになっており、ほとんどの場合アップデートできないというユニークな特質を持っている。これはまったく違った世界だ。次のチャンスというのがないため、品質に対する要求はきわめて高い。通常のデスクトップコンピュータと比べてはるかに遅いプロセッサを扱わねばならず、あなたは最適化に多大な時間を費やすことになるだろう。コードはエレガントであることよりは速いことが重要だ。あなたに使える入出力デバイスは限定されている。Picture of Hertz Neverlost GPS先週借りた車のGPSシステムは、そんな哀れなI/Oを持っており、ユーザビリティは陰鬱なばかりだった。こういうデバイスで住所を入力したことがあるだろうか?それらはスクリーンにキーボードを表示し、矢印キーを使って5つの3x3マトリックスから文字を選択しなければならない。(このUIのイラストをもっと見たければリンクをたどって。私の車のGPSにはタッチスクリーンがあり、UIはずっとましなものになっている。ちょっと脱線してしまった。)

ゲームは二つの理由でユニークだ。第一にゲーム開発の経済はヒット指向だ。あるゲームはヒットし、他の多くのゲームは失敗する。そしてあなたがゲームソフトで金を稼ぎたいのであれば、このことを認識し、ビッグヒットで失敗の穴埋めができるようにゲームのポートフォリオを持つ必要がある。これはソフトウェアよりは映画に似ている。

ゲーム開発のより大きな問題は、たった一つのバージョンしかないということだ。あなたのユーザはDuke Nukem 3Dを一通りやったら、バグフィックスや新しい武器のためにDuke Nukem 3.1Dにアップグレードしたりしない。いくつかの例外を除けば、ゲームを最後までやってしまったら、もう一度やるのは退屈なものだ。そのためゲームには組み込みソフトと同じ品質要求があり、はじめらから正しくやることは財務上の強い要請である。パッケージソフト開発者には、1.0が人々のニーズに合わず売れなくても2.0は売れるかもしれない、と期待できる贅沢がある。

最後に使い捨てコードだが、これは何か別なものを得るためだけに一時的に作られるコードで、ひとたび目的のものが得られたなら必要なくなるものだ。たとえばあなたは、手に入れた入力ファイルを操作して何か別のことで必要なフォーマットに変換するための、小さなシェルスクリプトを書くかもしれず、そしてこれは一度きりしか使われない。

たぶん私が見落としている別な種類のソフトウェア開発というのもあることだろう。

ひとつ知っておくべき重要なことがある。フルタイムのソフトウェア開発のグルやコンサルタントによって書かれたプログラミング方法論についての本をどれか読むとき、あなたは彼らがインターナル・企業ソフトウェアの開発について話していると思っていい。それはパッケージソフトでも、組み込みソフトでも、そして間違いなくゲームでもないだろう。なぜか?それは企業がこれらのグルたちを雇っているからだ。彼らが勘定を払っているのだ。(信じてほしい、 id softwareがエド・ヨードンを構造化分析について話してもらうために雇うなど考えられないことだ。)

先週ケント・ベックが、エクストリーム・プログラミングをやっていればバグトラッキング・データベースは実際必要ないと話していた。ペア・プログラミング(恒常的なコードレビュー)とテスト駆動開発(自動テストの100%カバレッジ保障)の組み合わせがバグを生み出すなんてありそうにないというのがその理由だ。私にはそれが正しいとは思えない。ここFog Creekで私たちが使っているバグトラッキング・データベースの中を覗いて、どんなバグがその中を賑わしているのか見てみた。

驚くなかれ、ペアプログラミングやテスト駆動開発で発見し得たものは、その中のごく一部だった。私たちの「バグ」の多くは、実際にはXPがストーリーと呼んでいるもので、基本的には機能要求である。私たちはバグトラッキングシステムを、私たちが実装したいと思っている大きな機能だとかちょっとした改善だとかについて、それを記憶し、優先付けし、管理するのに使っている。

そのほかのバグの多くは、ポーランド語のキーボードの問題みたいに、実地に使っていて見つかったものだ。ペアプログラミングではそれは見つけられない。そして異なる機能が一緒になったときに起こる、私たちのところでは決して起こらなかった論理的なエラーというのがある。プログラムが大きく複雑になると、あなたが考えもしない機能間の相互作用が増える。ありそうにない文字の並び(お知りになりたければ、それは{${?だった)が字句解析を混乱させる。あるftpサーバは存在しないファイルを削除しようとするとエラーを起こす(私たちのftpサーバは文句を言わないので、これは私たちには起こらなかったことだ)。

私はそれぞれのバグを注意深く調べた。私たちがサービスパックで直したCityDeskの106のバグのうち、正確に5つだけがペアプログラミングやテスト駆動デザインで防ぎ得たものであった。私たちが把握しているバグは実際にはもっとたくさんあり、見解(顧客によってしか修正できない!)は、XPメソッドで見つけられたかもしれないバグほど重要ではなかった。

しかしケントは、別なタイプの開発に対しては正しい。多くの企業開発アプリケーションではこれらのどれもバグとはみなされない。不正な入力でプログラムが落ちた?もう一度起動して、今度はあなたの{${?に気をつけるだけのことだ。そして私たちは一種類のFTPサーバしか使ってないし、会社のなかでポーランド語版Windowsを使っている者はいない。

ソフトウェア開発のほとんどのことは、あなたがどんな種類のプロジェクトで働いているかに関わらず同じであるが、しかしすべてがというわけではない。誰かがあなたにメソドロジーについて話すとき、あなたがしている仕事にどう適用できるか考えてみることだ。その人がどこから来ているのか考えてみることだ。スティーブ・マッコーネル、スティーブ・マグワイア、それに私は、みなとても狭い方面から来ている:ワシントン州のレドモンドで書かれた、マスマーケット向け表計算パッケージソフトだ。そんなわけで、私たちは使いやすさに対する基準が高く、バグと認定する基準が低い。他の多くのメソドロジー・グルたちは、インハウス企業開発に対するコンサルティングで生計を立てており、それが彼らの話題にしていることでもある。何にしても、私たちは互いに学べることがあると思う。



この記事の原文(英語)は Five Worlds です。 

ジョエル・スポルスキは、ニューヨーク市の小さなソフトウェア会社  Fog Creek Software の設立者です。イェール大学を卒業後、マイクロソフト社、Viacom社、 Juno社でプログラマとして働きました。


このページは著者の個人的な意見を掲載したものです。
All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky