Joel on Software

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

 

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

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

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

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

 

ジョエル・テスト


Joel Spolsky ジョエル・スポルスキ
翻訳: Fukushige Erika 福重 永里香
翻訳チェック: Takeda Toshiyuki 武田俊之
9.8.2000

SEMAについて聞いたことがある?かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った!そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。

ジョエル・テスト

  1. ソース管理システムを使っているか?
  2. 1オペレーションでビルドを行えるか?
  3. 毎日ビルドを行うか?
  4. 障害票データベースを持っているか?
  5. 新しいコードを書くまえにバグを修正するか?
  6. 更新可能なスケジュール表を持っているか?
  7. 仕様書を持っているか?
  8. プログラマは静かな労働環境にあるか?
  9. 買える範囲で一番良い開発ツールを使っているか?
  10. テスト担当者はいるか?
  11. プログラマを採用するときにコードを書かせるか?
  12. 「廊下での使い勝手テスト」を行っているか?

「ジョエル・テスト」の良い点は、それぞれの質問にすぐにイエスノーかを答えられることだ。「1日あたりのステップ数」や「変曲点(inflection-point)毎の平均障害数」について理解する必要がない。一つの質問につき、1点で数えること。
「ジョエル・テスト」には弱点がある。絶対に君の原子力発電所のシステムが安全かどうかを確認するためのテストに使ってはならない

12点は完璧で、11点は許せる範囲だ。だが、10点以下だったら君は本当に深刻な問題を抱えていることになる。実際のところ、大半のソフトウェア開発組織は2点か3点の状態で仕事をしている。そして、彼らは本当に助けを必要としている。なぜなら、マイクロソフトのような会社は常に12点の状態でいるのだから。

もちろん、このテストの項目だけが成功と失敗を決める要因であるわけではない。とりわけ、君が巨大なソフトウェアチームを持っていて、誰も欲しがらない製品を作っているとしたら、このテストに書いてあることはどうでも良いだろう。また、チームが「ガンマン」達の集まりで、このテストにあるようなことを何もせず、今だに世界を変えるような途方も無いソフトウェアを作り出そうと考えているような場合も考えられる。しかし、こういった場合を除いてはすべて同じだ。12の項目を正しく行っていれば、君は確実に製品を作り上げられる、よく統制されたチームを持っている、と言えるだろう。

1. ソース管理システムを使っているか?
私は商用のパッケージソフトを使っていたこともあるし、CVSを使ったこともある。CVSはフリーで、良いソフトだ。
もしソース管理システムを持っていないならば、君はプログラマたちに、協力し合って仕事をするように仕向ける必要があるだろう。ソース管理システムがないと、プログラマは他の人が何をやったのか知る手段がない。誰かが間違いを犯しても簡単に元に戻せないのだ。
ソース管理システムのもう一つの優れた点は、ソースコード自体はそれぞれのプログラマのハードディスクに「チェックアウト」されていることだ。ソース管理システムを使っているプロジェクトが大量のソースコードを紛失した、ということは聞いたことがない。

2. 1オペレーションでビルドを行えるか?
この項目で私が言いたいのは、最新のソースから出荷用のビルドを行うまでにどのくらいの手順を踏むか、ということだ。良いプロジェクトチームではスクリプトをひとつだけ持っていて、このスクリプトですべてのコードから実行ファイルを作る。すべての種類のバージョン・言語・ #ifdef の組み合わせでそれを行い、インストール用のパッケージを作って、出荷用のメディア-CDROM やウェブのダウンロードサイト用 - などを作ることができる。

1度で済まないと間違いを犯しがちだ。そして、出荷が近づけば近づくほど、君は「最後の」バグを直して最後の実行ファイルを作り・・のサイクルをできるだけ早く行いたいだろう。コンパイルをしてインストーラ作成のビルドツールを起動する、等等に20の手順が必要だとしたら、君はおかしくなってばかげた間違いを犯すだろう。

まさしくこの理由で、私が最後に働いていた会社では WISEから InstallShieldに切り替えた。我々はインストール作業をスクリプトで、NTのスケジューラを使い自動で終夜動かせる必要があった。WISEはスケジューラを使って終夜動かすことができなかったので、使うのを止めたのだ。(WISEの親切な人たちが私に請け合ってくれたが、彼らの最新バージョンでは夜中のビルドもサポートしているそうだ。)

