「ソフトウェア見積り―人月の暗黙知を解き明かす」 とその関連商品

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

本文はわずか300ページ足らずなのだが詳細な見積もり技法の本を何冊も読むよりも。現場に立つ開発マネージャーにとって（ただし、中小規模のプロジェクトの）、この本を読み込んだ方が役に立つ実践的な知識と考察が得られるように思う。
(赤戌/2006-11-16)

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

本書は、要求の導き出しから仕様化、要求の変更管理までを網羅している。
システム開発において、的確な要求を導き出すという永遠のテーマについて書かれた良書。
ＨｏｗＴｏ本と読み物としての二つの側面をもつ。
要求導き出しのテクニックなど、具体例をあげ解かり易く書かれているので、これから上流工程へ携わるビギナーの方にもお奨めできる。
また、訳本ではあるが、文章は平易で読みやすいのが大変良かった。（日本語訳、監修の方のご苦労が伺える仕上がりになっている）
本書では、要求の導き出しから仕様化の間に「要求のトリアージ」を行うことを推奨している。システム開発において、予算と納期、要求のバランスをとることは大変重要である。
この時点でボタンの掛け違いをすると、大抵の場合、納期遅延や予算超過などプロジェクトの失敗を招くことになる。
本書の第３章で取上げられている「要求のトリアージ」では、要求を選び出すための技術について触れられており、参考になった。 (ＫＩＴＴＹ/2007-01-08)

本書は、日経ＩＴプロフェッショナルに２００５年５月号から、２００６年３月号まで連載された、「本当に使える見積もり技術」を加筆修正して出版された本である。連載当時から興味深い内容であったので、今回の出版はよいことだと思う。著者は、ファンクションポイント法（ＦＰ法）の専門家である。理論的に仕事をしているＳＥにとって、見積だけが、「KKD（勘・経験・度胸）」法では、困ると思う。本書では、見積の準備、なぜ見積が重要か、その心得を説明した後、ソフトウェアメトリクスの話が出てくる。そのソフトウェアメトリクスを論じたうえで、ＦＰ法が出てくるので、なぜＦＰ法なのかという部分もわかりやすい。またＦＰ法の説明も端的でわかりやすく書かれている。このＦＰ法の部分がメインと思っていい。それから、係数モデルによる見積や、ＷＢＳによる見積が書かれている。実は、これらは、規模見積であり、そこから工数見積に展開する部分で悩む方も多いのではないか。この本では、規模見積から工数見積、期間見積、価格見積まで展開していく方法が説明されている。ここは、著者の見識であろう。しかし、なかなかこの部分の展開が書かれている文書が少ないので、貴重である。参考にするといいと思う。最後に見積書の作成が書かれているが、これはおまけかな。本書の本質は、ＦＰ法の使いこなし方と、規模見積からの工数見積、期間見積、価格見積への展開の２点が中心であり、その内容は、わかりやすく説明されている。見積を具体的に実践する方におすすめしたい。 (chukanshi/2006-10-05)

日立のＰＭＯに所属されており、また、日本ファンクションポイント・ユーザ会副会長でもある初田賢司さんが書かれた「ソフトウェアの見積り技術」の本。

プロジェクトの多くが、当初の「見積りミス」によるものであり、
その「見積りミス」の大半は、
　「見積り段階で前提条件を合意できておらず、
　　プロジェクトの実行段階でコントロールできなくなるケース」であり、
　結果として、気づいた時には、当初規模の２倍以上に膨れ上がることもある。

「こうしたリスクを回避するのは、
　ものづくりの計画に加え、
　マネジメントの計画を立てておく必要がある。

　スコープやコスト、スケジュールなどについてマネジメントのベースラインを決め、ベースラインとの乖離を把握する仕組みを作らなければならない。
　マネジメント計画は、見積りで大枠が決まる。
　だから、見積りでプロジェクトの成否の大半が決まる」


見積りにおいて、
「エンジニアリング」面と同等に「マネジメント」面と連携した見積りが大切であり、
その全体構造を明確に示しています。

ＦＰ法（ＩＦＰＵＧ法）とＰＭＢＯＫに、準拠しているのも、
思考のフレームワークとして理解しやすいと思います。 (papillon/2007-10-23)

売れているようなので、数ある見積り本の中からコレを選んだ。ファンクションポイント法はかなり詳しく書かれていて分かりやすかった。個人的には多くの見積もり手法の良し悪しを論じる時期は過ぎ、ファンクションポイント法を中心にいくつかの手法に集約されると思う。良書です。 (全力/2008-04-03)

