基本情報のファンクションポイント法を例題で理解する規模・工数・費用の計算

基本情報のファンクションポイント法は、機能を数えて終わる問題と、その規模から開発工数や費用を求める問題を分けると整理できます。最初に出るFPはソフトウェアの機能規模であり、そのまま人数や開発期間になるわけではありません。

この記事では、外部入力・外部出力・外部照会・内部論理ファイル・外部インタフェースファイルの5分類を、予約システムの例で見分けます。その後、件数と重みの集計、生産性の単位に合わせた工数の計算、費用への換算を練習します。数字と重みは教材用の仮定です。過去問の転載や実際の開発案件の見積りではありません。

基本情報のファンクションポイントの5分類

FPで測る規模と境界を押さえる

ファンクションポイントは、利用者が求め、利用者に提供される機能の量を測る尺度です。ソースコードの行数のような物理的な大きさとは視点が違います。IFPUGのFPA公式説明では、入力・出力・照会・内部データ・外部インタフェースデータを構成要素として示しています。

たとえば、予約の登録、予約状況の確認、利用料金の集計という機能を提供するシステムを考えます。別のプログラミング言語で作り直しても、利用者が必要とする機能が同じなら、機能規模を比較するための土台は保てます。一方、同じ機能を完成させるのに必要な作業時間まで同じになるとは限りません。規模の測定と、開発するチームの生産性を分けて考えましょう。

分類の前に、どのアプリケーションを測るのかという境界を決めます。ここでは施設の予約システムだけを計測対象とし、会員管理システムは対象外とします。「内部」「外部」は、この境界との関係を表す言葉です。社内で使うシステムだから全部内部、インターネット経由だから全部外部、という区別ではありません。

同じ会員データでも、会員管理システムの側から見る場合と、参照するだけの予約システムの側から見る場合では扱いが変わります。まず図の中央に計測対象を書き、利用者と連携先を周囲に置くと、入力・出力の方向やデータを管理する責任が見えやすくなります。

基本情報のマネジメント分野全体とのつながりを確認したい場合は、マネジメント系の頻出テーマと学習の整理も併せて読むと、見積りが工程管理のどこに関わるかを把握できます。

5機能は処理とデータに分ける

5つの名前を一度に暗記するより、処理を表す3種類と、データのまとまりを表す2種類に分けると理解しやすくなります。次の表は判断の出発点です。実際の計数では、境界や利用者要件を確認してから機能を識別します。

種類	見る対象	教材用の例
外部入力（EI）	外から入るデータ・制御情報を処理し、内部データの維持管理や振る舞いの変更を主目的とする処理	予約内容を受け取り、予約情報を登録する
外部出力（EO）	利用者への情報提供を主目的とし、計算・導出データの生成などを伴う処理	利用料金を計算して月次集計を表示する
外部照会（EQ）	データを取り出して情報を提供する処理。計算や導出データの生成、内部データの維持管理などを伴わない	予約番号で既存の予約内容を検索する
内部論理ファイル（ILF）	計測対象のアプリケーションが維持管理する、利用者が認識できる論理的なデータのまとまり	予約システムが登録・変更する予約情報
外部インタフェースファイル（EIF）	計測対象は参照し、別のアプリケーションが維持管理する論理的なデータのまとまり	会員管理システムが更新し、予約側は参照する会員情報

外部入力は、入力欄のある画面すべてを意味するわけではありません。予約番号を入力して予約内容を表示するだけなら、主目的は照会です。文字を入力する操作だけを見てEIと決めず、その一連の処理が何を実現するのかを見ます。予約の登録なら、データを維持管理する目的が判断の理由になります。

外部出力と外部照会は、どちらも境界の外に情報を示す処理です。表示先が画面か、帳票か、連携先かという見た目だけで区別しません。利用者への情報提供が主目的で、その処理中に料金合計などを計算するならEOを考えます。既存情報を取得して示すだけならEQを考えます。

ILFとEIFは、登録ボタンや検索ボタンの処理そのものではなく、処理が扱うデータのグループです。予約登録というEIと、維持管理される予約情報というILFは、違う種類の機能です。同じ業務に関わっていても、処理とデータを同じ行に混ぜると数え落としや重複の原因になります。

