【和訳】生産性は測れない / Martin Fowler
はじめに
以下が良い記事だったので和訳を残しておこうと思います。
適宜補足も加えています。
本文
ソフトウェアプロセスや設計実践などについて、非常に感情的な議論が多いのを目にします。これらの議論の多くは解決が難しいものです。その理由は、ソフトウェア業界がソフトウェア開発の効果を測定するための基本的な要素を測る能力に欠けているからです。特に、生産性を合理的に測定する方法がないという問題があります。
生産性はもちろん、ある活動の入力と出力を見て判断します。したがって、ソフトウェアの生産性を測定するには、ソフトウェア開発によるアウトプットを測定しなければなりません。しかし、生産性を測定できないのは、そのアウトプットを測定できないからです。
これが意味するのは、人々が測定を試みないということではありません。私が最も苛立つのは、コード行数に基づく生産性の研究です。まず、言語の違い、カウントスタイルの違い、フォーマット規約による違いなど、さまざまな要素が影響します。しかし、同じ言語で、すべて自動フォーマットされたプログラムに一貫したカウント基準を用いたとしても、コード行数はアウトプットを適切に測定できません。
優れた開発者なら、同じ内容を大きく異なる行数でコーディングできることを知っています。さらに、よく設計され、適切にファクタリングされたコードは、重複を排除するために短くなります。コピー&ペーストプログラミングは、行数を増やし、設計を悪化させる原因となります。これを証明するために、リファクタリングツールを使って一般的なルーティンにインラインメソッドを適用すれば、行数を簡単に倍増させることができます。
コード行数は既に死んだ指標と思われるかもしれませんが、毎月のようにコード行数に基づく生産性研究を目にします。IEEE Softwareのような尊敬されるジャーナルでも同様です。
これが意味するのは、行数が完全に無意味な指標というわけではなく、システムの大きさを示唆するのに適しているということです。100KLOC（Kilo Lines Of Codeの略）のシステムが10KLOCのシステムよりも大きいと確信できます。しかし、私が1年で100KLOCのシステムを作成し、ジョーが同じ時間で10KLOCのシステムを作成したとしても、それは私がより生産的であることを意味するわけではありません。むしろ、我々の生産性はほぼ同じですが、私のシステムの設計の方がはるかに悪いと言えるでしょう。
アウトプットを測定するためのもう一つのアプローチとしてよく話題になるのが、ファンクションポイントです。これにはもう少し共感できますが、まだ納得していません。異なるファンクションポイントカウンターが同じシステムに対して3倍も異なるカウントをしたという話を聞いたことがあります。
仮にファンクションポイントが機能を正確に測定できる方法を見つけたとしても、生産性のポイントを見逃していると考えます。機能性を測定することがソフトウェア開発の直接的なアウトプットを測定する方法かもしれませんが、真のアウトプットは別のものです。正確なFPカウントシステムがあるとして、私が1年間で100FPのシステムを提供し、ジョーが同じ1年間で50FPのシステムを提供したとしましょう。私はより生産的だと推測できるでしょうか？そうではないと思います。私の100FPのうち、実際に顧客に役立つのは30FPだけかもしれませんが、ジョーのは全て有用かもしれません。つまり、私の表面上の生産性は高いかもしれませんが、ジョーの方が真の生産性は高いと言えます。
ジェフ・グリッグが指摘したように、ファンクションポイントの提供に影響を与える内部要因があります。「私の100ファンクションポイントは非常に似た機能であり、再利用を適切に活用できなかったため、1年かかりました。ジョーの50の機能は（彼にとっては悪いニュースですが）全く異なり、再利用の余地がほとんどありません。それにもかかわらず、ジョーは驚異的な男であり、1年でそれをすべて実現しました。」
しかし、これは有用な機能性が真の指標ではないというポイントを無視しています。私が30の有用なFPの機能を提供し、ジョーが15だけを提供しているとしても、ジョーの15が顧客に1000万ドルの追加利益をもたらし、私の作業が500万ドルしかもたらさないとすれば、私は再びジョーの真の生産性が高いと主張します。真のソフトウェア開発の生産性の指標は、提供されたビジネス価値に基づくべきです。
この考えは成功率にも反映されます。ソフトウェアの成功についての一般的な声明は、失敗が何であるかを理解していないため、偽りです。私は、成功したプロジェクトはプロジェクトの費用よりも多くのビジネス価値を提供するものであると主張するかもしれません。ジョーと私はそれぞれ5つのプロジェクトを実行し、私が4つ成功し、ジョーが1つ成功したとします。私は最終的にジョーよりも良い仕事をしたと言えるでしょうか？必ずしもそうではありません。私の4つの成功がそれぞれ100万ドルの利益をもたらし、ジョーの1つの成功が彼のすべてのプロジェクトの費用を上回る1000万ドルの利益をもたらすなら、昇進すべきなのは彼です。
「測定できないものは管理できない」と言う人もいますが、それは逃げです。 企業は「価値を本当に測定できない」ものを常に管理しています。会社の弁護士、マーケティング部門、教育機関の生産性をどう測定するのでしょうか？できませんが、それでも管理する必要があります（詳しくはロバート・オースティンを参照）。
チームの生産性を把握するのが難しいなら、チーム内の個人の貢献度を測るのはさらに難しいです。チームのアウトプットをざっくりと把握するために、各イテレーションで提供される機能の数を見ることができます。粗雑な感覚ですが、チームのスピードアップや、あるチームが他のチームよりも生産的かどうかをざっくりと把握できます。しかし、個々の貢献を評価するのははるかに難しいです。ある人は機能の実装を担当するかもしれませんが、他の人はサポート役を果たし、他の人が機能を実装するのを助けます。彼らの貢献はチーム全体の生産性を向上させることですが、個々のアウトプットを把握するのは非常に難しいです。
この話が複雑すぎる場合、エコノミスト誌（2003年9月13-19日）には生産性の傾向に関する記事があります。経済学者たちは、90年代のコンピュータ投資による生産性の向上を認識しています。要点は、改善が投資に遅れて現れることです。「コンピュータに投資しても、生産性の向上は自動的には実現しません。企業はビジネス慣行を再編成する必要があります」 これと同様の遅れは電気の発明でも見られました。
つまり、ビジネス価値を測るのは難しいだけでなく、時間的な遅れもあるのです。 したがって、チームの生産性を測定するには、彼らが構築していたソフトウェアのリリース後数年を待たなければならないかもしれません。
生産性を測定することが魅力的である理由は理解できます。もしそれができれば、今よりもソフトウェアをはるかに簡単かつ客観的に評価できるでしょう。しかし、誤った測定は事態を悪化させるだけです。ここは無知を認めるべきところだと思います。
Discussion