リスト：引継ぎ資料 を表示しています。（全 23 件）

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

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

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

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

　
小説を読みながら、ＴＯＣ理論が理解できるので良いです。
　
小生なりの理解では、経営工学とは、
１）工場の生産性向上
　　　　原材料調達・生産計画・工場管理/改善・工程管理/改善・原価管理など、た
　　　　ぶん、工場の生産性に関する全ての理系的アプローチが含まれる。
　　　　そして、最近、トヨタ式生産方式（の考え方）が、郵政公社の作業効率改善
　　　　に役立てられるなど、もしかしたら、対象は工場に限らないのかもしれない。
２）作業の効率向上
　　　　ここでいう作業には、生産/製造活動・設計作業・実験作業、物流運搬作業
　　　　など、たぶん全ての作業が含まれる。
を目指した工学的（実践的）学問ですが、
その経営工学の中にある制約理論を、ドキュメンタリ風の小説を読むことで難なく
理解できてしまいます。
　
とうわけで、経営工学を学ぶ人は当然として、文系・理系を問わず、読んでおいて損
は無い本です。

（kakitsubata_1990 / 2007-02-04）

アメリカのMBAとかにおいて、オペレーションマネージメントの授業中にも触れられることが多いというこの本。製造業において、どのようにして生産効率を高めれば良いのかという命題にこの本は答えているが、面白いのは問題解決のプロセスだと思う。
現場や営業サイドと連携しながら、単に製造することだけに留まらない効率化が図られている過程を知ることは実に勉強になると思う。縦割り的な日本の大企業にいる人にはお勧めかも。
（ピンク太郎 / 2006-08-04）

私は本書を読んで、その改善プロセスも興味深かったが、それ以上にその改善プロセスを生み出していく過程・アプローチに大変興味をもったので、それについて述べる。
1.コーチング手法によるアプローチ
　本ストーリーは、所長が偶然に再会した恩師に改善の方法やポイントのアドバイスを求めるが、恩師はアドバイスや回答は示さず、逆に質問をして所長に答えを探させるという謎解きの手法で展開していく。これは小説的には推理小説のように謎解きで読者の興味を誘う手法であろうが、私には単純にそうは思えなかった。
より高い成果は、人から教えられ与えられたものでは得られず、自ら悩み考え出したもので得られると考える。すなわち、上司は部下に対して解決策等のアドバイスや回答を一方的に示すのではなく、部下に質問することで部下を悩ませ考えさせ、そして対策案を引き出し実行させる。部下は自分の発案であるから、やる気が出て、自発的に実効ある行動をとり、より高い成果に繋がっていく。これは、「答えは相手の中にあり、上司はそれをうまく引き出し、自発的な行動を促す」というまさしくコーチングの手法である。
2.組織を超えての検討チーム
本書で改善を中心になって進めるのは、所長・製造担当・経理担当・資材担当・データ処理担当といった、時には敵対しかねない立場の異なった５人である。しかし、彼らが目標達成に向けて侃侃諤諤議論して成功へと邁進していく。このことは本来あたりまえのことだが、現実にはうまく機能していないのが実情であろう。すなわち、それぞれの立場を背負っての検討チームではなく、立場を超えて自由に論議・発案できる、組織を超えた検討のできるチーム運営の実現が必要である。
3.家族（第3者）のサポート
忘れていけないのが仕事には直接無関係の家族（第３者）によるサポートである。所長の夫婦関係は最初はお互いの立場を理解しようとせず溝がふかまり離婚の危機となったが、お互いが関係修復に向けて努力した結果、お互いの立場を理解しあい、お互いの悩みを共有し、まずは夫の仕事の悩みに対しての会話が出来始めアドバイスができ解決に繋がった。仕事とは全く無関係の異なった観点からの見方・アドバイスではあるが、このようなことが出来る夫婦関係は理想的と言える。さらにキャンプでの隊列の進行速度やマッチ棒ゲームを生産工程にたとえて考察したり、子供との会話の中からもヒントを得るなどは、問題解決に真剣に取組んでいればどのようなものからでもヒントを得ることが出来るということを教えてくれている。
著者は本書の後記の中で次のように述べている。
・本書は改善プロセスのスケジューリングソフトの宣伝ツールであったが、高価なスケジューリングソフトを導入した企業より、本書を読んだのみで改善を図った企業の方が大きな成果をあげたケースがあった。
・また、本書を教科書として社員教育に取り入れた企業でもうまく改善ができず成果が出せなかったケースもあった。
この両者に共通しているのは、自ら取組んだものではなく他人から与えられたものへの取組みである。すなわち、当事者が自分のものとして認識せず、その気にならなかったから成果につながらなかったのではなかろうか。（岡　敏充 / 2002-02-04）

毎日、工場のラインに立っている私にとっては、目新しい情報はなかった。
本当に米国の工場では、こんな悠長なことをしているのだろうか？
この本に出てくる工場は日本の財政・行政を見るようだ。
官僚主義と前例主義の呪縛につかまっている。
この本を読んで、ゴール（目標）とプロセス（制約条件）を見極めてほしい。（ / ）

工場での業務改善の様子が物語風に書かれている。
工場の専門知識がなくてもわかるようになっており、文体も話し言葉がほとんどで会話をしながら主人公と一緒に学んでいくという形式になっているのでとても読みやすい。
企業や工場の本当の目的な何なのかというところから、根本的な問題を見つけ、その見つけ方を解明し、問題を解決する方法を探していく。小手先だけの解決ではなく、パラダイムシフトが重要だということが言われている。
読み進めながら、なるほど！確かに！という感動が次々に浮かんでくる。
また、この思考プロセスは特定の工場だけでなく、会社全体や人生においても同じことが言えるのではないかと思われる。（ＭＩＬＫ / 2006-12-02）

