「ハッカーと画家 コンピュータ時代の創造者たち」 とその関連商品

　誤解を恐れずにいえば、本物のハッカーによるハッカー入門書である。ただし、ネットワーク犯罪者やその予備軍は関係ない。かといって、ハッカーは聖人君子でも数学者でもない。
　技術論だけでなく、ハッカーの生き方、考え方について持論が述べられる。Lisp至上主義など、独善的とも感じられるところもあるかもしれないが、著者は自ら立ち上げたベンチャービジネスを大企業に売り抜けており、その成功体験を背景に主張するだけに反論するなら相当の理論武装が必要だ。
　大企業で出世の階段を昇っていくことなんか考えずに、ずっと最先端の技術と触れていたい、あるいは自分でテクノロジー志向のベンチャービジネスを起こしてみたいと考えている「とんがった」ソフトウェア技術者が若いうちにこのような本に出会えたら幸運というものだろう。あるいは、ハッカーを理解し、尊敬するひとのための本だ。ただし、手とり、足とりの親切さはない。ときおり「分かる人にしか分からない」ような表現もあるので、何年か経って読み直してみたら新たな発見があるかもしれない。 (meta-o/2005-02-28)

翻訳者の川合さんはGaucheやKahuaのハックで知られる本物のハッカーだ．しかも超コアなLispハッカーだ．その川合さんがウェブサイト上でPaul Grahamのエッセーを翻訳しているのを知ってニヤリとしたものだ．ハッカーはハッカーにしかわからないマインドがある．そのニュアンスを川合さんはうまく伝えてくれていると思う．コンピュータにかかわる人よりも，むしろコンピュータを知らない人の方がこの本を面白く読めるのではないだろうか．あとハッカーには（この翻訳本を読む前提で）是非オリジナルのテキストも読んで日本語には翻訳困難なニュアンスを感じて欲しい． (hironobu_suzuki/2005-03-24)

最近はwebに発表したエッセイや、ブログのエントリーをそのまま出版したりなんてことがあるけれども、この本もその類。そういう風に書いてしまうと、なんだか企画モノのような中身の無い浮ついた内容、ある種タレント本のようなものを想像してしまうかもしれないけれども、この本についてはそういうことは無くて、なかなかの内容。

内容はポール･グラハムによるIT業界、そのコミュニティ、もしくはハッカー（ごく一般的なITエンジニアも多少通じるところがあります）に関する文化論をエッセイとして論じたもの。

エンジニアが書いた文章だからと言って、その内容が堅苦しいわけでもなく、また理系用語をちりばめた、その知識が無ければ理解に苦しむようなものでもありません。お互いが技術者だから分かる、もしくは分かってもらいたいと言うような読者層を限定してしまう内容ではなく、エンジニアではない一般の人たちにも非常に分かりやすい内容。
特に非エンジニアの人たちには理解に苦しむところがあるのかもしれない、ハッカーの行動、考え方についてはエンジニアを組織、管理している立場の人間にはぜひ読んでもらいたい部分だったりします。 (espio999/2006-04-17)

眠っていたハッカー魂を喚起させられるパンチの効いた一冊です。
ハッカーと画家の社会的・文化的ポジション、そのほかもろもろの近似を屋台骨にして、ハッカー文化論(?)がつらつらと展開されています。そのつらつらに著者自身の強烈な主観(Lisp最強)が溶け合って、ただの文化論で終わっていないところがこの本の面白いところです。
私もLispに興味を持ちました。この手のハッカー本が好きな方には、まずハズレないですよ。 (nskj77/2005-05-01)

書店に行くと、この本が他のハッキング、クラッキングノウハウ本に紛れているのをよく見かけますが、
思想、社会等のコーナーに陳列されるべき本です。
著者は著名なハッカーとの事ですが、
neutralに思考し、最後まで考え抜くといった事を軽々とこなしているように見え、
ITに関することのみならず、格差やいじめ等の問題について鋭く、深くかつ共感できる知見を披露しています。
たびたび更新される著者のブログで最新の記事が読めますので、
これからも注目していきたいと思います。 (hu2/2007-02-17)

あなたが、ハッカーとまではいかなくても仕事でプログラミングを行っているなら、なんとも興味深いと思う。
この本ではプログラミングのみ話題として扱うのではなく、初っ端は教育問題であるが、このハッカーの教育論では、学校も教育制度（アメリカのだが、日本でも全く同じ）もボロカスにこき下ろすが、それがことごとく的を得ている。ハッカー思考があらゆる問題において有効かどうかは分からないが、常識に凝り固まった思考パターンを打ち破る特効薬ではあるし、何よりこの著者が、それに強力なパワーがあることを証明している。
この著者が絵を描いているところも面白い。プログラマと画家は似ているという。彼は絵を描くことからも、自分の感覚やプログラミングスタイルに確信を得たと思う。
プログラマならこれを読み、自信を得て可能性を高めるかもしれない。と同時に、IT社会そのものの真の本質も理解しやすくなるはずだ。案外、歴史的な書物かもしれない。 (silvermoon/2006-12-15)

何気なく手にしたので、彼の経歴や、Webサイトなどまったく未見であったのだが、非常に面白く読めた。
とくにタイトルにある通り、ハッカーと画家との類似点を上げているところや、彼の立ち上げたベンチャーの話など。。。
技術に対してなんらかの持論を持っている方はぜひ読むことをお薦めします。
プログラムをしない方でも十分読めますよ。 (kurookura/2005-03-16)

まだ、２章までしか読んでませんが、他の本には載っていなくて、なおかつ僕にとって共感できることがいろいろ載っていて、グイグイ引きこまれながら読んでます。
０章の、ものづくりにおいては、あれこれ前もって用意周到にやろうとせずに「とにかくやる」方式が有効だ！という考えは、僕自身行っている研究活動でも、当てはまってると思う。なんつーか、人は、勉強すればするほど、無駄で実効性のない議論にハマり易くなるように思う。自分にとって、動きやすいフィールドを見つけて、その中で「とにかく動く」ことが、ものづくりパーソンの健全なあり方なんだと思う。
１章「オタクはなぜもてないか」は、好きか嫌いかはっきり分かれる章だと思う。内容は、筆者自身が、中学・高校時代と灰色生活を送っていたこと、その原因に、学校システムというものの、無目的さ、それゆえに、子供たち自身による秩序の構成が起こって、空虚な人気競争に明け暮れる結果となり、オタクはその居場所を失って、さらに、いじめの標的になる・・・みたいな話。僕自身、中学・高校時代に対して、著者と同じような感情を持っていて、「受験勉強って、意味あんのかなー？」って、当時、かなり悩んでいたことを思い出した。僕も含めて、大抵の大人は、大人になるとそーゆーことを忘れてしまうんだと思う。でも、筆者は、そのことを執念深くもおぼえていて、自分の本の１章を割いて議論している。多分この章が、著者の一番言いたかったことじゃないかなって気さえしてくる。
著者によれば、学校ってのは、親がその管理から解放されるために、若者を押し込めて、退屈な授業という儀式を繰り返す、一種の刑務所のようなものらしい。僕もまあ半分くらいは同意かな。大人が真剣に制度の改革を行う必要があるって著者は言ってるけど、僕は、どこにも理想の制度なんてないのではと思う。制度改革で解決がつく問題なんて実際ほとんどないというのが僕の考えだ。（制度は作るより、実行するほうが１００００倍難しいというか。）とにかく、オタクという人種は、若者を押し込める学校制度の中で生きにくい存在であることは否定できない。むしろ、学校制度の外で、自分の創造性を発揮できるコミュニティーを見つけること。世界を広げることで、学校制度でのウサを晴らすというか、そーゆーくらいしか現実的な解決策はないんじゃないかって思う。今は、インターネットとかあるし、そーゆーコミュニティも作りやすい環境にあると思う。少しづつではあるが、僕らの時代より物事はいい方向にいっていると思いたいなー。
なんか自分の意見ばっかりだな、レビュー失格かも。本書購入の際の参考になれば幸いです。
教育関係者にもオススメ？？？ (shom/2008-08-20)

