ここまでは、誰もが同意するだろう。

従来のソフトウェア工学が決定的に間違っている点 - kwatchの日記
仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。頭の悪い大人100人より、すごく頭のいい小学生1人のほうが、成果物が出る。ソフトウェア開発はそういう類いの仕事。

にも関わらず、

ソフトウェア開発も同じような体制にしたほうがいいのではないか。生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。

とならないのはなぜか。

生産性は定数ではない

まず一番の誤解が、これ。頭の悪い大人100人も、教育次第で頭が充分よくなる可能性があるし、実際そうなっている。その頃には頭のいい小学生の生産性もさらに上がっているかもしれず、相変わらず生産性の差(正確には「比」だが、対数スケールで見れば「差」なのでそのまま)は30倍かも知れないが、しかしそれは頭の悪い人が30秒でやることを1秒でやる、という風にはならない。「30倍難しい問題」を同じ期間で解くとか、30日かかっていた仕事が1日で終わるとかという風にはなるかも知れないが。

ソフトウェアに限らず、生産の現場で「30倍でやれる」重要なのは、まず「それが出来る」ことであり、次に「予算と納期の範囲内でやれる」ことではないのか。

生産性は何を生産するかで大幅に変わってしまう

Ruby の開発でいえば、まつもとさんやささだ先生にサポートスタッフ (あるいは秘書とか内弟子とか) をつけて、極力彼らが雑用をせずに Ruby 開発に専念できるような環境を整えるべきではなかったか。

しかし、これが「Ruby on Rails の開発」だったら、どうか。MatzさんやささださんはDHHを上回る生産性を上げられるであろうか。そして「twitterの開発」だったら? DHHの方が twitter.com の中の人々よりも生産性が高いのだろうか。

たしかにたいていの場合、より難しい仕事をしているプログラマーは、より簡単な仕事をしているプログラムも書ける。が書けるからといってそれを書きたいわけではないし、書きたくないプログラムを書いている時の生産性というのは、ベストからほど遠いものになる。スーパープログラマーにいやいや仕事をさせるぐらいなら、「並」プログラマーに嬉々として仕事をさせる方がずっといい。スーパープログラマーにとっても「並」プログラマーにとってもいいし、ソフトウェア産業全体にとっても望ましい。

「生産性が高い」プログラマーほど仕事を選ぶ

なぜMatzやDHHといった人々の生産性が高い--ように見えるし実際そう--かといえば、好きな仕事をしているからだ。客の望んだものではなく、自分の作りたいものを作る。それがたまたま「みんなの望んでいたもの」だからこそ、彼らはそうしていられるのだが、しかしそれだけでは「客が注文した」ものは出来ない。「作ってほしいもの」と「作りたいもの」が常に一致していれば双方ハッピーなのだが、そうはよっちゃんイカを食べながら年収1億円とはめったにならない。

スーパープログラマのSIにおける限界 - novtan別館
そんなところにスーパープログラマーを投入するよりは、もうちょっとコアな、真にコンピュータスキルが必要なところに使いたい。ていうか、単純労働なんてしたくないでしょ、スーパープログラマー。

もっとも、スーパープログラマーというのは、必要とあれば単純作業を厭わない人々でもある。Larry Wall に至っては、ハードウェアまではんだごてで治してしまう。FizzBuzzで盛り上がるのも、どっちかといえばスーパープログラマーだったりもする。こういう人たちは、「真の20%ルール」で動いている。「やらなきゃいけない」仕事が20%で、残りの80%が「やりたいしごと」。たとえ単純作業でも、残り80%にそれが属しているのであれば嬉々としてやってしまう。彼らからこれを取り上げてしまうと、残り20%も小さくなってしまう。好きなようにやらせておくのが吉である。

だから、スーパープログラマーだけでは仕事はいつまで経っても終わらないのだ。彼らは延々と自分が好きな仕事を見つけてはそれに没頭しちゃうんだから。

そしてこのことは、まだ「並」なプログラマーにとってのチャンスでもある。はじめからスーパーだったプログラマーなど滅多にいないし、スーパーな連中は自分が好きなことにかまけている。ソフトウェア産業の世界は広大で、今なお広がっている。あなたが入る余地はいくらでもあるはずだ。

Dan the Programmer