用語の定義は、慶應義塾大学掲載のJIS X 0142：2010用語一覧で確認できます。ここでは試験学習に必要な判断を説明しており、この表だけで標準の厳密な計数手順をすべて代替できるものではありません。

外部出力と外部照会の違い

「外に表示される」という理由だけでEOを選ぶと、EQとの区別がつきません。比較するときは、出力の形式よりも、その処理の中で新しい値を計算・生成しているかを先に確認します。入力欄があっても、検索結果を得るための条件入力なら、その入力と結果表示を含めた照会処理として考えます。

教材用の比較として、予約番号に一致する氏名・利用日時・保存済みの料金を取り出して表示する処理を考えます。ここでは計算もデータ更新もないと仮定するため、EQです。保存済みの料金が過去に計算された値でも、今回の表示処理がそれを取り出すだけなら、「料金が出るから計算あり」とは判断しません。

これに対し、利用時間に時間単価を掛け、その場で合計金額を算出して表示する処理は、情報提供に計算を伴うためEOとします。見た目が同じ料金確認画面でも、「保存された金額を読む」のか「今回の処理で金額を計算する」のかで判断の理由が変わります。

並べ替えや条件による抽出があるからといって、直ちにEOになるわけではありません。IFPUGのiTip07は、EOとEQを区別する際の導出データや処理ロジックを具体的に説明しています。また、現在の説明ではEOの判断に内部データ更新や振る舞いの変更も関わるため、「計算がなければ必ずEQ」と単独の条件だけで決めないようにしましょう。

分類問題では、問題文にある「取得するだけ」「合計を求める」「情報を更新する」を拾います。書かれていない計算や保存処理を想像して足すと、提示された条件から離れてしまいます。説明が足りない仕様を実務で扱う場合は、目的と処理内容を確認する必要がありますが、教材の例では前提を明示して判断します。

画面数やテーブル数だけで数えない

機能の手掛かりを探すとき、画面や帳票、データの一覧は役立ちます。ただし、画面1枚が必ず1機能、テーブル1個が必ず1つのILFという換算ではありません。画面の区切りは見た目や実装の都合でも変わり、論理的な機能の区切りと常に一致するとは限らないからです。

たとえば、予約を登録するために入力画面、確認画面、完了画面の3枚を表示する設計でも、それだけで外部入力が3つあるとは決められません。逆に、同じ画面から登録と取消しを行える設計でも、利用者にとって異なる処理を提供しているかを検討します。画面の枚数と、完結した意味のある処理の数を区別します。

データも同様です。予約の基本情報と予約明細を複数の物理テーブルに分けていても、利用者要件からどういう論理的なグループになるかを確認します。保存先のサーバやディスクの場所だけを見て、ILFとEIFを決めるものでもありません。EIFでは、別のアプリケーションが維持管理するデータを計測対象が参照するという関係が大切です。

利用件数と機能数も違います。1日に予約登録が300回実行されても、「予約登録という種類の機能が300個増えた」とは考えません。取引量や利用者数は性能や運用条件に関わりますが、機能の個数と同じ数として足し込まないようにします。機能の種類を数える表なのか、業務処理の実行回数を示す表なのかを読み分けてください。

要素処理の考え方と境界については、IFPUG公式のサンプル問題でも、利用者にとって意味があり完結した処理かどうかが扱われています。単にボタンを押す回数やAPIの呼出し回数を合計する方法、と覚えるのは避けましょう。

予約システムを分類する例題

次はこの記事独自の分類練習です。予約システムを境界とし、表の各行は互いに独立した処理または論理的データのグループとして識別済み、と仮定します。実在のシステムの測定結果ではありません。まず「処理なのかデータなのか」、続いて「目的は何か」を説明してから分類してみてください。

