技法の穴をふさぐ：規模編--技法のルールは分かりにくい数え方の“迷い”をなくす

規模見積もりには、誰もが迷うポイントがある。経験を上手に生かす方法を考えなければならない。現場で何に迷うのかを洗い出し、迷いを払拭する仕組みを作ろう。

　規模見積もりは、これから開発するソフトウエアの大きさを測定する作業。大きさの単位は「FP数」や「ステップ数」、画面や帳票、バッチといった「機能数」など様々ある。ソフトウエアの規模は、開発に必要な工数やコストを算出する際のベースとなる。ここがブレるとすべてがおかしくなる。

　しかし、規模見積もりは一筋縄ではいかない。そもそも要件が固まっていない中で見積もりを強いられることが多い。加えて「同じ要件、同じ技法を使っても、人が違うと見積もり結果が変わる」（富士通 SIアシュアランス本部プロジェクトガイド室 室長 合田治彦氏）という問題がある。技法には見積もり担当者による解釈が入る余地があり、条件が同じでも値が一意に決まらないのである。

　規模見積もりにおける標準技法の落とし穴は、ルールの解釈が人によって異なる、技法がカバーしていない部分がある、早い段階で技法が適用しづらい――というものである。これらを克服する工夫が現場で必要となる。

ルールの解釈が人によって異なる 本来の考え方を正しく理解する

　標準的な見積もり技法の中には、ルールの解釈が難しいものがある。一つひとつのルールを覚えていくのも大事だが、まずはルール本来の考え方を正しく理解しよう。

　FP法は解釈が難しい技法の典型だ。2001年からFP法を利用している帝国データバンクの大場靖氏（システム部 サービス開発課）は「（FP法の1種で国際ルールの）IFPUG法には現場で解釈に迷う点がいくつもある」と指摘する。同社ではベンダーにFP法による見積書の提出を求めているが「ベンダーによってFP数が大きく異なることがある。慣れないうちは、本来のルールを正しく理解せず、誤って適用してしまうからだ」（大場氏）と言う。

　日本ファンクションポイント・ユーザ会（JFPUG）計測技術委員長の倉重誠氏は「FP法は実装形態を考慮せず、論理的な観点だけでシステムの規模を計測する技法。この考え方を理解していないと、現場で戸惑うことになる」と話す。例えば、FP法では「中間ファイルや一時ファイルは計測しない」という原則がある。これはメッセージ・キューイングなど別の実装技術を使えば、中間ファイルがなくても同じ機能を実現できるとFP法では考えるからだ。ところが「中間ファイルの作成も機能の一つなのだから規模に含めるべきだろう」と判断してしまうと本来の値とは違うものになってしまう。

　ほかにも、FP法では誤解しやすい部分がある（図1）。例えば、一覧表示が複数のページにまたがる処理。規模の単位が画面数であれば、それぞれのページを別々に数える。だが論理的な観点からは「一画面でも実装可能なので照会処理の一部分」と見なす。逆に検索処理の場合は、処理を分けてカウントする。検索処理は通常、条件入力→該当案件一覧表示→1件詳細表示という流れになる。ここに「一覧照会」と「明細照会」という二つの機能が含まれると考える。印刷プレビュー機能も画像イメージを作成する必要があるため、通常の印刷機能とは分けて数える。

図1●技法の本来の考え方を正しく理解する

日本ファンクションポイント・ユーザ会（JFPUG）計測技術委員会の倉重氏が作成。論理的な観点から計測するFP法には解釈しづらいルールがある。チーム内で正しい解釈を共有することが重要だ

[画像のクリックで拡大表示]

ユースケース図の利用も有効

　FP法では「計測対象はユーザーから見て理解可能な機能」としている。この点もエンジニアにとっての分かりにくさを増大させている。

　計測時には、DFD（Data Flow Diagram）やE-R（Entity-Relationship）図を利用することが多い。だが、これらの図にはユーザーの視点が希薄である。そこでNTTデータの藤貫美佐氏（SIコンピテンシー本部 SEPG 設計積算推進担当 課長）は、一つの工夫としてユースケース図の活用を勧める。「ユーザーの視点で機能をとらえるユースケース図は意外にFP法と相性がよい。ユースケースの粒度が一定であり、ユースケース・シナリオが書いてあればそれをベースにFP数を計測できる」（藤貫氏）

技法がカバーしていない部分がある 対象/対象外を細かく定義する

　技法のルールを細かく読み解いても、対処できない問題もある。その場合は、自分でルールを作らなければならない。

