生産性を測定できない

ソフトウェアプロセス、設計プラクティスなどについて、多くの感情的な議論が見られます。これらの議論の多くは、ソフトウェア業界がソフトウェア開発の有効性の基本要素の一部を測定する能力を欠いているため、解決不可能です。特に、生産性を合理的に測定する方法がありません。

生産性は、もちろん、活動の投入と出力を見ることで判断します。したがって、ソフトウェアの生産性を測定するには、ソフトウェア開発のアウトプットを測定する必要があります。生産性を測定できない理由は、アウトプットを測定できないからです。

これは、誰もが試みていないという意味ではありません。私の最大の不満の1つは、コード行数に基づいた生産性の研究です。まず、言語間の違い、カウントスタイルの違い、フォーマット規則による違いなど、多くの問題があります。しかし、同じ言語のプログラムで一貫したカウント基準を使用し、すべてを単一のスタイルに自動フォーマットしたとしても、コード行数は依然として出力を適切に測定していません。

優秀な開発者なら誰でも、同じものをコード行数が大きく異なる方法でコーディングできることを知っています。さらに、適切に設計され、ファクタリングされたコードは、重複を排除するため短くなります。コピーアンドペーストプログラミングは、高いLOCカウントと悪い設計につながります。なぜなら、それは重複を生むからです。Inline Methodをサポートするリファクタリングツールでプログラムに取り組めば、それを自分で証明できます。一般的なルーチンにそれを使用するだけで、LOCカウントを簡単に倍増できます。

コード行数は時代遅れだと思うかもしれませんが、毎月、コード行数に基づいた生産性研究を見かけます。IEEE Softwareのような、もっとよく知っているはずの権威あるジャーナルでさえです。

さて、これはLOCが完全に役に立たない尺度という意味ではありません。システムのサイズを示唆する上で非常に役立ちます。100 KLOCのシステムは10 KLOCのシステムよりも大きいとかなり確信できます。しかし、私が1年間で100 KLOCのシステムを作成し、ジョーが同じ期間に同じシステムを10 KLOCで作成した場合、それは私がより生産性が高いという意味ではありません。実際、私たちの生産性はほぼ同じであり、私のシステムの方がはるかに設計が悪いと結論付けるでしょう。

出力測定のためにしばしば議論されるもう1つのアプローチは、ファンクションポイントです。私はそれらに対してもう少し同情しますが、まだ確信していません。これは、同じシステムを使用する異なるファンクションポイントカウンターから、単一のシステムのカウントが3倍も異なるという話を聞いたことで、さらに助けられていません。

機能性を決定するための正確なファンクションポイントの方法が見つかったとしても、私はまだ生産性のポイントを見逃していると思います。機能性の測定はソフトウェア開発の直接的な出力を調べる方法であると言えるかもしれませんが、真の出力は別のものです。正確なFPカウントシステムを仮定すると、私が1年間で100FPのシステムを納品し、ジョーが同じ期間で50FPのシステムを納品した場合、私がより生産性が高いと仮定できますか？私はそうは思いません。私の100FPのうち、顧客にとって実際に役立つ機能は30しかないかもしれませんが、ジョーのものはすべて役立つ可能性があります。したがって、私の直接的な生産性は高いものの、ジョーの真の生産性の方が高いと主張します。

Jeff Griggは、ファンクションポイントの配信に影響を与える内部要因を指摘しました。「私の100ファンクションポイントは非常に似たような機能であり、再利用を適切に活用できなかったため、1年間かかりました。ジョーの50機能は（彼にとって悪いニュースですが）すべて非常に異なります。ほとんど再利用は不可能です。しかし、ほとんど再利用の利活用が不可能な50個の非常に異なるファンクションポイントを実装しなければならないにもかかわらず、ジョーは素晴らしい男なので、わずか1年でそれをすべて行いました。」

しかし、これらはすべて、役に立つ機能でさえ真の尺度ではないという点を無視しています。私が上手になると、30の役に立つFPの機能を生成し、ジョーは15しか生成しません。しかし、ジョーの15が顧客に1000万ドルの追加利益をもたらし、私の仕事は500万ドルしか生まないことがわかりました。私は再び、ジョーの真の生産性の方が高いと主張します。なぜなら、彼はより多くのビジネスバリューを提供しているからです。そして、ソフトウェア開発生産性の真の尺度は、提供されたビジネスバリューに基づいているべきだと主張します。

この考え方は、成功率にも影響を与えます。ソフトウェアの成功に関する一般的な発言は誤りです。なぜなら、人々はWhatIsFailureを理解していないからです。私は、成功したプロジェクトとは、プロジェクトのコストよりも多くのビジネスバリューを提供するプロジェクトであると主張するかもしれません。したがって、ジョーと私がそれぞれ5つのプロジェクトを実行し、私が4つ成功し、ジョーが1つ成功した場合、私はついにジョーよりも良い仕事をしたと言えるでしょうか？必ずしもそうではありません。私の4つの成功がそれぞれ100万ドルの利益を生み出し、ジョーの1つの成功が彼のすべてのプロジェクトの費用を合わせたものよりも1000万ドル多くを生み出す場合、昇進を受けるべきなのは彼です。

「測定できないものは管理できない」と言う人もいます。それは言い逃れです。企業は、価値を本当に測定できないものを常に管理しています。企業の弁護士、マーケティング部門、教育機関の生産性をどのように測定しますか？できませんが、それでも管理する必要があります（詳細についてはロバート・オースティンを参照してください）。

チームの生産性を把握するのが難しい場合、そのチームにおける個々の貢献を測定することはさらに困難です。反復ごとに提供する機能の数を見ることで、チームの出力のおおよその感覚を得ることができます。それは粗雑な感覚ですが、チームがスピードアップしているか、あるチームが別のチームよりも生産性が高いかどうかのおおよその感覚を得ることができます。しかし、個々の貢献を評価することははるかに困難です。一部の人は機能の実装を担当しているかもしれませんが、他の人はサポートの役割を果たし、他の人が機能を実装するのを助けているかもしれません。彼らの貢献は、チーム全体の生産性を高めているということです。しかし、そのチームの開発者でない限り、個々のアウトプットの感覚を得るのは非常に困難です。

これですべてが複雑でない場合、エコノミスト（2003年9月13〜19日）は生産性動向に関する記事を掲載しました。経済学者は現在、90年代のコンピューター投資によるビジネスにおける生産性向上が見られるようになっています。重要なのは、改善は投資に遅れることです。「コンピューターへの投資は、自動的に生産性向上を促進するわけではありません。企業はビジネス慣行も再編成する必要があります」。同じ遅れは電力の発明にも起こりました。

したがって、ビジネスバリューの測定が難しいだけでなく、タイムラグもあります。そのため、彼らが構築していたソフトウェアのリリース後数年経たないと、チームの生産性を測定できない可能性があります。

なぜ生産性の測定が非常に魅力的であるのかがわかります。もしそれができれば、現在よりもはるかに簡単に、客観的にソフトウェアを評価できるでしょう。しかし、誤った尺度は事態を悪化させるだけです。これは、私たちが無知を認める必要がある場所だと思います。