[Programs] / 最終更新時間:2004年06月24日 23時45分47秒

概要

最近、開発効率をなんとかしたいという思いが強くていろいろ調べている。どの手法を使うとどうなるのかが分からないと判断がつかない。そこで開発効率を測る物差しとしてファンクションポイント(FP)法に注目してみた。

よりよい開発のあり方については、楽しいプロジェクト運営もどうぞ。

目次

参考本

以下の本が例豊富でよいかもしれない。入門本というよりFPの計測について解説した本で、認定ファンクションポイント計測者になるための模擬試験ページまである。

ファンクションポイントの計測と分析

現状

実際の開発では経験と直感で工数を見積もり、予算を交渉し、いくつかの見直しを加えた後そのままGOとなるケースをよく目にする。しかし、その後珍しくない頻度で発生する変更、遅れ、人員投入、予備期間は変更や調整に、デバッグ期間は圧縮、残業は増えというケースも……よくあるパターンだ。

これらのリスクを回避するために、

  • 最初に出した見積もり日数に統計的遅れ係数(1.2〜)をかける方法(「係数かけとけ」法)
  • 複数の人間に同一ソフトウェアの見積もりを出して見積もりの精度を高める方法(Delphi法)

などのシンプルな手段もある。対策をとらないよりはマシだ。

しかしこの方法では改善のための物差しが統計的経験と直感だけが頼りであるため、生産性をあげたとしてもどのくらい生産性があがったのかまともな数値として出てこない。結果もあいまいなものとなる。

そうではなく、誰かの主観に頼りすぎない公平な評価の基準となる数値があれば、全社的な目標やボーナスとして(一部)その数値が利用できる。それはやりがいのある仕事となり、生産性をあげたり、自ら工夫をするきっかけとなるだろう。

計測とは離れて、リスク管理については熊とワルツをが分かりやすいです。
自ら工夫をするきっかけや、毎日の勝利の喜びを味わうために数値を使い、会社を活性化させる方法はグレートゲーム・オブ・ビジネスを参考にどうぞ。

ソフトウェアの規模

昔はソフトウェアの規模を行数(Lines Of Code)で管理していた。しかし現代において、行数が多いプログラムが必ずしもよいプログラムであったり、多くの機能を持っていたり、高品質であったりするものではないというのは直感的にも分かる。

FP法ではソフトウェアの入出力から「機能規模」を割り出し、これをソフトウェアの規模とする。ただし、これは工数の見積もり手法ではないので、実際の工数を出すには

標準工数 = FP値 × 生産性基準値(FP/人月)

という計算を行う[1]。できるだけ正確な物差しで規模を測ることで、より正確な工数見積もりができるという理屈だ。

  • [1]標準工数を実際の工数にするには、さらにプロジェクトごとのコスト要因を計算に加える必要があります。

さらに重要なのは、ある規模のソフトウェアを開発するのにかかる生産性の高さ(FP値に対する実際の開発時間・量)が分かるということ。つまり対策や試みの前後でこれを調べることで、なにが改善され、なにが改善されなかったかが分かるわけで、これは開発の最適化には欠かせない情報だ。

またFP法を使うと、内容を変更したり追加したことで開発規模にどんな影響があるのかといった情報を、クライアントに客観的な形で示すことができる。

注意すること

FP法はあくまでソフトウェア規模を測るもので、ソフトウェアの品質や芸術的要素、そのほか機能以外のあらゆる要求は考慮されていない。その点は別の係数として補っておく必要がある。

基本的にユーザーに提供する機能が同じならば、どんな言語、どんな設計手法を使い、どんな技術者が開発しようとFP値は変わらない。[2]

  • [2]いくつかの要素については一般システム特性という調整係数を計算に加えることでFP値に反映できる。ただし、この係数については否定的な意見が多いようだ。

FP法の用語

FP法では以下の要素をファンクションとして計測する。

データファンクション

  • ILF 内部論理ファイル
  • EIF 外部インターフェイスファイル

