コンピュータ・インターネット - コンピュータサイエンス - ソフトウェア開発

オーソドックスな要求開発技法の説明 （Ｄｏｒａ＿Ｐａｐａさん 2009-11-07）
要求開発を、準備、要求の抽出、分析、仕様化、妥当性確認、そして、要求の管理と、非常にスタンダードなステップに沿って、簡潔に説明している。殆どのページが技法の使い方にさかれていて、更に大変簡潔で手短な説明であるところから「実践」「ハンドブック」という名がついていると思われる。内容や考え方は「ソフトウエア要求」(カール・E. ウィーガーズ)などの本で理解し、技法の実践は、手ごろなこの本が適している。ただ、要求開発ワークショップについては、さすがに手短過ぎて、同じ著者の「要求開発ワークショップの進め方」のほうが実践的で良い。

お手本にしたいですね （kosei-halfmoonさん 2009-06-09）
最初にこれだけは言っておきたいのですが、各章末にある「Coffee Break」（コラム）を読んでいるだけでもソフトウェア開発から運用に至るまでの重要な知識を得ることが可能だと言っても過言ではないと思います。ちょっとオーバーですが、この「Coffee Break」に書かれている小さなコラムは、システム開発プロセスを学ぶ上での重要な手掛り、及び著者の経験と知恵が記されているということです。「Coffee Break」に書かれている意味が解らない場合は、各章をじっくりと読み込んでいけば良いと思います。 総評としては、ソフトウェア工学における著者の豊富な経験と知識が非常に解り易い表現で記載されています。各章で説明のために用いている説明文と表記法は、例えばシステム開発を行う現場で上司から部下へ、先輩から後輩へのOJTを行う上でお手本となる表現、及び表記法だと思います。ただ欲を言えばもう少し詳しく説明してほしい章もあったことは事実ですね。とはいえ「入門講座」ということを考えるとこれで良いのでしょうか…、さらに各章末にある練習問題も正答を得るというよりは各章で学んだことをキチンと確認しておくという設問になっていると思います。これから読む方のために内容に関することには触れませんが、とにかくシステム開発を行う現場に持ち込める（現場で利用できる）入門講座と言うことができますよ。

開発プロセスなどの具体性をもっと欲しかった （qazwsxedcrfvtgbyhnさん 2009-08-20）
ずっと受けたかったソフトウェアエンジニアリングの授業(1) のほうが参考になりました。 コストパフォーマンスも良いとはいえないので星１つにしました。

怒りは理解力の足を引っ張ります。 （伊賀のヲタクさん 2009-08-16）
Head Firstシリーズは、Javaを買って以降、わかりやすくて、デザインパターン、オブジェクト指向分析&設計、この本と４冊買っているのですが、この本に限っては(オブジェクト指向&分析もその気があったといえばあったのですが)非常に読むのが苦痛です。 他書でも散見される「誤植が多い」というのは、まあこのシリーズだから仕方ないと割り切ってしまっても良い(もちろんそれはそれで不愉快ですけど)のですが、他書を読んでおかないと話についていけないとか、エクササイズにとって重要なところがどこにも文章化されてない──にも関わらず次のページにはしれっと答が載っているというのは、本当に読んでいて「腹が立ちます」。 この本特有の「情動でも理解力を助ける」というコンセプトが、見事なまでに真逆を向いた本なので、残念ながら学習書としてはお薦めしません。退屈な技術書を読んでおく方がよっぽど理解力の足しになります。

SPLE の教科書としてはうってつけ （ZACKYさん 2009-01-18）
SPLE を体系的に学べる教科書が，ついに日本語訳されました！ 序章は，マスカスタマイゼーション(大量個別生産)に対してプラットフォームを解にするのがSPLE(ソフトウェア製品系列開発)であるという流れで，すっきり説明していて，導入としては今までのSPLE本の中でもっともわかりやすいです．次に開発プロセスのフレームワーク(いわゆる2層開発:ドメイン開発＋アプリケーション開発)が示されています．前半のハイライトは著者らが提案する直交可変性モデル(OVM: Orthogonal Variability Model)です．基本概念の説明をし，各工程でどのように記述していくかを丁寧に解説しています．後半はドメイン開発とアプリケーション開発の各工程を解説します．最後は，SPLE で重要性を強調される組織の問題，みんな気になる移行プロセスや事例について紹介します．事例については，注釈付きの参考文献紹介というスタイルになっており，ポインタとしてかなり重宝するのではないでしょうか． 翻訳についても，SPLE 研究・実践の第一人者である訳者陣がきっちり丁寧に翻訳しており，安心して読めます．意図的に漢語調(つまり，外来語をできるだけ漢字の技術用語で表現する方針)でまとめられているので，ちょっと日本語として堅く感じますが，そんなに違和感はありません． 個人的には第9章製品管理の章が，他と比べて技術者にとってわかりにくいかなと思いました．この章で挙げられている参考文献もドイツ語の文献ばかりなので，敷居が高いです．(ちゃんと追っていませんが，これらの参考文献と同様の英語の本はたぶんあると思います．) ただ，製品管理の辺りは世界的に見てもまだ良書がないのが現状です．製品管理の一通りの基礎概念を説明しているという点で，現時点では(製品管理だけ，ややわかりにくいとは言っても)やはりこの本を推薦するでしょう．そういう意味で，減点なしの5つ星です．

アーキテクト必携の一冊 （アーキさん 2009-08-08）
アーキテクトを担っている方、これから目指す方どちらにも是非とも読んで頂きたい「アーキテクトの思考プロセス」のベストプラクティスです。 本書のチェックリストをシステム提案、計画時に活用すれば手戻りも減る事でしょう。

アーキテクトならずとも読め （まっこうさん 2009-01-12）
ソフトウェアシステムのアーキテクチャ設計における、視点・原則・戦略・記述法が体系的に説明されている。アーキテクトはもちろん、システム構築に携わる他のステークホルダなど意思決定に携わる全ての方に読んでもらいたい。とは言え、書かれていることがいつも完璧に実践できることはありえず、プロジェクトとは常に妥協点を見出しながら進めていくわけである。しかしながら、ここで述べられているような視点・原則を身に付けていることで、限られた時間制約の中でよりベターな意思決定ができるのではないかと思う。原理を学んで、より優れたシステム構築を実践しよう！でも現実世界はやっぱり厳しいなあ。。。

ＩＴアーキテクトの体系的かつ実践的なガイドブック （masuda220さん 2009-01-09）
ＩＴアーキテクチャの関心事や課題を、６つのビュー（視点）と、１０のパースペクティブ（横断的な関心事）のマトリクスで整理し、それぞれのビューとパースペクテイブについて、典型的な課題と解決パターンを網羅したアーキテクチャパターンカタログです。 体系的ですが、網羅性よりも、現場での現実の課題と、実践的な解決パターンを重視した本で、現場で課題の整理や設計案の作成にすぐに使えるようネタが満載されています。 この本のもう一つの特徴が、さまざまなステークホルダー（利害関係者）のニーズ、彼らとのコミュニケーションを、一貫して重視していることです。 ステークホルダー、ビュー、パースペクティブという三つの軸を明確にすることで、ＩＴアーキテクチャというとらえどころが難しい技術テーマを、みごとに、整理した良書だと思います。 ＩＴアーキテクトとしてスキルアップを目指すかた、現場でＩＴアーキテクトの役割を担って、さまざまな課題を抱えられている方に、お薦めの一冊です。

アーキテクチャ的思考法 （白いミッフィさん 2008-12-17）
最近、企業や業界アナリストから、ITアーキテクトの育成や資質に関するテーマがあげられてきています。この書籍は、その問いに対する重要な解を示していると思います。 業界でも有名なアーキテクトX氏に師事して数年、アーキテクチャ策定（アーキテクチャ的思考法）に対するさまざまな知見を教えられました。 そのほぼすべてが体系化され実践的に解説されています。 ITAの役割：アーキテクトX氏の言葉「お客様が構築しようとお考えになっているＩＴシステムが、テクノロジーや製品、環境の観点から、それが運用可能なのか、また、お客様が欲している機能を達成できているのか、ビジネスの観点で問題ないのか、この3つの軸のバランスを取ってＩＴアーキテクチャーを決めていく仕事です。」

IPA/SECでは機能安全のガイドについで参考になる書籍 （kaizenさん 2008-12-18）
IPA/SECから出ている書籍では、機能安全のガイド、コーディング標準、プロセス改善ナビゲーションガイドベストプラクティス編とともに、ベストとして推奨できる冊子。 １１月１９日から横浜パシフィコで開催中のET2008のIPA/SECのブースで、 お披露目をしていました。 著者の一人の吉澤智美さんは、NECエレの方で、SESSAME,日本科学技術連盟など対外的な活動で、温厚な人柄と、技術に対する豊富な知識と、経験を生かすことができる繊細な心遣いと、技術系の管理者に期待される３要素を兼ね備えられている。上司にしたい女性のNo1に推薦したい。 ソフトウェアの品質については、日本規格協会の「ソフトウェア品質評価ガイドブック」が絶版になっているので、現場は困っていました。 その困っていることに、素直に答えてくれています。 課題としては、書いている人、レビューをしている人が、大企業に偏っているように読めてしまうことです。 資源と時間が少ない現場で、もっと簡単なことを測定するだけでも有効なことがあるような気がします。 ソフトウェアとは関係のなさそうなことでも、実はソフトウェアの品質特性としてつかっていいことなどを紹介すると、測定、改善のきっかけになったかもしれません。 第４章は、それぞれ、4.1伝達、4.2文書、4.3 見直し、4.4 試験、4.5 活動についての教訓が描かれてとても参考になります。 ただし、見出しを含めて、カタカナ語が多く、読みにくい気がしました。 １２づつ教訓が例示してあるので、ひとりづつ、優先順位をつけてみて、比較してみると、議論のきっかけになると思われます。 2/6に名古屋でもお披露目のセミナがあるらしいので、参加するとよいかもしれません。 組込み系のガイドは、順次改訂されているので、演習などの結果に基づいて、教育例、実践例が追加されることを期待しています。

これは、経産省のモデル契約に比べ実用的だ！ （officekobaさん 2008-10-31）
経産省のモデル契約は、本文と解説がうまく分離されていなくてどうにも読みづらかったが、この本は、読む側・使う側の立場に立ってうまく構成されており、とても実用的だ。契約本文だけでなく、その条項を採用する理由が明確なので、契約交渉の際にも役立ちそうだ。

プロジェクト管理の必須本 （メロディさん 2008-11-04）
Tracだけではなく、プロジェクト管理や問題解決といった具体的な事象から Tracのメリット、そして具体的な使い方に繋げていく目的ドリブンな 本の構成が素晴らしい。 また、挿絵と良い、マンガと良い、ライトなオーラが 本全体からにじみ出ていて、読みやすさも抜群。 Tracを意地でも分からせてやる、という気持ちが伝わってきた。 中でも特に、ガントチャート表示、カレンダー表示には感動！。 Tracを今まできちんと知らなかった自分が残念でならない。 Tracに対し、敷居が高いと感じられている方は、 この本を片手にまずは使ってみてはいかが？

入門から実務まで （かおるんさん 2008-10-05）
とても楽しく読むことが出来た。 Trac の説明にとどまらず、実際に Trac を使用したプロジェクト管理方法についても書かれているので、Trac の導入において特に実用的な一冊。 さらに｢逆引き Trac｣と｢Trac を使う上での心得(プラクティス)｣は長い目で見ても有用だと感じた。

トップエスイー講座と対偶となる教育をめざして （kaizenさん 2009-01-29）
形式手法の教育を行う場合に、受講生は、本書を全部読んでいる必要はないという命題をたててみました。 トップエスイー実践講座３では、「高度な数学的知識を習得して、現実的なシステムの仕様記述に利用することは容易でははい。」「モデル検査は、検証に必要な証明の作業を完全に自動的に行うため、上述の形式検証技術一般の問題点を解決できる。」とあることにもとづいています。 講師になる人間は、全部読んでいる必要があると感じました。 本書を読んでいて、わからない記述があったので記録します。 P21 論理命題が真であれば、その対偶は真となる。 「叱らないと勉強しない」（命題） 「勉強すると叱る」（対偶） 解釈としては 「勉強しているということは叱られたから」 という記述がありました。 疑問に思った点は、勉強していはじめたときと、叱ったときが同時でればよいのではないでしょうか。 「勉強しはじめたときにちょうど叱った」 というのが真であれば、 叱る方は「叱らないと勉強しない」と思うし、 勉強している方は、「勉強しはじめたときにちょうど叱った」と思うという理解ではだめでしょうか。 そのため、対偶としては、 「勉強しはじめたときにちょうど叱った」 といのではだめでしょうか。 あるいは、 叱る側の立場 「叱らないと勉強しない」 「勉強しているということは叱られたから」 というのは、すでに順序関係を含んでいるので、その記載がないことが問題なのでしょうか。 ところで、勉強する側の立場 「勉強しはじめたときにちょうど叱った」 の対偶は 「叱らなかったときに、勉強を始めなかったことがある」 というのでよいでしょうか？ ps. 命題が複数の人間に関するものは、表現を注意する必要があるのではという理解でよいでしょうか。

技術者としての市場評価の上げ方から、椅子の選び方まで （mnishikawaさん 2008-08-13）
「Joel on Software」のジョエル・スポルスキさんによるソフト技術者の採用ガイド。 つまり、一緒に仕事したいソフト技術者について書かれた本です。 前著”Joel on Software”で紹介された「ジョエル・テスト」に代表されるように、非常にシンプルで明確なコラムが並んでます。しかも、なんだか飲み屋の話題かと思うほど軽いノリで楽しく読める。 ソフト技術者は、ただ数を集めても生産性は上がらないし、「良い」技術者と仕事することが、ソフトウェアを創る上で最も重要なことだ。そういった意味で、採用のプロセスにこだわりを持っているというのは大切なことなんだけど、日本のソフトウェア業界で採用に対して強い意識を持っている会社って少ないように思う。採用段階でコード書かせてる所もあまり聞かない。 「採用」から開発は始まっている。こういった本をきっかけに、もうちょっと考えてみてもいいかもしれない。 あと、良い人材を探すだけじゃなく、能力を引き出すのも重要。 技術者との接し方はもちろん、椅子の選び方まで書いてます。 ソフトエンジニアを探している人はもちろん、エンジニアの人にとっても、自分の市場での評価や自分の能力を発揮させるための仕事環境を客観的に見直すには面白い内容です。 ぜひご一読を。

日本ではちょっと、、なところありました （neu-neuさん 2008-07-22）
良いエンジニアを雇いたければ、高額なブランドものの椅子を置けとか、ネットで好き放題ショッピングさせろとか、日本の大企業では考えられないアドバイスもあります。先進的なソフトハウスでは合うかもしれませんが、いまだネズミ色の机ならべて、車輪の取れたダニだらけの椅子もあったりして、それでもコストカットにがんばって開発している大銀行のプロジェクトでこんなことまでして良いエンジニア雇う余裕ありません(汗)

採用担当者だけではなく応募者にも管理職にも有益な内容 （もなりえるさん 2008-07-19）
本書は採用担当者のための本と言うことになっていますが、応募者にも管理職にも有益な内容になっています。 ジョエル氏の主張はおおよそこんな感じである。 採用について 1.インターンシップを利用する 2.有名大学や開発者会議へ自分から出向く 3.社員の紹介はあてにならない 4.良い人に来てもらうために社内の開発環境を良くしよう 5.履歴書は振るい落としに使うだけにする。 学歴や経歴で面接の順番を決めると効率が上がるが、それらで採用を決定してはいけない。 6.電話面接でさらに振るい落として手間を省く 7.面接でコードを書いてもらう 8.面接でクイズや知識だけの質問は最悪 9.落とした応募者にも会社に対して良い印象を持ってもらおう 職場の管理について 1.軍隊式管理は知的職業に向かない 2.従業員を数値的なもので評価すると、従業員はその数値を上げることに熱心になり、実際の効率は下がる。 3.社員を管理するよりも社員を教育しよう 4.社員と組織のゴールを一体化させよう。これが最高の方法だが、非常に困難である。 5.ジョエル・テストを使おう 全部読んでみると、結局のところ組織の管理と採用は表裏一体であることが分かります。 組織を改善せずに良い人に来てくれと言っても誰も来ません。 本書は非常に良い事が書いてありますが、以下の点を差し引く必要もあります。 1.ジョエル氏の経営するFog Creek Softwareは社員数十名の中小企業 2.少数精鋭。本当に優秀な人しか雇わない。 3.採用数は数名 4.社長のジョエル氏が未だに技術者で現場を良く理解している 5.アメリカの企業である 本書の内容は中小企業だからこそできることかもしれませんが、大企業でも参考にするべきことは多いはずです。

プログラマをより理解できる内容 （makoto_kwさん 2008-06-18）
採用に口を出せる立場でもありますが、どちからというと採用をされる側、プログラマの立場で読みました。「そうそう、プログラマってそうなんだよ」と共感できる部分が多く、採用に限らずプログラマへの理解を深めるのに有効な本ではないかと思いました。 もちろんタイトルに沿った内容で、履歴書や面接での質問方法など具体的かつ実践的な内容も数多く含まれているので採用担当の方に十分おすすめできると感じました。元プログラマでプログラマの気持ちはわかっているという方でも復習になると思います。 日本語訳も特に違和感を感じず読むことができました。

何に組み込む場合の開発でしょうか （kaizenさん 2007-12-25）
組込みソフトウェアといっても、何に組込むかで開発作業手順に大きな違いがある。 試作と量産用であっても、大きな違いがあると聞いている。 本書では、時間に制約されないプロセスの定義と、時間軸に移した工程設計を分けるような努力をしたという。 しかし、安全なシステム構築野際に、システムの要求を先に決めるか、安全要求を先に決めるかは、システムによるが、あたかもある順番かのような矢印が図に存在しているのは残念である。 具体例は、ある一つの具体例に基づいて、時間軸上に書き下してある方が、一般的な記述よりも役立つ。しかし、一般的な定義は時間軸上に書き下さない見方もできるとよい。 一般的な定義は、国際規格などに存在しているので、何か一つの製品の、試作のときと、量産のときの２つの例を示してもらえると、いろいろ役立てることができるので、ぜひお願いしたい。

改良開発における見積り方法論 （papillonさん 2008-09-22）
新規システムの開発とは異なり、 既存のシステムがある状況で新たな機能を開発・・改良開発における見積り方法。 ・・でも、いまどき、純粋の新規システムの構築の方がまれなので、参考になります。 改良開発のコスト構造・・ ・既存システムの規模 ・既存システムの理解容易性 ・保守性の水準 ・機能の変更量・追加量等々を、考慮した上で見積もる必要あり。 また、新規開発との大きな違いは、 「機能量とテスト量の相関が新規開発に比べて低い点」 ｅｘ．ソースコード１行の変更でも、そのコードが含まれる機能が母体の多くの部分に関係する場合 であれば、その変更の妥当性を保証するために、関係する母体全体をテストすることもあり。 また、保守性は、当然ながら、以前のプロジェクトの品質に大きく依存すること。 以上踏まえた、ジャステックさんの改良開発の構造を踏まえての見積りモデル、 計数の想定や計算式の適用可否は判断必要ですが、見積り時の考慮の観点、とても参考になります。 ・・既に実施されている場合でも、内外への説明として、頭の整理に良いと思います。