"The goal"の最後にゴールドラットは"how come the project never finishes on time"と現代のプロジェクトというタスク単位が納期を守れない事に着眼点を置きます。これに対しての分析とTOCによる解決方法がこのCritical chainに書かれています。自分はSEという職業柄常に複数のプロジェクトを見ていますが、面白いほどゴールドラットのプロジェクトの分析は的を得ています。今後自分がプロジェクトを管理する立場になった時は是非ゴールドラットのTOC理論を当てはめてみたいと思います。（ / 2001-03-23）

本書はプロジェクトに関わる者が持つ悩みに、実用的な解を与えるクリティカルチェーンプロジェクトマネジメント（CCPM）の啓蒙書である。CCPMは、PMにTOC理論を適用した手法であるが、この本が出た２００３年１０月頃はまだまだ知られていなかったが、最近では本書の日本語訳の解説を書かれている津曲氏のコンサル会社（エリヤフ・ゴールドラット・インスティチュート認定）の指導により幾つかの会社で導入実績がある。
物語はエグゼクティブ向のMBAコースでプロジェクトマネジメントの教鞭を採るリックが、TOCの理論を実際のプロジェクトに適用することで、CCPMを確立していく過程をドラマティックに描いている。このMBAコースにTOCを浸透させたキーマンは製造論担当のジョニー（ゴール２でアレックスがCEOになったユニコ社で一年間TOCを学ぶ）であるが、その陰には、ユニコ社で副社長を務めるドン（アレックスの懐刀）の目論み（社内でTOCを教えるのではなく、学生にTOCを教えてくれる大学を育成すること）があった。
本書では、大学が真に社会に役立つ教育を提供しているのか？という問いかけもあり、とてもアメリカらしい状況設定になっている。また、アメリカにはプロジェクトマネジメント学会もあり、実務的な手法の開発に対する科学的なアプローチがなされている。日本ではこのような実務能力の向上を大学教育に取り入れているところはまだまだ少ない（千葉工業大学　社会システム科学部　プロジェクトマネジメント学科など）。本書を読んでCCPMの手法をきちんと理解したいと思う人は、CCPMに関する良書も幾つか出てきているので、それらの本を読まれることをお勧めする。（私撰　綜（市川聡：さとる） / 2007-01-17）

ベストセラー「ゴール」の著者が、TOCをプロジェクトマネジメントにあてはめた小説仕立ての本だ。従来のクリティカルパスに、一番不足する資源（例：特定スキルの社員）のタスクのパスも組み合わせたものがChritical Chainであり、一番の管理対象となる。
ただし、この本に書かれている通りそのまま実現するのは難しい。例えば、タスクの実現可能性５０％の期間を見積もるのに、現在の見積もりの３分の１という期間が示されているが、なぜ３分の１なのか明確な証拠が示されていない。実は、この点は現在でも明確な説明がない。また組織文化的に厄介な部分もある。他にも批判的に読めば、このままでは使えない点に気づくだろう。
評者は実際にChritical Chainを使用してスケジュール管理をしている組織を知っているが、この本の通りには行っていない。また専用のソフトウェアを使用している。
考え方は使えるので星４つだが、そのまま使おうとするとヤケドするので注意。（やまちゃん / 2002-09-09）

デマルコの「熊とワルツを」で紹介されていたので読んでみました。
TOCの説明本と思いきや、小説として十分楽しめます。登場人物もみな立っていて続きが気になり厚さはまったく気になりません。
教える立場にある人は主人公の教え方も参考になるのでは。
しかしTOCをプロジェクトにすぐに役立てたい!という実利を求めて買った人にとってはそんな描写はいらん、と思いそうな気はします。
プロジェクト運営にすぐに役に立つかは ? ですがとりあえず参考にはなりそうです。
クリティカルチェーンの話はもうすこしつっこんでしてほしかった気はします。（nekot / 2004-01-05）

確かに前3作程の新しい理論はないが、
ストーリー的にはおもしろい。
TOCをプロジェクトマネジメントに活用した話。
TOCに関する復習と応用方法を知ることができる。
副題の「なぜ、プロジェクトは予定通りに進まない
のか？」に対する回答はしっかり本書で納得。
「TOCをぜひ活用してみよう」と言う気にさせる
本だと思う。（coolsunnyday / 2003-11-30）

日本語のSubversion解説本の中では間違いなく１番良い本だと思います。
Subversionを使う上で必要な基本知識をほぼ満遍なく網羅しています。
今回の改訂で最新メジャーバージョン1.4に対応。巻末にコマンド一覧が
付いているので、ちょっとしたリファレンスとしても使えます。（asip / 2007-05-08）

遅ればせながら、Visual Source Safeからの移行を検討するためにSVNを調べていました。
ネットでSVNを調べると、trunk,branches,tagsが出てきます。
これらを理解するために、本書を買いました。
これらに使用方法について、図を使ってわかりやすく説明しています。
ネット上の情報もいいけど、やはり本なので見やすく、理解しやすいです。
なお、ページ数も少なく、１日あれば読み切れます。（積読になりません）
日々の激務で忙しい開発(管理)者にぴったりです。（孤独な開発者 / 2008-12-07）

Subversionを(サーバ管理者として ではなく)使う上ではなかなかよい本ではないかと思います。各種コマンドの用法、ベンダソースなどをリポジトリに含める上での考え方など、丁寧に書いてあると思いました。
しかし、サーバのセットアップ、Apache上でSubversionを動かすためのconfファイルの設定、よりよく使うための設定の記述方法など、サーバを管理するための情報についてはさらりとしかまとまっておらず、結局インターネットで調べ回って何とかする という部分が多かったと思います(たとえば、設定によっては頻発する301や405エラーの回避方法など)。
サーバを作る人としてはここが一番詰まるところであると思いますので、もう少し詳細に記述していただきたかったです。（高見知英 / 2007-07-01）

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

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

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

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

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

