Japanese

From The Joel on Software Translation Project

[edit] 記憶に残るようなカスタマサービスへの7ステップ

2007年2月19日

2006年12月15日
人々がソフトウェアをいじるのは、多くの場合、それで遊びたくてそうしているわけではない。彼らがソフトウェアを使うのはツールとしてであり、それで彼らがやりたいと思う別なことを実現するのだ。彼らがチャットプログラムを使うのは、それでウィットがあるところを見せて、チャットの相手に一緒に時を過ごしたいと思わせ、そうして最終的には抱くことが出来るチャンスを高め、そうして利己的な遺伝子が自己複製できるようにするためなのかもしれない。

[edit] シンプルさ

2006年12月9日
機能が20%だけのシンプルな製品を作るというのは会社を立ち上げるときには優れた戦略で、それは限られたリソースしかないチームでも何か作り上げてユーザを手に入れることができるからだ。しかしそれが長期的にも良い戦略になるとは思わない。次世代の2人のスタートアップがそのシンプルなアプリケーションをクローンして参入するのを妨げるものはあまりないからだ。それに結局のところ人間の本性には抗えないということもある。

[edit] レゴプログラミング

2006年12月5日

[edit] スパムの操作

2006年11月30日

[edit] 選択肢 = 頭痛

2006年11月21日
コンピュータを使い終わったとき、あなたは毎回9つの選択肢の中からどれか選ぶ必要がある。数えてみて、選択肢が9つあるんだ。アイコンが2つと、メニューアイテムが7つだ。2つのアイコンは、おそらくメニューアイテムのどれかのショートカットだろう。私の想像では錠前のアイコンはメニューにあるロックと同じものだと思うが、しかし電源スイッチのアイコンの方はメニューの中のどれにあたるのかよくわからない。

[edit] アジャイル(?)なチームの話

2006年11月15日

[edit] 限りない音楽コレクション

2006年11月9日
12歳のとき私は毎週日曜の朝にKQEO放送でケイシー・ケーサムを聞き、新しい曲やリリース予定の曲をみんな書き出していた。それから毎週の5ドルのお小遣いをもらうと、まっすぐレコードショップに行って45回転レコードを買った。1枚1ドルだった。そのうち私のコレクションはかなりのものになり、全部でたぶん100枚くらいあったと思う。今では母にお願いだから捨ててくれと言われている。

[edit] ああ、こんなメールをよくもらう･･･

2006年11月9日

[edit] SQLインジェクションとは何か?

2006年11月1日

[edit] 採用面接ゲリラガイド(version 3.0)

2006年10月25日
「無政府主義者とフリーラブの提唱者とバナナの権利の擁護者の寄せ集めの一団が、プエルト・バリャルタを出たラブボート号をハイジャックし、7日以内に要求が受け入れられなければ616人の乗客と327人の乗員もろとも、船を沈めると脅している。要求は何か? 番号を控えていない小額紙幣で100万ドルと、評価の高いWaterloo Fortran IVコンパイラ、WATFIVのGPL実装だ。(フリーラブの連中がバナナの権利の連中と合意できることがいかに少ないかは驚くばかりだ。)」

2000年に公開されたオリジナルバージョンの「採用面接ゲリラガイド」は、Fog Creekで使うための採用ガイドだった。書籍版のJoel on Softwareには、そのメジャーリビジョンであるversion 2.0を載せた。ここにあるversion 3.0は、この数年の業界の変化を反映させ、それに私が面接について学んできたことも組み入れて大きく書き直したものだ。

[edit] 電話でのふるい分け

2006年10月24日
私たちは通常、本格的な実地の面接に移る前に電話でのふるい分けをしており、お話にならないくらい頭の良くない人のために時間と金を無駄にさせられることがないようにしている。

[edit] 書評：Beyond Java

2006年10月12日

[edit] Джоэл о программировании – たったの250ルーブル!

2006年10月11日

[edit] 新機能: 求人情報検索

2006年10月9日

[edit] SprintからすごいX線眼鏡が出たよ!

2006年9月19日

[edit] 再びRubyのパフォーマンスについて

2006年9月12日

[edit] 履歴書の順序づけ

