リスト：ソフトウェア技術者が読む本 を表示しています。（全 25 件）

バイブルとしていた「ソフトウェア開発の神話」の20周年記念増訂版とのことで期待して読んでみましたが、翻訳の下手さかげんにうんざりです。無理やり今風の言葉に訳している感があり、前作の真意が全く伝わりませんでした。アーキテクトは設計者、インプリメンテーションは製造担当、実現者とはいやはや意味不明、コーダーのことでしょうか。「ソフトウェア開発の神話」を読んでビシバシ伝わってきた感動が何も伝わってきません。山内正彌氏の翻訳の素晴らしさを改めて実感。（ユキナガ / 2005-03-20）

同業人として、名著、古典と呼ばれるこの作品の購入は
迷うことがありませんでした。
そこで読み始めてみると、
１．文章のリズムが日本語と異なっており（英文調？）、
２．（メインフレーム）プロマネの経験がないと理解
　　（同調すること）が困難では
と思われる内容でした。
但し、同内容の立場にある人には、大変有益な
内容であろうと思われ、個人的には機が熟した時
（著作と同じような立場になった時）に
読みたいと思う著書でした。

（HJ / 2007-02-11）

元が論文だったそうで結構わかりづらいです。
最初の２，３章と、最後のまとめの部分はそこそこですが、中心部分は理解しづらいです。訳が悪いという話もあるようですが、それも一因かもしれません。
あと、元になった話が20年以上前だということで、例えが現状に則さないのも一因かも。うわさの本なので買ってみましたが、ちょっと後悔気味です。（timeserver / 2006-04-06）

本書の扱いは大きく３つあると思います。（１）開発現場で経験のある人が読む、（２）これからその現場に入っていく人が読む、（３）一般知識として読む。私は（1）になりますが、いくつか参考になる部分はありました。ですが、（２）、（３）の方は、正直云って分かり辛いと思います。大雑把な分類ですが、これを参考に購読して頂ければ幸いです。（plynth / 2006-05-02）

ＩＴ関連に携わる者の間で、長年語り継がれている真理の一つであるブルックスの法則「遅れているプロジェクトに人員を追加するとさらに後れる」は、この本から引用されました。
本書は、私の周りでは頭の悪い体育会系経営者（管理者）から「縁起の悪い迷信」や「若輩者の言い訳」として迫害をうけたりしました。しかし、本書は、ソフトウェア開発者の愚痴やネガティブな意見をまとめたものでは決してありません。
著者の経験かれ得られた数々の提言は、ソフトウェア開発の本質を解き明かしてくれるでしょう。
初心者には難しい内容かもしれませんが、経験を積めば本書の内容がより分かるようになるでしょう。初心者にこそ読んで欲しい名著です。（スペースデブリ / 2003-04-21）

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

この本には、プログラミングの原則が、詳細かつ分かりやすく記述されている。
それらは、プログラミングをする上での、ごくごく当たり前の事柄なのだが、意外に実践できていなかったりする。
新人プログラマなど、とりあえずは動くものが作れるが、品質がいまいちな人たちに、最も読んでほしい本である。（卍 / 2007-02-21）

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

もっと早く読むべきだったと後悔しています。
達人の仕事振りを説いた１冊です。
この本のキーワードとなる言葉は、
１、割れ窓をなくす
２、蛙の煮物
３、伝達しよう
４、ＤＲＹ原則
５、直交性
６、自動化
７、絵画の制作のやめ時を知る
プログラマーでこの本を読んでいなかったら、
急いで読みましょう。
それ位、知らないと恥ずかしいです。（なか / 2007-04-23）

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

本書を読むのは開発者が多いと思うが、本当に読む必要のあるのは
管理職や経営者だろう。我々開発者は機械ではなく、生きた人間で
ある。人類の長い歴史の中で、技術者が如何にして学び、技術を継承
してきたか。その教訓を現代のソフトウエア開発にも活かすべきである。
優れた技術者は良い仕事をする。あたりまえのことだが、これを忘れ
ている経営者が多くないだろうか？　また、優れた技術者を育成する
のも優れた技術者の仕事であり、会社にとって最も注力するべき仕事
だろう。
本書の一節に、「非常に優れた技術者のほとんどは、やがて独立するか
もっと報酬の多い職種に転職する」とある。この問題をどう捉えるか、
管理職や経営者の方によく考えて頂きたい。（ / 2003-04-17）

ソフトウェア開発は職人の仕事だと思っていたので、思わず購入してしまった。
自分が思っていることとあまり違わないことが書いてあるので、ほとんど読まずに積ん読していました。
多くの書評（レビュー）を読むと、様々な立場で、この本を読んでいる事が分かりました。
「１００人未満のプロジェクトでは、ソフトウェア職人気質に則ったアプローチの方がより効率的になります。」
という記述は、自分の経験則からも妥当だと思う。ただし、能力が低く、なおかつ能力にばらつきがある場合には、１０人になったときから、ソフトウェア工学によった方がよいかもしれない。
職人気質を問題にするには、そこまでの質の高い職人がいる場合だけである。
そうでない多くの人たちには、関係ない世界かもしれない。
職人という響きに何も感じない人は、読まない方がよいかもしれない。
（kaizen / 2007-12-26）

製造業でシステム開発に従事しているため、「職人」と呼ばれる人達は
身近で何人も見てきました。
彼らの技術の奥深さ、知識の豊富さには神がかりと思えるほどに凄みを
感じるものが多いのは紛れもない事実です。
NCマシンやCAD/CAMが進化したとは言っても、製造の現場では定量化され
ていない事象があまりにも多く、思ったようには進みません。
そのため、定型処理や荒加工は自動化できても、納品できるレベルに達
するには職人さんに頼ることも多く、彼らなしには製造業は立ち行かな
いのが現実としてあります（「勘所」という奴ですね）。
本書は半ば強引な論調に思える言い回しもありますが、対比によって
理想＝ソフトウエア工学（NC機械）
現実＝クラフトマンシップ(職人)
を浮き立たせ、一見相反する存在の特性をうまく表現しています。
開発技術の具体例を述べているわけではないので、そういう話を期待す
るとガッカリすると思いますが、理想と現実に振り回されがちな開発者
達に対して健全な心構えのあり方も示しており、その意味では個性のあ
る良書だと思いますね。（製造業se / 2002-07-10）

多くの優れた開発者の大半が、
より報酬の多い別の活動へと移っていき、
しかも、開発者としては頭打ちという状態から
抜け出すために、管理者、起業家、研究者に
ならざるを得ない現状に警告を発しています。
プロスポーツの分野で、花形選手よりも
コーチの方に高い報酬が支払われているような
チームがどれだけ長くやっていけるかで、
例えています。
優れた技術者に育成するために、
徒弟制度を推奨しています。
現在の組織、プロジェクトに違和感を感じる方は、
是非一読してください。（なか / 2007-04-06）

ソフトウェアの開発に関して、単純な「技術」に着目した手法に疑問を
投げかけている本である。しかし、主張が目新しいかと言えば、そういう
こともない。
基本的には、日本の１９８０年代に行われていた手法そのままであり、
特に「職人」と強調しなくとも日本的な組織ピラミッドには自然と見ら
れた仕事の仕方を米国流に解釈して、特有のXP流言い回しに変えている
だけのように見える。その意味で、ソフトウェア工学に関する主張も検討
はずれだし、ソフトウェア工場に関する記述も、本家の日本での組織は
異なっていたように思う。（どちらかと言えば、工房という感じだった）
ただし、フラットで職能的な米国の労働習慣にはデマルコの「slack」など
でも批判していたので、このような批判!!が米国でもあることはオープンや
マイクロソフト流一辺倒の日本の開発組織でも知っておく必要があるだ
ろう。
もし、日本語で同様の主張を知りたいのなら、菅野文友著「ソフトウェア
エンジニアリング」（日科技連）や保田勝通著「ソフトウェア品質保証の
考え方と実際」（同）、石川肇「日本式品質管理 TQCとは何か」（同）など
が良いだろう。
このようなやり方は日本の組織が勝手に忘れていただけだから。（ / ）

プログラマ志望の人にはぜひ読んで欲しい。
プログラマになってしまうと、仕事が忙しくて読む時間がない人が大勢います。
学生のうちに読んでおくのがいいかもしれません。
goto文論争など基本的な情報の資料にもなっています。
すでにプログラマになっている人は、C言語プログラマだけに限らず、多くの方が読まれているとよいと思います。
会社が、本当にプロを養成するつもりなら、必ず読めというと思います。
会社が、読む時間を工面してくれるはずです。
会社が、一時的な金儲けだけを目指している場合には読めと言われないかもしれません。
プロとしての仕事を目指すのではなく、顧客の対応の時間を重視しているなら、読む時間を工面してくれなかもしれません。
そういう場合は隠れて読んで、３年たったら別の会社に行くのがいいかもしれません。
いずれにしても、プロとしてプログラムに向き合う時に必要なことがいろいろ搭載されています。
ps.
最初は全部理解しようと肩肘はらずに、気軽に読み進んだ方がいいかもしれません。
仕事で関係がありそうな話題になったときに、もう一度読み直してみましょう。（kaizen / 2007-12-26）

題名の通り、完璧なプログラミングコードを書くための指針をまとめたシリーズの上巻。
良いコードを書くために守るべき習慣（プラクティス）が次々と述べられており、自分で実践したくなることはもちろん、開発者仲間にも教えたくなるような事柄が満載である。
プログラミング言語は特に指定されておらず、例外は多少あるものの、基本的にどのプログラミング言語を使うときにでも共通に使用できるテクニックが中心に述べられている。
例として上げられている言語はVisual BasicとC/C++、それにJAVAが多いが、コードは簡単かつ明瞭に書かれているため、これらのプログラミング言語を使ったことがなくても、問題なく理解できるだろう。
非常にボリュームが豊富なため、読み切るのに苦労するかもしれない。
しかし、多くの内容が理路整然とわかりやすくまとめられているため、量が多くて苦痛になるという感覚はあまり感じなかった。
また、経験豊富な開発者なら、既に知っている内容も多く含まれているかもしれない。
だが、既知のテクニックを再確認できるという点で、読む価値は十分あるだろう。
完全な初心者には向かないかもしれないが、もっときれいで読みやすいコードを書きたい全ての開発者、プログラマの方々に是非手にとって欲しい１冊である。（the_world / 2005-07-31）

　　なんとなくノリに近い雰囲気でこの業界に入った．
　　プログラミング言語の解説本片手に，あるいはおじさんにいろいろ言われながら
　　プログラミングを覚えた．
　　もう自分は一人前の開発者だ！
というひとが読むと，自分が実はちっとも一人前ではないことや，
ただ動くコードと，それ以上の価値があるコードの違いが理解できる本です．
設計やテストなど，内容的にも大変網羅的で，無駄のない実践的な本です．
また，例として掲載されているコードはVBやC，Javaがほとんどですが，
細かい文法規則を論ずる本でもないので，これらの言語を知らなくても読むことに問題はないと思います．
一見するとボリュームはすさまじいですが，
この内容を経験のみから学ぶ非合理さ（バカバカしさ）を考えれば
むしろコンパクトにさえ見えてきます．
書架に置いといて，定期的に時間をかけて読み直したいと思う本です．（EVAM / 2006-10-01）

