システムの規模＝コードの行数ではない？プロが使う「本質的な規模感」の測り方

システム開発の現場で、「このプロジェクトの規模感はどのくらい？」という会話は日常茶飯事です。一昔前まで、その答えは「10万ステップ（行）」や「100万ステップ」といった**コードの行数（LOC: Lines of Code）**で語られてきました。

しかし、2026年現在のソフトウェア開発において、**コードの行数を規模の主標にするのは、もはや「間違い」**と言っても過言ではありません。

なぜ行数で測ってはいけないのか？そして、代わりに何を見るべきなのか？開発の成否を分ける「規模感」の正体について解説します。

「書いた量が多い＝規模が大きい」という考え方は、直感的で分かりやすいものです。しかし、システム開発においては以下の3つの理由から、LOCは不適切な指標となります。

同じ「1から10まで画面に表示する」という機能を作るにしても、Javaで書くのとPythonで書くのとでは、行数は全く異なります。言語によって「饒舌さ」が違うため、行数で比較することに意味はありません。

エンジニアの腕が良いほど、複雑なロジックを簡潔に、共通化して記述します。

下手なエンジニア：コピペを繰り返し、1000行で実装
優れたエンジニア：美しく設計し、100行で実装この場合、行数だけで測ると「下手なエンジニアの方が大きな仕事をした」というおかしな評価になってしまいます。

2026年現在、GitHub CopilotなどのAIや、ローコード・ノーコードツールが大量のコードを自動生成します。「AIが1秒で出した1万行」と「人間が3日考え抜いた10行」を同じ重みで測ることは不可能です。

現在、特に大規模開発や見積もりの段階で最も信頼されているのがファンクションポイント（FP）法です。

これは、プログラムの内側（コード）を見るのではなく、**「ユーザーから見て、そのシステムは何ができるか？」**という外部的な機能を数える手法です。

これらを「難易度」で重み付けして合計することで、言語や個人のスキルに依存しない、**客観的な「システムの重さ」**が算出できます。

変化の速いアジャイル開発（スクラムなど）では、詳細な計算が必要なFP法よりも、**「ストーリーポイント」**という相対的な指標が好まれます。

仕組み: 「ログイン画面を作る」という作業を基準（1ポイント）としたとき、今回の「決済機能の実装」はどのくらい難しいか？を比較して、3、5、8...といった数値（フィボナッチ数列）で表します。
メリット: 正確な工数（時間）を出すのではなく、「複雑さ・不確実性」を含めたボリューム感をチーム内で共有することに特化しています。

プロジェクトの性質によっては、以下の指標を組み合わせるのが適切です。

システムの規模感とは、単なる「テキストデータの量」ではありません。本当の意味での規模感とは、**「そのシステムがどれだけのビジネス要求（機能）に応え、どれほどの複雑さを内包しているか」**ということです。

「行数」という呪縛から解き放たれ、目的に応じた適切な指標を選ぶこと。それが、プロジェクトの遅延を防ぎ、エンジニアと顧客の「認識のズレ」をなくすための第一歩です。

関連記事