〜PoCは、安心するためではなく、不安を具体化するためのものだった〜
最近、ある新規プロダクトの開発を担当しました。フロントエンドとバックエンドの実装だけでなく、ローカル開発環境、認証、外部API連携、AWSへのデプロイ、本番リリースに必要なGoogle OAuthまわりの外部審査まで、かなり広い範囲を見るプロジェクトでした。
その中で一番考え方が変わったのが、PoC（概念実証）です。
以前の自分は、PoCを「小さく作ること」だと思っていました。もう少し正確に言うと、小さな完成版を作るイメージです。機能は少ないけど画面もそれなりにあり、データも取れて、見た目も整っていて、そのまま本実装に広げられるもの。それがPoCだと思っていました。
でも今は、こう思っています。
PoCは「小さな完成版」を作ることではなく、ある重要な経路が本当に通るかを確認するためのもの。
そしてPoCで一番難しいのは、実装そのものではなく、「何を先にやらないか」を決めること。
この記事は、そう考えるに至った失敗と、次にやるなら使う枠組みの話です。
第1部：一番複雑なメニューを選んでしまった
今回のプロダクトは、既存の別プロダクトの一部機能を参考に、新しく作り直す性質のものでした。参考にできる画面やロジックはある。一方で、ローカル環境、monorepo、認証連携、Google OAuth、GA4 Data API、DB migration、Docker、ECS、ECR、ALB……と、ゼロから整えるものが大量にありました。
このうち、フロントエンドとバックエンドの実装にはある程度経験がありました。特にUIタスクが多かったので、画面の複雑さには敏感でした。逆に、デプロイやインフラ、外部審査は経験が浅い。だから初期の自分は、自然と 「自分がよく知っている難しさ」= 画面の複雑さ に目が向いていました。
最初のPoCとして、一つのメニューを選び、フロントエンドからバックエンド、外部API、データ表示まで通す雛形を作ることになりました。end-to-endを一本通す、この方針自体は良かったと思います。
問題は、選んだメニューでした。私は、最も機能が多く画面も複雑なメニューを選びました。
そのメニューは、表示パターンが複数あり、選んだ条件によって出す数字も変わり、UI上の分岐も多いものでした。「一番複雑な画面が作れれば、他のメニューにも展開できる」と考えたからです。一番難しいものから潰す——筋が通っているように見えます。
でも、結果として自分は、経路を一本通すだけなら不要だったはずの細かいUIの再現に、かなりの時間を使ってしまいました。表示パターンの出し分け、条件分岐、見た目の調整。どれも「いつかは必要」ですが、最初のPoCで確認したいことではなかった。
このPoCで本当に検証したかったのは「複雑なUIをどこまで再現できるか」ではなく、
GA4 API → backend → frontend → 画面に数字が出る
この経路が通るか、でした。それを見るだけなら、メニューはもっとシンプルでよかったのです。
そして今振り返ると、もっと根っこに問題がありました。
自分は「プロジェクトにとって危ないもの」ではなく、「自分にとって見えやすい難しさ」を先に潰そうとしていた。
UIは自分の得意領域だから、複雑さがはっきり見える。だから大きなリスクに見えました。でも、このプロジェクトで本当にリリースを止めかねなかったのは、むしろ自分が経験の浅い側——外部APIが通るか、認証がつながるか、AWSにデプロイできるか、外部審査が間に合うか——でした。
人は、自分が見えている難しさを優先し、見えていないリスクを後回しにしてしまう。 慣れた難点ほど過大評価し、知らないリスクほど過小評価する。最初のメニュー選びは、その典型でした。
第2部：次にやるなら使う枠組み
ここからは、失敗のあとに整理した枠組みです。
PoCを始める前に、4つだけ決める
PoCがどんどん太るのは、「せっかくだからこれも」「後で困りそうだからこれも」が無限に足せてしまうからです。それを防ぐために、着手前にこの4つを書き出します。各項目、自分がやった悪い例 / 良い例を添えます。
1. 検証したい仮説 — このPoCは何を確かめるためのものか。
悪い例: 「GA4連携を作る」
良い例: 「GA4 Data APIから取得した1つの指標を、backend経由でfrontendに表示できることを確認する」
2. 通したい経路 — 点ではなく、線で書く。PoCは部品ではなく経路を確認するもの。
GA4 API → backend → frontend → 数字表示
3. やらないこと — これが一番大事。書かないと太る。
UIは最低限。表示パターンの出し分けはやらない。
ログは別PoCに回す。CodePipelineはまだ作らない。全メニュー対応はしない。
4. 停止条件 — どこまでできたら一旦完了か。
シンプルなメニューで、画面に数字が1つ出たらOK。
この4つを、PoC全体の設定として並べると、自分の失敗がはっきり見えます。
悪いPoC: 一番複雑なメニューを、見た目も含めてそれなりに再現する
良いPoC: 一番シンプルなメニューで、GA4 API → backend → frontend → 数字表示の経路だけを通す
今回の自分には、特に「やらないこと」と「停止条件」が足りていませんでした。
「最小」は、手を抜くことではない
誤解しやすいのですが、最小にすることは雑に作ることではありません。検証の目的に対して、今は必要ないものを意識的に外すことです。
これが意外と難しい。真面目に考えるほど、保守性も拡張性もセキュリティもエラー処理も気になってくる。どれも本当に大事です。でも全部を同じタイミングで扱うと、今一番確認したいことが見えなくなる。
だからPoCで問われるのは、開発スキルというより判断スキルです。何を作るかではなく、何を作らないか。どこまでで一旦OKとするか。何を次に回すか。
同じ枠組みは、デプロイにも効いた
この考え方は、デプロイでそのまま使えました。
本番に出すには、Docker imageをbuildし、ECR（imageを置く場所）にpushし、ECS Fargate（コンテナを動かす場所）で起動し、ALB（外部からの入口）経由でアクセスできるようにする必要がありました。画面機能はある程度削れても、デプロイ経路が通らないプロダクトはリリースできない。だから本来もっと早く検証すべきでした。
ただ、ここに落とし穴があります。もし当時の自分が「デプロイも早くPoCしよう」と考えたら、おそらくCodePipeline（ソース変更からbuild・deployまでを自動化する仕組み）まで一緒に作ろうとしたはずです。継続運用には重要ですが、最初のデプロイPoCの目的は自動化ではありません。確認すべきはもっと単純で、
ローカルでbuild → ECRにpush → ECSが起動 → ALB経由でアクセスできる
この経路が通るか、環境変数やネットワークで詰まらないか、でした。
実際、最終的に使ったのはかなり手動のフローです。ローカルでbuildし、ECRにpushし、image tagを書き換え、deployし、ECSを更新する。きれいではないし理想形でもない。でも「リリース経路が通る」ことは証明できました。今はこれを大事な最低ラインだったと捉えています。
順番は、まず手動で通す → 次に再現性を持たせる → その後に自動化する。動いていないものは自動化できません。一度通せば、buildが遅いのか、tag管理が危ないのか、設定で詰まるのか——問題が具体的に見える。
best practiceを探す前に、まず自分たちのpracticeを一度通す。
これを忘れると、「正しそうに見える先送り」が起きます。
PoCは、安心するためではなく、不安を具体化するためのもの
最後に、これが今回一番変わった捉え方です。
以前の自分は、PoCに「安心」を求めていました。ここまで作れれば全体もいける、複雑なものからやれば安心できる、と。今思えば、複雑なメニューを選んだのも、難しいものを先に倒して安心したかったからかもしれません。
でも今は、PoCは不安を具体化するためのものだと思っています。
着手前は、Google APIもAWSもデプロイも、全部が大きな黒い箱に見えます。この状態で「全体でどれくらい大変か」を見積もるのは無理です。だから最小の経路を一本通してみる。すると、ぼんやりした不安が具体的なタスクに変わります。
ここは動いた
ここは詰まった
ここは思ったより簡単だった
ここは設計を見直す必要がある
ここは相談した方がよさそう
具体的なタスクになれば、人に聞ける。AIに相談できる。調べられる。直せる。見積もり直せる。PoCの価値は、最初から正しい答えを出すことではなく、分からないことを分かる形に変えることにありました。
まとめ
PoCは「小さく作ること」ではありませんでした。
小さく考えることでした。
そのために、着手前に4つだけ決める——検証したい仮説、通したい経路、やらないこと、停止条件。特に「やらないこと」を書けるかどうかで、PoCが新しい沼になるかが決まります。
そして、いきなり理想形を目指さない。
まず手動で通す → 再現性を持たせる → 自動化する
best practiceを探す前に、まず自分たちのpracticeを一度通す
最後にもう一つ。今回一番効いた問いは、これでした。
自分が今つぶそうとしている難しさは、「プロジェクトにとって危ないもの」か、それとも「自分にとって見えやすいもの」か。
慣れた難点は大きく見え、知らないリスクは小さく見える。PoCは、その思い込みを早めに壊して、分からないことを分かる形に変えるためのものなのだと、今は思っています。