　第１版を読んだ時の感動を忘れることが出来ない。コンストラクション（広義の実装）についての「MUST」はカーニーハン等で知っていたが、「WHY」について、ここまで系統的にかつ実践的な書物が存在することに驚きを禁じ得なかった。ちょうど暗いトンネルに先に見える明かりを見つけた時の昂揚感とでもいうべき感情であったような気がする。
　第１版の出版から１０年が経過し、第２版が出版され、早速目を通してみた。第１版では抽象的な話題になりがちであった「ADT：抽象データ型」や「オブジェクト指向」がJAVAやVBによる実装例を得て、現実のソースコードとして記述されている。筆者の豊富な経験が盛り込まれている第２版は決して、第１版の焼き直しではないことを実感した。
　第１版を読んだことがない、新人プログラマー諸氏は第２版をまず読むことをお奨めする。２冊で１万円を超える投資は決して無駄にはならない。さらに本書の参考文献リスト（邦訳名が充実し検索がしやすくなった）を使って守備領域を拡大していくことが「職業としてのプログラマー」には必須であると確信している。
　（銀鼠 / 2005-05-03）

たしかに厚いし、小遣いで買うには高いかもしれない。
でもね、いいね、この本はいいねー。
読みやすいので、厚さに臆することなかれ。得られるものは計り知れず。
中立的な立場で書かれているのが気に入っている。
良いコード、悪いコードの対比も楽しい。
また、各章末で紹介されている関連書籍（寸評が参考になる）が良いんだなぁ。
この本を起点に、多くの有名書籍にめぐり合うことができました。（殿下 / 2006-08-08）

ソフトウェアプロジェクト管理に関する百科全書的内容を誇り、プロジェクト管理者であれば常時手元に置きたい書物と言えます。
CMMやPMBOKのように、決して綺麗に体系立てられたものではありませんが、Microsoftのコンサルタントとしての実績が、実戦に裏付けられた記述を可能としています。ただ、内容が豊富過ぎますので、先ずはさっと全体を洗い、後は必要に応じて適宜参照するような使い方をお勧めします。
原書の出版は1996年であり、その意味では既に古典化していますので、このレベルを早く常識とし、日本のソフトウェア業界全体のレベル向上につなげたいところではないでしょうか。（加納 裕 / 2003-04-26）

コンサルタントが実際に経験したことをベースに書いており、効率的な開発の基本が述べられています。特にプロジェクト管理者にとって一読の価値がある本だと思います。 ・事例とともに紹介されている ・犯しやすい典型的なミスがある ・ベストプラクティスがあり辞書的に使える（ / 2001-03-16）

プロジェクトを上手く進めるためのエッセンスがぎっちり詰まっています。
犯しやすい典型的なミス、見積もり、リスク管理、顧客、プロジェクトチームの取り扱いなどプロジェクト管理において注意すべき事項、どのような手順を行えば上手くいくのかが筆者の経験や実績データなどで説明されており、説得力があり、実践的な内容となっています。ところどころにある「ケーススタディ」は失敗例、成功例が物語風に書かれており、具体的なイメージが湧きやすいです。プロジェクト管理を行うにあたり、この本は私の手元から離せない本です。分厚く、重たく、高価な本ですが、その価値は十分にあると思います。システム開発に関わる全員が読んで欲しいと思う名著です（もし関係者全員が読んで、実践出来たら間違いなくシステム開発の苦しみから開放されるでしょう）。また、筆者の業界全体をいい方向へ改善したいという思いが伝わってくるような感じがします。（kinopp / 2007-02-23）

努力をしている人がいる。それはそれは、傍で見ていても真剣で、真摯で、必死だ。でも成果は得られない。むしろ事態は悪化していく。不幸は累積し、当人は燃え尽き、不満を周囲にぶつけ、時にはその不幸を他人のせいにし、孤立していく…。
実はこのような状態の多くは、「問題を解けない」から発生するのではなく、「正しい問題を見つけていないから」発生する。問題を解いても、解いても、問題が解決されないのは、「問題だと思っている事」が実は「問題の本質ではない」ために起こる。本質ではないため、問題を解決したつもりでも別の形で再噴出するのだ。
この本、多くの人に推奨している。が、大抵の「この本を読むべき人」は「忙しいから」「それどころではないから」と言って、この本を読まずに間違った問題を解き続けている。そして、忙しさが減らないと嘆き続ける。
是非、この本を読んでください。自分は関係ないと思っている人、読んでください。そんな暇は無いと言う人、読んでください。これはそんな「思い込みが激しいがゆえに、問題を正しく把握していないあなた」のための本なんです。（fjの教祖様 / 2007-06-14）

「自分に見えてないことは何か？」。問題に直面した時、このように自問できれば、いい方かも知れません。後になって、「なんで今まで気付かなかったんだろう？」と思うことの方が多いかも知れません。この本のメッセージは「問題は解くことより、何が問題か正しく把握することの方が難しい。しかし、問題把握にもコツはある。」です。
本書の中の非常に簡単な事例について考えている内に、以下について新たな気付きが得られることと思います。
１．自分はどんな思いこみをしやすいか？
２．自分の思いこみに気付くにはどうしたらよいか？
ちなみに原書は"Are Your Lights On?: How to Figure Out What the Problem Really Is"。訳は少々分かり難いところもありがすが、これは原書の言葉遊びの雰囲気を伝えようとした結果。間違った訳はないはずで、あまり心配なさいませんよう。（ / 2003-05-06）

「問題は解くより発見する方がずっとむずかしく、ずっと面白い。
―実人生で本当にものをいうのはそこなのだ。」
・・我々の多くの過ちは、
「問題は何なのか？」を確認する前に、答えを出そうとしていることにある、
という指摘は目からウロコ。
日頃、考えている・・・と思っていることが、条件反射的に反応しているだけなのかもしれない。
要求分析・要件定義にとりかかる前はもちろん、システム構築で悪戦苦闘しているのであれば
なおのこと、
少しの時間手をとめて、一読をお勧めします。（papillon / 2006-09-29）

この本が発行されてすぐ読み、その後も多くの人に推薦してきた。
われわれシステム屋にとって、またビジネスマン全体にとって、
問題発掘、問題発見は最も基本となる能力であり、その能力を
磨くための的確な指針を与えてくれている。
この本を読んで面白い、と感じた人は優秀なシステム屋やビジネスマンに
なれる素養があるが、さっぱり分からん、つまらん本や、と思った人は
何度も何度も読み返してみてください。
訳は多少手抜きというかビジネス用語になつていないとは思いますが
出版社が数学の本の専門ですからそれは大目に見ましょう。（三浦文篤 / 2003-08-03）

この本１０年程、前に購入して、昨日読み返していました。こちらのサイトに偶然入り参加しようかなと思いました。 この本他の人が書いているように、問題解決のプロセスを色々なケースで、おもしろく解説していてとても、参考になります。自分の問題解決能力の影には、こんな本もスキルとしてあったなあと、懐かしく思い起こしました。
残念なところは、英語圏での書籍なので、タイトルの事例についても、英文と日本語訳でのギャップが目立つため、原書でのジョークや、ユーモアが今一つ、伝わっていあにような感じを受けました。（ / 2001-02-26）

著者ははじめににおいて，「デスマーチプロジェクト（常態よりも５０％以上逸脱している
プロジェクト，死ぬほど大変なプロジェクト）は、常態であって、例外ではない」と述べている．
このような大変なITプロジェクトが避けられないならば，そこから生還するにはどうすれば
良いのかを書いている本．
中身は，アメリカのコンサルタントが書いてある本にありがちな，最初の章で定義を行い
その後の章が色々書いてあるという形態そのもののように思える．ちなみに２章以降は
政治，交渉，デスマーチ・プロジェクトの人々，デスマーチ・プロセス，プロセスのダイナミックス
クリティカルチェーンと制約条件の理論，時間の管理，進捗の管理と制御，デスマーチのためのツールと技術
シミュレーションと「戦争ゲーム」と１１章からなる．
特に難しい理論が展開されているわけでもなく，最後の２章は自分のツールのCMなので
気楽にまずは読むことができるのではないかと思う．そのなかから，トリアージ，時間の管理
チームの構成など，気になるものを探し出す方法が良いのではないかと思う．（親カッパ / 2007-11-29）

デスマーチの定義、デスマーチへ陥る原因のくだりは、共感する部分が多いのですが、
そうなってしまった場合の対策はあまり具体的に述べられてなく、別の本を探したほうが良いのかなと感じました。
また、純日本的な企業で働いていると、アメリカとの企業文化の違いもあり、
ちょっと自分の環境とは現実離れしている部分も気になりました。
- 本の中で出てくるアメリカのマネージャ・プログラマはハイリスク・ハイリターンで働いていて、
　失敗すれば首(ただし転職容易)、成功すれば多額のボーナス、長期休暇。
　マネージャがプロジェクトを請け負うか断るかの選択肢まであり。
　マネージャとプログラマで給料がかなり違う。
- 一方の日本的な企業ではローリスク・ローリターンで、
　失敗しても首の心配はなし。
　ただ、成功してもボーナスはほとんど変わらないし、休暇も桁違いに少ない。
　デスマーチを断る権利はほとんどなく、デスマーチに巻き込まれてる人はほとんどが仕方なく巻き込まれてる
　管理者になると残業手当がなくなり、場合によっては残業代つく部下の方が給料多い。
どちらの社会・会社がいいかは人によって違うと思いますが、こんなデスマーチを避けるにはどうすればよいか？というのは、もっと勉強と経験を積んで修得しないといけないのかなと思いました。（kura / 2006-10-23）

書いていることは事実をある視点で記述しているのだと思います。
解決策は、それぞれの現場で違うので、自分達で考えるしかありません。
現場の感触としては、能力のある人間にやる気を与えて仕事をした結果を、
どうお金に変えるかの手腕が経営者や営業にあるかだと思っています。
そういう手腕のある人でも、手腕があるが故に、仕事量が１０倍、１００倍になったときに、対応方法を誤ることがあるように思います。
万能の解決策はないということではないでしょうか。
少なくとも、
１　有能な技術者を組織する（やる気にさせる）
２　お金を支払う顧客を捜してくる
の２つができれば、大丈夫なのではないでしょうか。
割とありがちな問題と、割とありがちな解決策が体系的に書かれているので、時間があるときにのんびりと読むとよい。くれぐれも、デスマーチプロジェクトの時には読まない方がよいと思った。こまっているときには、原因を解決する方法か、対策が大事で、ありがちな解決策では解決しない。それは、公式プロセスの導入という、デスマーチプロジェクトに適用してはいけないと本書で書いていることと同じではないだろうか？
（kaizen / 2008-01-06）

