 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||||||
|
||||||||||||||||||||
| 見積手法の種類（2） | ||||||||||||||||||||
|
|
||||||||||||||||||||
| ファンクションポイント法 | ||||||||||||||||||||
|
図2は、PYRAMIDで用意している「ファンクションポイント法」をベースにした見積テンプレートです。ファンクション法の特徴は、ファンクションポイントという共通の指標で開発規模を表すことです。アプリケーションを「データファンクション」と「トランザクションファンクション」に分類して、ファンクション数をカウントし機能ごとのファンクションポイントをかけて、総ファンクションポイントを求めています。 簡単に言えば、データファンクションはファイル数、トランザクションファンクションは画面や帳票・バッチなどの処理プロセス数を表します。 |
||||||||||||||||||||
 図2：「ファンクションポイント法」の見積テンプレート（Excelシート参照） （画像をクリックするとEXCELファイルをダウンロードできます。/30KB） |
||||||||||||||||||||
|
データファンクションは、内部論理ファイル（ILF：自アプリケーションで持ち、保守するファイルの数）と、外部インターフェースファイル（EIF：ほかアプリケーションの持つファイルを参照する数）に分類されています。 一方トランザクションファンクションは、外部入力（EI：アプリケーション外部からデータ入力される処理数）、外部出力（EO：アプリケーション外部にデータ出力する処理数）、外部照会（EQ：アプリケーション外部にデータ照会させる処理数）に分類されています。 例えば、社員マスタ登録画面で社員テーブルを更新するとし、その際に部門テーブルを参照するならば、ILF=1（社員テーブル）、EIF=1（部門テーブル）、EI=1（社員マスタ登録画面）ということになります。また、社員検索照会画面で社員テーブルと部門テーブルを参照し、その結果を画面および社員一覧表（帳票）に出力するアプリケーションなら、EIF=2（社員テーブルと部門テーブル）、EO=1（社員一覧表）、EQ=1（社員検索照会）という機能数になります。 これらの機能数(A)に、それぞれの重み（B）をかけて合計ファンクションポイント(FP)を求めます。これを生産性基準(C)で割ったものが工数(D)ということになります。 ファンクションポイント法は、機能数をカウントして係数をかけるという手法自体は標準値法と全く同じです。違いは、機能数の中にデータファンクション（ファイル）の要素を加えていることと、いったんファンクションポイントという指標に置き換えて規模を表していることです。確かにアクセスするファイル数が多い画面、帳票の方が工数はかかりますが、その数をカウントするのは結構大変です。また、最近のアプリケーションはオブジェクト指向型となっているので、カウント基準が難しくなっています。ファイル数を別途カウントしなくてもその要素も難易度として加味できるので、弊社では簡便な標準値法の方が人気があります。 |
||||||||||||||||||||
| 積上げ積算法 | ||||||||||||||||||||
|
規模がそれほど大きくない場合や、既存アプリケーションを改修・カスタマイズする場合は、「積上げ積算法」をよく使います。また、スタート当初は「標準値法」や「ファンクションポイント法」などの概算見積で済ませていたものの、ある程度作成するアプリケーション機能が固まった段階で「積上げ積算法」を使って機能ごとの工数を再見積する場合もあります。 積上げ積算法は、作成するアプリケーション機能を洗い出し、その開発工数を直接記入して積上げる方法です。 例えば、「社員マスタ登録」は5人日、「社員検索表示」は3人日という具合に直接工数を見積り、それをシートに記入して行きます。工数算出の基準は見積者の推測だけなので、典型的なKKD法とも言えます。しかし、"全部で8千万円でどうだ！"というような勘にたよったドンブリ勘定ではなく、機能単位の見積を積上げる方式なのでそれなりに信頼性があります。 |
||||||||||||||||||||
 見積者の経験不足を補うためのルール一般に、ファンクションポイントのように計算式で求められる手法の方が、なんとなく根拠があって正確だと思われがちです。しかし、機能ごとにきちんと工数を判断するのであれば、機械的に数値を当てはめる「標準値法」や「ファンクション法」よりも、「積上げ積算法」の方がむしろ精度は高いと思います。囲碁の地（陣地）を途中で数える場合でも、右上済みが12目、中央がだいたい37目、左下が8目なので、約57目というように積上げ計算しますが、プロが数えると恐ろしいほど正確です。 問題は見積者の力量で、その経験が不足していれば誤差も大きくなります。そこで弊社では、ある金額以上の見積の場合は見積レビューを行い、その見積が妥当かどうかを有識者でチェックするルールにしています。複数のメンバーでディスカッションすることにより見積精度が高まりますし、参加者の見積スキルが向上します。 |
||||||||||||||||||||
|
|
||||||||||||||||||||
 図3：「積上げ積算法」の見積テンプレート（Excelシートの機能積上法） （画像をクリックするとEXCELファイルをダウンロードできます。/26KB） |
||||||||||||||||||||
|
図3は、PYRAMIDで用意している「積上げ積算法」の見積テンプレートです。対象アプリケーションの機能をこのシートに漏れなく書き出し、機能ごとの工数見積を右側に記入していきます。このシートでは、作業工程と機能分類で機能を分類していますが、分類の仕方はプロジェクトごとに変えてもかまいません。右端に実績欄があり、ここに実際かかった工数を記入します。最後にプロジェクト完了報告書を作成する際のレビューにおいて、これをもとに見積精度をチェック・反省し、次のプロジェクトに活かします。 |
||||||||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
