こんにちは！先日、我が家に「ハチワレだらけくじ」の戦利品が届きました。
↑ 大きさ比較のために2つ並べています。後ろがA賞の特大ぬいぐるみ、手前が「豆大福」の前掛けを付けたマスコット。余談ですが、私はちいかわくじの運がかなり良い方で、良い賞をよく引き当てます。
この手前の小さい子、よく見ると「豆大福」の前掛けを付けて、少し困った顔をしています。そう、あの回のハチワレです。
ざっくりおさらいすると、こんな話です（詳細はちいかわ公式Xや単行本でどうぞ）。
- 「出し物を用意して集まる会」が開かれることになる
- ハチワレ、これを「出汁」のことだと思い込み、出汁パックを用意して当日に臨む
- 会場で、自分の出番の直前に解釈が違っていたことに気づく（なお、うさぎも事前に取った出汁を持参していた）
かわいい。かわいそかわいい。でも IT の仕事をしている人間は、この3コマ目で笑えません。これ、私たちの業界で「受け入れテストで炎上する」と呼ばれている現象と、完全に同じ構造なんです。
今日はこの回を題材に、システム開発がなぜ揉めるのか、どう防ぐのかを、IT に詳しくない方にも伝わるように書いてみます。
1. 起きたのは「要求」と「理解」のズレ
システム開発には要求と要件ということばがあります。
- 要求: 発注する側の「こういうものが欲しい」（頭の中にある）
- 要件: それを受け取った作る側が「つまり、こう作ればいいのですね」と解釈してまとめたもの
トラブルの大半は、この「要求 → 伝達 → 解釈」という翻訳の連鎖のどこかで起きます。豆大福の会に当てはめると、
| 豆大福の会 | システム開発 | |
|---|---|---|
| 主催する側の頭の中（要求） | 出し物を持ち寄ってほしい | 顧客が本当に欲しいもの |
| 伝わったことば | 「だしもの」 | 発注書・提案依頼書 |
| ハチワレの解釈（要件） | 出汁を用意して集まる | 開発チームが「作るもの」として定めた要件 |
本来はこの解釈を文書にして、発注側と突き合わせて合意します。この工程が要件定義です。ハチワレは（無理もないのですが）この突き合わせを省いて、解釈したまま走り出してしまいました。
原作では、ハチワレがこの会のことをどうやって知ったのか──案内文を読んだのか、誰かから聞いたのか──までは描かれていません。でも確かなのは、ハチワレはサボったわけでも、いい加減に聞いていたわけでもないということです。「だしもの」ということばを受け取って、違う意味で解釈した。それだけです。
日本語は同音異義語だらけで、文脈で意味が変わります。そしてシステムの仕様書も、プログラミング言語ではなくこの曖昧な自然言語で書かれます。「ことばは伝わったのに、意味は伝わっていない」は、誰も悪くなくても起きるのです。
2. なぜ当日まで気づけなかったのか
この回の本当に恐ろしいところは、ハチワレが間違いに気づいたのが、当日どころか自分の出番の直前だったことです。それまで一度も、気づくチャンスがなかった。
理由は単純で、ハチワレの頭の中では、すべての辻褄が合っていたから。「出汁の会」という解釈のもとでは、出汁パックを選んで用意する行為は100%正しい。準備の途中で何度見直しても、間違いは見つかりません。間違っていたのは作業ではなく、前提だからです。
IT の世界では、開発の最後にUAT（User Acceptance Test：受け入れテスト）という工程があります。発注した側が「頼んだものになっているか」を実際に確かめる、いわば当日の会場です。
そして、開発現場で恐れられている法則がこれです。
作り方の間違いはテストで見つかる。作るものの間違いは、受け入れテストまで見つからない。
開発チームが行うテストは「自分たちの理解した要件どおりに動くか」を確かめるもの。理解そのものがズレていたら、テストは全部合格します。ハチワレの用意した出汁パックに、何ひとつ不備がないのと同じです。そして UAT で顧客が実物を見た瞬間、「頼んだものと違う」が発覚する。数ヶ月の作業が根本からやり直しになり、納期も予算も吹き飛ぶ──これが「UAT炎上」です。
発覚が遅いほど手戻りは大きくなります。出番の直前では、もう出し物は用意し直せないのです。
3. 防ぎ方は「一往復の確認」
では、どうすれば防げたのか。実は、たった一言で防げました。
「確認ですけど、"だしもの"って、お吸い物とかの出汁……で合ってますか？」
冗談みたいですが、IT の現場で行われている対策は、本質的にこれの積み重ねです。
- 復唱と議事録: 聞いたことを自分のことばで言い直して、相手に確認してもらう。「つまり出汁ですね？」「違います」で5秒で発覚します
- プロトタイプ: 完成品を作る前に、簡単な試作品や画面のスケッチを見せる。「例えばこういうことですか？」と現物で認識を合わせる。「これを持って行こうと思うんだけど」と出汁パックを見せた時点で気づけたはずです
- こまめな中間確認: 完成まで黙って作り込まず、作りかけでも動く現物を短い間隔で見せて確認してもらう（アジャイル開発と呼ばれる進め方の核心はこれです）。準備の途中で一度でも中身を見せ合う機会があれば、その場で気づけました
- 用語集: プロジェクト内で紛らわしいことばの定義を明文化しておく。「この会での『だしもの』は演芸・出し物を指します」と最初にひとこと明文化しておく
そしてもうひとつ大事なことがあります。「だしもの」ということばを発した主催側にも、曖昧さの責任の一端があるということです。読み手の誤解を「読み間違えた方が悪い」で済ませるチームは、同じ事故を何度でも起こします。誰が悪いかではなく、どこで気づける仕組みが欠けていたかを考える──この考え方はコンテナと隔離のコラムで紹介したポストモーテムの心臓部です。ハチワレは、悪くない。
そもそもこの手のズレは、相手の中で何が起きているかが見えないから起こります。中身を隠してシンプルな見た目だけを見せる設計を、ITでは抽象化と呼びます。便利さと引き換えに認識のズレを生みやすいのです。
4. AI に仕事を頼む時代、これは他人事ではない
最後に現代の話を。いま IT 業界では、LLM（ChatGPT や Claude のような、ことばを扱う AI）や AI エージェント（AI に道具を持たせて仕事を任せる仕組み）に作業を頼むことが当たり前になりつつあります。
ここで思い出してほしいのが、ハチワレの一番怖かった性質です。誤解したまま、完璧に作業を遂行してしまう。
AI も同じです。曖昧な指示を受け取ると、AI は自分なりの解釈で辻褄を合わせ、自信満々に出汁パックを用意してきます。しかも仕上がりは丁寧なので、一見すると正しく見える。指示のことば（プロンプト）は、あなたが AI に発する「だしもの」ということばそのもの。あなたは豆大福の会の主催者側なのです。
だから、AI 時代に価値が上がっているスキルは、実は昔から変わりません。要求を曖昧さなく伝えること。そして、完成を待たずに途中で確認すること。 豆大福の会が教えてくれるのは、最新の AI 活用術でもあったわけです。
まとめ
- 「出し物」と「出汁」のズレ = 要求と要件のズレ。ことばが伝わっても意味が伝わるとは限らない
- 誤解した本人の中では辻褄が合ってしまうので、実物を突き合わせる瞬間（UAT）まで発覚しない
- 防ぐのは高度な技術ではなく、復唱・試作・中間確認という「一往復」。そして曖昧なことばを発した側の見直し
- AI への指示も同じ。誤解したまま完璧に遂行するのはハチワレだけではない
それにしても、間違いに気づいた瞬間のハチワレの顔をぬいぐるみにした公式の慧眼よ……。私の机の上では今日も、豆大福の前掛けを付けたハチワレが「要件定義、ちゃんとやろうな」と語りかけてきます。
(※本記事は漫画『ちいかわ』の一エピソードへの感想・考察です。原作画像の掲載は控えていますので、ぜひ公式Xや単行本でお楽しみください。)