生産性を考える
ITPro: ［OSC島根］「RubyでCOBOL技術者は復活する」---松江市の基幹システム開発で得られた実感
Rubyの生産性について，吉岡氏は「COBOLやC/Sシステムとほぼ同じだった」とする。全体の30％を占める設計工程はCOBOLでもRubuyでも同じ。全体の40％を占める製造工程は4分の3の工数で開発できた。全体の30％であるテスト工程は同じ。実際に開発する前は，Railsのテスト自動化機能によりテストの工数を削減できるのではないかと期待していたが，自動テスト機能は，プログラムの状態やデータベースの状態が同じでなければ使えないことなどにより削減できなかった。繰り返し型の開発で威力を発揮する自動テスト機能も，今回の開発はウォータフォール型で1回限りの開発のため工数削減にはつながらなかった。しかし全体を通して見れば工数を1割削減できている。
- ウォータフォール型開発じゃん...
- 設計・製造・テストと工程を分割することによって発生するオーバーヘッドが生産性の上限を決めてしまう。
- 言語の記述性とか、ツールの良し悪しなんてのは、そのオーバーヘッドに比べれば誤差範囲なわけよ。
- なので「RubyとCOBOLの生産性がほぼ同じ」と言われちゃうと、「ぉぃぉぃ」という気分になってしまう。
- 正しくは「ウォーターフォールなら何をやっても無駄」。
で...記事の書き方が悪いだけかもしれないけど、テスト自動化による「工数削減」ってのはなんなのかね？
- 「実際に開発する前は，Railsのテスト自動化機能によりテストの工数を削減できるのではないかと期待していたが，自動テスト機能は，プログラムの状態やデータベースの状態が同じでなければ使えないことなどにより削減できなかった。」とあるけど、プログラムやDBをいじくった後の影響を把握する意味でもテスト自動化は重要ではないかね？
- もちろん、それにより本体のコード以外にテストコードにも見直しは入る。
- つまり、ある仕様修正に対する作業量は非テスト駆動型開発より増える。
- これを見て「テスト駆動型開発は生産性が下がる」とのたまった知人がいるけど、生産性ってのは単位時間あたりの作業効率で決められるべきことなのかね？
- ある修正によって発生した副作用をその場で検知し対応しておかないと、後々にバグ探知で無駄な時間を費やすことになるよね。
- そして、バグ探知と対策ほど「作業見積りをしにくい」工程はないよね。
- プロジェクト計画管理で一番困るのは作業見積りと実績の大幅な乖離のはず。
- にも関わらず、ウォーターフォール開発では「テスト」という期間があらかじめ計画され、そこの範囲内で作業を終わらせようとする。
- つまり、バグがいくつ出るか、それらのバグの探知対策に要する時間がどれくらいか、最初から見積もられているわけだ。
- すごいよね。凡人の俺様にはできない。
- というか、多分ほとんどの人には、できない。
- テストで検知された問題点にはそれなりに対処するけど、「与えられた時間内でできるだけバグを拾う」域をでない、というのが現実。
- そういう視点で考えるのなら、「実際に開発する前は，Railsのテスト自動化機能によりテストの工数を削減できるのではないかと期待していたが，自動テスト機能は，プログラムの状態やデータベースの状態が同じでなければ使えないことなどにより削減できなかった。」という結論に到達するのも理解できる。
もう言い古されている話だけど、品質と生産性とを切り離して、生産性のみ比較することに何の意味があるのだろう？
