プログラミングの本質はコードを書く作業ではない

まぁ、なんか胡散臭いタイトルをつけてしまったが、俺もそう思ってる。
別に「上流過程がうんたら」、「SEにステップアップ」とかそういう胡散臭いことを書くつもりでもない。そういう人は@IT自分戦略研究所にでも逝ってろ。

それよりもっと胡散臭い感じな話。

Joelさんの記事に書かれている通り、プログラマの生産性には大きなばらつきがある。
しかしあらゆるプログラムに対して生産性に差が出るか、というとそうでもない。例えばHello worldだったらどうだろうか？

#include

int main(int argc, char** argv){
printf("hello world\n");
return 0;
}

こんなもんだろうか。今計ってみたら１分経ってなかった。コンパイルも実行もしてないから動かないかもしれないけど。
これで生産性を競うとなると、単純にキーボードを打つ速さを競っているだけである。

で、ようやく本題へ。

Communications of the ACM: August 2000より"Software is not a Product"
http://www.corvusintl.com/CACM_Aug_2000.htm

この記事の続編しか読んでなかったんだけど、ソフトウェアは製品ではなく知識であり、プログラミングとはソフトウェアを作成する作業ではなく、「作成するための知識」を得る作業である、ということだ。

これを考えを元にプログラマの生産性を説明する。
先ほどのHello worldの例で説明すると、多くのCプログラマはprintfで文字が出力できることを知っており、printfを利用するにはstdio.hをincludeしなくてはいけない、ということを知っている。よって、生産性に違いは出ない。

では、ネットワークプログラミング経験者と未経験者でechoクライアント・サーバを書かせるとどうだろうか？経験者ならすらすらと書けるだろうが、未経験者は下手すればIPやポートの概念から勉強しなくてはならない。このように「作成するための知識」の有無によって生産性が変わる。

ここまでは誰もが納得するだろうが、

「じゃあ、いろんな言語やライブラリを使ったことがあるプログラマがいいプログラマなの？」

というと、それも違う。ソフトウェアを「作成するための知識」は「必要な関数群」だけではなく、「どのように組むか」が重要となる。

多分プログラマな人なら分かると思うけど、一度組んだことがあるソフトをもう一度書き直す時はより早く（＝生産性良く）組むことができる。これは「作成するための知識」として「どのようなモデルで組めばいいのか」を知っているからである。

「じゃあ、色々なソフトを書いたことがあるプログラマがいいプログラマなの？」

というと、これまた違う。

例えばちょっとした条件分岐もオブジェクトに分けてポリモーフィズムを利用する方法もあるし、複雑怪奇なif文で実装することも可能である。このように、「どのように組めばスマートに組めるのか」が重要であり、その閃きがあるか、ということが重要なんだろう。

「じゃあ、その閃きはどうやったら手に入れられるの？」

と言われると、わからない。やばい。わからないなんてやばすぎる。宇宙ヤバイ。
俺もその閃きが欲しいもんである。