リスト：やらされSEリーダーのための本 を表示しています。（全 15 件）

私が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）

数十年前に書かれた内容であるが、今現在でも通用する大事なことが書かれています。
笑顔を忘れない、心からほめる、おだやかに話す、人の身になる、顔をつぶさない、
あら探しをしない、といった当たり前のことがわかりやすい事例で説明されています。
カーネーギーの人に対する深い愛情と慈悲の心から発せたれた言葉には重みがあり、
自分の心もあたたかくなり、心から感動することができます。
ビジネスだけでなく日常生活においても、あらゆる人との接し方を改めて考え直す
すばらしい機会を与えられたと思っています。
このギスギスした世の中で、できるだけ多くの人に読んでもらいたい名著です。（まりも / 2008-08-20）

人を動かすには、その人に"気に入られる"か、その人にとって"重要な人物になる"と思わせるかのどちらかではないでしょうか。私はこの４月で入社５年目を迎える社会人で、周囲には自分より入社年次の高い人がまだまだおられます。仕事を成し遂げるためにはそういった人々を当に"動かす"ことが必要になるのですが、本書を読んで以来、人間は感情の生き物であるということを強く意識するようになり、そのおかげで社内外の調整局面において非常に良い結果を得ることができるようになりました。
私のように入社年次がまだ比較的若く、役職も持たない人間にとって特に効果が高いのは、以下のことであると思われます。
■気に入られるために
・その人の良いところを見つけ、本心で褒める
・心からの誠実な感心を寄せる(犬がかわいくてたまらないのは、彼等が人間に大して誠実な感心を寄せしっぽを振ってなついてくるから)
■重要な人物になるために
・業務知識に精通する(特に、"これだけは誰にも負けない！"という分野を作る)
・利己的にならず、周囲の人をよくサポートする
その他にも、本書には実にためになることがぎっしりと書かれています。書店には自己啓発系の本があふれていますが、本書のエッセンス薄めて流用しているものも少なくないです。良書というのは、いつの時代にでも通じるものだということがよく分かっていただけると思います。（らきすけ / 2006-05-13）

おなじみ「道は開ける」と共に超ロングセラーの本です。
頭ごなしに注意しても人は動かない事や、徒に他人を非難しない事。
あるいは、相手に対して重要性を持たせる事の大切さ。注意するときは自分の失敗談をまず話せ・・・などなど。
「おお〜！納得！！」と思わず頷く箇所は数かぎりなし。日々生きる上での教訓としても非常に貴重。
この本に限らず、カーネギーの本は、読む者の人格を大きくする。
読者をひきつける魅力は今もって全く色あせてはいない。（カーネギー2世 / 2006-07-20）

　僕たちを取り巻く人間関係はとても複雑ですね。
男と女、親と子、先輩と後輩、上司と部下など、普段からどれだけ
多くの役割を演じていることか。
そこで良いコミュニケーションをとろうと思えば、相手の立場に立って
物事を考えなければいけない。でも、それは言うほど簡単じゃない。
僕は男ですが、なったこともない女性の気持ちなんて、どんなに想像してみても
リアルじゃありません。
ですから、相手との温度差により思わぬアクシデントが起こることもあります。
そんなとき、この本は複雑な問題をシンプルにする力を与えてくれます。
人間関係の迷路に迷い込んでしまったとき、本書は「いつでも帰れる場所」として
役立ってくれると思います。（チクタクぴあの / 2008-01-15）

D・カーネギーが書いた大変有名な人間関係円滑術＆処世術の本。
『人を動かす原則』『人に好かれる法』『人を説得する法』『人を矯正する法』『家庭を幸福にする法』など...。
日本版の初版出版は約50年前だが、今日でもしっかり通用する内容であり、具体的な例も交えて、複雑な問題の解決法も率直に話している。
（快適生活 / 2008-01-02）

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

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

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

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

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