　SEが中堅へステップアップするためには最適の本です。上流工程の整理方法について、今まで理論や方法論を解説した本を何冊も読みましたが、これだけ「現場」に近い感覚で即戦力になる本は皆無でした。作者は独自のノウハウを織り込みながらわかりやすく解説していきます。私の２０年のＳＥ経験からみてこの手法は充分納得出来るものでした。若い方だけでなく、中堅以上の方にもお奨めします。
　簡単にこの本の手法を説明します。上流工程の方法論として、処理を最初に考える方法(Process Oriented Approach:POA)と、データを主体に考える方法(Data Oriented Approach:DOA)が一般的です。この本ではDOAを主体としながらも独自の方法論をとっています。
　処理を「機能」と「業務」にわけて、業務とデータを同時に分析し、その後機能を分析するのです。新DOAと言えるかも知れません。業務はデータ・フロー・ダイヤグラム(DFD)で整理し、データはER(Entity-Relationship)図で書きます。このDFDもER図も「渡辺式」と言うべき独自の作図法です。DFDは「タイミングを表せない」という欠点をなくし、ER図は「実データ（タプル）を描けない」という欠点を完全に取り除いてあります。最後に機能分析ですが、ここでも驚くべき手法を提案することで、若手でも簡単に機能分析が出来る仕掛けを用意してあります。
　大変読みやすい本ですので、実用書と思えるかも知れませんが、バックボーンの理論もしっかりしています。著者はデータモデリングの本を既に２冊書かれた方です。この本がSEのバイブルになることで、不幸せなシステム開発が１つでも減って欲しいと思います。（hat / 2004-05-05）

上流工程には唯一無二の方法論は存在しないながらも、何らかの道しるべが欲しいという方には一読の価値はあると思う。具体的な業務フロー、データモデル等の書き方も参考になる。また、最後にまとめとしてセッションを会話ベースでシミュレーションしているのがリアルで理解を助けてくれる。自らの方法論を構築するためのベースとしての知識は網羅されている。（ / ）

非常に手堅い、堅実な本です。若いエンジニア、特に「Webアプリケーションの開発からキャリアをスタートし、基幹系業務システムの経験が薄い」エンジニアに強く勧めたいです。
著者は、業務システム（ビジネスシステム）の上流工程について、輸入された理論や知識、図法を形だけ適用するのではなく、現実の経験に照らして整理しています。
その態度は、まさに「工学的」で、非常に勉強になります。デスマーチ的な日々に埋没しがちな私は、尊敬しないではおれません。システム開発を成功させ、顧客に利益をもたらすためには、こういう工学的な態度を持っているべきだな、と。
他のレビューではあまり触れられていないようですが、本書の後半に列挙されている「上流工程で適用できるパターン」の考え方は、特筆に値すると思います。
最近では、「パターン」といえば「デザインパターン」であり、設計以降で利用されるものとしてとらえられていますが、著者は上流工程でのパターンとして、「業務フローのパターン」「データモデルのパターン」「機能モデルのパタ－ン」「サブシステム分割のパターン」の４種を挙げ、抽出を試みています。
若干、一般化が進みすぎているという感はありますが、業務に関して一般的な知識を得ることができ、とても有意義です。
あえて難点を挙げるとすれば、DFD、ERともに著者によるアレンジが加えられていることでしょうか。
アレンジ自体は、著者の優れたアイデアであり、書かれていることはよく理解できます。しかし、実務で使おうとすると、ER描画ツールが対応していないのです。また、他のエンジニアに、記法から説明しなければならないのです。この点は、やむを得ないところですが、読者の側に若干の注意が必要なところになります。
とはいえ、全般に読み応えのある、よい本です。経験則や、現場のやりかたに慣れて、より良い方法を考えるのをやめてしまいがちですが、この本はそうした惰性を断ち切るチカラになるでしょう。多くの人に読んでもらいたいと思います。（izagon / 2005-05-19）

私は、筆者が上流工程を設計されたシステムを今でも担当しています。筆者が設計されたＤＢの素晴らしさは、７年経った今でも色あせることはありません。筆者に５年ほど前に上流工程について講習をうけたことがあります。そのころ私は、ＳＥとしての経験も浅く正直筆者の話に感銘はうけましたが実践するまではいたりませんでした。それからの５年間で私自身いくつかのシステムを立ち上げましたが、その中で筆者より教わったことを断片ながら応用しシステムの立ち上げに役立てることができました。今回この本を購入し読み進んでいく中で、私が最近感じているシステム開発の難しさ、それに関する解答を見出すことができました。すばらしい本です。（kanzaburo / 2005-05-08）

今までＳＥとしての訓練を受けたこともないまま
次の開発で要件定義を書く担当になり、途方にくれつつ
参考になる本を探して、最初に見つかったのがこの本。
読んでから業務に取組み始めると・・
◆基本設計／詳細設計という言葉がプロセス、データモデル
　といった領域を無視したように語られているのがこの本を
　読んだ後だと不安
◆他の本も参考にしてますが、この本のデータ、プロセス、
　システム機能といった区分が一番しっくりいく
結局はこの本が座右の書になりそうです。（趙子竜 / 2004-01-20）

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

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

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

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

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

私にとって探し求めていた一冊。　渡辺式ＥＲ図は非常に見やすく、提示されているデータモデルは極めて具体的で非常に参考になる。
わたしはSEではなく、どちらかといえば生産管理担当者側の人間だが、生産管理そのものについても、非常に参考になった。
具体的な実装において、とくに「継承属性」の実装が、専門家でない私には困ってしまう。（各RDBSの機能による）これはこの本のテーマの範疇外だそうです。（ / ）