Lispハッカー及びエッセイストとして知られるポール･グレアムのエッセイ集。
Web上のエッセイをまとめたもの＋新たに書き下ろした2章。
タイトル「ハッカーと画家」は第2章の題名をあてたもので、本書の当を得ていない。
前半は主に”デザイン”について、後半は”プログラミング言語”について述べている。

非常に斬新な切り口に、痒いところに手が届く話題運び、
論理的で無駄がない文章に、読者の心は掴まれる。
（Gauche開発の川合史郎氏による）翻訳も、読みやすくて良い。

興味を抱かれたなら、Web上の日本語記事を一読すると良い。
「知っておきたかったこと（What You'll Wish You'd Known）」（本書に非掲載）
は、自分が高校の頃抱えていたモヤモヤを、見事に吹き飛ばしてくれた。 (おひるねおさる/2005-02-22)

訳者のホームページで、原著者のエッセイの翻訳を毎回楽しんでおりました。原著が出たので、手に入れました。こういうコンピュータ関係のエッセイの翻訳書は出ないだろうなぁと思っておりましたから。日本語訳は、おまけがあるので、原著とほとんどのエッセイが無料で読めるとは言うものの購入しなければなりません。ありがたいものです。どこからでも読めるし、学生だって楽しめるところがあるんじゃないだろうか。こうなるともう一人のLisp使いRichard P. Gabriel（こっちは音楽作家）のエッセイ（パターンにについて）の翻訳も読みたいね。売れないと思うけど。 (/)

それなりに面白く読んでいたのですが、１２９ページで、それ以上読めなくなってしまいました。ベイズ統計を使ったスパムフィルターの説明のはずなのに、「一方の集合にのみ現れる単語の確率はどうするかという問題もあるが、これも試行錯誤から0.01と0.99とした。」このどこがベイズ統計なのでしょう。この１文のせいで、すべてが暗転しました。ベンチャー企業は体力だけの勝負なのか？とか、ナードが中学時代にいじめられてそれに対する復讐心がベンチャーの原動力ということか？こんな会社買収したyahooもトホホ？ベイジアンを名乗るビルゲイツもこの種のデタラメを信じているかも。と、暗い連想が次から次から押し寄せて。 (Datura/2005-02-06)

自分の仕事道具はいつでも手の届くところおき、
ヒントやひらめきや良いアイディアを形にする、
画家とハッカーが本質的に同じと主張している。

アイディアというものは思いついてもそれはあっという間に忘れてしまう。

兎に角、考えてじっとするよりもまずやってみる。
すばやく仕事を仕上げる、そして良い仕事をする。
そんなヤツラがハッカーなんだ。

自己実現・自己表現のために一生愛用できる武器を手にせよ。 (ishingo/2009-04-16)

ポール・グレアム氏のエッセイ集です。
内容は挑発的なので他人には進めにくいのですが、
中級レベル以上のプログラマがターゲットです。
初級、初心者では言っている意味が分からないかもしれません。

タイトルになっている「ハッカー」とは優れたプログラマの意味として使っていて、
「画家」がどう関係するか興味深く読んだのですが、
ポール・グレアム氏は美術学校に入った経験をもち、
プログラマと画家の仕事が似ていると感じていて、
何処が似ているかは一読ください。

ハッカーが日頃考えていることが分かる一冊でした。 (なか/2009-02-15)

プログラムマネージャーとして働くことが多いため、どうやって円滑にプロジェクト、特にチームを率いていけるだろうかと考えていたころ出会った本です。

仕様書の書き方（なるべく面白く書く）、WindowsとUNIXの考え方の違い（これはすごく同意します）、ペーパープロトタイピング（この本でそういうUIデザインの技術があることをはじめて知った）、エクセルの共有機能を使ったスケジュール管理、テスタ（QA）を雇わないと大変、マーケティングの人間にプログラムマネージャーにしない、開発者の面接の仕方、などなど

この本に書いることは全部ためしている。

ぼくが以前はプログラマーであったので、ジョエルの開発者からの視点はすべてに納得がいきます。

でも、結局はビジネスの人はシステムをドラえもんが作っていると思っているんだろうなぁと良く感じる。
今のところ四次元ポケットを作れといわれていないのが救いか？ (紅天太郎/2007-01-30)

メソドロジやプロセス、プロジェクトマネジメントなどを扱った書籍って、最近多いですね。そういう書籍って、読後に「結局現場で使えるのかなぁ」といったモワモワした感じが残りがちです。そういう本に飽きが来ている人に、この本をお勧めします。この本はソフトウェア開発にまつわる様々なことが書かれた著者のブログを集めたものですが、いろいろな「気付き」を与えてくれるだけでなく、内容がとても「地に足着いて」います。前述したモワモワ感が残りません。著者が現場で得た生きた経験に基づいているからだと思います。

また、訳書ですが、十分自然な日本語であり、とても読みやすいのも GOOD です。 (rerun/2006-02-20)

プロジェクト管理に関する45のエッセイを人気Webブログサイト「Joel on Software」から収録した本。多くの章は読み物として読んだが、中には実務で使いたいと思う方法や考え方を見つけられたのは収穫。一時有名になった「Joel Test」（プロジェクトを成功に導き、コードの質を高めるための指標）に始まり、仕様書の書き方、スケジュール管理、テスターの重要性、ペーパープロトタイピング、開発者の面接方法、チーム管理などなど、ユーモアたっぷりに、現実的ですぐ実践できる指針を示しているのがよい。ブログサイトでのQA集を最終章として収録。 (鈴木純一/2007-09-29)

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

Webサイトに公開したエッセイをまとめたものです。

内容は、仕様書はどうあるべきか、プログラミングに関するtips、人の採用やプログラミングチームのマネジメント、自分自身の仕事の方法、取組み方、IT業界の歴史や各社の戦略、競争に関する考察、以前にいたマイクロソフトの開発の様子などです。技術技術した話題は少なく、マネジメントやIT業界に関する話題が多かった気がします。

独立した話が４５個程度あり、順序もなく、興味のある内容だけ読めるようになっています。

アメリカと日本の違いなどもあり、「明日からそのまま使える」という本ではなかったですが、その考え方は、ソフトウェアプロダクトの生産現場やプログラミングチームを率いるときに、役に立つことが多い印象でした。