3. 毎日ビルドを行うか?
ソース管理システムを使っていると、あるプログラマが、間違えて、ビルドできなくなるような修正をいれたままチェックインしてしまうことがある。例えば、新しいソースファイルを追加して、それぞれのマシン上ではすべてがうまくコンパイルできたとする。しかし、ソース管理にそのソースファイルを登録し忘れてしまう。プログラマはマシンを落とし、そんなことには気づかずに、幸せな気分で帰宅する。その後、チームのほかの人々は仕事ができなくなり、やりきれない思いで家路につくことになる。

ビルドできなくすることは、とても悪いことだ(そして、よくあることだ)。毎日ビルドすることで、この危険をカバーし、気がついていない破損個所が存在しないことを確認できる。大きな開発チームで破損個所が正しく修正されていることを確認する良い方法は、午後、ほら例えば昼休みに毎日ビルドすることだ。全員が昼食前に、できる限り多くのソースファイルをチェックインしておけば、昼食から帰ったころにはビルドが終わっている。ちゃんとビルドできていれば、最高だ。そうしたら、それぞれ最新のバージョンのソースファイルをチェックアウトして仕事を続ける。ビルドに失敗したときは、君はそのエラーを修正するが、他の人たちはビルドに失敗する前の、壊れていないソースファイルで仕事ができる。

エクセルの開発チームで、我々はビルドエラーを出した人は誰でも、罰として次の人がエラーを出すまでビルド係をすることになっていた。この決まりはビルドでエラーを出さないようにするための良い刺激となった。また、ビルド作業をメンバー内で回す良い方法だったので、全員がビルドがどのように動くのかを知ることができた。

日常的なビルドについては、"Daily Builds are Your Friend" を読んで欲しい。

4. 障害票データベースを持っているか?
なんとおっしゃろうと、君がプログラムを作っていて(たとえチームの一員だとしても)、発見されたすべてのバグを記録してあるきちんとしたデータベースを使っていないとしたら、君は低い品質のプログラムを出荷することになるだろう。多くのプログラマは、自分の頭の中にバグの一覧表を持っていられる、と思っている。ナンセンスだ。わたしは1度に2つか3つのバグしか覚えていられない。そして、次の朝か、出荷前の忙しさの中でそれさえも忘れてしまう。絶対に、正式な形でバグの経過を残しておかなければならない。

障害票のデータベースは複雑でも簡単でもよい。きちんと機能する最小の障害票データベースは、それぞれのバグについて以下のデータを含んでいなければならない。

  • バグを再現する完全な手順
  • 正しい動作
  • バグの現象
  • 誰が直すべきものか
  • バグが修正されたかどうか

障害票管理システムを使わない理由が、複雑だから、ということならば、上にあげた項目だけの表を作って使ってみることだ。

バグのトラッキングについてもっと知りたい方はPainless Bug Trackingを読んで欲しい。

5. 新しいコードを書くまえにバグを修正するか?
マイクロソフトのWord for Windowsの一番最初のバージョンは、「死の行進」プロジェクトだといわれていた。永久に続き、躓き続けた。チーム全員がばかばかしいほどの時間働き続けた。プロジェクトは延ばされ、延ばされ、また延ばされた。精神的なストレスは途方もないものだった。何年も遅れてやっとこの危なっかしいソフトが出荷されたとき、マイクロソフトはチーム全員をカンクーン(訳註:メキシコ・カリブ海沿の有名なリゾート地)に送り、バカンスを取らせた。そして真剣に反省した。

その結果マイクロソフトが気づいたことは、プロジェクトマネージャたちがスケジュールを守ることを厳しく強制してきたことだった。このため、プログラマたちはひたすらコーディングの作業に突進し、ひどいコードを書いた。なぜなら、正式なスケジュールにバグ修正のフェーズは組み込まれていなかったのだ。バグの数を減らそうという試みはされなかった。全く逆だったのだ。
ストーリはこんな風だった。文字の行高を計算するコードを書くべきプログラマが、単に "return 12;"と書く。そして、その関数の結果が常に正しくないということを報告する障害表が来るのを待つ。このプロジェクトのスケジュールは、単にバグになるのを待っているだけの機能の出来具合をチェックするものだったわけだ。事後の分析では、このことは「欠点無限大の方法論」と呼ばれた。

