PoC疲れとは｜原因5つと抜け出す5ステップ

エンジニアとして関わった、ある現場の話から始めましょう。形を変えて何度も見てきた、おなじみの光景です。

デモは大成功、なのに本番にならない

新しいアイデアを試すために、2か月でPoC（概念実証）を作ったことがありました。短期決戦で、とにかく「動いて見えること」を目指して、突貫で組み上げた。結果、デモは大成功でした。会議室で動かしてみせると、関係者から「おお」と声が上がって、その場の空気が一気に明るくなる。経営層も乗り気になって、こう言いました。「素晴らしい。じゃあ、これを本番化しよう」。

うれしい言葉のはずでした。でも、筆者の心の中には、ひとつ、重たい予感がありました。そして、その予感は後に的中するのです。

本番化に向けた見積もりを出す頃になって、「このPoCのコードは、ほとんど捨てて、ゼロから作り直しになります」。

経営層は、きょとんとしていました。「えっ、さっき動いてたじゃないか。なんで作り直すの?」。

このやりとり、エンジニアなら、たぶん誰もが一度は経験しています。そして、たいてい、うまく説明できずに、もどかしい思いをする。「動いて見える」と「使い続けられる」のあいだに、どれだけ深い谷が横たわっているか。それは、作っている本人にはくっきり見えているのに、見ている人には、なかなか伝わらない。同じものを見ているのに、立っている場所で、景色がまるで違うんです。

この、見ている人と作っている人のあいだに走る深い断絶。今日は、「成功したPoCが、なぜか本番にならない」という、あの不思議な現象の正体を、ほどいていきます。（そんな現場レポーターたる筆者の来歴は、自己紹介に。）

あの「作り直します」の正体 ― PoC疲れとは・原因5つ・抜け出す5ステップ

物語の続きに入る前に、ひとつ種明かしをしておきます。あの「成功したのに前に進まない」現象には、業界でちゃんと名前がついています。言葉と全体像をそろえておくと、このあとの話が、ぐっと自分ごとになるはずです。

PoC疲れとは｜PoC止まり・PoC死との違い

PoC疲れとは、PoC（Proof of Concept＝概念実証）を何度も実施しているのに、そのどれもが本番稼働に至らず、現場と経営の双方が消耗していく状態を指します。似た言葉に「PoC止まり」「PoC死」「PoC倒れ」がありますが、指しているものは少しずつ違います。

言葉	指しているもの
PoC（概念実証）	作る前に「それが成立するか」を小さく確かめる実証実験
PoC止まり	個々のPoCが、本番化されないまま終わっている状態
PoC死／PoC倒れ	本番化を前提に始めたPoCが、移行の段階で頓挫すること
PoC疲れ	PoC止まりが組織で繰り返され、期待も予算も枯れていく状態

つまりPoC疲れは、1回の失敗につく名前ではありません。同じ止まり方を何度も繰り返した組織に、少しずつ溜まっていく疲労の名前です。だから、個別のプロジェクトを反省しても直りません。止まり方そのものを変える必要があります。

なぜPoC疲れが起きるのか（背景）

生成AIやAIエージェントのように、やってみるまで性能が読めない技術では、「まず小さく試す」という判断そのものは正しく、PoCの件数は増える一方です。問題は、増えたのがPoCの件数だけで、本番に渡すための設計と合意が、同じだけ増えていないことにあります。技術が難しくて止まるより、始め方のせいで止まっているケースのほうが、現場では圧倒的に多いのです。

PoC疲れが起きやすい位置｜プロトタイプ・PoC・MVPの関係

段階	確かめたい問い	作るもの	出口
プロトタイプ	この体験でいいか	見た目と操作の試作	設計の合意
PoC	技術的に成立するか	検証用の実装	成立可否の判断
MVP	価値があるか（使われるか）	最小限の「本物」	継続・撤退の判断
本番開発	毎日、安全に回るか	運用に耐える実装	稼働

PoC疲れは、この表のPoCとMVPのあいだで起きます。PoCの出口は「成立可否の判断」であって「動くシステム」ではない――ここが共有されていないと、検証のために雑に組んだ実装が、そのまま本番の土台として扱われはじめます。段階ごとの詳しい進め方は、PoCの進め方5ステップとMVP開発とはで扱っています。

PoCが本番化しない5つの原因

原因	何が起きるか
1. 設計の目的が違う	「動いて見える」ための作りは、「使い続けられる」要求に耐えない
2.「あとは作るだけ」の誤解	本番化に必要な予算と期間が、最初から計上されない
3. 前提が決まっていない	捨てる前提か育てる前提かを決めずに走り、途中で入れ替わる
4. 合否の基準がない	デモの盛り上がりが評価になり、移行できるかが測られない
5. 出口が定義されていない	「何が確かめられたら本番へ進むか」が最初に決まっていない

