プログラマの妻たちへ（料理とプログラミング）

料理をしたことがない／できない、というプログラマを夫(もしくは彼氏)として持つ人がいたら、以下のように説明すると料理を作ってくれるようになるかもしれません。

料理はソフトウェア開発と同じなんですよ！（言い切る）
両者には、以下のような対応関係があります。

料理に関する概念	ソフトウェア開発における対応物
レシピ	仕様書、設計書
レシピに従って料理を作る事	コーディング、プログラミング
できあがった料理	プログラム
食べる	ソフトウェアを実行する
味見	テスト
栄養バランスや残食材とコストを検討して長期的に飽きない持続可能なおいしい献立のシーケンスを検討考案する。	マネージメント、リソースマネージメント。
食べる人の好みを配慮して献立を決定する。	マーケティング、要求開発。
「美味しい」という概念	ソフトウェアにおける「美しさ」という概念
レストランのフレンチフルコースもしくは懐石料理	商用大規模開発

詳細なレシピに字句通りにしたがって、料理を一回限り作るのは、設計書をそのままコードに書き下すのに似てます。このような作業は一見知的能力を必要としない機械的作業のように思えます。しかし、それでは済まないのが普通であり、多くの場合、思わぬ失敗や予測困難なトラブルに刻々と対処していく事になり（塩辛い！みりん切れてる！鰹節取り出し忘れた！里芋が無い！etc.etc.）、適切な対処をするには、高度なノウハウが必要です。加えて、レシピの行間を読んだり、不足を補ったり、効率よく実装（料理）するのにも高度なスキルと経験が必要になるのです。

新たなレシピを作り出すのは、もう一段上の難易度であり、料理経験を踏み、努力と試行錯誤とちょっぴりの才能をもってして、はじめて良いレシピを作る事ができます。

ソフトウェア開発における、業務システムや基幹系とかの商用開発、あるいはチームでの開発は、レストランで多人数のチームでフルコース料理を作ることなどに対応します。この場合、料理技術以外にもコミュニケーションスキルやリーダーシップが重要になってきます。

１回こっきりの料理や休日だけの料理ではなく、コスト（＝家計）を考えて持続可能な形で毎日料理を継続していくのには、料理そのものとは全く異なる次元の多角的・立体的な（時間軸を考えた）認知のレベルが必要であり、これはソフトウェア開発ではリソースマネージメントなどに該当します。

それぞれ時にはアートとみなされたり、センスが要求されるのも同じです。同じ「料理」といっても、朝食に卵掛けご飯をつくるのと、海原雄山の「美食倶楽部」レベルの料理を作るのとの間には、大きな差がある、というような範囲の広さと言う点でも似たところがあると思います。

ある種の「ソフトウェア工場」と言われるような大規模長期間開発は、全国フランチャイズの大規模チェーン居酒屋のメニュー開発と実装に相当するかもしれません（強引ですが）。

なお、料理を作る手順をステップバイステッップで書き下した「レシピ」が「プログラム」で、「レシピを書き下すこと」を、「プログラミング」と見なしたくなるかもしれませんが、違います。レシピが対応するのは、設計書もしくは仕様書（「入力＝材料」と「大まかな実行手順＝フローチャート」レベルの仕様記述）です。レシピは、そのまま実行可能でもなく、正確に再現可能なほどの厳密さも持ちません。レシピ（仕様）を元に、料理する（プログラミングする、実装する）事で、料理（実行可能なプログラム）が生じるのです。

そして完成した料理（＝プログラム）は頂く（＝実行される）ことによって機能を発揮します。この実行は一回限りです。うまく作れて美味しく食べ終わったときの喜びと、作ったプログラムが意図通りに十全に機能した時のうれしさは等価なものだと思います。

料理の「美味しさ」とソフトウェアの「美しさ」の類似点は以下の通り。

• 一見主観の様にみえながら、客観的ファクターに多くが還元される
• 文脈に依存する

・・・というような説明で、いざ、旦那（もしくは彼氏）を料理好きにしてしまいましょう。優秀なプログラマであれば料理の素養はばっちりです。ただし、一人前になるには相当の教育コストがかかると思うべきでしょうけれども。

「俺はプログラマだから『段階的抽象化』『間接参照レイヤの導入』によって問題を解決する、つまり人に命じてやらせるのが得意だ」とか言い出したら末期症状なので追い出しましょう。

プログラマの妻たち

金曜日の妻たちへ DVD-BOX

おまけ

ソフトウェアと料理で似てないところ：

• 決定論的であるかどうかの度合い。同じインプッットで同じアウトプットが出てくるかということについて、ソフトウェアが常に決定論的であるとは限らないけれどもソフトウェアの方が遥かにその度合いは高い。なので料理の場合、味見が重要という事になる。
• レシピは通常試行錯誤をへて作成され、従って実績があり、（それが広まれば）何度も実装され、実装それぞれが１回だけ実行される。方や、ソフトウェアの仕様は通常１回も実行されずにぶっつけ本番で作成され、それを元にやはり１回だけ実装され、多数回実行される。この結果ソフトウェア開発の方が遥かに難易度が高く、予測も難しい。
• 規模。料理の実装には何ヶ月もかかったりする事はあまり無く、通常数時間程度。
• 素材の差異。料理の結果は素材に大きく左右されるが、ソフトウェアはそうではない。ソフトウェアにとって素材ってなんだろう。
• 結果の重要性や関わる金銭の多寡。料理が失敗しても高々「食えない」「まずい」「金返せ」ぐらいだが、ソフトウェア開発が失敗すると原発が止まったりロケットが落ちたりする場合もある。死の行進とかになったりすることもままある。