　システム設計屋からみて、初めて実践に役立つ本に
出会った思いです。現場を知ってる方が書かれた生産
管理手法の説明です。「本物」の迫力があります。
　部品表の展開やバケット管理などＤＢ構造を前提に
しないと説明出来ないのですが、今までの本はそこが
おろそかにされていたため学術書の域を越えませんで
した。この本はシステム屋にとっての実用書です。
　初級～中級のシステム屋さんは是非これで勉強して
欲しいと思います。（hat / 2003-08-07）

デザインパターンのDOA版。
業務はわかるが関係データモデルへの反映の仕方がわからない、
データモデリングはやっているが、よいお手本がない、といった方にいいと思います。
とかくファイル転がしになりがちな生産と原価システムに対して
DOAのモデルを示している良書です。
メインフレーム上がりの設計者は必読です。（へっぽこSE / 2002-11-26）

私は10年から15年も前に作られたIBMのAS400で稼動する生産管理を保守しております。
この本を読んで自分の目の前に在るシステムと比べると、うなずける部分がこの本にはいっぱいありました。
本が提唱するＤＢ設計になっている部分は、なんら問題なく今も動いています。（あまりにもＤＢ設計が似ているのでビックリです）
未来在庫の予測などは勉強になりました。
トリガー機能やジャーナル機能の存在をこの本で知りました（無知で恥ずかしいです）
受注と出荷の関係や発注と仕入れの関係も良く理解できました。
ＤＢの正規化のプロセスが存在するなんて知りませんでした。
今までの経験でなんとなくＤＢを追加していましたが、正規化を知っていればもっとマシなＤＢが追加できたのにと悔やみます。
このような有益な本を出版して頂いてありがとうございました。（object_brain / 2006-04-27）

業務系、特に生産管理のシステム設計についての本が少ない中で
実務で役に立ちます。「渡辺式ＥＲ図」は手書きでは書きやすい
のですが、仕様書をＥＸＣＥＬやＶＩＳＩＯで書くときに困ります。
著者はモデルリング用のフリーツールも作っているので
一度、参考までに見てみたら？
あくまでモデリング（概略設計）用で、ＤＢの詳細設計には別のツールが
必要ですが。
（masabun / 2006-02-11）

10年早く読みたかった。
そうすれば、不合理なコード体系に振り回されて工数を空費することもなかったし、DAOの粒度を無意味な大きさに統一することもなかった。まだ記憶に新しいアノ不具合も作りこまなかった。後悔しきりだ。奥付を見ると２００６年の出版とある。となると最短で読んだとしても、あの不具合とアレくらいしか救えなかったかな…それでも結構大きいぞ…と胸算用してしまった。
そのくらい生々しいノウハウが、書かれている。
著者が失敗から学んだことだろう。私も似た失敗をして学んだことが多く書かれていた。だから技術書なのに"赤裸々"な感じがするのだ。
勘定系システム開発とは切っても切れないデータベース設計での失敗、落とし穴、そして肝心の回避策が多く書かれている。そんじょそこらの先輩・研修講師には決して教えてもらえないような質・量だ。１年生には難しすぎるけど、２年生なら十分に読みこなせるだろう説明の仕方もすばらしい。
（kimitoitoko / 2009-01-16）

この本は、DB設計の肝であるERDについて書かれています。
筆者の経験とこれまでに読んだモデリングの本の知識がまとめられており、
実際の伝票や請求書のフォームから、適切なER図を描くにはという点や
SQLにまで触れられています。
ただ、ERDというかデータベース設計を行う上での基本的な用語については
解説されてませんから、それらは別の書籍などで補う必要があります。
その様な入門書を読んでみてSQLを多少触ってみて、さてこれから実際に
どうしようという時に、この本は強い手助けになるのではないでしょうか。
（Ａｋｉ / 2006-11-13）

モデリングについて、筆者が経験上培ったものを
まとめた書籍です。
モデリングには「これ」という正解がある訳ではないので、
読者がこの書籍に書いてある内容をそのまま参考に
するかどうかは、読者自身の判断になります。
モデリングの実習がもう少し多ければよかったです。
少し物足りない感があります。
やはりモデリングは経験が大切と感じます。
理屈ではなく、失敗を繰り返しながらベストな
方法を体で覚えていくのでしょう。

（tagachil / 2006-06-22）

RDBのテーブルの設計やらモデリングやらのポイントを丁寧に説明している本です。
自分は、特に、モデリングの部分がおもしろかったです。
実際のレシートやら図書館の予約表やらを題材にして、
そこから得られる限られた情報から、時には十分説得力のある推量もまじえて、ぱぱっとE-R図をつくっていくようすがとても参考になります。
題材を見たら、まず自分でE-R図をつくって、そのあとで説明を読むようにしていました。
「ああー自分のモデリングではそこは見落としてた」なんてのがしょっちゅうあってためになりました。
こっち方面の勉強中というひとは買いです！
（本屋が好き / 2009-07-24）

順を追って何度も呼んでいくとDB設計の実践方法が身につくように
出来ています。
SI業者さんでなかなか設計の仕事が回ってこない若い人や
ACCESS等のRDBMSの上級エンドユーザにおすすめ。
ただ一点、ERDの表記法IDEF1Xについて、説明が無いのが残念です。
（yasuoy / 2009-12-17）

ＳＱＬを初めて学ぶ時、何をどう書いたらいいのか？
もしかしたらわかりやすい書き方があるのでは？？
と思ってことのある入門者の方にかなりお勧めです。
わかりやすいイラストでイメージしながら
ＳＱＬ文を組みたていけるので、
基礎力はかなりつくと思います。
私も会社の新人教育で自習用に勧めました。
これでしっかり勉強した人は、「ＳＱＬ文作成に自信がついた！」
ってみんないってました。
Oracle, SQL Server などで若干違う箇所があるのですが、
そのあたりのフォローがあるとうれしいですけど
まぁ、気にならない程度ですね。（おぎわら@.net道場 / 2009-02-22）

