リスト：ソフトウェア開発を基礎から学ぶ本 を表示しています。（全 12 件）

　スタンダードなプログラミングとは何かということが書かれていると思います。速度のみを重視した、解読不可能なトリッキーコードは全くありません。誰もが努力すれば必ず身につけることができるような、そういった内容です。しかし、それこそが、最も効率的で、最も効果的で、最も美しいプログラミング、正にプログラミングの王道あるということが分かります。
　この本を読みこなすには、最低Cの知識が不可欠ですが、それでもCのよく使われるライブラリのみでコードが構成されています。
　また、awkやperlが分かると、更に楽しく読めると思います。（たか / 2002-09-16）

出版された時から、書店で手にとっていたのでどんな内容は分かっていたつもりだったのですが、実際に読んでいくと、実に深い内容だなあ、と思います。
最初にプログラミングのスタイルの話から入るのですが、いつも私が悩んでいる変数の名前付けなどについて，きっちり結論がだされていて、ためになります。
この辺の問題は、別にプログラマや、プログラマを目指す人だけの問題ではありません。会社でVBAマクロを書くだけの人にもぜひ、意識してほしいと思います。
頭がなかなかついていかないので、読むペースが上がらず、もどかしいのですが憧れのカーニハン大先生の本なので（プログラミング言語ａｗｋでプログラミングに開眼しました）、じっくり読もうと思います。（トニオ、アントニオ / 2001-11-10）

カーニハンの本には、いつも無駄がない。職業プログラマが、キャリアアップの中で経験する試練を乗り越えるための、英知と示唆が凝縮されている。多くのWindows本に見られるようなディスプレイ画面のコピーや使い方で多くのページ数をさいて、判ってしまえば積読になる昨今のノウハウ本とは全く対極をなす。かといって何回な数式や論理を振り回すこともない。読者が経験を積めば積むほどに、深く考えさせられる。新人教育用に、またベテランは自己のスキルの再チェックのためにプログラマから管理者まで必読してほしい。（トム仙人 / 2002-05-26）

　この本のエピローグの後には「Appendix：ルール集」というものが付いており、各章の主旨やルールがまとめられている。一度読み終えれば、このAppendixを眺めるだけでも充分だろう。
　C、C++、Javaを始め、AwkやPerlによるプログラムも紹介されている。言語による記述の違いが明快で興味が持てた。
　参考書には書いていない今さら人に聞けないような「変数名や関数名の名前の決め方」なども書かれている。
　また、各章のはじめにある著名人たちのことばから得るものも多い。
　我々のバイブル的な書籍であろうという評価には納得だ。（petitbee1980 / 2003-08-30）

プログラミング作法に関する類似本はたくさんありますが、本書が一押しです。コーディングスタイル、インタフェース、テスト手法、などに関して、単にお勧め方法が書かれているのではなく、その本意がきちっと説明されているので納得できます。
また、従来作法の間違い指摘なども随所に盛り込まれています。
仕事で作るプログラムのヒントが盛りだくさんに書かれています。
コーディングスタイル、インタフェース、移植性の重要性を説明できますか？自己満足のプログラミングではなく、仕事に役立つプログラムを作成するためには、絶対に読むべきです。かならず役に立ちます。（春峰 / 2005-06-19）

初めて読んだデザインパターン本でしたが、最後まで行き詰まることなく読み進めることができました。他の方も書いてますが内容は非常に良いです。ただ、訳がまるでこなれてなく、誤訳も多いため星3つとしました。単なる技術書であれば『訳がこなれていない』ことは減点対象ではないのですが、本書では同一の内容を異なる表現、文体で繰り返すことで知識を定着させることを狙っているため、直訳調ではない日本語として練られた訳が重要だと思いました。
2版は正確かつ練られた訳になることを期待します。
（たびもり / 2006-12-24）

