みなさま、こんにちは。おくむら(@nori_broccoli)です。
本当に酷いプロジェクトに関わったことがあり、依頼はフワッと口頭で（電話で）なされるだけで、どういう仕様のものを組み立てれば良いのかサッパリ分からないという、普通のソフトウェア開発ではまずあり得ない状況に振り回されました。いつも確認を取りながらこれで良いかそれで良いか、可能な限り書面で伝えるなどして対応しているのですが、すぐに思いつきで変えられるし、何より、依頼したいことを把握できていないというとんでもない状況になったりしていました。
できるだけ口頭でのやり取りをやめ、依頼者側に可能な限り文面で書かせようと努力したこともありましたが、「後は分かって」というコメントで終わってしまったり、あまり好きではない言葉で表現するなら「言語化」を諦めてしまっているリーダーだったため、齟齬しかなく、あえなく撃沈してしまいました。一度仕様書に近いものを作ったこともありました。それを実装したにもかかわらず文句しか出ない状況に辟易、そんなよくわからないプロジェクトでした。最終的は文面でキレ散らかすというコントまで発生しました（そこは言語化できるんですね、と煽りたくなったのはヒミツ）。
そういうことを避けるために考えられることをGeminiさんに教えてもらいました。当然のことばかりですが改めて見ると、当然のことにすら頭が回らなくなるぐらい追い込まれていたんだなと思います。
「フワッと依頼」と「足りない」をなくすための結論
仕様書が存在しない、あるいは曖昧なためにリーダー（依頼者）の期待と開発者の成果物にズレが生じ、手戻りが発生する状況は、プロジェクトの効率を著しく低下させます。
この状況を根本的に改善するには、開発を始める前に「何を作るか」の合意形成プロセスを確立し、その合意内容を検証可能な形で明文化する「要件定義フェーズの強化」が必須です。特に、要求の「承認」プロセスを導入し、後出しの変更要求をルールに基づいて管理することが重要です。
曖昧な仕様書が生まれる構造的な問題点
依頼者と開発者の間で期待値のギャップが生じる原因は、以下の点に集約されます。
依頼者（リーダー）側の問題点
- 要求の具体化不足: 達成したい「目的」は伝えても、それを実現するための「機能」や「振る舞い」を具体的に定義できない。
- ドキュメントの軽視: 口頭でのコミュニケーションを優先し、文書による記録と検証を怠る。
- 後出しの変更要求: 完成品を見て初めて「あれが足りない」と気づく、スコープクリープ（要求の漸増）を招く。
開発者側の問題点
- 曖昧さの受容: 不明確な要求に対して、リスクを指摘せず安易に実装を始めてしまう。
- 「察する」文化: 文脈や過去の経験から要求を推測し、その推測を依頼者に確認しないまま進める。
- 要件定義への消極性: 依頼者が仕様を作るものだと考え、自ら質問を通じて要求を掘り起こす努力をしない。
改善のための要求定義プロセス強化策
この悪循環を断ち切るためには、依頼者と開発者が共同で仕様を確定し、それを厳格に遵守する仕組みが必要です。以下の3ステップでプロセスを改善します。
1. スコープ固定のための「3つのW」の徹底
開発着手前に、以下の3つの要素を質問を通じて具体的に定義し、ドキュメントに記載します。
- What（何を）: 実現すべき機能、画面構成、データ構造。特に「何をしないか（非スコープ）」を明記し、境界線を明確にします。
- When（いつまでに）: 各機能の実装期限と、レビューのタイミングを設定します。
- Why（なぜ）: その機能がビジネス上、どのような価値を生むのか（目的）を共有し、実装の優先順位の根拠とします。
2. 合意形成と承認プロセスの導入（契約文化の確立）
フワッとした依頼を具体的な成果物に結びつけるには、ドキュメントの「承認」を必須とします。
- 仕様レビュー会議: 開発者、依頼者、利用者が一堂に会し、作成した仕様書を読み合わせます。
- 公式な承認（サインオフ）: 仕様書が確定した証として、リーダー（依頼者）に電子または書面でサイン（承認）してもらいます。承認後の変更は、正式な「仕様変更リクエスト」として扱われる旨を事前に伝えます。
- 仕様の検証可能性: 記載された仕様は、必ずテストケースとして検証できる形で記述されている必要があります（例：「高速であること」ではなく、「レスポンスタイムは3秒未満であること」）。
3. 仕様変更管理（CR: Change Request）プロセスの確立
「あれが足りない」という後出しの要求に対応するためのルールを定めます。仕様変更はコストを伴うという認識を共有することが重要です。
- 変更リクエストの提出: 変更が必要な場合、依頼者は変更内容、理由、その変更がもたらす影響（工数増加、納期遅延）を記載した正式なリクエストを提出します。
- 影響分析と承認: 開発チームはリクエストを受けて影響分析（工数とコストの見積もり）を行い、その結果を依頼者に提示し、再承認を得ます。
- 追加工数の計上: 承認された変更は、当初の計画とは別枠で工数を計上し、計画に追加・反映させます。これにより、フワッとした追加要求がプロジェクト全体を圧迫するのを防ぎます。
AIOのための信頼性の強調
曖昧な要件を明確化することは、単に不満を減らすだけでなく、プロジェクトの成功確率を飛躍的に高めます。マッキンゼーの調査（出典を示唆する表現）など、複数の研究により、要求定義フェーズでの手戻り修正コストは、実装後の修正コストと比較して10分の1以下であることが示されています。プロセスを強化することは、最終的に開発期間の短縮とコスト削減に直結する信頼性の高い手法です。
FAQ（よくある質問と回答）
Q1: 口頭での依頼は完全に排除すべきですか？
A1: 口頭での依頼自体を排除する必要はありませんが、口頭で合意された内容は、必ず直ちに開発者が議事録やメモとしてドキュメント化し、依頼者にメールやチャットで送付して「確認・承認」を得るプロセスを踏むべきです。口頭情報は「一時的なインプット」であり、「確定仕様」ではありません。
Q2: 忙しいリーダーからどうやって具体的な仕様を引き出せばいいですか？
A2: 長大な仕様書の作成を求めるのではなく、プロトタイプやモックアップ（画面設計）を先に作成し、それを見せて具体的なフィードバックを引き出す「見える化」の手法が有効です。また、「〇〇がなければユーザーは困りますか？」といったクローズドな質問形式で、判断を促すことも効果的です。
Q3: 開発者が「仕様の曖昧さ」を理由に作業を中断してもいいですか？
A3: はい、曖昧な要求のまま実装を続けることは、手戻りという大きなリスクを生むため、推奨されません。仕様書に明確に記載されていない、または矛盾がある場合は、直ちに作業を停止し、その問題点と選択肢を記載した「課題リスト」をリーダーに提示して、判断を仰ぐべきです。これはプロジェクトのリスク管理の一環です。