ファンクション・ポイント法よりさらに簡単に、システム規模を特定する方法があります。それはシステムのソースコード行数を用いるというものです。

 使用する言語が同じであれば、ある機能を実現するプログラムの記述に必要な行数はほぼ同一です。したがってソースコードの行数はシステムの規模とほぼイコールということになります。
 実際、メインフレームが主流の時代には、アーキテクチャが同一で、言語もCOBOLに統一されていましたので、ソースコード行数(Step数ともいう)が規模を表す重要な指標でした。ベテランのSEになれば、おおよその機能がイメージできると、即座にコード行数が頭に浮かんいました。「これのシステムはだいたい何Step?」「じゃあ○×億円くらいですね」などという会話が日常的に交わされていたのです。

 最近ではシステムのオープン化が進み、複数のアーキテクチャが混在する環境が当たり前となってきました。また使用する言語も様々です。したがって理論上では、ソースコードの行数は様々な値をとることになります。

 となると、コード行数は規模の特定には使えないのでしょうか?そんなことはありません。コード行数はシステム規模の特定において十分実用になります。ここでも、本コラムで何回か述べているマクロ的現象が効果を発揮します。

 たしかにCOBOLとJavaでは、同じ機能を実現するために記述しなければならないコードの行数は異なります。
 Javaの方が抽象度が高く、カプセル化が可能ですので、一般に少ないコードで済むといわれています。実際、弊社のシミュレーションでも、COBOLはJavaに対して3倍程度の文章量が必要との結果が出ています。
 しかし一方で、抽象度が高い言語ほど、事前の構造設計が重要となり、コーディングの作業速度は遅くなるというのも事実です。結果として、COBOLでもJavaでもコードを記述する生産性には大きな違いは生じません。

 したがって、システムの見積書、あるいは提案書をベンダーから受け取るときには、必ずコード行数の見込みを記載してもらうとよいでしょう。

【弊社刊行マニュアル書籍のご案内】
政府IT予算の削減にも使われたノウハウを凝縮!
情報システム発注における価格検証・価格交渉完全マニュアル」くわしくは「こちら」。
3000件のIT診断実績から得られた知見をそのまま書籍化しました。他では得られない貴重な情報です。