2006年9月8日
最高のプログラマにとってリクルーターの頭にくるところは、彼らがキーワードやバズワードに病的に執着していることだ。プロのヘッドハンターやリクルーターの業界では、候補者を職にマッチングする単純なアルゴリズムが使われており、採用側の会社が現在たまたま求めているものに合った技術略語のリストを持つ候補者を探すのだ。それが余計腹立たしく感じられるのは、そういったリクルーターのほとんどは、それらの技術が何を意味するのかまったく知らないということだ。「ああ、MSMQの経験はないの? じゃ、しょうがないね」。不動産屋であれば、サブゼロ冷蔵庫やバイキングストーブについておしゃべりしていれば、少なくともそれが何なのかは知っている(最近ではステンレス製の冷蔵庫はみんな「サブゼロ」とみなされているようだが)。技術分野のリクルーターは、5年のRuby on Railsの経験を求めたり、「Windows API」の仕事から履歴書に「Win32」としか書いていない人を落としたりするときにぼろを出す。

——「採用ゲリラガイド」の最終回となる第3回は、「履歴書の順序づけ」について。

[edit] 開発者観察ガイド

2006年9月7日
私の経験からすると、たくさんの言い訳が積み重なって、よほど進んだ会社でもない限り、開発者に個室を与えることは実質的に不可能になる。そして進んだ会社においてさえ、どこに移転し、どこでみんな働くのかという決定は10年ごとにしか行われず、その決定はオフィスマネージャの秘書と大きな建築会社の下級アソシエートからなる委員会によってなされるのだが、彼らはオープンスペースは会社のオープンさを示すという建築学部で習ったおとぎ話を信じており、開発者や開発チームの意見が聞かれることはない。

——「採用ゲリラガイド」の第2回は、「開発者観察ガイド」だ。

[edit] 優れた開発者を見つけるには

2006年9月6日
新しい求人掲示板ができたのを記念して、アーティクルシリーズ「採用ゲリラガイド」に取り組んでいるところだ。

第1回として「優れた開発者を見つけるには」を公開しよう。

[edit] jobs.joelonsoftware.comについて

2006年9月5日
ニッチ向けの求人掲示板というアイデアは私のものではない。何百万の企業と何百万の求職者を集めているあの巨大な求人掲示板より、ニッチ向けの掲示板の方がいいアイデアであるのがなぜか分るのにはしばらく時間がかかった。ニッチ向けの求人掲示板の目標は控え目なものであり、1ダースほどの優れたプログラマたちが一緒に働く素晴らしい場所であるような会社が、何ダースか集められればそれでいい。

[edit] Wasabi

2006年9月1日

[edit] 言語をめぐる論争

2006年9月1日

[edit] お気に入りのFirefoxエクステンション3つ

2006年8月25日

[edit] マネジメント法3種

2006年8月7日
イントロダクション
 指揮統制マネジメント法
 入門経済学マネジメント法
 一体化マネジメント法

(ジョエルは休暇中。このエピソードは前もって書かれたものだ。)

[edit] 君のプログラミング言語で、これ、できる?

2006年8月1日
あなたのプログラミング言語がファンクターの使用を強要しているのなら、あなたは現代的プログラミング環境の利点を十分享受していないことになる。お金の払い戻しが受けられないか確認してみるといい。

[edit] はじめてのBillGレビューのこと

2006年6月16日
当時は、BillGレビューと呼ばれるものが時々行われていた。基本的には、大きく重要な機能はすべてビル・ゲイツのレビューを受けることになっていたのだ。私は書いた仕様書をレビュー用に彼のオフィスに送るように言われた。500枚のレーザープリンタのプリントアウトだ。

[edit] FogBugz 4½と主観的幸福感

2006年5月16日
今日リリースするのは、本当のところFogBugz 4½とでも言うべきものなのだが、これを5.0と呼ぶことにした。分数がなくとも人生は十分込み入ったものだからだ。

[edit] 開発抽象化レイヤ

2006年4月11日
若い男が町にやってきた。彼は見かけも悪くないし、ちょっとは金も持っていた。

過去のことについてはあまり話したがらないが、血の通ってない大企業に長くいたらしいことは明らかだった。

彼は生まれつき人当たりが良く社交的で、自分に自信を持っていながら傲慢ではない。だから地元のプログラマーズ・カフェにある求職の掲示の中からちょっとした仕事を見つけるのは、彼には簡単なことだった。しかし保険データベースプロジェクトや、主婦向けの飾りだらけのWebページや、会計計算エンジンといったものには、やがて興味をなくしてしまった。

