タイラー・コーエンがMarginal Revolutionの12/23エントリで引用している文章が興味深い。以下がその引用部。
Software output cannot be measured as easily as dollars or bricks. The best programmers do not write 10x as many lines of code and they certainly do not work 10x longer hours.
Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem. They may cheat. But just when they are being their most productive, nobody says “Wow! You were just 100x more productive than if you’d done this the hard way. You deserve a raise.” At best they say “Good idea!” and go on. It may take a while to realize that someone routinely comes up with such time-saving insights. Or to put it negatively, it may take a long time to realize that others are programming with sound and fury but producing nothing.
（拙訳）
ソフトウエアのアウトプットは、（営業が稼ぐ）ドルや（レンガ職人が積み上げる）レンガのように簡単に計測することはできない。最良のプログラマは10倍の行数のコードを書くわけではなく、10倍の時間働くわけでは決して無い。
プログラマが最も効率性を発揮するのは、コードを書くことを回避する時だ。たとえば、自分たちに与えられた課題は本来解決すべき課題ではなく、顧客の要望が実際の需要に一致していないことに気付く場合だ。あるいは、彼らの課題を解決するには、あの再利用ないし再編集可能なコードを使えば良い、と気付く場合だ。あるいは、誤魔化しをする場合だ。しかし、プログラマが最も生産性が高い時に、「おお！ 正面から問題に取り組んだ場合に比べて100倍の生産性を上げたね。昇給ものだ。」と言ってくれる者は誰もいない。「グッド・アイディア！」と声を掛けて通り過ぎるのがせいぜいだ。ある人が決まってそういった時間節約的な発想をもたらしてくれることに気付くのには時間が掛かる。逆の言い方をすると、別のある人が一所懸命になってプログラムを書いているが、何も生産されていないことに気付くには長い時間が掛かる*1。
引用対象のブログエントリは、ジョン・クック（John D. Cook）という数学者のもので、なぜプログラマの能力の差が収入の差にあまり反映されないのか、ということについて書いている。コーエンは、プログラマに限らず企業内の個人の生産性の差の一般的な話として、こうしたことを経済学者がもっと研究すべきだと考えているとの由。
ちなみに、文中の「再編集可能（re-editable）」という言葉には、クックの以前のエントリへのリンクが張られている。そちらのエントリでは、ドナルド・クヌース（Donald Knuth）のインタビュー記事から以下のような発言が引用されている。
I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.
（拙訳）
再利用可能なコードの流行に対しては強い反発を感じていることも言っておくべきだろうね。私にとっては、「再編集可能なコード」の方が、中身を触れないブラックボックスやツールキットよりもずっとずっと良いものだ。このことについては話し始めたらきりがない。もし再利用可能なコードが素晴らしいものだと確信している人がいたら、その人の意見を変えさせることはできないだろうが。ただ、再利用可能なコードは基本的に厄介者である、という私の意見を変えさせることもできないだろう。
また、「誤魔化し（cheat）」という言葉にも別のエントリへのリンクが張られているが、そこには以下のようなことが書かれている。
Sometimes we’ll struggle mightily to solve a problem analytically that could be easily be solved numerically (or vice versa). Or we’ll imagine that a problem must be solved using a particular programming language even though it could be done more easily using a different language. It feels like “cheating” to go for the easier solution. But if you’re not in an academic setting, you can’t “cheat.” (Of course I’m not talking about violating ethical standards to solve a problem, only dismissing artificial restrictions. Where there is no law, there is no sin.)
There may be good reasons for pursuing the more difficult solution. For example, entertainment value. Sometimes we want to see whether we can do something the hard way. There’s nothing wrong with that, as long as we acknowledge that’s what we’re doing. But sometimes we do things the hard way for no good reason other than not having examined our self-imposed limitations. Maybe we’re trying to win rather than solve the problem.
（拙訳）
時々我々は数値的に簡単に解ける問題を解析的に解こうとして（もしくはその逆で）頑張る。あるいは、ある問題を特定のプログラム言語を使って解かなければならないと思い込む――他の言語を使えばもっと簡単に解けるにも関わらず。簡単な解決法を使うのは「誤魔化している」ように感じるわけだ。しかし、学術研究でなければ、「誤魔化し」になるはずもない*2。（もちろんここでは、問題解決のために倫理基準を破ることではなく、あくまでも人為的な制約を取っ払うことだけを指している。法が無ければ罪もなし。）
より困難な解法を追究するべき立派な理由があることもある。たとえば、楽しみのためだ。あることを難しい方法でできるかどうか試したい時もある。そのこと自体に問題はない――自分が何をしているかわきまえている限り。しかし、難しい方法を採る唯一の理由が、単に自ら課した制約を碌に検討しなかっただけ、という場合もある。そうした場合、我々は問題を解決しようとするのではなく、問題に勝とうとしているのかもしれない*3。
なお、The Baseline Scenarioのジェームズ・クワックも、コーエン経由でクックのこのエントリを取り上げ、以下のようなことを書いている。
- 営業も事前や事後の周囲のサポートがあって初めて良い契約が取れることが多い。また、多分に運もモノを言う。従って、売上高で完全にその営業マンの能力を判定できるわけではない。
- ただ、本当に優れたプログラマはやはり周囲から認められる。そしてクック自身が（上記の引用部の前段で）書いているように、そうしたプログラマは転職したり独立したりしてより多く稼ぐようになる。その意味で、能力に応じた収入を得る仕組みもある程度は存在していると言える。
- 本当に優れたプログラマの評価について衆目が一致することが多いにも関わらず、同じ会社内ではそれほど給与格差が付かないのは、社会的文化的要因が大きいだろう。営業マンは各人が一匹狼だという意識が強いのに対し、プログラマはチームワークが重要視されることが多いので、チーム内の大きな給与格差は士気の低下を招いてしまう。
- もう一つの理由は、やはり経営側の問題。彼らはソフトウエア開発というものを得てして理解していない。たまに目利きの経営者もいるが、数が限られているので、優秀なプログラマの価格を競り上げるとしても限りがある。言ってしまえば、プログラマの価値を理解していない大部分の経営者が、サマーズやデロングやフィッシャー・ブラックらの言う「ノイズ・トレーダー」の役割を果たしている*4。
*1:この辺りは、矢野さんが以前書かれていたこのエピソードが連想される。
*2:この文章は学術研究を前提に書いているが、“簡単な解決法を使うのは「誤魔化している」ように感じる”のは一般社会でも良く見られるところである（小生が以前書いたエントリの掃除機のエピソードを参照）。そもそもリンク元でも、実務界のプログラマの手法としてcheatという言葉を使っている。
*3:引用部の前段では、レッドベルトという映画の柔術指導者の主人公が取り上げられている。彼は試合を好まないが、それは恣意的なルールが課せられるためである。また彼は、闘いは勝つこと（win）ではなく優勢になること（prevail）が目的だと考えている。
*4:cf. デロング、シュライファー、サマーズ、ワルドマンの論文「Noise Trader Risk in Financial Markets」では、ノイズ・トレーダーの存在により市場のアービトラージの機能が損なわれ、価格がファンダメンタルから乖離する可能性を理論的に示している。
