システム企画（要求定義）段階での見積もり

見積はシステム開発を実施する前に一度行えばいいのでしょうか？

そうではありません。

見積はあるプロジェクト内で繰り返し行われるべきものです。

また、可能であれば複数の手法で複数のメンバーによって複数回行うべきものです。

では、どのようなタイミングでどのような見積を行えばよいのでしょうか？

前述の見積りモデルに基づいて、どのようなタイミングで、どのように見積りを実施していくのかについて説明します。

まず、システム企画（要件定義）段階では、業務フロー図を作成し、大まかにどのような画面がいくつ必要なのか、帳票がいくつ必要なのかを整理します。

画面数や帳票数、バッチ処理数がわかったら、その数にある考え方で係数を乗じることにより規模の見積りを実施します。

この段階で、複雑度を考慮して重み付けを変えるという方法もありますが、私の場合は重み付けの基準が明確でないかぎり実施しません。（⇒一律の係数を適用します。）

では、どのような考え方で係数を乗じるのかということですが、まず処理をいくつかのパターンに分けます。

その処理ごとに基本的な処理パターンを考えて、「こういう処理であれば、このくらい」ということを決めていきます。

私の場合は、基本的にファンクションポイント（以下ＦＰ）を係数のベースにすることが多いので、ＦＰに置き換えて見積もりを行います。

まず、処理のパターンわけですが、細かく分けることもできますし、大まかに分けることもできますが、私の場合は以下のパターンに分類します。
①画面入力系プロセス
②画面照会系プロセス
③帳票出力系プロセス
④バッチ更新系プロセス　　　の４つです。

これらをさらに詳細に分類することもあります。画面入力系プロセスを、マスタ更新系プロセス、伝票入力系プロセス、グリッド入力系プロセス細分化するなど・・・です。

しかし、あまり細かく細分化して分類しても、実際にはあまり見積もり規模に大差はないため、分類のための手間がかかるだけという結論で、上記のような４つのタイプに大まかに分けることにしています。

各処理パターンごとの規模の考え方ですが、
①画面入力系プロセス
②画面照会系プロセス
③帳票出力系プロセス
④バッチ更新系プロセス　ごとに処理パターンを考えてその処理パターンであれば、このくらいの規模になるという係数を求めます。

例えば、以下のような考え方です。

◆データ更新を行う画面については、登録、変更、削除の各更新処理が存在するものと想定する。

==>データ更新処理（ＥＩ）は登録、更新、削除の３種類が存在する。
この段階では、複雑度は評価することができないため、複雑度は”Ａ：Average”とする。
ＦＰ法ではＥＩの複雑度”Ａ：Average”のポイント数は、４のため
データ更新画面の係数＝４（ＦＰ）×３（更新処理）＝１２

となり、業務フロー図を作成して整理した業務機能（プロセス）のうち、画面入力系プロセスに対して１２を乗じることにより、概算のＦＰ値とします。

以下、同様の考え方で、画面照会系プロセス、帳票出力系プロセス、バッチ更新系プロセスについても、係数を想定します。

業務フロー図を記述することにより、画面入力系プロセス、画面照会系プロセス、帳票出力系プロセス、バッチ更新系プロセスがそれぞれ何個存在するかは識別することができますので、それぞれのプロセスタイプの総計にそれぞれのプロセスタイプの係数を乗じることにより、概算の規模を算出します。

ここでは、システム企画（要件定義）段階での概要見積りについて、記述してきましたが、設計が進んでいくに従って、見積りに利用できる情報が増加してきます。

次回は、もう少し設計が進んだ段階での見積もり方法をご説明します。