1. 見積り入門
Ver 1.0

2. はじめに
 対象者
チームリーダ、またはチームリーダ候補
ですが、メンバの方もリーダの考えを知るのは重要なので全然 OK
 狙い
・「見積り」で求められていることを知る
・見積り手法にどんなものがあるか？またその特性は何か？を知る
・見積り時に気を付けるポイントを知る

3. 見積りって ?
「このリストにある機能を見積もって欲
しい。
次の新製品に搭載したいので６月までに
は
完了してほしい」
といわれたら何をしますか？

4. 何を求められているかを理解する (1)
 ビジネスターゲット／ターゲット
実現したいビジネスの目標
⇒予算内で出来るだけ多くの機能を載せたい。
ある機能をどれだけお金がかかっても載せたい。
デモをやりたい。出来るだけ早くリリースしたい。 Etc…
 見積り
ターゲットを達成するためのコントロールを行う上で、
適正な意思決定ができる明快な視点を提供するもの。
 計画
スケジュール、体制、マイルストーン。

5. 何を求められているかを理解する (2)
これらの見積りはそれぞれ異なりま
す。
工数 規模
コスト スケジュール

6. 「良い」見積りの定義
プロジェクトの責任者がプロジェク
トの
ターゲットを達成するためのコント
ロールを行う上で、適切な意思決定
が出来る
明確な視点を提供する見積り

7. 過小見積りと過大見積りの比較 (1)
過大見積りの弊害
パーキンソンの法則
仕事は、その遂行のために利用できる時間をすべて埋めるように拡大する
学生症候群
納期のある作業を行う際に、余裕時間があればあるほど、
実際に作業を開始する時期を遅らせてしまう

8. 過小見積りと過大見積りの比較 (2)
過小見積りの弊害
予定通りに完了する機会が統計的に減少する
開発者の作成する見積りは、実際の工数よりも２０％～３０％低くなる。
手戻り工数の増加
見積りが少ない場合、設計工数に十分に時間がとれないといった現象が発生し
プロジェクトの後期になって設計やテストの繰り返しが発生する。
遅延がさらなる遅延を呼ぶ
プロジェクトが一度「遅延」状態に陥ると、予定通りに行われている時には発生しない
様々な作業が発生し、さらなる遅延を呼ぶ。例えば以下のようなもの。
・遅延挽回策の検討のための MTG
・プロジェクトの軌道修正のための再見積り
・顧客への謝罪。またそのための資料作成
・顧客やステークスホルダーへの暫定リリース版の準備（本来であれば通常のリリース版で実施）
・モジュール結合などが行えず一部チームで待ち状態が発生
・ターゲットの達成のための機能ドロップなどの検討

9. 過小見積りと過大見積りの比較 (3)
比較検討
学生症候群
実行タスクの監視を行えば問題ではない。
不利益の多さ
見積りが少なければ実コストが増大しプロジェクト効率が悪くなる。
見積りが多ければパーキンソン法則が始まる。
どちらの不利益が多いのか？がポイント。
過大見積りの場合、不利益は「直線的で有限」
⇒ 使用可能な時間を使いつくすまで拡大する可能性があるがそれ以上は拡大しない。
過小見積りの場合、不利益は「直線的ではなくどこまでも増えていく」
⇒ 損害がどこまで増えていくか分からない。
過小見積りによる品質低下
⇒ 切迫したプロジェクトでは、切迫していないプロジェクトに比べて４倍の欠陥が発生する。

10. 見積り手法の分類
分類 概要
類推型 過去の類似プロジェクトとの比較から，開
発するシステムの規模や工数を類推する
係数モデル型 機能数や画面数といった値に係数をかけて
見積りを行う。
ボトムアップ型 実際の作業単位までに細分化されたタスク
から工数を算出する方法。
個々の作業を見積もって積み上げていく。

11. 見積り手法（類推型）
具体的な手法例
類推法、デルファイ法
メリット
要件定義が完了していない初期段階でも見積りやすい
過去の実績データが多い場合、比較的少ないインプットで
精度のよい見積りが出来る
デメリット
そのプロジェクト特有の要件があまり加味されない。
経験のない領域については見積り出来ない
過去の実績データが少ない場合、客観性に欠ける。精度が低い

12. 見積り手法（係数モデル型）
具体的な手法例
LOC 法、 FP 法、 COCOMO/COCOMOII 、ユースケースポイント法
メリット
画面数や機能数をベースとするためユーザーの納得感を得やすい
FP やユースケースなどは開発言語の影響を受けにくい
デメリット
要件定義が完了していないと，見積もることが難しい
非機能要件は見積りにくい（可用性や品質の重さの違いなど）
パラメータの設定自体、難易度が高い
PG フェーズといった局所見積りには向かない

13. 見積り手法（ボトムアップ型）
具体的な手法例
WBS 法、標準タスク法
メリット
 細分化された工数やコストを成果物として算出するので見積り後の