この問題を解決するために、マイクロソフトは 「欠点0方法論」とでもいうべき方針を会社全体に打ち出した。社内の多くのプログラマたちは嘲笑した。なぜなら、重役達の命令によってバグの数を減らせると管理部門の人々が考えている、と思ったからだ。実際のところ、「欠点0」とは、常にすべてのバグを修正するまではいかなる新しいコードも書いてはならない、という意味だった。以下がその理由だ。

一般的に、時間が経てば経つほど、バグを直すのにかかるコスト(時間とお金)は増える。

例えば、コンパイル時にタイプか文法エラーが出たら、それを直すのはごく当たり前のことだ。

バグを抱えていて、プログラムを動かそうとした最初のときに見つけたとする。君はわけなく直せるだろう。なぜなら、君の頭の中でそのコードはまだ新鮮だからだ。

2、3日前に書いたコードの中にバグを見つけたとする。それを追い詰めるのには少し時間を要するだろう。しかし、書いたコードを読み直せばすべてを思い出し、手ごろな時間で直せるだろう。

でも、2,3ヶ月前に書いたコードの中のバグについては、君はそのコードについて多くを忘れているだろう。そして、直すのはこれまでよりずっと大変だ。このケースでは、君は誰か他の人のコードを直していて、書いた本人は休暇でアルバ島(訳註:ベネズエラ北西カリブの島・リゾート地)に行っているかもしれない。この場合、バグを直すことは科学"science"のようなものだ。ゆっくり、順序立てて慎重にやらなければならないし、直す方法を見つけるのにどのくらいかかるのか、確かなところがわからない。

そして、すでに出荷されたコードのバグを見つけたら、それを直すには途方も無いコストを招くだろう。

正しいやり方でバグを直さなければならない理由は以上のことで、つまり時間が少なくてすむからだ。もう一つ理由がある。それは、新しいコードを書くのにかかる時間を予測することの方が、バグを直すのにかかる時間を予測するよりも簡単だということだ。
例えば、リストをソートするコードを書くのにどれくらい時間がかかるか見積もって欲しいと君に頼んだとする。君はかなりきちんとした数字をくれるだろう。でも、君のコードがInternet Explorer 5.5がインストールされた環境ではうまく動かない、というバグを直す時間を見積もって欲しいと頼んだとする。君は恐らく推測することすらできないだろう。なぜなら、君は(きっと)何がバグの原因なのか知らないからだ。検証するのに3日かかるかもしれないし、2分で終わるかもしれない。

つまり、直すべきバグを山ほど残したままのスケジュールを持っていたとしたら、そのスケジュールは当てにならないということだ。しかし、わかっているバグをすべて直してあり、残っているのは新しいコードだけだとしたら、君のスケジュールはすばらしく正確だろう。

バグの数を0に保つことの素晴らしい点はもうひとつある。競争に迅速に対応できることだ。プログラマの中にはこのことを「常に出荷可能な状態にしておく」と言う人々もある。そうすれば、君の競争相手が君の顧客を奪う素晴らしい新しい機能を取り入れたとしても、君はその機能を入れるだけで、即座に出荷できる。溜め込んだ山のようなバグを修正する必要はないのだ。

6. 更新可能なスケジュール表を持っているか?
さて、これでやっとスケジュールの話になった。君のコードがビジネスにとって重要だとしたら、そのコードがいつできるかを知ることがビジネスにとって重要である理由はいくらでもある。ご存知のとおり、スケジュールを作ることに関してはプログラマは不機嫌になる。出来上がったときが終わるときさ、とプログラマは営業担当者に叫ぶものだ。

不幸にして、それで済ませるわけにはいかない。コードを出荷する前には計画上の決定項目が山ほどある。コードを出荷するにあたって販売促進で先を行くための、デモやトレード・ショーや広告等々だ。こういったことを行う唯一の方法はスケジュールをもつことで、常にそれを更新し続けることだ。

