ある日の飲食店で

先日、友人と二人で飲食店に行きました。最近よくあるタッチパネル注文のお店です。

私たちは各々、食べたいものをタッチパネルで注文しました。私はAのご飯、Bのおかず、Cのサイドメニュー。友人はDのご飯、Eのおかず、同じくCのサイドメニュー。

しばらくして、料理が運ばれてきました。しかし、膳に入れられた料理がてんでバラバラだったのです。

私のところにはAとBだけ。友人のところにはD、E、そしてCが二つ。私のCはどこに行ったのか。友人の膳にまとめられていました。

なぜこうなったか

注文した時点では、私と友人は別々のコンテキストで操作しています。「私はA+B+C」「友人はD+E+C」という明確な対応関係がある。

しかし、この注文がキッチンに届いた時点でコンテキストが消失しています。キッチンが受け取るのは「テーブルXからA、B、C、C、D、Eの注文」という情報だけ。誰が何を頼んだかは伝わらない。

配膳する店員は、料理と人のマッピングを推測するしかありません。Cが二つあるなら、まとめて片方に置く方が合理的に見える。でもそれは間違いです。

コロナ禍以前、人が注文を聞いていた時代を思い出してください。

「こちらのお客様がA定食、そちらのお客様がB定食」。店員は注文を聞く時点で、誰がどれを頼んだかを暗黙的に把握していました。キッチンに伝える時も「Aは手前のお客様、Bは奥のお客様」と伝えられた。

A定食・B定食のようなシンプルな注文なら、タッチパネルでもミスは起きません。品数が少なければ、配膳時に推測しても正解率は高い。

しかし、メニューの多様化が進み、注文の組み合わせが複雑になりました。サイドメニューを追加したり、単品を組み合わせたり。そうなると、配膳する側の確認作業が追いつかなくなり、結果的にサービスの質が落ちてしまう。

タッチパネルは注文を受ける側のコストを劇的に下げました。人件費の削減、注文ミスの防止、人との接触を減らすコロナ対策。入口としては大成功です。

しかし配膳する側の判断コストは考慮されていなかった。むしろ、人が注文を聞いていた時代には自然に保持されていたコンテキスト（誰がどれを頼んだか）が、タッチパネルによって失われてしまった。

入口を最適化した結果、出口のプロセスが破綻する。 部分最適が全体のサービス品質を下げてしまう構造です。

ここからは私の本業の話です。ソフトウェア開発の現場で、同じ構造の問題を目にします。

AIコーディングツールの導入によって、コードを書く速度は劇的に上がりました。これはタッチパネルで注文が簡単になったのと同じです。入口の最適化です。

しかし、書かれたコードをレビューし、承認し、統合するプロセスはどうでしょうか。

構造を並べてみると、対応関係が見えてきます。

タッチパネルの配膳ミスと同じです。入口（コード生成）を最適化しても、出口（レビュー・承認・統合）のプロセスが従来のままなら、全体のスループットは上がらない。 むしろ、品質が下がるリスクすらある。

飲食店の話に戻ると、解決策はいくつか考えられます。

AI駆動開発でも同じです。

入口を最適化するなら、出口も一緒に再設計する。当たり前のことですが、便利なツールを導入する興奮の中で、忘れがちなことでもあります。

飲食店のタッチパネルも、AI駆動開発も、「便利になった」のは間違いありません。ただ、便利になった部分だけを見て、全体のプロセスを見直さないと、思わぬところでサービスの質が落ちる。

入口の最適化は出口の最適化とセットで初めて意味がある。次にタッチパネルで注文するとき、ちょっとだけこの話を思い出してもらえたら嬉しいです。