Joel テストを満点にしよう！　と思うのは、ある意味、「いいことは全部極限までやってみよう」という XP と通ずると感じました。 Joel さんは書いているほど XP を遠ざけていないと思うし、ましてや全否定は絶対してないと感じました。学ぶべき事の多い本でした。 kdmsnr さん、レビュアーだったのでつね。

納得できるプラクティス満載。特にマーケティングや、利益に言及しているあたりは、さずがにCEOである。ソフトウエアをベーススキルとするマネージャーには必読だと思う。ただし、XPに対する誤解（XPが必要ないといっている仕様とは、詳細（動作）仕様であり、Joelが必要であるといっている仕様は要求仕様である）はいただけない。要求仕様の無いソフトとはただのくずであり（仕様書があるかどうかは別のトッピック）、ベックがこのような誤りをしているわけ無いのだが。

【開発者マネジメント論＋IT業界での戦略論】 開発者のマネジメントの方法を学べると思って購入したのだが、蓋をあけてみれば、おまけとしてIT業界での戦略論がくっついていた（双方に関係性はまるで無いので、たぶん興奮して書いちゃったのかな？）。 『ジョエル・テスト』と呼ばれる12の質問に答えることで、自社の開発体制がどれだけ適正になっているかを判断できる。12の質問の詳細は、各章で説明されているため、具体的にどういうことを言っているのか理解できる。 スタートアップでは当然となった『MVP』の話などがこの本で登場している。きっと当時のIT業界では当然だったのだろうが、まだ2000年当時（本書が執筆された年）はITでのスタートアップが多くなかったことから、あまり知られていなかったのだろう。 翻訳の質はあまり高くないけど、楽しく読める一冊。

レビュー書いた http://kimikimi714.hatenablog.com/entry/2015/12/11/210000

一章が神。なぜ、誰も読まない機能仕様書ができるのか。それは退屈でつまらないからだ。それなら、シナリオを必要以上に具体的に書けば面白くなるし、仮想のユーザーが見えるようになる。よく見る仕様書は正確さを追求しすぎて、そもそものところが分かりにくい仕様書になっているのではないか。

筋が通っていて面白い。ソフトウェアに関する文字コード、採用、戦略など著者の経験から幅広く書かれていて面白い。気づきをあたえてくれる。 ささっと読めるが、すすすっと抜けてしまう。

仕様書のあり方やスケジュールマネジメント、評価など、多くのソフトウェアにまつわる示唆に富んだ内容だった。 この一つ一つのエピソードを覚えることは困難だが、知恵として役立つことは間違いないな、と思う。

まず最初にこの本は押し付けられた本だったので無理矢理読み流したといった方が正しい。 彼は2000年代のデスクトップアプリケーションエンジニアだということが解り、自分はwebアプリケーションエンジニアなのですべての考えや経験が当てはまる訳ではない。 仕様を決める人とエンジニアの間に壁はないし、デバッガーなんていない。１年もかかるプロジェクトや20人も30人も関わっているプロジェクトなんて経験したことがない。 しかし、射撃しつつ前進のような記事を読むと勇気ややる気をもらえる。 ブログの記事を修正したものを載せてるようなのでとりとめもない、様々なことが書かれている。そのときの興味があっていればカッチリはまるんだろう。 彼は仕様書を書くのを推奨しているらしいが、この本を進めてきた彼は仕様書を書かない人だし、共通点はあまりないような気もする。この本のなにを読んでほしかったのだろうか？

尊敬する同期I君の紹介。 元Microsoft社員で、Stack Overflow（http://stackoverflow.com/）というWebサイトを構築した人が著者らしい。 基本はソフト開発のマネジメントについて書かれた本だけど、開発者も耳が痛いことがたくさん書かれている。 この作者は他にもたくさん著作があるようなので、是非他の本も読んでみたい。