SQLの実習本を探していて、この本を購入しました。
[悪い点]についても書いていますが、全ページやり遂げられたので星５つです。
勉強期間は、仕事をしながらですが1ヶ月半で全課題が終了しました。
【良い点】
・SQLの「書き順」について書いてある。
（モヤモヤがスッキリしますよ）
・付属のソフトウェアにより、楽しめながら勉強できる。
（気になるバグは無かったですよ）
・SQLの「コードの呼ばれる順番」、「副問い合わせ」など
　重要な点もそれなりに抑えてある。

【悪い点】
・索引が付いていない。
（自分でポストイットなどでマーキングしましょう…）
・用意されているDBテーブルを把握するのが面倒臭い。
（DBテーブルは8つ程用意されています…）

マジで「索引」さえあればPERFECTだった本です・・・（T-MAX / 2009-07-15）

のみならず、「リレーショナルデータベース管理システム」は今後必須の知識なので、確実にものにして行きたい。
栢木先生のシリーズと同じイラストなのに、釣られた＾＾；（向上心≠上昇志向 / 2007-06-28）

非常に使いやすいです。
SIベンダーのデータベース担当に配属されたばかりの人や、
EXCELやACCESSのクエリーを画面でいじっているが、
SQLビューで何をかかれているか理解し活用したいと
考えているエンドユーザーにすすめられます。
（yasuoy / 2009-12-17）

プログラムマネージャーとして働くことが多いため、どうやって円滑にプロジェクト、特にチームを率いていけるだろうかと考えていたころ出会った本です。
仕様書の書き方（なるべく面白く書く）、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）

本屋でこの本を見かけた時、表紙を見て嫌な気分になってしまった。"Will Code For Food"（食べるためにコーディングします）とのダンボール箱の切れ端を掲げたプログラマの成れの果てのもの乞いの写真が載っていたからだ。表紙でかなりネガティブな気分になってしまったのでこの本は買うまいと決めて居たのだが立ち読みして１８０度この本に対する評価が変わってしまった。素晴らしい。「達人プログラマー―システム開発の職人から名匠への道」を彷彿させる良書。単なるコーダーの仕事はインド、中国等の低賃金の国に流れているこの時代にプログラマは如何に生き残るべきかを解説した本。タイトルから著者がインド人プログラマに偏見を持っているのかと印象を受けるが、決してそうでは無く著者がインドに赴任していたこともあり著者の描くインド人像は私の経験と照らし合わせてみてもかなり正確（エネルギッシュで熱意がある、因みに私は三人インド人の同僚が居る）。
著者がRuby大好きの下りを読んで立ち読みしている足でレジまで行って購入。じっくり読んでこの本の良さを再確認。達人プログラマを目指す人は読むべし。（じんけうどんき / 2006-10-14）

オフショアは価格競争の担い手であると同時に、コンペティタでもあるわけですが、ユーザーが利用しているときには味方（必ずしもそうなり得ていない現実もあるのですが）ではありながらも、やがてはそのユーザー自身をも置き換えられてしまうような、諸刃の剣的存在として捉えられることが多いと思います。カバーには物乞いと化したプログラマの写真、そして本書のタイトルが暗示しているかの如く。
しかしながらこの本は、そうした現実を物語る本ではなく、その現実にどのように対処すべきなのか、という著者から技術者への52の処方箋的提案として構成されています。
そしてその提案は、オフショアに対する見方、捉え方、接し方を云々するものではなく、技術者としてどうあるべきなのか、と言うことに終始しているのがポイントで、実は本書の内容は、オフショア云々とは本質的には関係無い、「技術者心得」的なものだったりします。（espio999 / 2006-10-17）

もうタイトルで参った。即買いしてしまった。
なぜ、「My Job Went To India」の部分を日本語にしなかったんだろうと
惜しまれる。そうすれば、もっと売れるはずだ。
日本の場合、地理的要因と文化的背景もあって、My Job Went To China
という感じだが、この業界にいると、職場にどんどん中国人がプログラマで
派遣されてきて、脅威を感じるのは、私だけではないと思う。
そんな人にとてもおすすめ。
目次に「もうコーディングは武器にならない」ってあって、プログラマの
未来はないのかと思わされるが、大丈夫。
それでもプログラマであり続けたい人のための方策も書いてある。
その方策は一言で言えるものだが、ネタバレするので、ここには書かないが
なるほどと思った。同じ土俵で勝負してはいけないんだなと。
それにしても、世知辛い世の中になったものだ。（よろよろ / 2007-10-05）

→ソフトウェア開発者という、「一見して弱い立場」から捉えた
　「仕事の本質」が語られています
　
→殺人的な技術スピード、
　要求を突きつけ続ける上司と顧客、
　そして、押し寄せるオフショアの波．．
　そもそも弱い立場であるにもかかわらず
　さらに厳しい環境にさらされている人々が
　どうやって生き残っていけばよいのかの「具体的な方法論」とともに．．
→著者の　
　１流のミュージシャンと共にサックスを奏でていたことや
　１年半インドに住みながら、オフショアを「体験」したことをふまえ
　ソフトウェア開発が
　「弱い立場」の出口の見えないトンネルのような仕事ではなく
　「魅力的で、やりがいのある立場」の「輝かしい未来を創る仕事」であると
　教えてくれています
　．．５０を超える格言とともに．．
→私はプロジェクトマネージャー志望なので
　この本で書かれているソフトウェア開発者の方々が持っているような
　プログラミングや言語に対する情熱は持ち合わせておりません．．
　．．しかしながら、この本を読んであらためて
　もう一度プログラミングをやってみたいという衝動にかられました
　最新の技術を追いかけながら．．（よこはま　こうたろう / 2007-07-24）