ズバリ良書だと思います。
構成もしっかりしており、特にコラム欄に無駄な内容がなく充実しています。
著者の経験と実績にしっかり裏づけされており、理解しやすく納得度も高いです。

見積もりのメトリクスとして以下の５つを紹介しています。
　・Line of Code（ステップ数）
　・FP数
　・画面帳票数
　・ユースケースポイント数
　・ドキュメントページ数
これらをメリデメで比較しつつ、FP数が最も適切なメトリクスであると結論づけ、FP法の具体的な使用法に展開していきます。

いよいよFP数の割出そうとする際には、その精度は経験に依存するところを大としますが、ある程度フレームワーク化されているので教科書になるでしょう。

見積もり初期段階（基本設計前）でも、ユースケースポイント数でなく、推測を使えばFP数で見積もることができることがわかりました。
つまり、見積もり初期から一貫して同じメトリクス（FP数）を使用することで、見積もりのブレに対する分析・評価がしやすくなると述べられています。

付録のCD-ROMに、「見積もり支援ソフト」「見積もりリスク分析ソフト」の各試用版が収録されていますが、このソフトを使用しながら学習するようにはなっておりません。
(nobuakim/2008-04-01)

2000年までの6300件のデータをもとに、多くのグラフを用いて説明されており、非常に説得力があります。
概念的には、機能総量＝プロセス生産性×工数×開発時間で表すことができます。この関係からわかるように、工数と開発時間はトレードオフ関係にあり、開発時間を延ばせば工数が減ることになります。
従来の見積もりでは単に人月であり、開発時間を考慮していないため、正確に見積もれないことがわかります。（100人月：100人なら１ヶ月？１人なら100ヶ月？）
どんなに頑張っても（コスト・人を投入しても）これ以上早くは開発できないという最短開発期間が存在するというのも、目から鱗でした。無理ムリのスケジュールでの開発は、破綻することになります。

計測されたデータの分析結果が主になっているので、いざ実際に計測しようとすると、他の書籍などを調べる必要があるかとは思います。

5章と11章だけでも読む価値があるかと思います。 (tkcjun/2005-12-03)

ソフトウエア開発の現場では、今でもいろんな混乱がある。
■工期短縮のためには工数増が必要であるのも拘わらず、プロジェクト開始後に要件決定の遅れや納期の短縮要求をズルズルと受け入れてしまう。
■トップがその年に決めた目標(たとえば生産性向上５％)を達成するために、他の重要なメトリックスを悪化させてしまう。

この本の中では、ソフトウェア開発の分野では中核となるメトリックスは５つある（規模、工数、工期、品質、生産性）といい、６３００の実績データの分析、メトリックスの導入、注意事項について解説している。

全体を通して痛感するのは、何を測るか、それをどのようにフィードバックするか、こういうことを継続して考えていかないと５つのメトリックスを同時に改善していくことはできないということ。本書の中で引用されている、絶対温度で有名なケルビンの「計測できればコントロールできる」という言葉が強く印象に残ります。日本でも、ソフトウェア開発分野のプロセスエンジニアという職種が定着することが必要とも感じました。 (yu-ji/2006-09-13)

主にソフトウェア開発者に向けたプロジェクト管理のための１冊です。内容は多岐に渡り、一回で読んで全てを理解するのはなかなか難しいと思います。そこでお薦めなのは、自分の現在の状態、仕様検討段階であるのか、コーディング段階であるのか、リリース前であるのか、その段階に応じてその部分について書かれた箇所を読む方法です。前に読めば予備知識になり、後で読めば振り返りになると思います。また、著名な書物からの引用も効果的でなかなか楽しいものでした。
マイクロソフトで、とありますがマイクロソフトに特化したところはなく、一般的な手法として参考になります。 (limegreens/2006-11-07)

文字も小さく400ページ以上もあり簡単には読めるものではないが、プロジェクトマネージャを目指すあるいはその職にある者にとって最良の1冊となるのは疑いない。
現場のプロジェクトマネージャが必ず悩み懸念する事が章建てとして構成されており、他のPM本とは一線を画す。
美辞麗句な言葉はなく、全て著者の実体験に基づいた金言が散らばっている。

この書籍のおかげで、これからも随分と助かる気がする。 (blue/2008-11-16)

タイトルのプロジェクトマネジメントと聞くだけで嫌なものだと誤解して、食わず嫌いだった。しかし、アートオブとついているので、管理が技術だという視点からすれば、ちゃんと読めば良かったと後悔している。
第１０章は、特によい。人の仕事の邪魔をしないで、人の助けをするのが管理の基本である。しかし、多くの管理者、管理本は、人の仕事の邪魔をするようなことを平気でやったり書いたりしている。基本を外した本が多いなか、本書は要点を得ているので読む気になる。

