生産性は測れない
現実逃避で、Martin FowlerのBlogを無断邦訳してみた...ちょっと古い記事だけど、その後画期的な生産性指標が発見されたとは聞いてないので、今でも使える話でしょ。
我々はソフトウェア開発プロセスだとか、設計プラクティスだとかの話題になるとついつい感情的な議論を始めちゃうけどさ。こういう議論の多くは実は結論を出せないんだな。なぜなら、我々がいるソフトウェア業界というのは、ソフトウェア開発の効率を測定するという極々基本的な要素を欠いているからなんだよね。
もちろんここでいう生産性とは、ある活動における入力と出力とを観測することで定まる「何か」だよ。つまり、ソフトウェアの生産性を測定するには、ソフトウェア開発における出力を測定する必要があるわけだ。生産性を測れないというのは、実はこの出力を測れないことに理由があるんだな。
測れない、というのは、みんなが試さない、ということじゃないよ。自分がイライラしちゃうことの一つに、コードの行数(LOC)で生産性を測定しようとする研究がいろいろあることなんだ。LOCで出力を計測することの問題としては、例えば、言語の違い、行数を勘定する基準の差異、書式の差異などがある。仮に同じ言語で標準的な書式に統一したとしても、LOCは出力の測定には向いてないんだ。
経験ある開発者なら、同じコトを様々な行数のコードで表現できることを知っているはずだ。さらに、よく設計され、整理されたコードは行数が少くなるはずだ。なぜなら、そういったコードからは冗長重複が排除されているからね。コピー＆ペーストに頼るプログラミングは行数が増え、設計としては悪くなる。なぜなら、冗長重複が増えるから。これを証明することは簡単だ。インラインメソッドをサポートするリファクタリングツールを使って、なにかコードをいじくればよろしい。共通ルーチンをインライン化するだけで、簡単にLOCは倍になるはずだ。
そうだねLOCは使えないね、と君は思うかもしれない。だが実際にはLOCに基く生産性研究を毎月のように私は見ているのだよ。それらの中には、IEEE Softwareみたいな重鎮論文誌まで含まれているくらいだ。
さて、とはいうもののLOCが全く使い物にならない尺度というわけじゃないんだ。LOCはシステムの規模をざっくりと表記するのには良い尺度だよ。100KLOCのシステムが10KLOCのシステムよりも大きということについて、私は別に異論を唱えない。でも、自分が100KLOCのシステムを一年で書けて、Joeという人が同じ一年かけて、同じシステムを10KLOCで書けた場合、私がJoeよりも生産性が高いとは言えないわけだ。実際の所は、私とJoeの生産性はほぼ互角だけど、私のシステムはJoeのものよりもかなりひどい設計である、という結論になるでしょ。
出力測定に関する他のアプローチには、ファンクションポイント(FP)というのがあるね。FPについて言えば、私はLOCよりは共感できる。でも、まだ納得はできないな。とあるシステムのFPを同じ方法で何回か測定したのに、結果は最低から最高まで三倍の開きが生じた、という話を聞いたこともある。
仮にFPを使って、ある機能の複雑度を正確に測定する手法を見つけられたとしても、生産性を測定することは無理だろうと私は思うね。ある機能の複雑度を測定するというのは、ソフトウェア開発の直接的出力を測定するというのとはちょいと違うよね、とも言えるね。真の出力とは、なにかもっと別のものなはずだ。正確なFP測定のシステムがあるとしよう。もし私が一年かけて100FPのシステムを開発できたとする。Joeは同じ時間かけて、50FPのシステムを開発できたとする。私はJoeよりも生産性が高いかな？違うかもしれないね。私の作った100FPのうち、30だけが顧客にとって使い物になる機能で、Joeのは50全部が使い物になる機能なのかもしれない。私の方が直接生産性は高いけど、Joeのほうが実効生産性が高い、と言うこともできるね。
Jeff Griggは、納品物のFPに影響を与える「内部要因」がある、と指摘している。「私の100FP分は、どれもこれも際だって同じような機能で、この開発に一年を要した。その理由は、再利用によるレバレッジを効かせられなかったから。Joeの50FP分は（彼には悪いニュースだが）どれもこれも異る機能で、再利用はほとんど不可能。再利用できなかったために、50FP分の際だって異なる機能を実装しなければならなかったけど、Joeってのはすごい奴だと言える。しかも1年でやっつけてしまったわけだ。」
こうした議論の全てに言えることだけど、使い物になる機能が真の測定値ではない、ということを忘れているよね。仮に私が30FPの使い物になる機能を開発し、Joeは15しか開発できなかったとしよう。もしかしたら、Joeの仕事は1000万ドルの利益を生むかもしれない。そして、自分の仕事は500万ドルの利益しか生まないかもしれない。この場合、Joeの真の生産性は私の生産性よりも高いと言えよう。なぜなら、Joeのほうがビジネス面でより大きな価値を生んでいるからだ。ソフトウェア開発における真の測定指標は、ビジネスにおける価値を基準にするべきだと私は思うのだよ。
この考え方は、成功率にもつながるはずだ。ソフトウェアにおける成功話の多くは嘘っぱちと言って良い。なぜなら、多くの人は失敗とは何かを理解してないから。成功したソフトウェアプロジェクとは、投入したプロジェクトコストよりも高いビジネス価値を生み出したもの、と言えるはずだ。もしJoeと私がそれぞれ５つのプロジェクトを担当し、私は４のプロジェクトで成功し、Joeは１つだけしか成功しなかった場合、私はJoeよりも良い仕事をしたと言えるだろうか？そうとも限らないんだな。私の成功したプロジェクトがそれぞれ100万ドルの利益を出し、一方でJoeの一発が1000万ドルの利益を叩き出したら...Joeのほうが昇格対象となるはずだ。
「測定できなければ、マネージメントもできないじゃん」と言う人がいるかもしれない。でも、それは逃げっていうやつだよね。ビジネスにおけるマネージメントなんてのは、その価値を測定できないものが対象になることが大半でしょ。企業の法律担当や、企画部門や、人材開発部門の生産性をどうやって測れる？実際のところ、測れないんだよ。でも、そういう所でもマネージメントは必要だよね。(詳しくはRobert Austinを見よ)
チームの生産性を測定するのが困難だとしたら、そのチームの個々人の貢献度を測定するなんてのは、さらに大変なわけだ。チームの出力については、イタレーション毎に納品された機能数を観測することで、ざっくりとした感覚は得られるかもしれない。粗い感覚ではあるけど、チームのスピードが上がっているとか、あるチームが別のチームより生産性が高いとか、そういうざっくりした感じは得られるよね。だけど、個々人の貢献度はなかなか評価できない。ある人達は機能の実装を担当している一方で、別の人達はその実装を支援しているだけかもしれない。この支援役達はチーム全体の生産性を向上させるのには貢献しているかもしれないけど、開発をしていない個々人のアウトプットを測定するってのはとても難しいよね。
まだまだややこしい話があるよ。2003年9月13-19号のエコノミスト誌に、生産性トレンドの記事がある。どうやらエコノミスト編集局は、90年代におけるコンピュータ投資の結果として最近のビジネス生産性は向上していると分析しているようなんだ。大事なことは、投資してから結果が出てくるまでに遅延がある、ということだ。「コンピュータへの投資はただちに生産性を上昇させることにはならなかった。企業はビジネスのやり方まで見直す必要があった。」同じ遅延は、電気の発明の際にも生じている。
ビジネスの価値ってのは測定するのが大変なだけではなく、さらに時間遅延まであるということだ。すなわち、ある開発チームの生産性は、今作っているソフトウェアがリリースされてから何年か経過するまで測定できない、ということになるかもしれない。
生産性を測定するということがとても魅力的なことだというのは私にもわかるよ。もし生産性をちゃんと測定できれば、ソフトウェアの査定なんてのは現状我々がやっているよりも、はるかに簡単で明快になるはずだから。でも、間違った測定は物事を悪くするだけだよね。このことに関して、我々は自分達の無知さ加減を認めるべきじゃなかろうかね。
