ステップ数

「ステップ数」というのは、プログラムのソースコードの行数のことである（※１）。

ソースコードの行数が多いほど、プログラムの規模が大きい。当然、開発に掛かる時間も大きくなるだろう。というわけで、ステップ数は、プログラミングに必要な工数の見積や、進捗の管理に使われることがある。

しかし、実際には、ステップ数だけで工数を把握することは不可能である。

そもそも、完成したプログラムのステップ数がいくつになるのか、開発を始める前には分からない。プログラムは、ソースコードが何行になったら完成、というものではない。

たとえ、完成後のステップ数をある程度予測できたとしても、そこからプログラマの作業時間を予測することは更に困難なことである。プログラミングでは、ソースコードを書いている時間（手を使っている時間。ステップ数が増える）より、設計や技術調査をしている時間（頭を使っている時間。ステップ数は増えない）のほうが多いからだ。

また、同じ機能のプログラムであれば、多くの行数で書くより、少ない行数で書くほうが、良いプログラムである場合が多い（※２）。プログラミングに無駄が多いとステップ数が増えるからである。言い換えれば、プログラムの動作を変更せずに、ステップ数だけを不正に増やすことも簡単にできるのである。

このような理由から、プログラマの中には、管理者からステップ数の報告を求められることに反感を抱く者もある。

★

では、なぜ、ステップ数という単位が工数管理に使われ続けているのだろうか？

おそらく、決定的な代替案がないからだろう（※３）。ステップ数のような不確実なものでも、数値的な尺度が何もないよりはましだということであろう。

確かに、何にせよ、収集するデータは多いほうがよい。ステップ数に限らず、開発作業において簡単に測定できる数値情報があれば、何でも測るべきだろう。様々なデータが集まれば、有意義な解析も出来るかもしれない（もちろん、測定自体に手間が掛かるようであれば、その限りではないのだが）。

そういう意味では、プログラマは、ステップ数を報告することに反対すべきではない。ステップ数が測定されること自体には、何も問題はないはずだ。

問題があるとすれば、その数値がどう扱われるか、という点においてである。

もしも、管理者が、ステップ数だけを基準に、プログラマの生産能力を評価したり、進捗状況を管理しようとするならば、実態の把握を誤るばかりか、プログラマ達に不信感を抱かせることになるだろう。そうならないためには、特定の数値だけに頼るのではなく、もっと質的な情報も収集し、総合的に進捗を判断することが必要だろう。

※１
実際には、行の数え方にも細かいルールがある。例えば、コメント（注釈）だけの行を数えるのか数えないのか、など。開発会社やプロジェクトなどによって、決まっていることが多い。

※２
ソースコードの読みやすさを犠牲にしても、行数を少なくするような場合はその限りではない（プログラムのサイズに上限がある場合などは、そういったことが必要な場合もあるかもしれないが）。

※３
個人的には、プログラムの規模を測りたいのなら、ステップ数よりもソースコードのサイズ（バイト数）や、実行ファイルのサイズを測るほうが素直ではないかと思う。また、オブジェクト指向開発においては、ステップ数よりもクラス数、メソッド数のほうが妥当かもしれない。いずれにせよ、工数を管理する上で、不確実な単位であるということには変わりはないのだが。。。

■関連記事
・やってみなきゃわからないという現実
・どのくらいでできる？