【工数見積】工数見積もりについて

はじめに

 * 業務で見積りを行ったのだが、体系的に学んだことはなかったので、まとめてみる
 * 見積り一つで、そのプロジェクトが成功するか破たんするかが決まるので超重要。
 * 当たり前のことだが工数があればあるだけいいに決まっており、
  バッファーを積みすぎて出しても、管理(特に経営)にかかわる人間には納得しないので
   根拠がある見積もりを行わなくてはならない
 * 経験での見積りだと、他の人間には納得しない(正しいと判断できる材料に乏しい)ので
   見積経過・根拠がわかるような見積もりを行わなくてはならない

見積もり手法

 * 様々な見積り手法をみていく。

[1] KKD法(勘・経験・度胸)

 * エンジニアの経験と勘に頼った見積もりのこと
   (なんだかんだ言って、他の手法も、KKD法にどうやって根拠を持たせるかであって
    最終的には勘や経験で見積もっている気がする)

[2] 類推法

 * 今までの経験や過去の類似プロジェクトでの実績をベースに見積もる方式
 * 「以前、同じようなプログラムを開発した」
   「別のプロジェクトで、類似ソフトウェアを作っていた」という過去の事例を基に見積もる方式
 * ある種、KKD法?

利点

 * 簡単に見積もることが可能
 * ソフトウェアの詳細機能が固まっていない初期段階で威力を発揮

欠点

 * 客観性の欠如(根拠に乏しい)
 * 事例がないと見積もることができない

参考文献

http://monoist.atmarkit.co.jp/mn/articles/1108/23/news003.html

[3] 積み上げ法、積算法、WBS法(Work Breakdown Structure)

 * 実施する作業を出来るだけ細分化(ブレイクダウン)して個々のタスクについて見積りを行った後、
  それをすべて合計する事で全体の工数とする見積り手法

 * 積み上げ法による規模見積もりは、以下の2種類。
  [3-1] LOC(Line Of Code;行数)見積もり/SLOC(Source Lines Of Code)
  [3-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

[4] 積み上げ法:LOC見積もり

手順

 [1] 開発するソフトウェアを通常の設計時と同じ方法で機能の分解や詳細化を進め、
     小さいモジュールに分割
 [2] 各モジュールのステップ数を合計
 [3] その総ライン数を、一人当たりの生産性(例えば、ステップ数/月)で割り算して人月を計算し、
     コスト・必要人数を出す

欠点

 * ライン数を割り出すのが主観的
 * (個人的な意見だが)ライン数はシステム規模の一つの指標にはなると思うが
   絶対的なものではないと思うので見積もりづらい
 (昔ならまだしも、フレームワークなどを使う現代の開発では、ライン数だけじゃ見積もりづらいのでは?)

[5] 積み上げ法:FP見積もり

 * 詳細は以下の関連記事を参照のこと
http://blogs.yahoo.co.jp/dk521123/33918780.html

[6] パラメトリックス法

 [6-1] SLIM(Software Life Cycle Management)

参考文献

http://monoist.atmarkit.co.jp/mn/articles/1112/22/news005.html

[7] CoBRA法(Work Breakdown Structure)

 * 次の仮説に基づいてコストを算定する

仮説(1):変動要因の存在しない理想的な状態においては、開発コストは開発規模に比例する。
仮説(2):現実のソフトウェア開発においては、開発コストを増加させる複数の変動要因が存在し、
     その影響度の総和だけ開発コストが増加する。

(工数 E)=a×Size×(1+∑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

[8] プランニング ポーカー

 * チームの開発者全員で担当する機能を見積もる時、
  プランニングポーカー(フィボナッチ数列に基づくカード。1、2、3、5・・・。)を出し合って、
  見積もる参加型の見積もり技法。

手順

[1] 作業を行うメンバーを集め、それぞれにプランニングポーカーカードを配る
[2] それぞれのタスクに対して開発を担当するメンバーが思いのままに数字のカードを出し合う
[3] メンバーがそれぞれ提示したポイントについてお互いに根拠を述べ合う
[4] 各メンバーの考えをシェアすることで、一人で考えている時には漏れていたかもしれない工夫や懸念材料を洗い出す
[5] ディスカッションを終えたら、再度カードを出し合う
[6 ] このサイクルを2、3回繰り返す
 → 全員がある程度、納得できる見積もりを出すことができる

分かりやすい説明

http://www.ryuzee.com/contents/blog/4664
http://enterprisezine.jp/iti/detail/3385

プランニングポーカー簡単ガイド

http://f.hatena.ne.jp/wayaguchi/20120218091121

プランニングポーカー

http://congasoft.com/wp/wp-content/uploads/2014/04/planning_poker.pdf

正確な見積もりを作成するには

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

関連記事

工数見積もりについて

http://blogs.yahoo.co.jp/dk521123/33505512.html

ファンクションポイント(FP)法

http://blogs.yahoo.co.jp/dk521123/33918780.html