見積もりが大切だと経営者の方からは教わりましたが （kaizenさん 2007-12-22）
見積もりの事例は貴重です。各社がどういう見積もりをしているかがわかる。 ps. ソフトウェア経済学という用語があったが、発想は斬新かもしれない。経済学が、膨大は論理とデータを消費する学問がもう一つ増えるのであろうか。 原価計算に基づかない見積もりに、どういう意味があるか、あるいは原価計算に基づいた見積もりをするが原価部分は公開できないということであろうか。 ソフトウェア開発の資源として重要なプログラマの原価の計算が十分でなく、性能（能力）の評価が十分でなければ、よいものは作れないのではないだろうか。 見積もりにおいて、誰が担当するかによって原価が違うはずであるが、顧客にはそれは知らせないのが慣習になっているのだろうか。 その他の課題としては、調達の基準である各種国際標準との関連が明確でない点である。 受入試験をどうやっているかによって、見積もりの精度が変化するかについての記述があるとよかったかもしれない。

ISO/IEC 14764 （kaizenさん 2008-01-17）
JIS X ０１６０ソフトウェア技術−ソフトウェアライフサイクルプロセス−保守 として、日本語で読むことが出来ます。 www.jisc.go.jpで無償で閲覧できるほか。 ダウンロード、紙での購入は www.jsa.or.jp でできます。 ソフトウェア保守と、ソフトウェア運用は、何が違うのでしょうか。 ソフトウェアはなるべくメンテナンスフリーに書いて、運用費用を安くするべきものではないでしょうか。 安易に、保守と称して、運用をまかせていないでしょうか？ そういうことを考える出発点になるとよいかもしれない。 ps. IT関係の国際規格はISO/IECのはずなのに、IECを外す出版社がしばしばある。 これはなぜでしょうか？

保守開発にスポットを （徳明木 望さん 2007-12-05）
新規開発業務に比べて、標準化整備ができているようでできていない保守開発業務。 新規開発の延長線上で考えられていることが現実だが、取り組む姿勢・観点は違うというのが本書の主張。 保守が発生しないシステム開発はありえない。システムは使うために作るもの。システムライフサイクル全体で捉えなければ、ＳＥとは言えない。 かなり現場の現実の状態に迫りながら、保守業務について語っている。 保守業務の要員に必要なスキルを含めて、どのようにしていくことがより良い仕事をすることにつながるかメスを入れている。 システム保守を担当する技術者は必見、と言っていいと思う。

デジステのソフトが優れている理由 （モリコウスケさん 2009-05-07）
著者の平野さんが代表を務める、デジタルステージという会社のソフトがなぜ優れているか、 そして、ユーザーに支持されているかがわかる本です。 それは、平野さんが「めちゃくちゃ普通の感覚の人」だからこそ、いいモノを作り続けることができているのです。 ソフトを作っている時点でかなり世間とズレている。そのズレを自覚できている人なのです。 (他との比較では、自覚できていないのがPS3、自覚できているのがWiiとも言えます) 昔、ラジオパーソナリティーでパソコン電話相談番組をやっていたとき、番組後にすべての問い合わせに対して平野さんは折り返し電話をして答えていたといいます。 オンエア中に解決できない問題があった場合には、なんと翌日以降に、平野さんがその人の自宅まで自腹で行って、直接パソコンを修理したりしていたそうです。 平野さんはこの経験を 「絶対に普通は手にすることができない掛けがえのない財産を手に入れました」 と表現しています。 こうした感性と経験に裏打ちされて、 ユーザー志向のモノづくり、ユーザーとともに成長していきたいというデジステの考え方につながっているんだなあ、といたく共感しました。

デジタルに働く社長のステレオタイプを破壊する、体温を感じさせるいい内容の本だった。 （久保田夏彦さん 2008-03-08）
なかなか良い本だった。筆者はデジタルの世界で生きて、ソフトウェアをつくり、グッドデザイン賞を５回も取り、一見クールな履歴。 しかし、本の内容はいい意味で青臭く、ウェットで、体温が感じられるものでした。 マンガしか読まないといいきってたり、仕事のできる人はPCに向う姿勢も絶対に前向きで早いとか。 面白いエッセイがいろいろあり、休刊になってしまったマックパワーの人たちが最後にまとめてくれたのも、うなずける。 かなりさらっと読むことができるし、デジタルワールドを仕事にしている人には、参考になる点も多いのではないでしょうか。 僕も合宿とかやってみようと思いました。 筆者の仕事に対するTIPSをまとめた本とか、ぜひ出して欲しいです。

平野さん、いつまでも応援します。 （asakuramkさん 2007-09-21）
私の一番好きな会社の社長が書いた本です。 といっても会ったことありませんが。 ここが製作するソフトウェアには感動があります。 感動のきっかけを作り出している平野さん。 こんな人、周りにいても実際は空想に浸るのが関の山と思います。 しかし、彼はその精神で今の会社を継続させている。 最後に書かれてましたが、その精神は父から受け継いでるものであり、またその父である叔父からも続いているものです。 わたしの琴線に響いたを一冊です。 ぜひ、一読を。

超実践的 （Joeさん 2009-03-04）
正直、超実践的な内容です。 同業者で非常に興味があったのですごく参考になりました。 うちでも開発手法の幾つかを取り入れさせていただきました。 入門書ばかりが目立つジャンルの中で非常に珍しい本だと思います。 したがって初心者が読んでも絶対わけわからないと思います。

アーキテクトの本懐を赤裸々に綴る （藤原紀章さん 2008-03-23）
とてもすばらしい本です。 なにがすばらしいかというと、 @実務に使える Aアーキテクチャとは、処理方式のことである。 B「ビジネスとITの融合」などといったわけの分らないことを行っていない。 CDOAが開発成功の早道と悟りきっている。 のC点に集約されるでしょう。 ただ、著者の劣悪な境遇には、ただ涙するだけです。 すぐれた技術書はすぐれた実務家によって書かれることを改めて確信しました。

ソフトウェア工学？ （eva2014さん 2008-05-16）
ソフトウェア開発は、事務職でサービス業だと断定している点が疑問。 なぜ、「ソフトウェア工学」なのだろう。 大学の情報処理関連の学部が、工学部にあって、文学部に無いのは、どう説明するのだろう？ プログラミングが著者のいう仕様書をプログラムに翻訳する単純作業と定義できればいい。 現実に大規模開発の現場では、そういう人材も使わないと人手不足なのは、 分かる気がするが、あまりに極論すぎる。 しかし、ソフトウェア工学の成果を実際に現場で活用する方法が具体的に示してあるのは、 評価できるし、なるほどと思う部分もあった。 理系ではない大量の人材を使わざるを得ない初級管理者や、 理系ではないが、プログラマーしか職の無かった人が読むには向いている。

既存のコードを修正できないでいることがよくあるとお聞きしています。 （kaizenさん 2008-03-21）
既存のコードを修正できないでいることがよくあるとお聞きしています。 自分でも、自分の作ったプログラムのバグが取れずに、ある方法で動かすと現象がでないので、そのままにしているものがあります。 どうにもなんともならなくなる前に、一度、作り直す機会があるとよいかもしれません。 CPUが変わるとき、OSが変わるとき、メモリの大きさが変わるとき、クロックが変わるとき、どんなときがよいかはわかりません。 何かが変わるときに、一緒に変えると、何が原因かがわからないので嫌だという話はお聞きしたことがあります。 その気持ちもわかるので、既存のソースを直すのは、実験的な作業だけにとどめたい気持ちもあります。 そんなぐだぐだした状態に喝を入れるヒントがみつかれば儲け物かもしれません。

全く使えないわけではないですが （tadaさん 2008-07-02）
ソフトウェアを開発するにおいて必要な事項、基礎知識などはおさえられるが、組込みソフトウェア開発についてはあまり触れていない。 組込みソフトウェア開発というよりはソフトウェア開発全般を取り扱っている。 この本の題名を「組込みソフトウェア」開発基礎講座にする必要はなかったと思う。 正直期待を裏切られた。

技術リーダーのための基礎講座 （哲学屋さん 2007-07-12）
基礎講座とあるが、技術リーダーのための基礎講座としたほうが良いかもしれない。組込みソフトウェア開発技術と開発管理に関するさまざまな情報に著者の経験が織り込まれて記述されているので、現在採用している手法の検証や新たに採用しようとする手法についての予備知識を得るために本書は有効であろう。またプロジェクトのポイントポイントでも本書は技術リーダーに多くの気づきを与えてくれると思う。個人的には第7章「エンジニアが陥りやすい誤解」、第8章「原点の再確認」に「うんうん、そうだよな」と思うところが多かった。同意できてもなかなかプロジェクトをそのように運用できないのは難しいものだが :-P 技術面だけでなく、チームでの開発について語る本は少ないこともあり、貴重。本書を読む人は、できればデマルコの著作もあわせて読むと良いと思う。

こんな本は書いても、売っても、買ってもいけません （憂い人さん 2007-05-29）
組込みエンジニア教科書シリーズの基礎講座というので買ってみたが、どこにも組み込みらしいことは書いてありません。ビジネス系のことも書いてありません。まったくなんのためにこの本が出版されたのかわかりません。責任をもって執筆し出版してください。

ウォータフォールじゃない場合はどうするの？ （kaizenさん 2007-12-25）
お金儲けには、ウォータフォールが一番確実という話を聞いたことがあります。 それで、本当によいものが、やすくできれば問題はないかもしれません。 しかし、例えば、安全に関するソフトウェアは、お金儲けだけを考えていると成功しないかもしれません。 現場の作業は、ウォータフォールではなく進展していく場合には、どのようにすればよいでしょうか。 また、システムのテストを開発前にモデルを使って行うというのは、よくあることですが、しばしば出てくる図では、最後になっています。 組込みソフトウェアでは、対象によって、作業がさまざまに違いときに、 本当にこのガイドが役立つ人と、読み込みが浅いと、無駄なことをさせようという場合とがでてくるかもしれません。 現場、現地、現物で対応するのが一番よいかもしれません。 その際の原則として比較対象にするのには便利だと思います。

多数のドキュメント間の関連がわかる （にじおじさん 2006-11-20）
ETでも配られていたようですが、「ソフトのドキュメントが多すぎて、何が何なのかわからない！」って人にはいいと思います。 それぞれのドキュメントの目的がわかりやすく記載されています。ウォーターフォールモデルを元にドキュメント関連がわかるようになっていますので理解しやすいです。 よく「機能仕様書とは？」という定義が関係者間であいまいになる場合は、まずはこの本の定義に習ってみるといいでしょう。

構成管理をはじめる前に （わなびさん 2006-12-28）
本書は「Subversion実践入門 達人プログラマに学ぶバージョン管理」で参考文献に挙げられています。 この本は、構成管理を（デザインパターンと同様な）パターンとして紹介し、かつ、パターンを単独でなく相互に関連するパターン言語としても紹介しようとする本です。 パターンの相互関連図もついているので、わかりやすいと思います。 日本語版の表紙はちょっと硬めですが、内容的にはそんなにもったいぶったものではありません。 翻訳上の誤字・誤記がいくつかはありましたが、全体に読みにくくはありませんでした。 本書には、全部で16個のパターンが紹介されています。 各章の表紙には、その章の暗喩となるような、大きめで、少し古風な写真が使われているのがなかなか素敵です。 巻末にある各種構成管理ツールの比較概説も、かなり参考になりました。 私にとっては、ぐいぐい引き込まれるような本ではありませんでしたが、構成管理を始める前や、ちょっと迷ったときなどに、一読の価値はあると思います。

CVS/Subversionの使用方法みたい （Turtleさん 2006-12-08）
ソフトウェア構成管理ということで、内容はソースコード管理のパターンについて記述されています。CVS/Subversionでブランチを活用した管理をすでにやられている方には当たり前の内容となっています。VSS主体でブランチなどあまり使ったことがないという方であれば、一度この本を読んでSubversionなどのツールで適用するとよいでしょう。 私個人としては構成管理をもう少し広い範囲で捕らえていたのでちょっと物足りないというのが実感です。

