「ソフトウェア開発の定量化手法」 とその関連商品

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

辞書にもならない。
この著者の本ではもっと分かりやすく実践的なものがあります。 (/)

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

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

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

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

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

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

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

第１８章　プロトタイピングの見積りが役に立ちました。
中規模がプロトタイピングに合うこと。
使い捨て、タイムボックス、進化型の３種類あること。

第１９章、設計の見積り、
第２０章　設計検査の見積り
第２４章　ソフトウェア試験の見積り
も大切だと思いました。
(kaizen/2008-07-09)

どうも日本の教育は定量的な労働の評価を行うことができない。成果主義とは名ばかりで、「成果」を測る尺度が明確に定義されず「好き嫌い」が評価になっている。また、このように感じることを、労使・管理者/従業員のお互いが納得できるようになっていない。本書のようなデータに基づく、明示的な尺度で、評価して欲しいと思うのは私だけだろうか。そうではないだろう。このために、リーダーたるもの、勢い（意気込み・やる気）だけでなく、冷静な目で、本書のようにプロジェクトのリスク評価を行える技量が必要なはずだ。大多数の人は、使われる側であるが、リーダーが勉強しない以上、自己防衛のために読むことも勧めたい。今までに「突撃隊の仕事」に疑問をもった経験のある人なら、身にしみる話ではないだろうか。ソフト業界だけに限らず、他の業界でも同じことがあると思う。（すくなくとも、ハードウェア設計でも同じことが言えることは私は調べている。） (hisashi3sasaki/2001-05-30)

見積もりに関するソフトウェア工学の論文を紹介するだけの本。本文はとっても読みにくい文体。
単なる目録用途にしか使えない。 (amazon_hk/2004-09-20)

確かに定量的な資料で説明されるので具体的な何かが得られるような気になります。しかし現在のIT業界（特にWeb業界）では１～２カ月間にサイト構築やサイトの全面改訂をしますから；彼らの仕事していた時代とは本質的にスピードが違います。ＸＰに代表されるプログラミング手法が流行るのはその手法が有効だからです。しかし、この本の内容はＩＳＯ９０００取得するような場合には役立つかもしれないが．．．現在の若手バリバリの方々に有効でないと感じます。 (/2003-08-31)

だけど、このデータ本当に自分のプロジェクトに使えるのかなぁ。
答え→読んで考えてください。 (/)

ソフトウェアの開発現場でメトリクスを行う際には、
１．目的(情報ニーズ)を明確にすること
２．データの分析結果を現場にフィードバックしてあげること
が非常に重要である。目的もなく、現場に何のメリットももたらさないメトリクスは、現場の負担となるだけである。
その意味で、本書は、メトリクスの構築を情報ニーズの明確化から分析方法の確立までの一連の手順として紹介しており、わかりやすい。
メトリクスを現場に導入するための有効な教科書だと思う。 (/2005-03-07)

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

大学で品質工学をやる方にはよいのかもしれませんが、専門ではない私にはちょっと敷居が高かった。難しくて読むのを断念。 (Turtle/2007-08-06)

本書は、日経ＩＴプロフェッショナルに２００５年５月号から、２００６年３月号まで連載された、「本当に使える見積もり技術」を加筆修正して出版された本である。連載当時から興味深い内容であったので、今回の出版はよいことだと思う。著者は、ファンクションポイント法（ＦＰ法）の専門家である。理論的に仕事をしているＳＥにとって、見積だけが、「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)

インスペクションとは上流工程からの成果物(機能仕様書、テスト仕様書など）に対して一定の判定基準を元に内容を精査するプロセスのことです。
ソフトウェア開発プロセスの品質改善とプロセス自体の改善を目指したものであり、そのために本書ではデータの収集と分析を非常に重んじています。
どちらかといえば形式的なところを重んじていますが、それによる問題も同時に取り上げています。
正直な感想としては、内容に重量級のボリュームがあり、すぐに実践できるかというと、「それは無理」と感じます。
何度か実経験を踏んだ上で、さらに何をどうしたらよいか考える再に、非常に示唆に富んだ提言がかかれていると思いました。
実際の成功例・失敗例などもリアルに書かれているので、インスペクションは成功すれば成果はすごいが、そんなに容易でもないということを分からせてくれます。
分量的な面から言っても、あまりイントロダクションとしてはふさわしくないです。
インスペクション初心者には Karl E. Wiegers の「ピアレビュー」と併読することを勧めます。
「ピアレビュー」は大変良い書物ですし、内容の割には薄い本なので初心者にはもってこいなのです。
その上で本書を読むことにより、インスペクションを実施していくための理論的基礎の強化ができると思います。 (taka-m/2005-11-08)

検査といわれればするのに、インスペクションといわれた途端にやる気がなくなる現場がある。なぜかはわからない。自己査定は許容水準だった。自分では、この点よりよくするつもりはありません。これ以上やると無駄が増え、改善を阻害しそうだと感じるからです。大規模組織で、大規模開発の場合と、小規模組織で、小規模開発の場合での違いがあるかどうかが課題だと考えています。

以下は自己査定の回答例です。
(1)　通常する
（２）通常する
（３）ときどき
（４）通常する
（５）ときどき
（６）ときどき
（７）通常する
（８）ときどき
（９）通常する
（１０）まったくしていない
（１１）通常する
（１２）通常する
（１３）通常する
（１４）通常する
（１５）ときどきする (kaizen/2008-07-09)

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

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

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