飜訳が日本の文化への移転を十分していないのは、外資系の企業だけでなく、日本の企業でもソフト系の企業はカタカナ語が氾濫しているので仕方がないかもしれない。 (kaizen/2008-02-16)

プロジェクトマネジメントに興味があり本書を手に取りました。
なにか合理的な内容を求めるときは、いつも外国の書籍を読みます。
英語がもつ構造的な論理性に惹かれるのかもしれません。

実用性重視で書かれた多くのプロマネ本に対して、本書は
経験ゼロの人でも理解しやすい内容になっています。
それは数多くの実例と、著者のユーモアに依るところが大きいでしょう
私の本業はITから遠いので、実践的なソフトウェア、Web開発の章は
とばし読みしました。
それでもなお、目の覚めるような内容が含まれています。

１０章「メンバーの邪魔をしない方法」では、チーム内のコミュニケーションに
おける不快さの削減方法が記されています。メールや電話、あるいは立ち話
について、すぐにでも取り入れられることが多いです。
あるいは、１６章「社内の力関係と政治」は、組織に所属する
全ての人がぶつかる問題でしょう。
本章には「政治とは汚いことを表す言葉ではない」とあります。
政治が問題解決の１ツールであるという考え方は、風通しが良いです。

ソフトウェアおよびWeb開発に関する知識が乏しいため、私は本書の
価値を理解できていません。そのための星３つです。
もし知識があれば星５つではないかと思います。
(trafk/2007-03-25)

ITコンサル・プロマネ（職歴18年）視点でのコメントです。

システム開発やプロジェクト管理に関連した書物は、これまで数百冊を読んできました。

その中で三本の指に入る素晴らしい本です。絶品です。感謝です。

特に内容にはコメントしません。

私がこの本に支払ってもよいと考える金額は・・・

８０００円

しかし絶版だったら・・・金額はつけられませんが、何が何でも手に入れたい本です。 (pluto/2008-11-17)

プロジェクト管理の各フェーズで役に立つTipsを集めた一冊という感じです。
内容的には、なるほど、と思わせられるものが多いのですが、
訳がこなれていない上に、翻訳もの特有の笑えないジョークが鼻につくのが、
ちょっと残念、星一つマイナスです。 (palemoon/2007-04-22)

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

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

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

見積もり、運用/保守、組織改革など広い範囲の内容を、
比較的浅いレベルで網羅している。
ノウハウ的な内容はシステム開発に関連する書籍を何冊か読んだことが
ある人間には割りと常識的なことしか書いておらず、この著者ならではの
独自情報は特にないと感じた。

類書と異なる特徴があるとすると、現在進行形で現場のリーダーとして
働いている人間として、「受託開発」という仕事自体をより楽しくしたい、
という熱い思いが前面に出ている部分と思われる。
しかしながら、モチベーション向上や組織運営の向上、という
視点での考察について学びたいのならば、古典的名著である
トム・デマルコの「ピープルウェア」の方を私としては強くお勧めしたい。

内容的には星３つの本だと思うが、「受託開発の【極意】」を
標榜しながら【極意】に相当する有益な情報が得られなかったことが
失望を大きくしたので星２つの評価とさせていただいた。

(dbplatinum/2008-05-18)

あくまで自然体でありながら、熱く、的確に、開発への向かい方を示されたように思います。

テーマに挙げている「受託開発」について、設計，テスト，進捗管理といった日頃の開発ひとつひとつにおける取り組み方や、見積もりやチーム形成のあらゆる場面での考え方に至るまで、プロとしての実践的な「極意」がぎっしり詰まってます。
理想論とかじゃなく、あくまでも「現場」視点。エンジニアなら、共感しながら自分の開発に役立てることがたくさん見つかるはずです。 (mnishikawa/2008-04-16)

変化を起こすためには、自らが楽しんで率先して動くこと。
そして、周りを巻き込んでいくこと。
継続していくこと。

私が考えている実践的な組織論と同じ考えを
著者は自らの経験と知識を通じて、力強く執筆されています。

特に、第2部はプログラマではない私にとっても
心に響く内容でした。

同世代のビジネスリーダーを志す人々にとって
本書はとっつき易く、かつ、読んだあととても元気付けられること間違いなしです！

(rickey/2008-04-15)

ソフトウェア開発の中で「受託開発」に的を絞り、現場ベースでの立場から

