二つ目の仕様バグは「過剰」である。「要求を挙げていくと，100件から多いときで1000件くらいがリストアップされる」（クオリカ システム本部 第一事業部 Kプロジェクト推進部 部長 沖山英明氏）。その中には，「データの二重入力をやめたい」「新たな帳票が欲しい」「他システムと連携させたい」――といった要求が際限なく挙げられ，中には過剰と思えるものも含まれる。絞り込むにしても，むやみに減らすわけにはいかない。
過剰な要求を絞り込むには，その要求が正当なものであるかをチェックし，優先度を考える。その知恵を見ていこう。
効果は期待できるか？
優先度を考える切り口はいろいろあるが，「答えを出すことを焦ってはいけない。解決すべき問題がどこにあるかをきちんと理解した上でないと，本当に必要な要求の絞り込みはできない」（グローバルナレッジネットワーク 事業統括本部 技術教育スペシャリスト 井澤哲也氏）。
パワーソリューションズの高橋氏は，洗い出した要求を整理するために業務内容分析シートを使っている。このシートで，業務にかかる標準時間や難易度を整理し，最終的には「労力」と「効果」を評価する（図7-A）。そうした上で優先度を見極め，優先度の高いものから順番に開発していく。
 |
| 図7-A●根拠をもって要求の優先度を決める方法 1 パワーソリューションズの高橋氏は洗い出した機能ごとに「システム化するための労力」と「システム化による効果」を設定し，開発の優先度を決める。業務内容分析シートで機能の優先度を決める [画像のクリックで拡大表示] |
要求は浮いていないか？
要求全体をふかんして要求同士の関係を確認し，浮いた要求がないかと考えてみる。優先度を見極めるには，こうした方法も有効である。
例えば，「要求を業務フロー図とヒモ付けて眺めてみるのが効果的だ」と，クオリカの沖山氏は言う。受発注業務の迅速化を図るシステムであれば，「承認のプロセス簡素化」「Webサイト上での受注」「二重入力の防止」「在庫チェックの簡易化」――といった要求はすべて一つの業務フローの中でプロセスに対応している。
一方で「画面遷移のレスポンス向上」という要求は，この中では浮いた感じがする（図7-B）。浮いた要求はほかと関連しないので，とりあえず除外して考えることができる。
 |
| 図7-B●根拠をもって要求の優先度を決める方法 2 クオリカ 沖山氏のやり方。業務フローに沿って要求を並べると，一つの流れに位置付けられるものと，浮いたものが出てくる。浮いたものを除外する |
一方で「画面遷移のレスポンス向上」という要求は，この中では浮いた感じがする（図7-B）。浮いた要求はほかと関連しないので，とりあえず除外して考えることができる。
「一見脈略のなさそうなたくさんの要求も，並べてみると関連が見えてくる」（クオリカの沖山氏）。要求の中には他の要求と同じ目的を達成するためのものもあれば，あまり脈略のない浮いた要求もある。浮いた要求は，優先度を落とすのが得策である。