　オブジェクト指向、構造化設計といった様々な設計・開発手法を絶対化せずよいところは柔軟に採用しましょうという、穏健派の良心的著作。先端の技術を追いかける開発者にとっては古くさい話が多いように感じられますが、３２章だけでも読む価値は十分にあります（英米の経験主義、良質のプラグマチズムといったものを感じます。「認識の有限性」というテーマは「複雑系」にもつながっており決して「穏健」という言葉でくくれないのですが）。
　ありがたいのは本書が参考文献のアーカイブともなっておりこれを基に興味の方向を拡大していけることです。ただし邦訳が出ている著作について邦訳名が記載されていないのも多く、Amazonで英語名で検索して、邦訳名を確認することが必要でしょう（ということで１個落としました）。（銀鼠 / 2002-12-27）

石川勝さんが翻訳しているので、きっとよい本だろうと思って購入した。
その後積ん読状態で、改訂版を購入した。
両者を比較しながら、少しづつ読んでいる。
全部を一気に読めるような世代のうちに、読んでしまった人は幸せだと思う。
できれば、プログラミングをはじめて１年以内に読むことをお勧めする。
年を取ってから読むのは辛いかもしれない。（kaizen / 2007-12-26）

もう古典に位置付けられるかも知れないが読んで損のない本です。特に、趣味のプログラマからプロのプログラマになりたい人には必読です。（ / 2000-11-15）

ソフトウェア開発ライフサイクルのうち、詳細設計の後半から単体テストの一部までを「ソフトウェアコンストラ
クション」と定義し、これをターゲットとしている。「ソフトウェアコンストラクション」とはいわば実装（インプリメン
テーション）と同義。コンストラクション・テクニックの手引きにとどまらず、ルール、原則、考え方、ガイドライ
ン、環境・ツールについて（多分世に出ている本のなかでも一番）包括的に書かれたハンドブックである。
宗教的議論になりやすい論点、"防衛的プログラミング"や"GOTO文"、"ハンガリアン命名規約"、"
コードのレイアウトとスタイル"、"プログラムのサイズ"についてそれなりの分量で語っていると同時に、それ以
外にも、管理やメトリックスの話、品質やチューニングにとどまらず、プログラムを作る人間のパーソナリティ、
メンタリティについてもカバーしている。物足りない部分があるとしたら、オブジェクト指向の敷居が高かった
時代に書かれたので、オブジェクトそこらへんの記述は弱い部分だが、そのことがこの本の価値を減らすこと
にはならない。書かれている基本原則は容易に応用可能だからだ。
章の最後にある参考文献リストには著者のコメントが書かれており非常に参考になる。
良くも悪くも正統的、過去の歴史の積み重ねの上に生まれた良書だと言える。（エパメイノンダス / 2007-02-26）

ソフトウェア開発工程の中の、重要一工程であるプログラミングについて、
鉄壁のプログラムを書くための鉄則が記述されている。
プロの開発者を目指すならぜひ一読されたい名書である。（ / ）

大学でコンピュータを教えるのならこの本が最初がよいかもしれない。
第１章では、すごく幅広く、パソコンから車載の者まで利用の幅があることを紹介している。そういう初歩的な事項から始めて、CPU性能まで上巻で記載している。
各項目ごとの演習問題と、「誤信と落とし穴」というはまりそうな罠について示しているのは有り難い。
情報理論、電気理論のどちらかしか勉強していいない人だと、時々誤信や落とし穴にはまりこんでいることがある。
ps.
自分では電気を出ているとはいえ、実設計をしていないので、「fanout」（P29)を知らなかったので、あわててネットで検索しました。
出力に接続して駆動できるトランジスタの数のことのようですが、日本語の表現が「出力に接続されるトランジスタの数」と書いてありました。
「The capacitive load per transistor is a function of both the number of transistors connected to an output(called the fanout) and the technology, which determines the capacitance of both wire and transistors.」

（kaizen / 2008-03-07）

コンピュータ・アーキテクチャを学ぶ上での定番の教科書である。
上巻では、アセンブリを中心にわかりやすく解説されている。
時代は移り変われど、コンピュータの原理は変わることはないので、
この本で、根底の部分を学ぶことは、非常に重要である。
一つ留意すべきことは、内容は明快に記述されてはいるが、
全くの初学者が使うには少し辛いかもしれないことである。
また、第３版になってページが削られてしまい、
多くのページが、pdfファイルとして、CDROMに格納されている。
私としては、pdfファイルを一々印刷するのは面倒なので、
本のページをもう少し増やして欲しかった。
そのため、星を１つ減らして４つとしている。
（pdfの内容自体は星５つである）（iwashi / 2006-08-08）

