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

システムが納品され、意気揚々と使い始めた現場から、必ずと言っていいほど上がる声があります。「この画面、すごく使いにくい。ボタンが押しにくいし、表示も遅い。不具合だから直させてよ」

この時、 ITリーダーが直面するのが、ベンダーとの 「不具合か、それとも追加要望か」 という不毛な論争です。

この板挟みを解消し、プロジェクトの着地を安定させるためには、要件定義の段階で「境界線」を明確に引いておく必要があります。

1. 「正常」の定義を数値化・具体化する

トラブルの多くは、「使い勝手」という主観的な言葉から生まれます。これを回避するには、要件定義書の中で可能な限り 「数値」 や 「具体的な動作」 を用いて正常な状態を定義することです。

要件定義書には「やること」ばかりが書かれますが、実は 「やらないこと」 を書くことの方が、トラブル防止には効果的です。

サポート対象ブラウザの明記: 「Google Chrome 最新版のみを動作保証とする」といった定義です。Mac の Safari や Opera など、サポート範囲外のブラウザで表示が崩れたり、特定のスクリプトが動かないといった事象は、不具合ではなく「環境に起因する制約（範囲外）」であることを握っておきます。
「スマホ対応は対象外（PC ブラウザのみを保証する）」
「 1,000件を超える一括登録機能は、今回は実装しない」
「既存の古い会計ソフトとのデータ自動連携は含まない」

これらを明文化し、経営層や現場リーダーにも共有しておくことで、後からの「当然やってくれると思っていた」という期待を、あらかじめ適正なレベルにコントロールできます。

文書だけでは、どうしても限界があります。当サイトが推奨する「完全型プロトタイプ（EDD）」を要件定義の主役に据える最大のメリットは、 「この画面のこの動きが正解である」 という共通認識を、実物で持てることです。

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

要件定義とは、単に機能のリストを作ることではありません。ベンダーと自社の間で 「どこまでを契約の範囲（責任範囲）とするか」 という合意形成のプロセスそのものです。

「いい感じでよろしく」という曖昧な甘えを捨て、ドライに境界線を引くこと。それが、最終的にベンダーとの良好なパートナーシップを守り、予算内での確実なシステム導入を実現するための、 ITリーダーに求められる最も重要な資質です。