ヤバい現場のヤバいコードをノンエンジニア向けに鬼畜レストランで例えてみた

「エンジニアが、なんか色々現場の文句を言ってくるけどその内容がイマイチ理解できてないノンエンジニアの現場責任者の方」
がこの記事の対象です。
ものすごくニッチっぽいけど、実はそうでもない話です。

あなたの開発現場はヤバいですか？

ここで「ヤバい」と言える人はまだ大丈夫です。
何かのセンサーが敏感な方なのでしょう。
「別にヤバくないよ」と思ってしまう場合は、本当にヤバい可能性が高いです。
シロアリに食い尽くされる木造家屋みたいに、倒壊するまで被害に気づかないかもしれないからです。
しかし、この記事では対応方法までは書きません。
ここでは、エンジニア用語そのものではなく「ヤバい現場で作られるコードのヤバさ」を技術用語無しでもわかるように解説します。
それを読んで「ヤバさの温度」を感じてもらうのが目的です。

ここは鬼畜レストラン

ヤバいシステムのコードをレストランで例えてみます。
厨房もある意味専門的な領域ではありますが、システム開発よりかは想像をしやすそうなのが理由です。
これから各話ごとに「よくあるヤバ」をレストランのストーリーで例えた後に、おまけ程度にちゃんとした解説を添えていきます。
もし、このストーリーで本当にエンジニアリングに興味を持った方は、その解説の用語を調べればいいという親切設計です。
では、鬼畜レストラン。開店です！

0. 鬼畜レストランは大規模

鬼畜レストランは、パーティの会場にもなる大きなホールが自慢だ。
当然それに見合う巨大な厨房がある。
そこには30人のシェフがいて、少しでも美味しい料理を早く出そうと忙しく働いている。

1. 効率なんか考えない　（システム設計）

本日最初の注文は「カレーライス」
まずは一人のシェフが動き始める。
自慢のカレーは寸胴に仕込んであるが、その寸胴はいつもホールの真ん中に置いてあるので、
厨房から出て、ホールに向かう。
お客さんのテーブルの間をすり抜けて寸胴を手に入れたら、また厨房に戻る。
寸胴をコンロに載せて火にかけたいが、火がつかないので元栓を開けにいく。
ガスの元栓はレストランの隣のビルにあるので、
外に出てそのビルに入り、元栓を開けた。
また戻り、コンロに火をつけてカレーを温め始めた。
温まるまで微動だにせずにじっと待つ。
そして、十分加熱された気がするので、カレー皿に盛ろうと思ったが、
そもそもカレー皿がなかったので、最寄りのホームセンターに行き、1枚だけ買って帰ってきた。
そして盛り付けようと思ったが、今度はお米がないことに気づいた。
でも、お米の炊き方を知らないので諦めた。
カレールーだけを目分量で盛り付ける。
そういえば寸胴をちゃんと片付けないと怒られるのを思い出したので、
先ほどのホールに寸胴を戻した。
そしてまた厨房に来たが、元栓を閉めないといけないのも思い出したので、隣のビルにまた行って元栓を締めた。
再び戻ってきて、すっかり冷えたカレールーだけがのった皿を給仕役に渡した。

解説：これは「システム設計」がない、という話

「システム」とは、たくさんの部品（道具・材料・人・手順）が連携して、一つの仕事をやり切る全体のことです。料理なら、厨房まるごとが一つのシステムですね。

「設計」は、それを動かし始める前に、何をどこに置き、どの順で動かすかを先に決めておくことです。今回のシェフは、腕が悪いわけではありません。一手ずつは真面目にこなしています。足りないのは、この「先に決めておく」が丸ごとないことです。だから動くほど往復が増え、料理は冷め、お米も間に合いませんでした。

作業の上手い下手より前に、全体の段取り＝設計があるかどうか。ここがソフトウェアの土台で、この先に出てくるヤバさは、全部その上で起きています。気になった方は「システム設計」「アーキテクチャ」あたりから調べてみてください。

2. 役割分担ってなに？　（オブジェクト指向）

