何だかんだで品質向上の為にサボらず最後まで仕事してたな。
勤勉な労働者や。(´・ω・`)
しかし、一体どれだけソースを書いたんだろ？
ちょっと気になってカウントしてみた。
指標値：STEP/月
プロジェクトの生産性を計る指標として、「月々どれくらいのソースの行数が増えているか？」というステップ数という考え方がある。
まあ、このステップ数という見方は定量的ではあるけど問題もあって、例えば僕の場合、ソースを自動出力するツールを使っている、自動出力したソースとそうではないソースを混ぜてステップ数を計っても生産性の指標にはならんだろう。
また、「最初に作った画面」と「後で作った似たような画面」では意味が意味が違うから、これらを混ぜる行為もおかしい。
そして何より、少ないステップ数で機能を実現するテクニックについても考慮されていない。
そして、言語。
一般的に「２０００STEP/月が平均」とされているけど、それはCOBOLで算出された生産性だからな。
Javaや他の言語と同列ではない。
つまり、ステップ数という考え方は、ソースの上から下まで全部を泥臭く実装していたCOBOL時代の名残りで、ライブラリや自動化が進んだ現代においては不十分な指標だ。
しかし、それらを踏まえた上で、ソースの性質を僕が自分で見極めてカウントしてみよう。
ウズマスターの生産性
このプロジェクトの総ステップ数は１７０００ＳＴＥＰだ。実行ステップ数な。コメントはカウントしていない。
しかし、既存プロジェクトからパクッてきたソースや、自動出力したソースも含まれており、それらを除外して、僕がちゃんと自ら書いた部分に絞り込むと３０００ＳＴＥＰとなる。
実際には３０００ＳＴＥＰの中にもコピペが混ざっていたり、逆に３０００ＳＴＥＰの外でＨＴＭＬを書いていたりするから厳密とは言えないが、そういうのを相殺すると大体３０００ＳＴＥＰと考えて問題無いと思う。
また、この３０００ＳＴＥＰは起動に乗った後の数字だ。
技術調査フェーズは先月で終わっており、今月はひたすら作業のフェーズだった。
要するに、この３０００ＳＴＥＰという数字は技術的ハードルや余計な雑作業を除外して大量生産体制に入ったと想定した数字に近い性質を持つという意味だ。
そして、この僕は３０００ＳＴＥＰを２週間、１０人日で製造した。
つまり、
- ウズマスターの生産性＝６０００ＳＴＥＰ / 月
となる。
やっぱこんなもんだな。(´・ω・`)
昔からウズマスターの生産性は３倍近いと言われていて、数年前に計った時もこんなもんだった。
数年前も今も同じってことは、やっぱりこの辺りが能力の限界ってことだろう。
どう頑張ってもこれ以上に生産性を上げることは不可能。
と考えると、もはや僕はプログラマーとしての目標が枯渇に近づいており、新しい目標に向かわねばならない時期に来ていることが改めて分かる。
↑こういうこと
で、問題は「新しい目標って何なの？」って所なんだけど、イメージとしては上記な感じ？上記みたいな分析は僕自身が叩き上げのプログラマーであるから可能なのであって、大企業とかに多い専門マネージャーではそこまで深い分析は不可能なのよ。
ＳＴＥＰ数計算なんて、プログラマーじゃなければ全体をドボンと計算するしか出来ないでしょ？
「ソースの実態と性質を見分けて計測する」なんてやり方は僕がプログラマーだからこそ可能な芸当だ。
「プログラマーはプログラミングしか出来ない」じゃなくって、プログラマーだからこそ可能な分析というものがあるわけよ。
- 元々がプログラマーだから持っている視点
- 元々がプログラマーだから可能な分析
- 元々がプログラマーだから実行できる改善
- 元々がプログラマーだから実現できる経営
これをより具体化して世の中に示してやらねばならん。
それがプログラマー出身経営者という特性のある僕を他の専任経営者と差別化するポイントであり、
「自分も若いうちは今みたいにプログラミングしていれば食っていけるけど、何歳くらいまで頑張れるのだろうか？」みたいな不安を抱えている子羊プログラマーに示してやらねばならない未来への指標なのだ。
とはいえ、さて、どこから手を付けていくべきか。
イメージはあるんだけど、色々あり過ぎてどうにも整理がつかない状況。(；´・ω・`)
とりあえず僕の頭の中身をドキュメント化していくところから始めてみるか。(´・ω・`)
0 件のコメント:
コメントを投稿