トランザクションファンクション

  • EI 外部入力
  • EO 外部出力
  • EQ 外部照会

しかし、いまいちピンとこない。用語には正確さが必要だけれど、聞きなれない略語や想像しづらい日本語では敷居が高くなってしまう。ここではあえてこれらの用語の言い換えをしてみよう。[3]

  • [3]慣れたら、ここに列挙した業界共通の用語に戻りましょう。

用語の言い換え

データファイル

内部ファイル (ILF 内部論理ファイル)
アプリケーション境界内にあるデータのグループ。物理的な意味ではなくユーザーの概念上にある、一連の項目のまとまりを1つのファイルとする。
外部ファイル (EIF 外部インターフェイスファイル)
アプリケーション境界外にあるデータのグループ。つまり他のアプリケーションが保守するファイル。

要素処理

入力 (EI 外部入力)
アプリケーション境界外からデータや制御情報を受け取って内部ファイルを処理するか、アプリケーションの振る舞いを変える処理。
出力 (EO 外部出力)
アプリケーション境界外に出て行くデータや制御情報を生成する処理。同時に内部ファイルを処理することもある。
検索 (EQ 外部照会)
データや制御情報を検索してアプリケーション境界外に提示する処理。検索以外の処理を行わないもの。

FP法ではユーザーが識別しないものは、機能とはみなさない。たとえファイルや要素処理がプログラム内部で使用されようとも、それが外に見えないなら、実装方法のひとつに過ぎないというわけだ。

ユーザーが識別していたとしても、要素処理されないファイル(静的なデータ)は機能とみなさないし、アプリケーション境界をまたがない要素処理も機能とみなさない。

また、アプリケーション境界内でユニークでないファイルや要素処理はそれぞれをひとつにまとめ、複数の機能とはしない。

要素処理はユーザーにとって意味のある最小単位でのみ計測すること。

FP値の計測手順

  1. FPの計測タイプを識別する
  2. 計測範囲とアプリケーション境界を識別する
  3. すべてのデータファイルと、その複雑度を識別する
  4. すべての要素処理と、その複雑度を識別する
  5. 未調整FP値を求める
  6. 一般システム特性から、調整係数を決める
  7. 調整済みFP値を求める

以下、計測の流れを簡単に追ってみる。[4]

なお、これから行う計測手順の説明は結構ややこしい。でもFP法には導入しやすい簡易手法もあるので少しご安心を。簡易手法について計測手順のあとにご紹介。

  • [4]ここでとりあげるのは適当な例やまとめなので、詳しくは参考書を見てください。

どんなレポートを書くか?

まず先に、計測後に書かれたレポートを見てみる。

プロジェクト見積もり

プロジェクト名 ○○○プロジェクト
アプリケーション名 ○○○アプリケーション
バージョン 1.0
プロジェクトタイプ 新規開発
アプリケーションタイプ 対話型 データベース利用
プラットフォーム クライアント/サーバ
使用形態 複数拠点/海外展開
FP 350
生産性 13.29
人月 26.34
工期 10.97
FP当たりの原価 753
欠陥数 44

一定時期ごとに計測を行い、数値を記録していくことでグラフ化が行える。加えてプロジェクトプロフィールのチェックリストから算出したカテゴリ[5]をもとに、リスク分析結果の得点やコメントなどを書いておくとよいが、ここでは省略する。

  • [5]管理、要求記述、設計、制作、テスト、環境

1. FPの計測タイプを識別する

  • 新規開発プロジェクトFP
  • 機能拡張プロジェクトFP
  • (既存の)アプリケーションFP

このなかからひとつを選択。FP法では新規開発前でも、バージョンアップ前でも、開発済みのものでも計測を行えるわけだ。

2. 計測範囲とアプリケーション境界を識別する

アプリケーション境界とは、文字通りこのFP値を計測するアプリケーションと、それ以外を分ける境界のこと。この境界を行き来する処理が、アプリケーションの機能として識別される。