次の注文は「ビーフステーキ」
ホールからの注文が厨房に響き渡る。
しかし、30人のシェフは誰も動かない。
「ビーフステーキの担当」が決まっていないから仕方ない。
10分以上誰も微動だにしないシェフ達。
見かねた給仕役が「誰でもいいからステーキ作ってください！！」と叫ぶ。
すると、30人が同時に動き始めた。
一つのフライパンを5人で掴み、誰かが火をつけるまでコンロの前で静止するシェフ。
それとは別のフライパンに牛肉をそのまま載せるシェフ。
その同じフライパンに次々と違うシェフが入れ替わり立ち替わり、牛肉をどんどん積み重ねていく。
フライパンに山盛りになる生肉。
視界の端では塩胡椒のグラインダーを、殴って奪い合っているシェフ。
牛肉には塩胡椒をかけてから焼くので、その戦いが決着するのをひたすら待つ。
同じ理由でステーキソースを持ったシェフ8人もその様子をじっと見ている。
ついに塩胡椒をめぐる戦いは終わり、殴り合い勝者シェフによって山盛り生肉の上に塩胡椒がちょっとだけ振られる。
さあ焼こうと思ったが、今度は火がつかない。
そこで全員が元栓について同時に思い出し、フライパンやステーキソースや皿やなぜか木刀や、とにかくそれぞれの道具を持ったまま、
全員で隣のビルに向かい、全員で元栓を開けて、全員で戻った。
しかし、コンロに火をつける役が中々出てこないので、また全員が静止を始めた。
先ほどの給仕役がスタスタと現れてコンロに火をつけた。
シェフ全員で一つのフライパンを見つめる。
山盛りの生肉は多すぎて中々火が通らないので、シェフの一人がボソッと「ミディアムレア」とだけつぶやいて、
火を消した。
たっぷりの生肉を皿に載せると、ステーキソースをずっと持っていたシェフ8人がその上にソースを8杯かける。
付け合わせの野菜を採りに山に向かったシェフもいたが、2度と戻ってこなかったので、シンプルに肉だけとなった。
こうして、冷え冷え山盛り生ステーキが完成した。

解説：これは「役割分担」がない、という話

大人数でおいしい料理を早く出すために、ふつうの厨房は仕事を「担当」で分けています。肉担当・ソース担当・盛り付け担当……と、それぞれが自分の持ち場と道具を持ち、他人の領域には手を出さない。ステーキが欲しければ「肉担当に頼む」だけで済みます。

プログラムにも同じ考え方があって、これを「オブジェクト指向」と呼びます。要は、機能ごとに担当を決めて、内側には他から勝手に手を出させない、という整理術です。

今回の厨房は、これが丸ごとありません。担当がないから、注文が来ても誰も動かない。かと思えば「誰でもいいから」で全員が同じ一皿に殺到する。道具は奪い合い、ソースは8杯、火をつける人はいない。30人もいるのに、一皿すらまともに出せませんでした。人数や腕ではなく、「誰が何を担当するか」が決まっていないだけでこうなります。気になった方は「オブジェクト指向」「責務の分離」あたりから調べてみてください。

3. レシピって美味しいの？　（仕様書）

シェフ特製サラダの注文が入った。
お客さんが好きな味や食感などをカスタムできる、レストラン自慢の一品だ。
今回の要望は「スパイシーで、食感の変化があって、食べ応えがあって、食事にもなるサラダ」だった。
サラダ担当のシェフ（はいるらしい）が調理を始める。
しかし、このシェフは生まれてから一度もサラダを食べたことがない。
とりあえず、生の野菜を混ぜてドレッシングをかけたものなのは知っているので、まずは自分の好きな野菜を選ぶことにした。
カボチャ、ジャガイモ、さつまいも、里芋、人参…
このシェフは根菜が好きみたいだった。
皮を剥いて乱切りにして、サラダボウルに入れた。
次に、「スパイシー」をなんとかしようと思ったが、スパイシーという言葉の意味がわからなかった。
しかし、他のシェフや、ましてやお客さんに意味を聞くのはシェフとしてのプライドが許さないので絶対にできない。
そこで「スパイシーとは、酸っぱいの方言だ。酸っぱいしーということだ」と自分で推理して、大量の酢酸とクエン酸を用意した。
次に、食感の変化というのはわかりやすいので、サクサクのポテトチップス、ふわふわのマシュマロ、とろけるプリンを加えることにした。
食べ応えについては単に量を増やせばいいし、食事にもしたい要望は白米をサラダの上に載せればいい。
こうして、「ごろごろ生根菜とお菓子の白米添え。2種類の酸ドレッシングの大盛りサラダ」
ができた。