[edit] 「Eric Sink on the Business of Software」への序文

2006年4月7日
私が最初に手がけたビジネスについて話したことがあったろうか?

どうにか思い出せるかやってみることにしよう。それは14歳の時だったと思う。ニューメキシコ大学では、TESOLサマーインスティテュートとかいうのをやっていて、私はそこでカウンターの奥に座って、論文誌の記事が必要な人にコピーしてあげる仕事をしていた。

カウンターの横に大きなコーヒーメーカーがあって、ほしい人はカップに25セントを入れれば飲めるようになっていた。私自身はコーヒーは飲まなかったけど、ドーナッツが好きだったので、コーヒーと一緒にドーナッツがあれば素敵だろうなと思った。

[edit] ユーザビリティへの第一歩(初稿)

2006年3月7日
航空機制御システムであれば、ユーザビリティのまずさが「地表への制御下の航行」という楽しげな呼び方をされる状態に到る可能性がある。

あなたのプログラムのユーザビリティの問題がそこまでクリティカルな結果に到ることはないかもしれない。運が良ければ、あなたのデザインのユーザビリティがまずくとも誰かが手足を失うか親指をなくすくらいで済むだろう。大したことないじゃん!

(このアーティクルが「プログラマのためのユーザインタフェースデザイン」の冒頭部分を書き直したものであることに気付いたかもしれない。実際私はこの本の大部分を改訂している最中で、あなたが今目にしているのはその原稿だ。)

[edit] すばらしいデザイン: 目次

2006年1月30日

[edit] すばらしいデザイン: 何によってすばらしいものとなるのか? (初稿)

2006年1月30日
どんな製品カテゴリにも、一流の金張りの星のような製品がある。映画スターならブラット・ピット。ロックソングなら、もちろんスイートホーム・アラバマだ。オフィスチェアならハーマン・ミラー・アーロン。MP3プレーヤーなら、間違いなくiPodだ。
これらの製品に共通しているものはなんだろう?

[edit] すばらしいデザイン: デザインとは何か? (初稿)

2006年1月26日
ニューヨークにある、あの見事な褐色砂岩の建物をご存知だろうか? 精巧な彫刻やガーゴイルや美しい鉄のフェンスのある建物だ。古い設計図を探し出せば、昔の建築家がしばしば単に「美しい雷紋模様」としか書いてないのがわかるだろう。熟練の大工が美しい何かを作ってくれるのを当てにして、そのイタリアからやって来た老職人に任せておくのだ。
そういうのはデザインではなく、デコレーション(装飾)だ。

[edit] すばらしいデザインイントロダクション(初稿)

2006年1月25日
私が携帯電話の電源を切るのが怖いのは、それを再びつけるために必要な脳細胞を招集することが、必ずしもできないからだ。
携帯電話には2つのボタンがある。楽しげな緑のボタンと、何か怖い感じの赤いボタンだ。ボタンには変なアイコンが描かれているが、何を意味しているのかはわからない。
緑のボタンで電源が入ると思うでしょ? 緑は進めという意味だものね。
でも違うんだ。

[edit] Micro-ISV: ビジョンから現実へ

2006年1月11日
解くのはどんな問題で、それは誰のためであり、その製品によって問題が解決できるのはなぜで、そして顧客はその解決に対してどのような仕方で支払うのか説明できないのなら、会社を始めないこと。以前私は6社のハイテク新興企業のプレゼンテーションを聞きに行ったことがあるが、そのうちのどれ1つとして、どんな問題を解決しようとしているのかについて明快なアイデアを持っているものはなかった。

これはボブ・ウォルシュの新刊「Micro-ISV: ビジョンから現実へ」に寄せた私の序文だ。

[edit] Javaスクールの危険

2005年12月29日
「近頃の若い者」は我慢がないと不平を言うようになったのは、私も年を取ったということなのだろう。

[edit] 読書リスト: Fog Creek Softwareマネジメントトレーニングプログラム

2005年11月22日

[edit] Fog Creek Softwareマネジメントトレーニングプログラム

2005年10月26日
これまでは、私たちが採用するのはほとんどがプログラマだった。それは始めだったからだが、しかし次世代のマネージャを採用しはじめる必要もある。それだから今日、Fog Creek Softwareマネジメントトレーニングプログラムを立ち上げることにした。これはソフトウェア業界について私たちの知っているあらゆることを教えるべくデザインされた集中的な3年間のプログラムだ。

