寓話
両手でメニューは書けるが、厨房にはシェフが一人しかいない
老舗酒楼の厨房管理は二つの段階を経た。第一段階は、老師匠の頭の中にあるレシピをすべて標準作業カードに書き出すこと：各料理の材料のグラム数、火加減の時間、盛り付け方法をすべて紙に落とす。新しい料理人は作業カードを見れば同じ品を再現でき、師匠の口伝に頼らなくなった。これが無形の経験を有形の文書に変えるということだ。
第二段階の問題が来た。操作カードが料理人それぞれのポケットに散らばっていた。塩の量を変えたのに誰にも知らせない者、古い版のカードを受け取っている者、改良したのに他の持ち場が知らない者。同じ糖醋魚が、三つの竈で三つの味になった。操作カードは書かれたが、版は乱れていた。
料理長は一つのことをした：すべての操作カードを共用のトタン棚に保管し、棚の鍵は一本だけにした。誰かがレシピを変えたいなら、彼を通さなければならない——古いカードを提出し、理由を説明し、新しいカードを受け取る。トタン棚の中のカードが唯一信頼できるバージョンであり、厨房は棚の中のカード通りに料理を作り、毎日作業開始前に一度確認する。
さらに半年後、総料理長は中央棚だけでは足りないと気づいた。新しいカードに従って料理を作っても、実際の火加減はカードと完全には一致しない——厨房が実行しているものと、棚に書かれているものの間に検査の工程が欠けている。彼は手順を一つ追加した：毎日正午に二品を抜き取り検査し、完成品を操作カードと比較し、偏差があればすぐにカードの誤りか人が従わなかったのかを追跡する。
このブリキ缶と毎日の照合の組み合わせこそ、後厨が「ファイルに書く」を経て初めて踏んだ第二の落とし穴である。操作カードだけでは Infrastructure as Code——設定を読めて再現可能なファイルに変えること。ブリキ缶に単一の鍵、バージョン管理、自動照合を加えて初めて GitOps——中央リポジトリを唯一の真実の源とし、実際の状態が逸脱していないか継続的に検証する。
酒楼の厨房器具の調達も後に同じ道をたどった。以前は調達リストを調達係のノートに記していたが、共有ドキュメントに変えてから確かに明確になった。しかし、共有ドキュメントを「厨房主管のみが変更でき、調達係は閲覧と発注のみ」に設定し、毎日自動で一回照合するようになって初めて、調達の偏差率は本当にゼロになった。
厨房の総括会で、総料理長は黒板に一本の線を引いた。左側には「文書に書けば伝達できる」、右側には「文書を唯一の倉庫に閉じ込め、毎日検証する」と書いた。彼は二つの段階がそれぞれ一つの価値を持つが、大きな価値を持つのは第二段階だけだと言った。