優秀なほうが安い仮説 - Martin Fowler's Bliki (ja)

http://martinfowler.com/bliki/CheaperTalentHypothesis.html

2008/2/8

ソフトウェア業界では、才能あるプログラマのほうが生産性が高いとよく言われる。 CannotMeasureProductivityなので証明はできないのだけど、おそらくそれは正しいだろう。人間の活動のほとんど全てにおいて、他人よりも優れた人がいるのである。そしてその違いは、著しいことがしばしばだ。ソフトウェア業界においては、プログラマ自身がその違いに気づくことが多い。ただ、その場合も常に自分を「才能ある方」に入れているみたいだけど。

当然ながら、優れたプログラマは、フルタイムで雇うにせよ契約するにせよ、その単価は高い。しかし、たとえ単価が高いとしても、’'’高価なプログラマのほうが実際には安価なのではないだろうか？’’’

バカげた質問に聞こえるかもしれない。何をどうしたら高価な人材が安価になるっていうんだろう？タネ明かしをすると、まぁいつものことなんだけど、価格と価値に対する視点をもっと広げることにある。

テクノラティで検索すると、才能あるプログラマのほうが平均的なプログラマよりも生産性が高いことは概ね同意されているようだが、計測が不能なのだから実際の数字に表すことはできない。そこで、この議論のために、仮に「2」という数字を設定してみよう。つまり、才能あるプログラマは、給料が半分以下の平均的なプログラマに比べて、生産性が2倍高いということにする。すると、才能あるプログラマのほうが結果的に安価だということが分かるだろう。なお、コストの差額が生産性の差分よりも小さかったら、高価な開発者を雇うほうが安価であると考えることにしょう。「優秀なほうが安い仮説」とは、コストの差額が実際には小さくなる、というものである。そのため、単価が高くてもより生産性の高い開発者を雇うほうが、結果的に安くなるということである。

これが我々ThoughtWorksの哲学の鍵だということにお気づきだろうか。私が独立コンサルタントを辞めてThoughtWorksに入社した理由がココにある。我々の単価は高いかもしれない。しかし、最終的には、クライアントにとって安価になると我々は信じている。もちろん、多くのクライアントにこれが正しいと説得しなければならない難しさはある。ここでも、生産性を計測する客観的な指標がないことがネックになる。以前、見込み客が、以前失敗した未完のシステムを担当した企業よりも、我々のほうが料金が高いことに文句をつけてきたことを今でも覚えている。我々は、少ない料金を払ったことで何の価値ももたらさないプロジェクトにしてしまったことが、いかにファイナンス的に良くない戦略であったかを、丁寧に指摘しなければならなかった。

「優秀なほうが安い仮説」には注目すべき結果がいくつかある。もっとも注目すべきは、好ましいスケーリング効果があることだ——チームサイズが大きくなればなるほど、優秀なほうが安いという利点が大きくなるのである。たとえば、10人の優秀な開発者でチームを作るとしよう。彼らは平均的な開発者のチームの2倍の生産性があるので、給料も2倍だ。これはどこか違う世界の話なので、細かいところは気にしないでおくれ。さて、この場合、優秀な開発者に対応するには、平均的な開発者は何人いればいいだろうか。単純に考えると20人ということになる。

しかし、生産性はチームサイズに対して線形にスケールするわけではない。チームサイズが重要なのではない。ソフトウェア開発においては、チームメンバとのコミュニケーションが重要なのである。ソフトウェアチームにおけるもっとも大きな課題は、他のメンバが何をしているかをチームメンバ全員が確実に理解することである。そのため、チームサイズが大きくなるにつれて、生産性は低くなるのである。ここでもまた明確な測定基準はないのだが、私はチームサイズの平方根が生産性の値になるのではないかと思っている。何の証拠もない私の推測をベースにすると、2倍の生産性を得たければチームサイズを4倍にする必要がある。つまり、優れたチームの2倍の生産性を得るには、平均的なチームのチームサイズは4倍、つまり40人にする必要がある。すると、コストについては2倍になるわけだ。

もうひとつここで重要となる要因は、製品化に要する時間（タイムトゥマーケット）である。 2つの4人チームを考えてみよう。1つは優れたチーム。もう1つは平均的なチームだ。優れたチームが有利にならないように、上の段落で使った数字を割り引くことにしよう。ここでは、優れたチームの生産性は平均的なチームの2倍とする。なお、優れたチームの給料は2倍だ。これでファイナンス的にはどちらのチームを選んでもよいことになっただろうか？

残念ながら、またもや優れたチームが勝つのである。優れたチームは平均的なチームの半分の時間でプロジェクトを完遂する。つまり、顧客は、納品されたソフトウェアを使って、より早く価値を生むことができるのである。より早く生み出された価値は、お金の時間的価値によってさらに強化され、かかるコストが一緒であっても、ファイナンス的に優れたチームを選ぶほうがメリットがあることを示すことになる。

さらに、アジャイル開発がこの効果を一層加速させる。優れたチームは、平均的なチームよりも速いスピードで開発サイクルをまわすことができる。これにより、チーム全体が、構築、評価、最適化の選択肢をより速く見つけることができる。この高速化によって、よりよりソフトウェアを構築できる。結果として、より高い価値を生み出すことになる。これが、タイムトゥマーケット効果をさらに増強するのである。（それに、当然のことながら、優れたチームのほうがよりよいソフトウェアを開発することができるだろう）

より速くサイクルをまわすことで、製品はよくなっていくだろう。しかし、優れたチームがもっとも貢献できるのは、おそらく、ソフトウェアの内部的な品質の向上なのである。優れたプログラマと平均的なプログラマの生産性の違いよりも、優れたプログラマのコードと平均的なプログラマのコードの違いのほうが大きい。優れたプログラマは優れたコードを作り出す。このことはつまり、内部的な品質が優れているために、優れたプログラマの生産性は時間の経過にともなって向上していくということである。

このことはすべて、少なくとも私にとっては、説得力のある話だ。それにこれは、広く受け入れられたものでもある（少なくとも、自分のことを優れたプログラマだと思っているプログラマにとっては）。しかし、ソフトウェア業界全体で受け入れられているとは言いがたい。というのも、優れた開発者への給料や契約金のプレミアムは、生産性の違いほど差がないからである。雇用者は、高価なプログラマが実際に生産性が高いという客観的な証拠を持っていない。コストが高いということだけが客観的だ。結果として、雇用者は、価値が高いという主観的な判断と、コストが高いという客観的な判断とに折り合いをつけなければならない。多くの雇用者は、個人的に優れたプログラマに価値があると信じていても、マネージャや人事部や購買部に対して、そのコストの全額を正当化する覚悟ができないのである。

これは主観的評価においても難しい。ThoughtWorksでは、同僚の評価に頼っている——開発者の能力はチームメンバによって評価される。結果が正確になることはないが、誰にでもできるベストな方法である。

優れたプログラマの採用や雇用は難しい。採用や評価は難しい仕事だ。非常に個人的な要望を持った人を扱わなければならない。これは薄給であることよりも重要なことである。雇用者は、追加業務と高いコストと主観的な生産性の高さの対立に直面するのである。