勉強のため、というより、読み物として、と思うと、楽しく読める本であると思います。 (lemonerika/2006-09-24)

ソフト開発に携わっていながら、本当の意味でわかっていない人によんでもらいたい本です。泥臭さを本当の意味で理解し、考えようとする気がある人には、納得できる内容ばかりです。

なお、本書には、随所にいろいろな情報がちりばめられています。
新入社員だけでなく、日ごろなんとなくソフト開発している人に、お勧めかもしれません。

個人的には、自分たちのソフト開発チームに参加する方全員に、よんでもらう予定です。
(まみむめ/2007-10-08)

かつてExcel(VBA)開発のマネジメントを行い、現在Win用ソフト開発会社を
率いる著者が、人事採用、環境整備、品質管理、経営戦略等々、縦横な視点
から語ります。
内容は総じて具体的で面白いのですが、もってまわった言い回しが論旨を
ぼかしていて、結局何を言いたいのか結論が見えないことも。
またWordに必要な機能を考え出したのは?年前だと批判するわりに、
自身が開発に関わったExcelの巨大さは必要な機能だと言い張ったり、
.NETのランタイムの巨大さとプリインストールされないことを批判するわりに
VBを開発言語のメインに据えていたり、
アンチエイリアスが読みにくいという著者の主張を通すために、
AAをかけたフォントにわざと読みにくいフォントを使用したりと、
著者の強引な誘導に気づいて鼻白むことも。
しかし、そういった癖の強い著者にあるときは共感し、あるときは腹を立て
るのが、この本の魅力になっています。 (mononoke/2006-04-30)

著者はXPをはじめとするアジャイル手法にやや懐疑的なスタンスを表明しているが、じっさい本書に書かれている内容は、かなりアジャイルである。

重要なのは彼がそれを実体験から独自に編み出して実践していることで、ご立派な「方法論」の本とはわけがちがう説得力がある。そして怖いのは、同様な手法をMicrosoftが長年実践しているという点である。Microsoftには、ちょっとやそっとじゃ追いつけない理由がここにある。 (ただただし/2005-12-25)

コの仕事に限った話ではないけど、いかにして場の空気を読むのが重要で、どうして生産性が上がらないのかとか、経験則に基いた話がたくさんで読んでて楽しく且つタメになる本です。これからプロジェクトマネジメントとかやりそう、またはプロジェクト管理に不安がある人向けかな。もちろん一端のプログラマが上司はこういうことを考えてるのかなあと想像しながら読んでもよし。 (浦郷圭介/2006-01-12)

マイクロソフトに勤めた後自分の会社でも開発者として活躍するジョエルのwebサイトの内容を本にしたのが本書である。
プロジェクトマネージャの真実、マイクロソフトの裏側、ソフトウェア開発の方法論など、ジョエルが普段感じていること・考えていることが軽い文体で書かれている。
面白いエッセイ。おすすめ。 (amazon_hk/2006-05-07)

米マイクロソフトや米大手ISPのJunoで、ソフトウエアの設計・開発に従事してきた筆者によるソフトウェア開発などに関連するエッセイ(同名サイト)を書籍化したものだそうです。

ソフトウェア開発やプロジェクトマネジメントや、業界の論評などについて、優秀なソフトウェア開発者が考えたことを、アメリカ人らしいユーモアのある軽い文体で書かれています。

個々のテクニックなどは、専門書を読めばいいので、エッセンスや考え方みたいなものを理解すればいいというものでしょう。

ただし、このアメリカ人の軽い文体を、日本語訳した文章の日本語っぽくなさが読みづらくてしょうがないので、☆3つにしておきます。 (ヴィヴ/2007-01-04)

すばらしい。
細かく見ていけば不満点もないわけではないが、全体的に見たとき、これほど（いろんな意味で）面白く示唆に富んだエッセイはなかなかない。しかも、自分の知識が増えるほどに面白くなることは請け合いだ。思い当たる節が諸所にあるのも、面白さを倍加させる。

日本の風潮と合わないために採用は難しいが、「読みたくなる仕様書」は心底書きたいと思う。

電車など、公共の場で読む場合は注意。噴き出して奇異な目で見られても自己責任で。 (みりん/2009-05-15)

プログラマーなら気楽に読めるし、ユーモア満載でとにかく面白い本です。

決してかたっくるしい本ではないけれど、色々興味深い話題もありますよ。

joelonsoftware.comのサイトに掲載されていて本に収録されていない記事も多いので、ぜひ改訂版を出してほしいです。 (ミカトイ/2008-12-02)

Scheme で Lisp の洗礼を受けた自分は，本書を読むまで hygienic でないマクロに対して偏見を持っていましたが，読後徐々にその考え方は変わっていきました．
冒頭の引用にある「Lisp はプログラム可能なプログラミング言語である」，この特徴に大きく貢献しているマクロの使い勝手やテクニックを，実例を交えながらこれでもかというほど見せてくれる．何度も読み返してはその知恵を肌身に染みこませていきたい，そういう類の本です． (mits/2008-02-27)

本書の著者ポール・グレアムの別の著書「ハッカーと画家」（オーム社）で、グレアムはLisp言語の実用でのメリットを強く主張していた。WebシステムにおいてもLispを採用することで、グレアムのベンチャー企業はライバル会社よりはるかに早く強力なシステムを開発し、競争に勝ち続けた。Web開発言語もPerlからPython、そしてRubyが支持されてきているが、それはLisp化への流れであるという。
しかし、学術的なLispのテキストを見ても、なかなかそれが理解できなかったので、グレアム自身がこれを懇切丁寧、そして実践的に解説してくれている本書は実に興味深いと思う。
グレアムが強調するLispのメリットはマクロである。本書でも、マクロは機能面は（Lisp独特のクセも含め）もとより、微妙な問題でもある、マクロを使うべき場面、関数との使い分け、効果的なマクロの定義方法からマクロの欠点まで、絶妙な実例を参考にしながら教えてくれている。さらに、Prolog言語の実装やオブジェクト指向Lispも簡易ながら実践的に解説しているのも面白い。システム開発のライバルには読ませたくない本だ。 (silvermoon/2007-06-15)

内容が前に出たソフトウェア開発者採用ガイドとかなりかぶっています。かぶっていない部分は前作と比べると面白くありませんでした。ソフトウェア開発者採用ガイドを持っていない人なら買ってもいいんじゃないでしょうか。 (やすます/2009-05-20)

原書を持っているので邦訳がこの時期に出たことに驚きを隠せないのだが、目次を見ると分かるようにLISPをつかったHTMLジェネレータの例題があったりしてなかなかに面白い内容になっている。
しかし、ずぶの初心者でも分かりやすいかというと、私自身かなりやさしい本から始めたクチなので、この本は文法的にはエッセンスを簡潔に書き込んだという印象があり、そういう点で何か別の一冊がないと、ちょっと敷居が高いかもしれないと思う。 (taka-m/2003-03-04)

Lisp達人によるCommonLispの要点メモみたいなノリ。少なくともその体裁から想像するほどには入門的ではありません。これからLispという人はまずWinston著"LISP"(洋書)を片付けた後で読みましょう。Lisperにとっては日本語で読めるグレアム本が出たんだねぇ、って感じですかね。 (/)