待望のHead Firstシリーズ、国内第二弾。
オリジナル本が大ベストセラーとのことだが、それを裏づける素晴しい内容だと思う。初学者にとっては、日本語で記述されたデザインパターン本の自習書とし最適であると思う。
デザインパターン本やオブジェクト指向プログラミング本に関しては、中・上級者が紹介する推薦本（良書）は、中・上級者にとっては当たり前のことであっても、初学者にとっては「なぜ？」という疑問がつきまとう。行間に隠れてしまっている概念がまったく理解されていないがゆえに、「何でそれが重要なのか？それが問題なのか？」がまったく理解できない。早い話が、ほとんどが「馬の耳に念仏」になってしまう。また、よくある表現、言いまわしついても、何冊も似たような書籍と格闘し、挫折してようやく「もしかして、こういうこと？」とようやく正解に少しだけ近づくことができるのだ。それとて本人にとっては自身が無いはずだ。要は、初学者にとっては推薦本の解説本が欲しいのだ。
この「Head Firstデザインパターン」は、このような初学者に対して親切、丁寧に解説してくれる。中、上級者の方にとっては、部下、後輩への教育にもきっと役立つはずだ。
個人的には、「師匠と弟子」の会話が最高に面白い。それとGoFの写真が紹介されていたが、なぜか感動してしまった。

しかし、Bridgeパターンが「13章　付録：残りのパターン」の中で紹介されており、しかも見開き2ページとは悲しすぎる。また、本国で発売されてからじつに14ヵ月もの時間がたって邦訳・出版されるのは理解できない。
（はるちゃんのぱぱ / 2005-12-05）

デザインパターンの解説書は敷居の高いものが多いですが、様々な方面からアプローチされた例を多用しているのでデザインパターンの習得を志す人なら誰でも本書内のどこかの段階で理解できるような構成になっています。
これまで自分が無意識に書いていたコードとデザインパターンの定義の関わりが理解できたことが最大の収穫でした。
今後、分からなくなったときにはこの本に戻れば大丈夫という安心と自信を与えてくれる一冊です。
（kamome373 / 2006-02-25）

読み進められれば力になると思います。
しかし、この重さ。。。
もうちょっとで改版されるタイミングで買ってしまったので、第2版がうらやましいｗ。
買って損したとは感じない本です。（やさぐれSE / 2006-12-10）

デザインパターンの本としては最も読みやすく、理解しやすい本のひとつ。GoFのパターンのうち、重要なものにフォーカスして解説。重要なポイントについては繰り返し、手を変え品を変え説明されている。その結果、GoFのパターン本よりも分厚い本になっている。初めてデザインパターンを学ぶため、あるいは他のデザインパターンに挫折した場合などに最適な本。一通り理解した後に、細かいポイントを見直すにはやや冗長かもしれない。 （鈴木純一 / 2007-10-21）

ファウラーのリファクタリングの書籍を受けるようにして書かれた本書です。
ファウラーの書籍に続いて読んだ感想は、下記のような点です。
・やはり、日本語として読みやすい
・リファクタリングの項目ごとに章分けされているので、後でコツを調べやすそう
本書にも書かれていることですが、リファクタリングの各項目は、プログラミングのコツを知っている人には、常識的なことだと思います。
しかし、初級技術者が持っているコーディングレベルを少しでも上級者に近づけるには、
謙虚に本書にあるような項目を意識してコーディングをしていくことが役立つと感じます。
そういう意味では、本書を見ることは、先人の知恵の詰まった、プログラミングの帝王学を学ぶと言うことかもしれません。
通して読んでから、実際に本書のコードをリファクタリングして、後は、気になるときに読むといった使用方法が良いのかなと思います。（hiroshi / 2007-05-22）