デモは大成功→「あとは作るだけ」→予算も期間も足りない→本番化せず終了、そしてまた次のPoCへ、と時計回りに循環する4つの箱で、PoC疲れが同じ止まり方の繰り返しであることを示した図 — 止まっているのは技術ではなく、始める前のひとこと

原因1｜「動いて見える」設計と「使い続けられる」設計は別物

PoCは、限られた期間で可能性を示すために、意図的に多くを飛ばして作ります。整えたサンプルデータ、想定どおりの操作、一人だけの利用、後回しのセキュリティ。一方、本番に求められるのは、バラバラな実データ、想定外の操作、同時利用、24時間の稼働と情報保護です。PoCが「考えなくていい」と決めた項目のほとんどが、そのまま本番の要求事項になります。だからコードが流用できないのは、手抜きの結果ではなく、目的が違ったことの当然の帰結です。

原因2｜「あとは作るだけ」で、予算と期間が先に削られる

デモの印象が強いほど、「もう9割できている」という体感が生まれます。すると本番化は残作業として扱われ、必要な予算と期間が計上されません。実際には、この“あと”こそが工数の大半を占めます。見積もりの前提を早い段階でそろえておく話は、要件定義書の書き方やベンダー選定の進め方とも地続きです。

原因3｜「捨てる前提」か「育てる前提」かを決めずに走り出す

PoCには、検証したら捨てる使い捨て型と、本番の芯として育てる型の2種類があります。どちらも正しいのですが、決めずに始めて、途中で入れ替わるのが最悪です。捨てる前提で雑に組んだ基礎の上に、本番という重い建物を積み上げることになるからです。

原因4｜合否の基準が、デモの盛り上がりになっている

「関係者の反応が良かった」はPoCの合格基準になりません。評価すべきは、精度や見栄えではなく、運用できるか・保守できるか・コストが見合うか・安全に保てるか、です。基準を決めずに走ると、判断は会議室の空気に委ねられます。

原因5｜出口（本番へ進む条件）が最初に決まっていない

「何が確かめられたら本番に進み、何が確かめられなかったら止めるのか」。この2つを開始前に文章にしていないPoCは、終わり方を持ちません。終われないPoCは、成果ではなく宙ぶらりんの資産だけを残し、次のPoCの予算を静かに削っていきます。

PoC疲れから抜け出す5ステップ

ステップ	やること	つまずきどころ
1	捨てる／育てるを、始める前に宣言する	曖昧なまま始めると、途中で前提がすり替わる
2	検証項目に「本番への移行可能性」を入れる	技術の可否だけを見ると、運用・保守・コストが漏れる
3	育てる前提なら、細い一本を「本物」で通す	見栄えを優先すると、張りぼてに戻る
4	合否は「本番に一歩近づいたか」で出す	デモの盛り上がりを成果と取り違える
5	捨てるものは、期限を切って潔く捨てる	「もったいない」が技術的負債の入口になる

ステップ1｜始める前に「捨てる／育てる」を宣言する

PoCの企画書に一行、「このPoCのコードは検証後に破棄する」または「このPoCは本番の初期実装として育てる」と書きます。たったこれだけで、作り方も、見積もりも、期待値も変わります。PoC疲れの大半は、この一行が無いことから始まります。

ステップ2｜検証項目に「本番への移行可能性」を入れる

確かめるのは「技術的に動くか」だけではありません。実データに耐えるか、運用担当が保守できるか、想定利用量でコストが見合うか、権限とログをどう設計するか。ここに開始時点で当たりをつけておくと、「動いたのに本番にならない」というがっかりを、かなりの確率で避けられます。

ステップ3｜育てる前提なら、“歩く骸骨”を一本通す

育てる前提を選んだなら、機能を大胆に絞ったうえで、データの入口から出口まで、本番と同じ道を一本だけ通します。エンジニアの世界で「歩く骸骨（ウォーキング・スケルトン）」と呼ばれる作り方です。派手なデモにはなりませんが、あとから肉をつけられます。MVP検証の進め方とも相性のいい考え方です。

ステップ4｜合否は「本番に一歩近づいたか」で出す

PoCの成果報告は、デモの再演ではなく、判断材料の提示にします。何が確かめられ、何が未確認で、本番化にはあと何が必要か。この3点が言えるPoCは、たとえ結論が「進まない」でも成功です。逆に、盛り上がったのに次の一歩が言えないPoCは、うまくいっていません。

ステップ5｜捨てるものは、期限を切って潔く捨てる

捨てる前提のPoCには、破棄の期限を決めておきます。「動くものが手元にある」という状態は、想像以上に強い引力を持っていて、放っておくと誰かが本番の土台に流用します。捨てる勇気ではなく、捨てる仕組み（期限）のほうが効きます。