まさかの展開で、このサラダがそのお客さんには大好評で、
また翌日来店し、同じものを注文した。

しかし、今度は別のシェフが担当したので「同じもの」が何かわからない。
仕方ないので、どんなサラダだったかお客さんに聞くと、
「生の根菜に薬品などがかかっていて、美味しくはないが、口が面白かったのでまた食べたい感じ」
と言われた。

このシェフは実はまともだったので（一部いるらしい）
そんなサラダが存在すること。何より「美味しくなくていい」ことに驚愕した。
苦心しながら再現したが、
「茹でた根菜に、香り高いスパイスを効かせたドレッシングをかけ、揚げた肉や穀物で食感の違いを演出した美味しい温サラダ」
をつい作ってしまった。

しかし、そのお客さんは「口が面白いのがサラダ。味なんてどうだっていい」となぜか思っていたみたいで、
一口食べただけで「これは前のサラダと違う！」と怒り狂って出て行った。

そんなことがあってしばらく経ったある日。
そのお客さんはまた来店した。そして今度はあの「美味しい温サラダ」の方を注文した。
まさかの展開に、給仕役が「面白くない方のサラダですけどいいんですか？」と確認して聞いたら、よその店で普通のサラダを食べて「サラダは美味しくていいんだ」と知ったとのことだった。

でも困ったことがある。
美味しいサラダを作れるシェフは、もう辞めてしまっていた。

どうなったのか…
一つだけ確認できているのは、刻んだ消しゴムに胡麻ソースがかかったサラダが、いつまでもお客さんのいないテーブルに置いてあったとかなかったとか…

解説：これは「仕様書」がない、という話

何を作るかを書き出して、お客さんと作り手が同じ認識を共有するための仕組み、それが仕様書です。
今回でいえば「どんなサラダか」を、記した文書のことです。
要はレシピですね。
レシピがないとどうなるか？が今回の話です。
「スパイシー」「食感の変化」のような曖昧な言葉を、作り手が自分の勝手な解釈で埋めていく。ひとこと確かめれば済むのに、聞かずに「酸っぱいの方言だろう」と突き進む。だから、頼んだものと出てくるものが、まるで違う。

しかも仕様書がないせいで、二度と同じものが作れません。たまたま良いものができても、再現はできません。

そしていちばん怖いのはその先です。基準（仕様書）がないと、「何が良いものか」自体がわからなくなる。変なサラダを「これが正解」と刷り込まれ、頼んだ側も、本当はもっと良いものがあると気づけない。決める基準を持たないと、いちばん雑な作り手の手癖が、いつのまにか「正解」になってしまうのです。気になった方は「要件定義」「仕様書」あたりから調べてみてください。

4. 共通化は目的？　（DRYとYAGNI）

鬼畜レストランのメインディッシュのハンバーグ。
作り方は

注文が入ってから肉を挽く
玉ねぎを1人前だけ炒めてから冷ます
調味料とつなぎと肉と玉ねぎを混ぜる
小判形に整形しタネを作る
フライパンに火をつけてタネを焼く
焼けたらハンバーグを皿に盛り付ける
付け合わせの温野菜を調理する
温野菜を皿に盛り付ける

の手順なので、提供まで2時間以上かかるし、
基本的にはハンバーグは冷え冷えで、付け合わせだけ温かい。

しかし、ある一人の天才シェフが気づいた。
「付け合わせは、先にまとめて調理しておけばいい」ことに。
その発想はなかったと大絶賛された。

注文が入ってから肉を挽く
玉ねぎを1人前だけ炒めてから冷ます
調味料とつなぎとさっき作った挽肉と玉ねぎを混ぜる
小判形に整形しタネを作る
フライパンに火をつけてタネを焼く
調理済みの付け合わせの温野菜を電子レンジで温める
皿にハンバーグと同時に温野菜を盛り付ける