まず題名に魅了された．
なかなか良い題名を付けたと思う．
日本人の著者では書けないような内容が随所にあり，
楽しく読ませてもらった．
アメリカとかインドばかりではなく，
日本は勿論，世界中のどこの職場でも通用するような心構えが書いてあり，
プログラマーでなくても一読の価値あり．
ただし，本の中身は，その題名ほど衝撃的なものではなく，
そこそこ面白い程度と感じた．
オープンソースの勉強を盛んに推奨しているが，
著者自身がその系統の本を書いており，
なかなか宣伝上手だと感心した．
（ジミタカ / 2008-06-03）

リファクタリング時に、こういう論拠で、こうしたら、
デザインパターンになりました、という具合に、
具体的なサンプルを通じて解説してくれます。
先人のノウハウの固まりだから、設計の段階から、
うだうだせずにデザインパターンを使おう、という意見に、
何となく違和感を感じている人には、
特に、読む価値のある一冊だと思います。（palemoon / 2005-09-16）

この本は、リファクタリングによって設計を改善して行く際に、デザインパターンのエッセンスを取り入れて設計を良くしていく道筋を取り上げています。
最初からデザインパターンを使うのではなく、リファクタリングによって、段々とパターンに近づけていく様を、「先輩とペアプログラミングしている」かのように読み進められます。
『オブジェクト指向における再利用のためのデザインパターン』、『リファクタリング』の両書を先に読んでおけば、本書の内容はすんなりと理解できるはずです。（ / ）

～リファクタリング、という言葉を意識するようになったので、買ってみたのがこの本です。ぼくはデザインパターンはよく知りませんが、例をあげて丁寧に方法を示してくれています。本の中では、なぜリファクタリングが必要なのか、また、デザインパターンの適用の仕方を、筆者の経験を交えて説明してくれます。例として、問題のあるコードについて、一般的なデ～～ザインパターンの適用手順と、具体的な適用例を示してくれるのでとてもわかりやすいです。むやみにデザインパターンを適用するのではなく、状況にあわせてリファクタリングを行うことを教えてくれます。～（ / ）

単なるデザインパターンの説明だけの本よりは理解しやすいです。
どこもかしこも「デザインパターンを使えばよい」ということではなく、
「小さい金槌でこんこん叩けばいいところを大きな金槌を振り回すよう
な状況でデザインパターンを使うのはよくない」という内容の記述が
あり、はっとしました。
自分を含め、勉強したての人ほどついその傾向があるとおもいます。
じっくり読むことでリファクタンリグもデザインパターンへの理解も深まります。（ / ）

使えば使うほど便利な機能を発見してしまいます。
でも見やすい文章ってのは、自己流ではなかなか出来ませんし、
自分でもわからないんですよね。
今回、｢報告書でひとつアピールしてやろう｣と思い購入しました。
今まで遠回りな仕方をしていたのが、瞬間で出来てしまうのが
嬉しいやら悔しいやら。
分りやすい言葉でかかれてありますが、ちよっと初心者の方向きではないかも知れませんね。
ある程度Ｗｏｒｄを経験された方向きかと思いました。（zanzan / 2003-08-25）

最近「わかってきた」という方も多いと思いますが、
ワードはワープロ専用機や一太郎（新しいのは知らないが）のような、
文字、行、全角、半角単位で・・・というものではなく、
「段落」というものをしっかり理解してはじめて使えてくるソフトです。
ちょっと「年賀状が作れるようになった」とか、「表が作れるようになった」レベルでは、
まだこの本は厳しいと思うので、もう少し使い込んできてから読んでください。
冒頭箇所で挫折します。
エクセルは使う分にはごまかしが効きますが、ワードはごまかしが全く効きません。
ここまでワードを使い込む内容は、個人的に読み物としてもおもしろかった。（ぷりっと / 2008-02-23）

初級の方には難しいと思いますし、仕事上、編集のレイアウトをワードで行う方限定といった手法が多いと思います。
自己流でやるには限度があると思うので、そんなときにアイディアをくれる一冊です（ / 2004-06-29）

企業などでレイアウト専門ソフト(インデザイン等)を使わずに、どこのパソコンにも入っているWORDを使って数百ページ超えの業務マニュアルなどを作ることは意外に多いと思う。専門ソフトなら容易くできることもWORDではその独特の動作原理を理解しないと、仕事がはかどらず連日の徹夜作業となる可能性が高いが、本書を読めばそのような事態に遭遇してしまった方を救済できるような気がする。また、そのような境遇の方を対象にしたWORDの参考書というのはほとんどない。
よくある“WORD入門”の本ではサラっと流されてしまう必須機能のスタイルなどにも詳しくページを割いたり、メニュー表記の間違い(バグに近い)も指摘したり、ある意味、WORDで長文の編集作業をしている人には必読の本。
但し、読み物としては楽しいが切羽詰まっている読者には若干わかりにくい箇所もある(WORD自体もわかりにくのだが)。図や写真などで整理されているともっとわかりやすいと思った。（j / 2009-11-04）