マーチンファウラーの「リファクタリング」より本書の方が読みやすく感じられました。訳書独特の言い回しは必要以上に難解に感じられると、本書を読んで改めて感じました。JDK5に対応している点もポイントです。
一通りプログラムが書けるようになったら読み、また、その後も何度でも読み返して考えを新たにする、そういう内容だと思います。
Javaプログラマーでなくても十分に通じる思想だと思いますし、多くのプログラマーに読んでもらいたいと思います。
本書と、もう一冊「デザインパターン入門」があればJavaプログラミングの勉強に関して他はあまり必要性を感じません。
ただ、個人的には「リファクタリング」という単語は小難しい印象があって、少なからず読者を遠ざけているのではないかと思うこともあります。（あらこ / 2007-02-01）

結城さんの本は、どれも分かりやすく内容も深い。
この本も例外ではなく、良書だと思う。
なぜ、リファクタリングが必要なのかを改めて実感できる。
マーチンファウラーの「リファクタリング」を挫折してしまった人にもお勧めできる本。
（卍 / 2007-02-20）

基礎がわかっている人や他の言語を知ってるけどjavaはあまり知らないと
いう人には、かなり良いと思う。
javaプログラミングの処方箋、java謎落とし穴、J2EEアンチパターン
といったリファクタリング系の本はけっこうあると思う。
各本の違いは、正直読んで見ないとわからない。
結城さんのjava系の本で、デザインパターン入門やスレッド入門などありますが
これはそれらの２冊よりもページ数でいったら６〜７割くらいです。
少し見にくい（カラーにしてもよいのでは？）といったところがあります。
後は、ページまたぎが多いから電車内で読んだりするのには適さない。（あぃっく / 2008-04-24）

会社の先輩とかが一応読んどいた方がいいというので読みました。
自己流でもプログラム暦が結構あって沢山のプログラミング関連の書籍を読んでいたなら、
そこまで新しい知識はありませんが
コード体質の改善という観点での整理には良いかも。（9re / 2009-11-14）

海外のエンジニアから薦められて読みました。
こんなので有益な知識が得られるのか？と思いましたが、内容は真面目です。
自分は初学者ではありませんが、この本から得るものはそれなりにありました。
風変わりなレイアウト構成とは裏腹に、内容は最新のオブジェクト指向分析・設計の
スタンダードとなっているアプローチを忠実に説明しています。
この本の良い点は下記です。
・何度も言葉や視点を変えて説明するという方法が取られており、記憶に残ること
・難しい内容をわかりやすく簡潔に説明しており、気楽に読めること
・１ページ（か見開き）で説明することは１つだけというスタイルを貫いていること
リファレンスとしては使えず、１度読んだら本棚に眠ってしまうタイプですので、
コストパフォーマンスを考えて４点にしましたが、とてもわかりやすく内容も
すばらしいので、理解するために読むには最適です。（ひにもの / 2008-07-27）

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

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

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

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

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

プロジェクト管理の要諦を、物語仕立てで描いたものである。
テーマは主にプロジェクトチームの活性化やプロジェクトメンバのケアについてで、
トムデマルコの著作のなかでは「ピープルウェア」に近い。
いつものようにその指摘は鋭く、切れ味はよい。たとえば、
　・一日をむだにする方法はいくらでもある。しかし一日を取り戻す方法はひとつもない。
　・プレッシャーをかけても思考は速くならない。
　・我々は味方同士である。敵は問題そのものだ。
などなど。ニヤリとさせられる箴言ばかりである。
ただし理論的ではなくあくまで経験論的なので、
プロジェクトマネジメントの初学者にはピンとこないかもしれない。
逆に言えば、経験に応じて光って見える言葉も違ってくるだろう。
何度も読み返して自分自身の成長を確認する、という読み方もよいかもしれない。
一読の価値はある。（丁三 / 2006-11-23）

ピープルウェアの作者でもある、トム・デマルコの思想は、徹底的に、人間を善人としてみていて、気持ちがいい。 それはしかし、単なる楽観主義ではなく、ソフトウェア開発コンサルタントとして長年働いてきた経験に裏付けされたものであろう。
管理者が管理するのは数字ではなく、「人」なのだ、という、ピープルウェアでも貫かれていた思想が、より強力に打ち出されている。 しかもそれがエッセイや論文でなく、なんと小説で！！ 小説になっていることにより、エンターテイメントとしても一級の作品になっている ただ、この面白さがわかるのはソフト開発者に従事する人間だけではあろう。
しかし、その分、ソフト開発者が読めばこんなに痛快で面白い本はないとおもう。一読の価値あり！（ / 2001-04-13）