これで調理時間は1時間半に短縮された上に、温かいハンバーグが供されることになった。革命だともてはやされ、気をよくしたそのシェフは、次に「玉ねぎはあらかじめ炒めた後に冷やしておく」や「調味料は手の届きやすい調理台の上に置いておく」などの革命的改善を繰り返し

手順は

注文が入ってから肉を挽く
調味料とつなぎと今作った挽肉と炒め玉ねぎを混ぜる
小判形に整形しタネを作る
フライパンに火をつけてタネを焼く
調理済みの付け合わせの温野菜を電子レンジで温める
皿にハンバーグと同時に温野菜を盛り付ける

となり、時間は1時間にまで短縮された

ここまででも鬼畜レストランにしてはすごいが、
そのシェフは更にその上を目指した。

「挽肉を挽く機械があればいい」
そう。実は今までは2本の包丁で肉を叩いて1人前づつ挽肉にしていたが、
肉を挽肉にすることも自動化できれば、大幅に時間が短縮される。

そのシェフは、日夜研究を繰り返し、
ついに挽肉マシンを完成させた。

そのマシンは、1人前の生肉を入れると自動で挽肉にしてくれる優れものだった。
しかも、どんな肉にも対応できるように、センサーで肉の種類を特定し、最適な刃と回転数と自動で選択する機能もつけた。
また、調味料と玉ねぎをセットしておけば、1人前づつハンバーグのタネにもしてくれる機能も搭載した。
その上、せっかくなので、監視用の液晶モニタと、インターネット接続機能と、かき氷も作れる機能など、ありとあらゆる機能を追加した。
あまりにも機能を追加したため、完成まで3年が経っていた。

そのシェフが自信満々で厨房に久しぶりに帰ってきて「万能挽肉マシン」をお披露目した。

しかし、反応が思っていたのと違う。
誰もが気まずそうに目を合わせようとしない。

不安になって、何が起きたかを問いただすと、こう答えられた

「スーパーに挽肉ってのが売ってたよ。挽肉って毎回作らなくてもいいんだって」

最終的な手順

調味料とつなぎと挽肉と炒め玉ねぎを混ぜる
小判形に整形しタネを作る
フライパンに火をつけてタネを焼く
調理済みの付け合わせの温野菜を電子レンジで温める
皿にハンバーグと同時に温野菜を盛り付ける

その挽肉マシンがどうなったのかは誰も知らない。

解説：これは「共通化」が目的になった話

同じ手間を毎回くり返すなら、先にまとめてやっておく——これがプログラムでいう「DRY（Don’t Repeat Yourself＝自分で繰り返すな）」です。付け合わせを先に作る、玉ねぎを先に炒めておく。シェフが最初にやった改善は、まさに正しいDRYで、ちゃんと時短が効いていました。

その流れなら、次の一手は明らかです。タネも先に小判形に仕込んでおく。それで十分でした。

ところがシェフは、そこを飛ばして「どんな肉でも挽ける万能マシン」を作り始めます。「いつか役に立つかも」と、あらゆる場合に備えたから、3年もかかってしまいます。
これが「YAGNI（You Aren’t Gonna Need It＝そんなの必要ない）」です。共通化や自動化は手段のはずが、いつのまにか作ること自体が目的になっている。

いちばん怖いのは最後のオチです。その自動化、そもそも要らない仕事でした。挽肉は売っているのを買えば良かったのです。要らない工程を、3年かけて立派に自動化する——これは現場で本当に起きます。気になった方は「DRY」「YAGNI」「車輪の再発明」あたりから調べてみてください。

5. 味見をするのは素人　（テスト）

