コード品質を計測して、コードの完成までを見積もるための考察 | Moonmile Solutions Blog
コードの完成までを見積もるための考察(2) | Moonmile Solutions Blog
の続きです。
マネジメント的に 80% の合格ラインを目指すためには、どの値から計算をしていけばよいでしょうか？という問題です。
TOC/CPPM 的には、50% の見積りを最初に出します。そして確率的にプロジェクトバッファを 50% ほど取ることのなるのですが、この「50% の確率」で見積もるのは結構難しいことが分かっています。
どうして難しいかというと、
・楽観的な人に見積をしてもらうと、リスクを含めないで理想的な日数が出てきて過小見積りになる。
・悲観的な人に見積をしてもらうと、リスクを含めた日数がでてくるので過大見積りになる。
というわけで、中央の5分5分の位置というのは結構難しいのです。なので、方法としては、
・楽観的な人の見積と、悲観的な人の見積を足して 2 で割る。
のような見積をしたり、
・楽観的な人の見積の 2 倍を予想期間として見積もる
という方法を取ったりします。実際のところは、後者の「楽観的見積×2」というのが経験的に現実に非常に合います。
ならば、経験的にやりやすい方法かつ現実に即した方法を取るように、楽観的な見積＝理想日数を基準にして期間見積を出すとよいのでは？と考えてみます。
(理想日数 + タスク件数 x 不具合率 x 日数) x 80%確率
になればよいわけです。ちなみに楽観的な人の見積を基準にすると、
理想日数 x 2
楽観的と悲観的見積を足して2で割ると
(理想日数 + (理想日数 + リスク発生)) / 2
この中で不確定値が少ないほうが、数式が正確になります。ただし、変数が少なすぎると最初の予想が間違っている場合は、ずれが大きくなりますね。リスク発生による日数が、理想日数の2倍と同じになると、楽観的見積からの計算と同じになります。つまりは、楽観的な見積の約3倍が悲観的な見積が、常識的なラインということでしょうか。こうなると、個人によって見積に差が出るのは当然な気がします。
ある意味、「理想日数 x 2」では、理想日数（最速でコーディングができる日数）の部分は、出せることが多いのですが、「x2」の根拠はどこから？というのがあります。まあ、経験上の x2 なので、根拠があるような無いような数値ですね。
先のシミュレートの場合は、理想日数 200 日間になるので、予想期間が 400 日間になります。シミュレートの結果よりも大幅に多いのは、不具合率が少なすぎるか、不具合修正の日数が過小すぎるか、このシミュレートが現実を表していないか、ということになるのですが。まぁ、現実よりも十分すぎるほど楽観的なモデルなのは確かですが。
さて、不具合率と不具合を直す日数の予想がつけば、それを入力値にしてシミュレーションをすることが可能です。
試しに、不具合率を 0.1, 0.3, 0.5 で計算すると「(理想日数 + タスク件数 x 不具合率 x 日数) x 80%確率」の値は次のようにシミュレートできます。
0.1: 226 日間
0.3: 298 日間
0.5: 420 日間
0.1 というのは、試験 10 件のうち 1 件に不具合が発生がする、という意味なので、0.5 の場合は 2 件に 1 件という値ですね…非常に品質の悪い状態。このシミュレーションでは不具合修正に対しても不具合が発生するという複利的な確率になるので、不具合率が増えると予想期間は自乗に比例して延びます。これを、先の理想日数 x2 と比較すると、このシミュレーションでは 0.5 弱ぐらいがうまくマッチングします。
逆に言えば、不具合率を 0.5 より下回れば、理想日数 x2 となる予想日数よりも早く終わる可能性があるわけです。
また、試験を開始して 0.3 という確率で不具合がでているならば、300 日以内に終わる確率が 80% という予想が立てられます。まぁ、実測値からの予想は、シミュレーションをするよりも、実測の不具合率 x 実測の不具合修正日数から予想を立てるほうが、良いとは思いますが。
ここで「不具合」という言葉を使っていますが、実は、
・設計にあわない不具合（コーディングが間違っている）
・設計そのものが間違っている不具合（業務にそぐわない）
の２種類がありますが、それのどちらも含めます。どちらも「直さなければいけない修正」なので、あらかじめ修正のための日数として取っておくほうが良いと思っています。
これは、設計書に 100% 忠実に沿うようにしても、不具合が 0 件にはならないことを示していて、そうであるならば、
・設計書に 80% 忠実にコーディングをする。
ことによって、設計書に沿うための労力を減らして、その分の余力を 2 種類の不具合対処にまわすというやり方です。