Unified Process適用事例です。 （Turtleさん 2007-02-07）
開発時の管理ツールを作成するという小規模分散プロジェクトにRUP(Rational Unified Process）を適用した事例を紹介したものです。RUPなら知っているよ、という人は不要でしょう。最近はOpenUPというものもありますのでRUPは知らないけど、UPは興味がある、という方は一度読んでもよいのではないかと思います。 「ソフトウェア開発の課題１ソフトウェア開発の持つべき文化」と内容が若干重複するところがあるかもしれません（私は重複しているなと感じました）。

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

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

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

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

インフラ・もしくはミドルウェア開発者向けかな （Turtleさん 2006-10-27）
以前であれば、バッファオーバーフローなどはCやアセンブラで注意しなければならない事項で、この手の本は非常に役に立ったのですが、いまじゃC#やJavaで大半が実装されており、この本に書かれている内容はあまり意識しなくていいんじゃないかなと思います。C#やJavaではもっと別に注意しなければならないことがあるはず。 ただ、httpサーバやJavaEEプラットフォームなどミドルウェアを実装している方は相変わらずこの本に書かれている内容は理解しなければならないはず。当然、そうしたミドルウェアを使用する方（インフラ担当者）も理解が必要だし、アプリケーションアーキテクトもこうした知識は必要でしょう。 C#やJavaのアプリが全盛のこのご時勢、あくまで上級者向きの内容ではないかと思います。

利用者の直感 （kaizenさん 2007-12-25）
ユーザビリティは、設計者、利用者の直感による部分と、設計の体系化による部分とがあるかもしれない。 また、道具は使い方を規定していないことがあり、使う人の自由に任されている部分があるかもしれない。 そういう自由の海を乗り切るためには、何かガイドがあると嬉しいこともある。 そういう時に読むと役立つかもしれない。

現場技術者にとっては当たり前すぎる内容 （くまぷうさん 2008-09-07）
たしかに新人さん向けにはいい教科書になるかもしれません。 しかし現場で求められているのは「この本を書けるぐらいのスキルの人」だったりします。 また、この本の通りだと「とても初心者っぽいコード」にもなります。 充分なスキルを持つ人達を対象に、より保守性に優れたコードを記述するためのアイデアを 盛り込んだ書籍の登場を期待しています。

役に立つ視点を提供している重要な本 （kaizenさん 2006-11-27）
C言語のコーディングガイドには自動車向けのMISRA-Cがあります。 自動車では、カーナビを除いて、メモリは静的に決定して、動作中にメモリを確保、解放する方法を取っていないそうです。 その理由は、検証可能なコードでないと、安全性を確保できないためだとお聞きしいます。 MISRA−Cは安全性だけでなく、可搬性、移植性を取り上げています。 可搬性、移植性のないコードに対して、厳密な文書化を要求しています。 MISRA-Cの厳密な議論は、初学者には何をしていいかわからないことがあります。 そのため、C言語の初学者に、MISRA-Cを利用する前段階としてpuzzle bookを読むことをお勧めしています。 本書では国際規格であるSQuaREというソフトウェアの品質の規格の視点で評価した貴重な本です。 ps. 専門家にとっては、CPUの規格がないことによるISO/IEC 9899:1999の未解決の問題およびCの精神の課題について十分な解説をしていない点に不満が残るかもしれません。 また、ISO/IEC 9899:1990の未解決の問題でISO/IEC9899:1999で解決した問題についての言及があるとより嬉しいかもしれません。

新入社員に教えるのに適切な本です （のり吉さん 2006-07-11）
会社にて、この本を拝見しぜひほしいと思いましてこの度購入させていただきました。内容は、丁寧で”あーそうだね”というような感じでさらりと読むことができ、新入社員などにＣ言語を教えるには、丁度よい１冊ではないかと思いました。

モデリングの本なのに図のレビューが甘い （オドリー南の島さん 2008-11-25）
クラス図，コミュニケーション図，状態遷移図の相互関係をチェックすると， 整合性がとれていない部分が多数ある。 本当に読もうとすると，あてにならない記述が多いので注意したほうがよい。 たとえば，p124とp125の両方に重複してポットクラスがあったりする。

状態遷移が肝でしょうか。 （kaizenさん 2008-03-21）
対象物の状態遷移を記述できれば、制御が可能だという意味で、オブジェクト（対象）指向は有効なのだと思われます。 モデルを作る場合に、対象（オブジェクト）を記述していくのが王道なのだと思われます。 本当に必要な技術と、内容を確かめるために使う技術と、試験のための技術との詳細な説明があるとよいかもしれません。

オブジェクト指向入門者から中級者まで特におすすめ　 （むにゃさん 2006-06-17）
表題にあるとおり組み込み向けのオブジェクト指向本です。 ポットのシステムを題材とし、ユースケースから実装までの一連の流れについて記述があります。また、単なる開発の流れのほかに開発で当然必要となる設計品質とレビューについて記述があるところが大変よいです。 特にオブジェクト指向で初心者や勘違いをしている中級者が迷う分析の視点をどのようにクラス・状態遷移・コラボレーションにマッピングするかの思考の過程が書いてあるところがいいですね。 組み込み向けということでメモリマッピングやタスク分割についても一通り記述があり、単なるオブジェクト指向本では学ぶことのできない組み込みを開発する上での基礎技術も網羅されています。 ただ、気になったことが組み込み向けとありますが、組み込み以外の一般的な開発にも使えるので表題は微妙なところですね。オブジェクト指向本としても十分な内容です。 構造化の第２弾ということですが是非シリーズでイテレーション開発をからめて続編が欲しいところです。

盛りだくさんの情報 （kaizenさん 2007-12-25）
ソフトウェア品質に関連する技術が盛りだくさんの紹介。 一つ一つだけでも、１冊の本になるので、体系的な学習の出発点としてはよい。 一つ一つの技術を評価して、採点していくと、自分に本当に必要な技術につきあたるかもしれない。 モデルによる設計の５つの利点をあげている。 「正確な設計が可能となる」 仕様が明確な記法を使う 「設計が見えるようになり、レビュー効率アップ」 図示、または表にすることにより、問題が明確化 「コミュニケーションが円滑になる」 定義が明確なので意思疎通が容易 「シミュレーションや検証をツール化できる」 道具の連携が可能 「標準化が促進され再利用が容易になる」 部品化可能に 言い換えてみると、なるほどと分かる。 ps. ライフサイクルプロセスといいながら、ウォータフォールしか想定していないような出だしはなんとかならないものか。V字で一方向でしか考えれないようだと、品質が保証できるかが怪しいかもしれない。

定量データは５年必要 （kaizenさん 2007-12-25）
人に関連する統計は、５年とり続けてみて、初めて嘘と嘘でないものとの区別がつくかもしれない。 そのため、1年だけ見て、善し悪しを判定するだけではなく、５年間分を並べてみて、測定方法、測定対象の傾向を分析したときに、役に立つ知見がでてくるかもしれない。 そんな出発点としては、まずここからという感じだろうか。

図表のかたまり （張小東さん 2006-10-05）
名前は２００５年の”定量データを徹底分析”から”定量データで示す開発の実態”に変えたので、あんまり強く言えなくなったが、やはり分析が欠けている。 データの価値不明 １４００のプロジェクトのデータを集めたが、これらがその時期に該当企業の全PJ？あるいは業界の売り上げのほとんどを占める？または無作為で選んで会社のPJ？ではないので”開発の実態”って本当に示されているのかどうかは疑問。

見積もりは不正確でよいのでは？ （kaizenさん 2007-12-17）
本書は、見積もりのいろいろな事例を紹介しています。 定型的な開発では、見積もりが容易だと言われています。 しかし、定型的な開発なら自動化できるので、ほとんど費用はかからないかもしれません。 何に費用がかかるのでしょうか。 ITで見積もりができれば、製品が完成したも同然と言われることがあります。 新規開発では、見積もれない要因があるので、少し開発をし、試験をしてみて、全体を見積もるのでないと現実的な見積りにならないという話をお聞きしたことがあります。 インクリメンタル開発、プロトタイピングなど、見積もりをするためのソフトウェア開発をしている場合があります。 本音と建て前の間の差は、見積もりの誤差よりも大きくないでしょうか。 見積もりの協議のきっかけの出発点として、お互いに何を見積もりたいかの議論の出発点としてよい本ではないでしょうか。

怪しいものと、怪しいものの２乗になっているかも。 （kaizenさん 2009-05-28）
ユースケースは、UMLの道具の中で、頭の整理のために使うか、 最後に試験の事例に過不足がないかを確かめるために使うかの ２つの使い方があることが知られている。 本書では、その一つの使い方に限定して、話を展開していないだろうか。 また、アスペクト思考とは、 構造化、オブジェクト指向の流れの一部であって、 構造化＞オブジェクト指向＞アスペクト指向と、 前者を前提にしたより狭いところを指すものではないだろうか。 ２つの怪しげなものが組み合わさっても、優秀な人書けば、 ソフトウェアができあがるという実証かもしれない。 著者の能力の高さが、本書の支えではないだろうか。 いずれにしても、能力の高い人の書いたものは、参考になる点が多い。 ただし、自分の能力ではできないことも平気そうに書いているので、 間違って同じ方法を取ろうとすると、失敗するかもしれない。 そんな気がする今日この頃です。

ユースケース駆動モデルとAOPを紐付ける最新の教科書！ （やぶさん 2007-11-11）
まず、本書の目的の何たるかを知って置いたほうが良いでしょう。 結論から申しますと、C++やJava、.NETといったOOP言語ではAOPの完全実現は行えないことに注意してください。本書においてはAspectJを例に取り上げ、AOPとは何かを説いています。 つまり、「AOPとはこういうものである」ということの理解を助けますが、既存の主流言語では実現の限界性があることを加味して、参考とすべきであるということになります。 では、本書は絵に描いた餅であるかというと、決してそんなことはありません。あくまでランゲージ・ニュートラルであることをイヴァー・ヤコブソン自身が明言しており、ユースケース駆動モデルとAOPは対局しないことを謳っています。 ユースケース駆動モデルの可能性がAOPにおいても通用することを示唆していることでもあり、また本書でAOPの何たるかが分かれば、それに沿った設計を行うことでAOPらしい設計〜コーディングを行えるでしょう。 バージョンアップや修正が発生したプロジェクトでも、新規機能や複数のクラスを横断する機能(つまり他のクラスに依存するクラス)の機能をポイントカットとしてアスペクトの中に包含するという考えは、ユースケースにおける>と考えられます。 こうしたことを詳細に、またユースケースからロバストネス分析、設計モデルまでの流れも説明していて、ユースケース駆動モデルの実践的応用にも役立つことかと思います。

うまく構造化できれば （kaizenさん 2008-03-21）
うまく構造化できるということは、うまくモデルが作れたというのと同義だと思っていました。そのため、要求分析、設計、ソースコード作成は一体として構造化へまっしぐらだという感じです。 対象となるシステムによって、構造化の仕方が違うかもしれません。 経験が豊富ではないので、本書も一つの事例として参考にさせていただきます。 ありがとうございます。

大学の教科書にぴったりじゃない （組み込み太郎さん 2008-02-03）
構造化は、コーディングでは常用されていて重要だと思う。大学初年の教科書にぴったりだと思う。 プログラミングの知識として必要だと思う。ただ、オブジェクト指向なのが、ちょっと気にかかる。 欲を言えば、純粋に構造化だけで書いて欲しかった。と申しますのは、オブジェクト指向にしてしまうと、継承の問題がからみ、実際にコーディングが終わると反省会で良くなかったねとなるからです。 現場では、オブジェクト指向より明示的メソッド（全部自分で書く事になるけど）の方が良く使われます。 でも、良本です。

構造化の本って重要なんじゃない？ （むにゃさん 2007-01-17）
組込み系はOO開発と手続き型（機能型）開発の２種類あります。 一般にエンジンボードといわれているところは手続き型のC言語で記述しているところも多々あり、現場ではまだまだ使われているのではないでしょうか？ sessameが著書のオブジェクト指向もありますが、オブジェクト指向のベースの一部は構造化からきていることもあって合わせて読むと理解が大変深まります。 オブジェクト指向編では何故構造化が悪いのか、悪いというか陥りやすいアンチパターンについて書いてあり、手続き型の開発からオブジェクト指向開発に移行する際にもためになるでしょう。

おもろい （あさん 2006-05-01）
まだまだ開発現場に オブジェクト指向開発が浸透してるわけでもない昨今 組込み系と構造化モデリングの組み合わせは 現場に即したものではないでしょうか。 オブジェクト指向設計を学ぶ前段階としても 意義のある著作だと思う 欲をいえば モデリングツールであるDFDとかCFDそのものを もうちょっと突っ込んで詳しく解説してほしかった 続編を望む

ソフトウェア開発 で伸びなかった人間からすると （kaizenさん 2009-10-03）
ソフトウェア開発 で伸びなかった人間からすると、本書に書かれていることはちょっと違うなと思いました。 あるいは、著者と伸びる方向が違うのかもしれません。 ソフトウェア開発で伸びる人とは、ソフトウェア開発が効率的にできる人ではなく、開発したソフトウェアが効率的である人だと思うからです。 開発したソフトウェアが、顧客の役に立つのでもなく、社会の役にも立つものでもないものが、利益率が高いことがしばしばあります。 ソフトウェア開発が効率的とは、役に立たないものを高値で売り払えれば、すばらしく効率的だからです。 ソフトウェア開発で儲けらるようになった人を、伸びた人だとすれば、本書は役にたつのかもしれません。 いずれにしても、読者が、そこから何を得るかが重要ですので、役にたてるかどうかは読み方の問題かもしれません。 反例だと見るか、凡例だとみるか、範例だとみるか、判例だとみるか。 立場によって、得られる質と量が違うかもしれません。 自分では、いろいろな反例を知ることができたので、本書は貴重です。

アラサーの社会人に読ませたい （Н∧Lさん 2009-09-25）
この本は、プロとしてのモノの見方考え方を、伸びない人との対比をすることによりわかりやすく説いている。 すべて「あるある」と納得するものばかりだが、特に気に入ったフレーズは 「何のためにやるのか」- 目的指向 「良いプライド・悪いプライド」-分らない自分が恥ずかしいのか、 分らないことがばれるのが恥ずかしいのか。 「あなたはソフトウエア開発者ですか、ソフトウエア作業者ですか？」- 常に改良の努力を惜しまないか？ きっとこの本を手にとる読者はすでに「伸びる人」である可能性が高いと感じさせる。 読み方次第では、本人の資質で伸びる人は伸びるとも読めてしまうが、 考え方を行動特性ととらえて、伸びる人のまねをするところから始めるのも自分を伸ばす助けにはると思う。

ソフトウェア開発に携わる者の教科書 （じゃが〜さん 2009-09-20）
出来れば20代のうちに読んでおきたい本。 実は、ソフトウェア開発で「伸びない人、伸びる人」と「幸せになれない人、幸せになれる人」編から構成されている。 なお、必要な技術として言語力(国語、英語、抽象化力)、目的志向などいくつかの力・スキルが上げられており、それぞれを磨くための本も推薦してある。いずれの本も古典ながら長く読み継がれてきた名著が多い。

自分のために読めました （北村義治さん 2009-06-28）
ソフトウェアに関する仕事をしていてどうも 自分が伸び悩んでいるように思っていたのですが そんな時、この本を読みました。「伸びない原因」 のいくつかが、ピタリと自分に当てはまってしまったので ショックではありましたが、逆にその面を改善して いけばいいかもしれないと思えました。 自分なりに分析してみて、頭の中だけで新しい 技術などを理解したつもりになってしまっていて 実はそれが身につかずに、それが積み重なった結果 行動が起こせなくなってしまっているようなので 変なプライドみたいなものは捨てて、これから先が 有意義になるように、 できることから実行していきます。

自分の行いを見つめなおすきっかけになるかも？ （marknさん 2008-02-21）
タイトルどおり、ソフトウェア開発現場で伸びる人、伸びない人が、さまざまな シチュエーションにおいて、その行動を対比しながら書かれています。 こういうとき、伸びない人はこうする、伸びる人はこうするみたいに。 ただ、他の方も言われているように、この本の『伸びる人』全てに当てはまる人は ほんとに完璧超人です。そりゃ伸びますよってな人です。ほとんどの人は、 全てに当てはまるようなことはないと思います。 多分この本が気になった方は、何かしら日ごろの仕事の上で思うところがあった 方々だと思われます。そういう方は是非、『自分ならどうだろう』と考えながら 読んでみられるといいと思います。自分に足りないところが見つかると思いますし、 逆に自分の強みも見つかることと思います。 ただ、やはり他の人も書かれているように、読んでいて疲れます･･･。 多分自分自身で無意識の内にでも感じ取っているネガな部分が、客観的にかつ 簡潔に指摘されているからかな？と思いました。これも、無駄なプライドの ひとつかもしれませんね（^_^;

マイコン組込みシステムの開発に関する知識の整理に参考となる本 （Makoto Ichikawaさん 2008-12-12）
マイコン組み込みシステムを開発するのに必要なハードウェア、ソフトウェアなどの全体の知識を提供することを目的に編集した本と考えられます。大学･高専などで電子電気工学を学んだ人が実務でエンベデッドシステム開発の仕事に取組むに際して、知識の整理に使用するのがよいと思います。なお、本書は一般論となる入口の部分を示すのみであり、もし、自信のない部分があったら他の専門書を調べて深い知識を修得するのがよいと思います。 実践的な知識を得るには、H8とかSHとかターゲットとなる具体的な組込み用マイクロプロセッサと開発環境について書かれた書籍やWebサイトを調べることが有用です。

組込み技術者の基本文献 （kaizenさん 2008-05-12）
この本から、わからない単語を１００個抽出して、ネットで情報源から意味を調べ、体系かしてみれば、入門段階を脱するのではないかと思います。 書籍は、道具ですから、利用の仕方が分かれば、便利な勉強の対象になります。

ファームウェア経験者が知識をまとめるのには良い （もなりえるさん 2007-02-09）
ファームウェア経験者が読むと知識の整理になると思います。 本の厚さの割には説明文はやや不親切です。特にRTOSの説明はかなり不親切で、説明になっていないのではないかと思うところもありました。 そのため、ファームウェア初心者には向いていないと思います。 巻末に平成17年度のテクニカルエンジニア[エンベデッドシステム]の過去問題が付属しているのですが、 この本は情報処理試験対策本という訳でもないのにこんなオマケをつけても余計な気がします。 こんなオマケを付けるなら、説明をもっと丁寧に書くべきではないでしょうか。

入門書として （sakuさん 2006-02-08）
かなり読みやすいです。組み込み初心者の方だけではなく、経験者にも知識の体系作り／復習として参考になると思います。 テクニカルエンジニア（ＥＳ）を目指すのであれば、この１冊だけでは厳しいですが、まずは入門書として読むのが良いかと思います。

中級編？ （モン太さん 2006-02-01）
ある程度、組込みを知っている人向けです。 活字が多く重要語は太字になってますが全ページ白黒です。図もそれ程多くは掲載されていません。過去問も1回分しか載ってませんので資格を取ろうとする人には向かないでしょう。

１００年使えるモデリングを会得する （kaizenさん 2008-10-06）
ソフトウェア関連業界では、自転車操業で、１００年使える技術について、視点を持っている人は少ない。 流行に流されないという視点を持つだけでも、本書は貴重だと思う。 ハードウェア、ソフトウェアの均衡もよいので、ぜひ、続編または改訂版を出して欲しい。 ps. 名古屋のトラフィックシムという会社では、「１００年続く会社」を目標にされており、 「組込み開発事例集」に掲載されています。

組み込みソフトの基礎を学びたい方へ （masamiさん 2006-03-23）
私はハードウェアに関しては知識が乏しいのですが、私が読んでも理解できる程度に、わかりやすく書かれていました。 第４章「100年使えるモデリングを会得する」の中の、システムのモデリング（状態遷移モデルの作成）で扱われている、「アカウント・バンク」という商品の製品設計の具体例や、第５章「製品開発の生命線、ソフトウェア・テスト」の中の、まちがいだらけの自動テストで扱われている、「携帯電話」のテストの具体例は、ハード／ソフト製品の第三者検証を生業とする私にとって、大変参考になりました。 技術者の卵、または若手の技術者にとって、一読に値する本かと思います。

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

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

MISRA-Cについていけない人の入門書 （kaizenさん 2007-12-25）
MISRA-Cは、大変役立つコーディング標準だが、C言語初心者には敷居が高すぎる。 本書は、そういう初心者の入門編としてたいへんに役立つものと思われる。

ソフトウェア技術者をまとめるには （kaizenさん 2007-12-25）
人と話をするのが嫌だからプログラマになった人に、 人と話をしろといっても、何の解決にもならないかもしれない。 そんなジレンマに陥ったときには、世の中で流行っていることに手を出すのもいいかもしれない。 あるいは、じっと、事実を見つめることが大切かもしれない。 その選択をするのは、自分自身。 ある先生から、プロジェクトマネージメントは計画管理と訳せと教えられたことがあります。 プロジェクトマネージャという用語を使う会社はありますが、会社によって役割は全く違うことがあります。 また、権限を与えずに責任だけを割り当てて、仕事のやる気をなくさせている企業もあるように聞いています。 実際に話を聞くとチームリーダという人の管理の役割だけを持った人がいます。 予算も人事の権限もないプロジェクトマネージャと呼ばれている人が、責任だけを押し付けられて右往左往していないでしょうか。 さまざまな疑問に、この本はどれだけ答えてくれているでしょうか。 さらなる改定で、例えばプロジェクトマネージメントという用語を止め、現場の管理者に役立つ名前を提案するのはいかがでしょうか。 短期のプロジェクトが多い場合には、プロジェクト管理ではなく、組織管理で対応すべき事項もあるという話を、ソフトウェア工場の松本先生からご指導いただいたことがあります。 ps. 「プロジェクトマネージャって事業部長のことですか」と聞かれたあなたはなんと答えるでしょうか。

本書から何を学ぶかは必要に応じて （kaizenさん 2008-02-16）
SWEBOKはソフトウェアに関連する知識を体系的に整理したもの。 英語の文献を中心にしているため、日本の知見が十分に入っていない可能性がある。 ただし、五輪書、改善（KAIZEN)などは英語にもなっているのですべてが欧米文化依存であるとは限らない。 理論を振りかざして現場での創造的な実験を認めない人達には読んで欲しくないが、現場で何か困ったことがある人は、ぜひ読んで欲しい。自分に必要な知見がそこかしこにあるかもしれない。SWEBOKはISO/IECからTRとして発行されている。 プロジェクト管理が欧米で強く、組織管理が日本で強いと言われている。 CMMIの水準４，５が日本が強く、欧米は水準２，３が強いと言われている。 日本でプロジェクト管理や、水準２，３を目標にしてはいけないことが本書から読み取れるようになるとよいかもしれない。 知識体系を吸収すればするほど、知識以上に大事なのは現場での改善であって理論を振り回すことではないということに気がつけくとよいかもしれない。

ソフトウェア工学の全体像が見れる （masayh4さん 2005-08-27）
前半の解説は筆者ご自身の研究成果に基づいてSWEBOKを分かりやすく実践的に解説しています。この部分には、要求変化に対応してアスペクト指向開発の考え方を取り入れた現代的な設計アプローチを説明しています。この部分だけでもこの書籍を手に入れる価値があります。後半は、SWEBOKを辞書的に扱うための解説です。こちらは、参照用に活用できます。中上級者が知識を整理するために最適だと思います。

傾向を見るための道具 （kaizenさん 2007-12-25）
生データは、しばしば公表が不可能なことがある。 そのため、分析チームに入っていないと、出ているデータで欲求不満になるかもしれない。 しかし、５年くらいのデータを比較していくと、分析した人たちとは違った視点での分析が可能になるかもしれない。 一つの業界には、最低でも１つのデータ集は必要である。 最良の一つか、最低限の一つかは、手に取った人の価値観かもしれない。 あるいは、何のためにデータを料理したいかかもしれない。 社会統計に絶対がないことがわかっていれば、料理の仕方はわかるはずである。

ＳＥ持つべき一冊 （張小東さん 2005-09-13）
1000個以上のＰＪの統計データ、多角度な分析、大変参考になる一冊。と同時に、データ公開度が低く、生データがなく、再分析不可。分析が少なく、掘り下げないなどの問題もある。とはいえ、2000円以上の価値があるのは間違いない。

未踏ソフトウェア創造事業の紹介 （UMEOKAKAさん 2009-05-16）
IPA（情報処理推進機構）の実施している未踏ソフトウェア創造事業に採用されたプロジェクトの紹介です。 １１件のプロジェクトが紹介されています。 登場された方々やソフトウェアは、検索してみると有名な方ばかりです。 優れたソフトウェアの生みの親・その背景と支える方々の話は、そのソフトウェアに対して親近感を与えてくれます。 タイトルは、ちょっとおおげさですね。

ＩＰＡのソフトウェア開発支援事業に応募してみては？ （自営業やまぐりさん 2005-07-16）
ＩＰＡは大げさな名称をよく使うがこの本のタイトルもその一つ。「日本の匠」とあるのは「匠の雛達」とした方が適切ではないか。そうは言っても、この本には、ＩＰＡのソフトウェア開発支援事業における具体例として、ソフトウェアと開発者の取り組みを、創造として４例、安心として４例、競争力として３例、紹介してある。読めば、必ず、その開発者の挑戦する姿勢に共感または刺激を受けることになるだろう。ＩＰＡの支援事業に応募しようと考えている方はもちろん、広くシステム・エンジニアの方々にもおすすめしたい本である。

IPAの取り組みの紹介 （the_worldさん 2005-07-06）
独立行政法人情報処理推進機構（Information-technology Promotion Agency、以下IPA）が行ってきたいろいろな取り組みをまとめた１冊。内容は、IPAの宣伝という側面が強いが、気になるというレベルでもない。IPAの支援を通じて成功した事例を読むと、自分もIPAを利用して頑張ってみたくなる。文章を読んでいくうちに、そんな気持ちが生じてくるぐらいの宣伝力である。IPA自体がいろいろなことをやっているため、本書に挙げられている例も、個人を対象にしたものから、グローバルレベルの大企業を対象にしたものまで様々である。IPAの活動自体が日本のITの問題を解決することを目標としているため、本書で上げられているいろいろな事例を読んでいくことで、日本のIT業界を取り巻く問題点を理解するためには役に立つかもしれない。ただ逆に、紹介されている事例が多いため、１つ１つの内容は薄くなってしまっており、面白い章、興味のある事例などでは、少々物足りなさを感じてしまったことは否めない。