内容は文句なしに最高です。
とにかく考えながら読むのが楽しい本です。
PCにSchemeの処理系を入れてポチポチやりながらやってもいいと思いますし、
紙と鉛筆で、手でやってみても面白いと思います。

ですが、翻訳が最低です。
訳が良くない本とかはありますが、これは問題外です。
こんな翻訳がまかり通っているとは。
誰か、別の人に訳して欲しいところです。
本当は良い本のはずなのに、翻訳の悪さが一気に価値を下げています。
(ark/2008-07-13)

原著を読んだほうがいいと思います。内容的にはかなり良いと思いますが、
誤訳が多い気がします。原文と比較してみましたが。。。 (InTheDark/2008-10-03)

確かに序文の翻訳はむちゃくちゃですが，その他の部分は他の技術書の翻訳と大差ないと思います．
本書の肝は文章ではなく問題を解いていくことにあります．必ず紙と鉛筆と計算機（コンピュータ）を手元に用意し，時間を掛け考えながら解き進めていくべきでしょう．読む本ではなく考える本です．
原文はこちらで公開されています．http://mitpress.mit.edu/sicp/ (りょうす/2007-12-10)

「これ1冊でコンピュータのすべてがわかる本」ではありませんが、プログラマにとって必読の本です。この本で言う解釈(Interpretation)を理解すればプログラマにとって新たな道が開けるでしょう。scheme の言語解説に始まり、scheme 上で新たな言語を生成し、インタプリターを生成し、最終的にはコンパイラまで作ります。gcc コンパイラが lisp を採用している(?)意味がわかります。
この類いの本は他にありません。
日本語をよく読めば原文の意味もわかります。訳文（の評価）に惑わされずに上を目指すプログラマなら是非読むことをお勧めします。 (foobar/2005-11-30)

まず、原著は(とても)よい本に違いないということには異議無し。
日本語訳について：この本(第２版、和田訳)は、他の多くの方が言っていますように、とてもひどいです。前書き、本文の最初の十数頁を真剣に読んでみてください。ストレスがたまります。多くの箇所で「英語ではなんてかいてあるんだろう？」と考えこむことになると思います。
なお、原著の第１版の日本語訳が存在します：元吉文男訳、マグロウヒル(1989)。こちらは、私は見たことがないのですが、もしかしたら訳文は問題ない(良い)のかもしれません(信頼できる人が推薦していましたから)。残念ながら出版社が倒産してしまい、今は古本以外入手不可能ですが。 (/)

この和田氏訳の日本語版、日本語が最悪です。どんなに英語が苦手な人でも、恐らく英語で読んだほうがはるかによいと思います（なお、オリジナルは全文 Web で公開されています。確か）。 (んんたら/2004-05-04)

大学の情報系というと、LispかPascalが基本でした。
本書のように、コンピュータ、プログラムの仕組みを親切に教えてくれるものをもっと早く知っていれば、脇道にそれなかったかもしれない。

計算機の仕組みと、プログラミングの基本技術について知ることができます。
名古屋アジャイル勉強会でも、しばしば話題になっています。
計算機、プログラムの構造が、いかに重要化がわかると思います。

最近、大学ではＬＩＳＰは流行らないと嘆いていた先生がおみえになりました。
ＬＩＳＰはアセンブラのようなものなので、情報科学系では。本書を使って１年で教えるべきだとお話しました。

海外の講義の映像が自由に見られるので、自習も可能です。 (kaizen/2008-05-01)

原書を読め!といろんな方がおっしゃっていますが、日本語で読める手軽さは否定できません。
ただ、内容は非常に高度な概念を含みますので簡単には理解できませんよ!(私はすべて理解出来ていません)
しかし、コンピュータサイエンスを志すものとしては是非とも原書、訳書どちらでも良いから一度は読んでもらいたいものです (takuya_o0917/2003-01-26)

あくまでテクニカルに本文のみ見るのをお勧めします。本を始めから順番に読んで行く人は、要注意です。日本語が最低です。 (/2003-01-17)

　講義の教科書として疑いも無く購入しましたが、せめて前書きだけでも読んでから買うべきだったと反省しています。他の方のレビューでも同様のコメントが書いてありましたが、序文の段階で既に日本語が理解出来ない部分が多数……一昔前の安物の翻訳ソフトに任せたのではないかと疑ってしまうほどの訳文の独創性にはもう天晴れです。それでも邦訳版を読むのだと言う方は、取り敢えず買う前に序文だけでも読んでから判断しましょう。
　調べてみると、MITでWEBにも公開しているようですので、そちらを参照するのも良いかも知れませんが、使い勝手が悪いので個人的には洋書で購入するのが一番かと思います。邦訳は脅威的ですが、内容自体は高級な内容を扱っており、Schemeを中心に計算機によるプログラムの醍醐味を十分収録してあります。と言っても、自分自身全て細かく読んだ訳ではないのですが、教科書的に最初から徐々に読み進めていくよりは、自分の参照したい箇所を見つけてざっと概観を掴んだ後は辞書的に、あるいはプログラムのテクニックを磨く為に参照するのがお勧めです。実際相当分厚い本で、更に収録内容も非常に多いです。それでも私は最初から全て読むのだと言うのであれば、それこそ洋書版を読むことをお勧めします。 (/2005-06-20)

学生レベルの翻訳。
訳者を代えて欲しい。
内容は秀逸。
(turbo/2008-12-07)

楽しいプログラミングの入門. lisp/scheme 利用者は必読. 実用本位の人には楽しくないかも. (nofuture4u/2001-05-04)

　Small is beautiful これがUNIXの設計思想だ。これはフォルクスワーゲンが世界に売り出したときのコピーだそうだが、なかなかおもしろい考えだ。基本的にこのOSは小さなプログラムをいくつか組み合わせることで素早くアプリケーションを走らせる、合理的なOSだ。シンプルだからこそ早く作れる。小さいからこそ素早く未来に対応できる。いくつかのプログラムに分割できるから、悪いところをすぐに直せる。多機能主義の弊害は確かにうなずける。「一つのプログラムには一つのことをうまくやらせる」とは魅力的な言葉だ。 (マーマレードスカイ/2002-01-13)

UNIXユーザーへ向けた本書ですが私は、知的生産のための指南書としても読み換えられる濃い内容と思います。
プログラムという単語を、ヒトや組織に置き換えて考えるだけで、この本は優秀なビジネス書となりえます。
第三章の人間による3つのシステムのくだりは、まさに創造的組織の成長過程を描いており組織改変の糸口を指し示しています。
UNIXについての知識がなくとも、仕事でPCを使用する方なら読んでわからない内容でもないです。
効率的な仕事をするという意味ではプログラムも組織も同じ、そして会社のベースになる理念といったものがOSに相当すると思え、理念無き組織もまたありえないことを教えてくれます。
コンピュータ技術書のレビューになっていないかもしれませんが、購入を大変お勧めしたい本です (kaizen/2008-05-13)

小さい機能のコマンドを、パイプでつないで複雑な処理をする。
AWK,SEDのような小さな処理系で、複雑な処理をこなす。
UNIXの提案は、画期的でした。