本書で言う「デスマーチ」とは、主にソフトウェア開発を対象として「開発者に過度の負担を掛けながら破綻への道を突き進む」プロジェクトを指す。私はソフトウェア開発25年の経験を持つが、私の入社時には「遅れたプロジェクトに新たに人員を投入すると、そのプロジェクトは更に遅れる」という名言で有名なブルックスの「人月の神話」がプロジェクト管理の本として著名であった。
本書では、「プロジェクトのパラメータが正常値の50%以上のもの」をデスマーチと明快に定義している。例えば、納期、人員、予算等が見積もりに対して半分以下なら即デスマーチだ。逆に要求仕様が2倍だったらやはりデスマーチだ。著者はデスマーチが起きる原因を、経営、営業、楽観主義、不測の事故等に分類し、解説する。こうした分析嗜好はアメリカ人の性癖によるものだろう。簡潔に言うとアメリカでは職能(マネージャ、担当者etc.)主義が徹底しているのでそれに沿って、ある意味マニュアル化した方法で対処するのが良いと言う。
翻って日本はどうだろう。顧客との折衝でビジネスライクに事を進め、常に必要な予算を確保できるのであろうか ? 私はむしろマーフィーの次のような法則の方が現実に近いように思われる。「失敗する可能性のあるプロジェクトは必ず失敗する」。そして、失敗する可能性の無いプロジェクトなど存在しないのである。（紫陽花 / 2006-12-01）

ソフトウェア開発業界では、８０年代後半から９０年代にかけて「ＣＡＳＥ」や「構造化技法」が一世を風靡したが、著者のＥ．ヨードンは構造化技法のひとつ、ヨードン法の考案者として著名であった。筆者にとっては懐かしい名前である。
さて本書は、そのヨードンが長年の経験にもとづいて、デスマーチプロジェクト（＝開発メンバに非常にきつい労働を強いるプロジェクト）からの脱出方法を説いたものである。考察は広範に渡っていて、政治的圧力への対処方法、予算や期日の調整、リソースの交渉術、人の問題への対処法など、システム開発プロジェクトで直面する問題をほぼ網羅している。
とくに新しいアイディアとしては「トリアージ」という考え方を提出している。
「本書からたったひと言だけ覚えるとすれば、それは「トリアージ」である」P127
トリアージとは、戦場や被災地で限られた医療資源を、緊急性や効果に鑑みて、負傷者に割り当てること。転じて、数量の乏しい必需品を最大の効果が得られる人だけに割り当てるシステム、のことをいうそうだ。火を噴いているプロジェクトでトリアージを間違えると、時間と労働力という貴重な消化資源を浪費してなお火は鎮火せず、いよいよ燃え広がってしまう。いやはや恐ろしい。
ただ論文というよりエッセイにちかく、全体にやや散漫、冗長でまだるっこしい。デマルコに比べるとジョークもいまいち冴えない。もちろんおおいに勉強にはなるが、読み物としてのおもしろさ、という点ではデマルコに２，３歩譲るだろう。
ともあれ、ヨードン、デマルコ、ケン・オア、ワインバーグといった往年のコンサルタントたちに親近感のある方にはお勧めできそうである。（丁三 / 2006-06-17）

1.CVSによるバージョン管理
2.JUnitによるユニットテスト
3.プロジェクトの自動化
という三部構成で、それぞれのツールの有効性と具体的な使い方が説明されています。
基本的な使い方しか書かれていないので、これらのツールを既に使っている人（達人？）にとっては、新たに学ぶものは少ないでしょう。
また、上記のツールを使ってみようという意欲のある方は、インターネットを利用して、より新しく詳しい情報を調べられるはず。
ほいじゃ、本書の対象となる読者は誰かというと、「バージョン管理なんて意味あんの？」とか「単体テストめんどくせー」などと言っている人。
こんな人が身近にいたら、本書をそっと机の上に置いておくのだ。
内容は良いのだが、邦題がいまいちなので星いっこ減らしたぞ。
（殿下 / 2007-02-18）

CVSによるバージョン管理から始まって、
JUnitによる単体テスト、自動化までを説明している。
プログラマーレベルではなく、リーダー、管理者向けな感じの本。
テストファースト等のXP的開発を始めようとしているチームには良いと思う。
というか、今やってる仕事そのままだったので、星5つという話。（hayapu / 2005-04-09）

初版は１９８７年だから、もう２０年にもわたって読み継がれているソフトウェア開発者の「古典」である。著者のトム・デマルコは、８０年代後半から９０年代にかけて活躍したシステムコンサルタント。構造化技法のひとつである「デマルコ法」の考案者としても著名である。
ドッグイヤーとかマウスイヤーと呼ばれるほど進歩の早いこの業界にあって、本書がこれだけ長い間読者を魅了し続けるのは、まさに書名のとおり、ハードウェアでもなく、ソフトウェアでもなく、それを作る「人」に焦点をあてた論考だからであろう。
最近でこそ、コーチング理論やメンタルヘルスなど、ヒューマンリソースのケアが重要視されているが、当時、開発者のやる気や、生産性の高い作業環境、チームビルディングの重要性を正面から論じた本はこれ以外にはなかったと思う。
現場のソフトウェア開発者の視点に立って、管理者や会社側の不条理を追及するというスタンスなので、当時プログラマだった筆者は「わが意を得たり」と密かに喝采を送ったものだった。チームで回し読みしては「パーキンソンの法則」「スパゲッティディナー効果」「チーム殺し７つの秘訣」「黒服チームの伝説」などなど、議論白熱して終電を逃したことも懐かしい。
当時の仲間はいまや皆管理職になり、本書からは攻撃を受ける立場になった。今、第二版を読み返してみると必ずしも肯ける話ばかりではないが、それは単に立場が変わったというだけではなくて、きっと初心を忘れてしまっているからなのだろう。
というわけで、筆者にとって本書は、この業界に身を投じた当時の初心に立ち返るための大切な本であるが、もちろん若い方にも勧めたい。頭のかたい上司、理不尽な上司の下で働いている方なら、きっと溜飲が下がること請け合いである。（丁三 / 2006-06-17）

いかなる仕事も，それを実行する「人」にかかっている。このあたりまえのことをあたりまえと放置せず，「人」の仕事の質を上げる，または下げる要素について広く深く分析している。特に阻害要因についての記述は，組織で仕事をしている人ならば誰しもが頷け，自分の組織にこうなって欲しいと希望を持ち，
あるいは自分の組織のダメ具合に暗澹たる気持ちになるような内容である。経営者やリーダーたち全員に読んで，本書の示唆通り実行して欲しい本。多数の読者の声によって，そのために復刊されたのだから。（kasm / 2001-11-26）

1987年に出版された第1版にプラスして「ピープルウェアの小さな続編」を設けたこと、それと電子メール環境の繁栄により一部の記述を変更した形となって第2版が出ました。実は第1版は読んでいないのですが、記述されている「プロジェクトにおける人」について如何に振舞うか、扱うかの内容は今も15年前も変らないです。特にプロジェクトにおける管理者の役割についてはプロジェクトマネージメントの精神論的な内容に思えて、「ここまで人を大事にすべきか！」と思われるほどです。作業環境について一人あたりのスペースについても記述されていましたが、目に見えない効果をどこまで管理者層が納得して動けるか・・・というのは大きな課題です。
これまでの日本において欧米に追いつけ、追い越せで実施してきて戦後（そのときは皆中流階級）、そして日本が世界に到達したときに得た次なる目標、次なる仕事の仕方が見えなくなり、それとともにITによる世界的なデフレ化。そのために「人」も他と同じように頑張れば食べていけた時代から、何時の間にか360度評価、実績主義へと変貌したかと思ったら、次は「整理解雇」に意味が取って代わったリストラが台頭してきている現在を思うと、「ピープルウェア」は誰のために？と悲しくなったりします。
お互いの利益を超えた（というか利益を考えずにお互いの幸せを供する）仕組みが近いうち訪れるのではないのかと考えています。資本主義は競争社会であり、かつかけがえのない地球を蝕んできたことを徐々に多くの人が気づき、良い方向に向かおうと努力しているように思われます。そのときには「ピープルウェア」の真髄が随所に発揮される世の中になっているのではないでしょうか。
「人」について一番幸せな方法を皆で考えましょうと訴えてくれた大切な一冊になりました。（やんちゃ青 / 2002-07-02）

旧版とあわせて、折に触れて手に取ります。

・・・プロジェクト成功の鍵は、「技術」「プロセス」「人」の３つ。
ＩＴ技術者にとって「技術」は生命線ですが、
プロジェクトの円滑な推進には「プロセス」と、
そもそもの「人」・・感情を持つ人間の営み、組織論の理解が
十分条件になると再認識し、
チームのあり方や
自身の行言動を振り返ることしばしばです。（papillon / 2007-08-21）

謳い文句としてはソフトウェアプログラマーの管理手法とそのあり方についてのお話。
だが、管理という概念について非常に考えさせられる有益な本だと思う。
実験結果もあり、童話のようなものもあり、説得力も高い。
ただ、内容的には「デッドライン」と多くの部分がかぶっている。
気になったのが、後半部から訳が直訳になっていて、
日本語としてというか文章として成立してないと感じる部分が
非常に多く、翻訳ソフトを通した結果でも見ているかのような
文章になっていた。
「デッドライン」のほうは完璧に日本語に感じられたので残念。（んにゃ / 2004-11-27）

内容は間違いなく星5つ。ですが、あえて、欠点をあげつらってみます。
この書に挙げられたテクニックは確実に計算量の係数を減らしますが、次数を減らせるかというと違うことも多いです。そもそも計算する必要があるのかについては疑問を挟まないスタンスをとっています。
未熟なプログラマ -つまり私のような- は、アルゴリズムの選択を間違えて、データ量の定数倍の時間ですむはずの計算を二乗・三乗にしてしまうとか、そもそもやらなくてもいい計算をやってしまうとか、直視したくない放蕩をやってしまうものです。そんな無駄に気付かせてくれるのは、もっとありふれたアルゴリズムのアンチョコだったりします。Knuth の The Art of Computer Programming まで引っ張り出す必要はありません。高校教科書さえあれば旧帝大に合格できるように、3000円程度の和書をマスターするだけで中級のプログラマになれます。
土台から考え直すときには、むしろ別の本を探す方がいいです。土台を固めた上で最後の無駄を削る、つまり真のハッカーにこの書は役に立ちます。（katsuhiromihara / 2005-07-06）

アルゴリズムの解説書は、たいていソートや文字列検索のトピックスに終始しているが、この本は違う。より根本にある算術や論理に費やされるインストラクションレベルの“体脂肪率”（＝時間）削減を、極限まで極めた解説を行っている。だからといって、アセンブラを知らないと読めない本では全くない。むしろ上級のＣプログラマに無理なくアセンブラの教養が身に着く。行列の転置やビットマップのウエイト算出といった、あたりまえに普段使っているコードの高速化を正面から解説してある解説書はあまりにも少なかった。巻末の論文一覧がさらに有用である。２×２行列どうしの積が７回以下の乗算でできることを既に知っている人や、Ｊ．Ｌ．ベントリーあたりの本が好きな人はぜひ！（本多欣亮 / 2004-11-22）

