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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェアのプロマネ本の1つです。
ソフトウェアの開発を管理する上で、気を配らなければならないことが書いてあります。作者の長いソフトウェア業界での経験が凝縮されていて、その点は参考になります。
しかし、少し内容がふるいのが気になります。1980年代の前半の話などがよく引用されて出てきます。さすがに20年前の話をされても困ります。
で、トータルすると星３つ。 (ユングベリ/2008-12-21)

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

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

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

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

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

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

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

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

８０００円

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

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

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

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

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

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

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

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

疑問を投げかけ前提に挑む。
そんなプロマネの存在理由が明らかに。

機能的な書籍というよりは、如才無いプロマネの心構え。

著者のScott Berkun （スコット・バークン）さんは、
マイクロソフトで、OfficeやVisual Basic、IE等の
プロジェクトに関わってきたようだ。

プロマネの経験がある人なら、それらのプロジェクトが
どれほど壮大か想像できるだろう。
その場で、吐き気をもよおす人もいるかもしれない。

プロセスに取り憑かれ、方法論への執着が
間違った方向へ行っている場合、力が大きいほど、修正はきき難い。

チームメイトに心配を抱かせないためにも、
プロジェクトマネージャーだけではなく、チーム全員が読んでいただきたい。

スケジュールが狂うのは何故か？

「スケジュールが遅延するということは、
誰も把握していないコストが隠されていた、
あるいは無視されていたということを意味しているわけです。」

以下の2つ、笑えるけど、自分がやっているとしたら、
まったく笑えない。　その詳細も解説

* 「よく見かける悪い手段」
* 「質の低いビジョンのドキュメントに見られる特徴」

大胆さ、図太さがプロジェクトを邁進させる。
あなたへの命令が大切なコトか試す方法

「私は、自分が理解できない、遠回しで曖昧かつ官僚的で組織的な
プロセスは無視するようにしています。」

無視した事案が大事な場合、偉い人がスッ飛んでくるハズ。
重要でない場合は、当然、誰も来ない･･･

現場を守る、プロマネの領域

「誰かが優先順位を無視した指示をしてきたと思った時には、
『ノー』と言ってください。

あるいはその指示をした人に対して、私が『ノー』と言っていたと伝えれば、
その人は私のところに来るはずです。

もし彼らが文句を言ったとしても、
議論して時間を無駄にしないようにしてください。

とにかく私のところに来るように、その人に伝えてください。」

"計画すること"が目的ではない。

「計画に従うことで勝利できるような戦いはないが、
計画なくして勝利できるような戦いもない。」

ドワイト・E・アイゼンハワー（ドワイト・D・アイゼンハワーのこと？）

それでは、何故計画をするのか？

「戦闘というものは計画通りに行えるものではない。
計画は変化に備えた共通の基盤でしかないのだ。

重要なことは、全員が計画を知っておくことで、
容易に変更が可能になるということなのだ。

近代戦は非常に流動的であり、
意思決定は迅速に行わなければならない。

そしてそのほとんどは計画に従ったものとはならないのだ。

しかし全員が少なくとも、自分はどこから来て、
（その後）どこに向かっていくのかということを知っているのだ。」

イスラエル防衛軍司令官 ダン・ラネル陸将補


つい、行うタイミングを逃しがちな、プロジェクトの検死報告（反省会）

打ち上げの偉大性、組織を構成するメンバー、個別の利害にも目を光らせる

皆さんが気になるのは、16章の「社内の力関係と政治」ではないだろうか？

* 「政治的な理由で･･･」
* 「大人の事情で･･･」

と言った言葉は、逃げの言葉だ。
語る者同士の思考を停止させてしまう魔力がある。 (ウェブ担当/2009-06-12)

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

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

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

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

本書は、見積もりのいろいろな事例を紹介しています。

定型的な開発では、見積もりが容易だと言われています。
しかし、定型的な開発なら自動化できるので、ほとんど費用はかからないかもしれません。
何に費用がかかるのでしょうか。

ITで見積もりができれば、製品が完成したも同然と言われることがあります。
新規開発では、見積もれない要因があるので、少し開発をし、試験をしてみて、全体を見積もるのでないと現実的な見積りにならないという話をお聞きしたことがあります。

インクリメンタル開発、プロトタイピングなど、見積もりをするためのソフトウェア開発をしている場合があります。
本音と建て前の間の差は、見積もりの誤差よりも大きくないでしょうか。

見積もりの協議のきっかけの出発点として、お互いに何を見積もりたいかの議論の出発点としてよい本ではないでしょうか。 (kaizen/2007-12-17)

やっと日本でも分かりやすい見積りの本が出たか、とわくわくして思って読んだ。式を示してくれるのはうれしい。一通り教えてくれるのはうれしい。
しかーし、FPとCOCOMOを単純に比べたりしてるのでちょっとびっくりしました。FPは規模見積でCOCOMOは工数見積と教わったんですけど。FPはLOCと並ぶものではないんですか？
内容を鵜呑みにしないでひとつの考え方として読むのはいいかもしれません。この本をバイブルにするんじゃなく、見積手法を考えるきっかけとするならいいかもしれません。その勢いで引き続き各手法の専門の本を読んだ方がいいと思います。英語の本しかなかったりするんですけどね。
とはいえ、ちょっとオリジナルなソフトウェア見積の一般書を出した勇気に星一つ。
そして、この本をきっかけに多様な見積本が出てくることを夢見て星もう一つ。 (metochan/2004-08-05)

