プログラミングとおいしい料理

経験則になるが、機械でもソフトウェアでも、「短時間で作り上げたものは壊れにくく、長時間かけて作ったものはすぐ壊れる」という感覚がある。長時間かけて作るというのは、作る過程で試行錯誤が入っているため、無駄が増え、複雑になるため、ちょっとしたことで動かなくなるというような意味である。

料理も、いつまでも材料をいじくっているとおいしくならない。じっくり煮込む必要があるものもあるが、プログラムは放置しておいても何も変わらないのでここでは触れない。段取りと手際のよさがおいしい料理の秘訣である。

プログラミングも料理も試行錯誤しながら作っているうちは、いいものになりそうにない。当然新しいものに対しては、試行錯誤が必要であるが、それはそれで別に作るとして、実際のソフトウェアを作る際には、悩んでいてはいけない。

実際に納品するべきプログラムというのは、悩まずに作り上げると言うのが理想である。といっても規模の問題があるので、まずは部品レベルをそれぞれ悩まずに仕上げる。料理で言うところの下ごしらえである。そして、下ごしらえしたものを悩まずに手早く組み合わせることで、ソフトウェアを完成させる。

その後、実際に動かしてみたり、仕様変更があった場合には、完成したものを修正するのではなくて、下ごしらえからやりなおしである。ソフトウェアは一期一会、仕様が変われば別のものだ。味付けが違うという場合に、上からソースをかければいいというものではない。

幸い、一度作った部品は、もう一度使いまわすことが可能だ。下ごしらえ部品で足りない部分だけを作って、もう一度組み合わせ作業をするのである。下ごしらえにも階層ができるかもしれないが、それはそれでよい。

ただ、下ごしらえ部品の延長にソフトウェアがあるのではなくて、下ごしらえしたものは、それぞれが依存関係のないばらばらの状態で、最終的なソフトウェアにする時にそれらを一瞬で組み上げれば、たぶん品質の高いソフトウェアができるんだと思う。

つまり、ソフトウェア開発プロジェクトのスケジュールに、下ごしらえ部品作成フェーズと、組み合わせフェーズを用意して、まずは下ごしらえをすべきだということだ。仮組みは何回やってもいいが、正式なソフトウェアとして組む時は、日取りを決めて１日で仕上がるぐらいの粒度になっていればいいと思う。

ソフトウェアはブラックボックスだとよく言われるが、ここまでやれば、何を組み合わせたかがその日のうちに全部わかるわけで、チーム全員が状況を把握できるのではないだろうか。ドキュメントもレシピと呼ぶ事にしよう（嘘

昔流行ったプログラム部品を蓄積しようという考え方に似ているような気もするけど、次で使うために作るのではなくて、今回のプロジェクトに必要な部品を下ごしらえするという点がだいぶ違うのではないだろうか。