[edit] 優先順位を決める

2005年10月12日

[edit] (Forum) 私はなぜフレームワークが嫌いか

2005年9月30日

[edit] プロジェクトAardvark仕様書

2005年8月17日
どちら側からでもプロセスを開始できるようにするために必要となる画面について検討していたとき、プロセスは救助者が開始する必要があるというようにすれば、劇的にシンプルになり、しかもAardvarkの有用性は変わらないことに気付いた。仕様書の上でその変更をするには1時間か2時間しかかからなかった。この変更をコード上でやっていたとしたら、スケジュールが何週間も延びていたことだろう。エクストリームプログラミングの支持者たちの嫌っている、前もって大きなデザインをすること(Big Design Up Front)の有効性を、私は口で言い表せないくらい強く信じている。私はBDUFによっていつも時間を節約でき、よりよい製品を作ることができた。XP の狂信者たちがどう言おうと、私はBDUFを採用していることを誇りに思っている。この点に関してXP狂信者たちは単に誤っており、そのことは私にとってまったく明らかなことなのだ。

[edit] Moraeを使ったユーザビリティテスト

2005年7月30日

[edit] ソフトウェアにおける高音域

2005年7月25日
「最高のプログラマ」を雇うということにそもそも意味があるのだろうか? 最高のプログラマを求めることが重要な意味を持つほど、プログラマの能力の違いは大きいものなのだろうか?

この疑問に対する答えは私たち開発者には明らかなことかもしれないが、しかしその他の人々には、依然証明を必要とすることなのだ。

[edit] プロジェクトAardvark中間レポート

2005年7月7日
これはあなたがあきらめて、自分では10秒で直せることが2時間の悪夢となることを思い知る瞬間だ。その間は家族とも離れ、眠れなくなり、電話回線を塞いでいるためにガス欠で立ち往生しているマージおばさんはおじさんに助けに来てもらうことができず、あなたのことをずっと恨み続けることになるのだ。あなたがプログラマだというだけで、友達や親戚やアパートの隣人たちといった1ダースもの人たちのヘルプデスクをしなきゃならない理由はない。そうだよね?

[edit] 「Best Software Writing I」への序文

2005年6月20日
「ソフトウェア開発の世界は、良い読み物を必要としている。著者が16人いる、外国語学習者の変な英語で書かれたクラスライブラリに関する2000ページの本をまた読まなければならないとしたら、私は頭がおかしくなってしまう。似非学術的に気取って書かれたハードカバーのオブジェクト指向モデリングの本は、もうFog Creekの図書室に入れるつもりはない。ゴミ箱に直行だ。熱心な9歳児やスラッシュドットのトレッキーが書いた、Microsoftのバグだらけのコードに対する元気のいい攻撃文をもしまた読まなきゃならないんだったら、私はとがった鉛筆で目玉を突っつきたくなるかもしれない。やめてくれ、お願いだからやめてくれ!」

これは、今発売中の本「The Best Software Writing I: Selected and Introduced by Joel Spolsky」のために書いた序文の一部だ。この本には、ソフトウェアに関する、見事で洞察に富み、ときにひどく可笑しな29の短編が収められている。序文をここで読むことができる。

[edit] ブックレビュー

2005年5月20日
インターンたちに渡した本の山に何が入っていたのか教えてくれという人がたくさんいた。あの本の山はプロジェクトAardvark向けに最適化したものだったので、たとえばOpenSSLについての本だとか、ニューヨークの余暇ガイドなんかも入っていた。一方私はすべてのプログラマに薦める本の標準的なリストも持っていて、これは2002年以来アップデートしてなかったのだけど、どう思う? これらの本は本当に不朽の作品なのだ。たぶん私はあと何年かこのリストをいじることはないと思う。

[edit] 間違ったコードは間違って見えるようにする

2005年5月11日
この時期に典型的なことは「水ぶくれのフジツボみたいだ。一貫したコーディング規則がなきゃだめだ」みたいなことを言って、次の日をチームのためのコーディング規則を書くために使い、そのあと6日間で「唯一正しい括弧付けのスタイル」について議論し、そのあとの3週間を古いコードが「唯一正しい括弧付けのスタイル」に合うよう書き直すのに費やすが、それに気付いたマネージャから全然お金にならないことに時間を使っていることで怒鳴りつけられ、それでソースに手を入れる必要が出た時ついでにフォーマットを直すのでも別に悪くないと思い直し、半分だけ「正しい括弧付けスタイル」という状態になってしまうが、そんなことはすぐに忘れ、そしてすぐまた別な何か、1つの文字列クラスを別な文字列クラスで置き換えるというような、お金になることとは無関係なことに心を奪われるのだ。

