リスト：プロジェクトマネージャと戦う前に読む本 を表示しています。（全 12 件）

ソフトウェア開発プロジェクトを成功させるために実際どのように取り組めばよいのかを具体的に説明しているバイブル的存在の良書です。３００ページほどの本ですので、プロジェクトの進め方について分厚い本を読みたくないのであれば、当著書を１冊読むことをお勧めしたいです。ソフトウェア開発プロジェクトに携わるすべての人に読んでいただきたい。｢ステージ別納品｣を中心にプロジェクトの立ち上げから納品までの手順と注意事項はかなり参考になると思います。当著書が気に入ったのであれば同著者の｢ラピッドデベロップメント｣を読むこともお勧めします。（kinopp / 2007-02-18）

プログラマ志望の人にはぜひ読んで欲しい。
プログラマになってしまうと、仕事が忙しくて読む時間がない人が大勢います。
学生のうちに読んでおくのがいいかもしれません。
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）

上巻が良い内容でしたので、迷わず下巻を読みました。
上巻よりは少し難しいかったですが、それでも大変読みやすい本でした。
内容は、テスト、デバッグ、リファクタリング、コードチューニング、ツール、
レイアウトについてで直ぐに実践できる内容ばかりで業務に生かせます。
上下巻合わせて手の届く場所に置いておくべき、プログラマ必須の本でした。（なか / 2007-02-05）

上巻はあまりそうでもないですが、下巻は第1版とは大分趣が違うように感じました。オブジェクト指向、C++、XP、PMBOKなど、最近の手法やプロセスについての記述が多く、職人技的な内容(個人的にはこちらが好み)の割合が少ないようです。まあ、この辺の新しい知識もこれからは必要ですが...。（ / ）

コードコンストラクションにまつわるトピックを完全に網羅しています。参考文献が豊富に紹介されており、変な入門書より役に立つでしょう。
値段が高めですがその価値はあると思います。
ITエンジニアには特にオススメです。（amazon_hk / 2007-03-30）

上巻と同様、これもMUSTです。
原著は1巻構成になっていることを考えると、上下巻を切り離して読む事は出来ません。
たとえば下巻では自分の経験や勘に基づいて当てずっぽうでパフォーマンスを上げようとしたり、最初からパフォーマンスを優先して人間に分かりにくいプログラム書いてしまったりするなど、フォーマンス問題にありがちなアンチパターンと、そうした問題に対する正しい対処方法が書いてあります。
また、何かに付けてコメントを付けまくるコーディングスタイルの問題点なども上げられています。この本を読んでからは、コメントを書くぐらいならコメントが無くても分かるようなコードを書こう、コメントを書く場合はどうしてもトリッキーなコーディングが避けられなかった場合だけにしよう、という考え方に変わりました。
下巻は他にもエンジニアにとって不可欠なノウハウが満載です。上巻だけで満足するのではなく下巻も手に取り、"自分のために"勉強しましょう。（伊藤淳一 / 2009-11-01）

上巻の前半までは仕事でプログラミングに関わる方なら皆読んだ方がよいです。
上巻の後半から下巻にかけては特にこの本ならではという内容ではありません。
目次を見て興味がある方だけ読めばよいと思います。（やすます / 2009-05-20）

一見地味なタイトルで，良くありがちなゴシップ的な書籍かと思ったが，内容はまともでなかなかの良書である．専門家ならば嫌と言うほどご存じの「常識」が，一通り再確認されている．
例えば，現在無数にある「ソフトウエア開発方法論」や「設計手法」などのほとんど全てが眉唾ものと言って良い．誰でも高品質のソフトウエアが開発できる「ソフトウエアの品質管理手法」だとか，「画期的に生産性を向上させる」といったふれこみで登場するツール類なども，残念なことにほとんどは額面通りの効果は発揮しない．それは優れた開発者ならば経験的に知っているのだが，残念なことに技術を知らない経営者や中間管理職は裏付けのない言葉に踊らされるというのも良く聞く話である．他の業界なら管理できているものはソフトウエアでは管理できない．それは何故か？それはソフトウエア業界における品質管理技術が遅れているためでも，ソフトウエア開発者が品質に無頓着だからでもない．ソフトウエア開発は他の業界，例えばビル建設や家電の量産などとは全く異なる性質を持つためなのだ．全く異なる性質を持っているのだから，他の業界の手法が使えなくても当然だろう．
では一体ソフトウエア開発の性質とはどのようなものだろうか．それを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）