数学的な背景を持った見積もり技法を「サイエンスとしての見積もり」、経験則と単純な公式による見積もりを「アートとしての見積もり」とマコネルは区分けしている。本書では両方を取り扱うが、より「アートとしての見積もり」に重点を置くとしている。
プロジェクトのサイズを大中小と分けるなら、中小プロジェクトが圧倒的に多数を占めるものと思う。こうしたプロジェクトでも当然見積もりは必要とされるが、「サイエンスとしての見積もり」を行うのは少々スペックオーバーに思える。ほとんどの現場では経験則や貧弱な根拠による見積もりが行われ、プロジェクトに混乱をきたしているのではないだろうか。
第1部では、良い見積もりとはなにかの考察が行われる。マコネルは、見積もりとターゲットとコミットメントが異なるものであることを最初に示し、様々なデータを元に見積もりに対する考察を行う。その中で良い見積もりと適切なプロジェクトコントロールは不可分のものであるというメッセージが度々語られている。
第2部では、プロジェクトの規模や種類、ステージに応じた具体的な手法がまとめられている。
第3部では規模、工数、スケジュールなどのそれぞれの見積もりごとの手法と課題がまとめられている。
本文はわずか300ページ足らずなのだが詳細な見積もり技法の本を何冊も読むよりも。現場に立つ開発マネージャーにとって（ただし、中小規模のプロジェクトの）、この本を読み込んだ方が役に立つ実践的な知識と考察が得られるように思う。
（赤戌 / 2006-11-16）

常に提示される見積もりに疑問をもっていたので、じっくり本書を読んだ。
最初に提示される見積もりとコミットメントの違いの説明で、その疑問の半分は解消される思いがした。通常提示されていたものは見積もりそのものではなく、コミットメントではないかと。　この調子でアートとしての見積もりに関する知見にふれていくことで、見積もりの在り方の理解が進んでいく。
ただしここで提示される見積もりはそれなりにしっかりとしたバックデータに裏付けられた見積もりであり、通常の日本のベンダーではこの様な定量的な分析ができる体制になっているのか疑問であり、残念な気持ちにもなる。
その様な現実的な側面はあるものの、中小規模の開発案件を企画管理する立場の人には見積もりの在り方を考える上で必読の書であると思います。（tabopapa / 2008-03-09）

　いやー、おもしろい本を見つけました。
　「なんで、こんなに忙しいんだ！」「なんとかしろ！」と職場でお嘆きの方にはお薦めです。
　プロジェクトというのは、完了が遅れることがあります。特にソフトウェア開発プロジェクトは、よく遅れます。
　著者が提案する解決策はシンプルで、
　　　・計画段階で、担当者のサバを吐き出させ、
　　　　できるかできないかギリギリの締め切りを設定する。
　　　・その代わり、予定通りできない時は、プロジェクト全体の余裕
　　　　（親方バッファ）を使わせてあげる。
　　　・「残り○○％」という管理は行わず、「あと○○日終了」で報告
というものです。
　詳細は本書を参照いただくとして、著者の提案を実践すると、担当者とマネージャが良い関係になることは間違いなさそうです。
　よく、管理者が部下に「何か問題ないか？」という質問する人がいますが、こういう質問をする人は、「本当に問題が起りそうだったら早めに報告してほしい」と思っていることは稀で、部下も敏感に察知します。
　本当に事前に問題をキャッチしたいのなら、
　　　「プロジェクト完了までの間に問題があるとしたら何がある？」
というのが正しい質問とのこと。
　カラーで図がたくさん入っていて、とても分りやすい本書ですが、ＴＯＣ（イスラエルの物理学者エリヤフ・ゴールドラット博士が提唱する経営直結の経営哲学）という理論から生まれたCCPM（Critical Chain Project Management）という最新のプロジェクト管理手法がベースにあります。
　しかも、単なる学術書ではなく、多くのプロジェクトをてがけた経験を背景にして書かれている本書は、「面白くて、ためになる」というおいしい本の典型です。「サバ取り段取り」、「親方バッファ」、「科学的段取り八分」など、ネーミングの妙もお楽しみください。（くろやぎ / 2006-04-05）

ここまで分かりやすく書かれたプロジェクトマネージメント関連の本ははじめて見ました。計画がうまくいかないから細かく管理しなければならないとう、これまでの定説がひっくり返されたような気分です。
プロジェクトを成功させるために一番重要なことは、統率や管理ではなくコミュニケーションだったんですね。（パーキンソン虫 / 2006-01-19）

「目的は何ですか？」
「成果物は何ですか？」
「成功基準はなんですか？」
「この直前に行うことは何ですか？ほんとうにそれだけですか？」
「本当にぎりぎりの納期ですか？」
「あと何日かかる？」
「もし問題があるとしたら何がある？」
「それは事実ですか？」
「それはなぜですか？」
少々長くなってしまったが、これらの言葉は本書のはじめににパワフルな言葉として紹介されている。実際プロジェクトのマネジメントをされている方にとっては、さっそく使えるものではないだろうか。
なぜ工程は遅れるのか？できる人は何が違うのか？
うまくいくときもあるのになぁ。そんな疑問は、この本を読めばおおかた氷解するといっていいと思う。そういうことだったのか。。。がいっぱいつまっている。
また本書の良さは中身だけではなく、その読みやすさもある。かわいいキャラクターとウィットの効いたコラムがあなたを「チョーやる虫」にしてくれるに違いない。
がんばってるけど、なぜか結果が出ない。そういう人には特にお勧めしたい。

（宮下陽 / 2006-01-05）

この本は本物です。
プロジェクトマネジメントに関する本は数多くでていますが、確かにどの本も間違いのないものですが、専門書の共通である堅く難しい内容のものが多く、読んでいる途中で飽きてしまうこと。さらには、実践するには無理があるだろうと思わせる類書が多いものです。しかし、この本は読者を飽きさせるどころか、読んでいくうちにだんだん前のめりになって読んでしまう本です。読みやすさ、分かりやすさは図やイラストをふんだに使い、専門書であることを忘れさせる編集にもあると思いますが、なによりも現場の目線から捉えた要点がギッシリ詰まっており、即実践で使える解説になっていることです。各業種によりさまざまな問題点があることと思いますが、TOCをベースとしたクリティカルチェーン・プロジェクトマネジメントの実践本として、全ての業種の問題解決や人材育成のお助け本となる一冊です。是非読まれることをお勧めいたします。さらに付録としてCCPMソフトウェア体験版CD-ROMまでついていますので、試す価値あるプロジェクトマネジメント本です。
（sabayomi / 2006-01-05）