鬼畜レストランの名物に「秘伝のコンソメスープ」がある。
初代が命を削って編み出した渾身のスープで、遠く異国からもそのスープを求めてお客さんが来たほどだ。
しかし、当然レシピはないので「なんとなく昨日と見た目が同じになるように」シェフ達が気まぐれで食材を継ぎ足して作っている。
初代の時には透き通った琥珀色の美しかったスープは、今では名状し難い、地獄の淵のような色をして、この世のものならざる香りを発している。
今日はスープが10人前出たので、10人が救急車で運ばれた。
その減った量の分、翌日の仕込みでシェフの一人が食材を追加する。
ドロドロとした漆黒の見た目にするため、イカ墨、海苔の佃煮、墨汁、黒烏龍茶、タールをまず投入する。
次に、ドロドロさを出すために、片栗粉、紙粘土、スライム、腐葉土も混ぜる。
あとは、コンソメスープという名前なので、市販のコンソメキューブを大量に溶かし入れて完成。

これを飲んだら病気になるのは知っているので、当然味見はしない。
何故毒になるものをお客さんはみんな飲むのかは疑問だが、ちゃんと考えたことはない。
でも考える必要はない。初代の味を守るのがこのレストランのシェフの務めだから。
昨日もこのスープを飲んだお客さんが病院送りになったし、今日も明日もきっと病院送りになる。
伝統はしっかりと守られている。

解説：これは「テスト」がない、という話

料理人が、お客さんに出す前に味見をする。それが「テスト」です。
プログラムでは、作ったものが意図どおり動くかを、出す前に機械的に確かめる作業を指します。そしてもう一つ大事な役目が、「昨日と同じ味か」を毎回試すことです。プログラムはどこか一か所をいじると、関係なさそうな別の場所が巻き添えで壊れることがあります。その確認をするのがテストです。

ところがこの厨房には、レシピ（＝正しい味を書いたもの。前に出てきた「仕様書」です）がありません。正しい味が決まっていないと、味見しようにも「何と比べればいいか」がわからない。だから基準は「昨日の鍋」だけになります。誰も正解を持っていないので、毎日ほんの少しずつズレても気づけない。琥珀色が何年もかけて地獄の色になるのは、こうして起きます。一日ぶんのズレは小さいから、止める人がいないのです。

しかも人間は、見たら困るものを見ないようにしてしまう。味見をすれば「これは出しちゃいけない」とわかる。でもわかったら向き合わないといけない。だから確かめない。「味見なんて素人がやることだ」と自分に言い聞かせるのです。
確かめる仕組みがない厨房では、そのズレは止まりません。

ここでいちばん怖いのは、もう元の味に戻せないことです。正しい味の記録（仕様書）も、確かめる習慣（テスト）もないまま継ぎ足した結果、最初がどんな味だったかを誰も知らない。直したくても、目指す先がありません。
気になった方は「テスト」「リグレッション（回帰）」「テスト駆動開発」あたりから調べてみてください。

6. 手段だって目的だろ！　（リファクタリング）

鬼畜レストラン人気メニューのオムライス。
どうしても手数が多く、技術の差も出やすい料理。
特に卵を割るのが大変なことに悩んでいるあるシェフが、
「全自動卵割り混ぜ機」があればいいのに。と思いついてしまい、以前万能挽肉マシンを作った元シェフ（今は発明家になっている）に相談をしに行った。

数日後「全自動卵割り混ぜ機」はあっさり完成した。
早速使ってみる。
すると、確かに高速で自動的に割れはするが、豪快に殻ごと入ってしまっていたらしい。
ジャリジャリのオムライスは、食べられずにそのまま返ってきた。

発明家の元へまた相談に行くと、「殻を取るなんて仕様は聞いてない」と怒られてしまった。
でも「そこをなんとか」と懇願して対策をしてもらった。

数日後「全自動卵の殻取り機」が完成した。
殻ごとの卵液をその機械に通すと、殻を取ってくれる。
早速使ってみると、確かに殻はキレイにとれたが、
殻をとるアームから機械油が垂れる仕組みらしく、卵液が七色の油膜に覆われてしまった。
ヌメヌメのオムライスは、食べられずにそのまま返ってきた。

発明家の元へまたまた相談に行くと、「油を出さないなんて仕様は聞いてない」と怒られてしまった。
でも「そこをなんとか」と懇願して対策をしてもらった。

数日後「全自動油取り機」が完成した。
油の入った卵液をその機械に通すと、油を取ってくれる。
早速使ってみると、確かに油はとれたが、異常に発熱するらしく卵液がすべて蒸発してしまった。
卵なしのオムライスは、食べられずにそのまま返ってきた。