[edit] FogBugz 4.0への道

2005年3月28日
今週は、FogBugz 4.0の開発の舞台裏を5回に分けて紹介しよう。毎朝、新しい回を投稿するつもりだ。

今日は「FogBugz 4.0への道: パート1」として、顧客のフィードバックに耳を傾けて追加した2つの大きな機能と、私たちが「顧客に耳を傾け、競合は無視しよう」というのをマントラにしている理由について話そう。
Fog Creekでは会社に来るメールの処理にFogBugzを使っており、このFogBugzを自分で使う(「自分のドッグフードを食べる」)経験が、ベイジアンスパムフィルタと、良く使うフレーズや良くある質問への回答をまるまる入力できるようにする「スニペット」機能を開発する動機となった。「FogBugz 4.0への道」の今日の回では、ドッグフーディングから生まれた2つの新機能について見ることにしよう。
FogBugzをWindows同様Unixでも動かせるようにするために、PHPバージョンが必要だった。一回きりの移植をする代わりに、私たちはASPのソースからPHP版を自動生成するコンパイラを構築することにした。その顛末についてFogBugz 4.0への道パート3で読める。
パート4: Fog Creekのチームで費やされる100カロリーに対し、顧客の元へと届けられる新しいコード行を実際に書くのに使われるのは、ほんの2カロリーに過ぎない。
今日は「FogBugzへの道」の衝撃の結末について。

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

2005年2月11日

[edit] コンピュータサイエンスの学生へのアドバイス

2005年1月2日
大学生の多くは、幸いなことに、生意気なものであり、あまり年長者にアドバイスを求めたりはしないが、コンピュータサイエンスの分野においてはこれは良いことなのだ。年長者というのは「2010年にはキーパンチャーの需要が1億人を越える」とか「Lispを使う仕事が最近すごくホットだ」みたいな間抜けで時代遅れなことを言うものだからだ。私自身も、学生にアドバイスするとき何について話したらいいのかわからない。しかしそんなことで書くのを思いとどまったことはない。

[edit] ラクダとおもちゃのアヒル

2004年12月15日
価格を設定するとき、あなたはシグナルを送っているのだ。競合ソフトウェアの価格が100ドルから500ドルの範囲にあり、あなたが自分は中間を行きたいと思って自分のソフトを300ドルで売ることにしたら、顧客にどんなメッセージを送ることになると思う? あなたは彼らに、自分のソフトは大したものじゃない、と言っているのだ。もっといいアイデアがある。1350ドルにするのだ。そうすると顧客は「あれはとびきり上等に違いない。連中はあんなに高い値を付けてるんだから!」と考えるのだ。

[edit] ユーザビリティがすべてではない

2004年9月6日
ユーザビリティが「発明」された1980年代のソフトウェアでは、コンピュータと人の間のやり取りがすべてだった。現在でも多くのソフトウェアはそうだ。しかしインターネットは新種のソフトウェアをもたらした。人と人の間のやり取りにかかわるソフトウェアだ。人の間の仲介をするソフトウェアを書くときには、ユーザビリティをちゃんとさせた後、ソーシャルインタフェースをちゃんとさせる必要がある。そしてソーシャルインタフェースの方がより重要なのだ。世界最高のUIがあったとしても、まずいソーシャルインタフェースを持ったソフトウェアを救うことはできない。

[edit] Joel on Software書籍版の目次

2004年8月19日

[edit] マイク・ガンダロイのCoder to Developer

2004年5月5日

[edit] 履歴書を読んでもらうには

2004年1月26日

[edit] ストラテジーレターV

2002年6月12日
ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。

[edit] 5つの世界

