「やることリスト」に基づく見積もり手法

「やることリスト」を作成する

まず初めは、「やることリスト」を作る。ソフトウェアの機能項目・設計項目を思いつく限り洗い出す。この段階で機能仕様書や設計書に書く内容がすべて網羅できているくらい、徹底的に洗い出すことが望ましい。

文書のページ数を予想する

次に、１項目あたりの平均的なボリュームを推定し、洗い出した機能項目・設計項目の個数に掛けることで、機能仕様書と設計書のページ数を予想する。

開発プロセスの工程ごとに工数を見積もる

最後に、予想ページ数を基に、開発プロセスの工程ごとに工数を見積もる。

工程ごとの工数を見積もる方法は、ウォーターフォール型開発モデルのＶ字型モデルに基づいている。

ソフトウェアテストの分野では、ウォーターフォール型開発モデルにおける開発工程と品質保証との関係を、下図のようなＶ字型モデルで表す。

ここでは比較的小規模なソフトウェア開発を想定しているので、工程を簡略化し、次のように考える。図には、各工程での成果物も付記した。

Ｖ字の左側（前半）は品質を作り込むフェーズ、右側（後半）は品質を確認するフェーズである。左右で同じ高さにある工程どうしは、左側の工程で作った品質を、右側の工程で確認する、という関係にある。

このＶ字型モデルを基に、工程ごとの工数を見積もる方法を説明する。

工程ごとの工数を見積もる方法をまとめると、下図のようになる。

工数の指標となる「規模」の捉え方が違う

＠IT情報マネジメント用語事典 [ファンクションポイント法]には、ファンクションポイント法の特徴として、次のような記述がある。

ファンクションポイント法は、プログラミングフェイズに入る前にユーザー要件が定まり、必要な機能が見えてきた段階でシステム規模を概算することができるという特徴がある。

プログラミングに入る前に、必要な機能が見えてきた段階で見積もりができる、という点は、「やることリスト」に基づく手法でも同じである。

どちらの手法も、最初に定めた要件定義が、ソフトウェア全体の工数を決める。即ち、最初に要件定義を定めて、それに従って開発を進めるウォーターフォール型の開発には適している。

ファンクションポイント法との違いは、工数を見積もるための指標となる「規模」の捉え方にある。

ファンクションポイント法では、ソフトウェアの姿（モデル）を構築し、そこから算出したソフトウェアの大きさが、工数を見積もるための指標となる。

一方、「やることリスト」に基づく手法では、担当者が考えるべき作業項目を洗い出し、そこから推定した文書作成に要する作業量が、全体の工数を見積もるための指標となる。

モデル化という困難な作業は必要ない

ファンクションポイント法では、工数を見積もるためには、外部との入出力に着眼してソフトウェアの構造をモデル化する必要がある。

だが、ソフトウェアのモデルを構築するのは、簡単ではない。モデルを構築する作業そのものにも、それなりの工数をかける必要がある。これは、小規模なソフトウェア開発では、無視できなくなってくる。

例えば、20人月の開発プロジェクトでは、見積もりのために概要設計を考えておおよそのモデルを構築するのに、仮に１週間かけたとしても、全体の１％でしかない。

だが、例えば１人月のプロジェクトでは、仮に３日ほどで大雑把にモデルを構築できたとしても、それだけで全体の１５％も消費してしまうことになる。

「やることリスト」に基づく手法では、概要設計にすら着手する前の、作業計画の段階で見積もりを行う。考えるべき項目を洗い出すだけなら、モデルを構築するよりも早く、１日もあれば済ませられるだろう。

工数を直観的に推定できる

ファンクションポイント法で算出される値は、ソフトウェアの規模を表すポイントである。工数の見積もりのためには、このポイントに係数をかけて、工数に換算しなくてはならない。

この係数によって、いわば機能を工数に変換するのだが、正確な値を求めるのはかなり難しい。それは、機能と工数という異なる尺度を対比させているためだ。１ポイントが何人月に当たるかは直観的には分からない。そこで、ファンクションポイント法を正式な見積もり手法として導入する前に、ファンクションポイント法で規模を見積もったソフトウェア開発の実例を数多く積み重ねて、係数を導き出すという準備が必要になる。

「やることリスト」に基づく手法でも、係数は必要となる。だが、基になる指標は文書のページ数である。１ページを書くのにどれくらいかかるかは、直観的に分かりやすい。ページ数から工数を算出する係数は、数値に基づく効果的なプロジェクトレビューを行えば、簡単に見出すことができるだろう。

プロジェクトの軌道修正をしやすい

ソフトウェア開発プロジェクトを進めている途中で、当初のスケジュールからずれが生じることがある。その場合は、改めて詳細な見積もりを行い、全体のスケジュールを見直す必要がある。

ファンクションポイント法でも、プロジェクトが進むに応じてソフトウェアのモデルを詳細化し、規模と工数をより正確にしていく、ということは行われる。だが、より詳細なモデルを構築する、という作業が必要になる。また、詳細なモデルを基に、改めてポイントを算出する必要もある。そのため、見直しにもかなり時間がかかることになる。

スケジュールにずれが生じているケースでは、たいてい余裕がない。そのため、ファンクションポイント法のような大仰な手法による見直しの時間は確保できないこともあるだろう。

一方、「やることリスト」に基づく手法では、文書が完成した時点で実際のページ数を基に見直したり、作業項目の増加分を反映させたり、設計と実装の比率を調整したりなど、プロジェクトの進捗状況に応じて、柔軟な見直しが可能である。見直しのために改めて準備することもないため、スケジュールが厳しい状況でも、わずかな時間を割くだけでプロジェクトの軌道修正が可能である。

個人差を見込みやすい

ファンクションポイント法のベースとなるソフトウェアのモデル化には、高度な専門的技能が必要である。そのため、ファンクションポイント法による見積もりは、個々の作業担当者ではなく、特定の上級者が行うことになる。そのため、実際に作業を行う担当者のスキルや、過去の経験の有無による作業効率などによる個人差を見積もらなくてはならない。

特に、既存ソフトウェアの改造や機能追加において、経験による個人差の影響は大きいが、それを他者が正確に見積もることは困難である。

一方、「やることリスト」に基づく手法では、それぞれの作業担当者が、自分が作成する文書のページ数を予想して、それを基に工数を見積もる。

担当者は、過去に経験があり良く知っている作業であれば、新たに作り込む機能についてしか、設計書には記述しないであろう。一方、あまり知らない箇所を担当することになれば、該当部分の仕組みについても広く調査し、結果を文書にまとめるため、記述量は多くなる。

個人差の影響は、作成される文書のページ数に表れる。そこから導かれる工数の見積もりも、個人差を見込んだものとなる。