包丁を握る手と、キーボードを叩く手
料理をする人とプログラムを書く人。
ふたりが同じ部屋に座ったとき、話は噛み合わないことが多い。片方は「火加減」と「塩加減」を語り、もう片方は「処理効率」と「例外処理」を語る。語彙が違う。道具が違う。
だが、問題の構造は——驚くほど同じだ。
レシピは関数である
料理のレシピを書いたことがあれば、気づくはずだ。
レシピは 入力と出力を持つ手順書 だ。
入力: 卵3個、砂糖50g、薄力粉100g、バター60g
手順: [1. 卵を溶く, 2. 砂糖を加える, 3. ...]
出力: スポンジケーキ1台これはプログラミングの 関数（function） と同じ構造だ。同じ入力を与えれば、同じ出力が得られる——理論上は。
「理論上は」と書いたことに、料理をする人はすぐ気づく。卵の鮮度、バターの温度、室温の湿度、混ぜる速さのわずかなブレ。レシピ通りにやっても、毎回まったく同じスポンジにはならない。
プログラマーはこれを 副作用（side effects） と呼ぶだろう。関数の外部状態に依存する振る舞い。完全に純粋な関数は、現実の厨房には存在しない。
だから熟練の料理人は「レシピを守る」のではなく「レシピを読む」。センサーはレシピの外にある。生地の感触、卵のなじみ具合、オーブンの癖——これらを 実行時の変数 として読み込んで、手順を動的に修正する。
プログラマーがコードをデバッグするように、料理人は鍋の声を聞く。
ミザンプラスはアーキテクチャだ
フランス料理の専門用語に ミザンプラス（mise en place） がある。「すべてをあるべき場所に」という意味。調理を始める前に、食材を切り揃え、計量し、道具を配置する——その準備の哲学だ。
プロの料理人は、調理中に「あ、にんにくを刻み忘れた」と思って手を止めない。手を止めた時点で、タイミングが死ぬ。火加減が崩れ、食材が変化する。
だからすべては事前に整えられている。
これは ソフトウェアアーキテクチャ の設計思想に重なる。
システムを動かす前に、依存関係を整理し、インターフェースを定義し、データの流れを設計する。実行中に「あ、この処理が必要だった」と気づいた時点で、コストは跳ね上がる。コードの途中で設計を変えることは、炒め物の途中でフライパンを変えるのに近い。できなくはないが、代償がある。
ミザンプラスは単なる段取りではない。「どの順序で考えるか」という認識論だ。先に整えておくことで、実行中の判断量を減らす。プログラマーが言う「設計に時間をかける」も、同じ意図を持っている。
キャッシュとしての仕込み
日本料理の厨房では 仕込み という概念が重要だ。出汁を取る、食材を下処理する、煮物を前日から仕掛ける。注文が入ってから一から始めるのではなく、あらかじめ中間状態を作っておく。
コンピュータサイエンスでは、これを キャッシュ（cache） と呼ぶ。
同じ計算を何度も繰り返さなくていいように、結果を保存しておく。次に同じ問いが来た時、保存された答えを返す。それだけで、処理速度が劇的に上がる。
料理の仕込みも、本質的には同じだ。出汁は毎回ゼロから取るよりも、まとめて取って保存しておく方が効率がいい。煮物の下味は、時間をかけて食材に「浸透」させておく——これは計算結果を「保存」することと構造的に等しい。
ただし、キャッシュには 有効期限 がある。昨日の仕込みが今日も使えるとは限らない。プログラミングでも「古いキャッシュが新しいデータと矛盾する」という問題はあらゆる場面で起きる。仕込みの鮮度管理は、キャッシュの整合性管理と同じ問いだ。
デバッグとしての味見
「味見をしながら作れ」と料理の先生は言う。
完成してから「しょっぱすぎる」に気づいても、もう遅い。途中の各段階で確認し、ずれを小さく修正し続ける——これが料理のデバッグだ。
プログラミングの世界には テスト駆動開発（TDD） という手法がある。コードを書く前にテストを書く。小さな単位で動かし、赤を緑にして、また次を書く。完成してから全体をテストするのではなく、都度都度確認しながら進む。
どちらも根底にある哲学は同じだ。フィードバックループを短くせよ。
大きく作って全部壊すより、小さく確かめながら進む方が、修正コストが低い。料理人もプログラマーも、経験を積むと「早めの味見」「早めのテスト」の価値を体感的に知っていく。
リファクタリングと料理の進化
同じ料理を100回作ると、プロセスが変わっていく。
「最初はこの順番だったけど、これを先にやった方が洗い物が減る」「この食材はもっと早く投入した方が香りが出る」——実行の中から、より良い手順が見えてくる。レシピは更新される。
プログラミングでは、これを リファクタリング と呼ぶ。コードの外部的な振る舞いを変えずに、内部の構造を改善する。同じ結果を出しながら、より読みやすく、保守しやすい形にしていく。
料理のリファクタリングは、料理人の「体に落ちていく」経験だ。手が最短ルートを覚えていく。頭で考える前に、体が動いている。
コードのリファクタリングは、「読み返した時に意図が伝わるか」という問いだ。未来の自分や他のエンジニアに向けて、書き直す。
どちらも「初めて動いた」ことで満足しない。動いた先に、「これでいいのか」という問いが残る。
創造と制約の同型性
料理とプログラミングは、どちらも 制約の中の創造 だ。
料理は、食材・道具・時間・予算という制約の中で、食べた人の感動を引き出そうとする。プログラミングは、計算資源・開発期間・仕様という制約の中で、ユーザーの問題を解こうとする。
制約がない創造は、創造ではないかもしれない。
詩が5・7・5の音節に縛られるから俳句になる。ジャズがコード進行に縛られるから即興が意味を持つ。料理が食材の性質に縛られるから、火入れが技術になる。プログラムがメモリとCPUに縛られるから、アルゴリズムに価値が生まれる。
制約は創造の敵ではない。制約が、創造の問いを作る。
二つの営みが交差する場所
料理とプログラミングの共通パターンを並べてみると、浮かび上がってくるものがある。
問題を 分解し、手順を 設計し、実行しながら 観察し、結果を 評価し、より良い方法を 探す——この循環が、どちらの営みにも共通している。
ならばこれは、料理とプログラミングだけの話だろうか。
農業も、建築も、執筆も、音楽も、この循環の外にはないかもしれない。人間が「作る」という行為の核心に、この構造が埋め込まれているとしたら——。
料理人がコードを読む必要はないし、プログラマーが厨房に立つ必要もない。
でも、もし相手の言葉で自分の仕事を語れたなら。もし異なる領域が同じ問いを抱えていることに気づいたなら。
その交差点で、何かが生まれるかもしれない。
それが何かは、まだわからない。