対象試験と出題頻度
LOC法は、基本情報技術者・応用情報技術者で出題される「ソフトウェア見積り手法」の代表格です。
ファンクションポイント法（FP法）やCOCOMOといった他の見積り手法との違い、特に「規模をどの単位で測るか」を区別できるかが頻出ポイントになります。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★☆☆☆
ランクC（応用）余裕があれば覚える
用語の定義
情報処理試験を勉強していると、「LOC法って結局、行数を数えるだけ？それで本当に開発期間が見積もれるの？」と疑問に思いがちです。
LOC法（Lines of Code）とは、一言で言うと
「ソフトウェアの規模を、ソースコードの行数で見積もる手法」
のことです。
イメージとしては、「引っ越し業者の見積もり」です。
引っ越し業者は「段ボール何箱分か」で作業時間と料金をざっくり計算します。中身が本か服かは細かく見ません。とにかく「箱の数」という分かりやすい単位で規模を測るわけです。
LOC法も同じで、プログラムの中身が複雑かどうかは脇に置き、「コードが何行あるか」というシンプルな数字で開発の大きさを見積もります。
📊 LOC法の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Lines of Code（Source Lines of Code：SLOC） |
| 分類 | ソフトウェア規模見積り手法（プログラムステップ法） |
| 主な利用工程 | 開発計画・工数見積り |
| 単位 | 行（ステップ）、KLOC（1,000行単位） |
| 別名 | プログラムステップ法、ソースコードステップ法 |
解説
ソフトウェア開発の現場では、契約前に「この案件は何人月かかるのか」「いくらで請けられるのか」を見積もる必要があります。しかし、まだコードを書いていない段階で工数を予測するのは難しい作業です。
そこで古くから使われてきたのが、過去の類似プロジェクトのコード行数を物差しにして「今回もだいたい同じ規模なら、これくらいの工数になる」と推定する考え方です。
これがLOC法の出発点です。
基本の計算式
LOC法では、見積り行数と1人月あたりに書ける行数（生産性）から工数を求めます。
📐 LOC法の基本式
工数（人月） ＝ 総ステップ数 ÷ 1人月あたりの生産性
例：総ステップ数 10,000行 ÷ 生産性 500行/人月 ＝ 20人月
行数の数え方には流派がある
「1行」と一口に言っても、何を1行と数えるかで結果が変わります。代表的な数え方は次のとおりです。
| 数え方 | 内容 |
|---|---|
| 物理LOC | 空行・コメントを含む全行数。最も単純だが冗長になりやすい |
| 論理LOC | 実行可能なステートメントだけを数える。空行・コメントは除外 |
| 有効ステップ数 | コメント・宣言文を除いた実行ロジック部分のみ。日本の現場で多用 |
// 数え方の違い（C言語例）
#include <stdio.h> ← 宣言文
← 空行
// 合計を表示する関数 ← コメント
int sum(int a, int b) {
return a + b; ← 実行ステートメント
}
物理LOC＝6行 ／ 論理LOC＝3行 ／ 有効ステップ数＝2行
メリットとデメリット
⭕ メリット
・概念がシンプルで誰でも理解できる
・過去実績との比較が容易
・自動カウントツールで機械的に集計できる
❌ デメリット
・プログラミング言語によって行数が大きく変わる
・コードの品質や難易度が反映されない
・設計段階では正確な行数を予測しにくい
他の見積り手法との比較
LOC法を正しく位置づけるには、他の代表的な見積り手法と「何を物差しにするか」で整理するのが近道です。
| 手法 | 物差し | 特徴 |
|---|---|---|
| LOC法 | ソースコードの行数 | 単純で分かりやすいが、言語依存が強い |
| FP法 | 利用者から見た機能数 | 言語に依存しない。要件定義段階でも算出可能 |
| COCOMO | 予測LOC＋補正係数 | LOC法を母体に、難易度・チーム経験を係数で補正 |
| 類推法 | 過去の類似案件 | 経験頼み。プロジェクト初期に有効 |
| 標準値法 | 標準工数表 | 組織内の標準値を参照して算出 |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 LOC法の核心を3行で
・ソースコードの行数を物差しに開発規模を見積もる手法
・「総ステップ数 ÷ 生産性」で工数（人月）を算出する
・言語依存が強く、品質や難易度が反映されないのが弱点
試験ではこう出る！
LOC法は、FE・APの午前問題で「ソフトウェア見積り手法」の選択肢として登場します。単独で深く問われるよりも、FP法・COCOMOとの違いを問う形で出題されることが多いのが特徴です。
📊 過去問での出題パターン
| 出題形式 | 問われる内容 | ひっかけの傾向 |
|---|---|---|
| 手法の説明選択 | 「ソースコードの行数で規模を見積もる手法はどれか」 | FP法（機能数）、COCOMO（補正係数）、類推法を混在させる |
| 計算問題 | 総ステップ数と生産性から工数を算出 | 単位（KLOC vs LOC）の取り違えを誘う |
| 欠点を問う | 「LOC法の課題として正しいものはどれか」 | 「言語に依存しない」という逆の記述で誤答を誘う |
📝 押さえるべきキーワード
キーワード①：「行数」「ステップ数」
選択肢に「行数」「ステップ数」が出てきたら、ほぼLOC法（プログラムステップ法）が答えです。FP法には「機能」「画面・帳票」「外部入出力」が登場します。
キーワード②：「言語依存」
LOC法の弱点として「プログラミング言語ごとに同じ機能でも行数が変わる」点が問われます。逆に「言語に依存しない」と書かれていればそれはFP法の説明です。
ここだけは確実に押さえてください。試験では計算式の暗記よりも「何を物差しにするか」という識別力が問われます。深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェアの規模見積り手法であるLOC法の説明として、最も適切なものはどれでしょうか？
- A. 利用者から見た機能の数（外部入出力、内部論理ファイルなど）に重み付けをして規模を算出する手法。
- B. 過去の類似プロジェクトの実績データを参考に、専門家の判断で工数をざっくり推定する手法。
- C. ソースコードの行数（ステップ数）を見積もり、生産性で除して開発工数を算出する手法。
正解と解説を見る
正解：C
解説：
LOC法はソースコードの行数（ステップ数）を物差しにして規模を測り、「総ステップ数 ÷ 生産性」で工数を算出するため、Cが正解です。プログラムステップ法とも呼ばれます。
選択肢Aはファンクションポイント法（FP法）の説明です。FP法は機能の数とその複雑度から規模を求める手法で、行数ではなく「ユーザーから見た機能」を物差しにします。選択肢Bは類推法（類推見積り）の説明です。過去の類似案件の実績を参照する経験ベースの手法であり、行数を直接の指標とするLOC法とは異なります。
よくある質問（FAQ）
Q. LOC法は今でも実務で使われていますか？
使われていますが、単独ではなく補助的な役割が中心です。受託開発の見積りではFP法やCOCOMO、アジャイル開発ではストーリーポイントが主流になっています。一方で、社内の生産性指標やリファクタリング前後の規模比較には今も活用されており、SonarQubeやcloc等のツールで自動計測する現場が一般的です。
Q. 同じ機能でもJavaとPythonで行数が違うとき、どう扱いますか？
言語別の生産性係数（言語係数）を使って補正します。例えばPythonはJavaより少ない行数で同じ機能を実装できる傾向があるため、過去実績から「言語ごとの1機能あたり平均行数」を持っておき、それを掛けて換算します。COCOMO IIではこうした言語補正が組み込まれています。なお、この弱点こそがFP法が登場した直接の理由です。
Q. KLOCとMLOCはどう違いますか？
どちらもLOCに接頭辞を付けた単位です。KLOC（キロLOC）は1,000行単位、MLOC（メガLOC）は100万行単位を表します。中規模の業務システムが数十KLOC、大規模OSやブラウザのソースコードはMLOCオーダーになります。試験ではKLOCがほぼ全てで、MLOCはあまり登場しません。
Q. 自動生成されたコードや外部ライブラリも行数に含めますか？
原則として含めません。LOC法が測りたいのは「人が書いた開発工数」のため、IDEが自動生成するゲッター・セッターやフレームワーク標準のテンプレートコード、import済みのオープンソースライブラリは集計対象外にするのが一般的です。組織やプロジェクトによってルールが異なるため、見積り前にカウント基準を文書化しておくことが重要です。
