システム開発において、その規模や複雑さを測ることが難しいことは皆さんよくご承知のことかと思います。
見積もりの不正確さはデスマーチの元にもなりますし、契約金の多寡にも関わりますから システム開発をする人間してみれば悲願のようなものであると思います。

大阪勉強会#12の帰りの電車で考えていたことなのですが、 うまくやればStep数にくらべ精度の高いシステム規模を示す数値が得られるかもしれません。

Step数とシステム規模は確かに正の相関性があるのですが、誤差が大きく、見積もりに使えないという見解でした。 では、その誤差の元になるものはなんなのでしょうか？

ひとつは、コードクローンの存在です。構造化がなされていないプログラムでは随所に コピー＆ペーストで作られたコードクローンが存在します。
コードクローンは、システム規模の見積もりに深刻な影を落としています。 Step数が多いほど規模は大きいと思われるわけですが、 構造化の程度がよいほどStep数は減るという背反関係にあるためです。

もうひとつは自動生成コードの存在です。Javaの場合、構造体的な使い方をされるBeanと呼ばれる クラスには大量のSetter, getterが存在し、コード量を水増ししています。
また、EclipseのプラグインのVisualEditorなどのGUIデザイン支援ツールを使うと、 これまた自動生成コードが大量に吐き出されます。 こういったコードは手作業で記述するコードと同列の尺度で工数を測れません。

圧縮してみてはどうか？

ふと閃いたアイデアは、辞書式の圧縮アルゴリズムを用いてclassファイルを圧縮したらどうか？というものでした。

コードクローンが多いほど、辞書式の圧縮が効きやすく、 純粋なシステム規模に近い値を出せるのではないだろうか―。
自動生成コードに対して、アノテーションによるマーキングを施し、除外するようにした上で、 ロジック部分に対して一度辞書式の圧縮を掛けるのです。

圧縮は例えば既存のZIPなどの圧縮方式を利用してもそれなりの値は出るかもしれません。 このあたりは実際のコードを用意して実験しないとなんとも言えないですね。
クラス名やメソッド名などのシンボルは辞書式に圧縮すれば嵩が減るため、 名前の長短は結果に大きな影響は与えないのではないかと考えています。 しかし、問題になるとすれば文字列リテラルなのではないかと思っています。

classファイルを対象に処理をするか、あるいは抽象構文木を対象に処理をすれば求める値がでる気がします。 その際に、クラス名などのシンボルを捨てる、文字列リテラルを捨てる、とすれば 精度のよいシステム規模のモノサシが得られるのかもしれませんね。