発明家の元へまたまたまた相談に行くと、「卵液の温度は指定されてない」と怒られてしまった。
でも「そこをなんとか」と懇願して対策をしてもらった。

数日後「卵液冷却装置」が完成した。
その機械があれば、卵液は蒸発しない温度に保たれるらしい。
早速使ってみると、完璧な状態の卵液がちゃんとできたし、オムライスも正しく完成した。
ただ、冷却装置の起動に毎回1時間かかるのだけが弱点だ。
また、仕様上1個分しか卵液を冷却できないので、1人前に卵を3個使うオムライスの完成までには3時間かかった。

お客さんは、オムライスを食べられずにそのまま帰ってしまった。

その後、巨大な全自動卵割り機械群は厨房の大半を占拠しているが、
手で卵を割って混ぜたほうが早いので、誰も使っていない。

解説：これは「リファクタリング」のはずだった話

「リファクタリング」とは、出てくる味は変えずに、作り方だけを良くすることです。お客さんに出る料理が前と同じなら成功、味が変わってしまったら、それはもうリファクタリングではありません。本来は地味で慎重な作業です。

今回の正解も、ごく地味でした。注文ごとに卵と格闘するのをやめ、あらかじめ卵を溶いて仕込んでおく。それだけで、オムライスの味はそのままに、作り方だけが楽になります。機械も、発明もいりません。

ところがシェフは、その地味な正解を飛ばしました。卵を楽に割りたい一心でいじるたび、出てくるものが変わり、問題が次の問題を呼ぶ——殻、油、そして蒸発。どれも「前と同じオムライス」から遠ざかる改悪です。ダメなら「手で割る」に戻せば一瞬で済んだのに、戻さず次の機械を足し続けた。気づけば、楽をするための機械が厨房を占拠し、肝心のオムライスは出てこない。手段が、目的になってしまったのです。

怖いのは、一つ一つの改造が、その場では「解決」に見えることです。だから止まれない。でも全体としては、誰も頼んでいない方向へ進み、お客さんに届く価値は増えるどころか減っている。いちばん難しいのは、引き返すことなのです。気になった方は「リファクタリング」「サンクコスト（やめどきの難しさ）」あたりから調べてみてください。

7. 汎用性のためなら実用性を捨てる　（抽象化）

またあるシェフが閃いてしまった。
「すべての料理には塩が入っているのに、人間は不正確にしか塩を振れない」
ならば、塩を入れることを便利で正確にする共通の仕組みがあれば、料理全部が楽になるし美味しくもなる。
それは是非とも何よりも優先してやるべきだ。
その天才的な気付きにシェフは突き動かされてしまった。

数ヶ月後。厨房はそのシェフにより「塩を振る機能のために」徹底的に改造された。

ある日、改造済みの厨房にジンジャーポークの注文が入る。
最初の工程は、豚肉に塩を振ること。

担当のシェフは、まず隣の「塩振り受付室」に豚肉を1枚持っていく。
そこでは、3人の検査官により「本当にそれが塩をかけていいものか？」を判断される。
3人は、それぞれ違う計測機器を使って調べているが、その検査法の詳細は誰にもわからない。数十分後「塩振り許可」の判定が出て、次は塩分判定室にいくように言われる。
そこでは「適切な塩分量はどの程度か？」を判定する専門家がいるので、その専門家に豚肉を見せる。
定規を当てたり、測りで重さを測ったり、顕微鏡で見たりする。
一通り計測が終わると、今度はパソコンに色々入力を始める。
しばらく唸った後に「3グラム」と呟いた。
「塩化ナトリウム3グラム。ご自身でこの用紙に書いてください」
なぜか、その専門家は書類を直接は書いてくれないらしい。
「3グラム」と書いた書類とぬるくなってきた豚肉を持って、また次の部屋の「砂糖検査室」に向かう。