素晴らしい内容であり、星の数による評価はもちろん五つです。買って良かったと思います。「計算をビット演算のレベルに落として色々やる」という内容(しかも洗練されたもの)です。濃い勉強になりました。そんな本なので、レビューで普通に褒めるのでは正直言ってつまんないし熱意のある初学者にとって参考にならない。だから、このレビューでは対象読者層の説明と些細な不満の吐露をやろうと思う。
(1)
本書の内容は普通の大学の教科書レベルの話ではありません。そんなものよりも高度な内容です。「Cは難しいからJavaが好き」なんて学生や教員にとっては今は買うべき本ではありません(難しくて読めないでしょう)。
(2)
本書を読むためにプログラミング言語やプロセッサの知識が強く要求されるわけではありません。どちらかと言うと論理数学の知識や数学の証明を文脈を自分で埋めながら読む技術が要求されます。と、いうのも、「事実」は書かれていても「証明」は省略されているんですから。後者ができるならプログラミングの知識はそれほど要らないと思います。
(3)
一部の章は非常に読みにくいと思います(一章とか)。評者の推測では、この読みにくさは直訳どころか逐語訳が行われていることに起因します。僕は「あ、ここはきっと"if and only if"を逐語訳したんだろうな」などと推測しながら読みました。日本語の文章を英語に置き換えて読むとわかりやすいと思います。訳が悪い章が最初に来ているので、最初だけ読んで挫折しないように注意してね。（ま2007 / 2006-04-27）

全てのプログラマーに、この本を推奨する。無条件に。無制限に。
この本に書かれているのは計算機上における数値表現、ビット表現、ごく初歩的な演算に関する徹底した検討だ。たとえば x&(-x) のようなものがごろごろと列挙されている。
ただし、そこには何をするものなのかは書かれているが、なぜ正しいのかはほとんど書かれていない。これを1つ1つ検討し、等価な方式を比較し、なぜ等価なのか考える。これが楽しいと判る人間にとって、この本は宝になるだろう。（fjの教祖様 / 2004-10-19）

　単純なビット演算のトピックス集と侮ること無かれ。
　コードから贅肉を殺ぎ落とす工夫、例えばビット演算をすることによってバッファ変数を用いずに入れ替え（C/C++では不可能だ！）、空いたレジスタに次の演算のための変数を読んでおくことが出来たなら、あるいは秒間数千回ものループのなかで条件分岐を一段削減できたなら・・・
　単純な処理であっても、大量のデータを前に真に効率がよいコードを書ける人は少ない。Cの汎用性に馴染んでCPUのマニュアルを見ないどころか、下手したら配列の添え字の割り当て方すら考えていない人のほうが多かったりする現状では、こういう本の存在は貴重で、読まないことは先人の業績に対する冒涜的ですらあろう。
　プログラマをアーキテクトに導く、貴重な知恵の宝庫だ。（ynar / 2004-12-12）

一見地味なタイトルで，良くありがちなゴシップ的な書籍かと思ったが，内容はまともでなかなかの良書である．専門家ならば嫌と言うほどご存じの「常識」が，一通り再確認されている．
例えば，現在無数にある「ソフトウエア開発方法論」や「設計手法」などのほとんど全てが眉唾ものと言って良い．誰でも高品質のソフトウエアが開発できる「ソフトウエアの品質管理手法」だとか，「画期的に生産性を向上させる」といったふれこみで登場するツール類なども，残念なことにほとんどは額面通りの効果は発揮しない．それは優れた開発者ならば経験的に知っているのだが，残念なことに技術を知らない経営者や中間管理職は裏付けのない言葉に踊らされるというのも良く聞く話である．他の業界なら管理できているものはソフトウエアでは管理できない．それは何故か？それはソフトウエア業界における品質管理技術が遅れているためでも，ソフトウエア開発者が品質に無頓着だからでもない．ソフトウエア開発は他の業界，例えばビル建設や家電の量産などとは全く異なる性質を持つためなのだ．全く異なる性質を持っているのだから，他の業界の手法が使えなくても当然だろう．
では一体ソフトウエア開発の性質とはどのようなものだろうか．それを55の真実と10の嘘としてまとめたのが本書である．ITを避けるわけにはいかない企業の経営者や管理職などは，是非一度この書物に目を通してもらいたい．何が事実で何が嘘か．これを知ることは今後ITを導入し活用していく上で，或いはアウトソース先と仕事を進める時などにも，この本は優れた道標となるだろう．（hesper / 2004-04-11）

～著者はソフトウェアに関する非常に多くの本を読み、また経験も豊富な方のようで、頷けるところが非常に多い。
経験上なんとなく感じていることが真実XXとしてまとめられており、なるほど、やはりそうなのか、と思うところが多い。
ソフトウェアに関係する人すべてにおすすめしたい。
ただ、実際にはこの真実に対してはこうすることで事態が改善される、と～～いうところまではかかれていません。(というよりも、昔からずっとある問題で解法がないものが多い)
読者が自分で解決法を自分なりに考える必要があります。
とりあえず、ウィーガーのピアレビューは読みたくなりました。～（nekot / 2004-12-25）

ソフトウェア開発をめぐる常識と常識になっているウソを
実務経験のある筆者の視点で解説した本。
賛否両論あるテーマに関しては、反論ものせてあるのがよい。
大抵はうまくいかない大規模システム開発のトラブルを
可能な限り避けるためのチェックに有効と思われる。
チェックしたらうまくいくというわけではないが、
成功の確立をあげるのには役に立つ。
最も重要なことは、ツールや技法ではなく
プログラマ自身であるという
真実１がすべてを物語っているという気がする。（i-職人 / 2004-05-31）

　この本のポイントは，２つ
・普通の、そして現場で働いている人が実際に感じるという意味で議論の価値がある問題を提起し、さらに非常に納得行く形で、問題を明文化していること
・ 問題に対する真実やウソの評価のための議論において、著者の意見の言いっぱなしジャーマンだけでなく、ソフトウェア工学の論文や過去の名著をきちんと参照していること。
　あなたがソフトウェアの開発に携わっている方なら、まずは，自分が感じる問題があるか眺めて見よう．必ず壷にはまる問題を見つけることが出来るはずだ。
　その次に本当にどう改善したいのかを考えた時に、この本を読み込もう。さらに議論を深めたいなら、この本が参照している論文や名著を探ろう。
　個人的に，もっとも影響を与えている本の一つ．お勧め．ついでに訳も最高に良くこなれている。（たかさ / 2005-11-26）

この本は、著者も賛同している「ソフトウェア201の鉄則」の
内容を参考にして書かれている部分が多数存在し、また、
「大事なのはツールや技法ではなくプログラマーの質」、
「遅れてるプロジェクトに人を入れるともっと遅れる」・・
など、プログラマーやSEなら同感される部分が多い。
「それでは自分にはどんな質が必要なのか?」って考えながら読むと、
最後まで興味が持続され面白く、読み続けられることが楽しい。
ただし、理想的な意見と反論は書かれてることは多いが、
実践するための具体的な方法まではあまり語られていない。
しかしながらそこは、「真実とウソを知り、SE・プログラマーが
自身で実践してみなさい。」
ということだろう。
なお、この書籍はこれからの開発と後輩への教育にかなり役立つ
書籍となるのは真実だと自負している。（ひげ / 2004-11-28）

　今まで、アルゴリズム関係の本をいろいろと読んできた。しかし、この本は何なんだろう。自分ではベストだと思っていたアルゴリズムが、かなりの確率で否定される。
　「これ以上は無理かな？」と思っていた巨匠アルゴリズム＋自己流アルゴリズムが、それ以上の高効率で処理されている。あるいは、「出来ないよ、そんなこと！」を「可能」にしている。まさに、「思い込み」は禁物だということを改めて感じさせてくれる、アルゴリズムにこだわる人には、まさに「目のウロコが落ちる」一冊。「速い」と「メモリを食う」は相反しないことに気づかされる。
　近年のコンピュータの高速化により、アルゴリズムの効率が無視されがちな企業プログラマには是非とも読んでいただきたい一冊。
　パズル的な面もあるので、アルゴリズムとパズルが好きな方は是非とも手に入れるべし!（ / ）

昨今のソフトウェア開発においては大抵がRDBMSベースのもので開発ツールも整っており、
アルゴリズムや計算量、メモリ使用量およびそれらの結果としてのパフォーマンスなどを
真剣に考えないと全く仕事にならないケースと言うのはあまり無いと思われ、それはそれで
幸せな時代とも言える。
本書はそんな「幸せな時代」に逆行する形となるが、上記で述べた内容（アルゴリズム、
計算量、メモリ使用量、パフォーマンス）をメインテーマとしており、それぞれ
1)提示された問題の解法を著者の視点で説明
2)ソースコードとして具現化
3)ソースコードについて更なる考察
4)同じテーマでの練習問題の提示
と言うスタイルで記されている。
特筆すべきなのは問題を解くにあたって筆者が最終的なソースコードにたどり着くまでの
「思考」（いわゆる設計作業）が文章や擬似コードや図表で表現されている事である。
他のアルゴリズム関連の書籍では大抵いきなり完成形のコードが出てきてそれらを説明して
終わりと言うパターンが多く、それではただの丸暗記であり、初級プログラマにとって
本当の意味でのトレーニングにはならないと思う。
個人的な見解だが特に初級プログラマのステップアップの壁に一つには「設計と言う概念の
理解」が挙げられると思っており、本書はそんな概念を掴みきれていない初級プログラマにとって
あぁ、プログラマの頭の中ってこんな風に試行錯誤しながらコードを紡ぎだすんだ！
と言う感覚が味わってもらえるような造りとなっており、非常に好感が持てる。
練習問題が結構多いので勉強会のネタにも使えそうである。
理解しながら読み進めるのは意外と大変かもしれないが読み終えた時にあなたは
一皮むけたプログラマになっているはずである。（コモヒコ / 2007-04-02）

この本は、プログラミング言語を学ぶという本ではなく、どのようにしてアプローチをしていくかという本です。たとえば、ある著名人は、よいプログラマーとは、机上でまず詳細設計を完璧にするものだといっていましたが、まさにその通りのことが書いてあります。
いきなりプログラムを書くのではなく、色々なアプローチからプログラムの骨格を作り上げていくことが出来る一冊です。
中堅プログラマーの方が、上級プログラマーになるためには必須の本だと思います。私のバイブルでもあります。（densuke / 2003-04-17）

コンピュータ・プログラムに手を初めて２０年近くなる。最初の２，３年は先輩が色々手解きをしてくれたのだが、答えられない内容にまで掘り下げて質問すると別の仕事を与えられたものだった。４，５年で自立すると立場が逆転した。過去に苦い経験をもつ私としては、常に最新の情報や考え方、パラダイムの転換といった、この職に不可欠な知識（知恵）を探求し後輩達に伝授していったつもりである。１０年も過ぎるとリッパなシニア・プログラマ（エンジニア）となる。それまでに獲得した知識を最大限に活用して仕事をこなしていく。が、ここ数年マンネリした技術に嫌気がさしていた時に、この１冊に巡り合った。プログラミングに携わる人には座右の書となるであろう。久しぶりに良い師匠に出会えた。わかる人にはわかる本である。初心者には敷居が高いかもしれないが丁寧に解説されているのできっと（数年後でも）役にたつはずである。技術的なことだけでなく、日々精進の仕方まで何気なく書かれている。著者にあってみたくなること請け合いだ。（ / 2001-06-14）

