ITエンジニアにとってヒアリングとは，ユーザーとのコミュニケーションの根幹を成す。難しい合意形成の成否も，聞き方一つで大きく変わる。
第一線で活躍するIT エンジニアやコンサルタントが現場で培ったヒアリングのテクニックをまとめた。
日本ヒューレット・パッカード（HP）の伊吹進吾ITコンサルティング本部エクスプレスサービス部コンサルタントは，ヒアリングに関する苦い経験を忘れられないでいる。
5年前のこと。当時，キャリア3年目で，技術力に自信を持ち始めていた伊吹氏は，得意先のユーザー企業A社に足を運んだ。ユーザーの要求を踏まえて策定したサーバー構成案に関して，意見をヒアリングするためだ。
伊吹氏は自信をもって案を説明したが，システム部門のキーパーソンの1人であるB氏は受け入れず，「別の案も検討すべき」とその説明を始めた。説明を聞くうちに伊吹氏は「自分の案の方が良い」と確信。B氏の話を途中でさえぎって論破し，案を引っ込めさせた。
その後しばらくたったころ，伊吹氏は「B氏に避けられている」と感じ始めた。以前のようにB氏が相談を持ちかけてくることがなくなったのだ。A社の担当である伊吹氏にとって，見過ごせない事態だった。悪い予感は的中した。A社の担当ではない同僚のSEに「B氏から新しい案件の相談を受けた」と聞かされたのだ。B氏に見限られたことは，明白だった。挫折感と精神的な重苦しさが，伊吹氏にのしかかった。
伊吹氏は「B氏の案をきちんと聞いたうえで話し合っていれば」と後悔したが，後の祭り。B氏の信頼を再び得ることはできなかったという。
単なる情報収集だけではない
伊吹氏は優秀な若手として社内で一目置かれる存在。それでも，過去に冒頭のような失敗をした。今回の特集ではヒアリング力の評価が高いITエンジニア約20人に取材したが，大半は伊吹氏のような失敗経験を持っている。
例えばフューチャーシステムコンサルティングの稲垣哲也プロジェクト統括本部アシスタントマネジャーは，あるユーザーが「従来の帳票も必要」と言うので新システムの要件に加えたところ，あとで別のユーザーからこう責められた。「少し考えれば全く必要ないことぐらい分かるだろう。どうして，従来の帳票が必要な理由をしっかり聞かなかったんだ！」──。稲垣氏は「ユーザーの言うことをただ聞くだけでは，ITエンジニアとしての付加価値はないことを学んだ」という。
「ヒアリングは，ユーザーとのコミュニケーションの根幹。奥が深く，極めて高度なスキルが要求される」。ベテランのITコンサルタントであるプロバインズの高柳剛宏 社長はこう指摘する。
ITエンジニアにとって，ユーザーへのヒアリングとは，「単に情報を収集する」ことではない。ユーザーの本音を引き出して隠れた課題を掘り起こし，協力を取り付けて合意形成するプロセスそのものなのだ。ここに，ヒアリングの難しさがある。
しかも近年，「ITエンジニアに要求されるヒアリング・スキルの水準はますます高まっている」（ITエンジニアのコミュニケーション技法を研究している富士通研究所の石垣一司 パーソナルシステム研究センター主幹研究員）。その原因は，業務に精通したユーザー企業の社内SEが減った，ヒアリングに費やせる期間が短くなった，プロジェクトの利害関係者が増えた，などいくつもある（図1[拡大表示]）。こうした傾向は今後も続くだけに，ヒアリング・スキルの重要性はますます増していくはずだ。
この特集では，第一線のITエンジニアやコンサルタントが培った，システム企画と要件定義フェーズにおけるユーザーへのヒアリングの実践ノウハウをまとめた。「準備」と「実施」という二つのフェーズに分けて見ていこう。
ヒアリングの準備で最も重要なのは，目的を明確化することである。「事前に目的を明確化しておかないと，準備が不十分になり，成果が上がらない」（日立製作所の水田哲郎 ビジネスシステムコンサルティング部長 上席コンサルタント）。目的を明確にするのは当たり前に思えるかもしれないが，「不十分なままヒアリングに臨むエンジニアは案外多い」（同）。
水田氏によれば，ヒアリングの目的は大きく二つに分けられるという。一つは，情報を収集すること。もう一つは，その情報を基に策定した案（仮説）をユーザーにレビューしてもらい合意形成することである。システム企画，要件定義などの上流工程は，この「情報収集」と「（仮説に対する）合意形成」を繰り返すことで進んでいく。
ヒアリングの目的が「情報収集」の場合と「合意形成」の場合では，準備すべき作業は変わってくる注1。「情報収集」の場合はヒアリング項目のリスト作成が不可欠になる。これに対して，「合意形成」では仮説の立案とその妥当性を判断する材料の用意が重要だ。
以下では，(1)ヒアリング項目のリスト作成，(2)仮説立案と判断材料の準備，(3)ヒアリング対象者の人選，(4)ヒアリング対象者への通知，という主要な準備作業ごとに，注意すべきポイントを紹介していこう。
ヒアリング項目のリストは，社内標準のシート，上司や同僚が作成したもの，自分で作成したものなど，いくつも存在するはずだ。ここでぜひ，取り組みたいのは「工程ごとに既存のリストをかき集めて突き合わせ，“いいとこ取り”をすること」（日本HPの大沼康二コンサルティング・インテグレーション統括本部マネージドサービス本部ビジネス開発推進本部ビジネス開発第一部PMP）。そうすることで，より良いリストになる。
工夫したリストの一例として，NTTデータが策定した「プロジェクトの根本目的を考えるためのヒアリング項目」を図2[拡大表示]に挙げた。図中の「課題は何か？」と「課題がどう解決されていると嬉しい？」という二つの項目が根本目的の候補となる。さらに，この二つだけを聞くのではなく，「解決すると嬉しい人」や「解決策を実行する人」など関連の深いリスト項目も加えることで，内容を深く掘り下げるようにしている。
ここで社内標準や他者が作ったリストを参考にする際に，気を付けるべきことがある。それは「ヒアリング項目一つひとつについて，それが何のために存在するのか理解すること」（製造業向けのITコンサルティング会社，ネクステックの斎藤隆弘 執行役員ビジネス変革推進部マネージングディレクター）である。
ヒアリングで収集する情報注2は，業務プロセスや機能要件などに関する案の策定（仮説立案）に必要である。つまりヒアリング項目はすべて，なんらかの「成果物」（業務プロセス図や機能要件一覧など）とリンクしているわけだ。
このことを考えずただシートを埋めていくだけでは，「材料が不足し，そのユーザーにとって適切な案を策定できない」（ソフトウエア開発会社，エスエムジーの浅川治 チーフテクニカルコンサルタント）。
ここでは案の策定（仮説立案）の詳しい方法には踏み込まないが，ユーザーへの案の提示の仕方に関して準備しておくポイントを二つ挙げる。
一つは，たとえベストな案が分かっていても，できる限りそれ以外の案も用意することだ。「ユーザーにとっては，一つだけ示された案の良しあしを判断するよりも，いくつかの選択肢から選ぶ方が納得感が生まれやすい」（東京海上日動システムズの山中吉明 営推・損害ソリューション本部損害ソリューションサービス部ソリューションプロデューサー）からである。
案を複数用意する場合は，必ずそれらを比較できる判断材料も準備する。「ユーザーが判断しやすいように，メリット・デメリットという形で一覧表を作成する」（同）のも良い方法だ。
もう一つのポイントは，策定した案に関して，ヒアリングの場でユーザーからどんな質問や意見が出るか，シミュレーションしておくことである。策定した案に対する合意形成を図るには，ユーザーから活発に質問や意見が出た方が望ましい。とは言え質問を受けてしどろもどろになっていては，ユーザーからの信頼を失いかねない。そこで重要なのが，ユーザーからの質問と応対のシミュレーション，というわけだ。
どんな質問が出るか予測するのは簡単ではない。ただし案を策定する過程で，自分なりに自信がある部分とない部分は分かるはずだ。そこで最低限，「自信がない部分については，上司のレビューを受けるなどして念入りにどんな質問がくるか考えておく」（日立製作所の水田氏）ことが重要である。
ヒアリング対象者の人選の条件は，目的が「情報収集」と「合意形成」のどちらかによって異なる。
「情報収集」であれば基本的に，関係する部署の業務全体を理解している実務的なリーダー，現場の社員，さらに必要に応じて決裁権を持つキーパーソンまで幅広くヒアリングするほうがいい。
一方「合意形成」が目的なら，ヒアリングすべきは関係するキーパーソンである。ただし，キーパーソンは社内規定上の決裁権を持つ人だけとは限らない。「決裁権を持っている人が，特定の部下の意見に基づいて決めているケースも少なくない」（IBMビジネスコンサルティング サービス＝IBCSの大竹伸明 パートナー）ためだ。逆に決裁権が形骸化していて，上司や他部門の管理職の了承がないと決められないケースもある。そのため形式的な決裁権をうのみにせず，実質的なキーパーソンを洗い出す必要がある。
実質的なキーパーソンの特定は簡単ではないが，工夫次第で策はある。例えば，IBCSの大竹氏は「このままでは間に合わないと意思決定を強く迫ったときに，決裁権者が誰のところに相談に行くかアンテナを張って調べる」（大竹氏）という。
最後にヒアリング対象者への通知方法に触れる。ヒアリングのための会議をメールなどで通知する際には，日時，場所，参加者などの基本事項に加えて，ヒアリング（会議）の目的，ヒアリング項目のリスト，各自に準備してほしいことも記載する。
加えて，初めてプロジェクトの会議に参加する人には，プロジェクトの「根本目的」も知らせるべきだ。「忙しい仕事のなか時間を割いてヒアリングに協力してもらうだけに，モチベーションを高めるためにも，プロジェクトの根本目的を示すことが欠かせない」（日本ユニシスの小早川泰彦 ビジネス・イノベーション・オフィス テクノロジ・コンサルティング・ユニット統括パートナー）。
もちろんそのためには，あらかじめプロジェクトの根本目的を明確にしておく必要がある。プロジェクトの根本目的があいまいな場合は，「改めてプロジェクトのオーナーである経営層や管理職に会い，プロジェクトを立ち上げた背景や狙いを具体的に聞いて整理し直す」（日立製作所の水田氏）。
もう一つ，初めて参加してもらうユーザーのモチベーションを高めるため，やるべきことがある。それは，「なぜあなたに聞きたいのか，協力することであなたやあなたの所属部署にどんなメリットがあるのか，というメッセージも記載する」（コンサルティング会社，ジェネックスパートナーズのコンサルタントである長尾朋子氏）ことだ。例えば，次のように通知する。
○○部長から，販売管理業務に精通なさっており，現行業務の課題について十分なご認識のうえにご意見をくださる方としてご紹介を受けました。販売管理部の方のご意見を伺うことが，販売管理部にとっても有益なシステムの構築につながると考えております。お忙しいとは思いますが，ぜひご協力ください。
こういう個別の文面を作るのは手間がかかるが，重要なユーザーに対しては必ず送っておきたい。
ここからは，ヒアリングの現場でのノウハウに入っていく。
目的が「情報収集」と「合意形成」のどちらでも，ヒアリングの冒頭では，雰囲気を和ませておきたい。いわゆる「アイスブレーク」である。特に初対面のときは，いきなり本題に入ると，最後まで無用な緊張感が続きかねない。そこで「天気や景気，ニュースなど話題は何でもよいので，最初に少し雑談する」（野村総合研究所の増田有孝 経営システムコンサルティング部長）。話し下手な人でも，事前に話題を考えておけば，決して難しくないはずである。
場が和んだら，メールで伝えた「プロジェクトの根本目的」や「ヒアリングの目的」「なぜあなたなのか」について改めて話す。そのうえで「何を聞きたいのか」を説明する（図3[拡大表示]）。
ただし，「どういう視点に立った意見や情報をどれだけ詳しく聞きたいのか」をユーザーに理解してもらうのは容易ではない。そこで，「プロジェクト全体の工程表を示し，『今日はここの部分に関して聞きたい』と説明する」（設計支援ツールなどのベンダーであるチェンジビジョンの平鍋健児社長）。あるいは「ヒアリング後に作成する成果物（ドキュメント）のサンプルを見せて，聞きたいことの具体的に説明する。
