実際に業務要求の洗い出しを行う場合の調査対象について説明しよう。調査の対象は，大きく分けて三つある（図3）。
（1）エンドユーザー（実際のシステム利用者だけでなく部門のマネージャも含む）
（2）ドキュメント類
（3）現行システム
この調査対象は，RFP作成者が誰なのかによって，実は大きな違いがある。例えば，エンドユーザーがRFP作成者の場合は，（1）は自分自身ということもあり得る。そこで，今回の説明では便宜上，RFP作成者は外部のコンサルタントという想定の基で行うこととする。エンドユーザーや情報システム部門をRFP作成者と想定する場合と比べて客観的な立場であり，様々な立場の読者の参考になると考えたからだ。
（1）のエンドユーザーに関しては，本連載中，業務要求の洗い出し・取りまとめのためのヒアリング・テクニックを説明する次回に解説する予定だ。以下では，（2）のドキュメント類から解説していこう。調査対象となるドキュメントには，以下のようなものがある。
a.現行システムの開発時に作成された要件定義書やシステム仕様書，および現行システムの維持管理に伴う仕様の変更履歴
b.エンドユーザーがなにかの折りに作成した問題点や課題について書いた資料
c.業務の説明が書かれた資料（新入社員向けの業務説明書や業務マニュアルなど）
d.現行システムから出力される帳票類
「掘り出し物」を見つける
ドキュメント類の調査で一番重要なことは「掘り出し物」を見つけることである。最近はISOなどの管理基準が浸透し，ドキュメント類の管理がきちんとした企業も増えてきている。しかし現実には，aの要件定義書やシステム仕様書，仕様の変更履歴といった資料がきちんと時系列で保存されていないことは少なくない。
逆に，ドキュメントがきちんと整理して保存されている場合でも，山のような大量の資料全てに詳細に目を通すとなるとうんざりするし，時間的にも厳しい。また，古い資料ではそのままRFPに活用できるものはほとんどない。従って，最初にざっと目次や資料のタイトルをチェックし，あたりを付ける作業は必要なのだ。aの類の資料では「当たり前に動いている基本機能」に関しては十分に参考にできる資料が残っている場合も多いので，そこに目星をつけて探すとよいだろう。
bの，エンドユーザーが問題や課題を記述した資料がある場合はぜひ有効活用したい。エンドユーザーが感じている問題点の大枠を掴むことの助けとなるし，ヒアリングを行う場合の質問項目作成のたたき台としても使える。ただし，その資料が何の目的で作られたのかは，知っておきたい。上席が出席する会議での報告資料であれば，精度は高い。逆に，個人的な覚書や少人数の打合せで使った資料などの場合は，重要度や問題の内容などが個人的見解に過ぎないこともあるので注意して用いる。
cの業務の説明が書かれている資料は，コンサルタントが入る時に最初に読む資料である。顧客の業務を知るためである。同様にベンダーにも業務に関する基本的な情報を与える必要がある。そのために「基本業務一覧」のような資料をRFPのアウトプットとして作成することがあるが，その作成時にcの資料は参考になる。
業界経験のないベンダーをベンダー選定の対象外とする場合は，そのような基本的な業務知識の資料は不要ではないか，という意見もある。しかし同じ業種でも，会社によって仕事の種類，得意分野，用語などが異なる場合が多いので，基本的な業務情報を与えるほうがベターである。
dの現行システムから出力される帳票類に関しては，いまさら説明するまでもないだろう。どのような種類の帳票がどのタイミングで出力されるのか，それがどのような用途に利用されるのか，特に業務フローを作成する上で欠かせない調査対象である。
現行システムを実際に操作してみる
（3）の現行システムは，実際に操作してみるといろいろな事柄が分かる場合が多い。前述のドキュメントの調査と併せて行うことで，より具体的に現行システムの機能や設計思想などが見えてくる。さらに，エンドユーザーの不満点や，ユーザビリティ上の限界などを体感することもできよう。
本番システム上では調査のための操作は限界があるので，テスト環境があればなおよい。しかし，実際にはある規模以上のシステムでないとテスト環境が用意されていない場合も多い。また，もろもろの制約でテストIDを発行できなかったり，テスト・データを作れないケースもあるだろう。そのような場合は，実際にエンドユーザーが操作する状況を見せてもらうか，画面のハードコピーを入手するなど次善の策を講じよう。
「百聞は一見に如かず」で，やはり実物を見て（できれば触って）みることは調査において効果的である。