対象	教材用の前提	分類と理由
予約登録	境界外から予約内容を受け取り、予約情報を追加することが主目的	EI。内部データの維持管理を主目的とする処理
予約内容の検索	予約番号で既存情報を取得して表示。計算・導出・更新・振る舞い変更なし	EQ。取得による情報提供が主目的
月次利用料金集計	対象予約の料金を合計し、月次合計を表示する	EO。情報提供の処理に計算を含む
予約情報	予約システムの処理が追加・変更・削除する論理グループ	ILF。計測対象が維持管理するデータ
会員情報	会員管理システムだけが維持管理し、予約側は参照する	EIF。別アプリケーションが維持管理するデータ

検索処理と会員情報を同じものとして扱わない点も確認しましょう。会員情報を検索して利用者に示す処理は、前提によってEQなどの処理機能です。参照される会員情報はEIFというデータ機能です。処理が読んだデータを、外から来たという理由だけでEIに分類すると、処理とデータの軸が混ざります。

この表に予約取消しを加えるなら、取消しが予約情報の削除や状態変更を主目的とするという前提を確認します。その条件ならEIと考えられます。ただし、実際の全機能の計数では他の処理と区別される要素処理かどうかも必要です。「操作名が違うので自動的に1件追加」と機械的に増やすのではなく、問題が識別済みの機能数を与えているかも読みます。

学習では、名前を当てるだけでなく「予約情報を更新するのでEI」「既存値を取り出すだけなのでEQ」と理由を短く書くと効果的です。理由を言えないときは、境界、主目的、計算の有無、データの維持管理先のどこが不明なのかを見直してください。

基本情報のファンクションポイントの計算

件数と重みを掛けて集計する

計算問題は、機能の種類ごとに件数×重みを計算し、その値を合計するのが出発点です。複雑度別に行が分かれていれば、それぞれを別々に掛けます。最初に件数を全部足してから、重みを一つだけ掛ける方法では、種類ごとの違いを反映できません。

以下は教材用に作った、識別済みの機能数と重みの表です。各種類の機能は同じ重みを使うと仮定します。ここで使う3、5、4、8、6という数値は、この練習のために与えた条件です。IFPUG標準の低・中・高複雑度の重み表として覚えるものではありません。

機能	識別済み件数	問題で与える重み	小計
EI	6	3	6×3＝18FP
EO	4	5	4×5＝20FP
EQ	3	4	3×4＝12FP
ILF	2	8	2×8＝16FP
EIF	1	6	1×6＝6FP

未補正の合計は、18＋20＋12＋16＋6＝72FPです。機能数は6＋4＋3＋2＋1＝16件ですが、72FPとは別の値です。件数に重みを付ける前と付けた後の数字を、途中式の横に書き分けておくと、選択肢での取り違えを防げます。

この練習でさらに「合計に補正係数0.90を掛ける」と与えられた場合は、72×0.90＝64.8FPです。設問が求める値が未補正なのか補正後なのかを確認します。補正の指定がない問題に係数を自分で追加しません。係数の掛け忘れだけでなく、各行を補正してから合計を再び補正する二重適用にも注意してください。

厳密な標準の複雑度判定では、処理機能とデータ機能に応じて、データ項目や参照先、レコードの論理的なグループなどを確認します。IFPUGの早期FPAと費用見積りの資料も、詳細計測と、仮定を置いた概算を区別しています。試験の計算練習では、表に与えられた重みを使うことと、標準の判定規則から重みを決めることを分けてください。

たとえば、同じEIでも低複雑度が4件、中複雑度が2件と分けられ、教材用の重みがそれぞれ3と4なら、4×3＋2×4＝20FPです。件数6に重み3を掛けた18FPではありません。表の行の見落としが原因なので、複雑度が分かれているときは種類の名前だけで行をまとめないようにしましょう。

生産性の単位から式を選ぶ

FPの次に工数を求める場合は、生産性などとして与えられた値の単位を見ます。FP／人月なら1人月で作れる機能規模、人月／FPなら1FPに必要な工数です。どちらも見積りに使う比率ですが、数値が大きいときの意味と、掛け算・割り算の方向が逆になります。

