3週間前、夜の10時半にNotionのページを眺めていました。クライアントからカスタム予約プラットフォームのブリーフが届いていたのです。ブリーフは4つの箇条書きと絵文字だけでした。本当に「Calendlyだけど犬のトリマー向け🐶」というだけ。それで全部。ユーザーフローもなし。エッジケースもなし。SaaSなのか単一テナント導入なのかも不明。それなのに金曜日までに仕様書が必要でした。
以前は、そういう瞬間が嫌いでした。今はほぼ楽しみにしています。
Claudeを中心としたワークフローを構築したおかげで、そうしたカオスを2時間程度で整理された防御可能な仕様書に変換できるようになったのです。過去1年半の間にSeahawkで40近いプロジェクトを通じてこれを洗練させてきたし、「でも私はXができると思ってた」という書き直しが少なくとも3回は必要だったかもしれないお金のかかる手戻りから救われています。
きちんと説明していきましょう。
---
曖昧なブリーフが実は良い出発点である理由
曖昧なブリーフについての事実は、それが信号を含んでいるということです。犬のトリマーCalendlyの例は、業界、競合製品、そして暗黙的な規模（エンタープライズではなく中小企業）を教えてくれます。これは無視できません。
以前私がした間違いは、ブリーフを自分ですぐに肉付けしようとしたことです。仮定を立てて、それをドキュメントに組み込んで、クライアントが私の推測40%を含むものに署名することになっていました。これは災厄の前触れです。
Claudeにはそういう問題がありません。Claudeは質問をします。正しくプロンプトを与えれば、あなたが聞くべきだった質問を生成するのです。
新しいプロジェクトで最初にすることは、生のブリーフをClaudeに貼り付けて、それを構築するために自分が仮定する必要のあるすべての仮定を特定させることです。機能ではなく、仮定です。出力は通常15～25の質問で、そのうち約3分の1は私が見落としていたものです。
犬のトリマープロジェクトでは、Claudeが次のようなことを指摘しました。トリマーは複数のスタッフ、それとも個人営業？ペットのサイズが予約時間に影響するのか？予約時にデポジットまたは支払い情報を取得するのか？ペットのサイズについては全く考えていませんでした。クライアントも気づいていなかったようです。ディスカバリーコールで、スプリント3の代わりに捕捉できました。
---
実際に機能するプロンプト構造
仕様書作業のプロンプト方法を色々試してきました。「予約アプリの設計を手伝って」というような一般的なものは、一般的なつまらない結果をもたらします。効果的なのは、Claudeが出力を制限するのに十分なコンテキストを与える構造化された入力です。
今使っている大まかなテンプレートはこちらです：
- ロール定義。Claudeに、B2Bサース製品をリリースした経験があり、スコープクリープを嫌う上級プロダクトマネージャーとして機能するよう伝えます。
- 生のブリーフ。粗くても、そのまま貼り付けます。
- 制約条件。予算範囲、既知の場合はテックスタック（ほとんどのクライアントサイトはWordPress/WooCommerceがデフォルト、より重いものはカスタムLaravel）、タイムライン、チームサイズ。
- 出力形式。特定のセクション：問題文、ユーザーペルソナ、コアユーザーフロー、機能リスト（MVP対ローンチ後）、未解決の質問、リスク、を含む構造化ドキュメントを要求します。
制約条件の部分は、ほとんどの人がスキップする部分です。これは非常に重要です。「予算：£8,000、タイムライン：8週間、2名のデベロッパーと兼任デザイナー1名」は、制約条件なしの同じブリーフとは大きく異なる仕様書を作ります。制約条件がなければ、Claudeは6ヶ月と£60kかかる製品を喜んで仕様書に含めます。読むのは楽しいですが、出荷するには役立ちません。
---
対立的プロンプティングで仕様書を反復する
初期ドラフト仕様書を作成するのは簡単な部分だ。本当の価値は反復にある。
Claudeが初期ドキュメントを作成した後、私は「adversarial pass」と呼ぶプロセスを実行する。率直に聞くんだ。「この仕様に対して反論してくれ。スコープクリープが最も起こりやすいのはどこか？何を過小評価していないか？このリストのどの機能が12ヶ月後に最も技術負債を生むだろうか？」と。
Seahawkは2022年、マイクロ投資ポートフォリオ追跡用のダッシュボードを望むフィンテッククライアントを担当していた。最初の仕様書は堅実に見えた。Adversarial passで「リアルタイム価格更新」機能がMVPで大きな役割を果たしており、私たちのタイムラインと予算では想定されていないWebSocketアーキテクチャが必要になる可能性が高いことが指摘された。私たちは見抜いた。MVPは60秒ごとのポーリングにスコープを絞り、リアルタイムはフェーズ2の機能にした。クライアントはそれで問題なかった。Adversarial passがなかったら見抜けただろうか？もしかしたら。でも誰かが開発に3週間費やすまで気づかなかった可能性が高い。
Adversarial stepはプロセスに20分程度追加する。毎回の価値がある。
---
仕様書からユーザーストーリーへの翻訳
仕様書が十分に堅実になって恥ずかしくない状態になったら、ユーザーストーリー生成に進む。良いユーザーストーリーの作成は退屈で、下手にやるのも簡単だから、Claudeが本当に輝く場面だ。
仕様書をClaudeに戻して、標準フォーマットでユーザーストーリーを求める。「[ロール]として、[アクション]がしたい。なぜなら[成果]だからだ」というやつだ。また、「グルーマーとして、休日の時間をブロックしたい」には驚くほど多くのエッジケース（繰り返しブロック？タイムゾーン？既存予約があるクライアントに通知するか？）があるから、非自明なもの全てについて受け入れ基準にフラグを立てるよう求める。
私が絶対に譲らないいくつかの点がある。
- ストーリーは汎用的な「ユーザー」ではなく、特定のペルソナに向けて書く。
- 各ストーリーは大まかな複雑性見積もりを持つ（S/M/L。この段階ではそれ以上の粒度は不要）。
- 「L」バケットのものは全てJiraに入る前に更なる分解のためにフラグを立てる。
この最後の点が重要だ。スプリント計画会議でのLストーリーは基本的に爆弾だ。Claudeに早期に浮上させてもらえば、誰かが開発を始める前に会話を持つことができる。
---
Claudeとの線引き
正直でありたい、なぜなら今AIが全てをするという熱烈な意見が多いから。
Claudeは決断が下手だ。オプションと権衡取引を示すのは得意だが、カスタム通知システムを構築するか、それとも3つのプロジェクトで使用済みで推奨できるNovuを使うかについての実際の決定には、プロジェクト、クライアント、チームの能力を知っている誰かが必要だ。
また、特定のライブラリバージョンやニッチなAPI動作に関わることについても信頼性が低いことに気づいた。広範なアーキテクチャ討論なら問題ない。「この特定バージョンのWPGraphQLは負荷下でこの特定クエリパターンを処理するか」については、信頼するより検証したい。
正直なところ、プロンプト自体にもスキルが必要だ。チームのジュニアが同じワークフローを試したが、制約とロール枠組みが十分に厳密ではなかったため、平凡な仕様書に終わった。ツールはそれを使う人を増幅させる。それは批判ではなく、現実的であるべき価値がある。
---
出力を生きたドキュメントに整理する
Claudeが作成した仕様書は最終成果物ではない。それは入力だ。
私がクライアントに実際に提供するのはNotionドキュメントだ。Claudeの出力から構築されるが、サインオフに適した形式に再構成される。通常は以下の通り。
- エグゼクティブサマリー（3～4文、専門用語なし）
- スコープ（含まれるもの、明示的に除外されるもの）
- ユーザーペルソナ（最大2～3個。この段階ではそれ以上はノイズだ）
- コア フロー（段落ではなく番号付きステップとして記述）
- 機能表（列：機能、MVP またはフェーズ 2、大まかな工数、担当者）
- 未解決の質問（決定を阻む事項、回答責任者の指定付き）
- リスク及び対策
未解決の質問セクションは 2020 年のプロジェクト後に導入しました。そのとき、データ保持ポリシーについて誰かが解決済みだと全員が想定していて、プロジェクトが脱線したんです。各未解決の質問に人名をつけることで、問題が無期限に放置されることがなくなります。
Notion ドキュメントをクライアントと共有して、彼らがそこに直接コメントし、45 分の通話で内容を検討します。すべての未解決の質問に答えが出るまで、開発者には何も渡しません。
---
The Actual Time Savings, Honestly Stated
このワークフロー以前は、中程度の複雑さのプロジェクト（例えばメンバーシップポータルやカスタム e コマースの構築）の仕様書作成に 1 日半かかっていました。執筆、疑問、再執筆の繰り返し。同僚にドラフトを送って、コメントをもらって、それを組み込む。
今は Claude の支援による下書き作成に 2～3 時間、その後人間による編集とクライアント向けの仕上げに 1 時間程度。合計で 3～4 時間といったところです。
1 年を通すと、この削減は見過ごせません。Seahawk では月に 2～3 プロジェクトの仕様書を納品しています。保守的に見積もっても、年間 50～70 時間は一から仕様書を書く作業をしなくなります。
しかし、より大きな勝利は正直なところ品質です。特に対抗議論（adversarial pass）は、私が見落としていたものを捉えます。最初の仮説の洗い出しは発見通話をより生産的にします。なぜなら、私が気づかなかったギャップを埋めるのに四苦八苦するのではなく、実際の決定について議論できるからです。
---
FAQ
このワークフローは内部ツールにもクライアントプロジェクトと同じく機能しますか？
はい。内部ツールの場合、クライアントのブリーフより使用者をよく知っているので、かえってうまくいくこともあります。昨年 Seahawk 独自の社内時間追跡ツールの仕様書作成時に、本質的に同じプロセスを使いました。制約入力は簡単でした。予算（外部費用ゼロ、開発者 1 名、期間 3 週間）と、ペルソナが文字通りオフィスの人たちだったからです。
非技術系の創業者は開発者なしでこれを使えますか？
ある程度まで。仮説の洗い出しとユーザーストーリーのステップは技術知識がなくても問題ありません。難しくなるのは対抗議論と工数見積もりです。Claude が複雑性を過小評価しているのに気づく経験が必要です。非技術系なら、そのステップを実際にソフトウェアをリリースした経験者と一緒にやってください。1 時間の通話でも構いません。
Claude を使うとき、機密のクライアント情報をどのように扱いますか？
プロンプトに入れる前に機密情報を匿名化します。クライアント名は「[Client]」に、個人識別情報は削除します。また、本当に機密性の高い内容は Claude を API 経由で使用し、コンシューマー製品ではなく Anthropic のエンタープライズデータ処理規約が適用される環境を使います。自分の状況で何が適切かを判断する前に、Anthropic の使用ポリシーを読む価値があります。
仕様書は開発者との初回接触で常に形を保ちますか？
いいえ。また、そうあるべきではありません。仕様書は、思考を凍結する契約ではなく、適切な会話を早期に持つための強制機能です。クライアントに言うのは、この仕様書は今日、私たちが何を構築するかの共通理解だということです。変わります。その変化を事故ではなく意図的で可視化することが、仕様書の役割です。
---
仕様書はドキュメントではありません。それは議論です。問題をよく理解して、構築する価値があるものを構築できるほどに十分理解していると主張しているのです。Claude がその議論をあなたのために行うわけではありません。しかし、自分が本当に言いたいことが何かを理解するための、実に有用なスパーリングパートナーになります。
それは誰の時間でも 2 時間の価値があります。