vii.

かなり前の話ですが、著者は経験あるプログラマを対象に、（Javaなどの新しい技術を教える研修プログラムを受け持っていたことがあります。その時に驚いたのが、受講者間での「生産性」の差が非常に大きかったことでした。生産性の低い人と高い人の違いは歴然でした。効率の違いは、使っているツールによるものではありませんでした。コンピュータとの全般的な関わり方の違いが、その差を生んでいたのです。

p.4

物事の中に何か「パターン」を見つけ出せば、そしてそれに「名前」をつけることができれば、同様の物事の存在に気づきやすくなるのです。

p.43

「後」はいつになてもやって来ません。生産性の高いソフトウェア開発者になるためには、いかに目先の生産性を下げずに（皮肉な話ですが、実際、下がってしまいます）に、将来の生産性向上につながる活動をするか、そのバランスが重要になります。

p.81

私たちの試算では、同じ分割を手作業で行った場合、約10分を要すると考えられます。一方、自動化に要したのは約1時間です。最終的に、同じ作業をあと5回繰り返すことになったため、自動化に費やした時間の「元は取れた」ということになりますが、実はそれは大した問題ではないのです。単純な手作業の繰り返しは、人間から知力と集中力を奪ってしまいます。知力と集中力は、生産的活動にとって最も重要な資産ですから、それが奪われることは何より重大な損失なのです。

p.262

Ruby on Railsの作者であるDavid Heinemeier Hansson氏は、こんな風に言っています。—「高まった生産性を仕事を余計にこなすためではなく自分の将来に向けて使おう」。
（中略）
大事なポイントは1つ。生産性の高いプログラマは、生み出した時間を使って、自分の人生をより豊かにするための投資をすることができるのです。
（監訳者あとがき）

p.9

我々が潜在的に年間3百万ドルになるマーケットを検討しているとしよう。大きなベンダにとってはこのような小さなマーケットは追いかけることを検討すらできない。彼らの時間に値しないのだ。しかし年間3百万ドルの収入というのは、社員が15〜30人の小さな会社であれば十分支えることができる。このニッチにはチャンスがあり、誰かがそこに素敵な会社を作ることだろう。

p.10

それから、小さな会社は優れた製品によって顧客にサービスするという基本に集中しやすいということがある。ベンチャーキャピタルや4半期ごとの決算に対する期待といったことにより気を散らされることがない。よく見もしないで小さな会社を軽視したりしないことをお勧めする。

p.61

読書というのは自分の問題の答えを見つける場所ではない。そうではなく、読書は自分で答えを見つけるのに役立つバックグラウンドを身につけるための方法なのだ。

p.71

私が学んだことの1つは、小さなISVはプログラマを雇うべきではないということだ。
（中略）
“プログラマ”（コードを書くことに特化した人）ではなく、必要なのは”開発者”（製品の成功のためにたくさんの面で貢献する人）なのだ。

p.75

そのような広範なスキルセットを持った開発者は簡単には見つからないのでは？
そのとおり。本物の開発者というのは貴重なものだ。たぶん外から雇ってくることはできない。自分のところにいるプログラマたちが開発者へと変わっていけるように手助けしてやる必要がある。
ひとたび彼らが開発者へと変わったなら、彼らを会社に引き留めておくために多大な努力をする必要があるだろう。そうしなければ、彼らは大会社でマネージャになるか、あるいは自分の会社を立ち上げることだろう。

p.145

ジム・バークスデールの競合選択の考え方が私は好きだ。バークスデールというのはNetscapeのCEOだった人だ。彼は、一番良いアプローチは「大きくて無能な」競合を見つけることだと言っている。

p.13

よくギークとスーツとか言って対立軸をおもしろおかしく言う人がいるじゃないですか。それは大間違いで、ギークもスーツも一緒なんですよ。単にAさんとBさんで共通のコミュニケーションのボールをもっていないだけで、どっちも優れたギークで、優れたマネージャーであれば、そこにどうにかコミュニケーションの共通するものを発見しようとするわけですよ。どっちも理解不能であるとすれば、どっちもコミュニケーションができないという悲しい現実を言ってるだけで、私はギークもスーツも対立するものではなくて、一緒に違う仕事ができるパートナーだと思っています。
（ミラクル・リナックス吉岡弘隆氏）

p.9

私はアウトソーシングに関する本をみな読んでみたけれど、ソフトウェア開発というのはデザインであって製造ではないのだということを、基本的に誰も理解していないように見える。
（Joel）

p.11

ソフトウェア会社がオペレーションの効率と戦略とを混同するとき、アウトソーシングは失敗する。オペレーションの効率が良いというのは、作業コストがより安いか、あるいは作業がより速くできるということだ。一方戦略というのは、長期的な競争優位を作り出すことであり、ソフトウェア会社にとっての競争優位は、革命的なアプリケーションを作る能力である。
（マイケル・ビーン）

p.96

優れたデザイナを雇ってデザインさせれば、製品は美しいものになると思うかもしれない。しかしあなた自身が良い趣味を持ち合わせていないのだとしたら、どうやって優れたデザイナを見分けられるのだろう？
（中略）
美が何かを知らずに美しいものを作り出すためのプロセスを管理することはできないのだ。
（ポール・グレアム）

p.238

開発者の職の候補者を検討するときには、次に挙げる10個の質問を自分にしてみるといい。