問題で与えられる比率	意味	工数の求め方
12FP／人月	1人月で12FPを開発できる	FP÷12FP／人月
0.08人月／FP	1FPに0.08人月が必要	FP×0.08人月／FP
4人時／FP	1FPに4人時が必要	FP×4人時／FP

先ほどの補正後規模64.8FPを、12FP／人月で開発する教材用の条件なら、64.8÷12＝5.4人月です。式に単位を付けると、64.8FP÷（12FP／人月）となり、FPが消えて人月が残ります。欲しい答えの単位になるかを確認すれば、「生産性だから必ず掛ける」といった暗記に頼らずに済みます。

逆に1FP当たりの工数が1／12人月／FPと与えられた場合は、64.8×（1／12）＝5.4人月となります。12FP／人月と1／12人月／FPは同じ関係を逆から表しています。途中で1／12を0.08に丸めると64.8×0.08＝5.184人月となり、別の答えになります。丸めの指示がない限り、途中の精度を不用意に落とさないでください。

確認用に、規模96FP、生産性16FP／人月なら96÷16＝6人月です。同じ96FPに対し、0.0625人月／FPなら96×0.0625＝6人月です。逆数の条件を使った2通りの式が一致することを、自分で計算してみると単位の理解を確かめられます。

一般にFP／人月の値が大きくなると、同じ規模に必要な工数は小さくなります。一方、人月／FPの値が大きくなると、必要な工数は大きくなります。「生産性が20％向上」という表現を使う設問でも、何を向上と定義しているかを読みます。FP／人月が1.2倍になる条件なら、工数は元の1／1.2倍であり、単に20％減になるとは限りません。

工数・期間・費用を順に求める

工数は延べ作業量、期間は開始から終了までの時間、費用は金額です。工数が5.4人月と分かっても、それだけで開発期間が5.4か月と決まるわけではありません。1人が何か月働くかという積と、カレンダー上で何か月かかるかという量を分けましょう。

教材用の条件として、3人が期間中ずっと同じ稼働率で担当し、全作業を均等に並行化できると仮定します。このとき期間は5.4人月÷3人＝1.8か月です。実際の開発でこの式をそのまま納期の保証に使えるわけではありません。前の作業が終わるまで着手できない工程などがあれば、人数を増やした分だけ短くなるとは限らないためです。

費用は、同じ工数に人月単価を掛ける条件なら求められます。単価を教材用に80万円／人月と仮定すると、5.4人月×80万円／人月＝432万円です。この数字は相場の説明ではありません。サーバ費用、購入費用、利益、税などを含めるかどうかも、この練習では追加条件がないため計算しません。

段階	教材用の式	答え
機能規模の集計	18＋20＋12＋16＋6	72FP
指定された補正	72×0.90	64.8FP
工数への換算	64.8÷12	5.4人月
均等並行化の仮定で期間へ換算	5.4÷3	1.8か月
人月単価による費用計算	5.4×80万円	432万円

費用を期間1.8か月×80万円として144万円にすると、3人分の作業量が落ちています。期間から計算するなら、1.8か月×3人×80万円／人月＝432万円と人数も含めます。工数5.4人月を使えば、その中に人数の分がすでに含まれているので、さらに3人を掛けません。

人時・人日・人月を換算する場合は、問題に示された稼働時間の条件を使います。たとえば、64.8FP、4人時／FPなら259.2人時です。教材用に1人日＝8人時、1人月＝20人日とすると、259.2÷8＝32.4人日、32.4÷20＝1.62人月です。暦の1か月を一律30日として換算すると、設問の作業日数と合わなくなることがあります。

FPが分かれば実務の費用が自動的に一意に決まる、という理解も避けましょう。IPAのソフトウェア改良開発見積りガイドブックは、生産性の前提や開発条件の影響も扱っています。試験では与えられた比率で計算し、実務では対象工程や条件に合う実績を使うという違いがあります。

期間や工程の関係をもう少し整理したい場合は、WBS・ガントチャート・EVMの役割と読み方が関連します。FPは機能規模、WBSは作業の分解という見ている対象の違いを理解すると、名称を選ぶ問題でも整理しやすくなります。

誤答を見抜く計算練習

