効率よく仕事すると損をする?

〜以前担当したことのある大手SIer配下のプロジェクト現場より〜

この業界では、未だに作業量を人月で見積ることがほとんどです。
人月とは、エンジニア一人1ヶ月の仕事量でいくら、というマンパワー的な発想の見積り手法のことで、これが諸悪の根源なのは周知の事実ですが、そのプロジェクトはもっとひどかったんです。

なんと、プログラムの規模をステップ数（ソースコードの行数）で測っていたんです。
古くさいCOBOLバリバリの汎用機の時代のカビの生えた手法を、JavaバリバリのWeb開発プロジェクトに適用しているのです！

ステップ数で規模を出すのと何が悪いのか？

プログラムというのはエンジニアのスキル次第で品質に大きな差がでる。
つまり、無駄が多く、効率の悪いプログラムほど、ソースコードの量が増えて、見かけ上の規模が大きくなってしまうということ。

そうなると、後の工程も引きずられて規模が大きくなる。不具合が多く発生して修正工数がかかるし、試験の工数も増えるから。

では、プログラムを無駄なく、効率よく、コンパクトに仕上げたら？

ステップ数が少ないため、見かけ上の規模が小さくなり、後の工程も規模が小さくなる。
これを手抜き工事ではないかと疑う輩がいる事はとりあえず置いといて、本当の問題はそれが全く評価されないということだ。

効率よく短い期間で仕上げれば損をする、効率悪く毎日残業ばっかりしてると「頑張ってるね」というように見られる。

こんなバカな話があるか！　ってなる。

これはちょっと極端な例だけど、でもとにかく評価されることはない

とくにそこの現場では、プログラムのコードレビュー（コードインスペクション）が工程に入っておらず、みんな好き勝手にプログラムを書いていた。それでも、プログラマーの間では、ソースコードを参考にしたりする際に中を見る機会があるので、誰が良いプログラムを書いているのか知ってる人は知っていたが、上の人間には全く知るよしもない。
上の人間が見るのは、ステップ数とか障害件数とかの数字だけ。

こんな状況では、だれも真面目にやろうと思わなくなるし、優秀なエンジニアが育たなくなるばかりか、ソフトウェア産業自体がダメになると思いませんか？

ではどうするか。

プログラムの規模をちゃんと見積もりましょう。

コードレビューを行い、品質評価をしましょう。
ステップ数だけではなく、それぞれのアーキテクチャに合わせて難易度・流用度・I/O数・条件数など規模見積りの観点を考え、結合度・可読性・保守性など様々な評価をしましょう。

こういう話をするとすぐに、どういう手法がベストなのか聞いてくる人がいます。実際、みんなそこを知りたいわけですし。

残念ながら、正解は一つではないので一概には言えません。

アーキテクチャやプロジェクトの性質によっても評価の切り口が変わってくるでしょう。
まずは試行錯誤しながら、ある程度のパターンを蓄積し、よりベターな手法を模索していくしかないんだろうと思います。

つまりそれこそがノウハウであり、本当の技術力となっていくのです。

みなさんは、どうやっていますか？