「不具合」と「要望」の境界線を、要件定義の段階で明確に引いておく方法

リリース後に「これは不具合か、追加要望か」という争いはよく起きます。ベンダーは「仕様通りに動いている」と言い、現場は「使えないのだから欠陥だ」と言う。この板挟みを防ぐには、要件定義の段階で「正常な状態の定義」と「対象外の範囲」を明確に書いておくことが必要です。

「正常な状態」を数値と具体的な動作で定義する

トラブルの多くは「使い勝手」という主観的な言葉から生まれます。「表示が遅い」「使いにくい」という声に対して、要件定義に具体的な基準がなければ、不具合かどうかの判断ができません。

これを回避するには、要件定義書の中で数値と具体的な動作を用いて正常な状態を定義することです。

レスポンス速度：「画面遷移は通常のネットワーク環境下で2秒以内に完了すること」と記しておけば、5秒かかる場合は明確な不具合として指摘できます。「速く動くこと」という曖昧な表現は判断基準になりません。

入力チェックの仕様：「この項目に数字以外が入力された場合、保存ボタンを押したときに日本語のエラーメッセージが表示されること」のように、具体的な入力パターンとシステムの反応を対で定義します。エラーメッセージの文言まで要件定義書に含めておくと、検収時の判断が明確になります。

画面の表示件数・並び順：「一覧画面では最大100件まで表示し、デフォルトは登録日の新しい順とする」のように、デフォルト状態を明確に定めます。この種の仕様が曖昧だと「思っていた表示と違う」という話が後からよく出てきます。

操作の流れ：「この画面から次の画面へ遷移するときは確認ダイアログを出す」「削除操作は取り消しできない旨を警告してから実行する」といった操作仕様も、具体的に定義しておくことで後からの解釈ズレを防げます。

「やらないこと（対象外）」をあえて書く

要件定義書には「やること」ばかりが書かれますが、「やらないこと」を明示しておくことも同様に重要です。対象外の範囲を書いておくことで、後からの「当然含まれると思っていた」という期待のズレを防げます。

サポート対象ブラウザ：「Google Chrome最新版のみを動作保証とする」と定義しておけば、他ブラウザでの表示崩れは対象外の問題として扱えます。どのブラウザ・デバイスをサポートするかは、利用環境を確認した上で具体的に定めてください。

対象外の操作・機能：「1,000件を超えるデータの一括登録機能は今回の対象外」「スマートフォンへの対応は次フェーズで検討」といった形で、対象外の範囲を箇条書きで記載します。

既存システムとの連携範囲：「既存の会計ソフトとの自動連携は含まない」のように、連携要件の範囲も明示します。連携を「なんとなく含まれるもの」として扱うと、開発後半に大きなトラブルになります。

これらを文書化し、経営者や現場責任者にも共有しておくことで、後からの「当然やってくれると思っていた」という期待を、事前にコントロールできます。

プロトタイプを合意の証拠にする

文書だけでは「そう書いてあっても、こういうつもりだった」という解釈の余地が残ります。プロトタイピングを活用している場合は、プロトタイプを合意の証拠として位置づけることが有効です。

「プロトタイプで合意した動き」と異なるものは不具合、プロトタイプにない新しい機能は追加要望——このシンプルなルールをベンダーと事前に合意しておくだけで、リリース後の「言った言わない」の多くを解消できます。

プロトタイプを使った合意の際は、「このプロトタイプをベースとして開発を進める」という文言を要件定義書に明記しておくことで、後からの判断基準がより明確になります。

変更管理のプロセスを決めておく

要件定義の段階では想定できなかった変更は、開発中にも発生します。問題になるのは「変更かどうか」の判断ではなく、変更が発生したときのプロセスが決まっていないことです。

「要件変更の申請は誰が誰に出すか」「変更の影響範囲とコストはどのタイミングで確認するか」「変更に同意するのは誰か」というプロセスを事前に決めておくことで、変更が発生した際の混乱を最小化できます。変更管理の手順を要件定義書の一部として含めておくことを推奨します。

変更管理のポイントは、変更の内容・影響範囲・追加コスト・対応時期を書面で確認してから承認するという手順を守ることです。「口頭でお願いしたら、いつの間にか高額な追加費用が発生していた」というトラブルは、このプロセスがないことから起きます。

まとめ

「不具合」と「要望」の境界線を明確にするには、要件定義書に「正常な状態の数値・具体的な動作」と「やらないことの明示」を含めることが重要です。プロトタイプを合意の証拠として活用し、変更管理のプロセスも事前に定めておくことで、リリース後のトラブルを大きく減らすことができます。「境界線を引く」という作業は、ベンダーとの信頼関係を守るためだけでなく、プロジェクト全体を安定させる基盤になります。