今までいろいろなアルゴリズムの本を見てきましたが、
ほとんどが理論的であり、眠気を誘うものばかりでした。
この本は、アルゴリズムが何であるか？データ構造とは？を
根本から解説しているのですが、プログラマであれば、
非常に興味をそそられる内容になっています。
サンプルプログラム等は、CやC++で書かれていますが、
他の言語しか知らなくても十分理解できるレベルです。
参考本情報が豊富にありますし、少しずつ読んで見ようと思います。（李牧 / 2004-05-02）

私が20代半ばで本書を買ったときには，本書の内容は全然ピンと来ませんでした。それから約10年が過ぎ，第一線の技術者としては先が知れてきて，周囲からはリーダーとしての役割を求められ，自分でもそう志向し始めた時，本書を読み返しました。そして，書いてあることひとつひとつに胸を刺されました。
技術屋はいつまでも第一線に留まりたがり，マネージャになるという「ダークサイドに堕ちる」ことを嫌がります。本書はそのことが本当はどういうことなのかを解き明かし，失うものなど本当はないのだとわからせてくれます。そして自分に気づき，人を動機付け，チームを大きな技術的成功に導くためのやり方を示してくれます。
「誇り高い技術屋」には，世にあふれるリーダシップ本やコーチング本よりも，まず本書を読むことを強く強く勧めます。（kasm / 2002-07-25）

技術者からマネージャーという立場になっていく過程(およそ３０から４０代)で読んでおきたい本。
実は１０年以上前、学生のときに購入してみたがその当時はさっぱりよくわからなかった。そのとき買った本は無くしてしまい、自分がそのような立場に立たされてきていると感じ新しく購入して読んでみた。
やはり、今読んでみて正解だった。いろいろと考えさせられることがあった。各章末の設問はまだやってないが、復習の意味でもう一度読んでみたいので、そのときはやってみたい。
どっちが先かは忘れたが、学生のとき同じく読んだデール・カーネギー著の「人を動かす」は無くさなかった。この本は、技術者にとってではなくどんな人にでも普遍的に読んでおきたい。（ / ）

「リーダーシップって本読んで身につけられるものなのか？」
「確かな技術を身につける以外に、技術者に必要なものってあるの？」
「なんで俺はリーダーに指名してもらえないんだ？」
こんな疑問に答えてくれるのが本書です。
まず、グループで問題に取り組むことの意味を論じ、リーダーシップのあり方について、読者の視野を広げてくれます。次に、自分の個性にあったリーダーシップをどうやって発揮するか、その具体策を提示します。最後には技術とリーダーシップを実践の場でどうやって伸ばして行くかを明らかにします。
原題は"Becoming a Technical Leader: An Organic Problem-Solving Approach"。訳書の題名にある「スーパーエンジニア」とは、グループで問題を解決する能力の非常に高い技術者、という意味で使われているようです。（ / 2003-05-09）

各自が、それぞれの立場でリーダーシップを発揮し、
変革を推し進めていくという考えは、
学習する組織の考え方とも通じるものもあり、
今よんでも、古さを感じさせないのは、流石、という感じです。
スーパーな技術リーダーになるための安易なハウツー本ではなく、
具体的に、どうしたら良いのかは、各自、自分の状況に応じて、
自分の頭で考えなければならないため、やや、ハードルが高いですが、
逆に考えれば、色々な読み方ができるので、手元に置いておき、
時々、読み返してみると、きっと、得られるものがあると思います。（palemoon / 2005-09-16）

システム開発の現場でマネージャーが、いかにリーダーシップを発揮すべきかを説いた著作。各章末にベテランのコンサルタントらしい「うーん」と悩むひねった設問（時折禅問答）が多数あり、読み応えがあります。リーダーシップ、コーチングという観点からは、近年発刊されているベストセラーよりもシステム開発の現場に即しており、エンジニアを職業とした人ならば学ぶところの多い一冊です。
僕は20歳前後の文学青年兼アマチュアプログラマーだった頃に神保町の古書店で購入して以来、時折読み返しています。
その時折の自分の役割に応じて毎回違った事を学んでいます。
アマチュアのときには、鋭い心理洞察に「にやり」としながら、その職業の面白さ奥深さを。
下流工程のプログラマーだった頃には、いかにチームと調和し、リーダーをサポートしていくか。
上流工程のリーダーになったときには、いかにチームを作り上げ、マネージャーや顧客との調整を乗り越えるか。
マネージャーとなってからは、モチベーションの高い成長するチームをいかに築き、社内政治から守るか。
起業して社長業を営むようになってからは、エンジニアを超えた自分自身の役割をいかに再定義すべきか。
エンジニアとしての道を歩む人の道しるべとして、座右に備えておきたい一冊です。（ozakih / 2009-09-14）

要求仕様について合意するための具体的な方策が体系的に列記されている。
ワインバーグの書籍では、一番何度も読み返して利用している本である。
実際に経験したこと、実際に思い当たることなどが、沢山書かれていて共感できる。
要求仕様を明確にせずに、後で手直しについて騒いでいる人達が、何故この本を読まないか不思議である。手直しが儲け頭なので、要求仕様を明確にするとお金にならないということなのでしょうか？
（kaizen / 2008-07-08）

ソフトウェア開発で収入を得ている全ての人に本書を勧めます。一概にソフトウェア開発と言っても、プログラム経験が無いに等しい方から開発ソフトウェアの全体像を知らないままプログラムを作成する方々まで、多岐に渡る範疇を含みます。そして、ソフトウェア開発中には必ずと言って良いほど、作業手戻りや抜けなど発生します。この根本原因についての検討を本書では行われています。内容構成としては、S/Wに対する要求分析と開発の進め方をシミュレートして、我々に身近な問題点を洗い出していくものです。（ / 2000-12-01）

その名の通り要件定義フェーズの為の本である。示唆に富んだ内容を「保証印ゴキブリ退治器」、「収束設計プロセスセミナー」などの比喩を使って面白く書いてくれていてとても読みやすくなっている。
　要件定義フェーズをあつかった本は、"いかに曖昧さを減少させるか"、"いかにユーザーニーズをコントロールするか" といった収束手法に傾倒しがちなものが多い中、"いかに関係者のアイデアを引き出すか"、"いかにユーザーの満足度を高めていくか"、などニーズ生成手法にも力を入れている。その根底には、"ユーザーの満足度＝プロジェクトの成功尺度"という当たり前だが軽視しがちな基本がしっかりと根付いている印象を受けた。
　要件定義の初め方から終わり方まで抑えるべきポイントを具体例をもって示してくれていて新しい発見もあったし、参考にもなった。ただアプローチの具体例はいかにもアングロサクソン的なものが多く、日本的なアプローチへのアレンジは要りそうだ。（dat247 / 2002-05-23）

本書のよいところは、アオキさんのレビューに尽くされています。非常に多くの研修機関や大学の情報系学科で推奨されてもいます。でもなぜか、持っている人が少ないようだ。考えてみたら、本書の前提として、ソフトウェア工学、特に要件工学を、それなりにわかっている必要がありそうです。Wieger "Software Requirement" MicrosoftPress,や　Alan Davis "Software Requirement" Prentice Hall　あたりを押さえておくと、この本の本当のおもしろさがよくわかります。（ / 2002-03-01）

気楽に面白くよめる。ワインバーグだからね。
若いエンジニアだったら予習になり、ベテランだったら自分も同じような経験をしたねと楽しくよめるでしょう。
品質管理の仕事をしている人はよむといいね。品質のもつ意味が違って見えてくるでしょう。
比較的、価格も高いが、名人の話を聞くと考えれば、安いものですよ。（アマ・チュア / 2006-05-17）

とにかく翻訳（日本語）のひどさに苦労させられました．もしかしたら元の英文を読んだ方が正確に理解できたかもしれないし，フラストレーションも少なかったかもしれない．社内の勉強会の準備のために訳書を読んだが，この翻訳の質なら原文をじっくり読んだ方が得られるものが多いと思う．せっかく原文がしっかりした内容なので，翻訳者にはもっと英語の分かっている人を選ぶべきではないでしょうか（技術的知識は当然のこととして）．（ / ）

TDDの手順が、プログラマの思考過程を含めてシナリオチックに、じつに事細かに書かれており、これだけでも本書の価値はある。アジャイルのような従来のプロセスからはかなり異質なものに初めて取り組む時、誰かの思考過程をそのままなぞることができれば、その第一歩としてはこれ以上のものはないだろう。あとは応用するだけだ。
ただし、言語も複数登場するし、特定のツールの使い方が説明されているわけではないので、ハウツー的な要素は薄い。実際に適用するときは、利用するxUnitの解説や、特有ツールの運用を含めた別のドキュメントが必要になるかもしれない。
それにしても、XP関連書籍の例に漏れず、翻訳の質がひどい。日本語のレベルでどうにかしてもらいたい箇所が無数にある。（ただただし / 2004-08-14）

非常にまわりくどい表現が多い。Kent Beckの性質だろうか。
例でもってテスト駆動開発を実演する部分の「くどさ」と「屈折」は置いておくとしても、パターンの部はで明快にはっきりといいたいことを表現してほしかった。
パターンの部は、デザインパターン・リファクタリングの基本的な知識があることを前提として書かかれているようである。
また、パターンの部は、デザインパターンの書式に準拠していない。
ある程度の設計・実装する力があると何か得るものがある書物と思う。
Kent Beckの表現に問題があるとしても、翻訳の質はひどい。（ / ）

ケントベックの文章は、回りくどい表現を多用するといった特徴から翻訳しにくいというのは自分も実感しているが、それを考慮しても本書の翻訳はひどい。
文法の整合性が取れていない箇所や、文と文のつながりを完全に無視して翻訳している箇所など、日本語としておかしい所がかなり目立つ。
翻訳者の長瀬嘉秀氏は、XPやagileの形を定義づける貴重な名著群の価値を、片っ端から劣悪な翻訳で貶めていることを自覚してほしい。（hirokawa / 2009-07-11）

本書は「こうすれば良い」といった啓蒙ではなく、具体例を挙げ「この場合はこうした」といった事が書かれているため、直ぐに読めてかつ身に付く実践の書。
例えば「完全に合理的な設計が結局は誤りだった」といった言葉で表されるように、TDDの効き目を実感できる。
従来の考え方をがらりと変えざるを得ない良書である。
ベテランも初心者(には少々難しいか...)もぜひ読んで実践しよう。
オススメ。（Tokyo Disney ... 関係ではありません / 2003-09-05）

この本はテスティングに関する論文で一番引用されているものだと思う。White boxテスティングを勉強するには非常に優れた一冊である。ただWhite box的テストのアプローチを説明しているので、PCのGUIのソフトをブラックボックス的アプローチでテストしたいという人には向かない。最低限コードを書ける人でないと理解は難しい本でもある。（高橋寿太郎 / 2001-04-16）