日本のソフトウェア産業の底力やいかに！？ （ニャンゴロさん 2005-06-22）
ＩＰＡ（情報処理推進機構）が日本のソフトウェア産業の底力を挙げようと様々な取り組みを行っていることはご存知の方も多いかと思います。本書ではそのＩＰＡが取り組み実際に成功を収めているプロジェクトの紹介。そして日本のソフトウェア産業の問題点などを浮き彫りにもしています。ＯＳから開発言語まで海外製のために日本は不利なのではないかと思っていました。しかし実際の成功プロジェクトをみているとそんなことは関係なく、アイディアや実現するための技術などがあり、またそれらをしっかりとした支援する体制があれば海外製ソフトウェアにも勝るとも劣らないものができるのだと感じました。しかし実際に成功例ばかりが取り上げられていたのですが、今後は失敗例というものも見てみたい気がします。

書籍並みに読み応えのある雑誌 （espio999さん 2006-04-15）
要素技術の話題は雑誌から専門書まで選択の幅が広いですが、この辺の業務系の話題になると選択肢が無いですよね。事例紹介的な雑誌はあるんですけど、それがそのまま他所でも通用するわけではありませんし、参考にはなっても、それが自身の血肉になるようなことは無いですね。 かと言って、いきなり専門書に頼ろうとしても、それは高価、かつ高尚なものが多いため、あまり馴染みやすいものでもありません。その辺の話題を包括的にキャッチ･アップできるのがこの雑誌の魅力ですね。 参考文献も紹介されているので、馴染みの薄い専門書を購入するための指針、ガイドとしても有用です。 技術の話題が中心では無いので、紙面には画面キャプチャやコード解説などは皆無。ほとんど文字ばかりで、薄い雑誌ではありますが、その内容はかなり充実しています。 特集の合間、合間にコラムが挿入されているのですが、このコラムでも文字ばかり、10ページ程度のものが4-5編収録されています。 「ソフトウェア開発の名著を読む」と言うコラムで名著を数冊紹介しているのですが、これが実際の書籍の単なるあらすじではなく、原著の章毎の概要を紹介しているところが秀逸だったりします。これだけ読んで原著を読んだ気になってしまうくらい。 雑誌ではありますが、通して読むと軽い書籍並みの読み応えです。

方法論の説明と、ＰＭＢＯＫの応用 （lemonerikaさん 2005-04-10）
２部からなります。１部は、ＸＰ、スクラム、クリスタル、ＦＤＤなどの「アジャイルな方法論」についての説明です。各方法論について、その内容や特徴、適用範囲などが記述されています。２部めは、ＰＭＯＫの知識体系を、アジャイルな方法論に適用するとき、「適用できるのか？」「そのときの注意は？」などが、ＰＭＢＯＫの各プロセスに対応させて、説明してあります。ＰＭＢＯＫだと、こうだけど、これを、アジャイルに当てはめると・・・という構成です。分量としては、１部、２部半々でしょうか。方法論も、管理も、というなかなか贅沢な本です。そのためか、コンパクトにまとめられてあります。ある程度、方法論とプロジェクト管理についての知識や経験がないと、ピンとこないかも！です。

最新のアジャイル系プロジェクト管理法をコンパクトに網羅 （Dr. Jasonさん 2005-03-06）
プロジェクト管理の技法は，軍事，建築/土木，プラント，造船などの技術分野から発展したものであり，情報システム開発におけるプロジェクト管理は他の工学的領域に比べると，歴史の浅さなどから管理技法として必ずしも確立しているとはいえない．特にこの 10-15年ぐらいのあいだに，色々な手法が提案されているが，どれも「決め手」に欠ける感がある．そういう中で，今年のはじめに出版された本書は，ソフトウェア開発に関わる最新の「アジャイル開発」といわれるプロジェクト管理法に属する様々な手法の特徴とツボ，在来の方法論との差異について，コンパクトにまとめられた，新しい参考書である．筆者は，経験豊富な，オブジェクト指向技術，モデリング，プロジェクト管理などのコンサルタントであり，本文中の参考文献をみるだけでもその守備範囲の広さには感心させられる．IT関連のプロジェクト管理に携わるすべての人，特に他のアジャイル系の参考書をみてしっくりこなかった中堅PMに，推薦できる一冊である．

まとめ方は非常に洗練されている。 （keloidさん 2005-02-18）
午前全体と、午後の一部を扱うコンパクトサイズの参考書。これだけ小さくなると、さすがにスペースの都合で記述する内容が希薄になりがちだが、要点を抑え、少ない文章できちんとまとめられている。ただし、要点は抑えているものの、ある程度知識を持っている事が前提で書かれているふしがあるので、初学者がこれ一冊と過去問で挑戦と言うのは、無謀かもしれない。あくまで通勤通学時に、知識の定着化を図る、ないし基本情報取得者で、あと一歩まとめられた深い知識が欲しい人間向けには、大変有効な一冊となるだろう。

企業で必要なプロセス改善のオーバービューを与えてくれる （さすらいのスナフキンさん 2004-10-05）
記事の中の「統合的最適化戦略」の記事が我が意を得たりという感じ。自分の経験から身しても、プロセス改善などは導入の行いやすさから言えば、部署別で取り組んだほうが敷居は低いが、予算の限界、プロセス改善活動にタッチするマンパワーの不足などに陥りやすい。そして、最悪プロセス改善は成果を出さぬまま終焉を迎えるのが、多くの企業のパターンだろう。また、現在のように企業同士が合併などを行うまでして、競争力を高める時代には企業全体でプロセス改善、組織改革が不可欠だ。そのような場合の具体的な方法・ガイドを紹介した記事は見たことが無かったので、大変参考になる。