１つの関数が１つのコマンドのような設計思想は、試験可能性と、プログラムの成熟という視点で有効だと感じている。

それに対して、重くなっていったUNIX,重くなりつつあるLinux。
KNOPPIX、組込みLinuxをはじめとする軽いLinuxの努力もある。

システム全体の堅牢性は、コマンドをパイプでつなぐより、全部をひとつにコンパイルするほうがよい場合もあるかもしれない。
自分ではUNIXのカーネルそのものの設計構造、コンパイルでくみ上げていくMAKE設計方法についての選択方法がこれでいいかどうかの指針までたどりつけていない。

シェルとカーネルという構造は成功し、Macintoshですら、UNIXの思想下にあるのは、隔世の感がある。
Windows2000も、かなりの部分はUNIXの思想を取り入れている気がする。

ps.
OSEKのように、UNIXとはまったく異なる単純化を目指したOSの位置づけが、設計思想と哲学という点で比較した書籍がでることを期待している。 (山田晃嗣/2008-11-20)

白状しよう。私はUNIXがキライだ。
あの判りにくくて覚えにくいコマンド体系はなんだ？
やれBSD系だの、V7系だの、大同につけず、小異に拘るUNIXファン達が理解できない。
いざ使おうととすると、「それをやるならツールは自分で作ってね」と言う感じで
ユーザーに高いスキルを求める文化も、とっつき難さを感じさせる。

昔私が使っていたDECのVMSは、実に素晴らしかった。
実に見事に統一されたコマンド体系、判りやすいヘルプ、充実したツール類、などなど。
UNIXなんて、「みんなが使っている」こと以外に
いったい何が良いんだろう？？？？

などと思っていたUNIX嫌いの私にも、この本は実に興味深く読めた。
なるほど。これだけ普及したのにはそれなりの理由があったわけだ。

まずはこの本のタイトルに注目。
日本語訳は「・・の考え方」などと言う無味乾燥な訳になっているが、
原題は「The Unix Philosophy」、つまり「UNIXの思想/哲学」なのだ。
この「思想/哲学」と言うタイトルが表すとおり、
多くのユーザーをUnixに惹き付けたのは、
UNIX自体の造り(実体)ではなく、その背後にある「思想/哲学」だった。
つまり、その思想/哲学に共感すれば、部品を継ぎ足すもよし、
改変するもよし、さあ皆で一緒に使いましょう、作りましょう、
と言った感じで実はハードルが低い。

さらに、Unixが生まれて普及するまでの上記の「思想/哲学」は、
現代の情報システムで使われるUnixには全く当てはまらないことも興味深い。
今ではUnixはハイエンドシステムで使われるために、
一部企業の管理下に置かれ、一般のユーザーは手出しできない。

正確な定義からするとUnixとは言えない「Linux」が、
初期のUnixの思想/哲学の一番の継承者になっているのも皮肉なことだ。 (/2007-04-24)

Unixにどっぷりつかっている人向けの本だと思う。実用書ではないので、すぐ役に立つノウハウを欲している人にはあまり役に立たないだろう。薄い本なので手軽に読めるが、その内容は、書籍としては他に類がないものだ。ひとつ残念なのは、「実際にUnix環境でプログラミングをしてみないと、この本が本当に伝えたいところはわからないかもしれない」ということだ。 (/)

題名通り、UNIXの設計思想と哲学について纏めたもの。コマンドの具体的使用法以前のOSのあるべき姿を書いたもので、UNIXあるいはLinux上の開発者にとっては実用書の前に読むと、何故UNIX(Linux)が現在の体系になっているのか理解できる。

「Small is beutiful」、「Only for one purpose」、「Don't make new program but use existing one」など、今では当たり前とも言える概念だが、現実には「複雑なプログラムを自力で作る」環境で仕事をしている身にとっては理想の世界と言える。

そして、この概念を究極の形で推進したのがLinuxを初めとするオープン・ソースの世界だと考えると、本書で語られる哲学が以後のソフトウェア開発環境に大きな影響を与えた事が分かる。OSを初めとするソフトウェアの開発思想の基本を綴った貴重な本。 (紫陽花/2007-07-29)

思想としてのUNIXを理解するのに、非常によい本。

1つ1つの定理が例とともに述べられ、UNIX思想を簡潔に説明しています。
どの定理も合理的で、美しいとさえ感じます。

UNIX環境以外でも、プログラミングに携わる人には是非読んでいただきたいです。
ソフトウェアのユーザインタフェースを考える上で、大きなヒントが見つかるでしょう。 (asa/2008-09-14)

総頁（本文）：148（145）　読了時間：10時間
想定読者（必要知識）：情報系の学生以上（基本的なコンピュータの知識）

・UNIXの根本にある哲学を解説する。
・一方UNIXの具体的操作の解説は、例示を除いて一切無い。

・焦点を絞ったことで、非常にコンパクトにまとまっている点で良い。
・UNIXの哲学は、ソフトウェア業界にとどまらず、一般的にみて方法論として優れている。下手なビジネス書よりも面白い。
・フィルタとしての機能を高める、いわゆる”CUIの良さ”が直接的に書かれている。
・32頁からの人間による三つのシステムが面白かった。あらゆる事象にあてはまる法則で、思慮深い。
・第9章「UNIXとその他OSの比較」が面白かった。選択肢は絞るべきか、広げるべきか。

・フェアじゃないが、その他のOSとして取り上げられているものが『Atari』『MS-DOS』『OpenVMS』とクラシックなのが難点。 (shom/2008-09-08)

最近LINUXについて学びだしたのですが、なぜLINUXは（UNIXもですが）GUI環境を持ちながらCUI環境が主なのだろうと疑問に思っていました。私のようなWindowsユーザには、CUIよりGUIの方が優れているという考えがありましたが、本書を読んで改めました。
「Small is beautiful」単純なことは間違いも少なく、また間違いがあってもすぐに見つかる。賢いプログラマなら言われなくてもわかっている事かもしれませんが、UNIXを使うだけでなく、プログラマとしての基本的な考え方を再認識させてもらった良書です。UNIXあるいはLINUXを使う方だけでなく、プログラマ全般にお勧めできると思います。
執筆年はこの手の本では古いかもしれませんが、決して内容は古びていません。ぜひ一読してみてください。 (bash/2006-11-13)

正しい姿勢でUNIXと向き合うことは、現実的理想主義の能動的な在り様を体現することである、と思います。
コンピュータ・システムに限らず、社会、会社などといった「組織」を次世代に継承していこうとするとき、この本に示す考え方、手法にたどり着くのではないかと思いました。

一時の感情や目先の我欲をできるだけ無視すると、最後まで理解しやすいと思います。 (saioh/2005-03-07)

UNIXの有用性のみならず、プログラミングを組む上での、注意点や拡張性の重要さなどSEとして必要な基本的な知識の認識にも役に立った一冊だった。自分はSE職について1年目なので今回読んだこの本に書いてあることは、参考になる部分も多かった。今後の仕事に生かしたい。 (ハッカ飴/2003-09-29)

良いソフトウェア、つまり高品質なソフトウェアを作るのに役立つ本です。