・開発規模、コスト等の、所謂工数見積りのみでなく、むしろ開発SEがプロジェクト推進にあたってぶつかる課題を、プロジェクトフェイズ毎に『見積り』をキーワードとして解きほぐしてくれる、『ソフト開発入門書』としての良書。
・開発規模見積りからWBS・ガントチャートへの展開手法や進捗管理の勘所（例：テストを終了するタイミングを『見積る』）等も具体的に示されていて、これからPMを経験するシニアSEには便利。
・反面、費用や工数の算出根拠になる開発規模ソノモノは、机上検討でプログラム行数を決める所からスタートしているので、その根拠となる手法は別途学習する必要がある。タイトルの『見積り』が、狭義の『開発工数見積』と同義でないことに注意が必要。
・ある程度の営業、プリセールス、サブリーダー級以上の開発SE経験がある人なら1日でさっくり読めて、初心者の教育用としても好適。持って損のない本。 (TOSHI!!/2005-04-26)

　ある程度規模の大きなシステム開発の案件をプロジェクト
チームで対応しようとするときのステップごとのチェック項目、
何に重点を置くべきかと行った視点の置き方、意識の違うメンバー
の意思統一、情報共有を図る手段が「見積り」なのだという主張
は、大変新鮮。まずはこの視点に感動した。
　さらに、具体的な作業の手順やチェックポイントを具体例や
図を使って解説しているところもとても分かりやすい。
　「ありがちな１冊」と思いきや、手にとって読んでみると
出色の出来であることがわかる1冊です。 (ny/2005-07-15)

見積もりの基本というタイトルに反して、プロジェクト全過程における受注者、発注者各担当の心構えに焦点が置かれている。
見積もりもCOCOMOだけで、それもEXCELテンプレートを自分で打ち込む為の数式が書かれているだけ。
COCOMOの各変数の意味合いなどはまったくわからない。
他の見積もり手法は名前だけの紹介。
見積もり手法を勉強することが目的であれば、本書は役に立たない。
プロジェクト全般の進め方であれば、それなりに役に立たないこともないが、当たり前と思われることが多いし、昔のやり方という気がする。
(笑/2009-02-14)

→見積りという切り口で、ＳＥ作業を分析した本
　プロジェクトの計画段階だけなく、
　実行・運用・保守段階に至るまでの、
　「合理的な手法を使った見積り」が、詳しく解説されています

→その合理的な部分は、
　著者の日本ＩＢＭ時代の経験が
　色濃く反映されていると思います

→巻末に載っている
　「見積もり用エクセルファイルの作り方」は
　参考になると思います
　
　現実的の仕事には、一度作ったその「合理的に作られた見積り」に
　「大人の事情」という係数を
　掛けないと使えないかもしれませんが..

→忘れかけていた基本を、思い出すことができました！
現実的に、この見積りを仕事で使えるかは置いといて．． (よこはま　こうたろう/2007-12-09)

新規システムの開発とは異なり、

　既存のシステムがある状況で新たな機能を開発・・改良開発における見積り方法。

　・・でも、いまどき、純粋の新規システムの構築の方がまれなので、参考になります。
　

　改良開発のコスト構造・・

　　・既存システムの規模
　　・既存システムの理解容易性

　　・保守性の水準

　　・機能の変更量・追加量　等々を、考慮した上で見積もる必要あり。

　また、新規開発との大きな違いは、

　　「機能量とテスト量の相関が新規開発に比べて低い点」

　　ｅｘ．ソースコード１行の変更でも、そのコードが含まれる機能が母体の多くの部分に関係する場合
　　　　　であれば、その変更の妥当性を保証するために、関係する母体全体をテストすることもあり。


　また、保守性は、当然ながら、以前のプロジェクトの品質に大きく依存すること。


　以上踏まえた、ジャステックさんの改良開発の構造を踏まえての見積りモデル、

　計数の想定や計算式の適用可否は判断必要ですが、見積り時の考慮の観点、とても参考になります。

　・・既に実施されている場合でも、内外への説明として、頭の整理に良いと思います。
(papillon/2008-09-22)

見積もりの事例は貴重です。各社がどういう見積もりをしているかがわかる。

ps.
ソフトウェア経済学という用語があったが、発想は斬新かもしれない。経済学が、膨大は論理とデータを消費する学問がもう一つ増えるのであろうか。

原価計算に基づかない見積もりに、どういう意味があるか、あるいは原価計算に基づいた見積もりをするが原価部分は公開できないということであろうか。
ソフトウェア開発の資源として重要なプログラマの原価の計算が十分でなく、性能（能力）の評価が十分でなければ、よいものは作れないのではないだろうか。
見積もりにおいて、誰が担当するかによって原価が違うはずであるが、顧客にはそれは知らせないのが慣習になっているのだろうか。

その他の課題としては、調達の基準である各種国際標準との関連が明確でない点である。
受入試験をどうやっているかによって、見積もりの精度が変化するかについての記述があるとよかったかもしれない。 (kaizen/2007-12-22)

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