著者はソフトウェアの世界では有名な人物のようであるが、いやいや小説家としても中々の腕前のようだ。
「ソフトウェアのプロジェクト管理に関する参考書」という捕らえ方もできるが、純粋に「小説」だと思って読んだ方がいいように思う。小説として楽しく読み進めながらも、そのなかで自然にプロジェクト管理に関するノウハウを知ることができる、参考書としては非常に優秀な本だ。
参考書とするには中で述べられる「１０１の法則」は概念的で具体性に乏しいものが多いのですぐに使えるものではない。かと言って役立たずではもちちろんないが･･･。
中で使われている言葉は専門的なものはほとんどないので、ソフトウェアの開発経験がなくとも十分に理解できる。何らかの開発経験があれば十分に楽しむことができるだろう。（本格派 / 2006-05-10）

この本の主人公「トムキンス」と同じ立場の人なんて、ほとんどいないでしょう。
なにしろ、国家プロジェクトである重要なソフトの開発総責任者という立場なのだから。
この本には主人公を助けるスーパーマンさながらの人物が沢山出てきて、次々起こる問題を解決していきます。
１週間あれば十分読めるほどの容量ですから、あまりの急展開に正直「そんなにうまくいくか！？」とか
「ありえない。。」と思う点もしばしば出てきますが（自分が普通の底辺プログラマ＆設計者だから
というのもあるかも知れませんが）、新発見や再確認など出てくるポイントが的を射ていてズパリな
「やや抽象的な」法則が出てきます。全てそのまま使える法則という訳ではありません。
ですので、法則をかいつまんで自分で咀嚼し、吸収する、ということをやらないといけないと思います。
その過程を経て初めて役に立つ本となることでしょう。
一通り読んだ感想として、ソフトを成功に導くためには「人を扱う力」「人に接する力」が大事なんだなと感じました。
あくまで自分にピッタリ！というわけではなかったので星４つです。（zico / 2005-12-13）

スイスイ読んでしまいました。ピープルウェアも確かに平易ですが、小説形式である分さらにこちらの方が読みやすいです。現実的にありえない設定でオイオイとツッコミ所満載ですが、理想論としては本当はこうできたらいいなと思うことが色々書いてあります。日々悩みもがくなかの、判断基準の一つ、リファレンスとして、別の著作のピープルウェアと同様価値があると思います。
ただし、こうできたらいいけど、なかなか難しいな、物によったら無理っぽいな、という状況が並んでいるのを読んで、読者が理想論に過ぎないと拒否反応示す場合もあるのでは？と心配になりました。（デッドラインは小説中の凄い設定が特にそう思わせる）
周囲の環境に恵まれた経験と、コミュニティとして機能していないチームでの!!経験がある人なら、うなずける部分がそれなりにあるのでは？と思います。表現が多少大げさだとか、定量化できないから上司を書いてある通りの方向に納得させにくいな、と思う部分を差っぴいても、一度は読むことをお勧めします。（悩み多き頭でっかち / 2002-04-18）

テスターをやっています。
テストは新人開発者がやるもの、とかよく聞きますけど、本当なんでしょうか？今所属しているテストプロジェクトは未経験者を採用しています。それは仕方ないですが、初日に「OSって何ですか？」と聞かれました。テストマネージャーには「できるだけバグを出さないように」と言われています。要するにテストチームは素人集団で良い、ということになっているのでしょうかね。あまりに落胆したので本書を衝動買いしたところ、期待以上にしっかりとした内容で、それもコンパクトに書かれていて気に入りました。電車の中で読みながら、これが仕事の基本だよなーと平常心を取り戻すことができました。著者の方、ありがとうございます。タイトルの「知識ゼロから～」も気に入っています(いざとなったら「これくらい読め！」と投げつけられる？)。
今度はぜひ上級者(というか、テストの理想を追い求めたい人)向けに書いて欲しいです。よろしくお願いします。（ / ）

