|
| プロジェクト名 | ○○○プロジェクト |
| アプリケーション名 | ○○○アプリケーション |
| バージョン | 1.0 |
| プロジェクトタイプ | 新規開発 |
| アプリケーションタイプ | 対話型 データベース利用 |
| プラットフォーム | クライアント/サーバ |
| 使用形態 | 複数拠点/海外展開 |
| FP | 350 |
| 生産性 | 13.29 |
| 人月 | 26.34 |
| 工期 | 10.97 |
| FP当たりの原価 | 753 |
| 欠陥数 | 44 |
一定時期ごとに計測を行い、数値を記録していくことでグラフ化が行える。加えてプロジェクトプロフィールのチェックリストから算出したカテゴリ[5]をもとに、リスク分析結果の得点やコメントなどを書いておくとよいが、ここでは省略する。
このなかからひとつを選択。FP法では新規開発前でも、バージョンアップ前でも、開発済みのものでも計測を行えるわけだ。
アプリケーション境界とは、文字通りこのFP値を計測するアプリケーションと、それ以外を分ける境界のこと。この境界を行き来する処理が、アプリケーションの機能として識別される。
ユーザーの視点にもとづいて決め、一度決めたら無闇に変更しない。
簡単な図を書いておくとよい。
「○○○アプリケーション」 ↑更新 「データベース更新者」
ここからいよいよFP値の計測に入る。
最初に計測するのは、このアプリケーションがどのくらいのどんなデータファイル[6]を持っているかという点。
以下のような表を作る。
| 説明 | タイプ | データ項目数 | レコード数 | 複雑度 |
|---|---|---|---|---|
| ○○ファイル | 内部/外部ファイル | 1〜 | 1〜 | 低/中/高 |
| ユーザー情報ファイル | 内部ファイル | -- | -- | -- |
| エラーファイル | 外部ファイル | -- | -- | -- |
アプリケーション内にあるのが内部ファイルで、外にあるのが外部ファイル。ユーザーが意識しないファイルは書かない。ユーザーの頭の中でグループ化されている単位で書く。同一種類のファイルはまとめる。
次に複雑度を決定する。複雑度を書き込んだ一覧表は以下のようになる。
| 説明 | タイプ | データ項目数 | レコード数 | 複雑度 |
|---|---|---|---|---|
| ○○ファイル | 内部/外部ファイル | 1〜 | 1〜 | 低/中/高 |
| ユーザー情報ファイル | 内部ファイル | 13 | 2 | 低 |
| エラーファイル | 外部ファイル | 4 | 1 | 低 |
データ項目(DET)数は、ユニークでユーザーが認識できる繰り返しのないデータフィールドか属性を数えたもの。同じデータファイルに対し、複数アプリケーションがアクセスする場合は、それぞれ自分が使用するDETのみを計測する。
レコード種類(RET)数はデータ項目のサブグループで、データ項目と継承関係にあるデータレコードを数えたもの。サブグループがない場合は1RETとして計測する。
複雑度は、以下のデータファイル複雑度決定マトリックスに横=データ項目数、縦=レコード数を入れることで判断できる。
| データ項目数 | ||||
| 1〜19 | 20〜50 | 51〜 | ||
| 1 | 低 | 低 | 中 | |
| レコード数 | 2〜5 | 低 | 中 | 高 |
| 6〜 | 中 | 高 | 高 |
次に計測するのは、アプリケーションがどのくらいのどんな要素処理[7]を持っているかという点。
以下のような表を作る。
| 説明 | タイプ | データ項目数 | 関連ファイル数 | 複雑度 |
|---|---|---|---|---|
| ○○処理 | 入力/出力/検索 | 1〜 | 1〜 | 低/中/高 |
| ユーザー情報の作成 | 出力 | -- | -- | -- |
| ユーザー情報の表示 | 検索 | -- | -- | -- |
| ユーザー情報の変更 | 入力 | -- | -- | -- |
| ユーザー情報の削除 | 入力 | -- | -- | -- |
データ項目(DET)数は、ユニークでユーザーが認識できる繰り返しのないデータフィールドか属性で、アプリケーション境界を横切るものを数えたもの。要素処理におけるその他の属性もDETとして数える。アプリケーション境界の外側に処理の完了やエラーメッセージなどを表示する場合は、複数のメッセージがあってもまとめて1DETとする。同じ要素処理の呼び出しに複数手段があっても1DETとする。同じ種類の情報が出たり入ったりする場合も各要素処理に一度だけ1DETとして計測する。
関連ファイル(FTR)数（参照ファイル数とも言う）は、要素処理で保守されるか読み込まれるファイルの数を数えたもの。保守されたり、読み込まれるファイルごとに1FTRとする。ただし、保守と読み込み両方を行うファイルについては合わせて1FTRとすることに注意。
複雑度は、以下の各要素処理のタイプ別の複雑度決定マトリックスに横=データ項目数、縦=関連ファイル数を入れることで判断できる。
| データ項目数 | ||||
| 1〜4 | 5〜15 | 16〜 | ||
| 0〜1 | 低 | 低 | 中 | |
| 関連ファイル数 | 2 | 低 | 中 | 高 |
| 3〜 | 中 | 高 | 高 |
| データ項目数 | ||||
| 1〜5 | 6〜19 | 20〜 | ||
| 0〜1 | 低 | 低 | 中 | |
| 関連ファイル数 | 2〜3 | 低 | 中 | 高 |
| 4〜 | 中 | 高 | 高 |
| データ項目数 | ||||
| 1〜5 | 6〜19 | 20〜 | ||
| 0〜1 | 低 | 低 | 中 | |
| 関連ファイル数 | 2〜3 | 低 | 中 | 高 |
| 4〜 | 中 | 高 | 高 |
複雑度を書き込んだ一覧表は以下のようになる。
| 説明 | タイプ | データ項目数 | 関連ファイル数 | 複雑度 |
|---|---|---|---|---|
| ○○処理 | 入力/出力/検索 | 1〜 | 1〜 | 低/中/高 |
| ユーザー情報の作成 | 出力 | 10 | 3 | 高 |
| ユーザー情報の表示 | 検索 | 10 | 1 | 低 |
| ユーザー情報の変更 | 入力 | 10 | 3 | 高 |
| ユーザー情報の削除 | 入力 | 3 | 1 | 低 |
データファイルと要素処理の情報が集まったので、一覧でみてみよう。
| 説明 | タイプ | データ項目数 | 関連ファイル数/レコード数 | 複雑度 |
|---|---|---|---|---|
| ○○ファイル | 内部/外部ファイル | 1〜 | 1〜 | 低/中/高 |
| ユーザー情報ファイル | 内部ファイル | 13 | 2 | 低 |
| エラーファイル | 外部ファイル | 4 | 1 | 低 |
| ○○処理 | 入力/出力/検索 | 1〜 | 1〜 | 低/中/高 |
| ユーザー情報の作成 | 出力 | 10 | 3 | 高 |
| ユーザー情報の表示 | 検索 | 10 | 1 | 低 |
| ユーザー情報の変更 | 入力 | 10 | 3 | 高 |
| ユーザー情報の削除 | 入力 | 3 | 1 | 低 |
これを未調整FP値に変換するのは単純な手順で行える。以下のIFPUGの未調整FP表に横=複雑度、縦=タイプに対応させて数を記入し、右側に合計を書くだけだ。
| タイプ | 低 | 中 | 高 | 合計 |
|---|---|---|---|---|
| 入力ファイル(ILF) | × 7 | × 10 | × 15 | |
| 出力ファイル(EIF) | × 5 | × 7 | × 10 | |
| 入力(EI) | × 3 | × 4 | × 6 | |
| 出力(EO) | × 4 | × 5 | × 7 | |
| 検索(EQ) | × 3 | × 4 | × 6 |
表に記入すると以下のようになる。
| タイプ | 低 | 中 | 高 | 合計 |
|---|---|---|---|---|
| 入力ファイル(ILF) | 1 × 7 | × 10 | × 15 | 7 |
| 出力ファイル(EIF) | 1 × 5 | × 7 | × 10 | 5 |
| 入力(EI) | 1 × 3 | × 4 | 1 × 6 | 3 |
| 出力(EO) | × 4 | × 5 | 1 × 7 | 7 |
| 検索(EQ) | 1 × 3 | × 4 | × 6 | 3 |
これをさらに合計すると、
7 + 5 + 3 + 7 + 3 = 25
となり、このアプリケーションの未調整FP値は25と計測できる。
FP法のデータファイルや要素処理で測りきれない要因を機能規模に反映させるため、調整係数(VAF)を求める。ただこの調整係数には否定的な意見があり、利用者によってはこの調整係数をないものとし、未調整FP値をそのままアプリケーションのFP値とすることもある。[8]
調整係数は一般システム特性(GSC)のチェックリストに答えることで計算できる。
一般システム特性には14個の項目があり、項目それぞれについて0〜5の尺度で影響度(DI)を記入していく。
| 項目名 | 影響度(0〜5) |
|---|---|
| 1.データ通信 | |
| 2.分散処理 | |
| 3.性能 | |
| 4.高負荷構成 | |
| 5.要素処理(トランザクション)量 | |
| 6.オンラインデータ入力 | |
| 7.エンドユーザ効率 | |
| 8.オンライン更新 | |
| 9.複雑な処理 | |
| 10.再利用可能性 | |
| 11.インストール容易性 | |
| 12.運用性 | |
| 13.複数サイト | |
| 14.変更容易性 |
各項目のもう少し詳しい解説はファンクションポイント法の流れなどを参考にするとよいかもしれない。
14個の一般システム特性の影響度を合計して影響度合計(TDI)を求める[9]。この数値は0〜70の数値になっているはず。これを以下の式に代入すると、調整係数(VAF)を求められる。
調整係数 = ( 影響度合計 × 0.01 ) + 0.65
最後に未調整FP値に調整係数(VAF)を積算すると調整済みFP値が求まる。
調整済みFP値 = 未調整FP値 × 調整係数
今回の例で、調整係数を 0.96 とすると、25 × 0.96 で調整済みFP値は 24 となった。
さて、計測手順をみてきて一番思うことは「仕様もはっきりしないのに、こんな複雑なことを決められるわけがない」とか「時間もないのにこんな手間をかけていられるか」といったことだろう。
FP法にはそのような場合に有用な計測手法がある。
これはオランダで発案・実施されているもので、NESMAに日本語の分かりやすい説明が掲載されている。この Early Function Point Counting の２つの手法を引用してみよう。
FP試算法：The indicative function point count
FP試算法は、下記の手順で行う。
*データファンクション (ILF, EIF) の数を決定する。
*アプリケーションの未調整FP値を下記の計算で求める。
FP試算値 (FP) = 35 x ILFの数 + 15 x EIFの数
即ち、このFP試算値は、論理ファイル (ILF, EIF) のみに基づいて算出される。
FP試算法は、下記の仮定に基づいている。
ILFには、平均して、３つのEI (ILFに対する追加、変更、削除）と、２つのEO、１つのEQを伴う。 EIFには、平均して、１つのEO、１つのEQを伴う。
つまり、FP試算法はデータファンクション(データファイル）さえ分かれば計算できるわけだ。
FP概算法：The estimated function point count
FP概算法は、下記の手順で行う。
*全てのファンクションについて、ファンクションタイプ (ILF, EIF, EI, EO, EQ) を決定する。
*全てのデータファンクション (ILF, EIF) の複雑度をLowに、 全てのトランザクションファンクション (EI, EO, EQ) の複雑度をAverageとする。
*未調整ファンクションポイントを計算する。
従って、正式のカウント方法との唯一の違いは、その複雑度の評価をファンクション毎に行うのではなく、デフォルト値で決める点である。
FP概算法は複雑度計算を省いているので、ファイルと要素処理をリストだしすれば計算できる。結論として、
どのカウント方式をいつ使えば良いか
正式のFPカウント方式は、もちろん概算法や試算法に比べ、より正確である。しかし、より多くの時間と、より詳細な仕様を必要とする。
どのカウント方式を使うかは、プロジェクトマネージャの判断と、システムのライフサイクルのフェーズに依存している。
多くのアプリケーションに適用した結果、FP試算法は、驚くほど良い見積もり結果を示している。データモデルは、ほとんど労力を掛けずに作成または入手できるため、多くの場合FP試算法で算出する事は比較的容易である。
ということで、これを使えばFP法導入の敷居を下げられるだろう。この「統計的デフォルト値を使う」という発想があれば、特殊なアプリケーションであっても、それぞれにうまく適合するFP法の簡易計測を行えるかもしれない。詳しくは上記サイトを参照のこと。
FP値を他の数値と組み合わせることで、ソフトウェア開発における様々な情報を導き出せる。前述の本からいくつか例をあげておく。
[10]
プロジェクトの総所要時間（人時） ÷ 引き渡されたFP値
FP値 ÷ 経過したカレンダ時間
欠陥数（フェーズごとあるいは合計の） ÷ FP値の合計
（文章ごとの）ページ数 ÷ FP値の合計
総費用 ÷ FP値の合計
（補修に要した時間 × 時間あたりの費用） ÷ リリースされた分のFP値
保守費用 ÷ アプリケーションFP値
指摘された欠陥数 ÷ アプリケーションFP値の合計
現在のFP値 ÷ 元のFP値
変更数 ÷ アプリケーションFP値
数値で管理できるもの「だけ」で測る目標管理には弊害がある。なにかの貢献度を単純化した近似値であらわし、その数値が増えても、そこにあらわれていない別の要素（離職率、製品の品質、顧客満足度、個人の成長…etc.）に悪影響があれば、本当の目標に近づいたとは言いがたい。なにか問題が発生するたびに目標管理を修正しても、いたちごっこはいつまでも続く。数値の限界を知っておくことが重要だ。
「ゆとりの法則」でトム・デマルコ氏はこう言う。
目標管理は、人為的に外部から「目標」というモチベーションを与え、労働者に内在するモチベーションを追い出してしまう。そのため、たとえば、ノルマを達成するという外部からのモチベーションに動かされている営業担当者は、顧客を満足させるという内在するモチベーションを無視するようになる。
このことに注意し「数値であらわせるもの」と「そうでないもの」の両方を評価する必要がある。これはもともと目標を明確な数値で管理していなくても、上司の評価が「顧客を満足させること」に向かっていなければ同じことだ。
また、トム・デマルコ氏は昔「測定できない事柄を、コントロールするわけにはいかない」といってソフトウェア開発管理に計測することをすすめたが、最近はこの言葉を思いなおしている。というのも、
わたしたちが生産性を計測するとき、自分の生産性がどうか見極めたり、実質的な生産能力に見合った方向へ修正するために計測するのではない。生産性を計測するとき、わたしたちは声高にはっきりと、生産性を上げろと言っているのであって、それは牧童の突き棒と同じなのだ。
どの方法を採用するか決めたり、なんらかの発見をするために計測するのはいいが、そうでなければ「計測するな」ということ。プレッシャーを与え続ける（＝牧童の突き棒）のはコスト、品質、時間すべてにおいて悪い結果を生む。このあたりはブックレビューのピープルウェア、ゆとりの法則を参照のこと。グレートゲーム・オブ・ビジネスでも数値を使うが、基本は叱るためにではなく、日々個人が喜ぶために使っている。