筆者のノウハウを含め、いかに良いソフトウェアを開発するかという方向へ

導いてくれています。

内容的にはそこまで濃いところまでは踏み込んでないのですが、本書の

ボリュームからすると無駄なくまとめられている感がしました。

これからリーダー的立場になっていく方への入門書としてお勧めです。

また、マネジメントの要素だけではなく、第2部ではライフハック的な

内容も含んでいるので、良い環境へ変えたくためのアプローチのヒント

になるのではないかと思います。 (うりゆり/2008-11-16)

最近は見積もりの方法をFP法で頼まれることが多くなった
理由は標準化された算出方法だからだろう。
FP値は開発規模をお客が知るのに利用する。工数も計算出来るが、企業で、今までの生産性などのデータがなければ余り意味がないだろう。
会社の技術力でかなり変動すると思うが。。。。
CMMを推し進める企業ではFP法は良く出てくる。
私は、FP法をこの本で学んだが、時間もかけずに覚えることが出来た
本書の2/3ぐらいが例であり、それを読みつつ、最初のFPの部分で詳細を得るとよいだろう。
ただし、この本では設計が決定したことを前提として見積るので
要求段階でFP法を利用する場合は高度な設計能力がなければ実際に近いFP値はだせないだろう。
ただ単にFP法を学ぶには良書である。 (seastar/2004-06-30)

今までのファンクションポイント法の書籍や資料を読んでも、具体的な手順の説明が詳しくなく、例についても結果しか載っていないので、今ひとつ理解できずにいました。この書籍は、第2章の手順が詳しく、答えのついた練習問題があるので、手順の各フェーズでどう処理してよいか、よくわかるようになりました。また、第3章の4つのケーススタディは、第2章の手順に沿って具体的に説明してあるので、第2章の手順の説明の復習にもなり、理解が深まりました。ファンクションポイント法の意義はわかっていたのですが、モヤモヤとしていたものが、この書籍を読むことで氷解した気がします。 (しぶや/2003-08-28)

ファンクションポイント法の入門に最適。
概略やキーワードを示した後で詳細を説明するスタイルでわかりやすく、また非常に丁寧に説明がなされている。
第１章の背景・概略、第２章の計測法の解説（例題付）、第３章の練習問題、で終わる、まさにファンクションポイント法を身につけ、実践してみるのに必要十分な入門書だと感じた。タイトルに「入門」がないのが不思議なくらいだ。 (/)

私はファンクションポイント法にまったく触れた事のない初心者である。
この本は、そんな私にはぴったりの1冊であった。
この本は、大きく前半と後半に分かれる。
前半部分では、ファンクションポイント法の体系的説明がなされており、
ファンクションポイント法の概略を理解する事ができる。
少し文が単調に感じてしまう事もあったが、これはこれで、リファレンスとして
利用するには便利であった。
後半部分にはファンクションポイント法を利用する演習が豊富に用意されている。
自分が何がわからず、ファンクションポイント法を利用するとどんなことが可能に
なるのかを体験的に学習できる。
解らないところがあれば、前半部分を利用して効率的に演習を進めることができた。
私のような入門者にはお薦めである。 (/)

本書は、ソフトウェア開発の生産性を高めるためのソフトウェア・エンジニアリングに関して書かれているものです。ソフトウェア・エンジニアリングとは何か？、コンピュータサイエンスとの違いは？、他のエンジニアリングとの違いは？などといった疑問に答えてくれる本です。また、ソフトウェアプロフェッショナルの意識について、個人の視点、組織の視点、業界の視点から論じており、この仕事をしている者として大変参考になりました。ソフトウェア開発者の必読書だと思います。 (TRK/2005-02-26)

IT業界は、うわべの技術が次々登場するだけで、実際の進歩は早くない。20年前に登場したソフトウェアの生産性を高める技法であっても、現場では意外と使われていない。見積もり一つをとっても、KKD(勘・経験・度胸)と呼ばれる手法(ですらない)が大半を占めている。
ソフトウェア開発には、プロセス志向と実力主義の二つのアプローチがある。どちらでも適切に運用すれば、良いソフトウェアを開発することができる。しかし実際に多いのは「ニセ実力主義」の組織であり、古い技法すら使わぬままにデスマーチを繰り返し、開発者を疲弊させ、失敗プロジェクトを量産している。
本書では、ソフトウェア工学を適切に運用する意義を説いた上で、ソフト開発プロの免許を提唱している。無茶な納期や品質への妥協を上司に強いられても、プロの免許があれば「これを認めれば免許取消か告訴のどちらかだ」と拒絶する権利を持つとの提案は、実に魅力的だ。米国でのプロ免許の重みが、日本では考えられないほど重いことが背景にあるとは言え。
「ニセ実力主義」のソフトウェア開発組織で働く技術者および、ソフトウェア開発組織を運営する管理者・経営者には一読の価値あり。特に管理者・経営者には、自分の組織がニセ実力主義ではないか、そうならばどう脱却するか考えるために読んでいただきたい。 (sakidatsumono/2005-02-13)