P8「一般にはテストはデバッグの後に行うが」という記述があって驚いた。
自分の知っている開発では、デバッグの後にテストを行っている場合があるためです。
ハードウェアにべたべたなソフトウェアでは、テストをやろうにも、デバッグしていないとテストが通らないので、デバッグして、かろうじてでも動く状態になって始めてテストに係ります。
何のテストをしようとしているのか。テストを支える土台がある上でのテストであれば、テストをして、バグを見つけ、そのバグを取る作業をデバッグと呼ぶのかもしれません。
動かないソフトウェアの場合には、動かすためのバグ取りをした後でないと、テストができないことがあります。
P8「デバッグは未知の初期条件で始めることが多く」とありますが、デバッグは特定の初期条件でしか始められません。未知の初期条件で始めるためには、デバッグが済んだ後のテストの段階で、未知の初期条件でも動くかどうかをテストするのではないでしょうか。
P9「テストの設計と実行については、かなり自動化されているが、デバッグについては、まだ夢の段階である」というのは同感です。
（kaizen / 2008-07-08）

　ホワイトボックステストに関して、バイザー先生の
この本を読まずして、プロの間でまともな会話は成立
しないんじゃないでしょうか？
　ブラックボックステストに関しては、同じくバイザー
先生の手になる「実践的プログラムテスト入門―ソフ
トウェアのブラックボックステスト」がおすすめです。
　この２冊に書かれていることを理解せずして、ソフ
トウェア技術者を名乗ることは、ちょっと勘弁して欲
しいというくらい、基本中の基本の書籍だと思いま
す。（こーたろ / 2005-03-21）

各所に散りばめられた皮肉やくすぐりが、密かに面白い。
苦笑すること度々、訳者にも感謝。（tanabe / 2009-02-27）

この本は私がテスト関係の業務について一番に読んだ本です。
姉妹本の　「実践的プログラムテスト入門―ソフトウェアのブラックボックステスト ボーリス・バイザー著 」といっしょに読まれる事をお勧めします。
私がテスト関係の業務をしたころはこの本しか見つける事ができませんでしたが、今はテスト本はたくさん出版されています。この本は分厚い本で読むのが大変ですが、テスト技術者になるにはこの本は最低でも読んでいただきたいと思います。　ソフトウェアテストのバイブル的な本です。（naka / 2008-05-23）

他の方もおっしゃっていますが、１～３章までは必読ですが
時間のない人は辞書的にも使えると思います。
ただ、すべてを一読しておくと、明日行うコーディング等にも
役立つ情報が多々ありますので、ぜひ一読することをお勧めします。
目から鱗が落ちるようなサンプルの宝庫です。（森　博之 / 2004-11-27）

この本は著者のXPでのリファクタリングの経験をカタログ形式でまとめたもので、ソフトウェアを少しずつ日々改善し、ソフトウェアが肥大化が修正を困難にしないようにする小さな手法の集まりを紹介しています。ソフトウェアの構造に日々手を加える(部分的な再設計の)ための、問題点の発見の仕方、直し方がカタログ化されています。
書いてあることの個々の内容は比較的単純なものばかりですが、まずい設計が示唆する問題点、改善による効果、リファクタリングが可能な条件、リファクタリング時に見落としがちな点の指摘などが十分に書かれていて、リスクと効果をよく考えながらリファクタリングが出来るようによく配慮された内容になっています。プログラミング初級者にとって、とても勉強になる内容だと思いますが、経験を積んだプログラマにも日々のプログラミングのチェックリストとして非常に役に立つのではないかと思います。
JAVAでかかれているため、C++を使っている人には多少違和感がありそうですが、.NETプログラミングにはうってつけの内容だと思います。（中村拓男 / 2002-11-10）

達人プログラマ、ソフトウェア職人気質も読みました（ただの流行り好きですね・・・）が前二書がメンタルな部分が多いのに対し、この本は非常に実践的です。
5章まででリファクタリングの意味を知り、後はリファレンス的に手元に置いておきたい本です。サンプルコードが多く明快な解説がされているので詰まったときに調べるのに最適だと思われます。（木下牛 / 2003-04-10）

リファクタリングの技法が非常にいっぱいつまっていてとても役立ちます。
通して読むのは1章から3章くらいまでで、後は辞書引きの方が良いでしょう。
1章から3章までのswitch文をStrategyパターンにもっていくやり方はぜひ身に付けて下さい。
リファクタリングも繰り返し行っていけば、不吉な匂いがするコードを書く前に気づき直すこともできるようになると思います。
直接生産性に影響する技術ではありませんが、保守がしやすく、すっきりとしたコードを書けるようになるので1度読んでみることをお薦めします。（貨物列車を止めた男 / 2004-10-19）

リファクタリングするための個々のテクニックのカタログを説明する
前に、それらを適用するストーリーを例示する章がまず最初に用意さ
れています。そのため、第１章さえ読めばやりたいことの本質が会得
できるので、非常にストレスなく読めます。（この構成は、ＧＯＦの
デザインパターンや、ランダル・L. シュワルツ の「初めてのPerl」
に共通する方法です）
導入の章さえ読めば、個々のリファクタリング技法の節を１節ずつ電
車の中、空き時間等に少しずつ読んでいくことができます。途中の節
から気軽に再開できるので、忙しくて読めない時期があっても最初か
ら読み直しにならない所が嬉しいです。
順番によまずとも拾い読みでも構わないし、もっと言えばカタログだ
から全部読破しなくてもいい、と割り切れるのがいい所です。なんと
なく持ち運んでいつのまにか、読み終わってしまいました。
ファウラーの本の中では、アナリシスパターン（挫折しました）、
ＵＭＬモデリングのエッセンス（若干難しかった）と比べて、
極めて読みやすく買って無駄になることがない本だと思います。（悩み多き頭でっかち / 2002-11-17）

　仕事で行うプレゼンテーションで使うアイデアを探そうと思い、10年ぶりに、さーっと目を通して見ました。すると、主要な法則は太字で書かれていて、タイトルを読んだだけでなんのことかすぐに思い出すことができました。実際に、日々の仕事の中でこれらの法則を使っていることにあらためて気づきました。また、自分で大切だと思った部分には、鉛筆で線が引かれており、そこだけ拾って読むだけでも再度勉強できた気になりました。そうやって時々読み返してみたい本です。
　自分自身でも様々な経験や感動を「ＸＸの法則」と名づけて記録する癖がついています。ものごとの本質がどこにあるのか、少し冷静になって考えると、直感とは違う法則が潜んでいることに気づきます。
　たとえば、仲間内で作った法則に「3択の法則」というのがあります。人は、3択で選択肢を見せられるとついついその中から選んでしまう、というものです。つまり、一つしか選択肢がないと、もっと多くの（つまり無限の）選択肢を要求したくなるものですが、最初に3択を見せられるとそこで展開された問題空間の範囲で考えてしまうようになるのではないかということです。そういったアイデアを共有し、発展させられるように意識してなったことが、この本から得た最大の収穫かもしれません。 （jimmy / 2002-09-23）

表紙はあまり趣味が良くないが中身は抜群に良書。
笑い話を読ませて法則を導き出す手口は見事。物の見方を磨くと同時に話術も磨ける。いままで何度読み返したかわからないが、そのたびに得るものがある。寝床に一冊、書斎に一冊と二冊持っている。
この本のさらなる使い方には法則の例を自分で見つけて書き込んだり、
自分で新しい法則を作るというやり方もある。
「（増補版）コンサルタントの秘密」を自分で作るのだ。
自分で思い付いたときにノートに書き溜めているが漠然と読むより
理解が深まり、洞察力も上がってきたと思う。（ / 2002-11-20）

本書は、コンサルティングに従事している方や、コンサルタントになりたいと思っている方、コンサルティングに興味を持っている人には強く勧めたい本のひとつです。しかし、たとえコンサルタントでなくても、技術的な仕事に携わっていなくても、この本は多くの意味において有用です。あまりにその意味合いが多すぎるので、ここにいちいち書くことができないほどです。他人と付き合いながら社会で生きていくときに必要なこと（役に立つこと）一般が、この本の主題だと言っても過言ではないと思います。末永く読み返したい本。（鈴木純一 / 2002-05-22）

本書はタイトルは、あまりそそらないモノですが、中身はスゴいです。著者がコンサルタントとして数多くの現場で習得した知識が、高い密度で盛り込まれているのがひしひしと感じます。
何気なくページをめくるだけでも、
・「問題を解決出来る見込みは、問題を起こしたのは誰なのか見つけ出そうとする立場に近づけば近づくほど減少する
・「もし彼らがこれまでしてきた事が問題を解決しなかったのなら、何か違う事をするように勧めるがよい」
・「知らなくても怪我をするとは限らないが、思い出さないとすれば間違いなくやられる」
など、コンサルタントとして働いた事がある人なら誰でも、「なるほど！」と頷いてしまうような金言が満載しています。
しかし、著者のアドバイスは、コンサルタント業界にのみ有効なのでなく、あらゆるビジネスパーソンにとって有益である事が本書を読み終わると感じる事でしょう。
（jiateng4 / 2008-04-29）

「コンサルタント」という気の利いた肩書きを持っていなくとも、問題を発見しなければならない、という場面はよくあることだろう。
そして厄介だけれども、その解決を要求される人はたくさんいるんじゃないかと思う。
そんな人であれば、是非とも読んで欲しい。
エピソードはどれもわかり易く面白い。そして、そこから導かれる数多の法則はどれもが本質を捉えた「知恵」と言える。
一気に読んでも面白いけれど、気が向いた時にちょっとずつ、何度でも読み返すのが良い。その都度に発見することがあるはず。（茶飲 / 2002-12-10）

私は”コンサルタントの秘密”という書籍を知らなかった。
ある日本屋を歩いているとこの”コンサルタントの道具箱”という書籍に出会い、手にとってみた。
立ち読みを開始して1分経過した時、「読む価値のないものは、読むな」というレヴィングスの読書の法則を目にした。
「これだ！！」と直感し、即座に購入し、1日で通読してしまった。
「成功法則」を論じた書籍は多いが、この本はそれらの多くの書籍とは
一線を画している。
まず、法則名がおもしろい。「ラズベリージャムの法則」があったかと
思えば「ブドーゼリーの法則」がある。小さな子供であっても、この書籍を抵抗無く読めるであろう。「成功には・・・が必要だ！！！」といったように強い調子で書かれていないため、すっと頭に入る。
次に、著者が人生を通じて会ったいろいろな人物から学んだことを道具としてまとめているため、具体例と法則（道具）が実にマッチしている。「・・・である。例えば・・・。」といったようなお決まりのパターンではなく、ストーリー性をきちんと持った書籍である。
最後に、読んだその日からこれらの道具を読者は試すことができる。私は毎日1つずつ試すのがおもしろくてたまらない。
このような名著に出会えたことを幸いに思う。（サッティー / 2003-08-21）

