開発プロセス業務としてソフトウェアを開発するならば、工数の見積もりは避けては通れない。見積もりは、ソフトウェア開発プロセスのはじめの一歩に過ぎないが、その成否はプロジェクト全体の命運を握ることになる。プロジェクトに焦燥と混乱をもたらすことなく、堅実に開発を進めていくためには、正確で具体的な見積もり手法が求められる。知られた見積もり手法の1つに、ファンクションポイント法がある。外部との入出力に着目して、ソフトウェアの機能から工数を見積もるファンクションポイント法は、有効な見積もり手法である。実際のソフトウェア開発の現場では、ファンクションポイント法で見積もりを行っているケースは多くはない。その原因の1つには、ファンクションポイント法を使うためには、入出力を定めたモデルの作成や、ポイントの計算方法など、専門的な知識と技能が必要なことが挙げられる。小規模なソフトウェア開発では、見積もりのしやすさも重要になってくる。ここでは、ファンクションポイント法より簡潔で、直観的で、実利的な見積もり手法として、「やることリスト」に基づく手法を提案する。「やることリスト」とは何かまず初めに、「やることリスト」とは何か、を説明しておこう。ソフトウェア開発の目的はプログラムを組むことだが、いきなりコーディングを開始することはあり得ない。ソフトウェアにどのような機能を持たせるか、それらの機能をどのように実現するか、手を動かす前にまず頭を働かせることから始まる。「やることリスト」とは、頭を働かせて考えるにあたって、具体的に何について考えるべきか、何を決めなければいけないか、というポイントを洗い出し、箇条書きにしたものである。考えた結果は、機能仕様書や設計書などの文書としてまとめることになる。「やることリスト」とは、これらの文書に書くべき項目のリスト、と言い換えることもできる。「やることリスト」に基づく見積もりの手順は、次の通りである。「やることリスト」を作成する文書のページ数を予想する開発プロセスの工程ごとに工数を見積もる「やることリスト」を作成するまず初めは、「やることリスト」を作る。思いつく限り洗い出す。この段階で機能仕様書や設計書に書く内容がすべて網羅できているくらい、徹底的に洗い出すことが望ましい。個数に掛けることで、機能仕様書と設計書のページ数を予想する。開発プロセスの工程ごとに工数を見積もる最後に、予想ページ数を基に、開発プロセスの工程ごとに工数を見積もる。工程ごとの工数を見積もる方法は、ウォーターフォール型開発モデルのV字型モデルに基づいている。ソフトウェアテストの分野では、ウォーターフォール型開発モデルにおける開発工程と品質保証との関係を、下図のようなV字型モデルで表す。ここでは比較的小規模なソフトウェア開発を想定しているので、工程を簡略化し、次のように考える。図には、各工程での成果物も付記した。V字の左側(前半)は品質を作り込むフェーズ、右側(後半)は品質を確認するフェーズである。左右で同じ高さにある工程どうしは、左側の工程で作った品質を、右側の工程で確認する、という関係にある。このV字型モデルを基に、工程ごとの工数を見積もる方法を説明する。要求分析この工程の成果物である機能仕様書のページ数は、すでに予想した。要求分析の工数は、機能仕様書を書き上げるのに要する時間を、ページ数から直接推定する。矛盾なく、使いやすいソフトウェアの機能仕様を考える時間と、執筆に要する時間を考慮する。顧客に機能を確認してもらうレビューの工数も忘れずに含める。設計この工程の成果物である設計書のページ数は、すでに予想した。設計の工数は、設計書を書き上げるのに要する時間を、ページ数から直接推定する。ソフトウェアの構造やクラス設計、アルゴリズム等を考える時間と、執筆に要する時間を考慮する。実装ソフトウェアの実装とは、設計工程で文書化した仕組みを、プログラミング言語を使って表現し直す作業である。実装にかかる時間は、設計にかかる時間に比例する。経験から求めた係数を掛けて、設計工程の工数から実装工程の工数を算出する。係数は、1.0と考えても構わない。単体テストV字型モデルが表すように、単体テストは設計の確認を行う工程である。単体テストにかかる時間は、設計にかかる時間に比例する。経験から求めた係数を掛けて、設計工程の工数から単体テスト工程の工数を算出する。係数は、1.0と考えても構わない。機能テストV字型モデルが表すように、機能テストは要求分析の確認を行う工程である。ソフトウェアが実現する機能は、機能仕様書に書かれている。機能テストでは、それらについて確認を行う。機能仕様書とは、機能テスト項目を文章で書いたものと見なしても良い。機能テストにかかる時間は、機能仕様書のページ数に比例する。経験から求めた係数を掛けて、機能仕様書のページ数から機能テスト工程の工数を算出する。工程ごとの工数を見積もる方法をまとめると、下図のようになる。[ファンクションポイント法]には、ファンクションポイント法の特徴として、次のような記述がある。ファンクションポイント法は、プログラミングフェイズに入る前にユーザー要件が定まり、必要な機能が見えてきた段階でシステム規模を概算することができるという特徴がある。プログラミングに入る前に、必要な機能が見えてきた段階で見積もりができる、という点は、「やることリスト」に基づく手法でも同じである。どちらの手法も、最初に定めた要件定義が、ソフトウェア全体の工数を決める。最初に要件定義を定めて、それに従って開発を進めるウォーターフォール型の開発には適している。ファンクションポイント法との違いは、工数を見積もるための指標となる「規模」の捉え方にある。ファンクションポイント法では、ソフトウェアの姿(モデル)を構築し、そこから算出したソフトウェアの大きさが、工数を見積もるための指標となる。「やることリスト」に基づく手法では、担当者が考えるべき作業項目を洗い出し、そこから推定した文書作成に要する作業量が、全体の工数を見積もるための指標となる。モデル化という困難な作業は必要ないファンクションポイント法では、工数を見積もるためには、外部との入出力に着眼してソフトウェアの構造をモデル化する必要がある。ソフトウェアのモデルを構築するのは、簡単ではない。モデルを構築する作業そのものにも、それなりの工数をかける必要がある。これは、小規模なソフトウェア開発では、無視できなくなってくる。20人月の開発プロジェクトでは、見積もりのために概要設計を考えておおよそのモデルを構築するのに、仮に1週間かけたとしても、全体の1%でしかない。1人月のプロジェクトでは、仮に3日ほどで大雑把にモデルを構築できたとしても、それだけで全体の15%も消費してしまうことになる。「やることリスト」に基づく手法では、概要設計にすら着手する前の、作業計画の段階で見積もりを行う。考えるべき項目を洗い出すだけなら、モデルを構築するよりも早く、1日もあれば済ませられるだろう。工数を直観的に推定できるファンクションポイント法で算出される値は、ソフトウェアの規模を表すポイントである。工数の見積もりのためには、このポイントに係数をかけて、工数に換算しなくてはならない。この係数によって、いわば機能を工数に変換するのだが、正確な値を求めるのはかなり難しい。それは、機能と工数という異なる尺度を対比させているためだ。1ポイントが何人月に当たるかは直観的には分からない。そこで、ファンクションポイント法を正式な見積もり手法として導入する前に、ファンクションポイント法で規模を見積もったソフトウェア開発の実例を数多く積み重ねて、係数を導き出すという準備が必要になる。「やることリスト」に基づく手法でも、係数は必要となる。基になる指標は文書のページ数である。1ページを書くのにどれくらいかかるかは、直観的に分かりやすい。ページ数から工数を算出する係数は、数値に基づく効果的なプロジェクトレビューを行えば、簡単に見出すことができるだろう。プロジェクトの軌道修正をしやすいソフトウェア開発プロジェクトを進めている途中で、当初のスケジュールからずれが生じることがある。その場合は、改めて詳細な見積もりを行い、全体のスケジュールを見直す必要がある。ファンクションポイント法でも、プロジェクトが進むに応じてソフトウェアのモデルを詳細化し、規模と工数をより正確にしていく、ということは行われる。詳細なモデルを構築する、という作業が必要になる。詳細なモデルを基に、改めてポイントを算出する必要もある。そのため、見直しにもかなり時間がかかることになる。スケジュールにずれが生じているケースでは、たいてい余裕がない。そのため、ファンクションポイント法のような大仰な手法による見直しの時間は確保できないこともあるだろう。「やることリスト」に基づく手法では、文書が完成した時点で実際のページ数を基に見直したり、作業項目の増加分を反映させたり、設計と実装の比率を調整したりなど、プロジェクトの進捗状況に応じて、柔軟な見直しが可能である。見直しのために改めて準備することもないため、スケジュールが厳しい状況でも、わずかな時間を割くだけでプロジェクトの軌道修正が可能である。個人差を見込みやすいファンクションポイント法のベースとなるソフトウェアのモデル化には、高度な専門的技能が必要である。そのため、ファンクションポイント法による見積もりは、個々の作業担当者ではなく、特定の上級者が行うことになる。そのため、実際に作業を行う担当者のスキルや、過去の経験の有無による作業効率などによる個人差を見積もらなくてはならない。既存ソフトウェアの改造や機能追加において、経験による個人差の影響は大きいが、それを他者が正確に見積もることは困難である。「やることリスト」に基づく手法では、それぞれの作業担当者が、自分が作成する文書のページ数を予想して、それを基に工数を見積もる。担当者は、過去に経験があり良く知っている作業であれば、新たに作り込む機能についてしか、設計書には記述しないであろう。知らない箇所を担当することになれば、該当部分の仕組みについても広く調査し、結果を文書にまとめるため、記述量は多くなる。個人差の影響は、作成される文書のページ数に表れる。そこから導かれる工数の見積もりも、個人差を見込んだものとなる。下記の2つのソフトウェア開発を対象に、「やることリスト」に基づく見積もり手法の有効性を検証した。「やることリスト」に基づく手法では、作成する文書のページ数を基に工数を見積もる。これは、ソフトウェアの規模や、開発に要する工数は、ページ数に比例する、という前提に基づいている。実装工程と単体テスト工程の工数は、設計工程の工数を基に算出した。テストの工程に要する工数の比率は、つねに一定である、という前提に基づいている。前述の2つのソフトウェア開発において、数値に基づく効果的なプロジェクトレビューを行い、これらの2つの前提が正しいか検証した。2つのソフトウェア開発プロジェクトの比較結果は、表の通りであった。ここでは、データ処理を行うライブラリの作成を基準として示す。4.1モジュール数とは、C言語の場合は関数、C++言語の場合はクラス数とした。テストに要した工数である。どの項目でも、2つのソフトウェア開発プロジェクトの比率は、4前後となっている。ページ数が、ソフトウェアの規模や、開発に要する工数の指標として利用できることを表している。テストの比率は、表の通りであった。ここでは、それぞれのソフトウェア開発プロジェクトにおいて、設計に要した時間を基準として示す。テストの工程に要する工数の比率は、約1:1:1で一定であった。テストの工数の比率は、1:1:1と考えても良いとした。これは、上記の結果に基づいている。技術コラムオブジェクト指向デザインパターン開発プロセスプログラミングソフトウェアプログラミングユーティリティ天文マニュアル。