わたしが生産性を計測する理由

　私は5年ほど前から、仕事に費やす時間を計測している。何に、何分費やしたか？をすべて記録している。その記録を見返せば何時何分には何をやっていたのかを知る事ができる。私がこのような計測をしているにはねらいがあって、それは、

1. 計測データを蓄積する事で、そのデータをもとにより正確な見積もりができるようになる
2. 何に、何分かけているのかを見て反省する事でより効率的なプロセスを発見する

である。

さて、5年やった実績から先に言うと、残念ながらどちらも達成できていない。1 に関してはたまに見積もりのデータとして活用することはあるが、その結果どのくらい正確だったかはわからないし、2 についてはまったく効率的なプロセスの発見には至っていない（どころか発見の助けにもなっていない）。

なぜ上記ねらいが達成できてい理由は2つあげられる。ひとつは、

　a. 仕事の内容が過去と同じではない

である。ソフトウェア開発という仕事は新しいものを作る仕事であり、新規性がともなうのは避けられない。それでも過去に自分が行った仕事と似ているものであれば、そのときの実績値をもとに見積もりを出せば良いのだが、案外過去にやったものと似ている仕事は少ない。と言うか、仕事を始める時点では過去のものに似ているか？という判断ができるものが少ないし、似ていると思ったけどふたを開けてみるとだいぶ違っていた、ということもある。実際に似ているものがあったとしても条件が異なるため過去の実績値をそのまま見積もりにするわけには行かない。リスク分を見積もって何割か足したり、逆に経験した事で次ははまらないだろうと考えて何割か減らすということをして見積もりをだす。まったくの勘で見積もるよりはましなのかもしれないのだが、期待していたよりも過去の実績値がばっちり当てはまるということが少なかった（まあ見積もりが正確かどうかは分からないけど、過去の実績をもとに出してますっていうと見積もりの説得力が増すという効果はあったけど）。プロセス改善について言えば同じ作業を異なるプロセスで試す事ができないのでどちらがより効率的か？というのは単純には分からない。

そして、もうひとつの理由は、

　b. 仕事の規模を表す適当な単位が見つけられない

である。まあコーディングならばいろいろ妥協して行数とすることもできるんだろうけど、実際の仕事はコーディングだけではない。例えば、クラス構成を考えたり、既存のコードを調査したり、規格書を読んだり、開発環境を整えたり、といろんな仕事をする。そしてそれぞれの仕事の規模をあらわすうまい単位を見つけられないのである。そうすると、せっかく時間を計ってはいても作り出した成果の大きさが分からないので生産性を導きだす事ができない、というわけである。

以上のふたつの理由が大きく、私が当初たてた計測のねらいは達成できていない。では、計測する意味はまったくないのか？というとそういう訳でもなく、当初期待していなかった副次的な効果があった。そして今はこれが計測を続ける主要因となっている。それは、

計測すると集中力が増す

である。時間を計測するのでタスク名の横に開始時間を記録してから作業を始めるのだが、そうすると「今はこのタスクをやる時間」という意識が芽生えて他のことをしなくなる（たとえば無駄なメールチェックとか）。その結果、目の前のタスクに集中することができる。というか、目の前のタスクに集中してこなさないと残念な記録が残ってしまうのでついついがんばってしまう。今は見積もりの確度向上やプロセス改善はほとんどあきらめてしまったが、それでも計測をやめないのはこの集中力が増す効果によるところが大きい。

最後にわたしは読了していないけど、計測の定番書を参考文献として紹介して本稿を終える。

PSPガイドブック ソフトウェアエンジニア自己改善 (IT Architects' Archiveソフトウェア開発の課題)