「要件定義で決めたはずなのに、開発フェーズで重大な漏れが見つかった……」
「本番リリース直後に例外操作でエラーが出て、休日対応する羽目になった……」
PMやエンジニアなら、一度はこんな苦い経験をしたことがあるのではないでしょうか。
仕様漏れは、決して「能力不足」だけで起きるものではありません。実は、ヒアリング中に登場する「特定のキーワード」を見逃していることが最大の原因なのです。
この記事では、Webサービス、金融システム、モバイルアプリなど、私が現場で見てきた「生々しい失敗事例」をもとに、仕様漏れを炙り出す魔法の質問リストをまとめました。
打ち合わせ中にコピペして使える形式にしています。ぜひ最後まで読んで、あなたのプロジェクトを守る武器にしてくださいね。
なぜ「仕様漏れ」は繰り返されるのか？
まず、私たちが陥りがちな「仕様漏れの正体」を図解で見てみましょう。
図のように、「ドキュメント上の理想」と「現場の泥臭い現実」のギャップが、すべて仕様漏れとして顕在化します。このギャップを埋めるのが、今回紹介する「質問術」です。
危険ワード① 「通常は〜」
【Webサービス開発でよくある事例】
ECサイトの注文フローで「通常は在庫がある前提」で設計。しかし、数万人が同時アクセスするセール時に「決済直前で在庫切れ」が発生。在庫の整合性が崩れ、大量のキャンセル対応に追われることに。
質問リスト（コピペ用）
□ 「通常じゃない」のは、どんなケース（在庫切れ、通信断、二重決済）ですか？
□ その例外は、どのくらいの頻度で起きますか？
□ 例外が起きたとき、今の現場ではどうリカバーしていますか？
□ それをあえて「システム化しない」場合、どんなリスクがありますか？危険ワード② 「〜という前提です」
【金融系システムでよくある事例】
「外部システムから届くデータは、バリデーション済みである前提」で設計。しかし、外部側の改修でNULL値や想定外の型が混入。自システムが異常終了し、バッチ処理が全停止する大事故に発展。
質問リスト（コピペ用）
□ そのデータが「来ない」「壊れている」ケースは想定していますか？
□ 異常データが混入した場合、誰が・どこで・どうやって検知しますか？
□ 検知後、再実行やデータ補正はスムーズに行えますか？
危険ワード③ 「それは別システムの責任です」
【マイクロサービス/API連携でよくある事例】
「認証は共通基盤の担当だから、自アプリ側では考慮不要」としていた。しかし、共通基盤がダウンした際、自アプリ側で適切なエラー表示ができず、ユーザーには真っ白な画面が表示され、不信感を買う。
質問リスト（コピペ用）
□ その境界線は、仕様書の何ページに明記されていますか？
□ 相手側がダウンしたとき、こちらのシステムはどう振る舞うべきですか？
□ 障害時、ユーザーへの一次回答はどちらのチームが担当しますか？危険ワード④ 「運用でカバーします」
【レガシーシステムのリプレースでよくある事例】
「複雑な割引計算は、月に数件なので手動でDBを書き換えます」という運用。しかし、担当者が退職し、手順書も紛失。数年後に計算ミスが発覚するも、誰も直し方が分からない「ブラックボックス」が誕生。
質問リスト（コピペ用）
□ 具体的に「誰が」その操作を行いますか？（属人化しませんか？）
□ その担当者が休んだ際、新入社員でも30分以内に再現できますか？
□ その運用は、1年間に何回、何時間発生する想定ですか？危険ワード⑤ 「基本的には変更しません」
【法改正が絡む業務システムでよくある事例】
「消費税率は10%固定で、ハードコード（直書き）でOK」とした。しかし、数年後に軽減税率やインボイス制度が導入され、プログラムを数百箇所修正する大規模改修が必要になり、予算が数千万円跳ね上がる。
質問リスト（コピペ用）
□ もし変更されたら、プログラムの何箇所に影響が出ますか？
□ 変更可能な設計（マスタ管理など）にしない、技術的な制約はありますか？
□ 過去10年で、このルールが変更された経緯を教えてください。危険ワード⑥ 「数はそんなに多くないです」
【SaaS/新規事業開発でよくある事例】
「最初はユーザーが少ないので、全件検索で十分」と設計。しかし、SNSでバズってユーザーが急増。1画面の表示に10秒以上かかるようになり、解約（チャーン）が続出。
質問リスト（コピペ用）
□ 「1日あたり」「ピーク1時間あたり」の具体的な件数は？
□ 3年後、データが100倍に増えても同じパフォーマンスを維持できますか？
□ 限界値を超えたとき、システムは「ゆっくり動く」か「完全に止まる」か、どちらですか？危険ワード⑦ 「ユーザーはこう使います」
【モバイルアプリ開発でよくある事例】
「ユーザーは画面の指示に従って保存ボタンを押す」という想定。しかし、実際には「保存中にアプリをタスクキル」「電波の悪い地下で操作」など、予測不能な挙動が多発。データが中途半端に保存され、不整合が起きる。
質問リスト（コピペ用）
□ 保存中に通信が切れたり、アプリを閉じたらどうなりますか？
□ ユーザーが「戻る」を連打したり、2回以上ボタンを押した時の対策は？
□ 「説明書を読まないユーザー」が陥る罠を3つ挙げてください。
危険ワード⑧ 「それは想定していませんでした」
【IoT/ハードウェア連携でよくある事例】
「センサーは常に正しい値を送ってくる」と考えていたが、電池切れ寸前で異常な数値（マイナス数万度など）を送信。システム側で「ありえない数値」を考慮していなかったため、グラフが振り切れて表示崩壊。
質問リスト（コピペ用）
□ 今この場で「ありえない異常な状態」を3つひねり出してください。
□ その異常が起きたとき、システムは「安全に停止」できますか？
□ 「想定外」が起きたときに、調査の手がかりとなるログは残りますか？危険ワード⑨ 「一旦これで」
【スピード重視のスタートアップ開発でよくある事例】
「仕様が固まらないので、一旦この画面構成で進めましょう」。しかし、そのまま開発が進み、後から「実はこの機能も必要だった」と根本的なデータ構造の変更が発生。2ヶ月分のコードがゴミになる。
質問リスト（コピペ用）
□ その「一旦」の判断を、いつ、誰が最終決定しますか？
□ 決まらなかった場合、開発はストップしますか？そのまま進みますか？
□ 結論が覆った場合の手戻り工数（金額）を、今のうちに概算しませんか？まとめ：嫌われる質問ほど、現場を救う
いかがでしたか？
仕様漏れは、決して「聞いていない」から起きるのではなく、「現実に起きうる泥臭いケースを、あえて聞けていない」から起きます。
打ち合わせ中、クライアントや上司に鋭い質問をするのは勇気がいりますよね。
「細かすぎる」と思われるかもしれません。
でも、断言します。
要件定義で嫌われるPMは、リリース後に現場のエンジニアから神様のように感謝されます。
逆に、要件定義で優しすぎるPMは、リリース後に全員から恨まれることになります。
この質問リストをブックマークして、次の会議から1つでもいいので使ってみてください。あなたのプロジェクトが、炎上から一歩遠ざかることを願っています。
コメント