全体最適でソフトウェア開発を見直そう （jadlerさん 2009-10-09）
この本は、トヨタ生産方式（TPS:Toyota Production System)の考え方をソフトウェア開発に適用する手法について書かれた本です。ウォーターフォール開発の問題点を理解し、解決していく考え方として、多くのソフトウェア開発に携わる方に是非読んでいただきたい一冊です。 アジャイル開発プラクティスを理論的に補強する考え方としても最近注目されています。 TPS（トヨタ生産方式）は、TOC（制約理論）と同様、生産管理を改善する方法として有名です。その全体最適に基づく考え方は、TOC(制約理論）と同じ原理に基づくものと言えます。TOCが生産管理だけでなく、プロジェクト管理、流通、営業・マーケッティング、サプライチェーンといった領域にとりこまれてきたように、TPSの考え方の原理も「リーン開発」として、製品開発プロジェクトの手法にとりこまれています。 「リーンソフトウェア開発」は、「リーン開発」の考え方をソフトウェア開発に適用する手法について書いた本です。論理的に、「リーン開発」の豊富な事例とともに説得力のあるわかりやすい記述で説明しています。ＴＯＣの観点で読んでも納得できる内容です。TOCより、より具体的な原理で説明しているので、TOCをソフトウェア開発に適用するイメージがわかない方にもお勧めします。 TOCは全てを全体最適という観点で説明します。実際、「リーンソフトウェア開発」で挙げている７つの原則も全てを全体最適という原則で、さらにシンプルに説明できると考えます。 しかし、それだけに具体性という意味でわかりにくい面もあるので、この本に書いてあるような数の原則にした方が、理解しやすいかもしれません。

和訳が酷過ぎ （cotipeltさん 2009-05-13）
本文の内容的には、難しい事を書いているわけではないが、原文を翻訳した日本語文章があまりにも酷い。内容を理解する前に、本文の日本語をどのように解釈するかに労力を費やす必要がある。英語が得意な方は、原文版をお勧めします。

ムダを排除する （hatさん 2005-05-22）
ホンダ・ヨトタという日本の自動車メーカが始めた「リーン原則」を使ってアジャイルプロセスの擁護をしようという本。２２の原則はそれなりに着想が面白いのだが、いかんせん本文の説得力が弱い。というかほとんど説得出来ていない。「この本にはこう書いてあった」というだけでそれを「正」として扱い、論を展開していくので誰もついていけないはず。でもそれを超えて原則だけを見ると面白い事をいってるのに気付きます。ツール２の「バリューストリームマップ」はトヨタ生産方式そのものをＳ／Ｗ開発に適用した具体例が示されているし、ツール１７の「認知統一性」はプロジェクト運営の中で使える概念だと思いました。「リーンソフトウェア開発」という言葉自身がバズワードになる可能性がありますので、読む価値はあると思います。何かを得たい方にはお奨めしません。トヨタ方式すら知らない管理職の方には是非読んで欲しいです。自分がいかに生産性を下げているかに気付かれるはずです。

自分で考えるための本です （lemonerikaさん 2005-02-18）
「イントロダクション」によりますと、ソフトウエア開発のリーダーが、アジャイルプラクティスを、自分で作り出すためのヒントやツールの紹介だそうです。ですので、ＸＰ等のアジャイル開発の方法論が説明してある本ではありません。リーン生産方式や、過去のプロジェクトから、迅速な開発を進めるための考え方、進め方についての一般的なプラクティスの紹介、それを、自分のプロジェクトに適応するために、具体的に、どのようなツールで、何をやってみればよいか、の紹介です。ボトルネックや問題点の発見の方法、改善方法をどのように考えていくか、素早いチームを作っていくには？などです。ソフトウエア開発の改善に「何から手をつけよう？？」と思っている方には、参考になるのでは、ないでしょうか。入門書で、「アジャイル開発って何？」というのを、知っておいてから読む方が、良い気がしました。

原典をおすすめします （neu-neuさん 2005-01-23）
リーンのプラクティスは悪くないのだが、著者としての技量がいまいちなのか書籍として説得力に欠けるように思う。トヨタ生産方式をアジャイル開発に応用するという「ひらめき」が最初にあり、それが正しいものであることをいろいろな文献の「断片」を持ち出して正当化することに終始している。そのことは脚注の多さが物語っている。だが、読者にしてみれば「活字で世に出ていることがすべて正しい」とは思っていないので、単に誰々さんがこー書いているから正しいんだと何度も書かれても、疑問が晴れない。プロジェクトのレシピであるプロセスはいらないと書きながら、バリューストリームマップというリーン用語でプロセスが示されていたり、ケン・シュエイバーの「アジャイルソフトウェア開発スクラム」と比べて理解に苦しむところが多い。またSEIのCMMIとPMIのPMBOKがよほど嫌いなのか、書籍の序盤、中盤、終盤と３回も批判的なことを書いているのだが、はっきり言ってPMBOKを一度も読んだことがなさそうである。PMBOKは最初にすべての計画をしろとは書かれていないし、反復型にも適用できるプロジェクトライフサイクルモデルの例がPMBOKの冒頭にちゃんと示されているのだが、そのことを知らないようである。この本よりも引用されている大野 耐一「トヨタ生産方式」、ピーター・Ｍ・センゲ「最強組織の法則」「学習する組織 ５つの能力」をオススメします。

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

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

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

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

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

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

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

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

これってアジャイルなの？でもプロセス改善に関する理解は促進されます。 （2004-02-04）
タイトルを見て手に取り、目次を読んで、びっくり。中心となっているものはSPI。序文の最初からSEIとかCMMとかの話が出てくる。XPとか、スクラムとかというキーワードは全くないです。訳者がなぜこのようなタイトルにしたのかその意図がよく分かりませんでした。（消費者の要求に答えることよりも、はやりのキーワードを載せて売ることが最優先なのかもしれません。）この本は、「プロセス改善導入の成功・失敗要因」がまとめられたものになっており、CMMなどに興味のある人向けの本だと思います。内容については、導入事例や教訓などが載っており、興味のある人には、十分役に立つものだと思います。このような日本語の本があまり出回っていないため、貴重な本だと思います。日本語訳については、CMMやプロセス改善というものに対してなじみのある人なら理解できるものになっていると思います。

RUPとアジャイルは好きですが （kaizenさん 2008-03-25）
RUPとアジャイルは、昔からやっている実際の仕事のやり方と似たことが書いてあります。 ですから、最新開発方法論を取り入れるという話しには違和感があります。 開発方法論を取り入れたいからRUPやアジャイルを勉強するのではありません。 昔からやっている実際の仕事のやり方で、ちょっと違う部分が書かれていると、その理由、背景、制約条件の違いを確認したいために読みます。 もし、同じ制約条件で、やり方が違うのだとしたらなぜだろう。 違う制約条件だとなぜ、そういうやり方をしていたのだろうと。 開発方法論は、その仕事をする人の技術、開発環境、開発期間などの制約条件と結びついているので、違う条件の場合に、取り入れるという発想が不思議かもしれません。 RUP中心なのはなじめますが、そこになぜ、CMMIを接ぎ木する必要があるかがわかりませんでした。RUP風のモデル自身も改善していけばよいのではないでしょうか。

最新手法の手軽な勉強には良いが本としての主張がない （ナレッジベーストビューさん 2006-05-03）
プロジェクトマネジメントの一般的な解説が本の前半で，最新手法（RUP，CMM，アジャイル開発）の紹介は後半である．最新手法の手軽な勉強には良いが，前半部分との一貫性は特にない．また，SW-CMMの解説が主で，「最新手法」のCMMIの解説があまりないのは残念．個々の説明はわかりやすいが，解説コラム集という印象であり，本としての主張は見えない．この手の「お手軽本」では，下手な主張はしないという割り切りかもしれない．

学習書として良くできている （2004-09-20）
書店で手にして購入しましたが、方法論、手法が網羅的に扱われていて学習するには大変良くできていると思います。たまたま、職場の同僚も持っており、同意見でした。私はソフトウエアのR&Dである研究的な作業に長年携わってきた為、手法や方法論などに詳しくないので、大変助かってます。最初から通して読むのもいいですが、手引きとしてのまとまりも大変使い勝手がいいと感じてます。同僚がたまたま著者の講演に参加したことがあるそうです。著者は国内外の大手メーカーで組織改革、プロジェクト管理など常に現場で活躍されて来た方です。私のような者には、プロジェクト管理、CMM、アジャイルなど、まず基本事項を知り、理解するという目的では、この書籍に大変満足しています。

ワカゾーかオヤヂにしか用のない羊頭狗肉本 （2004-09-16）
各種トレンドについて「お勉強」した内容をまとめた感想文付きレポートか、いわゆるコンサルタントの戯言集。抽象論と他人の例に終始しており、成功経験にせよ失敗経験にせよ、実際のプロジェクトを自身が「管理」し、それを終盤までやり遂げたリーダ経験が著者にあるとは、本書からは到底感じられない。とりあえず用語は覚えておかなければと焦るワカゾーか、覚えた言葉で説教したがる間接部門のオヤヂにしか有用ではないだろう（両者とも「プロジェクト管理」には無責任な存在であるのは共通しているが）。ましてや「経営者の視点」を云々する書籍ではない。

RUPを整理したい人には最適 （kueさん 2004-08-28）
「ソフトウェア開発の最新スタイル」ということですが、殆どのページがRUPの解説になっており、その関連情報として、CMM, Agile等が補足されている。このため、読者としてはRUPに主な関心がある人に限定される。また、製品版RUP(HTML形式の解説書)で見た題材をちょっと焼きなおして説明している、という印象を受けた。２章の「プロジェクトの分類」では、いつのまにか「プロジェクト・マネージャに求められるもの」という話にすり返えてしまい焦点がボケてしまっているのが残念。３章で取り上げている「価値体系」の視点と「組織による分類」を絡めて説明できれば興味深い内容になったと思う。ただ、訳本ではないので、とても分かりやすく説明してあるので、RUPに興味を持ち始めた人や、製品版RUPを持て余している人にお勧めできる。後者(私も含む)には、同じゼミを受けた友達が自主研究でまとめたレポートを読んでいる感覚で読めるので「あっ、そういう見方をすると良いのか」といった新たな発見に出会えます。このため、RUPを整理したい人には最適です。

内容は必見です。 （mark2000さん 2004-07-08）
仕事柄ＵＭＬを用いたシステム開発のコンサルティングをしています。思わず”そうそう”といいたくなる内容です。今までに会った人は負け組みに分類できる人が多かったと思います。これからＵＭＬを導入される方にとって、記法とは別の次元でためになります。

初心者にもわかりやすい （seiitiさん 2004-01-22）
オープンソースとしてのＥｃｌｉｐｓｅとそのプラグインとしてのＵＭＬモデリングツールの使い方をわかりやすく紹介してくれています。初心者の自分でも読みやすかったです。

かゆいところに手がとどく （伝衛門さん 2003-10-25）
数ある入門書で、エクリプスについてはひとわたりわかったけれども、さて、どう使う?という半歩抜きんでた読者向け。入門者にも配慮してあり、いちいち絵入りでプロセスが説明されているので、異様にわかりやすい。くどくどしい説明も一切なし。実際のソフトウェア開発に役立つプラグインがいくつも紹介されていて便利。まさにかゆいところに手がとどく。エクリプスを使いこなしたい人におすすめ。

プロダクトラインの実践書 （wpさん 2003-11-25）
最近注目を浴びている、プロダクトラインに関する本です。この本を読めば、プロダクトラインの基本的な考え方などの大枠を把握することができます。ただ、この本には具体的なプラクティスについてはほとんどかかれていません。まあ、各プラクティスはそれ1つで別の本になるようなものなのでしかたありません。それらの具体的なプラクティスの文献の情報などはあるので、別の本などを参照する必要があります。プロダクトラインについての基本的な考え方を知るには悪くない内容だと思います。ただ、訳はちょっとひどいです。明らかに内容を理解せずに訳していると思われるところも多いですし、コラムなどは機械翻訳なみです。英語がかなり苦手な人以外は、原書を読むか、あるいは、少なくとも原書を参照しながら読んだほうがいいでしょう。

じっくり取り組みたい本です （lemonerikaさん 2006-06-30）
アジャイルな開発の必要性、「エコシステム」という方法論の原則や価値観・考え方、XPやFDDIなどアジャイル開発方法論の各論の説明、そして「エコシステム」を実際に組織に適用するには、という内容です。 ボリューム的には、「エコシステム」の原則や価値観・考え方を述べた部分が多いです。半分ぐらいあった印象です。事例、有名人とのインタビューなど、多彩な書き方がしてあります。 アジャイルの各論の説明、アジャイルの歴史も充実していて、アジャイル開発方法論の勉強になります。方法論設計の考え方などもあり、方法論者には、読んでおいて損のない本であると思います。 明日からすぐ役立つか、はちょっと難しいかですが、示唆に富んだ奥深い本であった印象です。ボリュームもあり、内容の濃いので、じっくりと取り組みたい本です。 アジャイル方法論について、ある程度知識があってから読んだ方が良い本であると思います。

スクラムだけでなく、一般的な方法論に関する知識も深まります （lemonerikaさん 2005-08-25）
スクラムという方法論の、手順、プラクティス、有効性の説明、既存の方法論の問題とスクラムでの解決策、スクラムの導入方法、そしてスクラムを利用したプロジェクトの管理手法の紹介です。プロジェクト管理手法のボリュームが、他の方法論の本より、詳しく、具体的に書いてある印象です。最初にこの本を読んだ時は、よく理解できませんでした。が、アジャイルの入門書を読み、スクラムの概要を掴んでから読むと、理解できた部分が多かったです。スクラムに関する知識だけでなく、ウォーターフォール等、今までの方法論・プロジェクト管理手法の問題点等もしっかり分析してあり、知識が深まりました。スクラムの導入の如何によらず、方法論やプロジェクト管理に興味があれば、読んで損はない、印象です。個人的には、読みやすい本ではなかったですが、しっかり読むと「なるほどー！」と思う点が多々ありました。

反復型ソフトウェア開発のプロジェクトマネージメントに悩む方におすすめ （neu-neuさん 2004-01-04）
SCRUMは、ソフトウェア開発のアクティビティや成果物を定義しないものなので、UMLによるモデリングやテスト・ファーストなどの話は全くありません。（読み進めるのにオブジェクト指向の知識は特に必要ありません）逆にプロジェクトマネジメントのスコープ管理、リスク管理、スケジュール管理のコンパクトな管理システムとプラクティスを示しており、反復型のソフトウェア開発のプロジェクトマネジメントを実践する上でとても参考になりました。この本を読む前に、背景にあるマネジメント哲学および基本プラクティスとして、本書が参考文献にあげているセンゲの"The Fifth Discipline"のラーニング・オーガニゼーション（学習する組織）を理解しておくとよいと思います。残念ながら和訳は絶版ですが、姉妹書籍の"The Fifth Discipline Fieldbook"の和訳が"フィールドブック 学習する組織「5つの能力」"日本経済新聞社 ISBN 453231075Xが入手可能です。

理論的労作 （エパメイノンダスさん 2005-09-29）
適応型開発の手法について説明している本ではなく、適応型開発の理論的基礎付けを行っている本。その思想やコンセプトを理解するための本。なので実用的な内容を期待する人にとっては失望させるでしょう。疑問に思ったことは一つ。書かれた時期がそうだからかもしれないが、理論的裏づけのために複雑系の考えを借りた記述となっていること。多分複雑系というタームを用いなくても説得的な論を展開することができたのでは？と思った。「複雑系」が一時期ブームになり、いろんな人が何でもかんでも「複雑系」という言葉を使いまくっていたので、ある種胡散臭さを感じさせるかなと。米国『Software Development Magazine』誌「第11回JOLT Award」受賞作。

会社に一冊あると管理者が楽 （柏崎健一さん 2009-03-27）
管理者は専門的な本を読んで、ユーザーの人はこれを軽く読んでもらうと概要が掴みやすい。 会社に一冊あると管理者は楽だと思います。（私、元管理者です）

Noteって使いこなしてますか？ （多ぁ望＠新習慣クリエイターさん 2008-08-27）
社内では入社以来ずっとNotesを使ってきました．最近，ビジネス関連のノウハウ書を読み，時間の使い方や習慣の見直し等のアドバイスがいろいろと書かれてます．その中で，必ず出てくるのがＩＴツールを使いこなそうというもの．ＰＣも当然ですが，特にこのNoteに関してはグループ・ウェアという位置づけでありより高度な活用ができるはず．とうわさでは知っていても，実際に自分が使ってきた機能はメールと会議通知くらい．中には会議通知を使いこなせてないひとも多数． そんな状況を改善すべく，本書を活用してグループ・ウェアとしての価値を見いだそうとしています。NotesはGUIが非常にわかりずらく、このような解説書なくして、独自に機能を習得するのは困難です。 本書では３００ページにわたり、概要を説明してくれていますが、これでもまだビギナーズガイドレベル。奥の深いNotesですが、これを十分活用できているひとは少ないんじゃないでしょうか。まずはこのレベルを習得したいと思います。

すでに環境がある、利用者向けの本 （seastarさん 2005-02-15）
IBMからダウンロードした試用版を試すために購入しましたが全くダメこれから導入する場合は不向きな本ですDominoサーバーの内容はほとんど無いです内容はかなり簡単で初心者向きにかかれていますが、なんせインストールの手順がないし、パスワードを入力してくださいとか、あきらかに、すでにNotes環境がある場合を想定してある内容です。つまり、すでに環境が準備され、管理者のもとで使う人（利用者）が、自分の使いやすいように設定する為の本です

その名の通り、マネージメント入門には最適な本 （中堅組込屋さん 2003-07-09）
あなたがメーカに勤務しているソフトウェア技術者ならば、是非読むことをお薦めします。「ソフトウェアは人が作る」という点を重視した内容であり、人材の育成、組織の在り方、開発プロセスの重要性を知るための切っ掛けとして、大変良い内容の本だと思います。今後、プロジェクトのマネージメントを任される立場になりそうなソフトウェア技術者、特に製造業の組み込み系の技術者には、マネージメントを勉強するにあたっての入門編として最適な本だと思います。

是非入手をお奨めしたい作品 （もりつちさん 2009-03-27）
特集は「ソフトウェア開発で伸びる人、伸びない人」。 伸びる技術者と伸びない技術者の特徴がわかりやすく解説されていて参考になりました。伸びない人の特徴としては「手抜きをしたがる」「解決策をすぐに求める」「基礎知識の収集を怠る」「受身である」等。逆に伸びる人は「言語スキル」「目的指向」「抽象化能力」「論理的思考」「コミュニケーション能力」」に優れ、「日々の習慣」で左の能力を伸ばしているとのことでした。 他には「人間系の問題としての改善活動」が面白かったです。この記事はソフトウェア開発現場における人間系の重要性について触れた記事ですが、読んでいて「ナルホド」と思わず膝をたたきました。我々はソフトウェア開発における問題解決の手法として、新しいプロセスやツールに目を奪われがちです。しかし 「ほとんどの問題は根っこが人間系の問題」 「人間系の問題がクリアされれば、どんな開発手法でもソフトウェアは作れる」 という筆者の主張は頷けるものがありました。 その他アジャイルモデリング入門、CMM導入徹底ガイド、パターンに関する記事、コミュニティの活用等の記事が掲載されています。内容によってはやや古くなった記事もありますが、その大半が現在(2009年3月)読み返してみても十分に通用する内容です。 今ではやや入手困難になってしまったのが残念ではありますが、ソフトウェア開発に関する業務に携わっている方であれば、是非一読をお奨めしたい一品です。

ソフトウェア開発で伸びる人，伸びない人 （hiroblueさん 2003-06-23）
ソフトウェア開発の現場では、どんどん実力をつけて伸びていく人がいる一方で、何年たっても伸びない人もいます。という【特集１】だけでも価値あるんじゃないでしょうか。ソフトウェア開発って、機械がやるわけじゃなくて人間がやるんだってことと、誰がやるかで出来上がりに大きな違いがあるという、あたりまえのことを再認識します。ソフトウェア開発って人に依存するんだということを再認識するためにご一読を。その他の記事は、正直あまり関心ないので・・。

基本が学べます （lemonerikaさん 2003-12-17）
１／３が、システム開発の説明。どのような手順で、何を作りながら進めていくか、という話です。１／３が、ＣＯＣＯＭＯでの見積り、テストの統計的管理などの話題、残り１／３が、保守の現場でよく発生する問題、その原因、対策です。実例など、豊富にありますが、それでも、基本的（悪く言うと教科書的）な内容が、多かったような印象です。その分、システム開発・保守の基本が学べる本であると思います。参考文献も多くてＧＯＯＤです。

今時のソフトウェア開発の現場 （n_yoshimotoさん 2003-03-31）
第1部「ABCプロジェクト」で、大規模ソフトウェア開発のプロジェクトの開発の開発体制を組む段階、設計の段階、製作の段階、テストの段階で発生している問題点への現場の取り組みについて駆け足で網羅的に紹介されている。現場でそれぞれの立場で問題を抱えている人にとって、問題点の整理に役立つとおもわれる。たとえば、開発規模の見積もりではCOCOMOを紹介している。また、品質を上げる方法としては、上流工程でのレビューの実施を紹介している。どちらも現場では既に日常的に実践されているかも知れない。しかし、この本で重要なのは大規模ソフトウェア開発の問題点とその改善案について全局面に渡って紹介していることである。第3部「現場の声」では、著者の周囲で実際に起こったソフトウェア開発の各局面での「問題点」、「原因」、「改善」についてそれぞれ紹介されている。これも現場での問題点整理には非常に役立つだろう。

最悪・・・ （bleis-tiftさん 2006-09-30）
載っているプログラムは不完全、しかも文法ミスが目立つ。 内容は目も当てられず、「本当に参考文献に挙げた本を読んだのか？」と思えるほど的外れな理解。 オブジェクト指向に関しては、一体いつの話してるんだ、という内容で、XP(というかペアプログラミング)の独自解釈にはあきれ果てるのみ。 サブタイトルにもなっているUMLだが、本質を見失って、図を装飾することのみに力を入れている。 取り上げる例題も分かりにくい上に「そこはそうじゃないだろう」と思うところも多々ある。 全てにおいて何一ついいところの無い、こんな本は初めてだ。おそらくこの著者はOOについて何一つ分かっていない。

プログラムとオブジェクト指向方法論の本 （lemonerikaさん 2004-03-13）
構造化分析／設計の概要、問題点が少々。メインは、オブジェクト指向の話題でした。Ｃ＋＋を用いたオブジェクト指向プログラミングの例、オブジェクト指向分析、設計を会議室予約を例に説明してあります。本の厚さからボリュームは少なめですが、ポイントはおさえられてる印象で、オブジェクト指向での開発の流れが、わかる本でした。

経験してないと、なんとも、の部分が結構ありました （lemonerikaさん 2003-10-22）
オブジェクト指向の基礎的な概念・考え方、世の中の誤解、導入・成功のポイントなどが、数ページ１トピックで書いてあります。トピックが沢山寄せ集まった本でした。基本的な概念、ＵＭＬ、開発方法論、ソフトウエアの再利用、ユースケースを用いた分析に関する内容が多かったです。一方、プログラミングやデザインパターンに関する話題は、少々、です。丁寧に書いてあるため、書いてあることは、わかりましたが、経験していないことは、どうもピンと来ないなぁ、という感じの本でした。ある程度の経験があって、読む本でしょうか？

オブジェクト技術を学びたいと考えている入門者や、オブジェクト技術全体を捉え直したいと （鈴木純一さん 2003-05-06）
オブジェクト技術全般が広くカバーされており、幅広いトピックを分かりやすく解説してくれる本。第1章は、オブジェクト技術の基礎と時間的経緯を丁寧に説明しており、この技術を学びたいと考えている入門者や技術全体を捉え直したいと考える読者に適した内容となっている。その他、特に2章のユースケースモデリングの章が優れていると感じた。ユースケースモデルの作り方と、そこからクラスを抽出する過程が明快に説明されている。また、4章の「繰り返し型開発プロセスの困難を克服する」は実際的な情報が多分に含まれており、6章の「ドメイン工学とは何か」はこの話題に関する優れた概要を提供してくれる。

基礎はばっちり （smc_netさん 2003-04-24）
今までオブジェクト指向を暗澹と眺めてきましたが、そろそろ本気で身に付けないとまずいと思い手に取りました。UML関連の本はいくつか読んできましたが、どれも私レベルではチンプンカンプンでしたが、この本はオブジェクト指向とはどういうものかという観点からスタートし、UMLのやさしい解説もしてくれています。そこそこすんなり読めるし、お勧めです。ただし、デザインパターンはまだ私には少し理解しがたかったです。

ソフトウェア開発のための本かどうか （kaizenさん 2008-03-25）
ソフトウェア開発がうまくいくには、プロジェクト体制で行うのがよいか、 既存の組織のままで行うのがよいかは場合によると思われます。 プロジェクト体制でやった方がよいとしても、CMMのようなモデルを参照するのがよいか、モデルは参照しない方がよいかも場合によると思います。 その２つのハードルを越える制約条件は何かがより明確になっていると、 本書を誰が、どのような時に読むとよいかが解るかもしれません。 本当によいソフトウェアを開発したいのか、 ソフトウェア開発で金儲けをしたいのか、 組織の目標が何かで読み方も違うかもしれません。

ＣＭＭを実際に導入しようと考えている開発責任者向き （2005-06-24）
ＣＭＭの参考書籍となると抽象的な内容が多く、ある程度の理解はしても何から手を付けて良いか戸惑ってしまいます。本書はインドのソフトウェア企業で毎年上位３社に入るインフォシスでの管理について実例をあげて書かれており、現在作成中の開発計画書のテンプレートとして非常に参考になっています。ＣＭＭは理解できるけど、次にどうすれば良いか悩んでる開発責任者の方、ぜひ一読して下さい。

ソフトウエア開発のプロセス改善の実例を示した良書 （wonder1さん 2003-12-18）
ＣＭＭレベル５を取得している会社の実例が、ＰＭの観点で書かれています。中小企業に籍を置く小生は、レベルの違いに驚くばかりでした。例えば年間５００以上のプロジェクトをこなす会社なればこそ、実績のデータベース化も可能なのでしょう。年間１０にも満たないプロジェクトしか動かさない企業では、データベース化の金銭的余裕はないでしょうね・・・ＩＴ産業ののＰＭを志すものなら、組織を挙げてプロセスを改善する、その理想形を知る価値はあるでしょう。「入門」と表題にするには、ややレベルは高いかもしれません。

マネジメントは、あくまでも組織の経験則のうえに成り立つ物 （まる・ちさん 2003-12-04）
ＣＭＭ能力成熟度モデルCapability Matuarity Model自体については前著に詳しいようだが、本書でもその有効さは十分理解できる。全体は筆者の属するインドのソフトウェア開発会社Ｉｎｆｏｓｙｓ社での事例を引き合いにして語られるが、好例と悪例を対比させることで特徴が理解しやすい。ドキュメントコントロールに重きを置くＩＳＯに対して、経験に裏打ちされたＣＭＭの手法が、開発ステージ毎に、いかに効果的かと言うことが繰り返し述べられている。ここで重要なのは「なぜ自分のプロジェクトでは、このように上手く進まないのか」と言うことだろう。私のように本書に救いを求めに来た読者もいるかもしれない。本書で得られる答えは、有効な実績データが積み重なるまで、試行錯誤して自分たちのチームの力を見きわめ、見積もりの精度を上げられるような腰が据わった開発をすることだ、という事だろう。つまりマネジメントは、あくまでも組織の経験則のうえに成り立つ物で、早道はないと言うことである。無理な計画が神業のようなマネジメントで達成されるわけではない。妥当な計画を、逸脱を防いで完遂することがプロジェクトマネジメントなのだと教えてくれる。その積み重ねで自己修正していく手法がＣＭＭの骨子なのだと読めた。

ＶＤＭの参考書 （kaizenさん 2009-04-14）
ＶＤＭ，ＶＤＭ＋＋を利用するための書籍。 フェリカがＶＤＭで記述したことから有名になった。 フェリカの事例の資料とともに読むとよくわかるかもしれない。

英語のソースみつかりました （脳無駄さん 2005-06-12）
読み方が悪いのかもしれませんが、ツールの使い方はこの本の説明ではちょっと分かりにくいなと思いました。ツールに限らず、説明の足りない部分がいろいろあるような気がしました。翻訳者のひとりである荒木先生の「プログラム仕様記述論」のほうが、例も充実していて、私には分かりやすかったです。そちらも参考にしつつ、仕様を書いたりして勉強しています。両方とも読むのがいいでしょうね。

英語のソースコード （2004-10-27）
英語のソースコードは、ツールをインストールするとインストール先のexampleフォルダに入っています。

モデル化の良い入門書になります （2004-10-27）
VDM-SLの習得だけに読むのはもったいないです。モデルを構築する際の基本的な手順が紹介されていたりモデル化に当たって考えるべき事が所々にちりばめられていたりと勉強になる本だと思いました。日本語のソースコードがついてますが、英語のもちゃんと入っています。ツールをインストールするとインストール先のフォルダにあります。これだけはちょっと分かりにくいと思いましたが。

いいかげんな作りの本という印象 （脳無駄さん 2004-09-22）
付録のVDMTools Liteを使ってみるのを楽しみにしてました。CD-ROMには本の中で説明に使っているサンプルもはいっていますが、日本語化されていて、これはLiteでは使えないそうです。だったら、英語のファイルもいれておいてくれればいいんだけど、そうなっていません。自分で入力すればいいのでしょうが、本の中でできると書いてあることができないようになっているなんて、なんだか、いいかげんな作りの翻訳なんだなあという印象を受けました。訳文もぎこちなかったり、なんか違和感あります。装丁は立派だし、内容はとても重要な本なのに、残念です。

現場でソフトウェア開発改善は、こう行う！ （lemonerikaさん 2005-06-06）
アメリカのソフトウェア開発企業での、生産性や品質向上のための取り組みと、その成果をまとめたものです。どのような企業で、何が問題で、どう取り組み、その評価はどうだったか、という１０個の事例が載っています。テーマは、プロジェクトの進め方の工夫、リリースを判断するための新しい判断基準式の採用、プロジェクト支援室の設置と活性化、開発基準の策定と浸透、インスペクションによる開発プロセスの改善などです。プロジェクトを管理する立場、あるいは、もっと上の立場で、ソフトウェア開発を、どう改善していくか、という視点の論文が多かったようです。学問・学問した知識というより、実際の現場で、実際の問題にどう取り組んだか、であるためか、わかり良い内容でした。ここに書いてある知識がそのまま、仕事で使えるかは？？？です。状況も違いますし。しかし「現場でソフトウェア開発のプロセス改善は、このように行うのか！」という点が、よくわかりました。

中堅ＳＥの方は必読！ （tagachilさん 2004-03-21）
現在活躍中の中堅ＳＥをターゲットにした内容である。これから上級を目指す方には是非読むべき本といえる。また、自分の知識の再確認という意味でも役に立つ一冊である。ソフトウェア開発全般を幅広く解説しており、これからの動向も踏まえた内容になっている。読んで損はないと思われる。

「実践」の概要をつかみ、一歩踏み込むきっかけの本 （2003-08-25）
前作「図解でわかるソフトウェア開発のすべて」で書ききれなかったトピックの追加と、より詳しい設計、開発の記述がこの本の骨子なのでは、という印象を受ける。前作より一歩すすんだ詳しい内容になっているが、これを読んだからといって設計ができるようにはならない。書中に紹介されている参考文献へとつなぐきっかけを提供する意味では有益である。前作が気に入った人は読んで損はないと思う。

これからIT業界で仕事をする人に読んで欲しい （walkingdictionaryさん 2003-08-16）
是非、新人ITエンジニアに読んで欲しい本です。実務を経験すれば、ここに書かれていることは嫌でも実感すると思うのですが、事前にこの本を読んでおくと役に立つのではないでしょうか？実務経験者には当たり前のことでも、それが故に敢えて新人に教えようと思わなかったりするのではないかと思います。また、後半は、PMBOKやCMM、TOC、SWEBOKなど、実務経験者でも知らない人が多い、非常に重要な今後のIT業界の方向性が書かれており、システム開発担当者必須の内容です。

きわめて分かり易く実践的 （2003-01-05）
タイトルそのままに分かり易く、実践的な本と感じました。ソフトウェア開発の管理をしていますが、若いＳＥに読んでもらいたいなと思いました。プロジェクト体制面、コミュニケーション面、開発過程のなかでもテストや移行過程、あるいは顧客からＳＥへの期待などはまとめて書かれている例を見ませんので、一読の価値があると思います。また5章には最近の話題をまとめている点や他の推薦書などもあって参考になる面が多いと感じました。あえて難を言えば、オブジェクト指向での設計に触れていない点かと思いますが、その技術的な点は他書で補えばよく、全体的にはそれを補って余りあると思います。

いつもデスクに置いておきたい本 （2002-12-15）
『図解でわかるソフトウェア開発』というベストセラーがあったけど、その続編とのこと。今度は「実践編」ということで、執筆者の実体験からの教訓が、けっこうあちこちにちりばめられていて、「とつぜんシステム開発のプロジェクトリーダに任命されちゃったよ」というベンダー企業やユーザ企業のＳＥには、かなりお役立ちの本。

受かるためには最適 （kekoさん 2003-05-08）
「ソフトウェア開発技術者試験に合格する！」ということに徹しているのが良い。そして、試験問題の傾向の予測がずれていない。この本を書いた人たちの「試験勉強に対するセンス」の良さを感じる。

短期間で最低限のポイントを網羅する （2003-05-02）
この参考書のポイントは次の3点にあり、短期間で試験をなんとかクリアできる実力を養成するという目的の場合に適している。１、適度に過去問題をはさみながら解説しており、試験での得点力をつけながら、かつ解説ばかりに飽きずに学習が可能。２、言葉が平易でポイントが明確かつ、わかりやすい。３、サイズがやや大きめのため、文字の大きさやバランスにゆとりがある。より深い理解を求める場合は他書をあたるとよいが、試験合格を目指すのであれば本書を落ち着いて取り組むのが近道と思う。

飽きずにさらっと・・・でもやや足りない （matthewさん 2003-04-21）
これ１冊で午前対策、午後対策ともＯＫというのが、この本の売りのようだが、どちらの対策としてもやや中途半端という印象。また、複数の人が書いているため、わかりやすさにややばらつきがある（総じて、平易な記述ではある）。ただ、全分野にわたって、それぞれある程度ポイントを絞って書いてあり（逆に言うと、書いていないこともあるということだが）、説明と問題の量の配分も適切で、飽きずにさらっと学習できる。これ１冊では、午前、午後ともやや不安が残るので、これで学習するなら少なくとも問題集は必須であろう。

修整（テーらリング）の大切さ （kaizenさん 2008-03-25）
作業（プロセス）モデルにとって、修整（テーらリング）の大切さを例示している貴重な書籍の一つ。 モデルに振り回されている組織は、一度読んだ方がよいかもしれない。 モデルに書かれていることの根拠の制約条件と定量データを見ずに、信じる人がいるのは噴飯ものだと嘆いている人がいると聞いたことがあります。 異なる制約条件に無理矢理モデルに書かれていることを実行しようとする迷惑な人達もいると聞いたことがあります。真偽のほどはわかりません。 一つの事例として、書かれていない制約条件を推測しながら読むのもよいかもわかりません。

原著には本当にそう書いてあるの？ （2004-10-16）
タイトルに惹かれて読み始めました。が、次の文を目にして読むのを放棄しました。-■使用メモリをすべて開放あなたのプログラムがメモリを割り当ててるなら、必ずそれを割り当てないようにしておきましょう。-おいおい、原著は本当にそう書いてあるの？この本は、冒頭から理解できない箇所も多かったが、がんばってここまで読んできたのに。。。でも、これ以上、読めません。読むなら原著ですね。絶対！

これでは著者が可愛そう （2004-02-27）
パッケージだけを見て衝動買いしましたが、その文章には驚きました。編集者を省いたのか、文章に流れや説得力が無く、我慢して読み続けるとイライラしてきます。勿体無いです。

アウトソーシングをする前に （ysnakanoさん 2004-02-20）
企業内にいて、突然システムの担当者に任命されることがある。少しでもパソコンのことを知っているとシステムを全てわかっていると思われがちだがそうは簡単ではない。システムを発注しようにも敵も専門用語を駆使してあの手この手でくる。本書は、コンピュータシステムを開発する場合の手順が大まかに解説がされており、「へえーぇ」的に読むのもよし、コンピュータの歴史に触れるもよし、硬すぎずやわらかすぎず、入門書としては良い。気になる用語に行き当たったら、そのときには個別の専門書を見ればよいだろう。

この本で合格しました （2005-08-20）
私はこの本でソフ開に合格しました。後輩にも薦めたいので，改訂版が出るのを待つことにします。改訂される際は，中味はいいのですが文字の大きさや行間，デザインなどをもう少し改善していただけるともっとよくなると思います。

TSP提唱者の滋著 （kaizenさん 2009-07-06）
TSP提唱者が、自ら編集した書籍。 CMM,CMMIでは、見落としがちな事象を集めていったら、PSPとTSPにたどり着いたという。 ソフトウェア設計は人が命。 技術力があれば、PSPとTSPで技術を支えることができるだろう。 技術がない場合には、どうするかは、チームの力つまり相互作用で技術力もUpさせればいいのだろう。

訳が劣悪 （KNさん 2004-06-27）
期待して購入したが訳があまりに拙く，途中で読む気を無くした．全体に訳がこなれていないだけでなく，以下のように意味不明な文章が目立つ．34ページ「アーキテクトはメインフレームのオブジェクト指向でないコードの，以前とは別の方法による開発を推奨するかもしれない」256ページ「専門分野で華やかにする」同じページ「経営陣はしっかりとサポートし，常に激励し，モラルの低い期間も自由に抜け出させるようにした」監訳者の経歴を見ると非常に立派なのだが，もう少し内容に責任を持って欲しいと思う．

ＯＯ開発のプロジェクト管理の古典本（？） （fuuchan2さん 2004-06-10）
タイトルには”アジャイルプロジェクト管理”とりますが、内容は、原題の "Surving Ojbect-Oriented Projects" の示す通り、オブジェクト指向を開発技術のベースとしたプロジェクト事例から成功／失敗要因を導出し、その考察を記述をしたもので、邦題にわざわざ”アジャイル”と銘打った理由が判りませんでした。（監訳者あとがきに、それらしい理由は書いてありますが・・）序文の日付をみると1997年10月となっており、この事でも示されるとおり、記載内容の情報が少し古い様に感じられます。1997年時点で完了または進行中のプロジェクトからのヒントとトピックで本の内容が構成されており、もう一冊のシリース本である『アジャイルソフトウェア開発』のような具体的なプロセスの説明を期待して読んだので、期待外れの感がありました。『人月の神話著：フレデリック・Ｐ・ブルックス，Jr.』で代表されるプロジェクト管理の古典本に分類される本と考えて読むと良いと思います。

虎の巻がついてます （lemonerikaさん 2004-04-16）
アジャイルなプロジェクトを管理するためのポイントを説明した本です。失敗したプロジェクト、成功したプロジェクトの例、そこから教訓を引き出されるプロジェクトのポイント、プロジェクトの組織化（メンバの役割）、計画、見積等のポイント、インクリメンタルな開発方法の説明とポイント等です。全体的にプロジェクト管理の技法というより、プロジェクト（管理）を成功させるためのポイントの説明、という印象の本です。事例、教訓、そしてポイントも、オブジェクト指向を利用したプロジェクトが対象となってます。「アジャイルソフトウエア開発」等のアジャイル開発の内容を知ってから読んだ方がよいです。珍しく、付録が、かなり役に立ちそうな本です。「リスク削減のためには、何をするべきか」が端的に、わかりやすくまとまってます。もう一つ、付録として本書の内容を要約した（？）１ページ程の「プロジェクト管理虎の巻」がついてます。

コラムもお勧め （佐藤幸司さん 2003-08-31）
ソフトウェア業界一年目の私にとって非常に参考になった一冊。 複数人で行なわれるソフトウェア開発において効率的な方法とはどのような方法だろうか? 本書では，近年注目を集めている"Agile開発"や"反復型開発"について説明し，変化の速い現在のITビジネス界におけるソフトウェア開発法，開発プロセスの在り方について，読者に指針を与えようとしている． 内容は平易で，専門的な内容に偏っているところがなく，読みやすい．参考書籍についての紹介が豊富で，より専門的に学びたい場合は，それを参考により深い知識を身につけることが出来るであろうと思う． ソフトウェア開発を行なう際の入門書として有効に働いてくれる書籍であると感じる．

とても無難な本 （EEEさん 2005-01-23）
ソフトウェア開発について広く浅く解説しており、それなりの知識をもつものが読めば、有意である。内容は教科書的で小難しい解説が続くので、まったく知識を持っていない初心者が手を出しても、理解を助けてくれるものにはならないと思える。値段は手ごろ、眠れない夜のお供にどうぞ。

標準的 （うぶなネンネさん 2007-04-27）
Eclipse & CVS の組み合わせは、もはや開発の定番。 そういう意味でも、もっておきたい1冊だと思います。 ただ、基本的なことが多いので、ネットで調べれる環境の人には ものたりないかも？？

ＣＶＳの入門書としても辞書的にもつかえる一冊♪ （やーまんさん 2006-08-23）
いわゆる「開発」ってやつをひとりぽっちじゃあなくて 複数人でやるときにでてくることば。 Ｃ・Ｖ・Ｓ！ いや、たまーにＣＳＶと間違えちまいますね。 EclipseもしっかりサポートしちゃっているCVSは、 やっぱ通過点としても究極としても重要かもです。 入門者にもやさしいですし 辞書的な使い方もできるバランスがとれた良書です。

CVS本ではこれが一番よかった （エパメイノンダスさん 2005-05-12）
CVSに関する本で一番わかりやすく参考になった本です。とりわけ、ブランチの扱い、ブランチとトランクのマージについてはこの本で理解できました。他の本は、この本と違ってどちらかというとコマンドレベルでの操作手順に中心をおいた説明が大半だったからかもしれません。

ＣＶＳの理解に必要十分 （鈴木純一さん 2005-02-01）
オープンソース開発やチーム開発などで利用が必須のCVS。そのCVSを理解して使いこなすのに必要なことが網羅されている。入門書としても、リファレンスとしても有益。 --このテキストは、現在在庫切れの商品のレビューを参照しています。.

CVSについての本格的な本 （2003-05-16）
単なる入門書にとどまらず、具体例を挙げてCVSの使い方を解説｡これからCVSを導入するプロジェクトリーダーにお勧めです｡

訳がいまいち （lmmさん 2009-06-12）
他の方とは違う観点で。 内容は他の方の解説にもある通り文句なし。 ただ正直訳があまりよくなく、読んでいて疲れます。

”職人気質”を胸に刻もう （shomさん 2008-07-24）
”職人気質”を理念として提案し、業界の意識改革を求める書。 「ソフトウェア工学へのアンチテーゼ」、 「徒弟制度による、開発者育成の促進」を主なテーマとする。 管理者、ユーザに対しても、意識改革を求める点で、アプローチの正しさを感じる。 文章は、例えを踏まえつつ、軽快な調子ですすむ。 訳も良く、読みやすかった。 提案の性格上、明日からの実務に大きく反映できるものではないが、 近年の「アジャイル手法」への注目や、本書の評価の高さなど、 ”職人気質”は支持されるべくしてされつつある。 ただ、冗長な箇所が多く、内容がない節も度々見られる。 また、何度も読み返すような必要性に駆られず そういった意味で、評判に適う内容ではないように思う。

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

「中小規模」を職人という切り口で （よこはま　こうたろうさん 2007-04-07）
→個人のＰＭスキルを、経験してきたＰＪ規模で レベル分けすることがあります なぜなんでしょう？ →それは、「なんとなく」、「体験的に」 「大規模」と「中小規模」のＰＭは別物である ということを、数多くのＰＭの方々が認識しているからなんだろーなー と私は勝手に思っていました →この本は、その「なんとなく」、「体験的に」というモヤッとした部分を 「大規模」をソフトウェア工学 「中小規模」を職人 という切り口で、明確に、納得させてくれる本です →ただねぇ．．言ってることはいいんだけど 文章がダラダラ続いて読みにくいなぁ．． 斜め読みで十分かも．．

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

今となってはお勧めできない （かずさん 2006-04-22）
WebObjectsもバージョンがあがってAPIが変更になったりしているので、本書のサンプルコードそのままでは動作しない。マイナーなフレームワークなので本書の改訂も期待できない。さらに訳本にありがちな日本語の難解さが追い打ちをかけ、読むのが苦痛である。 数少ない日本語の解説書であるが、今となってはさすがにお勧めはできない。WebObjectsを始めるのであれば、最新の（英語しかないが）参考書を探した方がよい。

日本語の本の中では一番の出来 （2003-11-04）
取り上げているテーマはアップル有償セミナーのＩと同等レベル。一般的にありがちな”とりあえずプログラムを作ってみる”といったスタンスではなく、ＷｅｂＯｂｊｅｃｔｓの仕組みから解説している点が評価できる。サンプルも掲載されているが、初心者にはわかりづらいかもしれない。その点で初心者には本書以外にもう一冊”とりあえずプログラムを作ってみる”といったスタンスの本が必要になるかもしれない。初心者がはじめに手にする本としてはやや難しいが、ある程度のレベルに到達すると本書以外の日本語の本は読まなくなる。ＷｅｂＯｂｊｅｃｔｓの日本語図書を探している人にはお勧めしたい一冊。

改訂版がほしいところ （rgz-91さん 2002-10-28）
私はサーバサイドJavaにはある程度通じているものの、WebObjectsは5.1になってから勉強ã‚'始めたばかりので、いろいろ苦åŠ'ã-ています。とりわã'本書は4.5（+5.0）ã‚'ベースにã-て書かれているので、私のように5.xからWebObjectsにé-¢ã‚ã£ã¦ã„ã‚‹æ-¹ãŒèª­ã‚€å '合には、å°'なからずバージョンの違いで苦åŠ'されるã"とでã-ょう。APIでは、NSGregorianDateâ†'NSTimestamp、EOValidationâ†'NSValidationに変æ›'されている点と、本書の例題で使われているEventクラスが標æº-クラスになっているã"とに注意すべきです。とりわã'NSTimestampクラスのgregorianUnitsSinceTimestampメソッドではNSTimestampの引数の位置が後ろに変æ›'されています。API Referenceの例題もç›'されていないので、Appleにはレポートã-ておきまã-た。また、ã"れにé-¢é€£ã-てWebサイトからダウンロードできるサンãƒ-ルãƒ-ロジェクトについても、ほぼ半分ぐらいã-か使えないと思ってé-"違いないです。ほとã‚"どãƒ"ルド＆ランできないサンãƒ-ルなので、Javaファイルやwoファイルã‚'個別参ç...§ã§ãã‚‹ãã‚‰ã„です。さらに付ã'加えておくべき点は、データベース絡みのサンãƒ-ルのå '合、OpenBaseのバージョンもあがっているせいか、サンãƒ-ル付属のeomodeldファイルも再構築するå¿...要があるå '合が多いã"とです。私はほぼすべてのデータベースやデータã‚'カスタマイズã-ながら勉強ã‚'進めまã-た。ã"うã-た点ã‚'踏まえた上であえてï¼"つ星評価ã‚'与えたのは、不幸にも現状では本書ほど実ç"¨ãƒ¬ãƒ™ãƒ«ã§å...¨ä½"的によくまとまってã!„ã!!‚‹ã¨ã„えるå'Œæ›¸ãŒå­˜åœ¨ã-ていないからです。その意å'³ã§ã¯ã€ã"れからWebObjectsの勉強ã‚'始めようというのであれば、付属のマニュアルと「WebObjectsワークãƒ-ック」で基礎ã‚'身に付ã'、ある程度デバックできるようになってから本書ã‚'利ç"¨ã-たæ-¹ãŒã‚ˆã„かも知れませã‚"。なお、æ'‹æ›¸ã§ã¯Developer's Guideが誤記はå°'なくアッãƒ-デートなのでお勧めなのに対ã-、Professional WebObjectsはå...¥é-€ãƒ¬ãƒ™ãƒ«ã§ã™ãŒãƒã‚°ãŒå¤šã„のでデバックできるまで使うべきではないと思います。

もうひとこえ欲しかった （2002-04-28）
たしかにWebObjectsの日本語書籍は少ないが，この本は訳が直訳すぎて逆にわかりにくくなっているので，英語に自信がある人は原本のほうがいいかも．初心者が買うにはあまりオススメできません．この本だけで，WebObjectsをマスターするのは難しいです．しかし，この本の内容がつかめるようになれば，あなたも立派なWebObjects使いになれると思います．

実践的な記述が多く、参考になった。 （seiitiさん 2002-04-09）
実際に、業務にこのソフトを使うにあたっての実践的な記述が多く参考になります。

内容の豊富さにびっくりしました （稲尾光男さん 2003-06-23）
ノーツの技術者ですが、最近Javaの勉強も始めないといけなくなり、良い本を探してましたが、この本はノーツだけでなくJavaのことがぎっしりかかれていてびっくり。ノーツ関係の本でここまでJavaのことが書かれている本は外国の本でも見たことがないので、かなり良い内容でした。ほんとうにユニークでノーツとJavaをいっしょに勉強する人にはもってこいの書籍ではないでしょうか。

Javaサーバーブレット初心者におすすめ （アリスさん 2003-03-03）
Java初心者におすすめです。タイトルからは少し構えてしまう重さがありますが（値段も重い！）コードが他の書籍には見られない程細かく、詳しく、解り易く丁寧に記述してあります。なのに初心者レベルの内容ではなく上はEJBまでの内容となっており非常に価値のある一冊です。お薦めです。

ノーツとJAVAが詳しくまとまってます。 （安岡直治さん 2002-08-16）
ノーツをずっとやってきた人にとっては、目からウロコのような内容な本ではないでしょうか？とにかくノーツからJAVAを使う時の技術が詳しくまとまってます。それだけではなく設計やプログラムの作り方も分かります。価格が高い本だと思いますが、ノーツを仕事に使っている方は、１冊持っていることをお勧めしたいと思いました。

じっくり読みたくなる内容 （そよ風さん 2002-01-14）
前からずっと気になっていた、WebSphereとノーツの関連技術が説明されている内容です。難しい専門的な説明ではなく、出来るだけわかりやすく書かれています。ボリュームがすごくあるので、じっくり読みたくなります。非常にユニークな内容ですし、あまり類書が無いので、ぜひ一度読んで見ることをおすすめしたいです。

プロジェクト管理技術のカタログ集　－プロマネ向け－ （nomiさん 2002-08-07）
まずはじめに謝らなã'ればならないã"とがある。　私はã"の本のæ"¹å®šï¼'版ã‚'愛ç"¨ã-ていたのだが、いつのまにか（正ã-くは2001/9/26に）第５版が出版されていた。æ"¹å®šï¼'版の発行が1994/10であるから、7å¹'のé-"に3,4,5版と出版されているã"とになる。è...野孝雄の精勤ぶりは脱帽すべきものであろう。　「ソフトウェアé-‹ç™ºã®ãƒžãƒãƒ¼ã‚¸ãƒ¡ãƒ³ãƒˆã€ã§å-り上ã'る中心はãƒ-ロジェクトマネジメントの技法である。業務とã-てどのような作業ã‚'ã-なã'ればいã'ないか、また、どのようなステッãƒ-ã‚'踏むべきかについては例えば「システムé-‹ç™ºã®ä½"系」（æ-¥æœ¬ãƒ¦ãƒ‹ã‚·ã‚¹æƒ...報技è¡"ç "究会編、東京電機大学出版局）のæ-¹ãŒè©³ã-いが、作業の中でå...·ä½"的にどのような技法ã‚'å-るべきかはã"の本がよくまとめている。　WBSといったISO 10006(ãƒ-ロジェクトマネジメントにé-¢ã™ã‚‹æ¨™æº-、PMBOKという名前のæ-¹ãŒæœ‰åã‹ã‚‚ã-れない。2002å¹'上期の話題の一つだろう。)に絡ã‚"だ話もæ˜"からå-り上ã'られている。　また、付録にある「ソフトウェアé-‹ç™ºãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã®è¨˜è¿°é ...目」や「å"è³ªç®¡ç†ã®ãŸã‚ã®ãƒã‚§ãƒƒã‚¯ãƒªã‚¹ãƒˆã€ã‚‚雛型とã-てよくできている。ã"のままでも使えるが、できればã"れに自分で培ったノウハウã‚'加えて使っていきたいものである。　以前の版にはあったå¤-注管理の詳ç'°ã¯ã€Œå®Ÿå‹™è€...のためのソフトウェアå¤-注管理」（コンãƒ"ュータエージ社）、に移ってã-まったらã-い。また、人材育成もã"の版にはない。CMMといったãƒ-ロセスæ"¹å-„についてはå-り上ã'ていない。　そういったã"と重ねて考えてみるとã"の本のねらいは、あくまでも、ï¼'回のシステムé-‹ç™ºã‚'い!ã!‹ã«ã‚„り遂ã'るかであって、組ç¹"とã-ての継続的æ"¹å-„についてはå-り上ã'ない、というã"とだろうか。そういえばTQCといった話題もå-り上ã'ていない。　ãƒ-ロジェクトマネージャの技量は会議での寝技で測るのではなく、管理技è¡"で測るという事がわかる本である。