ユーザーの視点にもとづいて決め、一度決めたら無闇に変更しない。
簡単な図を書いておくとよい。

「○○○アプリケーション」
   ↑更新
「データベース更新者」

3. すべてのデータファイルと、その複雑度を識別する

ここからいよいよFP値の計測に入る。
最初に計測するのは、このアプリケーションがどのくらいのどんなデータファイル[6]を持っているかという点。

  • [6]正式にはデータファンクションという。

以下のような表を作る。

ファンクションポイント計測一覧表-ファイルをリスト化

説明 タイプ データ項目数 レコード数 複雑度
○○ファイル 内部/外部ファイル 1〜 1〜 低/中/高
ユーザー情報ファイル 内部ファイル -- -- --
エラーファイル 外部ファイル -- -- --

アプリケーション内にあるのが内部ファイルで、外にあるのが外部ファイル。ユーザーが意識しないファイルは書かない。ユーザーの頭の中でグループ化されている単位で書く。同一種類のファイルはまとめる。

次に複雑度を決定する。複雑度を書き込んだ一覧表は以下のようになる。

ファンクションポイント計測一覧表-ファイルの複雑度を加える

説明 タイプ データ項目数 レコード数 複雑度
○○ファイル 内部/外部ファイル 1〜 1〜 低/中/高
ユーザー情報ファイル 内部ファイル 13 2
エラーファイル 外部ファイル 4 1

データ項目(DET)数は、ユニークでユーザーが認識できる繰り返しのないデータフィールドか属性を数えたもの。同じデータファイルに対し、複数アプリケーションがアクセスする場合は、それぞれ自分が使用するDETのみを計測する。

レコード種類(RET)数はデータ項目のサブグループで、データ項目と継承関係にあるデータレコードを数えたもの。サブグループがない場合は1RETとして計測する。

複雑度は、以下のデータファイル複雑度決定マトリックスに横=データ項目数、縦=レコード数を入れることで判断できる。

データファイル複雑度決定マトリックス

データ項目数
1〜19 20〜50 51〜
1
レコード数 2〜5
6〜

4. すべての要素処理と、その複雑度を識別する

次に計測するのは、アプリケーションがどのくらいのどんな要素処理[7]を持っているかという点。

  • [7]正式にはトランザクションファンクションという。

以下のような表を作る。

ファンクションポイント計測一覧表-要素処理をリスト化

説明 タイプ データ項目数 関連ファイル数 複雑度
○○処理 入力/出力/検索 1〜 1〜 低/中/高
ユーザー情報の作成 出力 -- -- --
ユーザー情報の表示 検索 -- -- --
ユーザー情報の変更 入力 -- -- --
ユーザー情報の削除 入力 -- -- --

データ項目(DET)数は、ユニークでユーザーが認識できる繰り返しのないデータフィールドか属性で、アプリケーション境界を横切るものを数えたもの。要素処理におけるその他の属性もDETとして数える。アプリケーション境界の外側に処理の完了やエラーメッセージなどを表示する場合は、複数のメッセージがあってもまとめて1DETとする。同じ要素処理の呼び出しに複数手段があっても1DETとする。同じ種類の情報が出たり入ったりする場合も各要素処理に一度だけ1DETとして計測する。

関連ファイル(FTR)数(参照ファイル数とも言う)は、要素処理で保守されるか読み込まれるファイルの数を数えたもの。保守されたり、読み込まれるファイルごとに1FTRとする。ただし、保守と読み込み両方を行うファイルについては合わせて1FTRとすることに注意。

複雑度は、以下の各要素処理のタイプ別の複雑度決定マトリックスに横=データ項目数、縦=関連ファイル数を入れることで判断できる。

要素処理-入力(EI)複雑度決定マトリックス

データ項目数
1〜4 5〜15 16〜
0〜1
関連ファイル数 2
3〜

要素処理-出力(EO)複雑度決定マトリックス

