ソフトウェア開発が建築よりも料理に似るべき理由

　ソフトウェア開発は建築よりも料理に似るべきだと『ソフトウェア開発と建築と料理の類似性』に書きましたが、その理由をもう少し考えてみます。

　建築は、ピラミッド型の体制で、設計をしてから、設計のとおりに建てます。現場で設計を変更せざるを得ないことが起きた場合には、手戻りが発生し、費用やスケジュールに影響を与えるはずです。

　設計する人の中には、建物を建てる方法は知っていても、自らの手を使って建物を建てることのない人もいます。大規模な建物になればなるほどそうなります。

　料理は、できあがりのイメージを持ちながら、手を動かして作っていきます。出来具合を見ながら火加減を調整したり、味見をしながら塩加減を調整したりします。

　レシピだけを書いて実際に料理をしない人は、いないと思います。もし、いたとしてもおいしい料理ができるとは思えません。

　満漢全席のような料理であれば、複数の人が分担して料理し、全体を調整する人がいるはずです。全体を調整する人でも、ひとりで全料理を作れるとは限りません。それでも料理をしたことのない人に、務まるはずがありません。

　ソフトウェア開発には、両方の世界があります。大規模なシステムをウォーターフォール型で開発するときは、建築の世界と同じです。日本のＩＴベンダーは、ほとんどがこちらの世界にいます。

　ソフトウェア開発では、コードを書いているときに設計を変えたくなります。実際に作り、動かしてみないと最適な設計かどうかわからない面があります。アジャイル開発手法が提唱されたのもそのためです。

　ソフトウェア開発は、プログラムを動かしてみるまで、結果がわかりません。途中の段階で出来上がりを予想できるのは、コードレビューに参加している人ぐらいです。

　建築は、途中の段階でも素人目にもある程度、見てわかります。料理の途中では、最終的においしいものができるかどうかは、味見をした人ぐらいにしかわかりません。

　ソフトウェア開発は、後から設計を変更したくなる、結果が見えないという２つの理由から料理に似るべきです。それを建築のように開発すると、優れたものにはなりません。

　日本の大手ＩＴ企業は、大量の大規模なユーザー向け業務プログラムを開発するために、建築のようなウォーターフォール型の開発ばかりをしています。

　そのため、ソフトウェアエンジニアにプロジェクト管理ばかりをやらせています。それが、米国のソフトウェア開発企業に大きな差をつけられた原因の一つになっています。