レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

生産性は幻想だけど、必要ではある。

id:shot6さんのエントリ(続生産性の幻想 -生産性って言葉は適切じゃない)で、

僕の中で、フレームワークの生産性についての一連の話題はひと段落ついたが、

まだ1つだけ問題が残ってる。

「生産性という指標は不要か?」という疑問だ。


 ※ここで言う生産性は「開発効率性」のことではなく「生産スピードの定量表現」だ。



僕は、生産性は確かに「幻想」だが「必要」だと思う。

唯一工数の見積もりにおいて。



id:shot6さんの言うように、正確な生産性の測定は幻想であることは間違いない。

開発プロセス全体でみると開発時の生産性ってどれくらい影響があるのかな?生産性って保守フェーズも含めてるの?

工学的(というかサイエンスとしては)には全く同一の状態、全く同一のコンテキスト、全く同一の関係する人数、全く同一のスキルがある人間がない限り

生産性って測定できないと思うけど、みんなちゃんとそうやって測定してるのかな?測定してるとしたらその手法は?

生産性と人数の相関関係ってないのかな?

生産性という幻想 (風邪で寝込んでいる間に)

チームの構成やプロジェクトの背景によっても、

生産性は、雲泥の差となるため所詮大雑把な指標でしかない。


通常我々の会社で考えると、見積工程は「半受託」というような契約にさせてもらうことが多い。

「要件定義までは人月契約」→「再見積」→「基本設計から一括」などだ。

こうやって人月契約で上流を進めている裏側で、

アーキテクトチームは当該プロジェクトに対する生産性の評価をするが、

このときの生産性は、フレームワークに対する生産性ではなく、

チーム、背景、プロセスを含めた「当該プロジェクト」に対する生産性を計る。



ということで言えば、フレームワークに対する生産性はやっぱり幻想かつ計測不可能で、

「プロジェクトに対しての生産性」しか計れないのだろう。



・・・うーん、自己完結してしまった。。


チームの構成や、プロジェクトの背景、まで含めてフレームワーク毎に

生産実績の統計を取れれば有用な数値になるかもしれない。

昨日トラックバックをいただいたid:masataka_kさんの、

Zone導入パッケージ「Yukara」

チームの生産性をディフェンシブにマネージメントするという面白そうな内容なので、

各個人の「ゾーン時間」が分れば、それも生産性として数値化しても面白いかもしれない。