保守開発のためのパターン （kakugさん 2005-08-27）
僕はいわゆるサンデープログラマーで「1ヶ月ぶりにコードに向き合ったら内容を把握するので1日つぶれてしまった」なんてことがしばしば。アプリケーションを構成する要素を小さな部品に分解してあると理解しやすいわけですが、それぞれの部品をまとめ上げるルールがないと、今度は部品間の関係を把握するのが困難になるわけで。GoF本が再利用のためなら、POSA本は保守開発のための良き指針なのではないかと思っています。個人的には読みにくいと感じなかったので、星5つ。

内容は重要だが読みづらい （myosimuraさん 2004-03-30）
私は、この本を用いて会社で輪講会を行っているが、この本はよみづらく、正直いって少々閉口することがある。理由は２つあり、そもそも原書の原文がぶっきらぼうであり、「必要だったら参考文献を読め」といった態度でかかれている。さらに訳文がこなれておらず、誤訳らしき箇所も何箇所かみうけられる。これは再刊されていても修正されていない。この本と同等の内容の本がないため、勉強のため読んでいるが、デザインパターンに限っていえば、もっと分かりやすい本もでているのでそちらを読んだ方がよい。

アーキテクチャパターンを学ぶのに優れた一冊 （鈴木純一さん 2002-11-30）
本書は粒度の大きなアーキテクチャパターンから、より粒度の小さなパターンも説明していますが、最も意義のあると思うのはアーキテクチャパターンを説明している箇所です。説明は非常に丁寧で、具体例も適切だと思います。内容も実践的で役に立つものが多く、特にPipe & Filter、Broker、PAC（Presentation-Abstraction-Control）などはぜひ押さえておきたいところ。また、ソフトウェアパターンをある程度学習した読者には、筆者らの言う「パターン体系」がどんなものかを理解するのも重要だと思います。