コンピュータ・アーキテクチャ設計に当たり、CPUに始まりメモリ、各種バス等の周辺装置に至るまで、設計上の基本方針、留意点を丹念に記載した名著。各国の大学で教科書として使用されており、私の時代には「ヘネ・パタ」本として親しまれた。
特に各々の説明において定量的評価を忘れない点、豊富な例題で理解を容易にしている点、各所で問題と解答を載せ(著者が二人とも教授である事にも依る)、読者のやる気を出している点が特徴である。また、特に新版では増補されているようだが、ソフトウェアとのインタフェースを常に考慮し、コンピュータ・アーキテクチャ設計におけるハードウェアとソフトウェアのトレード・オフを重視している点が評価できる。このため、ソフトウェア開発者が読んでも役に立つ内容となっている。
ハードウェア、ソフトウェア開発者を問わず、コンピュータ関連従事者にとって必読の名著。（紫陽花 / 2007-04-30）

日本語版はなぜか2分冊になっているところは気持ち悪いですが，
翻訳も問題なく，非常に読みやすいです。
コンピュータアーキテクチャの方も，この著者が訳してくれていたらなぁ…。
（学生とかに分担して訳させるからああなってしまったのか…）
（ark / 2009-04-26）

わかりやすい構成と平易な文章での丁寧な解説。プログラム経験が０でない人には問題なく誰にでも薦められる。短いサンプルコードが豊富で、具体的なイメージもつかみやすい。
今まであまり理解できなかったイテレータやブロックについて、私はこの本で理解できるようになりました。（ / ）

解説が丁寧で網羅している範囲も広く、良い本です。
Rubyを日常使っていて、ある程度理解している人は楽しく読めると思います。
ただ、Rubyの知識がほとんどない状態で読むと難しく感じると思います。
私は、Rubyを身につけようとして、最初にこの本を買ったのですが、
正直あまり頭に入らず、入門書を別に買いました。
この本に入る前に、入門書（「たのしいRuby」とか）を読むことをお勧めします。（ / ）

どういうわけかRubyの本は質が低いものが多い。一見やさしそうな題名と可愛い絵で初心者を釣ろうとしているが、Perlが分からないと理解できなかったり、演算子の説明すらろくに載っていない入門本が多数出版されている。
この本はRubyの機能をほぼ網羅しており、手元においておけば、初心者以外にも十分使える本である。（奈菜資産 / 2005-05-13）

他の言語でプログラミングの経験があってこれからRubyを覚えよういうひとに向いている。入門書ではないので初心者の1冊目には向かないと思う。
本自体は厚いが各章は短くまとまっていて必要なところだけ読める。また目次も細かいしインデックスもしっかりしているので、必要な情報を見つけやすい。内容的にも豊富で解説も簡潔でわかりやすい。とりあえず文法をさらっと確認してすぐにプログラムを書き始められる。Rubyでプログラミングを始めるにはこれ1冊で十分。
2001年発刊のためバージョン1.6をもとに解説されているが、内容が古くなっていることはない思う。2006年2月時点でも最良の1冊に間違いない。（yomuta / 2006-02-09）

英語版の本も持っていたんですが、やっぱり日本語版だと、読み落としてた部分も発見できたりして、買ってよかったと思います。
Railsでアジャイルな開発をしたい人には向いているんじゃないでしょうか。
ligttpdを使ってRailsを使うことをお勧めしていたので、そのへんの話題をもう少し詳しく知りたかったです。（りゅ→ / 2006-03-02）