PoC疲れを繰り返さないためのポイント

5ステップの肝は順番です。ステップ1（前提の宣言）を飛ばして、ステップ2以降の検証設計だけを整えても、途中で前提がすり替わればすべて崩れます。始める前の一行を、いちばん先に。なお、PoCを重ねるうちに機能だけが増えていく現象については、AI機能を“足す”ほどプロダクトは使われなくなるでも書いています。

「動いて見える」と「使い続けられる」のあいだ

なぜ、成功したPoCを捨てて作り直すことになるのか。

理由はシンプルで、そのPoCは「動いて見える」ために作られ、本番は「使い続けられる」ために作られるから。求められているものが、最初からまったく違うんです。

2か月で動くデモを作るとき、エンジニアは、たくさんの近道を選びます。データは、きれいに整えた都合のいいサンプルを使う。エラーが起きるケースは、とりあえず考えない。同時に大勢が使ったら、なんて想定もしない。セキュリティの作り込みも後回し。誰か一人が、決まった手順で触れば、ちゃんと動く。それで「可能性は証明できた」ことになるからです。

でも、本番はそうはいきません。現実のぐちゃぐちゃなデータが流れ込んでくる。想定外の操作をする人がいる。何百人が同時に使う。一度でも情報が漏れたら大問題になる。24時間動き続けて、壊れたら直せないといけない。PoCが「考えなくていい」とした、その全部に、本番は向き合う必要がある。

だから、見栄えのいいデモを支えていた突貫の作りは、本番の要求の前で、ほとんど役に立たない。いちばん皮肉なのは、デモを華々しく見せることに最適化したPoCほど、中身は張りぼてで、本番から遠いことすらあるということです。動いて見えることは、使い続けられることの、保証にはまったくならないんです。

具体的に、何を作り直すのか。少しだけ挙げてみます。そのPoCでは「社内で整えた、都合のいいテストデータ」だけで動かしていたものを、本番では「数多ある取引先から届く、表記もフォーマットもバラバラな本物のデータ」に耐えられるよう作り直す。PoCでは「一人が、決まった手順でゆっくり操作する」前提だったものを、本番では「繁忙期に何百人が一斉に叩いても落ちない」ように組み直す。PoCでは見て見ぬふりをしていた「途中でエラーが出たらどうするか」「このデータは誰が見ていいのか」を、一つひとつ設計する。

こうして並べると、見えてくることがあります。PoCで作ったのは、いわば「家の完成予想図のCG」だった。本番化とは、そのCGを眺めながら、ゼロから「実際に人が住める家」を建てる工事さながらだったんです。CGがどれだけ美しくても、その絵の中に住むことはできません。

PoCが飛ばした4つのこと（都合のいいサンプル・エラーを考えない・使うのは一人・セキュリティ後回し）それぞれに、本番で向き合う要求（バラバラな本物データ・障害復旧・何百人の同時利用・24時間の情報保護）が対応することを示した図 — この右側ぜんぶが、「あとは作るだけ」の“あと”の中身

「あとは作るだけ」という、いちばん危ない誤解

ここで生まれるのが、「PoC成功＝技術的に可能＝あとは作るだけ」という誤解です。

この「あとは作るだけ」、筆者がいちばん警戒している言葉のひとつです。別の記事でも書きましたが、AIエージェントでも何でも、この“あと”が、実はいちばん難しい。今回のPoCで確かめられたのは、せいぜい「技術的に、動かせなくはない」という一点だけ。本番に必要な「毎日、安全に、大勢が、安定して使えるか」は、まだ何ひとつ確かめられていないし、他の技術的制約もまだ固まっているわけではないのです。

なのに、デモのインパクトが強いと、人はつい「9割できた」と感じてしまう。実際には、本番化という登山の、登山口に立っただけかもしれないのに。残りの「1割」に見えていた部分こそが、本当の山だった、という話は、本当によくあります。

デモを見た人の体感では9割できたことになっているが、実際にはPoC成功は登山口に過ぎず、本物のデータ対応・エラー処理・セキュリティ・負荷対策という山を登った先に本番があることを示した図 — 「残りの1割」に見えていた部分こそが、本当の山

そして、この誤解が厄介なのは、お金と期待の流れを狂わせることです。「あとは作るだけ」だと思っているから、本番化に十分な予算も時間も確保されない。「さっき動いてたんだから、すぐでしょ」と。結果、現場は突貫のPoCを無理やり本番に引き伸ばそうとして、技術的負債まみれの、いつ倒れるかわからないシステムが出来上がる。最初の華々しいデモが、後々まで尾を引く呪いになるんです。