UMLやjavaに対応した改訂が望まれます （neu-neuさん 2001-08-06）
既に米国ではアーキテクチャパターンのバイブル的な存在であるので翻訳されたことは喜ばしいことですが、せっかく原書の発刊から４年も後の２０００年末に発刊されたのですからダイアグラムはOMTではなくUMLで、サンプルはC++だけではなくjavaも欲しかったです。

買ってよかったです （あキさん 2006-12-21）
よくあるのが、「こうあるべき論」が論じられているものの、具体性が無く、結局どうすればいいのかわからないような本が多いのだが、この本は具体的なアドバイスが書かれている。具体的に「何を」「どうすべきか」がアドバイスされており、買ってよかったと感じている。

奥付が語る、本書のすばらしさ （まる・ちさん 2003-08-31）
技術開発というのは担当者の技量に品質が左右される場合が多い。優秀な開発者の多くは、ドキュメント作成や全体進行にとらわれず、マイペースで進めて立派な成果を出す事がある。しかし会社の業務や規模が大きな開発は一人ではできない。そう言うプロジェクトでは、学校と同じでいろいろな個性の能力を持った人間が一つの目的を持って、スケジュールにあわせて成果を出さなくてはならない。ではそう言うプロジェクトをどう管理するか。ビジネススクールで教わるようなソフィスティケートされた方法や、グループウェアのプロジェクト管理ソフトを使った自己管理中心のインテリジェントな方法では、現実には不十分もしくは不能な場合が多い。最終的には人間の管理なのであって、そこは結構泥臭いちだ。本書では多年の経験に裏打ちされた、実践的な方法が記載されている。特に突飛な方法ではなく、ごく当たり前のことでもある。いわゆる「ABC」（当たり前のことを、バカみたいに、きちんとやる）に近いものだ。読んでいると自分の中での迷いが消えていく気がする。思わず頷いてしまう記述も多い。管理者だけでなく開発当事者にも読んで貰いたい内容だ。なお、本書を選ぶにあたっての決めては奥付だった。３年前の本でありながら、初版で５刷も重ねているなんて、きっと素晴らしい本に違いない。そう思ったわけだ。実際に全国のぐったりした管理者は本書を読むことで、束の間、癒されたことと思う。しかし、二十歳を過ぎたマイペースな開発者達を、改めて躾けるように「開発の基本動作としてのスケジュール管理を身につけさせる」というのが、これまた大変なのではあるが・・・。

毒の面はいろいろあるかも （kaizenさん 2009-01-15）
P318は、SLCP-JCF98は「１９９５年にISOで定められたソフトウェアライフサイクルプロセス規格であるISO/IEC12207が1996年にJIS化されたので、国際標準に適合させ国際取引にも対応できるように、１９９８年に改訂された。」とあるが、国際規格の修整を記述していない不完全な文献です。 P315には、「ISO 9000-3は廃棄される運びとなる予定です。」と書かれているが、ISO/IEC 90003として改訂している。 国際規格の専門家のReviewを受けてから出せばよかったかもしれない。 「ユーザ企業」、「ベンダ企業」という用語があって驚いた。 どの企業も、ユーザとはその企業の顧客のことであって、自分がユーザであるわけがない。 どんなシステムもお客様のためのものであって、自分たちだけのためのものではない。 そこが、情報サービスを提供しているはずの企業の自覚のなさであろうか。 毒があるとすれば、そこなのかもしれない。 あるいは、カタカナ語が多く、日本語に直すと、どういう表現かを提示していないところも毒かもしれない。 一度、毒を味わうと、毒だと思わないところが、この毒の最大の特徴かもしれない。

最初の１冊としてはかなりいい！ （2003-08-25）
ソフトウェア開発の一連のプロセスと、最近注目の技術の大枠をつかむことができる。ＳＥ１年目で何もわかってないときに読み、ものすごく何かをつかんだような気がしたが、実際のプロジェクトに活かすには、書中に紹介されている参考文献レベルのものを読まなければできない。「あぁ、自分は今プロジェクトのこのフェーズにいるんだな。」と感じることはできる。大枠をつかみたい、最初のとっかかりを得たい人にはおすすめ。

新人教育に使いたいと思います （ballet@nekoさん 2002-09-12）
ソフトウエア会社の社員です。新人の教育に使いたいと思い、購入しました。自分たちの関わる仕事の全貌？的なものがわかるような本がないかなあと思って探しました。しかも一冊でその概要を閲覧できるようなもので比較的初心者でも読みきれるものをと思って購入しました。そういう目的では、なかなかよいと思いました。

薬にはなりませんが、毒にもなりません （yostosさん 2002-05-16）
伝統的な構造化手法からオブジェクト指向開発まで一通りつまんであります。こういった広い範囲を自分でまとめる努力を考えると安直にまとめてある本書のような本は有用です。ただし、一角の開発者が新人または開発現場に疎い管理職にひとしきりソフトウェア開発というものについてうんちくを語って聞かさなければならない立場に立たされるという状況か、そういう知ったかぶりの鼻をあかせてやろう程度にはやる気のある新人または開発現場に疎い管理職がソフトウェア開発というものを学ぶ・・・という状況においてです。これを読んだからといって一角の開発者になるために役立つという訳ではありません。

ソフトエンジニア志望者におすすめです （nexstarさん 2001-01-18）
プロジェクト管理手法から開発手法、品質管理まで、ソフト開発にまつわるすべてについて非常にわかりやすく説明してある「入門書」だと思います。各章ごとに参考文献が記載されていますので、それらの本と併せて読めば、書名の「～のすべて」の文字に偽りはないと思います。「入門書」という位置づけであれば「星４つ」です。

初心者向け （PDP11さん 2002-03-15）
初心者向け。今からノーツを利用しようとしている方が全体を理解するための内容として良い。この出版社は，初心者向けも多く出しており，構成が読みやすく考慮されている。ガイドなので，方針が示されているが例題はほとんど無い。

ソフトウェア構成管理 （2003-09-19）
ソフトウェア構成管理をPVCSを使用して分かり易く説明されている。多くの事例を元にソフトウェア構成管理におけるポイントを説明しているので、イメージがつきやすく読みやすい本である。

中級者以上用のマニュアル本が欲しいところ （くりばやしさん 2006-11-30）
希少ということで高額でした。が、中級者以上用のマニュアル本が欲しいところです。 巻頭でhttp://domino.webserve.ne.jp/webserve/notesqa.nsfを紹介しています。 いずれも、不満足でした。

ローカリゼーションの難しさ （2003-07-09）
ローカリゼーションと聞くと、リテラルローカリゼーションのことを思い浮かべがちですが、テクニカルローカリゼーションの重要性にも少し触れられていました。技術者だけでは思い浮かばないような項目もあり、興味深かったです。実際の翻訳ではツール上でGUIを表示しながらの翻訳だけでもまだまだ足りないのだということがよく分かりました。

プロジェクトマネージャーのための本 （2001-08-15）
仕事でちょっと読む機会があった本がこれ。 今回、特に参考にしたのが、「ソフトウェア開発ドキュメントの記述項目」のところだったんですが、 それ以外のところでは、大学のときに勉強したような内容なんかもあったりしてちょっと懐かしい感じもしました。プロジェクト管理に関する広範な内容が盛りこまれているので、プロジェクト管理に関わる方は、一度読むといろいろと参考になるかもしれません。

初級者のプロジェクトのお供に。 （ショウボウシさん 2000-12-03）
この本を読むのに一番適しているのは情報学部や工学部に在籍し、卒業研究でソフトウェア開発に取り組む学生だろう。内容としては学生がプロジェクトを進めていく上で必要になってくる報告書の書き方や、計画の立て方などのテクニカルなアドバイスが主であり、非常に読みやすくまた充実している。また最終章はソフトウェア開発がどのような流れによって進んで行くのかと言う構成になっており、知識の乏しい人でも苦無く読みきれる。ちなみにプロジェクトは構造化手法により遂行されている前提であり、オブジェクト指向手法による開発に関しては特に記述はしていない。しかし最終章以外は設計手法以前の問題に対する内容であるので、ほとんど気にすることも無いであろうと思われる。特にプロジェクト報告!書の作成手順に関しては、全く関係のない分野に応用しても"論文の書き方と構成"という内容で充分に通じ、良書と言えると思われる。

プロジェクトは性善説によるメンバーへの信頼 （うりゆりさん 2009-06-24）
ソフトウェア工学の第一人者である著者が、プロジェクトマネージメントに関する101の法則を まとめ上げ、しかも、ストーリーを織り交ぜた構成になっているので、堅苦しくなく楽しめながら読めます。 ストーリーは、主人公が架空の国モロビアへ拉致されて、6つ（結果的には18）の超大規模PJの マネージメントを任されるところから始まり、読み進んでいくと、現実ではありえない節々があるが、 それはストーリーを盛り上げる要素としての演出として捉えると先入観なく楽しめます。 著者が提唱するプロジェクト管理とは、次の4つの本質を踏まえることであり、チームメンバーの 性善説を前提としてる印象を受けました。 ・「適切な人材を雇用する」、 ・「その人材を適所にあてはめる」、 ・「人々の士気を保つ」、 ・「チームの結束を強め維持する」 プロジェクトは千差万別であり、全が本書のプロジェクトに当てはまるものではないが、 筆者が重要視している4つの本質は、成功プロジェクトのプロセスに必要なものだと思います。 ちなみに私は101の法則ではないですが、本書の中のセリフ 「バグはモジュールの真ん中にあるんじゃなくて、モジュールの端にあるんだ」 にすごく感動しました。

CMMIやPMBOKとは違う切り口です。 （樹さん 2008-12-12）
PM本を読むに当たり、私はCMMIやPMBOK、PSPなどをキーワードに書籍の選定を行い、読み進めてきました。しかし、本書ではCMM(CMMI)などのプロセスによる管理よりも、もっと大事な事があるんじゃないのかと問題定義するところから始まります。わかっちゃいるのですが現実は本当に難しいです。人を選ぶにあたり直感を信じろとあるのですが、実際、関係者にどうやって報告しましょうか？優秀な管理者ばかりが集まっている人材バンクなんてどこにあるんでしょうか？ 読み物としては面白いが、現実の既存の組織なりプロジェクトに対して、本書の観点を落とし込み、適用、実施する事はとても難しいと思います。 しかしながら、私が今まで学んだ切り口とは違う切り口の管理(マネージメント)にかんする書籍にであえてとてもよかったと思いますし、たくさんの人に読んで頂きたい書籍です。

買ってつんどくでした。 （kaizenさん 2008-07-09）
買ってつんどくでした。 書評を書こうと思って読んだら、予想以上に面白かった。最初の失業する人を、スパイが掠うという設定から度肝を抜かれました。 １０１の法則は読み飛ばしました。最後に幸せになる（ハッピイエンドな）ところがすごくよかったと思いました。 ソフトウェア開発者が幸せになるための一つの筋書きとして面白いと思います。 ここから教訓を削って出版してもらえると嬉しいかもしれません。 教訓はあくまでも読み取るもので、教えてもらうものではないかもしれないのではないでしょうか。

主人公と共に、彼の日記に記された言葉を味わう本 （よこはま　こうたろうさん 2007-12-10）
→主人公と共に悩み、主人公と共に喜び、 そして主人公と共に、彼の日記に記された言葉を味わう本 →小説として純粋に楽しめます！ 出てくるキャラクターが、いわゆる「立って」いて、飽きさせません！ 自分の思うがままに振舞う妖しく魅力的な女性、 どこかで名前の聞いたことのある若き成功者、 一度燃え尽きてしまった最強のプロジェクト管理者、 そして最後の最後まで悪役を演じる「どこにでもいる」権力者・・ →プロジェクトマネージャーという職業は 一般的に孤独と言われることがあります しかし、そうではないかもしれないと、考えを改めました だって、この本の主人公は、数々の困難を、 この個性豊かな人達と乗り切っていくのです 私にだって出来ないはずはないと．． →私が所属したプロジェクトにも この本に出てくる「マエストロ」みたいな 「プロジェクトの語り部」がいました このような人の価値を、なかなか会社は認めてくれないのですが 人間的な暖かいコミュニケーションが減った現在のプロジェクトには 貴重な、そして必要なメンバーであると 改めて思いました

ソフト開発の実証実験物語 （夢追さん 2007-05-21）
一つのソフトを違った条件で、 三つ開発するという夢のような実証実験の物語です。 内容はプロジェクト総管理者の目線で話が進みます、 かなり飛んでいるので実話では無いと思うのですが、 的を得ている内容なのでソフトウェア管理者にはお勧めです。 ただ残念なのが開発するソフトは、 既存のソフトを真似して開発するので、 要求や仕様に関することは何もありません。 実際のプロジェクトに完全にマッチしません。 それに対するフォローが少しでもあればと思いました。

共通フレーム９４，共通フレーム２００７の中間地点 （kaizenさん 2008-05-04）
共通フレーム９４，共通フレーム２００７という３つの共通フレームの中間地点に相当する。 国際規格適合の中身が書かれていないこと、ウォータフォール（落水）モデルに依存した記述が多いこと、特定の企業文化に依存した内容が多いこと、供給者側の視点が多いことなど、偏りが大きい。 ハードウェアの制約についての前提条件が書かれていないなど、共通フレーム９４，２００７とも共通する不具合を持っている可能性があるかもしれない。

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

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

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

ソースコード行数の算出規則 （kaizenさん 2008-07-08）
付録Aのソースコード行数の算出規則は、大変興味を持ちました。 合理的な規則がいろいろ書かれていて参考になりました。 プログラミング言語ごとに、行算出の道具が用意されていると嬉しいかもしれません。 特に、複雑度に応じて、重み付けをするような道具が嬉しいです。 定量化手法であれば、自動測定が基本だと思うのは間違っているでしょうか？

買ったけど読んでない。 （2002-10-19）
辞書にもならない。この著者の本ではもっと分かりやすく実践的なものがあります。

現場の長 （kaizenさん 2008-03-21）
プレイングリーダを現場の長と訳せば、本書もすばらしい内容であることが解る。 人物金を、ある期間で区切って清算しようとする経済的な要請に応えるには、 「プロジェクトマネージメント」というものが必要らしい。 しかし、現場の指導者たるもの、先を見越した布石をうつためには、 短期的な目標だけに左右されていてはまずいだろう。 そういう視点があちこちに記載されていると思う。

お題目プロジェクトリーダ入門 （とりさんさん 2002-04-01）
「プロジェクト」という言葉は本当にはやっているらしく、「プロジェクトマネジメント」なんて題したセミナーはたいていいっぱいになる。そこではつまらぬ一般論が語られていたり、あるいは Microsoft Project というソフトウェアの操作説明が為されたり、さらにあるいは各種チャート図の作り方／使い方が説明されている。そう、たいていは下らぬお題目が繰り返されることが多い。もちろんプロジェクトマネジメントに関する本も数多く出ている。状況はセミナーを巡る状況とほぼ同じ。プロジェクトマネジメントの「ツール」として利用することのできる本などほとんどない。本書も同類。せめてもの重み付けにと漢語表現を使ってみたりしているが、それも「面白さ」につながらず「嫌味」で終わっている。著者紹介の欄を見ると「旧奥州伊達藩平民」などと書かれており、本文から受ける印象もむべなるかなという感じはある。

ダイクストラ、ホーア論理との関係を本書で知りました。 （kaizenさん 2008-06-10）
E.W.Dijkstra構造化プログラミング N.Wirth段階的詳細化 H.Millsクリーンルーム, IEEE software, 1987, Cleanroom software engineering 塵や埃が入らないようにして半導体を製造するための部屋。 誤りが入らないようにして無欠陥のソフトウェアを開発する。 特徴は、 インクリメンタル開発プロセス ボックス構造化分析 関数等価性検証 統計的品質保証 また、ホーア論理によるプログラムの検証、ダイクストラ法によるプログラムの導出についての章がある。

わかりやすくGUI計測システムを作れます （2003-07-19）
これまでGUI(ｸﾞﾗﾌｨｶﾙﾕｰｻﾞｰｲﾝﾀｰﾌｪｰｽ)を用いた計測システムを作るのは素人には至難の技でしたが、この本の付属のCDを使えば素人でもシンボルマークを線でつなぐだけで計測システムを構築できます。そろそろ続編の登場を望みたいところです。