内容も充実してるし、試していくだけでお買い物カゴが出来るのは素晴らしいです。
普段使ってる商品のチェックやセッションなどの処理が初めから組み込まれているのでそれをチョット（2〜3行）修正するだけで処理が完了しまいます。仕事の効率が上がる事間違いなし！その上読んでて楽しい本ですので(付録以外は)楽しみながら試す事が出来ました。
PHPのSmartyでも楽しいと思ったのですが、こいつはもっと強力です。
良い部分は今までも散々既出ですのでこの本を読む（試す）に当たって気になった点をいくつか上げてみました。
１．最新のバージョン、OSの違いなど若干の誤差があるので、内容を理解しないとErrorが出る部分があります。（要・修正）ただ、色々なバージョン、OSで試しているのでじっくり読めばわかる事なのですが・・・。
２．サンプルの番号が解りにくい。
depotフォルダに番号を振ってあるのですが、イマイチ良くわかりません。自分だけでしょうか？
３．Ruby、Mysqlで組んだ事の無い人には・・・って当たり前な事ですが。
４．実際になんらかのシステムを組む場合、組む人間がRailsのクラス？動き等を覚えないといけない。
以上を踏まえた上でも満点間違いなしです。
Railsの楽しさをこの本で是非知って欲しいと思いました。
しかし・・・Rails仕事で使ってる業者いるのかな？（dango / 2006-06-07）

Javaプログラマーをしています。
勉強がてらRoRでもいじってみようと思ってこの書籍を購入しました。
感想は・・・
凄いです。今すぐRoRに乗り換えたくなりました。
Webプログラマーは是非勉強したほうが良いと思います。
久しぶりにプログラムを組んでいてワクワクしてきました。
この本はどちらかといえば、フレームワークの技術が詳細に紹介されています。
フレームワークの概要を理解したい人向けでしょう。
本書はRailsの入門書ではありますが、Webプログラミングの入門書ではありません。Webの基本から勉強しようと考えている人にはお勧めしません。
むしろ、JavaやPHPなど、既にWebに携わっている人に読んで欲しいです。
Javaなどの仕事で苦労した人のほうが、RoRの良さ（アジャイルを含め）を理解できると思います。
仕事で使いたいなぁ・・・（ウチの会社Rubyできる人がいないから無理かな）

（バックドロップ / 2007-03-12）

Ruby を使ってWebアプリケーションを（それなりにきちっとしたものを）書けるフレームワークがRuby on Railsです。本書は開発者の原著の翻訳です。
これ1冊で出来るようになっています。
ただ、Apacheとの連携で、FastCGIを推奨しているのは、訳に当たって、ちょっと補足してもらいたかったです。今のmod_rubyは、Railsを直接呼び出す機能を持っています。
これがあることで、簡単に、Apacheと連携する、つまり、本番環境で実働できるのです。
これから、このフレームワークは、知らない人がいないぐらいになるぞ。（Fhanrin / 2006-03-03）

という格言の通り、原書にふさわしい「完全性」を持った本です。入門から中級レベルまでこの一冊で押し上げてくれます。
氾濫する初心者本や雑誌連載、blog記事などを漁るより、少し高くてぶ厚くとも原書を買った方が出費・学習時間とも少なくて済む、という戦略にきちんと合致する完全性を持った良書です。（kano on feena / 2007-07-16）

表面的な文法を見ているだけでは分かり難い、C++でより良いプログラムを書くための指針が101種類のルールに整理されていています。
こういうのは今までノウハウや暗黙知としては存在しても、本としてまとまっているのは意外と珍しいかもしれません。
ある程度コードが書けるようになって、より上のレベルにスキルアップしたい人や、チームで開発する場合のコーディング指針を探している人には、最適だと思います。（和無田 / 2005-11-26）

一つ一つのトピックは簡潔にまとめられていて、著者の意図を汲み取れる上級者なら、スイスイ読めるのでしょう。
『雰囲気はわかるけど、もう少し詳細が知りたいという』中級者には、丁寧に挙げられた出典を読むことで、その欲求を満たせるでしょう。
「C++ In-depth」シリーズにおける現時点での総覧としての価値があります。（たびもり / 2006-12-25）

アレクセイ・アレクサンドレスクも著者の一人であるため、非常に難解である。ただし、その難解さを乗り越え理解する価値は十分にある。C++のコーディング＆開発ルールのプラクティスとしてほぼ完璧に精査されており、すばらしい。ただ、なぜそのプラクティスが必要かとう問いに、完全には答えていないのが残念。アレクセイなので、そこまで求めるのは贅沢かもしれない。（ichiro.mariners / 2007-12-04）