本書は、経験は乏しいが理工系学部以上の知識がある人、または、経験も理工系学部以上の知識があり、昔持っていた志が廃れ気味の人に、とても推薦できる書物と思う。
他のエンジニアリング分野とソフトウェア・エンジニアリングとの対比（違いがあるのか？）、現在のソフトウェアを産み出す工程がソフトウェア・エンジニアリングとなるべく取り組むべき事柄についての考え方は、本物のプロであるならば一読する価値はある。
章の冒頭で引用しているベーコンの言葉もなぜか心に響くものがあり、ソフトウェア関連書籍でお気に入りのひとつとなった。
また、個人的に次のような事柄も興味深かった。
本書では、「プログラミングの心理学」等で著名なワインバーグの名前が見当たらない。
「プログラミングの心理学」では、デマルコの「ピープルウェア」を批判的に述べているので、その本と本書でたびたび引用している「ピープルウェア」の内容との対比が強調された。 (masabun/2006-03-03)

優れた現状分析がされていて、読み物としては面白いのですが
その対策として、免許制度によるプロの育成では、即効性に
欠けています。
長期的な視点で読む本でしょう。
(keroko/2008-10-24)

例えば、フリーランスの開発者の場合、数々の企業と契約しながら設計･開発を進めるワケですが、ぶっちゃけ上場大企業でさえ作業標準や管理基準があやふや(最近はPMP他普及で多少は改善していますが)、CCB工数はダレが持つのか？、作業範囲･スコープは？、、←というコトバさえ理解されないコトも多い＾＾；
この本では、本来あるべき、契約にもとづく"品質の高い"OUTPUTの目指し方が書かれています。
私は、07年度後半に始まった某2次請け系業者との契約〜設計･開発の最中、あまりのアバウトさに閉口して本書を購入、読みながら『そうだそうだー！！』を連発していました。。
(上記業者とは、その後、契約範囲と瑕疵他明文化により作業範囲を囲い込み、離脱成功しています。)

アバウトな契約に悩める技術者の方へ、あなたの鬱憤も本書で少しは晴れることでしょう。
デマルコ本の曖昧さに迷いが生じている方にもオススメです。
また、国内で書かれたこの分野の書籍には偏ったものが多い印象なので、それらを俯瞰する視点を磨くためにも良書であると言えます。 (/)

ソフトウェア開発の文化論についての書籍としてはトム・デマルコの本が有名だが、
トム・デマルコの本は基本的にプロジェクトマネジメント論としての性格が強く、
その中において人を中心とした内容が多いと言われるのは周知の事実である。

そんなデマルコ本をプログラマーからシステムエンジニアあるいはマネージャへの
上位へのステップアップとして手を出してみたものの、敷居の高さを感じて
挫折してしまったと言う経験をお持ちの方はいないだろうか？
そんな方には是非こちらの本を読んで見ることをお勧めする。

本書はソフトウェアエンジニアリングと言う視点をベースに持ち、
コンピュータサイエンスとの比較を中心にソフトウェア開発技術者、
つまりソフトウェア開発のプロフェッショナルとしてどうあるべきか？
と言う内容が語られている。

章構成も良く考慮されており、最初はソフトウェア開発プロジェクトが
現在の様に至った過程を示しベースを確立する。その後は個人＜組織＜業界と
対象範囲を広げながらそれぞれの視点で「ソフトウェア開発のプロフェッショナル」が
どうあるべきかが語られ、後半にはソフトウェア開発における教育制度や
免許制の導入についての考え、技術者が持つべき倫理観について筆者の想いが爆発する。

とは言うものの詭弁じみた内容は全く無く「理にかなった形で実現するには」と言う
視点から外れていないのが見事だ。実際に実現する日もそう遠く無いように思う。

各章の終わりには参考文献のリストが載っているのだが他の書籍と比べるとその量が
非常に多く、裏取りの緻密さが伺える。日本語訳が出版されているものもそれなりにあるので
そちらもあわせて読んでおきたい。

久しぶりに「スカッ」とした読み心地であったので評価は５です。
(コモヒコ/2007-09-14)