驚くことに日本のソフトウェア業界にはレビューの価値を評価できずに、省略しても構わないとする文化が少なからずともあります。本書はしつこいくらいにレビューの必要性を説き、中でもインスペクションの有効性を強調しています。
私自身、ソフトウェア業界に従事して20年近くになりますが、レビューの必要性を痛感する一方です。会社にレビュー文化をいかに根付かせるか悩んでいる方にはうってつけの書籍ではないでしょうか。私は、自分の会社でこの本を配布し、レビューをソフトウェアシステム構築の重要なタスクのひとつであるということを認識させることに成功しました。（川久保智晴 / 2004-06-26）

レビューという言葉はコード・レビューの意味で使われることが多いようですが、最初の検討フェーズから各ステップでレビューを実施すれば大きな効果が得られると思います。
この本ではピアレビューをＣＭＭＩレベル３での実施アイテムとして提示していますが、企業としてのレベル３取得の動きとは関係なく実施できると思います。内容はなかなか実践的なので、読者自身が工夫することで自分のプロジェクトに応用できそうです。（横丁のおじさん / 2004-05-02）

ピアレビューとは「同僚による査読」であり、品質向上のためのツールのひとつ。この本はタイトル通りこの「ピアレビュー」をテーマにした1冊。その中でも「インスペクション」と呼ばれる公式レビューについての解説が厚い（第4章〜第9章）。公式レビューは、概要説明、準備、インスペクションミーティング、修正、フォローアップという5段階を踏み、モデレータや記録者、読み手という役割が必要となるが、それに見合う欠陥検出効果が見込めるという。実際には、プロジェクト計画において品質目標、規模などを考慮して公式レビューを取り入れるのかどうかを見極めることになるので、必ずしも公式レビューである必要はない。とはいえ、こういう手法を知っておくのはいいことだ。
第4章でも言及されているが、インスペクション（準備をしてミーティングによって欠陥を指摘する）がどれほどの効力があるかについては議論の余地があるようです。この本以外の書籍についてもあわせて読むことを薦めたい。たとえばソフトウェア・テストPRESS　vol.2でインスペクションについての記事が載っている。（softest / 2008-08-12）

内容は、レビュの重要性、効果が少々で、あとは、レビュを組織的に行うには？の説明です。
レビュ、インスペクション、ウォークスルーの違い、インスペクションの各種手法、インスペクションの準備、成果物、評価、陥りやすい失敗とその対策、効果を上げる方法等です。
インスペクションが中心に記述されています。ウォークスルー等については、違いが記載されている程度です。
手法そのものよりも、成果物や人の教育、体制、改善など、組織に導入するという点に重きが置かれている印象でした。
初心者にも、分かりやすく書いてありました。
また、厳密なインスペクションの実施に興味がある方には、参考になることがあると思います。（lemonerika / 2005-09-02）

この本はピアレビューを行う際の観点についての記載はないです。
残念。
みんなが悩んでいるところは、どうすればレビューで不具合を漏れなくガードできるかなんじゃないかな？こういった具体的なネタは会社固有のノウハウでなかなか外には出てこないのでしょうね。
プロセスについてはCMMIやPMBOK本のほうがいいかな！？（樹 / 2008-10-03）

ソフトウエア開発の現場では、今でもいろんな混乱がある。
■工期短縮のためには工数増が必要であるのも拘わらず、プロジェクト開始後に要件決定の遅れや納期の短縮要求をズルズルと受け入れてしまう。
■トップがその年に決めた目標(たとえば生産性向上５％)を達成するために、他の重要なメトリックスを悪化させてしまう。
この本の中では、ソフトウェア開発の分野では中核となるメトリックスは５つある（規模、工数、工期、品質、生産性）といい、６３００の実績データの分析、メトリックスの導入、注意事項について解説している。
全体を通して痛感するのは、何を測るか、それをどのようにフィードバックするか、こういうことを継続して考えていかないと５つのメトリックスを同時に改善していくことはできないということ。本書の中で引用されている、絶対温度で有名なケルビンの「計測できればコントロールできる」という言葉が強く印象に残ります。日本でも、ソフトウェア開発分野のプロセスエンジニアという職種が定着することが必要とも感じました。（yu-ji / 2006-09-13）

