リスト：見積(自分用まとめ) を表示しています。（全 5 件）

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

FP値と係数による見積、WBSによる見積、保守開発の見積など、様々な切り口にて、工数見積の方法が記載されています。わかりやすい本なので、職場の方にもおすすめしました。FP法だけ説明している書籍より、この本の方がバランスがとれていてるので、お勧めです。（okamoto53515606 / 2010-03-09）

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

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

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

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

→見積りという切り口で、ＳＥ作業を分析した本
　プロジェクトの計画段階だけなく、
　実行・運用・保守段階に至るまでの、
　「合理的な手法を使った見積り」が、詳しく解説されています
→その合理的な部分は、
　著者の日本ＩＢＭ時代の経験が
　色濃く反映されていると思います
→巻末に載っている
　「見積もり用エクセルファイルの作り方」は
　参考になると思います
　
　現実的の仕事には、一度作ったその「合理的に作られた見積り」に
　「大人の事情」という係数を
　掛けないと使えないかもしれませんが..
→忘れかけていた基本を、思い出すことができました！
現実的に、この見積りを仕事で使えるかは置いといて．．（よこはま　こうたろう / 2007-12-09）

システム開発関連の契約はとても複雑で、実際には、委託者、受託者双方とも中々合意できない条項が多々ある。
そのような実務レベルでの観点からは、書かれていないのが残念。
著者の体験を基に、こういうときにはこう対処した等、事例があるともっと良かったと思う。
ただ、システム開発関連の契約書を全く書いたことがない人にとっては、基本的な条項として参考になると思う。
（クライアント / 2007-04-27）

内容は悪くはないが、しかし実際に利用できるCD-ROMやダウンロードがなく、これらで実用性が大きく違ってくる。その点が非常に残念だった。（ / ）

重要なのは、お互いの合意を証明してしておくこと。
* 著作権の全貌
* プログラム内部（モジュール）に対する著作権
* 請負契約と委任契約の違い
契約書の各項目について、図解で解説されているので
大変わかりやすい。
実用性は乏しいが、各事項の読み取り方が
個別にアドバイスされているので、"基本"以上に役立つ書籍。（ウェブ担当 / 2009-06-16）

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

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

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