かたやHerb Sutter。
『Exceptional C++』の著者であり、Effective C++のScott Meyersをして、『彼の仕掛けた罠に私も見事に嵌ってしまった』と言わしめるほど、C++でプログラミングする上で注意しなければならない問題点を良く知る人物。
かたやAndrei Alexandrescu。
『Modern C++ design』の著者であり、テンプレートを使ったメタプログラミングの分野において、デザインパターンのGoFの一人、John Vlissidesをして絶賛させるほどのC++の強力な機能を良く知る人物。
　この二人以上にC++について知識があると自負できる方には何も言いません。そうでないなら、この本は必携のハンドブックです。
　勿論、すべてのプログラミング分野において技術的解法には何らかのトレードオフがあり、それ故に彼らは決してすべてのトピックスを読者に押し付けようとはしません。ほとんどすべてのトピックス、ガイドラインには適用されない例外事項が説明されています。
　この本を読んで自分には必要なかったと言い切れる人は、よほど実力があるSE/アーキテクトなのか、それとも最初から脱ぐ帽子を被っていなかったかのどちらかなのでしょう。（ynar / 2006-04-29）

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

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

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

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

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

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

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

この本を読むまで、バグの原因というものはデバッガでプログラムの挙動を追いかけながら見つけるものだと思い込んでいました。ところが、この本で紹介されていたのは、バグの検査を自動化するコードをそのプログラム自身に埋め込み、テストランによってバグの箇所をすぐに特定できるというやり方だったのです。バグを後から見つけるのではなくバグが入り込むのをプログラム作成時に防ぐ、という考え方に私は強い衝撃と感銘を受けました。この本に書かれた「退屈なコードを書こう」というポリシーは、今でも私のプログラミングスタイルの基本になっています。
Kent Beckのテスティング・フレームワークが現れた今となっては内容に古さが感じられますが、根底にある思想の大切さは今でも変わりません。アサーションを使ったことがなくデバッグ情報をprintfで表示させたりしているレベルのC言語プログラマがこの本から学ぶことは多いでしょう。一読をお奨めします。（ / ）

C言語開発のノウハウがぎっしりつまった本である。
例えば、C言語で短いコードが、機械語で短い命令群になるとは限らないことを述べているところが気に入った。結果として、
「論理式に対しては”｜｜”を使用せよ。条件式に対しては？：演算子を使用せよ。
　条件文に対してはifを使用せよ。」
教訓を導き出している。
付け加えるとすれば、始めて各パターン、始めてコンパイルするコンパイラ（CPU)では、
１度はアセンブラに直して確認しなさいと書いて欲しかったかもしれない。
ps.
自動車向けのコーディング標準であるMISRA-Cでは十分カバーできていないところを、
本書では述べている点がいくつかあるようなので、併せて取り組むとよいと思った。
MISRA-Cでは、C言語の落とし穴とSafer-Cを参照している。
本書も参照文献の一つに加えるとよいと思う。（kaizen / 2008-02-27）

私はソフトウェア開発の仕事を始めてから20年以上になりますが、最近の傾向として、様々なAPIの習得が最重要とされ（仕事に必要なので止むを得ない）、「如何にコードを書くか」という、ソフトウェア技術者にとって最も重要な訓練が軽視されているような気がします。
以前はKernighanやPlaugerなどが書いた本を多くの技術者が読み、「コードの信頼性を如何に上げるか」、ということが多大な関心時でした。計算機資源が限られていたことや、オンラインデバッガが未成熟だったこともあり、初期のコードを如何に洗練させるか（要するに、バグの発生を如何に初期に食い止めるか）、ということに日々頭を悩ませたものでした。
今も勿論そうだとは思うのですが、誰でも一日中自身の計算機を使える環境にあること、オンラインデバッガの機能が著しく向上したことにより、とにかく早くコードを作り、バグが出ればその都度修正する、というスタイルに必然的に移行していると思われます。
C/C++は難しい言語で、ちゃんと訓練を受けた人でなければ扱えません。最近のソフトウェアの信頼性の低さは、C/C++が広まった割には、それを使いこなせる技術者が相対的に減っていることにあると、個人的には思っています。
本書だけで十分というわけではないでしょうが、現在軽視傾向にある問題を見つめる上で、再認識されても良い書物です。冒頭でKnuth（今知っている人がどれだけいる？）のTeXに関する文章が引用されていますが、これを理想とすることが現在正に望まれます。（加納 裕 / 2004-03-20）

