ソフトウェア見積り

!!第1章　見積もりとは
!見積もり、ターゲット、コミットメント(p4)
見積もりとコミットメントは同じではない。
:見積もり:プロジェクトにかかる期間やコストを予測すること
:ターゲット:実現したいビジネス上の目標を明文化したもの
:コミットメント:定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束

!確率論としての見積もり(p7)
""

パーセント角度とシングルポイントの見積もりの値とを併用して、「24週間のスケジュールで完了する確度は90%のように用いる

!「良い」見積もりの実務的な定義(p15)
""

良い見積もりとは、プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで、適正な意思決定ができる明確な視点を提供する見積もりである。

!!第3章　正確な見積もりの価値

!パーキンソンの法則(p24)
作業は使用可能な時間を使い尽くすまで拡大する

!過大見積りと過小見積もり(p27)
過大見積りはパーキンソンの法則に起因する直線的な不利益（工数、コスト、スケジュール増）だが、過小見積もりの不利益は直接的でなく限界がないので深刻。

!ソフトウェア業界の構造的な問題(p30)
業界のデータから、ソフトウェア業界には過小見積もりの問題がある。

!正確な見積もりの利点(p31)
*状況の可視化が進む
*品質が向上する
*ソフトウェア以外の業務部門との連携が良くなる
*予算が良くなる
*開発チームに対する信頼が向上する
*早期にリスク情報が得られる

!予測可能性の価値(p33)
経営陣はコスト、スケジュール、機能を知りたい。
実現する機能を数パターン検討してコミットできるスケジュールのばらつきを比較できるように図示することで、ばらつきの少ない選択肢を承認してもらいやすい。

!!第4章見積もり誤差はなぜ起きる？

!不確実性のコーン(p40)
プロジェクトスコープ（工数、コスト、機能）の見積もりにおけるばらつき（最大見積もりと最小見積もりの区間）は、初期コンセプト、製品定義の承認、要求の完了、ユーザーインターフェース設計の完了、詳細設計の完了、ソフトウェアの完了と時期でばらつきが狭まってコーンの形を作る。

プロジェクトからバラつきの原因を取り除いてコーンを狭くしよう。

!不確実性のコーンとコミットメントの関係(p45)
見積もり誤差が２０％以内であればプロジェクトを完了に向けてナビゲートできる。コーンが初期の広い部分では、有意義なコミットメントは不可能。コーンを狭くする作業を終えるまでコミットメントを遅らせる。

!不安定な要求(p47)
要求が安定しない場合は不確実性のコーンは狭くならない。要求変更はトラッキングされないことが多く、再見積もりすべきなのにされない。要求が安定できない状況では反復型、スクラム、XP、DSDMなどの開発手法を検討する。

!アクティビティの見落とし(p49)
*セットアップ/インストールプログラム
*データ変換ユーティリティ
*サードパーティやオープンソースソフトウェアを使うためのグルーコード
*ヘルプシステム
*配置モード
*外部システムとのインターフェース

!!第6章　見積もり技法入門

!プロジェクトの規模(p85)
:小規模:5人以下。実際に作業を行うここのメンバーが作成する見積もりを元にプロジェクトの見積もりを作成するボトムアップ技法が最適。
:大規模:半年から一年以上継続する25人以上。初期はトップダウン技法、中期以降は組み合わせ。
:中規模:5人から25人。

!!第7章　数えて、計算して、判断する
見積もりの基本は数えること。数えられない場合は計算する。それもできないときのみ判断する。

!何を数えるか？(p91)
p93表7-1に以下の数えたデータの使用例がある。この表のデータを収集することで、過去のデータとして工数の見積もりなどの計算に使うことができる。
*初期
**マーケティング要求
**機能
**ユースケース
**ストーリー
*中期
**エンジニアリング要求
**ファンクションポイント
**変更要求
**Webページ
**レポート
**ダイアログボックス
**スクリーン
**データベーステーブル
*後期
**書きあがったコード
**欠陥指摘数
**クラス
**クラスタ

*見積もり対象のソフトウェアの規模と関連性が高いものを探す
*開発サイクルの早い時期に手に入るものを探す
*統計的に意味のある（数が大きいもの）平均値を出せるものを探す
*何を数えているのか理解する
*最小の労力で数えられるものを探す

!!第8章　補正と過去のデータ

!収集するデータ(p101)
*規模（コード行数など）
*工数（人月）
*時間（カレンダー月）
*欠陥（重要度によって分類されたもの）

!規模の測定方法を決める必要がある
*コードの数え方（リリースコードだけかどうかなど
*再利用コードの扱い
*ブランク行、コメント行
*クラスインターフェイスを数えるか
*データ宣言

!工数の測定方法を決める必要がある
*時間の単位
*1日何時間か？
*サービス残業を数えるか
*休日、休暇、ミーティング
*どんな種類の工数を数えるのか（要求、設計、調査、
*複数のプロジェクトの数え方
*過去のリリースのサポート時間
*展示会などのサポート時間
*移動時間
*下準備のあいまいな時間、

!プロジェクトが終わったらできるだけ早くプロジェクトの過去のデータを収集する
進行中にも収集する。規模と工数と欠陥について１～２週間ごとにデータを収集すると有益。