2002年5月6日
5つの世界：すべてのソフトウェア開発が同じではない。
追記：インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばしば切れ目なくつながっている。得てしてシステムは最初インターナルシステムとして開発され、それからビジネスの連中がそれを他の会社に売るうまい方法を考えるが、それがあまりに脆弱で実行される環境について多くの仮定をしているため、別な顧客のサイトにインストールするには数週間を要し、そこにコンサルウェアが生まれる。(VignetteのStoryServerはc|netのインハウスコンテンツマネジメントシステムとして始まったが、今では走らせるのに何百万ドルもかかる。) 理論上は、ソフトウェアはカスタマベースが拡大するにつれてインストールの容易さが強調され、パッケージソフトに移行するのだが、コンサルティング収入に味をしめたこれらの会社は、オフ・ザ・シェルフで使えるように使いやすくするメリットはないと考える。そして多くのインターナルシステム開発者は野生状態で動かせるソフトウェアというのを作ったことがなく、実際それは動かない。

[edit] 私たちの.NET戦略について

2002年4月11日
Fog Creek Softwareの2002年4月時点における今後の.NET移行計画

[edit] 氷山の秘密、明らかに

2002年2月13日
「うちの開発チームのどこが悪いのか分からない。」とCEOは心の中で思う。「プロジェクトを始めたころには何もかもうまく行っていたんだ。最初の2週間チームは馬車馬のように働き、ちゃんと動くプロトを作った。しかしその後は進み具合が這うように遅くなった。単に連中が怠けてるだけということかもしれん。」彼はキャラウェイ製のチタンドライバを選び、キャディに冷たいレモネードを取りに行かせる。「2、3人首を切れば、連中の尻にも火が付くだろう!

[edit] Rub a dub dub

2002年1月23日
我々がコードベースをゼロから書き換えたいと思う理由のひとつに、オリジナルのコードベースが本来の目的用にデザインされていないということがあげられます。それはプロトタイプや、実験用、演習用、またはわずか９カ月ほどでゼロから書かれ公に出されてしまったもの、あるいは一回限りのデモ用として設計されたものだったりする訳です。

[edit] 射撃しつつ前進

2002年1月6日
私の一日の多くはこんな感じだ: (1) 仕事にとりかかる。(2) emailをチェックしたり、Webを見たり、そのほかのことをする。(3) 仕事に取りかかる前にランチを取ったほうがいいと判断する。(4) ランチから戻る。(5) emailをチェックしたり、Webを見たり、そのほかのことをする。(6) いい加減はじめたほうがいいと心を決める。(7) emailをチェックしたり、Webを見たり、そのほかのことをする。(8) 本当に始めなきゃいけないと、再び決心する。(9) くそエディタを立ち上げる。(10) ノンストップでコードを書いていると、いつのまにか午後7:30になっている。
ステップ8とステップ9の間のどこかにバグがあるようだ。私は必ずしもこの溝を飛び越えられないからだ。

[edit] 下っ端でも何かを成し遂げる方法

2001年12月25日
このサイトではソフトウェアマネジメントを扱っている。しかしあなたは経営命令で組織を変える力を持ってないかもしれない。あなたが階級組織の最下層にいる下っ端のプログラマなら、人々にスケジュールやバグデータベースを作るように命令することができないのは明らかだ。そしてあなたがマネージャであったとしても、開発者を管理するのは牧猫するようなもので、違いはそんなに楽しくないことだとわかるだろう。「こうしろ」と言うだけではそうはならないのだ。

[edit] いいソフトウェアには10年はかかる。それに慣れることだ。

2001年7月21日
問題が出てくるのはあなたが新しい機能を何も思いつかなくなったときで、そうするとあなたはペーパークリップをつけ加え、それからそれを取り外し、しかもそのどちらの場合にもお金を取ろうとするのだけど、彼らはそれに引っかからない。いいソフトウェアには10年はかかる。それに慣れることだ。

[edit] ストラテジーレターIV: ブロートウェアと80/20の神話

2001年3月23日
ブロートウェアには大きな理由がたくさんあるのだ。1つには、プログラマがコードの大きさを気にしなくて良いなら、彼らはより早く出荷できる。そしてそれはより多くの機能を意味し、機能はあなたの人生をより良くし(あなたがそれを使うとき)、そして通常それは何も傷つけない(あなたがそれを使わないとき)。

[edit] ケンブリッジの春

2001年3月19日
arsDigitaがした非常に正しいことが1つあり、それは個人の声に関することだ。Fog Creekにとって私がもっとも重要だと思っているのは、この個人の声をどうやって維持するかということで、私たちにそれができたなら、私はフィリップ・グリーンスパンに大きく負っていることになる。

[edit] デイリービルドは君の友達

