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

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

ウォータフォールじゃない場合はどうするの？ （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は興味がある、という方は一度読んでもよいのではないかと思います。 「ソフトウェア開発の課題１ソフトウェア開発の持つべき文化」と内容が若干重複するところがあるかもしれません（私は重複しているなと感じました）。

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

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

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

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

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

盛りだくさんの情報 （kaizenさん 2007-12-25）
ソフトウェア品質に関連する技術が盛りだくさんの紹介。 一つ一つだけでも、１冊の本になるので、体系的な学習の出発点としてはよい。 一つ一つの技術を評価して、採点していくと、自分に本当に必要な技術につきあたるかもしれない。 ライフサイクルプロセスといいながら、ウォータフォールしか想定していないような出だしはなんとかならないものか。 V字というと、一方向でしか考えれないようだと、品質が保証できるかどうかが怪しいかもしれない。

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

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

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

ユースケース駆動モデルと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そのものを もうちょっと突っ込んで詳しく解説してほしかった 続編を望む

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

ソフトウェア開発のエッセンス （progerさん 2008-02-06）
ソフトウェア開発はそれ自身とても楽しい仕事です。開発ですから何かを生み出すというのはもちろんなのですが、そこへ至るプロセス自体もまた自由度が高く、そのプロセス自体もまたとてもクリエイティブです。 本書では、そんな楽しい仕事を、より効率よく、また楽しい気持ちで取り組むためのエッセンスが散りばめられています。 「目的指向」「保守の重要性」「プロダクトに対する客観性」「言語能力の重用性」等など、非常に重要なポイントが、簡潔かる網羅的に記載されています。非常に簡潔にまとまっていて、大好きです。 タイトルがいまいちですね(-.-)。

元気がでる本 （なかさん 2007-09-19）
プログラマ職に就く１年生へ贈る１冊です。 この本を読んでいると、元気とやる気がでてきます。 そういう意味からいくと、熟年プログラマも、 やる気が無くなった時には読む価値ありです。 本も軽くて１日で読めるボリュームなので、 大変、重宝しています。

ソフトウェア開発者の格差社会 （¥$':?/さん 2007-05-27）
この本を読んで感じたこと。 ソフトウェア開発者の淘汰が始まり、 一部の優秀な技術者と単純作業者に分かれていくんだなぁと。 実際、私のプロジェクトは既にそうなっています。 柔軟性・拡張性・保守性・機動性のバランスを見極め、 シンプルでわかり易いデザインができる技術者・・・そうそういませんって。 レビュは重要ですが、わからないんじゃ意味がない。だから極一部でまわしてます。 この業界を、ヘンな精神論でややこしくしてきた人たち、 あまり人に期待するのはよしましょう。人は変われますが、それは あくまでも自分で変わろうとしている人だけです。 「伸びる素養があり、楽しめる人」だけが生き残る可能性があり、 極一部の優秀なＩＴ技術者の地位が見直されるのでしょう。 "わかりにく"くてすいません。。

ポイントやキーワードは、基本的なビジネス共通なものです （日曜日の朝さん 2007-05-19）
新井玲子著『ソフトウエア開発で伸びる人、伸びない人』（技評ＳＥ新書、平成18年3月5日） 第一部ソフトウェア開発で伸びる人、伸びない人 第二部ソフトウェア開発で幸せになれる人、なれない人 この本、「最新の技術よりも、大切なことがある」と表紙の帯コピーが表現しているように、ソフトウェア開発についてのノウハウが書かれている訳ではなく、ＳＥとしの基本的な行動スタイルを２つの角度から書いているものです。 文章自体、平易なので軽く読めるので、スゥ〜と読み終わるとい感じですね。でも、所々に出てくるポイントやキーワードは、基本的なビジネス共通なものですから、たまにページをめくって見て新鮮な気持ちになるのはどうでしょうか。 それと、「あとがき」にこんな文章が引用されて紹介されています。この本の根本思想というか、やっぱりこれもＳＥにとどまらず、ビジネス共通に通じるものとして紹介しているものと思います。 「まじめに努力して行くだけだ。これからは、単純に、正直に行動しよう。知らない事は、知らないと言おう。出来ない事は、出来ないと言おう。思わせ振りを捨てたならば、人生は、意外にも平坦なところらしい。磐の上に、小さい家を築こう。」(太宰治の『正義と微笑』より) これは、太宰治の『正義と微笑』「僕は、きょうから日記をつける。このごろの自分の一日一日が、なんだか、とても重大なもののような気がして来たからである。・・・・」で始まる日記形式の文章であり、最後の「十二月二十九日。金曜日。」のところを引用している。

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

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

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

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

