5章以降の話は、本格的な規模の大きいプロジェクトでは使えそうだ。しかし、自分の所属する開発チームは7人日程度の工数が最大だ。そのため、あまり5章以降の話ですぐに生かせそうな話題がない。そこで、自分が気になったポイントをピックアップしてここに書いておく。
■見積もりでは「数えて、計算して、判断する」
数える
調査すると言い換えても良い。そもそも、見積もりは分からないものに対して用いる手法であり、調査して分かるのであれば、見積もりよりもずっと望ましい。
数えられるもの
要求の数機能の数、画面数、出力するレポートの種類数など
数えられるもののうち、開発工数と関連が深いものを選んで、数えること。
計算する
数えたものひとつ当たりの工数 × 数えたものの数
判断する
ここで云う判断とは、専門家の経験による見解とでもいうべきものである。これはなるべく用いてはならない。理由は、「即興の見積もりをしない」事と同じで、頼りにならないからである。
■当該開発チームの過去の実績データを参照する
一番良いのは、開発初期の実績データを使う事だが、これは自分のチームの開発だと、開発規模が小さ過ぎて、あまり使えない。実績データが出てから数日でその案件が終わってしまうからだ。しかし、長期化した場合は、その時までにかかった実績時間を元に見積もりを立てるのが良い。開発が初期の見積もりよりも遅れていれば、次の式で計算する。
残作業の初期見積もり ×（完了作業の実績工数 / 完了作業の見積もり工数）
例えば、既に終わった作業が初期見積もりの1.3倍の工数がかかっていれば、今後の作業にも同じだけの係数を掛けて計算する。間違えても「今後の作業はハイペースで進む！」などと想定してはならない。
開発初期の実績データがまだ出ていない状況下では、過去の開発の実績値を参照すること。
■実績データの収集
下記の優先度で収集する。月日が経てば何も分からなくなってしまう。
- プロジェクトの進行中に収集する。
- プロジェクトが終わってなるべく早い時期に収集する。
■見積もり誤差の計算式
自分の見積りの相対誤差の大きさ（MRE：MagnitudeofRelativeError）を計算する（Conte,Dunsmore,andShen1986）。MREの計算には次の公式を使用する。(Kindleの位置No.2352-2353)
MRE = (実際の結果 - 見積もり結果) ÷ 実際の結果
実績をベースにフィードバックループを作り、長期的に見積もりを改善すること。
■大数の法則の利用
複数の小さな見積もりを作って足すと、大き過ぎる見積もりと小さすぎる見積もりが打ち消し合って、全体としての見積もり精度が改善する。これを大数の法則と呼ぶ。大数の法則の恩恵を受けると良い。この法則の恩恵を受けるには、5～10個の見積もりが要る。
■アクティビティの計上漏れを防ぐには？
アクティビティの一覧を作ると良い。過去の実績データからアクティビティを取り出して一覧にしておき、今後の開発プロジェクトを見積もる時に参照する。こうすることで、「アクティビティを思い付かなかった」「検討し忘れた」という事態を防げる。
つまり、アクティビティも記録していく必要がある。
改修時の影響範囲についても、記録を取っていくことで、影響調査漏れを防げるかもしれない。
■レビューによる精度の向上
以下の手順で実施する。
- 複数の専門家が個別に、互いに相談せずに見積もりを行う。
- 出した見積もりを持ち寄り、互いの相違点について話し合い、見積もり幅の上端と下端を決める。
上記手順「2.」の中で、以下を実施してはならない。
- 単純に持ち寄った見積もりの平均を取る。
- 投票で決める。
このレビューにより、一人で見積もりを取った時に比べ、見積もり誤差を約半分に減らす事ができる。
