2002/01/26
 ステップの話１
ある程度システムエンジニアとしてのキャリアを積むと、プロジェクトを任せられ、そのプロジェクトにどのくらいの工数が必要なのかを算出させられることがあります。それを顧客に提出すれば見積もりとなるのですが、見積もりで顧客を納得させるには、それなりの見積もり根拠が必要なのは言うまでもありません。
見積もり根拠として、プログラマがプログラムを納期まで仕上げられるかというのは、そのプログラムの総量とほぼ比例するという考え方があります。つまり、１日にどのくらいの量のプログラムを組めるはずで、完成するプログラムがどのくらいの量だから何日くらいかかるはず、という考え方ですね。顧客の要望をコードレベルに置き換えたときにどのくらいの量のコードになるかはある程度推測できますから、それを元にどのくらいの人数がどのくらいの期間、開発すればそのプログラムが完成するかを求めることができるというわけです。物理的な量を超えてプログラムできる人はそうはいませんから、この考え方自体は決して間違っていないと思いますが、この考え方を純粋にコードの改行量だけで測定し、それを生産性の指標にする人がいます。このコードの改行量のことをステップといいます。つまり、ある単位時間あたりに何行のプログラムを書いたかというものを求めるのがステップです。このステップという指標は、たしかに構造化設計以前では量の計算には有効でした。例えばフォートランという言語は昔は１命令は必ず１行でしたから、ステップ数を使えば確実にプログラムの量を測定できたのです。しかし、実際にプログラムを書けばわかりますが、最新のフォートランも含めてＣ言語やBASICのような高級言語以降は、複数命令が１行に収まって書かれるようになりました。よって、ステップ数＝プログラム量と等価ではなくなってしまったのです。さらに構造化設計においては、同じアルゴリズムを何度でも利用する、いわゆるサブルーチン関数の技法が取り入れられるようになり、もはやステップは意味をなさなくなりました。
続きます。


 前　後

Topへ