ヒアリングの場で，業務部門のユーザーがITエンジニアに仕様をすべて話してくれるとは限らない。ユーザーが話していない仕様を聞き出す必要がある。そのときに有効なコツは「ユーザーが言ったこと以外のケース」すなわち「そうではないケース」を，ユーザーに質問することだ。
物流会社のバンテックで，輸出入管理システムの仕様策定に携わっている桜井功介さん（管理本部 情報システム部 輸出入ITグループ）は，そうではないケースを聞いて仕様を詰めた経験を持つ。
桜井さんが，輸出入システムについて営業部門のユーザーにヒアリングをしていたとき，システムで印刷される「作業指示書」の中に盛り込む「作業開始日」というデータ項目の話題になった。ユーザーは「この項目には，貨物が倉庫に入った日の2日後の日付を印刷してください」と桜井さんに伝えた。この2日間で，輸出用に貨物を梱包するのだという。
これを聞いて桜井さんは「なぜ2日後なのだろう。場合によっては1日後だったり3日後だったりすることもあるのではないか」と，ふと疑問に思った。桜井さんはヒアリングの後，倉庫の担当者に「作業開始日が，貨物が倉庫に入って2日後にならないケースはありませんか」といった詰めの質問をした。
その結果，限られた担当者で梱包作業をしたり，梱包作業そのものを改善したりすることで，作業開始日が，貨物が入って2日後以外になることが分かった。桜井さんは，貨物が入った日にかかわらず作業開始日を設定できるように仕様を策定した。システムの稼働後，作業開始日に関する仕様を変更することになったが「問題なく対処できた」と桜井さんは効果を語る。
そうではないケースを聞くのは，「受注したら商品の在庫を確認して受注した数量を出荷する」といった仕様が出てきた場面でも有効だ。この場合，そうではないケースを聞く質問としては「商品の在庫が不足しているケースでは，受注数分の商品がそろうまで待って出荷するのか」「在庫に余裕があるケースでは，受注した数量以上の商品を出荷することがあるのか」といったものが考えられる。
具体例を挙げると効果的
そうではないケースを聞き出すには「具体例を挙げて質問すると効果がある」と，NTTコムウェアの中澤博美さん（エンタープライズ・ソリューション事業本部 HCMソリューション部 担当課長）は話す。
中澤さんがある企業の人事管理システム開発のヒアリングを実施したときも，具体例を挙げた詰めの質問が奏功した。ユーザーから「システムで管理する情報は，部や課ごとにセキュリティをかけてもらいたい」という要望が上がってきたときのことだった。ここで中澤さんは「それは例えば『A部のP課に関するデータは，P課のメンバーは参照できて，A部の別の課であるQ課のメンバーは参照できない』といった具合でしょうか？」という，詰めの質問をした。
すると「今の例ではその通りです。しかしA部全体を統括するR課では，A部全体の情報を参照できるようにしたいです」と，詳細な仕様をユーザーから聞き出せた。
マトリックスで整理する
NTTドコモの坂本さんの工夫は，ヒアリングの内容をマトリックス（表）で整理すること。整理していくと，ヒアリングの内容だけでは埋められない空欄が見つかる。この空欄が「そうではないケース」に当たるというわけだ。「マトリックスの空欄に何が入るかを確認していけば，仕様の抜けは大幅に防げる」と坂本さんは説明する。
例えば，入退館システムのヒアリングをしたときには，管理対象となる人の分類と，立ち入れる場所の区分に分けて，マトリックスに整理した。その上で「グループ会社や協力会社の社員は，どの場所の入館や入室を許しますか」といった，ユーザーが言わなかったケースについて詰めの質問をした（図1）。「ユーザーとのヒアリングに十分な時間が取れないときは，こちらで空欄を赤字で埋めておき，問題ないかをユーザーに確認してもらっている」と坂本さんは話す。
