保守性の高いコードを定量的に評価するための手法が重要
生産性という言葉があります。単位時間当たりに何ステップのコードを書けるかを指します。プロジェクトの見積ステップ数を生産性で割り、必要な要員数を勘定するなんてことはめずらしくありません。人月の計算と要員の手配をしている管理側にとっては楽な方法です。
生産性の均一化は本末転倒
そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。
http://d.hatena.ne.jp/higayasuo/20080325/1206421786
穴埋め式の解答欄と同じように、穴埋めにロジックを書けば誰でも同じものが出来上がる。誰でもできるから単価を下げられるし、見積値のブレも小さくなる。大手SIerの経営層はそう考えて、研究部門にフレームワークを作らせたり見積手法の研究をさせたりしているのでしょう。
現場の管理側でも、ソフトウェアの製造プロセスは誰でもできると考えている人が多い。ギークな新入社員は驚くでしょう。実際、私も同じことを言われましたよ*1。
しかし、ソフトウェアは誰が製造しても同じ品質が得られるまでエンジニアリングが進んでいません。人月見積のブレを抑えるために生産性を均一化するのは本末転倒です。無理に均一化を進めれば、誰が書いても同じgdgdなコードができる危険があります。
保守性の向上が重要
重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。
http://d.hatena.ne.jp/higayasuo/20080325/1206421786
ソフトウェア工学の目指すべき方向は「保守性の高いコード」にあります。生産性は高いが保守性の低いコードを書く手法を研究する意味はない。今まで売り切りと更改でやってきた分野はともかく、顧客の目が肥えた分野では通用しません。保守性の高いコードを定量的に評価するための手法が重要です。
余談ですが、現場の問題を書くと、保守はこの先の別プロジェクトがやるから自分には関係ないという人もいます。更改プロジェクトに必ずしも同じ人がアサインされるわけではない点が、モラルの低下を招いている要因でもあります。