組み込みソフトの基礎を学びたい方へ （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」であり，ソフトウェア工学のお作法を，単に技術としてではなく，文化ととらえている点が，本書と他のソフトウェア工学の本との大きな違いである．さらに，品質と，継続的な学習を重視している点が，とても良い．プロとしてソフトウェア開発に関わるすべての人，これからソフトウェアの道を歩もうとする人に，強くお勧めする．ソフトウェア開発技術者必読の一冊．

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

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

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

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

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

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

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

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

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

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

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

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

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

無駄の無い開発とは何か （2005-01-18）
リーン（無駄の無い）ソフトウェア開発というタイトルから推測して、ＣＭＭやＰＭＩなどに代表されるソフトウェア改善プロセスを想像される方も多いと思われる。しかし著者はこのようなプロセス改善の動きを「開発」と「製造」を混同した誤った認識の上に成り立つ開発手法であると述べ、それらの手法に批判的な立場から、現場の創造性を尊重するリーン開発手法を紹介している。著者が述べている「無駄の無い」開発とは、権限の多くを管理者から現場にシフトし、変化に対してより柔軟で機動力のある開発方法を意味する。決してストップウォッチを片手に作業者の後ろで四六時中監視するような管理者を賞賛するものではない。トヨタのカンバン方式からゼロックス、３Ｍに至るまで、さまざまな業界での取り組みをリーン型開発の具体例として取り上げており、ソフトウェア業界を問わず業務プロセスの改善に取り組まれている幅広い分野の方々にも興味を持って読んでもらえる一冊ではないだろうか。

説得力がない （2004-10-19）
ウォーターフォール形の開発と繰り返し型の開発を比べて、シーケンシャルVSアジャイルの論法を繰り広げても意味がない。キチンとアジャイルを理解しているのであれば、ウォーターフォールでもアジャイルプラクティスの適用は可能なのではないだろうか？七つのリーン原則も、全く持って「当たり前」の事であり、ソフトウェアエンジニアリングを理解してる者であれば、20世紀から実践している原則に過ぎない。これは、「仕様説明書と保証書」を見れば明らかである。また、「予測はするな」と述べているにも関わらず、損益のシュミレーションはしてみたりと、話に合理性、統一性も感じられない。損益のシュミレーションは、全てのプロジェクト活動の予測に成り立っていることを意図的に無視しているのか？自分の理論を正当化するために、あちらこちらに論理的な無理が生じている上、特に目新しい話もない。

オブジェクト指向の本質を体系的に記述 （桑原 高雄さん 2006-03-08）
和訳が出版されるまでは、原著「Agile Software Development: Principles, Patterns, and Practices 」を読んでいました。この本のすばらしい所は、オブジェクト指向の本質を設計原則で述べているところです。設計原則からリファクタリングやデザインパターンと体系的に説明しており、本格的に勉強したい人にとっては必読書であると思います。 追記 この本に記述されている設計品質指標を測定するツール「JDepend」もフリーソフトとしてワールドワイドで流通しております。

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

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

体系だてられた経験的ガイドラインか。 （seraphyさん 2004-07-08）
アジャイルとかかれていますが、いわゆるXP/アジャイルなプロセスの説明本ではありません。また、概念レベルの説明に終始する入門者向け教科書でもありません。オブジェクト指向プログラミングに従事する者が経験によって体得してゆくであろう、重要な項目が体系的に説明がなされています。実際に要件から（初心者が思いつくような）ファーストインプレッションの設計をみせ、それの問題点を説明しながら徐々に改善してゆく、という手法での説明が沢山あり良い感じです。OOP/OODの入門レベルのプログラマにはぜひ一読してほしい本だと思います。この本は分厚いため値段も高めになっていますが、大量に出回っているオブ脳系本を２冊買っても、この本の代わりにはなりません。ページ数によって内容が希釈されているわけではなく、どのページを開いていも経験に裏付けられた価値ある文章がかかれています。その意味で値段相応の価値はあると思います。

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

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

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

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

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

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

ソフトウェア開発で伸びる人，伸びない人 （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）
構造化分析／設計の概要、問題点が少々。メインは、オブジェクト指向の話題でした。Ｃ＋＋を用いたオブジェクト指向プログラミングの例、オブジェクト指向分析、設計を会議室予約を例に説明してあります。本の厚さからボリュームは少なめですが、ポイントはおさえられてる印象で、オブジェクト指向での開発の流れが、わかる本でした。