■ はじめに
業務で見積りを行ったのだが、 体系的に学んだことはなかったので、まとめてみる
【０】見積もりの重要性
* 見積り一つで、そのプロジェクトが成功するか破たんするかが決まるので超重要。 * 当たり前のことだが工数があればあるだけいいに決まっており、 バッファーを積みすぎて出しても、管理（特に経営）にかかわる人間には納得しないので 根拠がある見積もりを行わなくてはならない * 経験での見積りだと、他の人間には納得しない(正しいと判断できる材料に乏しい)ので 見積経過・根拠がわかるような見積もりを行わなくてはならない
【１】KKD法（勘・経験・度胸）
* エンジニアの経験と勘に頼った見積もりのこと
(なんだかんだ言って、他の手法も、
KKD法にどうやって根拠を持たせるかであって
最終的には勘や経験で見積もっている気がする)
【２】類推法
* 今までの経験や過去の類似プロジェクトでの実績をベースに見積もる方式 * 「以前、同じようなプログラムを開発した」 「別のプロジェクトで、類似ソフトウェアを作っていた」 という過去の事例を基に見積もる方式 * ある種、KKD法？
利点
* 簡単に見積もることが可能 * ソフトウェアの詳細機能が固まっていない初期段階で威力を発揮
欠点
* 客観性の欠如(根拠に乏しい) * 事例がないと見積もることができない
参考文献
http://monoist.atmarkit.co.jp/mn/articles/1108/23/news003.html
【３】積み上げ法、積算法、WBS法(Work Breakdown Structure)
* 実施する作業を出来るだけ細分化（ブレイクダウン）して 個々のタスクについて見積りを行った後、 それをすべて合計する事で全体の工数とする見積り手法 * 積み上げ法による規模見積もりは、以下の2種類。 [1] LOC(Line Of Code;行数)見積もり/SLOC(Source Lines Of Code) [2] FP（Function Point）見積もり
欠点
* 要件がある程度固まった段階でないと適用不可
用語：ワークパッケージ
* WBSの構成要素 * プロジェクトマネジメントを行ううえでコントロール可能で、 コントロールすることに意味のある単位として設定されるもの * ワークパッケージは、必要に応じていくつかの アクティビティ（具体的な作業）と仕様が定義され、 責任担当者や実施組織などのリソースが割り当てられる
補足
http://www.nw-system-kaihatsu.com/evaluating_estimation.html
のサイトである通り、「大数の法則(※1)」の観点から、 細分化するほど、論理的な見積もり数値に近づく。
※1：大数の法則(law of large numbers)とは
ある事象(今回は見積もり)に関して、 試行回数(今回の場合、細分化)を増やすほどに、 理論値に限りなく近づくという法則。
参考文献
http://www.itmedia.co.jp/im/articles/0910/13/news131.html
http://www.itmedia.co.jp/im/articles/1001/27/news103.html
面白い経験談(最善な見積り方法は「KKD法＋積み上げ法」っと。一理あると思う)
http://den2sn.hatenablog.com/entry/20120410/1334059041
【４】積み上げ法：LOC見積もり
手順
[1] 開発するソフトウェアを通常の設計時と 同じ方法で機能の分解や詳細化を進め、 小さいモジュールに分割 [2] 各モジュールのステップ数を合計 [3] その総ライン数を、一人当たりの生産性（例えば、ステップ数／月） で割り算して人月を計算し、コスト・必要人数を出す
欠点
* ライン数を割り出すのが主観的 * （個人的な意見だが）ライン数はシステム規模の一つの指標 にはなると思うが、絶対的なものではないと思うので見積もりづらい （昔ならまだしも、フレームワークなどを使う現代の開発では、 ライン数だけじゃ見積もりづらいのでは？）
【５】積み上げ法：FP見積もり
* 詳細は以下の関連記事を参照のこと
http://blogs.yahoo.co.jp/dk521123/33918780.html
【６】パラメトリックス法
* SLIM（Software Life Cycle Management）
参考文献
http://monoist.atmarkit.co.jp/mn/articles/1112/22/news005.html
【７】CoBRA法(Work Breakdown Structure)
* 次の仮説に基づいてコストを算定する 仮説(1)： 変動要因の存在しない理想的な状態においては、 開発コストは開発規模に比例する。 仮説(2)： 現実のソフトウェア開発においては、 開発コストを増加させる複数の変動要因が存在し、 その影響度の総和だけ開発コストが増加する。
式
(工数 E)＝a×Size×(１＋∑COi) * a : 理想的な状態での生産性 * Size : 開発規模(プログラムソース行数、ファンクションポイント etc) * CO : 個々の工数増加要因による増加率
欠点
* 要件がある程度固まった段階でないと適用不可
参考文献
http://www.weblio.jp/wkpja/content/CoBRA%E6%B3%95_CoBRA%E6%B3%95%E3%81%AE%E6%A6%82%E8%A6%81
【８】プランニング ポーカー
* チームの開発者全員で担当する機能を見積もる時、 プランニングポーカー (フィボナッチ数列に基づくカード。1、2、3、5・・・。) を出し合って、見積もる参加型の見積もり技法。 => 詳細は、以下の関連記事を参照のこと
スクラム開発 ～ 見積もり ～
https://dk521123.hatenablog.com/entry/2023/02/04/011603
正確な見積もりを作成するには
http://www.atmarkit.co.jp/ait/articles/0712/18/news151.html
より抜粋 * 漏れのないように機能を洗い出す
現場(？)の技法
「やることリスト」に基づく見積もり手法
http://www.aerith.net/design/easy_estimation-j.html
* 非常にいい方法だと思う
その他
ブルックスの法則
[1] 工数の「人数」と「月数」は交換可能ではない [2] 開発要素の短縮が10％以内の場合、他の開発要素をそれだけ増やす [3] 開発要素の短縮が10％以上の場合、「n2分の1の法則」を適用する
注意点
[1] 開発期間を半分にすると、コストが2倍になる [2] 開発期間短縮すると、品質が悪くなる
参考文献
http://www.s-arcana.co.jp/tech/2011/09/post-51.html
関連用語
工数 / workload
* 作業に従事する人間の数に、かかる時間 * 工数 = 開発規模（サイズ） x 生産性(開発者が熟せる仕事量)
人月
* 一人の人間が一か月働く分の仕事量。 * 1人月＝「一人の技術者が1ヶ月に出来る作業量」
参考文献
http://www.fellow-ship.com/software/ningetsu.html
関連記事
スクラム開発 ～ 見積もり ～
https://dk521123.hatenablog.com/entry/2023/02/04/011603