もう一つ、スケジュールを持つ決定的な理由がある。それは、どの機能を入れるかを決めざるを得なくするためだ。スケジュール表があることにより、君は最低限の重要な機能だけを選び、「featuritis(機能病)(通称 "scope creep":つる草のはびこり現象)」に陥るよりは、むしろ機能をカットせざるを得ないだろう。

スケジュールを守ることは難しいことであってはならない。私の記事、 "Painless Software Schedules"を読んで欲しい。良いスケジュール表を作るための簡単な方法について書いてある。

7. 仕様書を持っているか?
仕様書を書くことというのは、デンタルフロスを使うことのようなものだ。誰もが良いことだといいつつ、誰もそれをしない。

これがなぜなのかはわからないが、多分ほとんどのプログラマがドキュメントを書くことを嫌っているからだろう。その結果、チームがプログラマだけで構成されている場合は問題を招く。プログラマは、ドキュメントを書くよりはコードの中で問題を解決しがちだ。まず先に仕様を考えようとしないで、コードの中に深くもぐりこんでコードを書こうとしがちだ。

設計段階で問題を見つけたときは、数行の文章を書くだけで簡単に解決することができる。一度コードが書かれると、感情的にも(人々はコードを捨てることは大嫌いだ)、時間の点からいっても、問題を解決するのにかかるコストは劇的に高くなる。だから、実際に問題を解決するのには抵抗があるだろう。仕様書から作られたのでないソフトウェアは普通、結果として悪い設計になってしまうものであり、スケジュールは管理不能に陥る。これはNetscapeで起こったことのように見える。最初の4つのバージョンはこういった混乱に入り込み、管理部門はおろかにもコードを投げ捨てて最初からやり直した。そしてまたModillaで同じミスを完全に繰り返し、制御不能で錐揉み飛行するモンスターを作り出した。そして最初のバージョンにたどり着くまでに数年を要した。

私のお気に入りの理論は、この問題はプログラマを writing の集中コースに通わせて書くことの苦手意識を無くすることで解決できる、というものだ。もう一つの解決方法は、文章化したスペックを作ることのできる出来の良いマネージャを雇うことだ。どちらのケースでも、「仕様書なしのコードはなし」という単純なルールを守らせなければならない。

仕様を書くこと全般については、私の "4-part series"を読んで欲しい。

8. プログラマは静かな労働環境にあるか?
広く書かれていることだが、生産的な利益は、知識労働者に空間と静かさとプライバシーを与えることによってもたらされる。古典的なソフトウェア管理の本「ピープルウェア」はこれらの生産性が広範囲に渡ることを述べている。

ここに問題がある。我々はみな知識労働者が「すらすらできる」状態のとき、"in the zone"(自分の中に入った状態)としても知られているが、完全に仕事に集中していて周りの環境から遮断されてしているときにベストの仕事をできるということを知っている完全に集中している間に、時間を忘れて素晴らしいものを作り上げるのだ。これが、生産的な仕事をやりとげる時だ。ライター・プログラマ・科学者、そして野球選手さえもが、完全に集中した状態について語ることができるだろう。

問題は、「集中する」ことは簡単ではないということだ。計ってみるならば、最高の生産性の状態で仕事を始めるまでに平均15分かかるようだ。時には、疲れているときやその日にすでに沢山の生産的な仕事をしてしまったときには、集中することすらできず、残りの就業時間をぶらぶらしたりウェブサイトをみたり、テトリスで遊んだりしてすごすことすらある。

もうひとつ、集中した状態から覚まされることがとてもた易いことだ、という問題がある。騒音、電話のなる音、昼食、コーヒーのためにスターバックスまで5分のドライブ、そして同僚による割り込み、特に同僚による割り込みが問題だが、これらのことはすべて君を集中から覚ますものだ。同僚が君に質問すると1分間の割り込みが入る。しかしそのことで、君は集中が途切れ、再び生産的な状態に入るまで30分を要し、君の全体の生産性にとっては深刻な問題となる。もし君がカフェイン中毒のドットコム企業のやつらが作りたがる、騒々しい牛の囲い場のような環境にあって、営業担当者がプログラマの隣りで電話に向かって叫んでいるとしたら、君の生産性は落ち込むだろう。というのも、そんな環境では知識労働者は次から次へと割り込まれ、決して集中することができないからだ。