1. この候補者はチームに他の誰も持っていないものをもたらすだろうか？
2. この候補者は学び続ける人だろうか？
3. この候補者は自分の弱さに気付いており、それについて気兼ねなく議論することができるだろうか？
4. この候補者は多才で、製品を成功させるために「必要なことは何でも」する用意があるだろうか？
5. この候補者はあの「10Xプログラマ」の1人だろうか？
6. この候補者は名門のコンピュータサイエンス学科を出ているか？
7. 博士号を持つ候補者であれば、その人が「パッケージソフト資質」をも併せ持つまれな人であることを示すものがあるか？
8. この候補者はパッケージソフトの開発チームでの経験を持っているか？
9. この候補者は良いコードを書くか？
10. この候補者は余暇にコードを書くくらい、プログラミングが好きか？

（エリック・シンク）

p.2

人生は、自分の仕事を憎むにはあまりに短いのだ。

p.29

これの意味するところは、残存バグがたくさんある場合には、スケジュールはあてにならないということだ。

p.205

これらのバグが見つかるには、いずれも、実世界で何週間も使われる必要があった。プログラマがラボでバグを再現して修正するには、2、3日かかったかもしれない。多くのバグ修正と同様ならば、修正したのは1行だけだったかもしれない。あるいは、2、3文字だけだったかもしれない。しかし、その2、3文字のために多くの時間と労力が支払われているのだ。
コードを捨ててスクラッチからやり直すとき、あなたはそういう知識のすべてを捨てている。それら、蓄積されたすべてのバグフィックスを。何年にもわたるプログラマの作業を。

p.206

スクラッチから始めるときに覚えておかなければならない重要な点は、あなたが最初にやったときよりもいい仕事ができるだろうと信ずべき理由はまったくないということだ。

p.226

もしあなたが開発チームを作っているなら、たくさんの経験の浅いプログラマたちに、抽象度の高いツールを使って大きなコードのブロックを作り出させていくのはOKだが、もし深い経験を積んだメンバがいて手強い問題を片付けるのでなければ、チームは上手く機能しないだろう。

p.229

ソフトウェアの世界というのはあまりに広く複雑で多面的であり、そのため、いつもは知的だと思える人が、ブログの中で「Microsoftはまともなオペレーティングシステムが作れない」みたいな愚かなことを書いているのは、率直に言ってバカにしか見えない。
（中略）
私はMicrosoftを擁護しているのではない。ただ、深い無知に基づいてお手軽に一般化された議論をするというのが、今日、ネット上でなされる最大の時間の浪費だと言っているだけだ。

p.240

私の意見は？と聞かれたら、そして私は偏っているわけだが、トップに立っているのがプログラマでない限りソフトウェア会社が成功することはないと思う。

p.266

もっと重要なことは、最高の人間を雇うことへの執着だ…十分優秀な人間が見つけられないなら、小さいままで十分満足だ（1年につき6週間の休暇を用意すれば、人を見つけるのはそれほど難しくはない。）そして私たちは、すでに雇っている人々が成長し、新しく入ってきた人たちの教育や指導ができるようになるまでは、会社を大きくしようとは思わない。

p.276

それがビジネスで核となる機能ならー何が何でも自分でやることだ。

p.39

プロジェクトのあり方をよりよくするためには、組織が積極的な役割を果たすことが欠かせないはずだ。これはつまり、提供するサービスの品質を組織としてどう考えるかという問題に他ならない。

p.140

筋の通ったITを整備しなくてはならない企業や組織は、実は従来型の産業の中に多いのではないのかという疑問がある。さらに、IT系として世間でもてはやされている企業にとって、それほどITが重要なのだろうかという疑問もある。

p.144

IT業界の寵児と呼ばれた急成長企業は、実は金融業と呼ぶべき仕事をしている。技術屋のはずのソフトウェア開発企業も、実は人材斡旋業にシフトしている。だとすると、日本にIT企業はいなくなっているのだろうか。
（中略）
現在の日本において真にIT企業と呼ぶべき企業とは、クリティカルな業務にITが切り離せなくなっている諸業種なのではないか。つまり、ダメITが、社会に多大な迷惑を及ぼしてしまうかもしれない業種・業態だ。

タイトルに「いつまでもダメな理由」とありますが、もちろん今後も「ダメ」でいいわけはありません。
他の産業でも同じかもしれませんが、大雑把に
・自分たちが提供している物（情報システム）やサービスに価値があるか
・それをきちんとビジネスにしているか
がますます問われていくことは間違いないと思います。

p.17

DHH「世界はもっとたくさんのソフトウェアが必要なわけではない、もっと少ないんです。」

DHHさんについては、4/19に行われたスタートアップスクールという講演内容など、共感できるところが多いです。（日本語での解説はこちらなどどうぞ。）

「必要なものはもっと少ない」のであれば、不必要なのに存在しているものはいったい何なのか。それは誰かの都合で存在しているものかもしれません。
自分の都合ではなく、自分の価値観からものを作っていきたい。そんな気がします。

p.3

アジャイル開発では、チームのメンバー（およびチームと共に作業するメンバー）全員が、プロジェクトで明確な結果を出すことを目指すプロフェッショナルであることを前提としている。

p.11

用意している役割はただひとつ、ソフトウェア開発者だけだ。

p.113

コードは、書くことよりも読まれることのほうがずっと多い。

p.196

アジャイル開発者たちが、アジャイルにチームで開発するからアジャイル開発