目次
システム開発やWebアプリ構築のプロジェクトを立ち上げるとき、必ず直面するのが「開発コスト（人件費・工数）の見積もり」です。
「システムの見積もりってどうやって計算しているの？」「プログラムステップ法とファンクションポイント法の違いは何？」と疑問に思ったことはありませんか？
見積もり手法を誤ると、予算オーバーや納期の遅延、最悪の場合はプロジェクト破綻につながります。また、基本情報技術者・応用情報技術者試験やITプロデュースの実務においても必須の知識です。
この記事では、伝統的な「プログラムステップ法（LOC法）」と、現在の標準手法である「ファンクションポイント法（FP法）」の仕組み、違い、身近な例え（アナロジー）、そして2026年現在のAIコーディング時代における最新の見積もり実務まで、分かりやすく徹底解説します。
1. システム開発の見積もりとは？なぜ工数計算が重要なのか
システム開発にかかるコストの大部分は、エンジニアやデザイナーが動く人件費（人月：1人が1ヶ月作業する単位）です。そのため、開発コスト＝「作業に必要な工数」をどのように精度高く見積もるかが重要になります。
- プログラムステップ法（LOC法）： プログラムの「行数（量）」をベースに計算する方式。開発者・コード視点。
- ファンクションポイント法（FP法）： 画面や帳票など「システムの機能数と難易度（質）」をベースに計算する方式。ユーザー・発注者視点。
2. プログラムステップ法（LOC法）の仕組みとデメリット
プログラムの行数で工数を計算する手法
プログラムステップ法（Program Step Method）は、作成するプログラムのソースコード行数（LOC：Lines of Code）を予測し、過去の生産性データ（例：1人月あたり1,000行）を掛け合わせて工数・コストを見積もる手法です。
例えば、過去の類似事例から「全体で10,000行のプログラムになる」と予測され、開発者の平均生産性が「1ヶ月に2,000行」であれば、10,000 ÷ 2,000 ＝ 5人月の工数が必要であると算出します。
身近な例え：原稿用紙の枚数で文章評価をする落とし穴
この手法のわかりやすい例えは、「原稿用紙の枚数で作家の執筆料やクオリティを決める」ようなものです。
文章に不慣れな初心者は無駄な言葉が多く原稿用紙10枚を費やすかもしれませんが、プロのコラムニストであれば同じ内容を原稿用紙2枚で簡潔かつ明瞭に書き上げることができます。行数が多いからといって価値が高いとは限りません。
プログラミングでも同様に、初心者エンジニアが冗長に書いた100行のコードより、熟練エンジニアがリファクタリングして綺麗にまとめた10行のコードの方が品質も保守性も優れています。行数依存の見積もりは、スキルの違いを正しく反映できないという根本的弱点があります。
プログラムステップ法のメリット・デメリット
- メリット： 計算式が極めてシンプルで、大規模なレガシーシステム（COBOLなど）で過去のコード行数データが豊富にある場合は流用しやすい。
- デメリット： 詳細設計が終わるまで正確な行数がわからない（上流工程で使えない）。プログラミング言語やエンジニアの熟練度によって行数が激変するため、見積もり精度が低い。
3. ファンクションポイント法（FP法）の仕組みとメリット
ユーザー視点の「機能数と複雑さ」で計算する手法
ファンクションポイント法（Function Point Method / FP法）は、システムが提供する「機能」の数と種類、それらの複雑さを評価してポイント（数値）化し、開発コストを算出する手法です。
プログラムの書き方ではなく、ユーザーから見えた画面入力、画面出力（帳票）、外部インターフェース、内部ファイル数などの数をもとに評価します。
① 外部入力（入力画面や設定パラメータ）
② 外部出力（画面表示や印刷帳票）
③ 外部照会（検索処理と結果表示）
④ 内部論理ファイル（システム内のデータベーステーブル）
⑤ 外部インターフェースファイル（他システムとの連携データ）
これらの要素に複雑さ（高・中・低）に応じた重み付けを行い、さらにシステムの処理環境（セキュリティ要件や通信速度など）による補正係数を掛けて最終的なファンクションポイント（FP）値を算出します。
身近な例え：注文住宅の間取りや設備数での積算
FP法の身近な例えは、「注文住宅の建築見積もりを、部屋数やキッチンの設備機能で計算する」ようなものです。
「部屋が4つ、トイレが2つ、システムキッチン1セット、床暖房あり」という機能仕様が決まれば、大工さんが使う釘の本数（＝コード行数）を細かく数えなくても概算費用を計算できます。
発注者（ユーザー）にとっても「どの機能にいくらかかるのか」が直感的に理解しやすく、双方で合意形成しやすいのが大きな強みです。
ファンクションポイント法のメリット・デメリット
- メリット： 実装前の要件定義・基本設計の段階（早期）で見積もりが可能。言語やエンジニアの腕に依存せず、客観的な妥当性を説明しやすい。
- デメリット： 各機能の複雑さの判定基準や補正計算に専門的なスキルや定型化された過去実績データが必要。
4. 2026年現在の開発現場：アジャイル・AI生成時代における見積もり実務
2026年現在の開発環境においては、単一の見積もり手法だけではなく、開発スタイルに応じた多様な見積もりアプローチが組み合わされています。
特にアジャイル開発では、ファンクションポイント法をベースにしつつも、機能ごとの相対的な開発規模を表す「ストーリーポイント（Story Point）」を用いた見積もりが一般的です。
さらに、生成AIによるコード補完やAIエージェントによる自動生成が浸透したことで、「1行書くのにかかる時間」や「定型機能の実装時間」が大幅に短縮されています。そのため、単純な行数計算（LOC法）の価値は薄れ、「ユーザー体験（UX）やビジネス価値（機能）をどれだけ満たせるか」を基準とするファンクションポイント法や類推見積もりの重要性が一層高まっています。
5. 実務・IT資格試験で使える！開発見積もり手法の比較一覧表
代表的な開発見積もり手法の比較表です。試験対策や社内での見積もり手法選定にお役立てください。
| 比較項目 | プログラムステップ法（LOC法） | ファンクションポイント法（FP法） |
|---|---|---|
| 見積もりの基準 | ソースコードの行数（ステップ数） | 外部入出力・ファイル等の「機能数」と「複雑さ」 |
| 実施可能な時期 | 詳細設計以降（製造段階に近い時期） | 要件定義・基本設計段階（上流工程） |
| 開発言語への依存 | 大きく影響を受ける（言語によって記述量が変化） | 影響を受けない（ユーザー視点で独立） |
| スキルの影響 | 技術者の熟練度により行数が変わるためブレが大きい | 機能要件で評価するためブレが少ない |
| 身近な例え | 原稿用紙の枚数で原稿料を決める | 住宅の部屋数や設備仕様で建築費を決める |
6. まとめ・参考文献
今回は、システム開発コストを見積もる代表手法「プログラムステップ法」と「ファンクションポイント法」の違いについて解説しました。
- プログラムステップ法（LOC法）： コード行数で算出。シンプルだがスキル差や言語に左右されやすい。
- ファンクションポイント法（FP法）： 機能数と難易度で算出。要件定義段階で使え、発注者にも説明しやすい現代の主流。
- 最新動向： AI時代においては行数価値が低下し、FP法やアジャイルのストーリーポイントがより重視される。
それぞれの特徴を理解し、プロジェクトのフェーズや性質に合わせた適切な見積もり手法を選択していきましょう。