プログラマについていうと、この問題は特に厄介だ。プログラマの生産性というのは、細々した沢山のことをちょっとずつ記憶しながら同時に操ることができるかどうかにかかっているからだ。いかなる時に割り込みが入っても、そういった細かいことがクラッシュする。仕事に戻ったとき、君は細かいこと(使っているローカル変数の名前や検索アルゴリズムのどこまでを終えたかなど)を思い出せないだろう。そして、そういったことを思い出すことからやり直して、そのために元のスピードに戻るまでには多くの時間がかかる。

ここに簡単な計算式がある。いいかい、(これまで書いてきたように)あるプログラマの邪魔をしたとすると、たとえそれが1分間でも実際には15分間の生産力を吹き飛ばしたことになる。例えば、ここに二人のプログラマがいるとしよう。ジェフとマットだ。典型的なディルバート式の囲いの中に隣り合わせで座っている。(訳註:ディルバートは、1989年よりアメリカの新聞各紙で連載されたコミックの主人公。うだつのあがらない係長で、彼の働くオフィスはキュービクルと呼ばれる一人ずつのパーティションに区切られている。)マットはstrcpyのUNICODEバージョンの関数名が思い出せない。マットは関数名を30秒かけて自分で探すこともできるし、15秒かけてジェフに聞くこともできる。ジェフは隣りに座っているから、ジェフにたずねる。ジェフは注意を逸らされ、15分の生産を失う。(マットの15秒を節約するために、だ。)

さて、二人を壁とドアで区切られた別々の部屋に引越しさせるとしよう。そうするとマットは関数名を忘れたときにはやはり30秒かけて自分で探すか、今や45秒かかり立ち上がることも必要となったが、(プログラマの平均的運動能力からいってこれは簡単なことではない)ジェフに聞くこともできる。立ち上がりたくないので、マットは自分で調べる。マットは30秒の生産を失うが、ジェフの15分は節約できた。ハハハ!

9. 買える範囲で一番良い開発ツールを使っているか?
コンパイルすることは、普通のPCでまだ時間をかけずにはできないことの一つだ。君のコンパイル作業が数分以上であるなら、最新で最高のPCを買うことによって時間を節約できる。15分以上かかるなら、プログラマはコンパイル中に退屈し、The Onionを読むほうに鞍替えするだろう。そして、The Onion はプログラマの集中力を吸いあげ、何時間もの生産を失わせる。

GUIのコードのデバッグを単一のモニタで行うことは不可能でないにろ、苦痛なことだ。君がGUIのコードを書いているのなら、2つのモニタを使うことで事はずっと簡単になる。

ほとんどのプログラマは、結局アイコンやツールバー用のビットマップを扱わねばならないのに、良いビットマップエディタを持っていない。Microsoft Paintを使ってみるというのは冗談のような話だが、多くのプログラマはそうしなければならないのが現実だ。

私の最近の仕事で、当時のシステム管理者は私に自動の苦情メールを送り続けた。それは、私がサーバのハードディスクの…よく聞いて欲しいが…220MBを使っているというものだった。私は、最近のハードディスクドライブの値段から考えると、この容量にかかるコストは私の使うトイレットペーパーのコストよりもはるかに安いということを指摘した。わずか10分でも時間をかけて私のディレクトリをきれいにすることは、生産性からいうと大変な無駄なのだ。

トップクラスの開発チームではプログラマを苦しめない。能力の劣ったツールを使うことでもたらされるほんの小さなフラストレーションによってでさえも、プログラマは不機嫌となり、不幸な気分になる。そして不機嫌なプログラマとは、すなわち生産性の低いプログラマだ。

そして、これらすべてに付け加えるならば…、プログラマはかっこいい最新式のものを与えることで簡単に抱きこめるものだ。これは実際のところ、君のために彼らを働かせるには、他に負けない給料を支払うよりもずっと安上がりな方法だ!

