前回，業務要求の調査対象は「エンドユーザー」「ドキュメント類」「現行システム」の三つであると述べ，主にドキュメント調査について解説した。今回は，エンドユーザー・ヒアリングを中心に説明していく。エンドユーザー・ヒアリングとは文字通り，実際にシステムを使っている（新しく構築するシステムもメインユーザーとして使うことを予定している）人たちに，業務内容やシステムの利用状況，現行のシステムに関する不満や意見，新しいシステムに求める要望（以下，「ユーザ－要望」とする）などを直接聞き取ることである。
（1）業務内容
・どんな業務を行っているのか
・業務のどの部分にシステムを使っているのか
（2）現行システムへの不満
・使い勝手への不満
・業務との食い違いへの不満
（3）新システムへの要望
・上記の不満がどのように解消されることを望んでいるのか
・不満解消とは別のまったく新たな要望
エンドユーザー・ヒアリングには，上記とは別に，実はもう一つ大きな目的がある。それは「根回し」である（図1）。システムを新しく導入したり，再構築したりすると導入当初はエンドユーザーから多くの不満がでてくるものだ。「前のシステムの方がよかった」「メニューが分かりにくい」「自分が期待していた機能がない」といったたぐいのものだ。もちろん新システムの出来が悪く，バグだらけというのは論外であるが，完成度が高くても文句はいろいろと出てくる。完成度が高いのに不満が多いのは以下の理由であることが多い。
・自分は聞いていない（自分に要望を聞くことなく，知らないうちにシステムが作られた）
・自分の要望が何の説明もなしに却下されている（できないならできないと理由を言ってほしい）
エンドユーザーに当事者になってもらう
このような不満を回避するためには，事前になるべく多くのエンドユーザーをシステム構築の「当事者」としておくことだ。エンドユーザー・ヒアリングを行うことで，「自分は聞いていない」という不満の多くは防止できる。また，ヒアリングに協力してもらったお返しではないが，要件を取りまとめた後に，システム化対象から外した要望に関しては理由（予算や優先度の制約，あるいは代替案提示や次フェーズ回しなど）をつけて早めに説明しておけば，後々大きな不満となることは少ない。
システム構築が失敗する一つのパターンとしてエンドユーザー部門と情報システム部門のコミュニケーションが少ない場合がある。エンドユーザーは「システム部は業務の事など何も分からず，分かろうともしない」，システム部は「エンドユーザーはいつも文句ばかり言っている。少しはITを勉強しろ」。このような状況では両部門のコミュニケーションは極めて少なく，エンドユーザーヒアリングに関しても特にシステム部門がやりたがらないことが多い。これでは良いシステムは構築できない。
エンドユーザー・ヒアリングは，大きく分けて次の三つのやり方がある。
（1）インタビュー
個人または数人のエンドユーザーに対して，質問を重ねて要求の聞き取りを行う。
（2）ブレーン･ストーミング
数人のエンドユーザーを対象に，KJ法などの手法を使って，要求の洗い出しを行う。
（3）アンケート
多数のエンドユーザーを対象に，システムや紙によるアンケートを実施し，要求を拾い上げる。
それぞれのヒアリング方法の特徴を図2にまとめておく。