データ項目数
1〜5 6〜19 20〜
0〜1
関連ファイル数 2〜3
4〜

要素処理-検索(EQ)複雑度決定マトリックス

データ項目数
1〜5 6〜19 20〜
0〜1
関連ファイル数 2〜3
4〜

複雑度を書き込んだ一覧表は以下のようになる。

ファンクションポイント計測一覧表-要素処理の複雑度を加える

説明 タイプ データ項目数 関連ファイル数 複雑度
○○処理 入力/出力/検索 1〜 1〜 低/中/高
ユーザー情報の作成 出力 10 3
ユーザー情報の表示 検索 10 1
ユーザー情報の変更 入力 10 3
ユーザー情報の削除 入力 3 1

5. 未調整FP値を求める

データファイルと要素処理の情報が集まったので、一覧でみてみよう。

ファンクションポイント計測一覧表-データファイルと要素処理を同時に見る

説明 タイプ データ項目数 関連ファイル数/レコード数 複雑度
○○ファイル 内部/外部ファイル 1〜 1〜 低/中/高
ユーザー情報ファイル 内部ファイル 13 2
エラーファイル 外部ファイル 4 1
○○処理 入力/出力/検索 1〜 1〜 低/中/高
ユーザー情報の作成 出力 10 3
ユーザー情報の表示 検索 10 1
ユーザー情報の変更 入力 10 3
ユーザー情報の削除 入力 3 1

これを未調整FP値に変換するのは単純な手順で行える。以下のIFPUGの未調整FP表に横=複雑度、縦=タイプに対応させて数を記入し、右側に合計を書くだけだ。

IFPUGの未調整FP表

タイプ 合計
入力ファイル(ILF)   × 7   × 10   × 15  
出力ファイル(EIF)   × 5   × 7   × 10  
入力(EI)   × 3   × 4   × 6  
出力(EO)   × 4   × 5   × 7  
検索(EQ)   × 3   × 4   × 6  

表に記入すると以下のようになる。

IFPUGの未調整FP表-記入例