2000年までの6300件のデータをもとに、多くのグラフを用いて説明されており、非常に説得力があります。
概念的には、機能総量＝プロセス生産性×工数×開発時間で表すことができます。この関係からわかるように、工数と開発時間はトレードオフ関係にあり、開発時間を延ばせば工数が減ることになります。
従来の見積もりでは単に人月であり、開発時間を考慮していないため、正確に見積もれないことがわかります。（100人月：100人なら１ヶ月？１人なら100ヶ月？）
どんなに頑張っても（コスト・人を投入しても）これ以上早くは開発できないという最短開発期間が存在するというのも、目から鱗でした。無理ムリのスケジュールでの開発は、破綻することになります。
計測されたデータの分析結果が主になっているので、いざ実際に計測しようとすると、他の書籍などを調べる必要があるかとは思います。
5章と11章だけでも読む価値があるかと思います。（tkcjun / 2005-12-03）

ソフトウェアのプロマネ本の1つです。
ソフトウェアの開発を管理する上で、気を配らなければならないことが書いてあります。作者の長いソフトウェア業界での経験が凝縮されていて、その点は参考になります。
しかし、少し内容がふるいのが気になります。1980年代の前半の話などがよく引用されて出てきます。さすがに20年前の話をされても困ります。
で、トータルすると星３つ。（ユングベリ / 2008-12-21）

失敗とは何か、、、
失敗の種類と特徴
失敗を起こす原因は、、、
致命的な失敗とは、、、
について書かれた本当に示唆深い1冊。
実際の事故（タコマ橋の崩壊、雪印問題、自らの研究室での実験、等々）を事例に、何がおき、何が原因で、それについてどう対応したかを紹介した上で、それをどう利用していけばいいかについて書かれています。
こんな本が、講談社文庫から出ているとは露とも知らず、驚きつつ感動してしまいました。
特に失敗情報の伝わり方・伝え方は、本人が大学の講義で学生に伝えていく苦労も含めて書かれていますので、すごく参考になります。
著者は、意図的に失敗するように講義や研究を行っており、小さな失敗、訓練での失敗なくしては、本当の技術や知識の習得はないと言っており、
確かに、過去に失敗したことって、よく覚えているし、二度と同じ失敗はしないように気をつけるよなあ・・・などと感心してしまいました。
また、失敗には「よい失敗」と「わるい失敗」があり、
未知の事象に突き当たり、それによって失敗することで、技術が進歩するのは「よい失敗」だが、
不注意や、未熟さでおきる失敗は「わるい失敗」だとしています。
さらに興味深いのは、失敗の原因には階層があり、
個人の技術の未熟さから発生するものと、
指導の悪さから、マニュアルの不完全で起きるものと、
会社や組織の構造上の欠陥から起きるもの
果ては、社会や文化を原因にして起きるものがあると説明しています。
まさしく「失敗学」と呼ぶに相応しい名著です。（蒼海苔天祐 / 2007-01-27）

　普通の感覚で言うと「失敗＝恥」みたいなものがある。しかし、この本で述べられていることは失敗を知識化してどう生かすかについて語られている。
　そのためには、失敗と向き合わなくてはならない。会社などでこの本に書かれているような取り組みを行おうとするのは正直言って難しい。しかしその取り組みも、失敗を重ねていけば、いつか上手くいくのだろうか。
　やはり失敗と向き合い、失敗を知識化するための文化には相当の労力を要する。ただし、そのための価値はあることは確かだ。人は必ず失敗するし、これまでも人は失敗から学んで成長してきたからだ。
　色々なハウツー本が出版されていて、それらを沢山読んでいる人もいるだろう。たまには「こうすれば上手くいく」ではなくて「失敗」について学ぶ価値もある。なぜなら、何も行動せねば失敗しないから。行動するためにハウツー本読んでいるのに、行動しないのは勿体ない。行動した結果、失敗したらこれをもとに失敗から学ぼう。
（arlo / 2006-08-23）