とっかかりの一冊としては、本当に素晴らしい本でした。
一見、「こんな当たり前のことを・・」と思ってしまいがちですが
その当たり前なことに気づかせてくれる一冊です。
その中で自分が参考になったのは、「スケジュールを逆算する」ということです。
例えば、普段私達が電車で遠出をする時は
「11時に東京駅に着く必要があるから、8時30分に家を出よう」
といったように、自然と時間を逆算して考えているんです。
このように、「いつ」までに●●しなければならない、といった時
私達は、逆算するという方法が最適であることを理解しています。
しかし、プロジェクトの現場では、それが行われていません。
とても不思議なことです。
そんな当たり前のことに気づかせてくれました。
その他にも、幾つか自分が参考になったことを紹介します。
１．最後の最後になって作業進捗が９０％のまま進まないことがある。
　　(９０％になってからが長い)
　　⇒ だから工程管理は「完了まであと何日」という日にちで表現する。
　　　(これは、作業担当者に確認する場合も使えます)
２．「プロジェクト完了までの間に問題があるとしたら何がある？」と質問する。
　　(リスクを前もって判断し、報告してもらうための手段)
３．タスク(仕事)のサイズは、プロジェクト関係者が
　　「具体的に作業の大きさや納期を議論できるサイズ」でなければならない
４．余計にお金を掛けてでも短期間に工期を終わらせた方が最終的には儲かる
５．原価が下がっても、必ずしも儲けにはつながらない。（ノグチョ / 2006-09-25）

GoFのデザインパターンハンドブック。タイトルの通りJavaのサンプルコードが使用されています。この本の初めに書かれているように、GoFのデザインバターンを一通り習得しておいたほうが良いです。
ハンドブックらしく実際にパターンを適用させるケースはどの様な場面か、パターンを適用させるためのチェックリストなどが記載されいます。さらに実務で使用する場合の注意点など実際にパターンを使用する為に必要な情報が詰め込まれています。図表も解りやすく、小さな本ですが非常に多くの有用な情報が詰まっている実用書になっています。
筆者がGoFの一人Ralph E.Johnsonから直接デザインパターンを学んだだけの事がある本です。（yohgaki / 2005-06-09）

プログラムの開発 および 設計を行っている全ての方、Java で開発されている方(サンプルが Java だから)にお薦めします。
「GoF のデザイン パターン」のハンドブックです。デザイン パターンごとに概略、クラス図 および サンプルが記述されていて、非常に勉強になります。
しかし、説明が非常に少ないデザイン パターンもあり、全てを知ることはできません。あくまでも入門書として捉え、興味が沸いた方は他の本を購入すれば良いと思います。
この本を読めば必ず素晴らしいプログラムを作成できる訳ではありませんが、技術者としてレベル アップするために、この本に限らずデザイン パターンについて勉強することをお薦めします。開発経験の長い方は、デザイン パターンを知らなくても、デザイン パターンが適用されているプログラムを目にしたことがあると思いますので、ちょっとした感動があるのでは？（みっちぃ / 2008-11-17）

Ajaxなんてことばができたおかげで、いきなり開発の機会が増えたJavaScript。
でも、VBのVisual StudioやJavaのEclipseのような定番の開発環境がないのが
ちょっと困りもの。
けっきょくVenkmanはイマイチで、昔から行われてきたalertデバッグの毎日。
そんな日にFireBugに出会いました。
これ、イケてます。
そして、このWEB+DB PRESSで、FireBugが見事に紹介されてます。
これだけでも読む価値あると思うので、ぜひ。
Ajaxの特集記事の執筆者のひとり、amachangこと天野さんのブログも
めちゃくちゃ勉強になりますよ。
IT戦記　　http://d.hatena.ne.jp/amachang/（str8 / 2006-11-22）

RESTとはHTTPのリクエストに対してXML形式でレスポンスを返す、程度の考えしか持っていなかった私のような人間がこの本を読むと、面食らうに違いない。
RESTはそんな単純なものではない。
RESTを理解するには、「リソース指向アーキテクチャ」という考え方を理解しないといけない、ということがわかっただけでも、この本を読んで良かったと思う。
まず、入門的にRESTとは何か？ということを知りたい人は、いきなりこの分厚い本に当たるのは得策ではないだろう。雑誌の特集記事や訳者のブログの方が初学者向けに良くまとめられてわかりやすい。
しかし、RESTをソフト開発で扱う人は、この本の内容を十分理解してから取り組むべきであろう。そうしないと、また、世界に誤った"RESTもどき"を放り込むことになるであろう。本書は、今の所、日本におけるRESTのバイブルであるから。
（ひかり / 2008-10-31）

タイトルからは対象がわかりにくいですが、webサービスを使用するための本ではありません。この本は、以下を理解するための本です。
・RESTを使ってwebサービスを設計するためのポイントはなにか
・RESTの裏にある思想
・RESTだと何がうれしいのか
例がやや冗長な気もしますが、webサービスを設計する立場にある人は読んでおいて損はないと思います。 （sish / 2008-08-27）

期待して購入したが抽象的であまりRESTとは関係ない話題も多く、
世の中の具体的なRESTベースのWEBサービスを例として交えながら
説明して欲しかったです。
これを読むよりも、GoogleやHatenaのRESTベースのWEBサービスAPIを使って
自分であれこれ遊んだ方が良い勉強になると思います。（hu / 2008-06-12）