「設計」を、以下のように定義してみる。

・設計とは、設計図をつくることである。
・設計図とは、「それに従えば、誰が作っても同じものができる」ものである。

ここで「誰が作っても同じ」というのはもちろん、作る人に一定のスキルがあるというのが前提で、また「同じ」といっても、許容しうる程度の違いはあるものとする。

建築の場合、建築家が「設計」し、工務店などの施工業者が「施工」する。
設計がきちんと作りこまれていれば、施工業者が作り出すものにはそれほど大きな開きは出ない。

しかしソフトウェアでは、「設計」と「実装」をそれほど明確に切り分けられない。
ソフトウェア開発において、「そこから先は、誰が作っても同じものができる」レベルとは、一体どのあたりだろうか。
モジュールやクラスを決めるくらいでは、「そこから先は、誰が作っても同じものができる」レベルにはほど遠い。
では、関数やメソッドのインターフェイスを決めるくらいだろうか。そこまで決められれば、「そこから先は、誰が作っても同じものができる」とまではまだ言えないにしても、残された「揺れ」は比較的少なくなっている。
しかし、関数やメソッドのインターフェイスといった詳細なレベルまで決めることが「設計」であるならば、それはほとんど「プログラミング」そのものと同じではないだろうか。

そしてソフトウェア開発においては、この「設計」自体がしょっちゅう変わる。プログラミングとは、まず設計を決めて、その内部を実装する、といった「ぬりえ」のようなプロセスではない。ああでもない、こうでもない、というトライ＆エラーで、「設計」自体を何度もやりなおすようなプロセスだ。それはまさに、建築家やグラフィック・デザイナー、ファッション・デザイナーなどが、ああでもない、こうでもない、というトライ＆エラーを繰り返しながらデザイン＝設計を作り上げていく、それと同じような作業だ。つまり、プログラミング自体が「設計」なのだ。

私は以前、「ITが建築から学べるものは多い」と書いたことがある。この考え自体はいまでも変わらないが、ITにおける「実装＝プログラミング」と、建築における「施工」は、かなり異質なものであることも確かだ。ITにおける「実装＝プログラミング」は、上記のようにむしろ「設計」に近い。

IT業界は「ITゼネコン」という言葉もある通り、業界の構造としては建設業界とかなり似ている。ソフトウェアの大きなプロジェクトは「ITゼネコン」が受注し、その下に多重下請け構造があって、ＳＥ・プログラマが人月ベースで大量投入される。こうした慣行のベースには、「ソフトウェア開発は労働集約的な仕事であり、単純にたくさんの人間を投入すれば早く仕事が進む」という考え方がある。これこそまさに、ITにおける「実装＝プログラミング」を、建設における「施工」と同一視する見方だろう。

もちろん建設における「施工」にも、一定のスキルや経験が求められる。それはどんな仕事でもそうだろう。しかし、それが基本的に労働集約的な仕事であり、たくさんの人を集めればそれだけ仕事が早く進む、という性質を持つことも確かだと思う。このような労働集約が効くのは、「誰が作っても同じものができる」からだ。

いっぽうITにおける「実装＝プログラミング」は、労働集約的ではなく、知識集約的な仕事だ。無意味に大きいソフトウェアは有害であり、むしろできるだけ小さいほうがいい。いくら多くの人間や時間、労力を投入したとしても、それはソフトウェアの品質と何の関係もなく、１００人の凡人が束になっても、１人の専門家のスキル・知識にかなわない。「誰が作っても同じものができる」にはほど遠く、むしろ「誰が作るかでぜんぜん違う」世界なのだ。

日本のIT業界が間違った方向に来ている理由は、業界構造や雇用・待遇などの問題もあるが、まず根本的に、ソフトウェア開発・プログラミングとはどういう活動なのかという認識が間違っているのだと思う。プログラミングとは「設計」そのものであって、「誰が作るかでぜんぜん違う」。これを労働集約的なものと見なしたところが、間違いの根源だろう。

ソフトウェアとはそもそも、情報の処理を自動化するものだ。もし「誰が作っても同じものができる」ような自明なプロセスが見つかったならば、間違いなく、そのプロセス自体がソフトウェアで自動化される。これがソフトウェアという情報世界の強みであり、面白いところだ。物質世界では、わかりきった自明のプロセスであっても、機械で自動化するのは容易ではない。

よってソフトウェア開発という世界では、「誰が作っても同じものができる」ことは今後もずっとありえないのであって、プログラミングは永遠に「設計」でありつづけるのだ。