10. テスト担当者はいるか?
君のチームに、少なくともプログラマ2、3人に一人の割合で専門のテスト担当者がいないとしたら、バグだらけの製品を出荷するのは簡単だ。あるいはテスト担当者が1時間30ドルでできる仕事を1時間100ドルのプログラマがやることによって、お金を無駄に使っていることになる。テスト担当者を節約することは経済的にとんでもない無駄なので、もっと多くの人が気づかないことにただ驚いている。

この問題について私が書いた記事、"Top Five (Wrong) Reasons You don't Have Testers"を読んで欲しい。

11. プログラマを採用するときにコードを書かせるか?
マジシャンを雇うときに、なにか手品を見せてもらいたいと言わずに雇うかい?もちろんそんなことはしない。

自分の結婚式のためにケータリングを頼むのに、料理を試さずに頼むかい?そんなことはしないだろう。(あのマージおばさんを除いて、だ。彼女に彼女の「有名な」チョップ・レバー・ケーキを作らせなかったら一生恨まれるだろう)。

にもかかわらず、毎日プログラマ達は履歴書が印象的だったり、面接官がおしゃべりを楽しめたという理由で採用されている。そうでなければ、つまらない質問を受ける。(CreateDialog()とDialogBox()の違いは?などというものだ。)ドキュメントを見れば答えられるような質問だ。君はプログラマがプログラミングについて何千ものつまらないことを覚えていたからといって、そんなことは気に止めないだろう。君にとって問題なのはコードを書けるかどうかだ。または、もっと悪いことは、プログラマがいわゆる「AHA!」な質問をされていることで、この手の質問は、答えを知っていれば簡単だが、知らなければ答えることは不可能なのだ。

どうか、こんなことはやめて欲しい。面接の間君がやりたいことは何でもやるといい、しかし、求職者には「いくらかのコードを書かせる」ことだ。(更なるアドバイスを読みたい方は、"Guerrilla Guide to Interviewing"を読んで欲しい。)

12. 「廊下での使い勝手テスト」を行っているか?
「廊下での使い勝手テスト」とは、廊下を通る隣人を捕まえて、君が書いたばかりのコードを使ってみてもらうことだ。5人にやってもらえば、コードの中にある使い勝手の問題点を95%は知ることが出来るだろう。

優れたユーザインターフェースのデザインは、君が考えているほど難しいものではない。そして、君の製品を顧客に気に入って買ってもらいたかったら、これはきわめて重要なことだ。私のUIデザインに関するフリーのオンラインブックでプログラマ向けのUIデザインについての短い手引を読むことができる。

しかし、ユーザインターフェースについてもっとも大切なことは、手ごろな人数の人(実際のところ5人か6人で十分だ)に君のプログラムをみせることだ。そうすれば、人々がそのプログラムを使うのに難儀する一番大きな問題を、即座に見つけられるだろう。ヤコブ・ニコルセンがこのことを説明している記事を読んで欲しい。君のUIデザインの能力が今足りなかったとしても、廊下での使い勝手テストを続ける限り、無料で、君のUIは今よりずっとずっと良くなるだろう。

ジョエル・テストの4つの使い方

  1. 君のソフトウェア組織についてテストして私にランクを教えてくれれば、言いふらしてあげる
  2. 君がソフトウェア開発チームのマネージャならば、君のチームが出来る限りよい状態にあるかどうかを確認するチェックリストとして使える。12点になったら、君はプログラマ達に自由にやらせておき、営業担当者がプログラマを邪魔することを阻止することに集中できる。
  3. 君がプログラミングの仕事を受けようかどうか決めるところだったら、未来の雇用者にこのリストでその会社が何点かを聞いてみることだ。点が低すぎたら、君がそういったことを正す権限を持てることを確認することだ。それができなければ、君は不満が溜まり、生産的に仕事ができないだろう。
  4. 君が投資家で、プログラミングチームの価値について正しい判断を下す必要があるか、君のソフトウェア会社が他社と統合することを検討中ならば、このテストによってすぐに大雑把な判断ができるだろう。

 



この記事の原文(英語)は The Joel Test: 12 Steps to Better Code です。 

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


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

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky