仕様書よりも、まず動くものを見せる：AI 時代の新しいプロダクト開発アプローチ
AI 時代、仕様書だけが正解じゃない：ニーズを素早く形にする新しい選択肢
なぜ読む価値があるのか？
要件が曖昧、仕様確定が難航、関係者との認識が合わない——そんな経験がある方にとって、この文章は新しいヒントになるはずです。私は DocuSign を用いた契約フローの自動化を、AI の力を借りて 1 週間で実装しました。この実体験をもとに、「動くプロトタイプを起点に合意を形成する」Demo-Driven Development という考え方をご紹介します。リソースが限られたフェーズや早期検証が求められる場面で、従来の手法に代わる現実的な選択肢となるでしょう。
従来の開発プロセスの限界
従来の開発では、PM が要件定義を行い、デザイナーが画面設計をし、エンジニアが実装します。これは大規模組織では合理的ですが、その分、確認・調整のやり取りに多くの時間がかかります。
そしてもっと厄介なのは、ユーザーにとって「理解できること」と「実際に使えること」は別問題という点です。
- B2B プロダクトでは、「この画面通りに使えますか？」と顧客に確認を取りに行く必要があります。
- B2C の場合はアンケートなどで意図を推測しますが、実際に触ってみないと本当の反応はわかりません。
だからこそ、Scrum では 2 週間ごとのイテレーションが推奨されますが、それでもコストは高いままです。
AI を活用し、1 週間で動くプロトタイプを作る
今こそ、別の選択肢を取るべきだと思います。
1～2人のマイクロチーム（PM とエンジニア、もしくは技術スキルを持つ PM）で、仕様書なしに直接プロトタイプを作る。
これは「アラインメントを無視する」という意味ではありません。動くプロトタイプを基軸に、実際の操作体験を通じてニーズをすり合わせる、という意味です。
AI コーディングツール（Copilot や LLM）を使えば、少ない人手でも十分なものが作れます。
事例：DocuSign を用いた契約プロセス自動化
最近、私が担当した案件では、営業チームが顧客との契約書や申請フォームをメールでやり取りしていました。
顧客数が増えるにつれて対応が煩雑化し、特に在庫確認などのプロセスが挟まることでスムーズな契約が難しくなっていました。
DocuSign を使って自動化したいと思いましたが、普通に進めたら大変です：
- DocuSign の API や webhook、template の概念を一から学ぶ必要がある
- 完全な仕様を詰められていない（営業も要件を確定できていない）
- 仕様書がない → 着手できない → プロジェクトが止まる
この状況を打破するために、私はまず簡単な PPT のフロー図で営業とアラインメントを取り、AI を活用してコーディングを開始しました。
そして一週間で、以下のようなシステムを完成させました：
- composite template を用いた「記入→承認→署名」のフロー
- 個人／法人ごとに異なる書類が自動送信
- 画面への埋め込み、テンプレートの自動選択、webhook による状態追跡
今では営業がこのプロトタイプを使って実際に顧客に提案し、顧客もその場で操作しながらフィードバックを返してくれるようになりました。
これが私の提唱する Demo-Driven Development です。
万能な手法ではないが、「方向性の検証」には最適
AI によるコードは不安定で壊れやすいこともあります。最終的にはプロのエンジニアによる保守が必要です。
しかし、方向性も定まらず、リソースも限られている状況では、このような方法で仮説を早く検証するのが合理的です。
最悪でも、無駄になるのは一週間だけです。
実質的には Lean MVP の一種
このやり方は、Lean Startup の MVP そのものです。 違いがあるとすれば、「プロトタイプによる理解の収束」を重視する点です。
つまり、会議や文章から始めるのではなく、デモできる何かを最初に作って、そこから考えるという順序です。
本質は「デモ」ではなく、デモがあるから話が噛み合い、誤解が減り、検証が早くなるというところにあります。
行動ベースの軽やかな開発思考へ
これは「PM がコードを書くべきだ」と言っているのではありません。
ただ、AI によって試すコストが下がった今、私たちは「まず動くものを作って試す」という選択肢を持つべきだと考えています。
特に、早期フェーズにいるスタートアップやリソースが限られているチームなら、ぜひこう自問してみてください：
「今、仕様を詰めるよりも、まず何か試作品を出せないか？」
プロダクトは会議ではなく、実行から生まれます。