　最近ソフトウェアテストの本が結構出てるけど、みんなページ数多いし字も細かいし、なんかソフトウェアテストの入門にいい本はないかなー、と思っていた矢先にいい本を見つけました。
　筆者の方はMicrosoft、SAP、ソニーといったビッグネームでテストを担当してきた歴戦の古参兵だけに、載っている事例も具体的かつ実のある（そしてちょっと苦笑いさせられる）内容です。
　恥ずかしながら、私はソフトウェアに携わる仕事をしていながらも、この本で自分の知識の浅さと狭さに気づかされました。開発工程の何割かを占めるテストについて、正しい知識を身につけることは大切ですね。
　これを読めば明日からの仕事がバリバリ進むという本ではありませんが、ソフトウェアのテストについて知る入り口としては最適だと思います。（ / 2005-03-07）

ソフトウェアの開発手法やテスト手法というのは、どこにも完璧なものは存在しません。
それを踏まえた上で、如何にうまく付き合っていくかを、筆者の豊富な経験に基づいて
書かれた書籍です。内容が正直でとても共感が持てます。
テストの本質が何か、そして何が大切であるかを、平易な内容でわかりやすく語られています。
テスト担当者でなくても、その管理者、そしてプログラマーの方にも是非読んでいただきたいと思う一冊です。（tagachil / 2007-01-19）

バグが発見されると大騒ぎされる会社(ＭＳ，ＳＡＰ，ＳＯＮＹ)
を渡り歩いている著者によるテストの教科書本です。内容としては、基本情報処理の資格取得した人が実務でテスト業務をする際に身に着けるべき内容となっています（少なくとも知識として知っておくと、よい）。
詳細を説明すると（ホワイト・ブラック）*ボックステストの基本手法から始まりシステムテストやソフトウェアテスト運用（費用対効果に優れる手法とは）そして、品質管理まで包括的に含まれてます。１テスターとして感じることと、管理者（著者）が感じることがかいてあります。
そんなテスト体制より、こっちのほうがいいですよとか
ですマーチは御免ですたいというＰＪを見分けるのに役立つかも（当然改善にも）
30代前半までに、著者の書かれた経験をされた方には、
自分の会社のテスト体制に一言言える状態になるかなって感じです。（こると / 2006-01-03）

注)ソフトウェア開発者としての意見です。
この本は、タイトル通り知識ゼロから学ぶに適した本だと思います。
簡潔にわかりやすく、テストの手法などについて学ぶことができます。
テストの本に関しては、読み進めていくのが難しい書籍がありますが
まず始めの一冊として読んでみてはどうでしょうか。（ノグチョ / 2005-11-25）

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

ＰＭ関連の本は、本当にたくさんたくさんあります。
気をつけなければいけないのは、杓子定規でいわゆるセオリーやロジックが記述されているものを間違って購入しないようにすることです。
資格をとるのであればいざしらず、資格はフォローはしてくれるかもしれませんが、実践に直接的には役にたたないことは、実践している人たちはよくわかっていると思います。
この本は、示唆に富んだ具体的に共感できる本でした。
特にコミュニケーションや目標設定など＜ヒト＞の共感や理解を重視した箇所については、とかく指示的にいきやすいＰＭとしては、ありがたい教えです。
また、あちらこちらにあるＴＩＰＳのようなコメントは苦しいときや大変なときに、振り返って見ると、冷静になって対処できるような気がします。
「ＰＭの８０％の仕事はコミュニケーションである」
「勝者は目標を設定し、敗者は言い訳をする」
なんて、最高じゃないですか？？？
時々に再読することをお勧めします。
さすがＩＤＩＯＴ　ＢＯＯＫ（バカでもわかる本）シリーズですね。（パタ / 2007-03-20）