本書に書かれている考え方はUNIX周辺に限らず、オープンソース、反復型の開発プロセス、Webサービス、XML、オブジェクト指向、（あとXPの一部）などといった現在のソフトウェア開発一般に通じるものでした。

その一方で、ソフトウェアの使われ方（ユーザーインターフェース）に関する事柄については本書の内容とは逆の方向へ進んでいます。
これは今後のソフトウェア開発の参考になるのではないでしょうか。

これはUNIXについての本ではありません。
UNIXを発展させた開発者たちの考え方が書かれているのです。 (及川　厚/2006-03-23)

「UNIX」をまったく知らない人向けの本だと思う。 技術書ではないので、UNIX技術者には余り役に立たない。 全体で148Pとページ数が短いので手軽に読めるが、内容が少々くどい。プログラミング概念を知るだけなら、130P～133Pまでの総括編を読めば解ってしまう。 (/2001-06-25)

泥沼に陥ってるプロジェクトに所属する開発者も、デスマーチになりそうな不安があるプロジェクトに入りそうな開発者も、プロジェクトも順調でお客様との関係が良好な開発者も読んでおいて損はない良書である。

なぜなら、これからの開発者としての取り組み方を考える「MYJOB WENT TO INDIA」や、仕事そのものに対するプロセス改善の指針となる「エンジニアのための時間管理術」、今時のプロジェクトノウハウを詰め込んだ「ShipIt!」等を串刺しにしてプロジェクトの改善というものへの取り組み方を示した本だからということが理由である。

とりあえず、今の仕事に不安な部分がある開発者はこの本を読んでできそうなプラクティスからやらせてくれと言ってみることだ。自分のプロジェクトがアジャイルだとかウォーターフォールだとかは関係ない。仕事場でアジャイルというのが恥ずかしいなら「改善提案」だとか「見える化」とか言語替えしてもいい、今あるものをお客様に動かしてみてもらってもいい、朝ミーティングをやりましょうと言ってみてもいい。必ず何らかのフィードバックが得られてそこから改善が始めることができる。

この本を読むことでプロジェクトを成功に近づける/遠ざける手段を学ぶことができるはずだ。何をすればいいのかさっぱりわからないという人には最初の一歩になるはずだし、いくつかはすでに実践しているという人にはさらなる一歩になると私は思う。
(hsbt/2007-12-28)

面白かったのは「コードレビューのパターン」で、３つの模様を紹介している。コード見直し模様。

オールナイタ
　お奨めしないそうだけど、年に１回はやりたい。ちょうど、昔のJUSE、今のSWESTみたい。徹夜とすればよかったかも。
ピックアップゲーム
　SHIP ITを参照せよとのこと。日本語版の書名は「Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」。読んでみます。
ペアプログラミング
　ドライバとナビゲータだそうです。運転者と道案内とすればよかったかも。
(kaizen/2008-07-11)

ソフトウェア開発の良い習慣について、コンパクトにまとめられています．
１つ１つの習慣の説明の中で「悪魔の囁き」「天使の助言」を使って、開発者の内面にも触れています．

好きな天使の助言を３つだけ上げるなら
* 批判するならアイデアにしなさい、人ではなく
* 自働化されたユニットテストを習慣にしなさい
* スタンドアップミーティングをしなさい

タイトルに「アジャイル」と付いていますが、アジャイルに全く興味がないディベロッパ、マネージャにも役立つ１冊になっています．
この本を通じて、ソフトウェア開発の現場に良い習慣が広まって行くことを願っています．
(hau01/2008-01-12)

このシリーズの、まるでソフトウェア開発専用であるかのような扱いは、もったいない。およそ「プロジェクト」と名のつく仕事に携わる人はいっぺん読んでみるといいと思う。

アジャイル開発手法が正しいと証明した人はまだいないし、おそらくそれは不可能だ。一方、社会システムの多くが非アジャイルで開発されていて、まがりなりにもうまく動いているわけで、アジャイル陣営は「こっちのやり方でもうまくいく」という事例を積み上げていくしかない。

中でも本書のように「アジャイルの現場の匂い」のようなものを扱った書籍は、実際に自分のプロジェクトにアジャイル開発手法を導入してはみたものの、うまくいっているのか自信が持てないような場合にかなり役立つだろう。

本書では各章の冒頭に、開発者を誘惑する「悪魔の囁き」があり、自分のプロジェクトが「きな臭い」方向に彷徨い始めているのを知るシグナルになっている。一方、各章の終わりには「天使の導き」と、プロジェクトが満たされているべき「香ばしいフレイバー」とも言える「こんな気分」という一節があって、正しい方向に進んでいるという確信を得られるようになっている。もちろんこの「正しい」は先人たちの経験の積み重ねにすぎなくて、証明されたものではない。それでも、道に迷っているときに、誰かが歩いた痕跡を見つけられたら、そりゃぁ安心だよね。

本書は、まだまだ何が出てくるかわからないアジャイルのジャングルに、恐る恐る分け入ってみた勇気ある人々のための道しるべだ。ソフトウェア開発者なら、直感的にアジャイル手法が正しいと感じることが多いだろうが、それでも自分の進んでいる道が間違ってないことを一緒になって確認してくれる、心強い友人のような存在として、そばに置いておきたい。 (ただただし/2008-01-11)

私はプログラミングとは無縁の人間ですが、それでもこの本はとても読みやすく、ためになりました。

まず、各章のまとめ方が、非常に明快。　行間のスペースも適度で目に優しい読みやすい配慮がされていたと思います。
個人的には、悪魔と天使のささやきが良かったです。とても簡潔で、且つ、ありがちな思考を的確に捉えており、それだけ読み飛ばしても本書のメッセージの概要は分かるように構成されています。
内容については、SEの方が使われる用語の中身は詳しくは分からないのですが、それでも説明している内容、注意点、改善するためにどうしたらよいかという手法は結構分かりました。
業種は違えど、仕事の精度と価値を向上させるための思考法にはそれほど変わりはないのだと確信しました。
それだけ本書が基本をしっかりと抑えているということだと思います。
もう一つ、「偉大なプログラマ、ではなく、偉大な習慣を身につけたプログラマを目指す」というあとがきのフレーズには深く共感しました。そう、仕事においても人生においても、偉大なことを成し遂げる人間は偉大な習慣を身につけ、それを常にスパイラルアップさせている方なのです。

読んでいてとても気持ちの良い本でした。
筆者とともに、お二人の日本人監修者に心から敬意を表します。
(rickey/2008-01-14)

なにがワクワクするかというと、書いてある内容がリアルで的を射ているからです。

こういう気持ちを持つと失敗へのアンチパターンであるという「悪魔の囁き」も、アジャイルな
方向で開発を進めているときの気持ちを表す「(天使の)こんな気分」も、
プログラマである自分にとってどちらも「起こっている」か「起こりうる」事象であると自覚できるのです。

いつも技術書を読んでいて感じるのは、本の中の人と自分自身は「他人」で「他所ごと」の話でした。
「ああ、この本に書いてある体験をする時がくるのかもしれないな、その時はがんばろう」という思いが
読後にありました。