筆者が見てきた中で、いちばん切なかったのは、優秀なエンジニアたちが、無理な納期と足りない予算の中で、捨てるべきだった突貫のPoCを本番に引き伸ばすことを強いられ、技術的負債で少しずつ身動きが取れなくなっていくケースです。彼らは、手を抜いたわけじゃない。むしろ逆で、最初のデモを、成功させすぎた。その鮮烈な成功体験が「これはすぐできる」という期待を生み、その期待が、本来必要だったはずの時間と予算を、根こそぎ奪っていった。なんとも皮肉な話です。もしあの日のデモが、もう少し地味だったら、誰も「あとは作るだけ」なんて、軽々しく言わなかったかもしれないのに。

捨てる前提か、育てる前提か。最初に決める

では、どうすればいいのか。要点は、PoCを始める前に、「これは捨てる前提か、育てる前提か」をはっきり決めておくことです。

捨てる前提（もしくは、捨てることを許容できる）なら、それはそれで、まったく問題ありません。「この技術が成立するかだけ、最速で確かめたい。コードは検証後に捨てる」と全員が合意していれば、突貫で作って、学びだけ抜き取って、潔く捨てればいい。これは健全なPoCの使い方です。大事なのは、捨てる前提のものを、間違っても「本番の土台」として扱わないこと。プロトタイプは、あくまでプロトタイプです。

ここを混同すると、悲劇が起きます。検証のために素早く作った使い捨てを見て、誰かが「これ、もう動いてるんだから、本番の土台にしちゃおうよ」と言い出す。そして、捨てる前提で雑に組んだ基礎の上に、本番という重い建物を、どんどん積み上げていく。砂の上に家を建てるようなものです。最初は、どうにかこうにかちゃんと建つ。みんな安心する。でも、ある日、何かのきっかけで、ぐらりとくる。捨てるものは、ちゃんと捨てる。その一見もったいない潔さが、半年後、一年後に、効いてくるんです。

育てる前提なら、話は逆になります。最初から、本番を見据えた“細い一本”を作る。機能はうんと絞っていい。でも、その細い一本は、ちゃんとしたデータの流れ、最低限のエラー処理、セキュリティの土台を持った、「小さいけれど本物」にしておく。派手なデモにはならないかもしれません。でも、これなら、太らせていくことで、そのまま本番に育てられる。捨てるための飾りではなく、育てるための芯。最初に選ぶべきは、たいてい、こちらです。

この“細い一本”を、エンジニアの世界では、ときどき「歩く骸骨（ウォーキング・スケルトン）」なんて呼びます。骨と皮しかないけれど、ちゃんと自分の足で立って、歩ける。機能は最小でも、データの入口から出口まで、本番と同じ道が一本、ちゃんと通っている。あとは、その骨格に、少しずつ肉をつけていけばいい。派手なデモで、全身の筋肉を張りぼてで見せるより、地味でも本物の骨格を一本通しておくほうが、本番という名のゴールには、結果的にずっと近いんです。急がば回れ、を地でいく話ですね。

捨てる前提のPoCは学びを抜いて潔く捨てれば健全だが、捨てそこねて本番の土台に流用すると技術的負債で身動きが取れなくなること、育てる前提なら細い一本を本物で作り肉をつけてそのまま本番に育てられることを示した図 — 悲劇は、前提を決めずに走り出して、途中で入れ替わるときに起きる

そして、PoCの検証項目に、技術の可能性だけでなく、「本番への移行可能性」を必ず入れる。動くかどうかだけでなく、運用できるか、保守できるか、コストは見合うか、安全に保てるか。ここに最初から当たりをつけておくと、「動いたのに本番にならない」という、あのがっかりを避けられます。

つまるところ、いいPoCかどうかは、デモがどれだけ盛り上がったかでは測れません。「このあと、本番に一歩近づいたか」で測るべきなんです。

拍手が大きいほど、足元を見る

デモの拍手が大きいときほど、少し足元を見るクセがついてくると思います。喜んでいる人たちには申し訳ないけれど、「この拍手は、張りぼての完成度に向けられていないか」と、つい疑ってしまう。意地悪を言いたいわけではないのです。何度も、華々しいデモのあとの「作り直し」を経験してきたからこその自衛反応とでも申しましょうか。

もし、あなたの会社で、成功したはずのPoCが、なぜか本番化の話になると急にもたつき始めたら、それはたぶん、誰かのせいではありません。最初に「捨てる前提か、育てる前提か」を決めずに走り出した、ただそれだけのことが多い。次にPoCを始めるときは、動かす前に、一度だけ自身に、チームに、問いかけてみてください。「これは、見せるためのもの? それとも、育てるためのもの?」。その一言の答えが、半年後のあなたを、ずいぶん助けてくれるはずです。