　古くから使われているLOC法には、何を数えて何を数えないかという具体的なルールがない。「ソースコードを見れば分かるのではないか」と考えるのは早計だ。コメント行は数えるか、セミコロンのような文末記号の行はどうするかなど、LOC法に基づくステップ数は取捨選択次第でいくらでも膨らむし、しぼみもする。人によって計測方法がバラバラなので、別の人の見積もり結果を参考に見積もっても、その測定結果はブレてしまう。

　そのうえ最近は、フレームワークやソフトウエア部品の利用が進んでいる。開発支援ツールによるコードの自動生成も普及してきた。こうした「書かないコード」はどう数えるのか。さらに保守開発の場合にステップ数をどうするかなど、ベテランでさえ意見が分かれるところが少なくない。

　富士通の合田氏は、自らの経験からステップ数の現実的な計測ルールを作成している（図2）。構文上の開閉カッコや文末記号の行は、文法上必要な行と考え1行と見なす。スクリプトやHTML、SQLといったコードもきちんと数える。「これらは実装の仕方や記述の巧拙で差が出やすいが、多少は割り切ることも必要」と合田氏は言う。

図2●技法がカバーしていない部分を補う

LOC法には標準的な計測ルールがない。富士通の合田氏は自らの経験から、その判断基準を作成。ISOで定義したコーディング規約やIPA/SECがまとめたコーディング作法ガイドなどに則ったコードが前提となる

[画像のクリックで拡大表示]

　逆に計測しない行として、開発支援ツールが自動生成したコード、ソフトウエア部品のコードなどを挙げる。労力をかけたコードを数えるのが基本と考えるためだ。コメント行や、デバッグをしやすくするために記述したコードも数えない。計測するのは、処理に直接関係する、命令行や宣言行、データ定義行（変数、定数定義など）といった行に限定する。

　難しいのが「保守開発」のステップ数である。修正する個所としない個所があるほか、修正する部分も修正の度合いはバラバラ。削除する場合はどうするかなども悩ましい。

　合田氏は「修正内容によって計測方法を分ける」と説明する。新規追加部分はもちろんカウントするが、書き換えの部分もカウントの対象とする。削除部分については、単独行の場合はそのままカウントし、連続した複数行の場合は2行（削除部分の始めと終わり）とカウントするという。

早い段階で技法が適用しづらい 情報不足でも計測できるよう改良

　要件があいまいな中で、ソフトウエアの大きさを推測するのは難しい。しかし、見積もりの現場で必要な情報がそろっていることはあまりない。見積もり時期が早くなるほど、その傾向は強くなる。それぞれの技法には必要な情報が決められているが、それが不足している状態ではその技法は使いにくい。技法が使いにくければ、アレンジしてしまうのも一つの方法だ。

　NECソフトの高山利彦氏（第二建設業SIグループ 建設業コンサルタント 建設基幹業務アプリケーションエキスパート）は、見積もりの初期段階でFP法を適用しづらいことに悩んでいた。「初期段階ではDFDやE-R図などほとんどない。IFPUG法を使ってFP数を出すのはほぼ不可能」（高山氏）。

　IFPUG法では「内部論理ファイル（ILF）」「外部インタフェース・ファイル（EIF）」など五つの機能を計測する。これをDFDやE-R図などから抽出するが、これらの詳細な仕様がそろうのは基本設計が完了した時点だ。

　初期段階でもFP数を推測できる「NESMA法」と呼ぶ技法もある。だがILFとEIFの数から全体のFP数を推測するため、どうしても精度が粗いという問題がある。

　それならと、高山氏は自らの経験をベースに、従来のFP法をアレンジした（図3）。独自に考案した方法は、初期段階でも入手しやすい機能一覧さえあれば計測できる。

図3●早い段階で技法を適用できるようアレンジする

FP法にはいくつかの種類があるが、情報が足りない初期段階ではIFPUG法が適用しづらい。NESMA法などのFP試算法では精度が粗くなる。NECソフトの高山氏は、自らの経験をベースに初期段階で簡易にFP数を算出できるテーブルを作成した

[画像のクリックで拡大表示]

　具体的にはまず、機能一覧から画面、バッチ、帳票、インタフェースという四つの機能を抽出し、それぞれ新規か変更かを特定する。次に各機能の複雑度を5段階で評価。あとは機能別に用意したテーブルに当てはめてFP数を算出する。今のところ「建設業に限定されるのかもしれないが、見積もり結果を検証するとIFPUG法の結果とほとんど差がない」と言う。