しかし、この本は「書かれてあることが『リアルタイムの自分自身』」なのです。
多くの問題・ストレスを抱えており「なんとかしたい」と思っている自分のことが書かれているのです。
それは、この本がチームメンバーや自分自身といった「人」を中心に据えて物事を語っているからだと思います。

プログラマの方はこの本を読んで、その多くをすでに実践しているかもしれません。
しかし、必ず得るものはあります。　非常に読みやすく、一週間もあれば読めるでしょう。

個人的には、自分はいつもMVCモデルのM(モデル)から作っていたのですが、
V(ビュー)から作ったほうがいいのだと自覚しました（当方は少人数チーム）。

開発言語についてはJavaなどコンパイル系の言語を中心に書かれてあるのですが、
PHPやJavaScriptなどのスクリプト言語のプログラマにも十分読める内容かと思います。
また、アジャイルな開発に有用なツールの名前はいろいろ登場しますが、詳細な使い方までは
載っていません。（まぁ、そういうのは他の本が沢山あるでしょうし）

-- 購入するかどうかを書店で判断するには --
１．目次を見る（気になる項目が並んでいるか）
２．巻末の索引を見る（気になる単語が並んでいるか(特に日本語部分)）

この順番で見て、決断されると良いかと思います。
(zico/2008-03-01)

色々と他のアジャイル本を読みましたが、この本が一番、アジャイルソフトウェア開発をプロジェクトにどのように適用すればよいか具体的で分かりやすかったです。

全体の構成も各項目が短くまとめられていて読みやすかったです。
200ページの専門書ですが３日ほどで読めてしまいました。

プロジェクトが上手くいかないと嘆いている暇があったら、読む価値は絶対にあります。
ブタであるプログラマ（読んでもらうと意味が分かります）の生き残るためのバイブルです。 (なか/2008-08-19)

アジャイル開発のプラクティスを紹介した本です。
ソフトウェア開発の進め方、チームのあり方、プロジェクトの運営
等の分野で、約50個のプラクティスが紹介されています。

各プラクティスは、解説、間違った考え方、
どんな状態となると良いか、、などで、1つのプラクティスについて
5〜6ページで紹介されています。

テクニカルな部分は少なく、ソフトウェア開発の進め方、
チームのコミュニケーション、人間関係などに関連する
部分が多かったです。
ですので、「アジャイル」と構えなくても、
一般のソフトウェア開発でも利用できるプラクティスも多かった
印象です。 (lemonerika/2008-06-02)

全章を通じて具体的な技術にはあまり触れずに、客観的な視点からアジャイル開発者の「あり方（心構えや思考）」を導いてくれます。

アジャイルとう言葉を全く知らない人も含めて、この本はソフトウェア開発に関わる全ての人に読んでいただきたい。まさに教科書です。

私は仲間にもこの本を自信を持って紹介しています。
(Tetz/2009-06-27)

　本書によれば、「アジャイル」という名前が付けられた開発手法は、2001年2月に発表された「アジャイルマニフェスト」に端を発している。よりよいソフトウェア開発方法を解明しようとして議論した結果、次のような価値観が根底に据えられたのである。
　- プロセスやツールよりも、人と人との交流を（重視する）
　- 包括的なドキュメントよりも、動作するソフトウェアを（重視する）
　- 契約上の交渉よりも、顧客との協調を（重視する）
　- 計画に従うことよりも、変化に対応することを（重視する）

　この「アジャイルマニフェスト」を実現するための具体的手法を、本書は９つの章立てで述べている。
　それぞれ章はいくつかの節に分かれているが、その節の構成がおもしろい。
　まず最初に「悪魔のささやき」が登場し、アジャイルでない方向へ読者を誘い込もうとする。悪魔に負けない解説文を駆使してアジャイルの方向に読者を向けたあと、正反対の結論をこんどは「天使」が高らかに宣言するというベタな展開。秀逸なのがその後の「こんな気分」というセクションで、２〜３行でアジャイルな考え方を的確にまとめてくれる。最後に必ず「バランスが肝心」というセクションで行き過ぎにブレーキをかけているのが、いかにも「アジャイル」だ。

　ドキッとさせられたり、感心したりする指摘が多かった中で、特に身につまされたのが、第６章の次の一節。

　呼び出す側が、呼び出されるオブジェクトの状態に基づいて判断して、呼び出される側のオブジェクトの状態を変更すべきではない。（中略）オブジェクトの外側での判断や状態変更を許してしまうと、オブジェクトのカプセル化を破ることになる。これはバグの温床になりかねない。

　今担当しているプログラムがしっちゃかめっちゃかになってきたのは、そういうことだったのか!!　なあ〜るほど。 (くろやぎ/2008-05-03)

一から十までプラクティスを掲載した書籍。ある意味、プラクティスを知りたければ、まずこの本を読んでおけば、ある程度問題ない状態まで、プラクティスを知ることが出来ると思います。

プラクティス本は他にも色々出ていて、私は色々な書籍を読んでいるので、アジャイルプラクティス自体から得た新しいプラクティスというのは、あんまりありませんでした。

しかし、各プラクティス毎に設けられている、プラクティスを実行していると「こんな感じ」になることを説明していたり、バランスについて説明していたり、構成にかなり凝っていて、好感が持てるし、非常に分かりやすい。

ただ、読んでいると、初心者には分からないであろう単語が幾つも何度も出てくるので、ある程度業界に所属していて、色々な本を読んでいる人が読んだ方が効果的だろうと思いました。もちろん、決していきなりこの本から読んではいけないという訳ではありませんが。

悪魔の囁き、天使の声という実際現場でありそうな葛藤を表現した手法も面白かったです。特に最後にまとめられている天使の声については、読めば書いてあったことがある程度思い出せるので、いい索引になっていると思います。

訳について言及すると、私はこの訳はなかなか良かったと思います。トム・デマルコの「ピープルウェア」程ではないにしろ、非常に分かりやすい言葉、語彙で書かれている。若干専門用語が出てきて、それに対する説明がなされていないのが残念でしたけれど。

全体としては、基本的なプラクティス全般を網羅している作品なので、実際の現場でどんなプラクティスを採用するかを考える時にも役に立ちそうですし、他のプラクティスを知らない人に対しても、説明しやすい内容に仕上がっていると思いました。これ一冊あれば、プラクティスについては十分なんじゃないかと思わせる一冊です。 (Juca/2008-04-03)

Webに公開されている文書の翻訳出版。http://www.gigamonkeys.com/book/

C->Perl->Ruby->Lispと進んで（？）きた者です。
CDデータベース作成の章（2章）を読んで、Rubyのピッケル本とよく似ているなと思いました（あちらはJukeboxを作りながらRubyの多彩な機能を説明しています）。
文の調子が割とくだけた感じで、結構な章を割いて文法もフォローしているので、私のようなLisp初心者にも楽しみながら読めました。日本語が若干読み取りづらいのは訳のせいでしょうか。

章が進むにつれどんどん難しくなります。おかげで、しばらくは飽きずに勉強できそうです。おすすめ！ (せかんど/2009-04-23)

Lispの本って、やたらと理論的な方向に走っているものばかりで、
実作業のためには使えなかったのですが（もちろん、使える人もいるのでしょうけれども）
この本は、徹底的に実用に徹しています。まさしく「実践」のタイトルの通りです。