同じ大学のOBの方にIT業界についてのお話を伺った際に、頂いた本です。 「ざっと読んでみて下さい」と言われ、このことを意識して読み始めたのですが、読了までにかなり時間がかかってしまいました。原因としては何といっても、「ソフトウェアに関する知識を持っていなかった」ことにあります。 が、何とか一応最後まで読み通すことができてよかったです。この本から得たことは ・ソフトウェアに関する事情、問題に触れることによる”雰囲気”の認識 ・(ITに限らず)仕事をする上でのコツ の2つだと思います。 それから2点目について例を挙げると ・射撃しつつ前進 ・文章を読ませるための仕掛け ・儲けるためには？:補完財のコモディティ化 があります。気になった方は、本書を手にとってパラパラしてみることをオススメします！ しかし、今の自分はこの本の内容を50％も理解していません。数ヶ月後、数年後、また読み返してみるつもりです。その度に追記するかもしれません。そういう意味で、今のところ星は3つです。

ソフトウェア開発に関する面白読み物。それでいてすごくためになる。ジョエルの言う「5つの世界」のうち、パッケージについての話が主だけど、それ以外の世界にも参考になることが多い。 以下、特に参考になりそうなところ。 ・3章 ジョエルテスト ソフトウェア開発環境の善し悪しをチェックする12のテスト項目。 ソフトウェア開発に限らず応用できるところも多い。 もし自分が、テスト項目がほとんど満たされない環境にいて、自分が環境を変えられない立場にいるのであれば、「31章 下っ端でも何かを成し遂げる方法」を読むといい。 ・4〜8章 やさしい機能仕様 まあ、機能仕様と技術仕様を分けてるような現場は経験したことがないわけですが。ここで紹介されてる書き方なら、書く方も読む方も楽そう。テンプレートの項目をびっちり埋めて各機能ごとに膨大な量の文章がありながら、読んだところで何を作りたいのかさっぱりわからない仕様書を撲滅したい。 ・9章 やさしいソフトウェアスケジュール 「そのコードのスケジュールを立てられるのは、それを書くプログラマだけ」は至言。自分の作業時間を見積もるのが苦手な僕ですが、その精度を上げていくための管理方法も書いてある。これは実践したい。

2005年と少し古い本だが、主にマネジメントの話なので、今でも通じる内容も含まれている。 とにかく文章が面白いので、あまり難しく考えずに読めるのが良い。 ジョエルテストという簡潔なプロジェクトが守るべき10の項目があるが、今でも確かに必要だと頷かされるものになっている。

全ソフトウェアエンジニア、開発リーダー必読！！ すばらしいの一言。 買ってソッコーで読み終わったけどただ今２回目読み直してます。 開発者なら絶対読むべし。

[関連リンク] yomoyomoの読書記録 - Joel Spolsky『Joel on Software』（オーム社）: http://www.yamdas.org/booklog/joelonsoftware.html

ジョエルテストで有名なジョエルが書いた本。 こういうプロジェクトは失敗するよねーとか、 こういう状況よくあるけど、実はこうしたほうがいいんだよね、 とか「あるある」と思うようなことが結構書いてあったりする。

とおる氏のレビューを見て購入した本。 和訳した本独特の言い回しに四苦八苦。 けどそれも前半だけ。 更新は興味の合った内容もあって、全体的には まずまずぐらいかと。 この本で紹介されていたいくつかの知識は、 ちゃんと押さえておこうと思った。

ユーモアにあふれた文章センスで、読んでいても退屈にならない内容。 その上、ソフトウェア開発プロセスにおける、ジョエルの経験談や考察から導き出されたベストプラクティスやテクニックが紹介されており、実践でも十分適用できる内容になっている。 中でも、自分が一番参考にしようと思ったのは、技術者の採用面接に関する話題。プロジェクトの要員面談や、自社の採用面談で実践してみようと思う（ちなみに自分に決定権はないけどね）。 そのほか、機能要件書の書き方なんかは、読んでもらう・読みやすくする実践的なテクニックが示されており、今まで自分が書いてきた機能要件書の退屈さ加減を思い知らされた。 まだ読んだことのない人には、ぜひ一読して欲しい本。絶対おすすめ！ 開発経験者にとってはニヤリとしてしまう内容が多いし、まだまだ経験の浅い若手にとってはよい参考書になると思う。 なにより、ジョエルの文章センスにハマること間違いなし。