著者はMicrosoft社にてVisual C++開発プロジェクトを管理したことで有名だが、本書はそれらの経験を元に、ソフトウェアプロジェクト管理について、含蓄のある記述を豊富に含んでいる。プロジェクト管理に携わっている人全てにお勧めの実践書。
（加納 裕 / 2006-09-25）

TEXのプログラムを見るまでもなく、プログラムそのものが文書であることはプログラマなら常識になっていて欲しい。
最初のプログラミングを学習したときに、プログラムと文書を別々に書くことを教わったり、
そもそも人が読めるようなプログラミングをしたことがない人には、釈迦に念仏なのかもしれない。
プログラムは芸術であって、工学ではないことを、理解する一歩にして欲しいと思っています。（kaizen / 2009-01-05）

邦訳の初版1994年，収録されている論文は70,80年代のもの．
コンピュータの処理速度向上により外面的な表現に関連した記述は修正が必要かもれしれないが，内奥に潜む本質に古びるところはない．
プログラム，プログラミングとは何なのか．サイエンティストやアーティストでない職業プログラマが増えた今だからこそ読んで欲しい．（InTheDark / 2009-11-03）

GoFによるデザインパターンのうちに作者にとって特に有益だと思われる
パターンの説明がrubyによって説明されています。
rubyの言語特徴により、かのJava言語で学ぶデザインパターン入門よりも
より短く、解かりやすいサンプルコードとなっています。
事実、速読ができない私でも読了に８時間程度で全部読めてしまいました。
おまけにrubyの文法の説明が章を割いて説明してあり、メタプログラミングや
モジュールの使い方等の説明もデザインパターンの説明内に書かれてあるため、
rubyの知識もふえてruby初心者の方には１石２鳥なのではないでしょうか？
星ひとつ減点の理由は、初心者には絶対お奨めですが、すでにデザインパターン
を知っていて、rubyの文法も知っている中級者以上にとっては、それほど大きな
発見はないので、この薄さで３９９０円はないよなーという気持ちになる点です。
個人的には、rails上のプログラミングではここに上がっているような
デザインパターンが使いづらい気がします。
ただ、rails本体はガンガンにデザインパターンを使用していて、デザイン
パターンの説明にをよくrails自体が参照されていたため、rails自体を知るには
この本が参考になると思います。（take shy / 2009-04-29）

しごとでは、JavaでWebアプリを開発しています。
RubyとRuby on Railsの入門書を読んだ後で、本書を読みました。
本書は、タイトルどおり、GoFのデザインパターンを、
Rubyで実装して、学んでいくというものです。
１章につき１パターンで、ソースコードを示しながら、
そのパターンのポイントを説明しています。
ひとつのでデザインパターンについて、
「Rubyでは、こんなふうにも書けるしあなふうにも書ける」
といった調子で、複数の実装方法を説明してあることも多いです。
あるいは、デザインパターンを使わない実装をして、その問題点を指摘して、
次に、デザインパターンを使った実装をして、その有用性を説明という場合もあります。
「継承より集約を使う」といった、オブジェクト指向プログラミングの
ポイントにもたびたび触れています。
デザインパターンにまじえて、文法やらブロックやら、
Rubyそのものの説明もしています。
はじめは冗長な気もしたけど、読み終えてみれば、
自分のようなRubyの経験の浅いものにはなかなかよかったと思います。
よりRubyっぽいプログラミングが学べたとおもいます。
Javaのデザインパターンの本も何冊か読みましたが、
それらと比べても、読みやすくわかりやすい本だと思います。
説明はていねいだし、例の大きさも適当でよいと思います。
JavaとRubyのちがいもあるのかもしれない。
すでにデザインパターンやらオブジェクト指向プログラミングを知っている人は、
特別、新しい何かが得られるということはないかもしれません。
あるとしたら、DSLぐらいか。
自分は、本書であらためて勉強しなおせてよかったとおもいます。



（本屋が好き / 2009-09-17）