設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。

生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。

これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし、コード書式も違うんですよ。仮に、同じ言語で、数え方を同じにして、同じコード書式にしたとしても、コード行なんかじゃアウトプットを正確に測れるわけがありません。

賢明な開発者だったら、同じことをやるのにいくつものやり方があり、それによってコード行が変わってくることくらいご存知ですよね。しっかり設計され、きちんとリファクタリングされたコードほど、コード行は短くなるものです。だって重複が無いんだもの。コピペぷろぐらみんぐだったらコード行は稼げるでしょうけど、重複重複重複重複で、設計は見てられないものになります。 メソッドのインライン化をサポートしているリファクタリングツールを使って、自分でやってみると分かると思いますよ。共通したルーチンをインライン展開してあるだけで、コード行は簡単に倍になるんです。

なぜ土壌pHの決定は行う

コード行なんてダメだなあって思ったでしょう。でも、コード行で生産性を測定しようと研究してる人たちは多いんですよ。 定評のある『IEEEソフトウェア』誌でさえそうなんですから。

さて。こんなコード行による計測ですが、まったくダメってわけでもありません。システムの規模を測るのにはちょうどよいのです。 100k行のシステムは、10k行のシステムよりも規模が大きいですよね。 だけど、私が一年かけて100k行のシステムを構築したのに、Joeが10k行で同じシステムを同じく一年で開発したら……どうでしょう。 私のほうが生産性が高いとは言えませんよね。成果物は同じだから生産性は同じなのかもしれませんが、私の設計がいいものだとは言えません。

もうひとつよく言われるのが、ファンクションポイント法による計測方法です。 こっちは、まあ、ね、分からないでもないですよね。でも完全には納得しているわけじゃありません。こんな話を聞いたことがあります。 ファンクションポイント法を使って同じシステムを計測したところ、結果がバラバラ（3倍！）になったんだって。

教師がいじめ

ファンクションポイント法が正確に機能を測定できるものだったとしても、まだ生産性のポイントを捕らえきれていないように思います。 機能性を計測して分かるのはソフトウェア開発自体のアウトプットでしかなく、本当のアウトプットはまだ他にあるのです。 ファンクションポイント法でシステムを計測してみましょう。私が100FPシステムを１年かけて納品したとします。Joeは同じ期間かけて、50FPのシステムを納品するとします。さて、私の方が生産性が高いと言えるでしょうか？……言えませんよね。私の100FP分の機能のうち、30FP分の機能しか実際にお客様に使ってもらえず、Joeの50FP分の機能はすべて使ってもらえるなんてこともあるのです。つまり、こういうことです。生産性数値自体は私のほうが高いですが、実際の生産性はJoeのほうが高いのです。

でも、使われる機能がどっちが多いかなんて、実際は関係ないのです。 私のシステムの30FP分の機能が使われ、Joeのは15FPしか使われないとしましょう。 でも誰かが気付きました。Joeの15FP分の機能は10ドルの余剰利益を上げて、私の30FP分の機能は5ドルしか利益を上げられなかったと。 （はあ何度目だよ）Joeのほうが本当の生産性は高いのです。彼のシステムのほうがビジネス価値を生んだからです。ソフトウェア開発の生産性を測る手段は、それによってもたらされるビジネス価値に基づいていなければなりません。

大恐慌からの思い出の写真

この考え方はプロジェクトの成功率にも関係してきます。 「ソフトウェアの成功」とよく言われるものは、だいたいウソです。 みんな失敗とは何のことだか、分かっていないからです。 成功プロジェクトというのは、プロジェクトにかかったコストよりも多くのビジネス価値をもたらすもののことです。Joeと私がそれぞれ５つのプロジェクトを受け持ち、私は４つ、Joeは１つプロジェクトを成功させたとします。さて、結局、私の方がJoeよりも良いんでしょうか？ いえいえ、必ずしもそうではありません。私の４つのプロジェクトがそれぞれ100万ドルの収入をもたらし、Joeのプロジェクトが（失敗したプロジェクト分のコストを合わせて）1000万ドルの収入をもたらしたとしたら……きっと昇進するのはJoeでしょう。

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

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

以上でまだ物足りないのなら、『エコノミスト』誌（2003年9月13-19日号）に生産性の動向に関する記事が載っていました。 この記事によると、90年代におけるIT投資によりビジネスの生産性は高まっていると専門家は考えているのだそうです。 重要なのは、投資に対する効果のタイムラグです。つまり、IT投資をすれば自動的に生産性が高まるわけではないのです。企業はビジネスのやり方もしっかり把握する必要があります。このタイムラグは、電気の発明の際にも起こりました。

つまり、ビジネスの価値を計測するのが困難というだけでなく、 そこにはタイムラグの問題もあるのです。 チームの生産性というのは、構築したソフトウェアをリリースしてから 数年後に初めて分かるようなものかもしれないのです。

「生産性の計測」に魔性の力があるのは分かります。 生産性を測ることができれば、ソフトウェアを今よりも簡単に、 より客観的に評価することができるからです。 しかし、偽りの計測方法では事態は悪いほうにしか進まないでしょう。 この点について我々は、自分たちの無知を認めねばならないように思います。