ここからは答えを見る前に、途中式と単位を書いて解いてみてください。すべてこの記事独自の教材用問題です。各表の数値、補正、比率、単価は実際の案件の測定値や市場価格を示すものではありません。

集計と補正の練習

問題：識別済みの機能がEI4件、EO3件、EQ2件、ILF1件、EIF0件で、教材用の重みは順に3、5、4、8、6です。合計に補正係数0.80を掛けた値を求めます。選択肢は、ア：10、イ：34.4、ウ：43、エ：53.75です。

正解はイの34.4FPです。小計は4×3＝12、3×5＝15、2×4＝8、1×8＝8、0×6＝0。合計43FPに0.80を掛け、43×0.80＝34.4FPとなります。0件のEIFは寄与も0です。重み6だけを足し込まないようにしましょう。

アの10は機能の件数だけの合計です。ウの43は補正前の集計で止まった答えです。エの53.75は43÷0.80としてしまった答えです。誤答の値がどの計算から出たかを確認すると、件数とFPの取り違え、補正の掛け忘れ、補正方向の誤りを区別できます。

生産性と費用の練習

問題：規模120FPを、15FP／人月の生産性で開発します。全員が同じ稼働率で均等に並行化できると仮定した4人のチームについて、工数・期間を求めます。さらに、人月単価を教材用に75万円とした場合の費用を計算してください。補正は追加しません。

工数は120÷15＝8人月、期間は8÷4＝2か月、費用は8×75＝600万円です。120×15＝1,800と掛け算をした値は、工数の単位になりません。期間2か月×75万円＝150万円も4人分を含めていないので誤りです。工数の8人月にさらに4人を掛けると、人数を二重に計上してしまいます。

同じ規模で生産性だけが15から20FP／人月に上がる条件なら、工数は120÷20＝6人月です。8人月から6人月への変化は2人月減、減少率は2÷8＝25％です。生産性は5÷15で約33.3％増ですが、工数の減少率まで約33.3％にはなりません。割合は「どの量のどの値を基準にするか」を書き分けます。

逆算と端数処理の練習

問題：許容工数が10人月、生産性が18FP／人月です。この教材用の単純な比例モデルで扱える規模を求めます。答えは10×18＝180FPです。欲しい値がFPなので、人月とFP／人月を掛けて人月を消します。工数を求める式をそのまま使って10÷18としないでください。

費用上限が800万円、人月単価80万円なら、工数上限は800÷80＝10人月です。同じ生産性18FP／人月なら180FPという計算につながります。ただし、これは固定費などを含まない教材の条件です。実際の予算で何FPの機能を契約できるかまで、この数字だけで保証するものではありません。

端数のある期間では、丸め方も設問に従います。工数7人月を3人で均等に担当するなら7÷3＝約2.33か月です。「月単位で切り上げる」とあれば3か月ですが、小数で答える問題なら勝手に3か月へ変えません。丸めの指定、単位、選択肢の桁を最後に確認します。

解き直すときは、間違えた答えを消すだけでなく「補正前で止めた」「FP／人月を掛けた」「工数と期間を混同した」と原因を一言添えます。原因に対応する途中式を次回から残せば、似た問題で数字だけが変わっても修正した解き方を使えます。

基本情報のファンクションポイントまとめ

基本情報のファンクションポイントは、まず計測対象の境界を決め、処理のEI・EO・EQと、データのILF・EIFを分けるのが出発点です。画面数やテーブル数をそのまま機能数にせず、主目的、処理内容、データの維持管理先を確認します。

計算では、件数×重みを行ごとに求めて合計し、指定された場合だけ補正します。次に、FP／人月なら規模を割り、人月／FPなら規模に掛けて工数へ換算します。期間は人数などの前提を確認し、費用は工数と単価を使って求めてください。

復習では、数字を替えた例題を一つ解き、答えの単位まで説明できるかを確認しましょう。分類の理由と単位がつながれば、公式を忘れても途中式を組み立てやすくなります。

この例題を解き終えたら、基本情報の他分野も含めて科目A・科目Bの過去問を演習することで、問題文から条件を拾う練習を続けられます。