2001年1月27日
デイリービルドは自動化された、毎日行われる、完全なソースツリー全体のビルドのことだ。

[edit] ビッグマック対裸のシェフ

2001年1月18日
一連のルールに正確に従っているだけで料理については何も知らないマクドナルドのコックと、キュートなイギリス人の裸のシェフ、ジェイミー・オリバーのような天才を比べてみよう。(もし今このサイトを去ってリンクをたどり、裸のシェフがバジル・アイヨリを作っているMTVみたいなビデオを見ようと思っているならどうぞ、ご自由に。)

[edit] やさしいバグトラッキング

2000年11月8日
もしあなたがチームであれ単独であれコードを開発しており、コードの中の既知のバグをすべてリストアップした組織化されたデータベースを持っていないのなら、単に低品質のコードを出荷することになるだろう。

[edit] やさしい機能仕様

2000年10月2日
パート1: なぜわざわざ書く必要があるのか?
パート2: 仕様書とはどんなものか?
パート3: だけど･･･どうやって書くの?
パート4: ヒント

[edit] ジョエル・テスト

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

[edit] ストラテジーレターⅢ: もとに戻してくれ!

2000年6月3日
人々があなたの製品に乗り換える抵抗をなくす一番いい方法は、簡単に元に戻れるようにすることだ。誰も将来の自由を抹殺するような製品に乗り換えたいとは思わない。

[edit] ストラテジーレターⅡ: 鶏と卵の問題

2000年5月24日
あなたのビジネスがプラットフォームを作ることであるなら、一般には鶏と卵の問題として知られているものによって苦しめられることになるだろう。その上で走る良いソフトウェアができるまでは誰もあなたのプラットフォームを買おうとはしない、そしてそれが大きなインストールベースを持つようになるまでは、誰もそのためのソフトウェアを書こうとはしない。ウープス。

[edit] ストラテジーレターⅠ: ベン&ジェリー対アマゾン

2000年5月12日
会社を作っている？あなたがしなければならない非常に重要な決断がひとつあって、それはあなたのする他のすべてのことに影響する。あなたがどんなことをするにせよ、あなたは自分がどちらのキャンプに属しているのかを知り、あらゆることをそれに合わせて行う必要があり、そうしなければ災難に見舞われるだろう。

[edit] ゲリラ的雇用面接のすすめ

2000年3月23日
Fog Creek Softwareでは適切にスタッフを採用する事が必須である。我々の業界では対象となる人々を３つのタイプに分類する事が出来る。一方には未洗のイモとでも呼ぶべき、この業種に従事するのに基本的なスキルさえも持ち合わせていない集団がいる。これらの人たちは履歴書を注意深く確認して２，３の簡単な質問をする事で比較的容易に除外する事が出来る。対極にはスーパースターと呼ばれる、パーム上で動くLispコンパイラを週末の暇つぶしにアセンブリ言語で書いてしまうような人たちがいる。これらの中間にあたるのが大多数の「応募者」で、何かしらやってくれるのではないかと思わせる人たちである。ここで紹介する幾つかのトリックはこれら一般的な応募者とスーパースターとの違いを見極めるためのものであり、Fog Creek Softwareはスーパースター以外は採用しない。

[edit] 二つの話

2000年3月19日
Microsoftでは、もしあなたがExcelマクロストラテジーの仕事をしているプログラムマネージャであるなら、たとえあなたが会社に来て6ヵ月に満たなかったとしても、そんなことは問題ではない。あなたはExcelマクロストラテジーの神であり、誰であれ、たとえナンバー6だろうと、あなたの邪魔をすることはできない— 以上

[edit] さらにサバティカルについて･･･

2000年3月18日
私は自腹でサバティカルを1995年に取り、それから2000年にもう一度取った。私はそれが良かったと思っている。

[edit] プログラマのためのユーザインタフェースデザイン

第1章環境をコントロールできれば楽しく感じるもの
 第2章ユーザが何を期待しているかを知る
 第3章選択
 第4章アフォーダンスとメタファー
 第5章一貫性とそのほかのゴブリンについて
 第6章もっとほかにやることがある人々のためにデザインする
 第7章もっとほかにやることがある人々のためにデザインする、パート2
第8章もっとほかにやることがある人々のためにデザインする、パート3
第9章製品デザインプロセス

[edit] Joel Spolskyについて

Retrieved from "http://local.joelonsoftware.com/mediawiki/index.php/Japanese"