ただし、理解しにくいところはそれなりにあります。原著からの問題なのか、訳が悪いのか、はたまた、私の理解力不足なのかは分かりませんが･･･Lispは難しい･･･。

旧来のLispの本とは方向性が違うところは素晴らしいと思います。
(ark/2008-08-01)

インパクトのあるタイトルと黒々とした表紙から、ギーク向けの本と思ってました。
が、読んでみるとソフトな内容。
プログラマとして知っておくべき、気をつけるべき、そして実践するべき内容が上手くまとめられており、「そうそう、そうなんだよねー」とウンウンしまくり。
もっと早く読めばよかったという気もするが、若い頃に読んでも実感が湧かなかったろうな。
挿入されているお話も面白く、新人研修などの講師になったら話のネタに使えそうだわ。
（生徒がこの本を読んでいませんように・・・） (殿下/2007-05-02)

もっと早く読むべきだったと後悔しています。
達人の仕事振りを説いた１冊です。

この本のキーワードとなる言葉は、
１、割れ窓をなくす
２、蛙の煮物
３、伝達しよう
４、ＤＲＹ原則
５、直交性
６、自動化
７、絵画の制作のやめ時を知る

プログラマーでこの本を読んでいなかったら、
急いで読みましょう。
それ位、知らないと恥ずかしいです。 (なか/2007-04-23)

この本には、プログラミングの原則が、詳細かつ分かりやすく記述されている。
それらは、プログラミングをする上での、ごくごく当たり前の事柄なのだが、意外に実践できていなかったりする。

新人プログラマなど、とりあえずは動くものが作れるが、品質がいまいちな人たちに、最も読んでほしい本である。 (卍/2007-02-21)

タイトルは「達人プログラマー」だが、実際の内容は、
システム開発に携わるエンジニアが心がけておくべき内容だと思う。
この本に以下のような記述がある。
ソフトウェアの無秩序さは加速度的に増大する。
そのため、質の悪い設計を行わない、または修正することが出来ない理由を明記するなど最初の無秩序を作らないことが重要である。
これはごく当たり前のことだが、分かりやすい例で書かれているため、知識として身につけ易くなっているところがこの本の良いところだと思う。 (3cr/2003-12-25)

本書の内容は、仕事のできる上級プログラマたちのノウハウ集である。
書かれている内容は、ある意味当たり前とも言える内容だが、この当たり前のことを実践できていれば、相当効率の良い仕事ができるのは間違いない。
もう１ランク上のプログラマになるためには、必読の本といえる。
このような優れたノウハウ集を、書店で簡単に手に入れられるとは、いい時代になったものだ。
なお、本書の内容を役に立たないと思う方は、実践経験が不足しているのだろう。
折角のノウハウも、実体験に照らし合わせて読むことができなければ、本当の価値を見出せずに終わるかも。
逆に、今まで何度も痛い思いをしてきた方にとっては、「そうそう！」と頷きながら読めるに違いない。 (/)

この本には、質のよいプログラムを書くことが出来るようになるよう、
70個のヒントを示しながら、良いプログラミングの方法を教えている。
自分も早くこのような本にめぐり合えていたら、と思う。
ヒント38：抽象概念はコード上に、詳細はメタデータ上に書くこと、
など、示唆に富むヒントから基本的なヒントまで、すべて為になった。
いろいろなレベルの方にお勧めできる本です。 (kaizen/2008-07-09)

伝える事柄さえ正しければ、伝える方法は何でも良いというのが間違いであることは、うすうす気がついていました。車の両輪というほど大事なものであることは、本書を読んで初めてきがつきました。そうだったんだ。
ヒント１１： DRY　Don't　Repeat Yourself。

１０　曳光弾
はずかしながら、読めませんでした。
ネットで探したら、「えいこうだん」とのことで、英語はTracer ammunition。
飛びながら光の軌跡を残す弾丸のことのようです。

どきっとしたのは「ヒント２７：仮定せずに証明すること」。
しまった。やられたと思いました。星５つ。
(袴田彰礼/2001-03-16)

システム開発者が何気なく実行していたことが 書かれていて、素晴らしい書籍である。 優秀なエンジニアを目指す方は必読すべき。 その上、ソフトウェアエンジニア以外の職種にも 摘要できる内容である。 (本音のレビューアー/2003-10-22)

プログラムに関する本、というより、プログラマーを職業とする（したい）人の為の本。
啓蒙的な内容なので、技術書として読むよりは、自己啓発の為に読む、というのが、正しい読書スタイルではないでしょうか。
書いている事のすべてを実践する必要は無さそうですが、刺激を受けると言う意味では、すばらしい内容の本だと言えます。 (/2004-02-29)

SEとしての基本が記述されております。2,3度読み返すことを薦めます。システム開発に入る前には、再度目を通すと開発時に注意すべきことが思い起こされ良いものを作れる手助けになるのではないでしょうか？ (/)

　達人とあるので、上級者向けと思われがちであるが、内容は、初心者から脱し、中級、上級者への移行途中の方が読まれると良いです。　私は、すでに上級レベルに達した後に読みましたが、これを若い頃に読んでいれば、もっと楽に上達できたのでは無いかと思います。　テクニックと言うより、考え方、創造力を磨く事が出来る書籍です。 (シンちゃん/2005-03-16)

いわゆる眠くなる本の典型です。書いてある内容もわかりにくい例えや、当たり前のことばかりで、価値のある部分はありません。
特に、実践的なノウハウを知りたいときは、役に立ちません。 (つる/2001-08-10)

この本はプログラミングやアルゴリズムのテクニックというよりは、開発作業をより円滑に、かつ生産的に行うノウハウについて説明しています。

開発を効率良く行うにはプログラミングテクニックだけでなく、作業の進め方や考え方を知る必要があります。それができないと、工数や開発予算を無駄に使うはめになります(私は工数や予算を無駄にしている開発プロジェクトをたくさん見てきました)。
これを読むと作業を進めるにあたっての正しい考え方が身に付きます。また、プログラミングという作業を哲学的な観点からも説明しています。

抽象的な説明が多く、具体例が比較的少ないですが(もちろん具体例が記載されているものもあります)、その場合は、他の本を参照すると良いです。
この本の中でも紹介されているプログラミング作法という本と組み合わせて読むことで、より理解を深めることができます。
この本に限らず、一冊の本だけでなく複数の本を組み合わせて読むとより多くの知識を得ることができます。

曳光弾を使った開発についての説明がありました。名前はかっこよくてインパクトがあるのですが、本文を読んでも普通のプロトタイプを使った開発と具体的にどう違うのかが良くわかりませんでした。これも、他の本を参照すれば理解できるかもしれません。

上記の件はあるにせよ、「下手な言い訳より対策を立てること」「割れた窓を放置するな」など、開発者として抑えておかなければならないポイントが満載です(開発者にとって言い訳は絶対NGです)。特に、ブロークン・ウィンドウ理論(割れ窓理論)の話はとても説得力があります。

現在開発プロジェクトのマネージャーをやっている人や将来それを目指している人、また、タイトル通り「達人プログラマー」になりたい人は、必ず読むべき本です。 (/2009-06-23)