FP法で業務モデルを計測する

児玉公信さんの本「システム開発の見積りのための実践ファンクションポイント法」を読んで、ファンクションポイント法を業務モデルの計測に使えないか、考えてことをメモ。
＃まとまっていないので、あくまでもメモ書き。

ファンクションポイント法(FP法)は、機能の規模の見積もりとして古くから知られている。
しかし、計算が複雑で、見積もりの根拠となるモデルが曖昧なため、普及しているとはいえない。
「システム開発の見積りのための実践ファンクションポイント法」で興味深いと思った点は下記の通り。

【1】業務設計やシステム提案という早い段階で、概算の工数見積もりを出す道具として、FP法を使うこと。

FP法を使うタイミングとしては、RFPによる提案やシステム化構想、業務設計など、プロジェクト計画書を作る段階を想定している。

実際の業務設計では、顧客の現行業務と新業務の二つのモデルを作り、システム化の利点をアピールして受注する。その時、現行業務モデルと新業務モデルの2つのモデルが作られる。
これを元に、FP法が使えるモデルへ変換して、システムの概算規模をFP法で計算できれば、過去のプロジェクトの実績から、おおよその工数を計算できる。

業務設計における要件定義と言う早い段階で規模を見積もりできる利点は多い。
要件定義では、SIとユーザ企業がシステム化対象のスコープをすり合わせる工程のため、お金や時間の制約から、おのずと開発対象のシステムの規模は収まるはずだからだ。

「システム開発の見積りのための実践ファンクションポイント法」では、ある相場では「1FP＝15人日」という事例が載っている。
つまり、1個の機能を作るのに、3週間かかっている計算になる。

この事例を考えると、業務モデルに出てくる機能は、約1人月で作れる規模感覚で洗い出せばいいだろう。
例えば、100FPならば、見積もり工数は75人月となり、1年未満の中規模プロジェクトになるだろう。
但し、FPと工数の関係は、プロジェクトによって大きく異なるため、注意しよう。

【2】FP法が使えるモデルとしては、「システム開発の見積りのための実践ファンクションポイント法」ではER図とDFDを推奨している。実際、ILF・EIFのようなデータと、EI・EO・EQのような機能の関係を表せればいいからだ。
Astahのようなモデリングツールの場合、岡島さんが推奨するように、ユースケース図にロバストネス図をミックスしたモデルを書けばいいだろう。

JRubyでJUDE CRUD-APIを試す - TECH-moratorium ： テクモラトリアム

FP法のアルゴリズムは、所詮、Excelのマクロで作れるレベルなので、Rubyで実装してしまえばいい。
Astahでモデルを書いた場合、JavaAPIを通じてモデルの値を取得できるので、JRubyを使えばいいだろう。
Rubyプログラムの中で、JavaAPIを簡単にコールしてモデルの値を取得できるからだ。

「システム開発の見積りのための実践ファンクションポイント法」で面白いのは、FP法が使えるモデルの書き方の注意点が、OOAやDOAと発想が似ていること。
まず良いモデルを作るのが、FP法では大事。
つまり、良いモデルかどうかを、FP法で計測することもできるのが面白い。

駄目なモデルは、機能やデータの漏れがあるために、実際に開発してみると、見積もり工数が大きく変わってしまう。
良いモデルならば、その後の要件の変更を新たな要求と見なして、顧客に追加のお金を要求することもできる。

OOAやDOAというモデリング技法にFP法を応用すれば、単なる工数見積もりだけでなく、モデルのメトリクスとして使えないだろうか？
つまり、モデルの規模だけでなく、モデルの品質にFP法を使えないだろうか？

【3】FP法が普及すれば、受託開発の契約を工数ではなく、システムの開発規模でやり取りできる可能性があること。

IT業界の悪いビジネス習慣は、人月ビジネス。
時間を切り売りするビジネスでは、品質が悪いシステムほど時間がかかるから、お金が儲かるという悪循環が発生しがち。
品質を向上させて生産性を上げる方向へ開発者の動機が向かない仕組みになっている。

しかし、「システム開発の見積りのための実践ファンクションポイント法」の最後では、アメリカで開発規模の単位で契約を結び、スコープを調整しながら開発するユーザ企業があるという話が載っている。
これは、まさにアジャイル開発そのものだ。
一定期間に一定規模のシステムを開発していくならば、自然に段階リリースして開発しているだろう。

アジャイル開発では、システムの規模はストーリーポイントという概念で表現されている。ストーリーポイントは、「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」にあるように、開発チームの議論の中から作られる。
しかし、モデルを作っているならば、FP法のアルゴリズムを使えばシステム規模を自動計算できるはず。

人月ビジネスから規模ビジネスへIT業界が変わるならば、生産性の向上が利益に直結するから、技術革新も生まれやすくなるはず。
FP単価、つまり、1FPで実装される工数が小さいほど、わずかな工数で同等の規模のシステムを作れるからだ。
つまり、SIにとってFP単価が受託開発ビジネスの利益指標になればいい。

ストーリーポイントの計算にFP法を用いて、アジャイル開発を補強できないか、考察してみたい。