新年度企画。勝手に新人SEを応援する連載第一回です。（気分で連載終了です）
初回は、「ソースコードって少ない方がいいんだよ？！」をテーマにお送りします。
システムの規模を表すときにSIerが好きこのんで使う指標に「人月」があります。1人の人間が1ヶ月に開発できる規模を1人月と称します。SIerがこの指標が大好きなのはもちろんそれが収益に直結するからです。1人月の開発をX万円で請け負う契約なら100人月のシステム開発は100X万円だからです。
一方で、ユーザー企業に人気がありそうなのは納品されるソースコードの量かもしれません。システム開発を依頼すると結果としてソースコードが納品されることになるので、ユーザ企業は言うなればソースコードにお金を払ったとも言えます。だから、ユーザ企業にとってソースコードは資産です。資産だから当然多い方がいい！ …のでしょうか？
ソースコードには一定の確率でバグが含まれます。もちろん開発者はテストによってバグを減らす努力をしていますが、それでもバグは残存します。バグを減らすために必要な工数は指数関数的に増大する上に、バグがないことを証明することは不可能だとわかっています。よって、システムにはバグが内包されていることを受け入れざるを得ません。
一定の確率でバグが仕込まれるなら、ソースコードは多いほどバグの数は多くなります。ソースコード（資産）の保有量とバグの保有量は比例するのです。
保守のことを考えても多すぎるソースコードは困りものです。システムが一度の増強もなくその使命を終えることなど希です。そしてハードウェアと違ってソースコードには寿命がない(とみんな勝手に思ってる)ので、数十年前のソースコードが残っているなんてよくある話です。そしてその仕様書がきちんと残っていないなんてことはあまりによくある話です。ソースコードが多くなるほどそのような保守対象が増えるということです。保守は、必要ではあるが生産的とは言えないのでたいていのエンジニアは嫌いです。ユーザ企業も保守はお金がかかるから嫌いです。そんな嫌われ者を量産するのはやめましょう。
続編へ続きます。