この部屋では、また別の専門家が「塩と砂糖の認識を間違っていないか」を、100個の質問でシェフに聞いて確認してくる。数十分後ようやく「塩認識問題なし」の判定が下る。
ほっと胸を撫で下ろし、すぐ隣の「塩振り最終窓口」に豚肉を出したら、係員の顔色が変わった。
部屋のランプを点滅させてブザーを鳴らし、拡声器で「エラーです。エラーです。牛肉置き場に間違った肉がセットされました。肉の種類をよく確認してください」というアナウンスを響き渡らせた。
慌てて豚肉を回収し、どうすればいいかを「塩振り案内係」に質問すると、「豚肉の受付は地下だからそこに行ってください」とだけ言われた。
どうやら、豚肉は別の場所に行かなければいけないらしい。
エレベーターで地下10階まで降りていくと、そこには「豚肉専用塩振りはこちらで受付」と書いてある窓口があり、係員が豚肉を受け取ると、書類にハンコを一つ押して「受付しました」とだけ言った。
が、しばらくしても何も起きない。
おかしいなと思って、また案内係に聞くと「はい。その手順で正しく受付は完了できていますので、一つ上の階に行ってください」とだけ言われた。
どうやら、地下の窓口は「受付をするだけ」だったらしい。
一つ上の階に行くと、「豚肉専用塩振り受付確認窓口」があった。
ここは、書類の不備を確認するだけの部屋のようで、また数十分待たされた。
「書類に不備なし」という追加書類を渡されて、また一つ上の階に行かされる。
そこは「豚肉専用塩振り確認書類確認窓口」で、その追加書類をさらに確認する窓口だった。
結局これを階数分繰り返しながら地上に向かって戻ると、いつしか「塩振り最終窓口」に辿り着いた。エレベーターに乗る前にいたのと同じ部屋だ。
豚肉と大量の書類を提出すると、今度は係員が無言で受け取り、奥へ引っ込んだ。
しばらく待つと、その係員が塩入れを持って戻ってきて、豚肉の上にさささと3回塩を振った。
無事に塩振りが終わったようだ。
シェフはそのまま「胡椒振り受付室」に向かった。

ポークジンジャーが完成するのがいつになるのかは、そのシェフにはわからなかった。

解説：これは「抽象化」をやりすぎた話

似たものを一つにまとめて、どんな場合にも通じる「共通のやり方」を作る——これを「抽象化（汎用化）」といいます。うまく使えば強力で、塩振りのコツを一か所にまとめれば、全料理の塩加減が一度に良くなる。考え方そのものは、正しいのです。

ただしこのシェフは、「あらゆる場合に備えた、唯一正しい塩振りの仕組み」を目指してしまいました。牛肉かもしれない、砂糖と間違うかもしれない、塩分量が違うかもしれない……。考えうる全部に備えて、受付・判定・検査・地下の受付……と、間に挟まる部屋（層）をどんどん積み上げる。一つ一つの部屋は真面目で、それらしく「正しく」できています。でも全部つなぐと、塩を一振りするだけのことに、厨房を何周もする大移動が要る。

プログラムでいう「3行で済むことが、10個のファイルをまたいで処理される」状態です。塩を振る一行を探すのに、延々と歩き回るはめになります。

これのいちばん怖いのは、全部が「ちゃんとしている」ことです。どの部屋も正しく、丁寧で、もっともらしい。だから誰も「これ、要りますか？」と言い出せない。
でも目指したはずの効率は明らかに落ちている。という矛盾が起きます。
気になった方は「抽象化」「過剰な設計（オーバーエンジニアリング）」あたりから調べてみてください。

鬼畜レストランはどこにでもある

どうでしたか？
「そんなレストランあるか！」と思ったでしょうか？
でも、システム開発をしている人間から見れば、どのエピソードもそんなに珍しいものでもないです。
「そういうシステムとかエンジニアいるよね」みたいな話だったりもします。
だからこそ、冒頭で言った通り「ヤバい」のです。
実際にこんなレストランがあったら、もちろん潰れるに決まってます。
でも、開発現場ではまかり通ってしまう。
そこに現場との温度の差があるのです。
とにかく大事なのは、この鬼畜レストランは案外身近であること。
それだけは知っておいて欲しいです。
あなたの担当するエンジニアが何か言っていたら、それはこの厨房のことかもしれないので。