スケジュール作成やコストの予実管理に流用しやすい
 洗い出しが出来ているタスクについては精度が高い
デメリット
ドキュメントやプログラムなど作成する成果物を基準に見積もるので，
要件定義や開発プロセス定義などは完了している必要がある
非機能要件は見積りにくい（可用性や品質の重さの違いなど）
作業洗い出しに時間がかかる

14. 見積り手法の具体的な例（ PERT ）
公式
期待ケース = [ 最良ケース + (4 * 最有力ケース ) + 最悪ケース ] / 6
最良ケースと最悪ケースを考える理由
１点見積りは精度が余り良くない
１点見積りは最良ケースの見積りに近くなる傾向がある
最悪ケースを考える習慣をつけることで見積りの精度が向上する
期待ケースを求める
最悪ケースと最良ケースの中間点では不必要に多くなる傾向
最有力ケースを追加して上の公式で期待ケースを算出する。

15. 見積りの漏れ
見積りを実施したタスクの精度は高い傾向だが、
一般に開発者は必要な作業の２０％－３０％の
作業を見落とす傾向にある。
（「 Why is software late? An empirical study of reasons for
delay in software development 」 van Genuchten 1991 IEEE)
見落としを以下の３つのカテゴリに分けて見てみる
•要求の見落とし（暗黙に示されている要求）
•開発作業の見落とし
•開発作業以外の作業見落とし

16. 見積りの漏れ ( 要求の見落とし )
 セットアップ／インストールプログラム
 外部システムとの I/F
 オープンソースを利用するためのグル―コード
 セキュリティ
 移植性
 信頼性
 拡張性
 ユーザビリティ
 再利用性

17. 見積りの漏れ ( 開発作業の見落とし )
 チームメンバーの立上げ
 ビルド環境等の開発環境の構築
 テストデータの作成
 変更管理、変更要求の処理
 前システム／既存システムのサポート
 パフォーマンスチューニング
 開発ツールの学習
 市場や品質保証部門からの問い合わせ対応
 顧客や展示会でのデモ
 計画、見積り、アーキテクチャ等のレビュー
 ユーザマニュアル作成、ユーザ教育

18. 見積りの漏れ ( 開発作業以外の作業見落とし )
 休暇、休日
 トレーニング
 ソフトウェア管理
 ハードウェア管理
 自社の進捗／社内見積り等の MTG ／報告
 自社／他社メンバーの評価
 協力会社の面談、ユーザ面談

19. 見積りに影響を与えるもの①（規模）
プロジェクト規模と生産性の関係
プロジェ 規模 (LO C )
クト 人年あたりの LO C
１ 万 2,000～25,000
１万
０ 1 ,000～20,000
１０
０万 700～1 0,000
１０万
００ 300～5,000
出典：『 Miasures for Excellence 』 (Putnam,Meyers,1992) 、『 Industrial Strength Software 』 (Putnam,Meyers 1997)
『 Software Cost Estimation with CocomoⅡ 』 (Boehm et al 2000) 、
『 Software Development Worldwide:The State of the Practice 』 (Cusumano et al. 2003)
一般的な傾向として規模が大きくなれば生産性は低下する

20. 見積りに影響を与えるもの②（ソフトウェア
の種類）
ソフトウェアの種類と生産性の関係
LOC / 人月 最小値～最大値 ( 見込み値 )
１ LOC
万 １ 万LOC
0 25万LOC
ソ ト アの種類
フ ウェ
プロジェ ト ク プロジェ トク プロジェ トク
航空電子工学関連 1 00～1 ,000 200～300 20～200
(200) (50) (40)
業務システム 800～1 8,000 200～7000 1 00～5,000
(3,000) (600) (500)
組み込みシステム 1 00～2,000 30～500 20～400
(300) (70) (60)
イ ーネッ システム
ンタ ト 600～1 0,000 1 00～2,000 1 00～1 ,500
(公開用) (1 ,500) (300) (200)
イ ラ ト
ント ネッ システム 1 ,500～1 8,000 300～7,000 200～5,000
(社内向け) (4,000) (800) (600)
リアルタ ムシステム
イ 1 00～1 ,500 20～300 20～300
(200) (50) (40)
パッケージソ ト
フ 400～5,000 1 00～1 ,000 70～800
(1 ,000) (200) (200)
システムソ ウェ
ウト ア、 200～5,000 50～1 ,000 40～800
ド イ
ラ バ (600) (1 00) (90)
一般的に下回りの開発は生産性が低く、業務システムなどと
比較すると１０倍～２０倍の差が出てくる

21. 見積りに影響を与えるもの③（人／言語）
 人的要員
一般的な技術スキル、業務領域の経験、使用言語／ツールの経験
、
プラットフォームの経験、チームの結束・・・
などの組み合わせによる生産性の幅は２２倍。
 言語