みんな大好き、joelの辛口ぼやき集です。 批判的なコトバって、いつでも楽しいものです。 さらに切り口がちょっと目新しかったりすると、それだけで賢そうにも思えちゃって、自分も賢くなれそうな気までしてきちゃう。 そういう煽動的なコトバであっても、自分自身がじゅうぶん批判的であれば、イイカンジに有用な知識や知恵をすくいとれるんじゃないか...なんて思ったりしちゃいますよね。 はたして、ぼくはこの本から、シニカルさ以上のなにかを得ることができたのでしょうか？ はてさて。 ま、面白いからいいんですけど。

ひらりんはJoelさんのファンです。 ソフトウェア開発について、自分にない視点をたくさん気づかせてくれるよ。ジョエルテストは自分のレベルを知るのに役に立つ。理想に対して直球です。まわりくどい考えが染み付いたビジネスマンエンジニアには、いい刺激になると思います。

ソフトウェア開発をしていて気が滅入った時に読むと勇気付けられる本。プログラマとしては確かに個室が欲しいな。

ブログでの仕様書に関する記事を見て、参考になりそうだと購入。 エキスパートエンジニアの思想や主張がアメリカ的な言い回しで列挙されている。 エキスパートがなぜエキスパート足りうるかを垣間見れそうだ。

ソフト開発における方法論などが書かれています。 著者は元マイクロソフトでエクセルの開発をおこなっていた人らしく、 書き綴ったブログが本になっている。

プログラム、もしくはそれに近い事をやった事がある人にとっては 何度読んでも楽しめる本。 単に読み物として、また「Joel Test」解説書として はたまた開発としての参考書としても読めるいい本です。

http://blog.setunai.net/20060124/joel-on-software/

面白くて、ためになる。 繰り返し読んで実践していきたい。 この手の風刺が効いた本って本当に楽しい。こんな文章が書けるのはとても素敵だと思う。内容について一切触れていないのはまぁ、読んでみて、ということで。

プロジェクトにまつわるいろいろなTips。現実的ではないものも多い（仕様書を面白く書け、とか。理由は面白くないと読まないから）かとおもえば、タスク管理はプレーンテキストがいいだとか、いろいろ考えさせられるものもある。大規模開発ではまた別の手法が必要かもしれないが、小規模であればこれを読めば十分だ。チーム単位で作業をしてるときにもいいだろう。

遂に買ってもた。毎度本屋で軽く立ち読みして「面白そうだなぁ」って思ってたんだ。読みやすいのが有難い。

筆者のセンスについていけなくて微妙に読みづらい感はありますが、それさえ除けばいい本。大企業で働いていただけあって、理想と現実の落としどころのバランスがうまいのは、参考にしたい。

元MicrosoftのExcel開発を行っていた著者のブログを書籍にまとめたのが本書です。ソフトウェアについて、プログラムの書き方から組織のあり方についてまで幅広く扱われています。エンジニアとはかくあるべきと思える良書でした。

なんて言うか、書かれている事にすごく共感が出来、そういう本は読んでいて楽しい。 たとえば、低レベルな事が高レベルなモノコトに対する理解や意志決定を支配するって事や、いいから仕様書書けとか、オープンソースに対するIBMのスタンスについてだとか、読書かれている事にすごく共感が出来、そういう本は読んでいて楽しい。 たとえば、低レベルな事が高レベルなモノコトに対する理解や意志決定を支配するって事や、いいから仕様書書けとか、オープンソースに対するIBMのスタンスについてだとか、読んでいてすごく共感できる。 まぁ日経ソフトウェアだとか、ソフトウェアピープルだとか、＠ITとかばっか読んで、いったい僕は(私は)どんなふうにこれからソフトウェアを作っていけばいいのよって思っている、方法論中毒患者(かわいそうに)の方は読むと多少すっきりするかも。 後、良くわかったの僕はXPが嫌い。（W

http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-274-06630-4