ここ３年ぐらい同一案件のアジャイル的な開発をやっているのですが、 見積もりについて経験則がまとまってきたので整理してみたいと思います。

まず、前提として以下のような作業を請け負っています。

• 顧客の要望を聞いて要件開発を行う
• 要件を元にシステムの設計を行う
• 設計を元にプログラムの製造を行う
• テストを行う
• 運用時に発生した障害の調査

開発は１期のスパンが２か月～３か月程度で、 開発した機能のリリースを行いながら順次機能拡張していくといった感じになります。

作業の見積もりはその作業の種別により分類されます。 建築での比喩で表現すれば、大きく分けると設計図面を引く前と引いた後です。 これに加え、突発的な飛び込み作業があるので、以下の３つに分類しています。

• 設計図面を引くまでの作業
• 引いた図面をもとに開発する作業
• 突発的に発生する作業

そして、それぞれの作業ごとに不確定要素（リスク）が存在します。

設計図面を引くまでの作業

要件開発の部分では、時間をかければ時間をかけただけ、作るべきモノの設計書(図面と比ゆしたもの)が増えます。 顧客側のいいなりに作業しているとえらく時間を取られる可能性があります。その部分がリスクと言えばリスクでしょう。

しかし、どうせ図面を大量に用意したところで投入人数が決まっているなら１期の開発で消化できる量が 決まっていますから、定量に達したところで開発側主導で中断するべきです。 具体的にはシステムの設計の過程で、ある程度確度の高い見積もりができますから、 積算して定量に達したらそれ以上の設計には着手しないで次回送りにします。

定量が定まっているためか、開発主導で中断できるせいなのか、この過程にかかる時間は 比較的安定していてそれほど大きなブレはありません。

引いた図面をもとに開発する作業

この過程も、それほど開発工数はブレません。 設計の際に洗い出した作業は思いのほか工数を外さないものです。 しかし、怖いのは洗い出しに失敗して、見落としていた作業があった場合。 この、作業の見落としは工数見積もりのブレの中では特に注意すべきポイントだと思います。

一番大きな痛手となるのは、設計が差し戻しになったケース。とても大きな工数を消耗してしまいます。 設計者が用件だけではなくシステムの設計も把握している人材でさえあればこのリスクはかなり低減します。 また、顧客との打ち合わせの仕方次第で仕様のどんでんがえしのリスクは軽減されます。

また、技術的なリスクもあります。 とくにシステムのコアとなる部分など、高度な部分の開発は、やってみてできなかったというケースがあり、 頭数を投入したからと言ってどうにかできるものでもありませんから、締め切りを後ろに伸ばすか、 後の工程を短い期間で無茶してやるかという選択になってしまいます。

といったところを気をつけるとよいでしょう。

突発的に発生する作業

障害対応が主なものです。 こればっかりはいつ出るのかわかったもんじゃありません。 保険の考え方を導入して予備工数を積むしかないでしょう。

製造した機能ごとに算出した工数を予備として積んでおきましょう。 私の方では

(製造にかかった時間 x 複雑さ係数) / (リリース後経過月数 * 調整係数)

といった算出の仕方をしています。時間経過に伴い、障害の発生率は落ちていくとしています。 直前の期でリリースした機能は比較的高い発生率と想定し、古い期にリリースした機能ほど 発生率は低くなるととらえています。

基準となるのは製造にかかった工数としています。 これは設計や仕様書の策定、テストケースの策定、テストの実施を抜いた、 プログラムの製造に関わる作業をてっとり早く定数化する手法です。

FP(ファンクションポイント法)などの規模感を測定する指標を持っているならそれらを利用してもよいでしょう。 ただし、ステップ数は規模感の測定に用いるには誤差が大きすぎるのでそのまま使うのはやめたほうがよい。

ここのリスクばかりは本当にコントロールしきれない。 一時期に集中的にバグが露呈することもあります。 ですが、金融工学に基づく保険の手法に学んで、リスクに対して備えを用意する程度にはあがきましょう。