規模見積もりには，誰もが迷うポイントがある。経験を上手に生かす方法を考えなければならない。現場で何に迷うのかを洗い出し，迷いを払拭する仕組みを作ろう。
規模見積もりは，これから開発するソフトウエアの大きさを測定する作業。大きさの単位は「FP数」や「ステップ数」，画面や帳票，バッチといった「機能数」など様々ある。ソフトウエアの規模は，開発に必要な工数やコストを算出する際のベースとなる。ここがブレるとすべてがおかしくなる。
しかし，規模見積もりは一筋縄ではいかない。そもそも要件が固まっていない中で見積もりを強いられることが多い。加えて「同じ要件，同じ技法を使っても，人が違うと見積もり結果が変わる」（富士通 SIアシュアランス本部プロジェクトガイド室 室長 合田治彦氏）という問題がある。技法には見積もり担当者による解釈が入る余地があり，条件が同じでも値が一意に決まらないのである。
規模見積もりにおける標準技法の落とし穴は，ルールの解釈が人によって異なる，技法がカバーしていない部分がある，早い段階で技法が適用しづらい――というものである。これらを克服する工夫が現場で必要となる。
ルールの解釈が人によって異なる 本来の考え方を正しく理解する
標準的な見積もり技法の中には，ルールの解釈が難しいものがある。一つひとつのルールを覚えていくのも大事だが，まずはルール本来の考え方を正しく理解しよう。
FP法は解釈が難しい技法の典型だ。2001年からFP法を利用している帝国データバンクの大場靖氏（システム部 サービス開発課）は「（FP法の1種で国際ルールの）IFPUG法には現場で解釈に迷う点がいくつもある」と指摘する。同社ではベンダーにFP法による見積書の提出を求めているが「ベンダーによってFP数が大きく異なることがある。慣れないうちは，本来のルールを正しく理解せず，誤って適用してしまうからだ」（大場氏）と言う。
日本ファンクションポイント・ユーザ会（JFPUG）計測技術委員長の倉重誠氏は「FP法は実装形態を考慮せず，論理的な観点だけでシステムの規模を計測する技法。この考え方を理解していないと，現場で戸惑うことになる」と話す。例えば，FP法では「中間ファイルや一時ファイルは計測しない」という原則がある。これはメッセージ・キューイングなど別の実装技術を使えば，中間ファイルがなくても同じ機能を実現できるとFP法では考えるからだ。ところが「中間ファイルの作成も機能の一つなのだから規模に含めるべきだろう」と判断してしまうと本来の値とは違うものになってしまう。
ほかにも，FP法では誤解しやすい部分がある（図1）。例えば，一覧表示が複数のページにまたがる処理。規模の単位が画面数であれば，それぞれのページを別々に数える。だが論理的な観点からは「一画面でも実装可能なので照会処理の一部分」と見なす。逆に検索処理の場合は，処理を分けてカウントする。検索処理は通常，条件入力→該当案件一覧表示→1件詳細表示という流れになる。ここに「一覧照会」と「明細照会」という二つの機能が含まれると考える。印刷プレビュー機能も画像イメージを作成する必要があるため，通常の印刷機能とは分けて数える。
ユースケース図の利用も有効
FP法では「計測対象はユーザーから見て理解可能な機能」としている。この点もエンジニアにとっての分かりにくさを増大させている。
計測時には，DFD（Data Flow Diagram）やE-R（Entity-Relationship）図を利用することが多い。だが，これらの図にはユーザーの視点が希薄である。そこでNTTデータの藤貫美佐氏（SIコンピテンシー本部 SEPG 設計積算推進担当 課長）は，一つの工夫としてユースケース図の活用を勧める。「ユーザーの視点で機能をとらえるユースケース図は意外にFP法と相性がよい。ユースケースの粒度が一定であり，ユースケース・シナリオが書いてあればそれをベースにFP数を計測できる」（藤貫氏）。