開発の全体を見渡せる本 （PDP11さん 2002-03-15）
ノーツデータベースでの処理を検討している方が最初に読む本。他の言語では開発経験の有る初心者向け。開発の環境と手法に関し，関数，式，スクリプトなどについて，その全体を概略的に記述している。例題も結構有るが，詳細に踏み込む内容ではない。初めて開発を担当する方が，ノーツでどのようなことが可能なのかを理解した上で，指針を決めることができる一冊。プログラムの詳細例題については少ないので別の本を薦める。

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

Technology, Toosl, Technician （kaizenさん 2009-04-02）
技術（開発および検証）、道具（環境）、技術者の３つの視点で整理している。 最初に、作業（プロセス）という視点からはじめて、技術から道具の視点に展開している。 SLCP(ISO/IEC 12207,15288)と、ISO 9000, IEEE1074,SSADM,データフロー設計という順に 粒度を並べているが、根拠が分かる文献があるとうれしいかもしれない。 また、Brando&Gray, Daly, Benjamin, Metzger, Boehmの工程定義は参考になる。 各種標準についても参照している。参考文献が、過去の標準の場合には、入手可能かどうか確認してみるとよいかもしれない。 全体を通して読むと、技術者の視点が少し弱いかもしれないことを感じた。 道具については、当時の時代を反映した記述になっている面と、道具の基本的な機能について言及している面があるかもしれない。現在使っている道具に置き換えて読むとよい。 参考文献は、基本的なものを押さえているので、入手可能なものはぜひ、全部読破されることをお勧めします。 参考文献のリストを作っておきました。２つに分割しています。

ここからどう出発するか （kaizenさん 2009-01-19）
多くの経験を読んで、自分はなぜそうしないか、なぜそうできていないかの理由を考えるとよいかもしれない。 その仕事固有の制約条件があったり、その分野固有の制約条件があってできないことがあるかもしれない。 それを洗い出すきっかけとしても、いいかもしれない。

実践を経た中級者以降の方に　お薦めです♪ （よこはま　こうたろうさん 2007-08-08）
→誤解してました．．すいません．． →「鉄則っていったって 著者が思いつくままの経験則を ただただ羅列してるだけなんじゃない〜？ だいたい２０１も列挙するなんて 『私は整理ができませんでした．．』って 自分の低い能力を単に さらけ出しているだけなんじゃない〜？」 って．． →違いました．．ごめんなさい．． →この本は、著者が、 ソフトウェア工学の実践者や研究者の論文を抜粋し、 そしてそれらを、幅広い知見と深い洞察によって ９つのカテゴリに分け、体系づけて提示したもの でした．． →驚きました．．と同時に、うれしいです．． →バランスが非常に良くとれています 他の著者であれば、３０を超えるカテゴリを選ぶだけで 書き手の思いが鼻につき 本全体のバランスが崩れてしまうことが多いのですが この本は２００という大台のカテゴリを選びながら 最後まで、きちんと整理された上 きっちりと遊びの部分も計算し、提示されています 驚きました．． →と同時に、ソフトウェアの世界で こんなに感銘を受ける本に出会えるなんて ．．本当にうれしい限りです！！ →初級者には、内容が少し高度だと思います 平易な文章で書いてあるので、 読むのに苦しみは感じないと思いますが 行間ににじみ出る「苦味や滋味」については 理解しづらいのではないかと思います 実践を経た中級者以降の方もしくは 中級者を育成する上級者の方に お薦めしたい１冊です♪

価値ある一冊だと思います。 （kumapoooooさん 2005-07-06）
101個の鉄則が、1ページあたり、1鉄則の割合で記述されています。各ページの構成は次のとおりです。まず鉄則が短い文で書いてあり、そのあとに理由、最後に引用元となった本や論文が記述されています。系統だった教育を受ける機会が無いソフトウェアエンジニアにとっては、手元に置いて、頻繁にめくって、実践すれば、ソフトウェア開発に伴う苦労を減らせるでしょう。経験が長いエンジニアにとっては、常識ばかりでしょうが、書いてある内容をどれくらい実践できているかを試すチェックリストにはなると思います。

再確認の本 （nyさん 2004-07-17）
一通りの知識を持ち、５年程度の実務経験を持っていればこの本に書かれていることはだいたい経験しているだろう。そういう意味では、再確認の本。しかし、プロジェクトにしても、ソフトウェア開発にしても要件定義にしても問題が起きるところはいつも大体同じ箇所であり、それはとりもなおさずこの本のテーマに上がっている部分である。そういう意味では、時々紐解いて同じ過ちを犯さないように用心するということには使えるかも知れない。

やっぱり、基本は大切 （lemonerikaさん 2004-02-11）
ソフトウエア工学の膨大な書籍から、そのエッセンスを抽出し、２０１の鉄則（～せよ！～するな！）にまとめたものです。１ページに１つの鉄則とその説明、参考文献からなってます。要求分析、設計、コーディング、テスト、管理などの各工程について、バランスよく出てきます。方法論とか開発対象とかに依存しないためか、一般論が多いです。９０年代前半～中盤の成果のためか、今となっては良くしられた内容も多いです。「これは！」というものは、ボチボチです。読みやすいし、ささっと読めて、日ごろの仕事のチェックになりました。やっぱり、基本は大切！ということでしょうか。

マネージャーはいかに在るべきか （天然素人さん 2004-03-12）
マイクロソフトの少し昔の開発風景が覗る数少ない本？開発者がいかにすばらしい製品を作り上げ、楽しむことができるのかを考えること、それがマネージャーの仕事である。本書を通してこのような考えが貫かれています。下手なプロジェクトマネジメント本のように、PMBOKばかり気にするより、こうした明確なポリシーを持って、プロジェクトのビジョンに従って考え、行動すればきっと今より楽しく、そしてうまくいく。そう実感できる内容です。

プロを目指すなら必読の一冊！ （2002-05-17）
スケジュール通りに進まないソフトウェア開発、なぜ遅れてしまうのか、どうしたら予定通りにリリースできるのか、こういった問題を解決する方法について、筆者の経験を交えながら記述されている。プロの開発者を目指すなら、ぜひ一読されたい名書である。

オーソドックスな日本の品質保証を紹介する本である。 （高橋寿太郎さん 2004-07-24）
著者は長らく日立に勤めていらっしゃたようで、日立での品質保証システムを紹介していると想像する。その品質保証システムは非常に質の高い、確固たるもので学ぶべき点は多い。内容は多少難しくアカデミックな面も多少あるが、既に実践されている内容なので、自分のソフトウェアプロジェクトに導入するにもハードルは決して高くないであろう。この本で一番特筆すべき点は、日本人による日本の品質保証システムを体系的に書いているところにある。アメリカのソフトウェアの品質保証システム（特にテスティング関連）は、多くの翻訳によって紹介されているが、日本のそれは多くはない。常に机の横に置いておき、なにか品質問題があった場合に参照するには最適な本と思われる。

プロジェクト管理に関してはまだまだ有益 （鈴木純一さん 2007-07-12）
今読み返すと、オブジェクト技術に関する内容については古さが目立ちますが、プロジェクト管理（とその失敗／失敗回避）という点ではまだまだ面白い話題を提供しています。スウェーデンの王様が命じた軍艦建造の逸話は、要件管理の重要さ、仕様変更とプロジェクト管理に関して面白い（が、手放しでは笑えない）事例。

職場に一冊！ （2002-04-11）
家庭の医学書ならぬ、システム部門の医学書。症状別に原因や処方箋を解説してくれています。決して読破するタイプの書籍ではありませんが行き詰まった時に良くお世話になります。著者が調査した膨大な数のプロジェクトでの計量で裏付けされているので説得力があります。「やっはりそうなのか」と思うことも多く、流し読みをしても面白いです。

ソフトウェアだけでなく多くの分野でのプロジェクト管理者に （hisashi3sasakiさん 2001-07-03）
まとまってソフトウェアの信頼性モデルについて解説しているのは本書だけだと思います。多くの書は、この問題について、一部分の概略ですませています。詳細に理解するには、本書しかないというのが実情ではないでしょうか。ただ、最近はCD-ROMなどで本で解説されたプログラムを実際に利用できるものもおおく発売されるようになってきています。本書は1994年に発行されたものなので、web普及するチョット前という感じで、実際にソフトを入手するようにはできていないのが残念です。私の場合には、ここで紹介されたソフトと似た機能を持つExcelプログラムを利用して、実際に業務で解析をしてみました。はじめは、本当に成長曲線になるか疑問をありましたが、調べてみると、かなり広い範囲で（i.e.ソフトウェアの構成だけでなく、ハードウェアの設計、しかもVerilog高位記述だけでなく、アナログ回路の設計でも）同じような結果を得ています。ということで、実はソフトウェアに限らず、多くの分野の方でも、プロジェクトの進捗を理解するうえでの基本的な概念なのではないかと思っております。すなわち、ソフトウェア開発、管理者はもとより、他の分野での設計を行う方にとっても、参考になるものと推薦したいです。

契約以前の問題と契約の問題の混在が問題ではないか （kaizenさん 2008-01-17）
ソフトウェア開発モデル契約を解説している貴重な資料。 ただし、契約以前の問題として、双方の理解が一致していないのに、 契約を取り交わしたりしていないかどうかが問題になります。 偽装請負という話題がありますが、そもそも委託であっても、請負であっても、 派遣にならざるを得ないのは、契約時点で契約すべき開発内容が決まっていないからではないでしょうか。 何を開発すべきかを考える契約も示してあるといいかもしれません。 ソフトウェアの場合には、設計書まで出来てしまえば、半分以上が済んでいて、 プログラムを組まなくても動いてしまうかもしれないからです。 設計書ができてから契約する家と同じような議論はうまくないかもしれません。 仕様変更ではなく、そもそも仕様がない状態から始める契約の話をもうすこし、厳密に議論できるとよいかもしれません。

日本電気における （kaizenさん 2009-04-01）
日本電気では、藤野喜一氏が在職されていたころから、SEIとの関係が深く、さまざまなソフトウェア工学の技法について検討されてきていました。 真野俊樹さんのご講演は、一度聞いただけですが、概念がよく整理されているように感じました。 本書を読む場合に、日本電気における過去の取り組みなどの背景をしっているか。 日本電気が製造しているものは何かを知っていないと、意味が理解できないことがあるかもしれません。 表層だけを見ていくと、抽象的にきれいに理解したつもりになってしまうかもしれません。 現実を見るときに参照するようにするとよいと思われます。

第２版がでているので、比較するとよいかも。 （kaizenさん 2009-01-29）
第２版では、付録Aのソースコード行数の算出規則は、大変興味を持ちました。 合理的な規則がいろいろ書かれていて参考になりました。 プログラミング言語ごとに、行算出の道具が用意されていると嬉しいかもしれません。 特に、複雑度に応じて、重み付けをするような道具が嬉しいです。 定量化手法であれば、自動測定が基本だと思うのは間違っているでしょうか？ 第１版と第２版を、比較すると、何が課題だったかがわかるかもしれません。

製造業では、Design Reviewを、長らく設計審査と呼んでいた。 （kaizenさん 2009-04-03）
製造業では、Design Reviewを、長らく設計審査と呼んでいた。 そのため、工場長などが真剣に取り組んでいたので、 よい設計だけを製造工程にまわすことにより、 製造現場の無駄な作業を減らしてきた実績がある。 「デザインレビュー」と言い出した途端に、質が落ち始めたような気がする。 ISO/IEC 912６は、ソフトウェアだけでなく、システムの品質特性の体系化にも役立つと思われます。

デザインレビューの指針のひとつとして活用できるのでは。 （osa_tomoさん 2007-10-09）
デザインレビューの基準について、各企業によってノウハウをまとめたりと独自のリストを作成したりと、実際の運用上絶対的なものはおそらくないのではないか。しかもソフト開発となると外注展開が大多数となり、外注のプロダクト品質をどのようにチェックするのか、はそれなりに苦労するところである。 本書の特徴として、プロジェクト計画書・構造仕様書・機能仕様所・詳細仕様書・テスト仕様書など各仕様書が備えるべき基本的要件を、ISO/IEC 9126の品質特性上の切り口をもちいてチェックリストの形で示していることが挙げられる。 本書中には、オブジェクト指向・デザインパタン等のソフトウェア技法に対応したデザインレビュー基準となるものは記載されていないため、物足りない感を持たれるかもしれないが、本書で指摘している項目については、”最低限”仕様書上にて押さえて置かねばいけないはずである。 本書の活用法の枠組みを各企業内にて工夫すれば、デザインレビューの品質を企業内で向上させることができるのではないだろうか。

「役に立つ」とあるが、果たして本当か？ （q-reviewerさん 2002-08-01）
デザイン・レビュウの優秀な解説書は残念ながらなかなか見あたらない。優秀なとは、現場で役に立つという意味だが、本書は大胆にも書名に「役に立つ」と宣言している。結論から言えば、残念ながら役に立たない。もちろん基礎的解説はあり、それなりに参考になることは確かであるが、現場実践となると頼りない。その証拠に、巻末にあるデザイン・レビュウ事例は、噴飯ものと言ってよい。社内では、悪いデザイン・レビュウ事例の教材として受講者にマズイ点を指摘させる材料に使っているほどだ。

第７巻です。 （kaizenさん 2008-05-05）
ソフトウェアの実行環境とは、主にOSのことだと思われます。 開発環境とは、主にコンパイラまたはインタプリタのことだと思われます。 この２つのソフトウェア群は、CとUNIX(LINUX)のように、組になって考えられてきました。 また、SmallTalkのように一体で考えられてきたものもあります。 この重要な概念に、どのように今後切り込んでいくかが課題かもしれません。 復刊COMで復刊しようという動きがあるようです。興味のある方はよろしくお願いします。

凡百の概説書より本書を （銀鼠さん 2003-06-07）
高度な概念を一貫した説明手法で、比喩を使用せず説明する姿勢はこの講座の「オペレーティングシステム」と同じです。コンピューター関連の仕事に長年携わっていると、暫定的理解で知ったかぶりで毎日を過ごすことが多いのですが、そういう頭に痛烈な刺激を与えてくれる良書です。どの章にもはっとするような記述があり、ばらばらの概念が一貫した視点により統合されていく体験は感動すら覚えます。ただし、出版されて１０年近く経過しており、分散オブジェクト技術や、カーネルのスリム化の延長線上にあるJAVAスレッド等には触れられておりません。時代の流れを取り入れていただくようお願いします。

むつかしい２つの課題 （kaizenさん 2008-07-09）
保守と再利用はソフトウェア開発における２つのむつかしい課題だと思っています。 保守：過去に作られて、動いているものを、どうやって変更するか。 再利用：過去に作ったものを、これから作るものにどうやって活かしていくか。 話題としては、広く紹介されているので、後は実践するのみである。 問題なのは、開発対象そのものがなくなってしまうようだと、再利用もへったくれもない。 過去のＯＳ、言語などをうまく他の開発対象に移行していけるような企画ができるかかもしれない。 過去を引きずらずに開発したいという要望と、どう折り合えばいいのだろう。

今富士通社員で何人が知っているでしょうか？ （kaizenさん 2008-01-03）
推薦のことばを菅野文友先生がかかれています。 内容もすばらしく、この活動を続けていれば、今頃世界のNo1ソフトウェア企業になっていたのではないかと思いました。 今、これらの活動はどうなっているのでしょうか。 実践!!IT屋のトヨタ生産方式 という本が富士通の子会社から出ていますが、関連性はあるのでしょうか。 よく、本が出た後に、現場を訪問すると、もうその活動は、ある理由で止めたというお話をお聞きすることがあります。 実際に現場で一緒に仕事をしてみると、よいところが残っていることがあります。 そういうところに光を当てる続編を期待します。

Windowsの発展 （kaizenさん 2009-02-05）
X WindowをはじめとするWindowsシステムの発展の経緯が記されている。 SRI, Xeroxでの成果の次に、Apple、X Windowシステム、MS Windowsにいたっている。 また、TEXの紹介があり、幅広い知見がえられる。

専門書ではなく現場の記録 （kaizenさん 2009-02-05）
本書は、専門書ではなく、現場の記録のひとつ。 人工（にんく）という人の管理だけで、原価計算をしようとしている現場の実態を浮き彫りにしている。 ソフトウェアの原価計算には、場所、建物、開発機材、ソフトウェア、検査機材など、 膨大な原価計算対象があるが、ほとんど触れられていない。 それが悲しいかな現場の実態なではないだろうか。 実際に使っている経理帳票類の用語がでている分、経理帳票がでてこない他のプロジェクト管理の本よりはましかもしれない。 まず、原価計算の本を先に読むことをお勧めしたい。

著者の無知さがよくわかります （2005-07-31）
私が読んだ専門書の中で最もレベルの低い本です。まず、主語と述語の関係がねじれている等、日本語として意味不明な文章が多いです。内容も、論理の飛躍が多すぎて理解不能です。説明部分も、経験や勘を頼りにしているので、実践で利用するのは困難です。著者の勉強不足も顕著です。プロジェクト管理で著名な文献が一切参考文献に入っていません。プロジェクト管理を勉強したいなら、まずはデマルコの本をお薦めします。

第１章と第３章は分かります （kaizenさん 2008-07-09）
第１章のプログラミングと第３章の言語はよくわかります。 第３章ではC,C++,LISPについて書かれています。 また、Prolog,Forth、SCHEMEの紹介があります。 すごく参考になる文献だと思います。 第２章はあまり得意分野ではなく、第４章はちんぷんかんぷんです。ごめんなさい。

２０年前、クロス開発を行うときに購入しました。 （kaizenさん 2009-04-21）
２０年前、クロスコンパイラを利用した開発を行う際に購入しました。 残念ながら、XASS-V,XGEN-V,XGDB-Vなどは購入できませんでした。 シグマプロジェクトの話題がコラムになっていて、時代を感じさせます。 現在では、GCC,GDBがあり、無償でこれらの開発が可能です。 ただし、ICEは、現在でも高価で、JTAGデバッガや、 ルネサスのE8などの安価なエミュレータの利用で開発しています。 本書は、隔世の感がありますが、基礎技術は今も同じで、参考になります。

ソフトウェアでは他の分野であたりまえのことができていない。 （kaizenさん 2008-08-16）
ソフトウェアでは他の分野であたりまえのことができていないことにしばしば遭遇します。 原価計算は、どの分野でもあたりまえのようにやっていることです。 ソフトウェア開発は、研究試作と同様な、原価外だというような驕った意識を持った人たちもいます。 まったく逆に、量産試作のような難しい問題を解こうとしているのに、単純労働のような労務管理をしている人たちもいます。 まったく逆の管理方法が混在し、技術者は右往左往することになります。 ソフトウェアの管理をする人たちが、品質会計のような考え方を身に着けて、管理のための管理ではなく、よい製品を作ること、効率よく作ること、能率よく作ることを心がけるようになるとよいかもしれません。

日本電気のソフトウェア品質を支えた一人 （kaizenさん 2008-05-04）
日本電気のソフトウェア品質を支えた一人として、またCMM（成熟度モデル）を日本に紹介した一人として、ソフトウェアの標準化、ソフトウェア技術者教育などにもその後従事された。 その活動の原点となる事項が記録されている。