　今までのワインバーグの本とは視点が違うと感じましたが、大変面白いことには変わりがありません。今までの本は読んだ瞬間に目から鱗が取れた気がして翌日から即戦力になる法則が満載でした。特に「コンサルタントの秘密」は最高だと今でも思います。
　今回の「コンサルタントの道具箱」は法則を教えるというよりは、元々私達の中にある良い部分を思い出させるための具体的な１６個のメタファー（暗喩）を提示してくれます。まだ２回読んだだけですので全部に共感出来たわけではありませんが、半分程度は理解し、４つは実際に使っています。「金の鍵」はコンサルタントでなくとも人生を前向きに生きる為に必須ですし「イエス・ノーのメダル」は良い仕事をするためには忘れてはならないものです。
　他人から人生相談を受けた時、相手の良い部分を思い出してもらうためにはこれらの道具は即戦力として使えるでしょう。コンサルは極めるとカウンセラーになるのかも知れません。（hat / 2004-01-17）

前作の副題が「技術アドバイスの人間学」だったのに対して、本作は「勇気と自信がもてる16の秘密」である。
これらの副題は、各々の書物の性格を、なかなか的確にあらわしている。
本作では、人生において活用できる16のリソース、つまり「道具箱」を、ユーモアに満ちた的確な法則で、喚起してくれる。
16の道具箱のイメージを想起し、それを活用している自分の姿を思い浮かべることは、自分の中のリソースを活用する助けになるだろう。
心理カウンセラーの方は、こうした道具箱のイメージを、クライアントを勇気づけるのにも、使えるのではないか。
こうした意味で、本作では、前作よりも、少し優しくなったワインバーグ氏の姿がある。（ekusuyono / 2003-08-29）

ワインバーグは、ソフトウエアシステムのコンサルタントだけれど、この本の内容は、ソフトウエア関係の仕事をしていない人にも役立つ。人に共通の思いこみや、性癖や、それに対応する方法が、具体的に楽しんで書いてあるからである。あらゆる仕事と、仕事を離れた家庭や人間関係でも通じる内容である。ソフトウエア開発といえど、人間の生業だから、あたりまえ、ということだろうが。
内容は、納得できるものばかりの考える道具箱。おすすめです（osm10 / 2005-06-04）

本書はコンサルティングを行うにあたって、どのような思想を持つことが望ましいかを説明している。一見、平易な言葉で書かれているように思われるが、理解するには何度か読み返す必要がある。また、理解した後、必要なときにその「道具」を使うことが出来るかが問題である。正直、今の私には難しかった。（tagachil / 2004-04-03）

８冊のうち、
マコネル　「コードコンプリート」
は別格だと思う。これは、プログラマのための本だ。
ワインバーグ　「プログラミングの心理学」
ブルックス　「人月の神話」
デマルコ。リスター　「ピープルウェア」
デマルコ　「デッドライン」
ハント、トーマス　「達人プログラマー」
マクブリーン　「ソフトウェア職人気質」
カーニハン　「プログラミング作法」
の７冊は、やや管理的な面もある。
本書を読むよりは、８冊とも読んだ方がよいのは、書評本の常ではないでしょうか？
書評者に同調できる人もいれば、疑問に思う人もいるかもしれない。
私は、
マコネル　「コードコンプリート」
ブルックス　「人月の神話」
ハント、トーマス　「達人プログラマー」
マクブリーン　「ソフトウェア職人気質」
の４冊は進めるが、他の４冊を読むよりは、もっとCPU,コンパイラ、OS、ネットワークの本を薦める。（kaizen / 2009-04-23）

この本がレビューしている8冊の本は、プログラミング書学者がプログラマとしての所作、行動、考え方を身につけるために読むべき本が選ばれていると思う。
この本の中では8冊の書籍、「プログラミングの心理学」・「人月の神話」・「ピープルウェア」・「デッドライン」・「ソフトウェア職人気質」・「達人プログラマー」・「コードコンプリート」・「プログラミング作法」を商標しており、基本的にはソフトウェアピープルの書評記事が元になっている。ただし、書評といっても、内容の解説と言うよりは、筆者の経験談や考え方が各書籍の解説に加えられ、通して質のいいプログラマーへの啓蒙書になっており、当然この本を入り口に各書籍を読み込んでいくことが重要であることは言うまでもないことだが、この本を読むだけでも十分な価値があると思う。（ishisaka / 2006-08-13）

　ソフトウェアエンジニアとはどうあるべきか？その答えの入り口を教えてくれる１冊です。
　入り口から中に入るため以下の名著８冊を紹介しています。
「プログラミングの心理学」
「人月の神話」
「ピープルウェア」
「デッドライン」
「ソフトウェア職人気質」
「達人プログラマー」
「コードコンプリート」
「プログラミング作法」
　ソフトウェアエンジニアだけでなくソフト開発に携わる管理者、
経営者の方にも是非よんでもらいたいです。
（なか / 2007-02-05）

本書で紹介されている８冊の「名著」は、
２、３０年も昔に出版され、今なお読み継がれる古典であり、
そこでなされる問題提起が、今なお問題であり続けることに、
筆者は慨嘆しています。
しかし、その慨嘆の意味するところは、
これら古典作品の効用が、
しょせん、机上の空論に過ぎなかったという裏付けにならないだろうか。
問題提起そのものには十分に価値があるが、
対策や方法論としては現実離れしている。
たとえば、日本中の全ての信号が、常に青であれば、
ドライブは快適になるだろうか。
「名著」８冊を賞賛するよりも、これらを批判的に読み返し、
先達が押さえ切れなかった新たな切り口を模索すべきだろう。
（たけぞう / 2007-06-16）

ソフトウェア開発に関する名著 8 冊を紹介している．この本を読んでもこれらの本のエッセンスがわかるという虫のいいはなしはないだろう．しかし，この本を読むことによってもとの本のうちの 1 冊でも読む気になれば，収穫があったというべきだろう．私のばあいは「ソフトウェア職人気質」を読みたいという気になった．
（Kana / 2009-12-01）

何かの材料を基に論述するというよりは、日ごろ感じていたことを纏め
てみたというエッセイに近い。
「どうすればいいか」という方策を具体的に語っているよりは、こうい
う人・考え方のほうがよいと思いますよ、といったトーンで書かれてい
る。多分、読者の皆さんにそれぞれ考えてほしいということなのだろ
う。書いてあることは至極ごもっともなことばかり。小難しいことが書
かれているわけでもなく、「新書」という媒体にふさわしい内容かと。（エパメイノンダス / 2006-04-04）

タイトルに惹かれて、つい買ってしまいましたが、私にとっては無意味な本でした。
・間違ったことは書いている訳ではないですが、通常の自己啓発本に書いてある範囲を超えていません。
・しかも、話が具体的でなく、教訓が羅列しているだけなので面白くない。せっかくコンサルをやってらっしゃるのだから、現場の具体例をたくさん交えて教訓を書けばよいのにと思いました。
・あと、ネガティブな話が多いので、ちょっとうんざりします。おそらく、現場で嫌な顧客とつきあうことが多かったのかもしれませんが、「〜な人がいかにダメか」という話が続くと読んでいるほうもネガティブな気分になります。（eihr / 2006-06-26）

思うように伸びない人は自意識過剰で、他人との比較によって自分の存在価値を求めようとする人。年功序列に信頼を置いている。伸びる人はその逆で、自分自身のことが好きで素直で真面目な人。そいう人は他人との比較で存在価値を見出す必要もないし、成果主義でもコツコツと自分を磨くことができる人。
要はプライドを過剰に評価したり過小評価したりせずに、ありのままの自分を受け入れることができる人が伸びる人。
といったことが書いてあります。目からウロコが落ちました。
また、ソフトウェアのある一部分だけにこだわりすぎる人、目的意識の乏しい人はスキルに伸び悩み、その逆の人は確実に伸びていくそうです。
言われてみれば確かにそうですよね。。。
単にソフトウェア開発だけに限らず、自分の人生の指針を考えさせてくれる本です。学歴高いんだけどプライドが高すぎて、仕事が伸び悩んでいるよなぁー。。。と悩む人には必携の書。
（ぴのき堂 / 2006-04-02）

本書で取り上げている「伸びる人伸びない人」とは結局のところ、その人の資質に依存するのだと感じました。実際に、目的や使命感、責任感のある人と、給料をもらうために何となく開発している人の差は日常でも強く感じられます。本書を読めば、その辺の見極め方が良く分かります。欲を言えば、「伸びない人」を「伸びる人」にする方法などがあれば良いと思いました。全体的に「伸びる人」は勝手に伸びていくし、「伸びない人」は、どんなにしても伸びないという感触を得ましたが、分析からもう一歩踏み込んだ、次の手みたいなものを期待したい。
（Yoshi / 2006-03-13）

ソフトウェア業界で生きていく事に思い悩んだ時に、たまたま本書に出会いましたが、
少し救われたように思います。
ソフトウェア技術者は「サラリーマンではない」ということに共感を覚えました。
「楽しい仕事」とは会社から与えられるものではなく、自分で「仕事を楽しくする」
ものであることがわかりました。
ソフトウェア業界は華々しいように思われがちですが、中はかなりハードな職業です。
それでもこの業界で生きていこうと考えている方、または迷っている方は、本書を
読んでみてはと思います。（tagachil / 2007-01-27）

あなたにとって美しいコードとはなんですか？汎用性、巧妙さ、統一性など人それぞれの観点があると思います。この本では偉大なプログラマと言われている方々が考える美しさが語られています。自分が今まで知らなかった美しさが必ずあります。なにせ33人もの偉人が書いているのですから。
「美しいコード？何それ？」という方はとりあえず、なか！見検索の抜粋を読んでみてください。美しいコードの一端がわかると思います。
この本の唯一の問題点は、各著者が自分の好きなプログラミング言語で美しさを語っているため、コードが理解しにくいことがあるということです。
（さわだ / 2008-09-05）

まだ冒頭の２話しか読んでないのですが、そんなにいいコードかな、と思いました。
初っ端の正規表現の超短いコードは、実装が簡単になるようなサブセットを勝手に決めていて、学生向けの教材に、そんな特殊解を紹介してどうする、と思いました。正規表現→NFA→DFAと変換する処理系の方が、ずっと基礎力がつくと思います。
まあ、カーニハンが書いているから、みんな読むんだろうけど。C言語のポインタのセマンティクスをうまく引き出したことに、盛り上がりすぎです。
二つ目のsubversionのツリー差分反映のコールバックインタフェースは、コンテキストを表現したオブジェクトの引き継ぎが美しい、と言っているけど、オブジェクト指向プログラミングしたら、普通に思いつくことじゃないかなと思いました。少なくとも、私は２０台の時にやりましたよ。
ま、この先、どんなものが出てくるのか、楽しみにしながら読んでみます。
おおこれはすごい、と思えるものが出てくるとよいですが。。
いやな本ではないですよ、決して。（hideo-t / 2008-12-07）