タイプ 合計
入力ファイル(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と計測できる。

6. 一般システム特性から、調整係数を決める

FP法のデータファイルや要素処理で測りきれない要因を機能規模に反映させるため、調整係数(VAF)を求める。ただこの調整係数には否定的な意見があり、利用者によってはこの調整係数をないものとし、未調整FP値をそのままアプリケーションのFP値とすることもある。[8]

  • [8]国際標準化機構(ISO)の「ソフトウェアの機能規模尺度の標準(ISO/IEC-14143-1)」でも一般システム特性を除外する方向で進んでいるらしい。

調整係数は一般システム特性(GSC)のチェックリストに答えることで計算できる。
一般システム特性には14個の項目があり、項目それぞれについて0〜5の尺度で影響度(DI)を記入していく。

一般システム特性の項目で答える影響度一覧

  • 0 該当しない。またはまったく影響がない
  • 1 弱い影響がある
  • 2 やや弱い影響がある
  • 3 平均的な影響がある
  • 4 かなり強い影響がある
  • 5 全体にわたり強い影響がある

一般システム特性の項目影響度記入表

項目名 影響度(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
  • [9]一般的なバッチアプリケーションの影響度合計は15未満、フロントエンドバッチアプリケーションで15以上30未満、対話型アプリケーションで30以上45未満、リアルタイム/テレコミュニケーション/プロセス制御システムでは30以上60未満になることが多いとのこと。

7. 調整済みFP値を求める

最後に未調整FP値調整係数(VAF)を積算すると調整済みFP値が求まる。

調整済みFP値 = 未調整FP値 × 調整係数

今回の例で、調整係数を 0.96 とすると、25 × 0.96 で調整済みFP値は 24 となった。

FP法の簡易手法

さて、計測手順をみてきて一番思うことは「仕様もはっきりしないのに、こんな複雑なことを決められるわけがない」とか「時間もないのにこんな手間をかけていられるか」といったことだろう。

FP法にはそのような場合に有用な計測手法がある。

これはオランダで発案・実施されているもので、NESMAに日本語の分かりやすい説明が掲載されている。この Early Function Point Counting の2つの手法を引用してみよう。

FP試算法:The indicative function point count

FP試算法は、下記の手順で行う。

*データファンクション (ILF, EIF) の数を決定する。

*アプリケーションの未調整FP値を下記の計算で求める。

 FP試算値 (FP) = 35 x ILFの数 + 15 x EIFの数

 即ち、このFP試算値は、論理ファイル (ILF, EIF) のみに基づいて算出される。

FP試算法は、下記の仮定に基づいている。

ILFには、平均して、3つのEI (ILFに対する追加、変更、削除)と、2つのEO、1つのEQを伴う。 EIFには、平均して、1つのEO、1つの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法から算出する様々な値

FP値を他の数値と組み合わせることで、ソフトウェア開発における様々な情報を導き出せる。前述の本からいくつか例をあげておく。

FP当たりの所要時間

[10]

プロジェクトの総所要時間(人時) ÷ 引き渡されたFP値
  • [10]これはプロジェクトレベルで評価できるが、個人の生産性指標として使ってはいけない。

開発速度

FP値 ÷ 経過したカレンダ時間

欠陥密度

欠陥数(フェーズごとあるいは合計の) ÷ FP値の合計

文章量

(文章ごとの)ページ数 ÷ FP値の合計

FPあたりの費用

総費用 ÷ FP値の合計

補修費率

(補修に要した時間 × 時間あたりの費用) ÷ リリースされた分のFP値

保守性

保守費用 ÷ アプリケーションFP値

信頼性

指摘された欠陥数 ÷ アプリケーションFP値の合計

成長率

現在のFP値 ÷ 元のFP値

安定度

変更数 ÷ アプリケーションFP値

計測よりも計測結果の利用方法が大事

数値で管理できるもの「だけ」で測る目標管理には弊害がある。なにかの貢献度を単純化した近似値であらわし、その数値が増えても、そこにあらわれていない別の要素(離職率、製品の品質、顧客満足度、個人の成長…etc.)に悪影響があれば、本当の目標に近づいたとは言いがたい。なにか問題が発生するたびに目標管理を修正しても、いたちごっこはいつまでも続く。数値の限界を知っておくことが重要だ。

「ゆとりの法則」でトム・デマルコ氏はこう言う。

目標管理は、人為的に外部から「目標」というモチベーションを与え、労働者に内在するモチベーションを追い出してしまう。そのため、たとえば、ノルマを達成するという外部からのモチベーションに動かされている営業担当者は、顧客を満足させるという内在するモチベーションを無視するようになる。

このことに注意し「数値であらわせるもの」と「そうでないもの」の両方を評価する必要がある。これはもともと目標を明確な数値で管理していなくても、上司の評価が「顧客を満足させること」に向かっていなければ同じことだ。

また、トム・デマルコ氏は昔「測定できない事柄を、コントロールするわけにはいかない」といってソフトウェア開発管理に計測することをすすめたが、最近はこの言葉を思いなおしている。というのも、

わたしたちが生産性を計測するとき、自分の生産性がどうか見極めたり実質的な生産能力に見合った方向へ修正するために計測するのではない。生産性を計測するとき、わたしたちは声高にはっきりと、生産性を上げろと言っているのであって、それは牧童の突き棒と同じなのだ。

どの方法を採用するか決めたり、なんらかの発見をするために計測するのはいいが、そうでなければ「計測するな」ということ。プレッシャーを与え続ける(=牧童の突き棒)のはコスト、品質、時間すべてにおいて悪い結果を生む。このあたりはブックレビューピープルウェア、ゆとりの法則を参照のこと。グレートゲーム・オブ・ビジネスでも数値を使うが、基本は叱るためにではなく、日々個人が喜ぶために使っている。

ミニリンク集