C 言語を１とした場合の他の言語の生産性
Java ／ C# ／ C++ ： ２．５倍
VisualBasic ： ４．５倍
Perl ／ SmallTalk ： ６．０倍
※ツールセットの差でも５０％の差異がある。

22. 見積りの正確性と精度
見積りの有効数字の桁数 ( 精度 ) と
見積りの正確性を一致させる。
（例）
・ π ＝３ は正確だけど精密でない。
・ π ＝３．１５８７３ は精密だけど正確ではない。
・ステークホルダーは精度を見て正確性を
判断する傾向があるので要注意
・適当な積み上げで 62.5 人日・・・というような見積りに
なった場合は３人月といった風に報告する

23. 見積りの前提条件
見積りのインプット資料
どのバージョンの仕様書か？など
◆ 納品成果物
開発のスコープ／スケジュール
曖昧／未決定の要件については仮の要件を設定する。
合わせて確定時期、確定後の措置（金額・スケジュール etc ）を
記載。
プロセス定義／テスト要件
非機能要件に関する記載
パフォーマンス、可用性、教育、運用・保守など
他者に依存する作業
仕様書のリリース時期、他社ベンダのライブラリ提供時期など。
レビューへの参加、要件定義 Fix 日など顧客に対する要求は明記
する。
仕様変更に関する取り決め
仕様変更の管理方法や発生時の措置方法
契約形態
体制／会議体
特にユーザ側の体制

24. 再見積りのタイミング
プロジェ 中のポイント
クト
初期見積り／初期コ ンセプト
製品化の承認
要求の完了
基本設計／UI設計の完了
第１次～第N次暫定リ ース
リ
実装の完了。
プロジェクトのステークスホルダーとは前もって再見積りの計画を合意しておくこと
お客様との間で再見積りが無い場合でも、マネジメントの観点から
内部的に定期的な見直しの計画が必要ないか検討すること。

25. 見積りの補正
例えば、 6 ヶ月のスケジュールがあったとしよう。あなたは、
最初のマイルストーンを 4 週間で達成する計画を立てた。しかし、
実際には 6 週間かかってしまった。
この場合、あなたなら次のうちどれを選ぶだろうか。
失った 2 週間は、スケジュールの後の方で埋め合わせられると考える。
スケジュールの合計に 2 週間を追加する。
誤差の大きさ ( この場合は 50%) をスケジュール全体に掛け合わせる。
もっともありがちなのは、 1 番目の選択肢だろう。通常は次のような論法になる。
「要求にかける時間が予定より少し長かった。だが、もう要求は固まった。
残りの時間を切り詰めよう。
コーディングとテストの間で不足分を埋め合わせられるはずだ」。
しかし、 1991 年に 300 以上のプロジェクトについて調査した結果によると、
プロジェクトが一度失った時間を埋め合わせることは、
まず不可能であることが分かっている。
それどころか、遅れはさらに広がる傾向にある。したがって、
この選択肢がベストチョイスなることは、ほとんどないと思ってよい。
( 中略 )
よほどの例外を除いて、実際の結果が見積もり通りにならない場合の
正しい選択肢は、 3 番目ということになる。
出典：ソフトウェア見積り 人月の暗黙知を解き明かす Steve McConnell 著

26. 見積りのポイント (1/2)
1.過去の実績データを利用する
3.複数の見積り技法を組み合わせて確認する
5.複数の見積り作成者の突き合わせを行う
7.再見積りを行う
9.インプットを補正する。アウトプットは補正しない
11.見積りの幅を持たせる

27. 見積りのポイント (2/2)
1.スケジュールを短縮する場合は工数を増やす
3.マネジメント工数は総工数の 10%-15% が目安

28. 見積りの交渉
見積りの議論を「交渉」ではなく、「問題解決」として考える
お客様は交渉のプロであることが多い。技術者は交渉の素人。
立場ではなく『利益』に焦点を合わせる
技術知識を持たないステークスホルダーはターゲットのオーナー、
技術者は見積りのオーナー。
ステークスホルダーは技術者の知らないビジネス上の情報を持っている。
技術者はステークスホルダーの知らない代替案を持っている。
予算超過の嵐より、嫌がられる見積りの雷を選ぶ

29. 参考資料（書籍）
1. ソフトウェア見積り 人月の暗黙知を解き明かす Steve McConnell 著

30. 参考資料（ Web ）
 やることリスト」に基づく見積もり手法
http://www.aerith.net/design/easy_estimation-j.html
 コンサルタントがよく使う RFP の書き方： 12 項目で網羅的に作成
http://enterprisezine.jp/article/detail/3414
 ソフトウェアテスト見積りガイドブック
http://sec.ipa.go.jp/pubcom/files/Guidebook_for_Estimating_Software_Test_07.pdf
 プロジェクトマネージャーとして特に知っておいて欲しい、
トラブル事例と JEITA モデル契約書活用のポイント
http://home.jeita.or.jp/is/seminar/101214and110210solution/101214_110210-2.pdf