失敗から学ぶことは大事だと思っていましたが、ここまで真剣に考えたことはありませんでした。
失敗の定義から始まり種類・特徴、そして創造にいたるまでの流れはまさに圧巻です。
今現在もさまざまな失敗が表面に出てきていますが、そのほとんどは事前に予測し対処可能なものがほとんどです。
今の日本に求められているのは、失敗を隠すことではなく生かすことではないでしょうか。
一人でも多くの方に読んでもらって失敗に関するイメージを変えて欲しいと思います。（好奇心のかたまり / 2006-02-06）

「失敗は成功の母」
そんなことは知っているよ！という人がほとんどだろう。
でも、それをしっかりと理解し、実際に実践している人はどれだけいるのだろうか。
失敗「学」と堅苦しい名前がついているものの、本書で著者が言いたいことは
　「失敗は成功の母」
という、ただそれだけである。
その格言を、実例を交えながらいろいろな角度から分析し、著者の考えを盛り込ませながら、説得力をもたせたのが本書である。
失敗とは何か？
失敗とどのようにつきあえばいいのか？
失敗をなくすにはどうすればよいのか？
失敗を忌み嫌うのではなく、失敗と真正面から向き合う。
社会としても、組織としても、そして個人としても、失敗に対する肯定的な態度を形成していくことを著者は望んでいる。
失敗は必ず起きるものである。（the_world / 2005-10-01）

失敗学というタイトルをつけた出版社の勝利ですね。
この本は失敗学という考えを広めるのに貢献しましたが、
内容的には、抽象的な概論論がメインです。
（この研究そのものは畑村先生だけでなく、同じ様に
　複数の人で研究していたようです。）
同じように研究されていた中尾 政之さんの失敗百選の方が
具体的で体系化されていて面白いです。
（この方も畑村先生と一緒に活動されていたようです。）
学校の先生らしく、抽象的な概念や学問化することには長けていますが、
私にはいま一つ迫力を感じませんでした。
畑村先生の本では「危険学のすすめ」の方が実践的で
格段に面白いです。
こっちの方が、真剣味、迫力みたいなものがあります。
（English learner / 2007-05-07）

企業がクリエイティブであり続けるために必要な6つの要素を紹介した本で、
日本や米国の事業での事例を豊富に盛り込み、小さな業務改善が大きな利益を生んだり、
社内での偶発的な出会いがきっかけとなり、大きな新規事業が生み出された逸話など、
現在の日本企業にとっても示唆に富んだ内容になっています。
いま流行の「社内SNS」などの必要性が、10年前に予言されていたような、
とても先見性に富んだ一冊です。（Kaju / 2007-07-01）

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

最近はwebに発表したエッセイや、ブログのエントリーをそのまま出版したりなんてことがあるけれども、この本もその類。そういう風に書いてしまうと、なんだか企画モノのような中身の無い浮ついた内容、ある種タレント本のようなものを想像してしまうかもしれないけれども、この本についてはそういうことは無くて、なかなかの内容。
内容はポール･グラハムによるIT業界、そのコミュニティ、もしくはハッカー（ごく一般的なITエンジニアも多少通じるところがあります）に関する文化論をエッセイとして論じたもの。
エンジニアが書いた文章だからと言って、その内容が堅苦しいわけでもなく、また理系用語をちりばめた、その知識が無ければ理解に苦しむようなものでもありません。お互いが技術者だから分かる、もしくは分かってもらいたいと言うような読者層を限定してしまう内容ではなく、エンジニアではない一般の人たちにも非常に分かりやすい内容。
特に非エンジニアの人たちには理解に苦しむところがあるのかもしれない、ハッカーの行動、考え方についてはエンジニアを組織、管理している立場の人間にはぜひ読んでもらいたい部分だったりします。 （espio999 / 2006-04-17）

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

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

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

