前回、ファンクションポイント法に関する3つの"誤解"について説明しました。今回は、その話を踏まえ、正しいファンクションポイント法についてお話しましょう。

それではファンクションポイント法の概略を説明します。

ここで紹介するのは、日本国内で最もメジャーなファンクションポイント法であるIFPUG法(※)のルールです。誌面の都合上ここでは概略しか説明できませんので、詳細を知りたい方は別途マニュアルなどをご参照ください。

※ IFPUG法はビジネスアプリケーションに適した手法ですが、すべてのファンクションポイント法がそうであるというわけではありません。ISO、JISのDS(デファクトスタンダード)の1つであるCOSMIC法は、組込み系のソフトをターゲットとして作られています。

ファンクションポイント法において最も重要なのは、「ユーザーの視点で考える」ということです。この場合、システムとしてどのように実装したかは排除して考えます。

ですからファンクションポイント法は、適用した技術とは独立した尺度となり、独立しているがゆえに適用技術の効果を測ることができるというわけです。

それでは、ファンクションポイント法が実際にどのようなシーンで有効なのかを解説しましょう。

ファンクションポイント法で重要なのは、ユーザー視点で考えるということ

受発注者間のコミュニケーションツール

受発注者間で機能要件を検討していく際、ファンクションポイント法を利用すると、その経緯を可視化できます。それだけではなく、定量化されたデータをベースに物事のやりとりができるようになるので、コミュニケーションも円滑になります。ユーザーの視点で考えるので、ユーザーも理解しやすいだけでなく、ファンクションの粒度が決められているので、個人のノウハウや経験に左右されることなく客観的に定量化できるのです。

最も大きな利点は、ファンクションポイント法を仲介することで、機能要件についてお互いに共通認識が持てるということです。ただし、そのためには発注側にもファンクションポイント法に関する知識が必要となります。難しい手法ではないので、ぜひ習得にチャレンジしてみてください。

新規システムにおける規模感の把握

新規システムの構築において、機能要件も実装方法も固まっていないまま、実装の結果であるプログラム行数で見積もることがあるかと思います。しかし、これでは難しいだけでなく、見積り誤りを起こしやすくなってしまいます。

特に、経験のない言語を使用する場合などは、今まで使用していた言語との比較につい目が行ってしまい、機能要件そのものの規模の把握がないがしろにされてしまう傾向があります。加えて、言語間のプログラム行数の換算値を間違えてしまうと、全体の規模に影響を与え、深刻な見積り誤りの原因となることがあります。ですから、まずはファンクションポイント法で機能要件の規模感をつかんでから、実装方法による影響を考慮してプログラム行数を見積もるべきです。実装方法による影響が不明な段階において、プログラム行数はあまりにセンシティブな尺度なのです。

ファンクションポイント法はかなり粗い尺度なのですが、枝葉ではなく森全体の大きさを把握するのには適しています。実績規模と比較してみると、細かい単位では凹凸があるものの、全体の規模感は不思議と合うのです。そのような意味では堅牢な尺度と言えると思います。

スコープの管理

一般的なプロジェクトでは、工程が進んで詳細化するにつれ、スコープは変化していきます。このスコープの変化を管理し、コストやスケジュールなどへの影響を把握しないと、プロジェクトの破綻を招きます。

プロジェクトの上流工程においてファンクションポイント法で見積もって機能要件のベースラインを作っておけば、その後の変動を定量的に把握することができるので、影響度合いの予測が容易になります。

執筆者プロフィール

藤貫美佐 (Misa Fujinuki)
株式会社NTTデータ SIコンピテンシー本部 SEPG 設計積算推進担当 課長。IFPUG Certified Function Point Specialist。日本ファンクションポイントユーザー会の事務局長を務める。

『出典:システム開発ジャーナル Vol.5(2008年7月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは 異なる場合があります。ご了承ください。