ソフトウェアの見積り
ソフトウェアの見積りとは
Section titled “ソフトウェアの見積りとは”ソフトウェアを開発するとき、「どれくらいの規模になるのか」「何人で何か月かかるのか」「費用はいくらか」をあらかじめ予測する作業が見積りです。見積りが不正確だと、予算オーバーやスケジュール遅延といった深刻な問題につながるため、プロジェクトの成功に欠かせないステップです。
見積りでは、おもに次の4つの要素を検討します。
| 見積り要素 | 意味 | 例 |
|---|---|---|
| 開発規模 | ソフトウェアの大きさ（機能の量やコードの量） | 画面数30、帳票10種類 |
| 開発工数 | 作業量（人数 × 期間） | 10人月（1人なら10か月分の作業量） |
| 開発期間 | 開発に必要な日数・月数 | 6か月 |
| 開発環境 | 開発に使用するツールや設備 | プログラミング言語、開発用PC、テスト環境 |
開発規模が大きいほど開発工数が増え、その結果として開発期間も長くなる、という関係を押さえておきましょう。また、開発環境（使用する言語やツール）によって生産性が変わるため、同じ規模でも工数や期間は変動します。
試験で出るポイント
「開発規模」「開発工数」「開発期間」は混同しやすい用語です。「規模＝大きさ」「工数＝作業量」「期間＝時間」と区別して覚えておきましょう。
以下の図は、「何を基準に規模を測るか」という問いから、適切な見積り手法を選ぶ流れを示したものです。これから紹介する各手法の位置づけを、まず全体像として把握しておきましょう。
graph TB
Q{"何を基準に<br>規模を測るか？"}:::primary
A["コード行数<br>（ステップ数）"]:::base
B["機能の数と<br>複雑さ"]:::base
C["過去の<br>類似実績"]:::base
D["他タスクとの<br>比較"]:::base
R1["ステップ数見積り<br>（KS単位）"]:::alert
R2["ファンクション<br>ポイント法"]:::alert
R3["類推見積法"]:::alert
R4["相対見積<br>（ストーリーポイント）"]:::alert
Q --> A --> R1
Q --> B --> R2
Q --> C --> R3
Q --> D --> R4
classDef base fill:#f8fafc,stroke:#94a3b8,stroke-width:1px,color:#333;
classDef primary fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e40af;
classDef alert fill:#fef2f2,stroke:#dc2626,stroke-width:2px,color:#991b1b;
開発規模の測り方
Section titled “開発規模の測り方”見積りの出発点は「開発規模をどう測るか」です。規模の測り方には大きく2つのアプローチがあります。
1つ目は、プログラムのコード行数（ステップ数）で測る方法です。規模を表す単位としてKS（キロステップ）が使われます。1KSは1,000行（1,000ステップ）のことです。たとえば「このシステムは50KS」と言えば、プログラムの総行数が約50,000行であることを意味します。
2つ目は、ソフトウェアが持つ「機能」の数と複雑さで規模を測る方法で、これが次に紹介するファンクションポイント法です。
ファンクションポイント（FP）法
Section titled “ファンクションポイント（FP）法”ファンクションポイント（FP：Function Point）法は、ソフトウェアが提供する機能の数と複雑さをもとに開発規模を見積もる手法です。プログラムのコード行数ではなく、利用者から見た「機能」に着目するのが大きな特徴です。
具体的には、次のような機能の種類ごとに数を数え、それぞれの複雑さに応じた点数（ポイント）を付けていきます。
- 入力機能（データの登録画面など）
- 出力機能（帳票の印刷、レポート出力など）
- 照会機能（データの検索・表示など）
- 内部ファイル（システム内部で管理するデータベースなど）
- 外部インタフェース（他システムとのデータ連携など）
たとえば、ある販売管理システムに「商品登録画面（入力）」「売上レポート（出力）」「在庫照会画面（照会）」がそれぞれ複数あれば、各機能の数と複雑さを点数化して合計します。この合計がファンクションポイントであり、開発規模の指標となります。
ファンクションポイント法は、プログラミング言語に依存しないため、異なる言語で開発するプロジェクト同士でも規模を比較できるという利点があります。一方、KS（コード行数）による見積りは、使用する言語によって同じ機能でも行数が大きく異なるため、言語をまたいだ比較には向きません。
| 比較項目 | ファンクションポイント法 | コード行数（KS）による見積り |
|---|---|---|
| 着目する点 | 機能の数と複雑さ | プログラムの行数 |
| 言語依存 | なし（言語に左右されない） | あり（言語で行数が変わる） |
| 開発前の見積り | しやすい（機能は要件定義で把握可能） | しにくい（コードを書くまで正確な行数は不明） |
試験で出るポイント
ファンクションポイント法は「機能の数と複雑さ」で規模を測る手法です。「コードの行数で測る」という選択肢は誤りですので注意しましょう。
類推見積法は、過去に開発した類似のプロジェクトの実績データをもとに、今回のプロジェクトの規模や工数を見積もる手法です。
たとえば、以前に開発した「顧客管理システム」が画面数20で開発工数15人月だったとします。今回「受注管理システム」を開発するにあたり、画面数や機能が似ていれば「前回と同じくらいの規模だから、今回も15人月程度だろう」と見積もるのが類推見積法です。
この手法は、過去の経験を活かせるため、短時間で見積りができるのがメリットです。ただし、見積りの精度は過去データの質や見積り担当者の経験に大きく左右されるため、属人性が高い（特定の人の経験に依存しやすい）という点に注意が必要です。
相対見積は、タスクの規模を絶対的な数値（時間や行数）ではなく、他のタスクとの比較によって見積もる手法です。
たとえば、基準となるタスクAの規模を「1」としたとき、タスクBが「Aの2倍くらいの大きさ」であれば「2」、タスクCが「Aの半分くらい」であれば「0.5」とする、といった具合です。アジャイル開発では、「ストーリーポイント」という単位を使って相対見積を行うことが一般的です。
相対見積のメリットは、絶対的な工数を正確に見積もることが難しい段階でも、タスク同士の大小関係を把握できる点にあります。「このタスクは前回のあの作業の何倍くらいか」という感覚的な判断で見積もれるため、チーム全体で合意を得やすいのも特徴です。
ソフトウェア開発では、完成したプログラムの品質を管理することも重要です。品質を評価する指標の一つに不良密度があります。
不良密度とは、開発規模あたりに発見された不良（バグ）の数を表す指標です。たとえば「1KSあたり5件のバグが発見された」という場合、不良密度は5件/KSとなります。
不良密度が極端に高い場合は品質に問題がありますが、逆に極端に低い場合も「テストが不十分でバグを見つけきれていないのではないか」と疑う必要があります。
試験で出るポイント
この分野はシラバスに記載がある一方で、過去の出題実績は少ない範囲です。「ファンクションポイント法＝機能で測る」「類推見積法＝過去の類似実績を使う」「相対見積＝他タスクとの比較で測る」という各手法の定義を正確に押さえておけば対応できます。