　筆者の カール・Ｅ・ウィーガーズ (Karl E. Wiegers) 博士 はEastman Kodak社で写真技術に関する研究やソフトウェア開発に18年間かかわり，現在は， Process Impact 社 を主宰して，ソフトウェア開発に関するコンサルテーション，講演，執筆などを行っている．
　本書は，1996年に出版され，ソフトウェア開発者向けの専門雑誌 Software Development Magazine 誌 の Productivity Award を受賞した話題作である．1996年の出版と聞くと内容が古いという印象があるかもしらないが，決してそんなことはない．流行の技術には殆ど左右されない本質的な内容である．
　私自身の経験では，この手の本では，「80%以上賛成」できるものは非常に少ないが，この本書は，その少ない例の一つだと言える．
　目新しい技術や，魔法のような手法ではなく，確実に効果があると知られているものについて，判り易い文章と豊富な参考資料とともに，うまくまとめている．
　原題は「Creating a Software Engineering Culture」であり，ソフトウェア工学のお作法を，単に技術としてではなく，文化ととらえている点が，本書と他のソフトウェア工学の本との大きな違いである．さらに，品質と，継続的な学習を重視している点が，とても良い．
　プロとしてソフトウェア開発に関わるすべての人，これからソフトウェアの道を歩もうとする人に，強くお勧めする．ソフトウェア開発技術者必読の一冊．（Dr. Jason / 2005-10-01）

物騒なタイトルを書いてしまったが、各章の最後に「文化を生かすもの」と「文化を殺すもの」の項目が記述してある。特に殺すものを読むと、自分の今までの経験の中でいくつかは当てはまるものを発見し苦笑いする人も多いのではないだろうか？そうした目でもう一度本文を読み直すと理解が深まると思う。
また、やはり各章末の「参考文献」と「補足資料」も役に立つ（日本語訳のない文献が多いのが残念だが、この書についている数行のコメントでもかなり雰囲気はつかめる）（キミノリ / 2006-03-23）

この本の著者にとって、建築とソフトウェアが類似している事を再確認させる事はあまり重要なことではないのかもしれません。
ソフトウェアと建築のアナロジーは、もう何年も前からソフトウェアの業界で言われている事で、最近新装版が出された「人月の神話」では「建築にたとえることはもう有用さを失った」とまで書いているぐらいですから・・・。
ということはさておき、
ソフトウェアの比較として「建築」が取り上げられているのかは、目に不自由がない限り、建築物は誰もが目にする対象であり、ごく一般的で分かりやすいものであるから、あえて著者が選んだのだと考えます。
著者が訴えたかった事は、何かを考えると、
実例まで挙げている、業界が抱えている危機についてではないでしょうか。!
この本を、何かの「答え」が書いてあるものと考えると、きっと読み辛いのではないでしょうか。
「HowTo本ではない」と認識して読まないと途中で挫折してしまうかもしれません。
ソフトウェア業界に身を置く人間が、この本を読み、現状の問題点に気付き、その改善によって、迫っている危機を回避する契機になればという思いを感じます。
ただ本当の意味で、ソフトウェア業界が抱える危うさが改善されるのは、ソフトウェア業界以外の大企業の管理的立場にある人の中に、ソフトウェアの本質を理解した人がもっと増えない限り難しいように感じますが・・・。（しげ / 2003-10-04）

建築とソフトウェア開発の類似性に着目してアーキテクト（建築家）の重要性と役割を説明している．昔からこの類似性はあちこちで言われてきているので，本書がこの類の内容を初めて書いているわけではないが，まとまったイントロとしては良いと思う．また，ソフトウェアアーキテクトのあるべき姿を考えるための材料としても良い．
ただ，この類似性を説明してアーキテクトの重要性を説くのにどうしてこれほどのページ数を費やす必要があるのかが不明．また，結局のところソフトウェアアーキテクチャとは何なのか，それをどう設計・保守するのかといった話題はほとんど書かれていない．アーキテクト，プログラマ（ビルダー），エンジニアの役割に着目した開発プロセスも説明されているが，従来のプロセスと同じで特に目新しさがないのも残念．アーキテクチャ駆動型の開発プロセスを説明している本を読む前座として読めば価値があるかもしれない．（鈴木純一 / 2005-01-05）