この手の本は、世の中たくさんあると思いますが、PM経験者、非経験者を問わすお勧めの一冊です。実務に即した内容で、プロジェクトを進めていく上で、起こりうる事象と、それに対する対処が細かく記述されており、特に、社内政治のケアまで書かれているのは、見事です。特に、海外と仕事をされる方は、日本と進め方が大きく違うので、会議などで、会話の文脈を合わせるのに非常に役にたつと思います。（takeshs / 2005-10-20）

プロジェクトマネジメント関連の本には、どうやって計画するか、どう考えるかというものが多いが、本書はどう解決していくかを理解できる本である。プロジェクトは生き物であり、そもそもの計画がそのとおりになることはない、問題が起きたときに実際に対応するのはプロジェクトリーダーでなくチームであり、関連する人たちの感情をも考慮にいれプロジェクトを成功裏に導く方法を総合的に理解することができる（99 / 2006-10-15）

先輩に薦められて購入しました。
具体的な事例を示し、初心者にも大変わかりやすい内容で記述されています。
はじめて学ぶ本としては最適だと思いました。
私はまだプロジェクトマネージャーの仕事をしていませんが、
これを読むことでプロジェクト全体の流れや、重要なポイントが
見えてきたと思います。
仕事をしていると、色々と悩むことが出てきますが、そういう時の指標になる
良い本と思います。
（真 / 2009-04-20）

Idiot's Guide（アホの為のガイド）とあるが、随所にワンポイントの言葉と絵が挿入されており、理解を助けてくれるのが良い。判り易く読み進むうちに専門的な知識が身につく実用書としてプロジェクトリーダー・メンバーに勧められる。これで期限通り・予算内でのプロジェクト打ち上げの美酒を味わえそうである。（MM / 2005-06-14）

下の方同様、前半は非常にわかりやすく3章まではよく理解できる内容です。ですが業務別データベースの設計は初心者には理解できません。実際の仕事を経験し、仕事の流れを十分にわかっている方でないと読めないでしょう。初心者の方に対してだけの評価で☆二つとさせていただきます。（オダー / 2002-10-18）

データモデリングの考え方と業種ごとのデータモデルの例からなる本です。得に、前半のデータモデリングの考え方は、非常に、わかりやすいものです。専門家以外にもわかるように、丁寧に説明してあります。
このデータモデリングの考え方は、情報システムだけでなく、いろいろな場面で応用できると思いました。わかりにくい資料を作らないため、自分の持つ情報を整理するため、等です。情報を扱わない仕事をしている人は、いないと思います。前半だけでも、日々の仕事に十分なヒントを与えてくれる気がしました。
後半は、少し、しんどいですが、前半だけでも、元は取れます。
比喩の使い方、説明の方法が、エンジニアっぽくって、鼻につきましたが、ま、愛嬌です。（lemonerika / 2002-05-24）

渡辺式ＥＲ図は階層構造が直感的に解りやすく、Windowsでエクスプローラのツリービューを見慣れている人には最適の図法だと思います。（それでいてもちろん、部品表のような再帰的構造も表現。）
これを読まずに安易なＤＢ設計で走ってしまったら絶対後悔しそう。　実装の面で悩んでしまうような難しいところもありましたが、妥協するにしても、知った上でするか否かは大違いだと思います。　これを読んで悩みましょう！（ / ）

第一部で著者は、システム屋と業務屋の溝、意思疎通のインフラ整備の遅れを嘆いている。本書の初版が２００１年。それから４年以上経った現在、状況は何も変わらない。我流ＵＭＬなどが出回ってむしろ現場は混乱する一方だ。小手先の技術でごまかしても本質は何一つ変わらない。
システムと業務知識が双方向で解説された本はいまだ数少ない。その意味で本書は４年経った現在も色あせていない。流行ばかり追うよりも本書のような汎用的なスキルを身につける方がはるかに大切だと思う。
データモデリングと業務知識を分離せずにコインの裏表のように一つのものとして解説している。後半がやや駆け足気味だったのが残念。（たけぞう / 2005-09-22）

