• 2014年5月16日金曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/2014/05/blog-post_16.html

ステップ数

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

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

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


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


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

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

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

ってのは別の話だよ。

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

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


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


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

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

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




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

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

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

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

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

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


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


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

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


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


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

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

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

2 件のコメント:

  1. 国益を損なうとか、マジどんなプロジェクトだよ…。で、ひど過ぎる…と。

    返信削除
  2. 国家のエネルギー戦略の中核となるシステム。
    インフラ管理のシステムなのよ。
    現在は人海戦術でインフラ管理を行っている所を自動化する。
    このシステムがコケるってことは、本来浮くはずだった何万人もの人件費をずっと維持し続けなきゃならんってことよ。
    毎年何千億円をドブに捨てることになるぜ。

    返信削除

お気軽にコメント下さい。