ソフトウェアアーキテクト会社が書くソフトウェアアーキテクトの重要性を述べた本
ＩＢＭでオブジェクト指向のチーフアーキテクトを勤めていた著者の
ソフトウェアアーキテクトの重要性を述べた本
ＷＷＩＳＡ（Worldwide Institute of Software Architects)という非営利団体の代表でもある著者の著作だけに，穿った目で見ると単なる宣伝の可能性もあります．
内容は，ソフトウェア開発を建築と比較し，建築で重要なアーキテクトに対する
重要な部分があるのではないかということを述べています．
著者はソフトウェアのアーキテクチャを定義し，アーキテクチャを決定する
ソフトウェアアーキテクトという職業を述べています．
後半はアーキテクトの役割，いつ活動するのか，どのようにして育成するのか
について述べています．
多分ですが，ソフトウェアアーキテクトについて述べた最初の本だと思います．
ソフトウェアエンジニアリングで説明できるところはソフトウェアの世界で
述べていますが，育成などの項目に関しては建築を参照しろと述べているだけで
それが本当に妥当かどうかが不明なところが多くあります．
また，建築のアーキテクトの世界もアートに近いコンセプトデザインと
姉歯に代表されるような構造設計の世界があります．
この本は（都合よく）この２つを
混同し引用しているように思える点もあります
建築物でもグランドデザインアーキテクトが必要な建築物は少なく多くは
姉歯のように構造設計，つまりエンジニアリングで充分な世界だと考えます．
ソフトウェアアーキテクトという職業が成立することは理解できるのですが
アートとエンジニアリングの間について適切に述べているかどうかは
不明かと考えます．（親カッパ / 2008-06-15）

久しぶりに読後にいろいろと考えさせられた。
全体を通して、ソフトウェアと建築の類似性をもとに、ソフトウェア業界に欠落しているアーキテクトの必要性を訴えている。
現在のソフトウェア業界には、建築で言うところのアーキテクトと呼ばれる役割を持った人が存在しないため、よいソフトウェアが供給されにくい現実を的確に説明している。
「第2章 アーキテクト不在の世界」では例えとして、そこらじゅうに欠陥住宅や不良住宅が乱立した世界をあげているが、今の世の中に供給されてきたソフトウェアのことを考えてみれば、言い得て妙である。（現実にも建築士抜きで建てた住宅が、欠陥住宅だったり、欠陥がなくても使いにくかったりすることはご存知のとおりだ）
アーキテクトは、クライアントにとってできる限りよいものを提供するためにデザインする。そして、アーキテクトがデザインしたものがきちんとエンジニアやビルダーの手によって作られていくことを管理する。
「第6章 ソフトウェアアーキテクトの役割」に書かれている内容は興味深い。ここで書かれている仕事は、まさしくアーキテクトの仕事である。よいものをデザインするには何をしなければならないかについて書かれている。。アーキテクト不在の現状ではシステムエンジニアが兼任しているが、この状況は確かに適切ではない。システムエンジニアやプログラマは、必ずしもクライアントの立場ではない。作り手の立場でデザインしてしまうことがあるのは、誰でも経験があることだと思う。クライアントが最善のソフトウェアを手にするためには、クライアントの立場で最善のソフトウェアをデザインする役割の存在が不可欠であり、その立場こそがソフトウェアアーキテクトである。
全体的に分かりにくい感があるが、これは「読者に何を訴えたいのか」を最後に述べているためだと思われる。各章の最後に「まとめ」があるが、各章を読み始める前に、この「まとめ」を一読しておくと理解しやすいかもしれない。（さわだ / 2003-05-31）

「建築におけるプランナーが建築家であれば、ソフトウェア開発におけるプランナーはソフトウェアアーキテクトである」とのことだが、出てくるのは本当に建築の話ばかり。読み終えるのが苦痛なくらいだ。
確かに、アーキテクトなるものの必要性は、多くのソフトウェア関係者が感じているだろうから、基本的な主張には共感できるだろう。ただ、この内容では、あまりの具体的指針の無さに不満を感じる人が多いのではないだろうか。（Gavi / 2002-10-19）

