ステップ数

また炎上チームを偵察してきたけど、実装作業ではなくドキュメント作りしていた。

作成ドキュメントは「機能毎のステップ数」だ。

僕はこの「ステップ数」というのを眉唾モノと思ってるんだけどね。


高スキル者が作ればステップ数は減る。
コピペ野郎が作ればステップ数は激増する。


これを「システムの規模の指標」とするには実態と合わない。

まあ、評価する側からしてみれば数値評価が必要なのは分かるけど、

『実態と乖離していても構わないから何でもいいから数字出せ』

ってのは別の話だよ。

僕はこういう『嘘数字』ってのが非常に気になる。

ＳＥでは無い人でも、『会社への貢献度を、業務成績ではなく、残業時間で評価する』のと似たような行為と考えてくれれば分かり易いだろう。


後々の品質指標として「ステップ数/テストケース数」の計算を行うには必要だけど、システム規模を計るには役に立たんと思うのよ。


とは言え、数字は数字で正確だから、見る人が見れば参考にはなる。
例えば、僕みたいなプログラマーであれば、仕様からステップ数を予測出来る。
それと比較して、提出されたステップ数が妙に多い場合は「きっとコピペ連発のカスソースなんだろうな」と察しをつけられるわけさ。

しかし、実態として、そんな分析は行われないだろう。
多分、どこぞの報告書に「ステップ数：ＸＸＸＸＸ」と書いて終わり。
その数字については誰も見ない。見たとしても実態に則していない。

こんな意味の無い作業に工数を費やす愚かさよ。




ここからがオチなんだけど、上の記事を読んで、読者の人は「ステップ数計測ツールでステップ数を自動計測している」と思っとりゃせんか？

違うのよ。目視計測なの。

と言うのも、ステップ数計測ツールってのは「Javaのクラス単位でステップ数を算出する」機能でしょ？
でもあのチームが作っているのは「機能単位のステップ数の一覧表」なのよ。

だから、単純に計測ツールでザッと計測することが出来ない。

「この機能で使っているのは、このクラスのこのメソッドだから、このメソッドの部分のステップ数を数えて、こっちの別機能に加算して、そのうちコメントアウトになっている部分は･･････」

みたいに、「ツールを使える所は自動ツール、使えない部分的は目視計算」というやり方なの。


こりゃ時間掛かるわな！！


で、ソースや設計はゴミだけど、そのドキュメントは凄い綺麗に書いてあんのよ。
あれは本当に綺麗。
僕はあんな綺麗なドキュメントを書いたことが無い。
綺麗なドキュメントの例として使えるくらい綺麗。

もちろん綺麗なドキュメントを書くには時間が掛かるから、このドキュメント作成に2日3日を費やしている。


実装が月単位で遅れてるのに、嘘ドキュメント作成に数日費やすっていうね。


嘘ドキュメントは上手に作ってあるからタチが悪い。

今でも客先は、このプロジェクトが順調に進んでいると思っているけど、
結合テストの段階で「実は半年遅れてました」みたいなことが露見することにだろう。

その時にどんな泥沼の裁判が待っているのか、僕が知るはずも無い。