これすごく良いです。例えばあたらしい業種の仕事が入った場合なんかはもうすごく役に立ちます。僕の場合は実際、生産管理系の仕事なんかしたことがなかったのですが、これでとてもよくわかりました。
一般的に業務の視点から書かれた本なんかは、その業務については確かになんとなくわかった気になるのだけれどもそれだけじゃあ果たして、『じゃあそれシステムとして考えたときにはどうなるの？』ってのがすっぽり抜け落ちていたりします。
或いは逆に、システムの視点からの本だともうシステムべったりで業務の現場おかまいなしのはなしばっかりだったりして、実際に仕事になったときに『ああ、本にかいてあるみたいにうまくいくわけないじゃん、例外だらけ。』みたいになりがち。
これ、その間を上手くとりもってくれている本だと思います。ですからまあ、でもやっぱりどっちつかずってとこもありますが、それはそれこの本を読むことで業務とシステムの間はどうなっているのかがぼんやりわかった上で、さらにそれぞれの専門書を読んだり実践で経験値高めていったりしなくてはならないですが、まあこの本のタイトルにもあるように、これ『入門』ですから。これでいいのだ。（tetsu-o6 / 2005-09-16）

全体的なアジャイル開発の進め方、という意味では割とあっさりとした、でもポイントは抑えた内容かな、と思いました。
素晴らしい点は、
開発の重要なポイントは「コードを書くこと」という観点で、
OOPの原則、デザインパターンの説明をしつつ、
アジャイル開発らしく、
「実際に動く」「変更を受け入れる」「簡潔なコード」を
重視した実装をどのように進めていくかが、
とてもよく解説されています。
「基本」と「応用」を一体化させたような印象で、
まさに「奥義」とはこういうことを言うのかもしれない、と感じました。（ / 2004-08-21）

この本を読むまで、Singletonってなんのことかさっぱりわかりませんでした。
16章の「singletonパターンとMonostateパターン」を読んで、はじめてああ、そうだったのだわかりました。
Singletonは単一生成、monostateは単一状態なのですね。なぜ、みんな日本語で言わないのでしょうか。たしかにプログラムで書く用語は、プログラムの用語のままの方がよいことはわかります。でも、翻訳するのなら、日本語に翻訳すれば、意味がわかって、説明が同じ量でわかります。そのため、singleton(単一生成)、monostate（単一状態）でよいでしょうか。single, monoの語幹の意味の違いがまだよくわかっていません。
翻訳しない単語は、意味をわかるのに、説明を訳注として追加すれば、同じ水準まで理解が進むと感じました。よろしくお願いします。
（kaizen / 2008-07-11）

特に、オブジェクト指向の原則、プラクティスなど開発者に
とってかなり有意義な内容だと思う。
他の本でも似た内容がちらばっていることはあるが、原則、
プラクティスとしてまとまっていると理解しやすい。
欲を言えば、デザインパターンの部分が多すぎるから、減らして
安くしてほしかった。（ / 2004-09-22）

中身は大変難しいです。GRAPというパターンはこの本で初めて知りましたが、大変有用なものです。
初めて.NET Frameworkでシステム構築するプロジェクトに参画した当時、
誰もオブジェクト指向のことは知らず、また会社が「講義を受けさせよう」という気が
全くなく、オブジェクト指向言語なのに、多くのメンバーがスクリプト的なプログラミングをするという酷いプロジェクトでした。
ですが、ほんの数人はオブジェクト指向を勉強しようという気があり、その中でも絶大に勉強に意欲を示したのが私でした。
通勤、退社の社中では必ずオブジェクト指向とUMLの本を読んでいました。
この本のタイトルは「UML」が前面出されていますが、活躍の場はUMLにとどまることを知りません。
ぜひ、目次だけでもご覧になってください。（カザミ / 2009-12-30）