本書は個人的に何度も要望してきた「見積もり方」の暗黙知を形式知としてまとめた本だ。世間一般に言われるコード桁数による見積もりやFP法などのような「規模の見積もり技法」だけではない、プロジェクトの始まりから終わりまでのライフサイクルを通じて、見積もりとはどのような物かを本書は教えてくれる。
1部では現状の問題と新しい概念の導入を述べ、2-5部では問題解決のためのプラクティスの数々を紹介し、6部ではこれまでに述べたプラクティスが成功する理由を述べるとともに読者への自信を補強し、最後に7部ではケーススタディとしてプラクティスをどのように実践するかを小説仕立てで書いている。開発プロセスを論じている本は多々あるが、本書のような6部と7部がある物は数少ない。
また、章の最後に議論のポイントを提示しているのも「どうすれば自分のプロジェクトに導入できるか」を考える良いきっかけになると思う。この「議論のポイント」は「考えてみよう」ではなく、「話し合ってみよう」となっている。自分で考えるだけではなく、本書を片手に見積もりと計画について、同僚や仲間と話し合ってみるだけでも新しい価値が生まれるはずだ。
（hsbt / 2009-02-05）

約5年前のXP祭り2004で、XPの達人がが「XPで一番面白いのは計画ゲーム」という発言をしていて、当時XP聞きかじり組だった自分は感心したものだった。なにしろXPといえばペアプログラミングや TDDばかりが取りざたされていて、計画ゲームやメタファーなんてプラクティスは、なんとなく「手の届かないもの」っぽい感じがあったものだ。
その後もしばらくは、計画ゲームはマジシャンの扱う道具で、その種明かしはベールの向こうという状況が続いていたと思う。で、計画ゲーム抜きで導入された「なんちゃってXP」が、失敗の山を築いていたわけだ。
本書は、そんなベールの向こう側をあますところなく見せてくれる。手品の種明かしがつぎつぎとなされるわけで、これは面白くないわけがない。
何がいいって、「例え話」が豊富なところがいい。まったく未知の概念を説明するのに、例え話は効果的だ。計画を頻繁に見直すことを水平線の向こうへの航海で例えてみたり、見積りの手法を家のペンキ塗りでたとえてみたりという具合。本書最後にあるケーススタディも、広い意味で例え話だと思うが、これがめっぽう面白くて、まさにクライマックス。
読んでいて、本当に隠されていたアジャイルの種明かしは「正直になること」なんじゃないかと思った。未経験者だけで集まってアジャイル開発なんてできないことを「正直に」認める。正確な見積りなんてできないことを「正直に」認める。チームメンバに、顧客に、いまわかっていることを「正直に」伝える。 5年前のアジャイル本が、きれいごとを並べてばかりだったのに比べると、本書は呆れるほど正直だ。
そうしてみると従来の手法は、実に欺瞞に満ちているなぁ。できっこないとわかっているのに、最初から正確なスケジュールを求める。チームメンバの出してきた見積りをしれっと2倍にしてから上司に見せる。嘘で塗り固めた計画が、うまく運ぶわけがない。バレたら困るから、手遅れになるまで見直ししないしね。
結局、お互いに正直になれる土壌作りが、正しいアジャイルの第一歩ですよ(これが一番難しかったりして)。（ただただし / 2009-04-20）

献本いただきました、旧来の見積り・計画立案の問題点を明確にし、それについてアジャイルな見積り・計画ではこのように問題を解決するという方法を示してくれる。TOC-CCPMと通じる物がある、旧来の問題点はTOC-CCPMスペシャリストの研修で教えていただいたことと同じ、バッファの考えも同じ。TOC-CCPMをソフトウェアに適用するためのガイドとしても使える。（hiro_e / 2009-02-10）

　プロジェクト管理の経験が少しでもあれば、見積手法として
FP法、COCOMO、COCOMOUなど、どれも使えないことに直ぐ気が付くでしょう。
　そこで自分なりに見積手法を編み出し日々進化させてきたのですが、
その答えが、既にこの本にありました。それが「理想日による見積」でした。
さらに進化系である。「ストーリーポイントによる見積」は
目からうろこのアイディアです。
　この本はプロジェクト管理のバイブルになることは間違いないでしょう。
（なか / 2009-11-24）