---
title: 生産性を計測する
tags: TAGS
---

http://www.martinfowler.com/bliki/MeasuringProductivity.html

ツールや方法論などについて、こんなにも長い間、激しく、出口の無い議論を続けてきたのは、それらの効果が正確に測定出来ないからです。つまり、開発チームの生産性を測ることが出来ないということです。厳密に言えば、成果物（どれだけのものを作り出せたか）を測定できないことが問題なのです。

計測しようという試みはあります。恐ろしいことに、他のところでは分別のある賢明な人々が、「生産性の計測にはコード行が適切だ」と考えているのです。しかし、私は今まで適切なものなど見たことがありません。ファンクションポイント法は理論的には興味深い代物ですが、互いに矛盾するような話をいくつも聞いています。

さらによくないことに、ほとんどの計測法では（それがちょっとだけ良かったとしても）どれだけの機能が実装されたかといった、私が「素の生産性」と呼んでいるものしか測らないようになっています。たしかに機能も顧客にどれだけの価値を提供したかということに関係あるにはあるのですが。ですが、誰も必要としない機能を多く作ったとしても、生産性が本当に高いとは言えません。本当に生産性を測定するのであれば、ビジネスの価値に基づいてなければなりません。単に機能だけではダメなのです。

「計測できなければ、マネジメントなんかできないよ」と言う人もいます。そんなのは単なる責任逃れです。ビジネスはいつだって計測できないものを扱っているのです。企業弁護士の生産性をどうやって計測しますか？ マーケティング部門の生産性は？ 教育機関の生産性は？ そんなの計測できっこないのです。だけど、計測できないものをマネジメントしていかなければならないのです（詳しくは[Robert Austin](http://www.amazon.com/exec/obidos/tg/detail/-/0932633366)の書籍を参照のこと）。

チームの生産性が分かりづらいのであれば、個人のチームへの貢献度はさらに分かりづらいものでしょう。イテレーションにつきどれだけの機能を実装したかで、チームの成果をざっと把握することもできます。ざっくりとしすぎてはいますが、チームのスピードが上がったかどうか、もしくは、あるチームの生産性が他のチームよりも高いかどうかといったことは分かります。一方、個人の貢献はなかなか把握しづらいものです。機能を実装する役割のひとがいる一方、サポートの役割を担うひともいます（他のひとの実装を手伝う人）。彼らの貢献はチーム全体の生産性を上げています。しかしながら、チーム内にいないと、なかなか彼らの成果は分かりづらいものです。

追加コメント

1.

2.

3.