泥沼に陥ってるプロジェクトに所属する開発者も、デスマーチになりそうな不安があるプロジェクトに入りそうな開発者も、プロジェクトも順調でお客様との関係が良好な開発者も読んでおいて損はない良書である。
なぜなら、これからの開発者としての取り組み方を考える「MYJOB WENT TO INDIA」や、仕事そのものに対するプロセス改善の指針となる「エンジニアのための時間管理術」、今時のプロジェクトノウハウを詰め込んだ「ShipIt!」等を串刺しにしてプロジェクトの改善というものへの取り組み方を示した本だからということが理由である。
とりあえず、今の仕事に不安な部分がある開発者はこの本を読んでできそうなプラクティスからやらせてくれと言ってみることだ。自分のプロジェクトがアジャイルだとかウォーターフォールだとかは関係ない。仕事場でアジャイルというのが恥ずかしいなら「改善提案」だとか「見える化」とか言語替えしてもいい、今あるものをお客様に動かしてみてもらってもいい、朝ミーティングをやりましょうと言ってみてもいい。必ず何らかのフィードバックが得られてそこから改善が始めることができる。
この本を読むことでプロジェクトを成功に近づける/遠ざける手段を学ぶことができるはずだ。何をすればいいのかさっぱりわからないという人には最初の一歩になるはずだし、いくつかはすでに実践しているという人にはさらなる一歩になると私は思う。
（hsbt / 2007-12-28）

ソフトウェア開発の良い習慣について、コンパクトにまとめられています．
１つ１つの習慣の説明の中で「悪魔の囁き」「天使の助言」を使って、開発者の内面にも触れています．
好きな天使の助言を３つだけ上げるなら
* 批判するならアイデアにしなさい、人ではなく
* 自働化されたユニットテストを習慣にしなさい
* スタンドアップミーティングをしなさい
タイトルに「アジャイル」と付いていますが、アジャイルに全く興味がないディベロッパ、マネージャにも役立つ１冊になっています．
この本を通じて、ソフトウェア開発の現場に良い習慣が広まって行くことを願っています．
（hau01 / 2008-01-12）

このシリーズの、まるでソフトウェア開発専用であるかのような扱いは、もったいない。およそ「プロジェクト」と名のつく仕事に携わる人はいっぺん読んでみるといいと思う。
アジャイル開発手法が正しいと証明した人はまだいないし、おそらくそれは不可能だ。一方、社会システムの多くが非アジャイルで開発されていて、まがりなりにもうまく動いているわけで、アジャイル陣営は「こっちのやり方でもうまくいく」という事例を積み上げていくしかない。
中でも本書のように「アジャイルの現場の匂い」のようなものを扱った書籍は、実際に自分のプロジェクトにアジャイル開発手法を導入してはみたものの、うまくいっているのか自信が持てないような場合にかなり役立つだろう。
本書では各章の冒頭に、開発者を誘惑する「悪魔の囁き」があり、自分のプロジェクトが「きな臭い」方向に彷徨い始めているのを知るシグナルになっている。一方、各章の終わりには「天使の導き」と、プロジェクトが満たされているべき「香ばしいフレイバー」とも言える「こんな気分」という一節があって、正しい方向に進んでいるという確信を得られるようになっている。もちろんこの「正しい」は先人たちの経験の積み重ねにすぎなくて、証明されたものではない。それでも、道に迷っているときに、誰かが歩いた痕跡を見つけられたら、そりゃぁ安心だよね。
本書は、まだまだ何が出てくるかわからないアジャイルのジャングルに、恐る恐る分け入ってみた勇気ある人々のための道しるべだ。ソフトウェア開発者なら、直感的にアジャイル手法が正しいと感じることが多いだろうが、それでも自分の進んでいる道が間違ってないことを一緒になって確認してくれる、心強い友人のような存在として、そばに置いておきたい。（ただただし / 2008-01-11）

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

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

・本文が締めるページ数は、523ページ中450弱。
　コードの掲載が多いため、実際はさっくり読める（15-20時間読了）。
・文章はですます調。翻訳は細かな部分を除けば問題ない。
・演習問題の解答は掲載されていない。
・オープンソースの実用コードを例に挙げる点、さらにそのコードを付録CDから
　参照可能である点が非常に良い。オープンソースが身近になった。
・コードリーディング以外に関して、「共用体の応用」「Makefileの書き方」など、
　初級者を抜け出したいコーダにとって痒い処に手が届く内容は、悪くない。
　また、オープンソースがコード例として優れており、理解が深まる。
・ひとつの言語・OSに偏らない解説（それぞれの環境に言及する）で、広く楽しめる。
・コードリーディングに関して、特別な方法論を提唱する類ではない。
・前半、易しすぎる内容が目に付く。Cライク未経験者に対してか、
　制御文に関する章に関して、それぞれのステートメントの解説から入る。
コードに慣れ親しみ、且つコードの理解に必要な周辺知識（言語仕様・データ構造など）や
暗黙知（イディオム・名前付けなど）を学ぶことで、コードリーディングを啓蒙する書。
コードを読むことに慣れていないような、学生・新社会人・初学者にお勧め。 （shom / 2008-08-18）

CodeCompleteとCodeReadingを併せて読むとよいと、
組込み系のSESSAMEプロジェクトのメーリングリストと、
OS系のTOPPERSプロジェクトのメーリングリストで推薦を受けました。
CodeCompleteは読んだことがあったので、CodeReadingを読んでいます。
オープンソースを仕事にしているので、たいへん役立っています。
MISRA-Cは研修で取り上げてきたので、本書も研修の資料としても取り上げるように準備中です。（kaizen / 2008-01-05）

私はプログラマではありません。コンピュータの運用保守の仕事をしています。でも、自分たちの使用しているオープンソースのソフトウェアがどんなコードで書かれ、それがどのような仕組みで動作しているのかを知っておくことは決して無駄なことではないと思います。業務でオープンソースのソフトウェアを使用した運用保守をしている時、コードのレベルで動作を知っていればと痛感する場面は多くあります(セキュリティホールが発見されたとき、修正パッチが出るのを待って、それを適用することだけが保守の仕事ではありません)。運用保守の技術者がデベロッパの視点を持つことができれば、受身がちだと思われがちなこの保守サービスをもっと能動的なサービスとして提供できるようになるのではないかと思っています。私はずっとこのような本が出るのを待っていました。C言語等の熟達者(あるいはデベロッパ)向けの本かと思いますが、是非、そうでない方も手にとって読んでみてください。（ / 2004-06-12）

「人が書いたソース・コードを読む」ということは、プログラマにとって最も重要な訓練だということは常々言われてきました(他の人か書いた文章を読まずに、良い小説が書けるでしょうか?)。しかし、プログラムを書くためのの教科書がこれだけ多く発刊されていながらも、他の人の書いたコードを読むための教科書は今まで書かれてきませんでした。この "Code Reading" は、その「人が書いたコードを読むための本」です。
オープン・ソース・ソフトウェアを題材としているため、(OSS で最も人気のある) C言語、C++、Java が解説の中心になっています。しかし、各言語に特化したいくつかの章を除けば高級言語からアセンブラまでの全ての言語、全ての規模のプロジェクトに適用可能な内容です。一方、C 言語に特化した章では C 言語のイディオムや注意点が幅広く紹介されているため、中級レベルを目指す C プログラマが入門書の次に読むテキストとしても適切でしょう。
著者は「コードを読むには目的(技術の向上、構造の解析など)が大切」と解く一方で、「小説のようにコードを読む楽しみ」を訴えています。なかなかその域には達っせそうにありませんが、数ある OSS の中から厳選されて CD-ROM に収められた 1700万行のソース・コードは、当面の欲求を満たすのには充分すぎる量だと言えるでしょう。翻訳も日本を代表する大ハッカーの監訳で非の打ち所がありません。全てのプログラマにお勧めできる一冊です。（heita / 2004-06-13）

開発の現場にいると、意外に他人のソースを読む機会が多いもの。また、オープンソースを扱っていると、トラブル時の原因究明だったり、あるは、自分の勉強のために読む、ということもあるでしょう。
そういう場面におすすめなのがこの本....と思っているとちょっと違います。意外に中身はプログラミング・テクニックがメインです。しかも、実践を積んできた人なら、いつの間にか身につけているテクニックだったり、あるは、プログラミングの教科書に載っているような、データ構造やアルゴリズムに関した話だったり。
なので「Code Reading」というタイトルよりも「オープンソースから学ぶプログラミングテクニック」というサブタイトルの方が、適切に中身を表していると思います。
それよりも、この本のカバーをはずしてみると....（july-mori / 2004-11-06）

見積もり、運用/保守、組織改革など広い範囲の内容を、
比較的浅いレベルで網羅している。
ノウハウ的な内容はシステム開発に関連する書籍を何冊か読んだことが
ある人間には割りと常識的なことしか書いておらず、この著者ならではの
独自情報は特にないと感じた。
類書と異なる特徴があるとすると、現在進行形で現場のリーダーとして
働いている人間として、「受託開発」という仕事自体をより楽しくしたい、
という熱い思いが前面に出ている部分と思われる。
しかしながら、モチベーション向上や組織運営の向上、という
視点での考察について学びたいのならば、古典的名著である
トム・デマルコの「ピープルウェア」の方を私としては強くお勧めしたい。
内容的には星３つの本だと思うが、「受託開発の【極意】」を
標榜しながら【極意】に相当する有益な情報が得られなかったことが
失望を大きくしたので星２つの評価とさせていただいた。
（dbplatinum / 2008-05-18）

いわゆる、”あの人は技術者やなぁ〜”と言われる人には、すごくお勧めです。　サービスを提供しているという観点から仕事を見る、という点に得られるものが多いのではないでしょうか。
（alesi / 2009-01-01）

変化を起こすためには、自らが楽しんで率先して動くこと。
そして、周りを巻き込んでいくこと。
継続していくこと。
私が考えている実践的な組織論と同じ考えを
著者は自らの経験と知識を通じて、力強く執筆されています。
特に、第2部はプログラマではない私にとっても
心に響く内容でした。
同世代のビジネスリーダーを志す人々にとって
本書はとっつき易く、かつ、読んだあととても元気付けられること間違いなしです！
（rickey / 2008-04-15）

ソフトウェア開発の中で「受託開発」に的を絞り、現場ベースでの立場から
筆者のノウハウを含め、いかに良いソフトウェアを開発するかという方向へ
導いてくれています。
内容的にはそこまで濃いところまでは踏み込んでないのですが、本書の
ボリュームからすると無駄なくまとめられている感がしました。
これからリーダー的立場になっていく方への入門書としてお勧めです。
また、マネジメントの要素だけではなく、第2部ではライフハック的な
内容も含んでいるので、良い環境へ変えたくためのアプローチのヒント
になるのではないかと思います。（うりゆり / 2008-11-16）

あくまで自然体でありながら、熱く、的確に、開発への向かい方を示されたように思います。
テーマに挙げている「受託開発」について、設計，テスト，進捗管理といった日頃の開発ひとつひとつにおける取り組み方や、見積もりやチーム形成のあらゆる場面での考え方に至るまで、プロとしての実践的な「極意」がぎっしり詰まってます。
理想論とかじゃなく、あくまでも「現場」視点。エンジニアなら、共感しながら自分の開発に役立てることがたくさん見つかるはずです。（mnishikawa / 2008-04-16）