Home > useful information > useful column>
Google
WWW を検索 このサイト内を検索
 
 
   

ヒアリング

ヒアリングとは何か
 ヒアリングとは要するに人の話を聞く事だが、IT業界では主に業務分析/業務設計などの工程で、顧客の要望を聞く時に使われるテクニックだ。
 如何に優秀な営業担当者や業務分析/設計者と言えども、情報システム開発のWhyとWhatを中心にした5W1H【注1】は、ある程度の誘導があるにせよ、最終的には顧客が決めなければどうしようもない。
 と言うか、その部分が曖昧なまま、当てずっぽうで独り善がりなプロダクツやソリューションを押し付けても、顧客満足につながらないことは明らかだ。
 ところが、IT業界が全体にソリューションの提供を標榜しながら、現実にはプロダクツ製品の販売が中心になって来たことで、細かな要件の調整を避ける傾向にあることから、IT事業者全般のヒアリング能力が低下しているようだ。

【注1】:1H
 ここの1Hは、Howでは無くHow muchなので間違わないようにして欲しい。
 ソリューションを請け負うIT事業者が、顧客にHowを聞いていたのでは話にならないが、コストの許容範囲は確認しないとトラブルの元だ。
 老婆心ながら付け加えると、顧客にHowの指示を受けて情報システムの構築やプロダクト製品の適用を行う場合も、WhyとWhatの確認は欠かせない。
 How・What・Whyの関係は、施策⇒目的⇒ねらい【注2】の関係になっているが、実現性や効果を十分検討しないと、施策を実施しても目的が達成できない場合や、目的は実現したがねらい通りにならない事は多い。
 もちろん、最終的にねらいが達成できない場合の責任は、システムの作りの拙さに押しつけられる事は言うまでも無いので、それらのリスクについて、顧客と事前に十分な調整を行う必要がある。
 何となく言ってる通りには成りそうも無いが、効果的な代替案も無いので取りあえず言われた通りにやってみるかと言うのでは、情報システムの専門家としては、あまりにも淋しい思考パターンだ。
 顧客の真の要求を把握して、より良いソリューションの提案が出来る知識を持ち、経験を積む必要があるだろう。

【注2】:目的・ねらい
 このコラムでは、目的・ねらいと表現するばあい、システム企画研修株式会社の方法論「Mind-SA」の用法に従っている。
 つまり、目的は施策の実施によって直接実現すること、ねらいは目的の実現で間接的に実現することと使い分けているので注意して欲しい。
 なお「Mind-SA」はシステム企画研修株式会社のホームページで公開されているが、禁無断転載となっているため詳細は直接システム企画研修社のホームページを見て欲しい。⇒http://www.newspt.co.jp/contents/manual/yes/ob/2a0e.html

ヒアリングの目的
 ヒアリングの目的は、目的達成に必要な情報を収集することだ。
 情報システムを構築するために業務要件を決めようと言う場合には、機能・ワークフロー・データ・ユーザインターフェースなど、ビジネスの中の登場し、直接ビジネスを支援する情報システムの構成要素について明確にすることになる。
 そのため、ヒアリング対象者が言うことだけでは必要な情報が不足する場合には、更に不足している情報を聞き出す必要がある。
 しかし、そもそも「何を聞き出すためにヒアリングをしているのか」と言うことが明確に認識されていなければ、必要な情報が不足していることに気付くことも出来ない。
 相手が言ったことだけ聞いて帰ったのでは子供の使いだ。
 必要な情報を聞き出すためには、上手く議論をリードし、顧客に情報不足の認識を促し、検討すべきは検討し決定すべきは決定するように誘導しなければならない。
 ヒアリング能力低下とは、一つには、この聞き出すべきこと、決めるべき事の全体像が把握できていないことに起因していることは間違い無いだろう。
 しかし、このコラムで話題にしようとしているのは、実はその部分では無い。
 聞き出すべき事のフレームワークを持つことは重要なことに違い無いのだが、相手・タイミング・目的・期間などによって様々に変化するので「此れ兵家の勢、先には伝うべからず」【注3】と言う事で、個別に経験を積むしか無く、ましてやコラムを読んで何とかなる話では無い。
 ここで話題にするのは、もうひとつの原因と考えられる想像性の欠如だ。
 分かり易く言うと、顧客自身も自分が思っているほど自分の考えている事が整理出来ていないと言うことだ。
 更に困ったことに、言語と言うものが本来持っている性質が、情報把握の難易度を一段と上げることになる。
 曖昧な顧客のイメージが、言語の特性によって更に曖昧に表現されると言う訳だ。
 これを額面通りに受け取ったのではたまったものではないが、この現象に対する対処法は簡単な訓練でスキルアップすることが可能であり、説明はコラム程度で十分なので、ここで取り上げると言う訳だ。

【注3】:此れ兵家の勢、先には伝うべからず
 孫子計編三の16節、解釈は「これが兵法家の言う勢と言うものであり、状況に応じて判断し処置するものなので、事前に伝えておくことは出来ないものだ」と言うことになる。

会話による情報交換の陥穽
 もともと人が会話する場合は、話し手の話す内容を一つ一つ言語として意味を理解していると言う訳ではない。
 多くの場合、意味不明な単語や表現を除き、断片的な情報を組み立て、過去の経験からパターンや想像で補って、相手の言わんとすることを全体的に把握すると言う処理方式で会話が進行しているはずだ。
 その中に「絶対」・「全て」・「一番」・「みんな」・「必ず」などの強調や、主語や動詞が無い表現も頻繁に使われるが、基本的に内容は聞き流しているので「全てって、本当に一つ残らず100%の全てですか」とか「それをやったのは誰ですか」などと世間知らずな質問をすることは通常あまり無い。
 これが他愛も無い世間話であれば何の問題も無いのだが、情報システムの機能や性能の話をする場合に、顧客が要求する内容を「絶対ミスの無い」とか「必ず終わらせる」「全て対応する」などと表現する場合に、そのまま真に受けると大変な事になってしまう。
 例えば「全て対応する・・・・」と言う表現を真に受けて、如何なる例外にも対応するシステムを考えるとするとコスト的に問題が起きるであろう事は容易に想像できると思うが如何か。
 また「夜間バッチは朝5時までには必ず終わらせるので・・・」を真に受けて、オンラインとバッチの並行処理の可能性を考慮していないと、制限時間超過時ににっちもさっちも行かなくなってしまう。
 このような場合は「〜のような例外処理もシステム的に対応するとかなりのコストが掛りますが、それも含めますか」とか「では、全ての構成要素を詳しく教えて貰えますか」、「万が一終わらない場合は・・・」「必ず終わらせると考える根拠は何ですか」などと必要に応じて確認することが必要となって来る。
 要するに、顧客が考えるのが面倒(または、知識や経験の不足から)で、一括りに「全て」とか「みんな」・「必ず」などと表現することを許してはならない。
 「そこは、具体的に内容の詳細を明示しておかないと、後で大変な事になりますよ」と言う事を専門家の立場から助言誘導して、顧客自身のイメージを、明確化しつつ整理する位のことはやって見せなければ業務分析者とは言えないということだ。
 このようなケースで如何に曖昧さを排除するかと言う事で、業務分析におけるヒアリングのやり方を、経験に基づいて整理する方法も有るのだろう。
 しかし、何事にも専門家と言うものは居るもので、ここではNLP【注4】と言う心理学を応用したコミュニケーション技術にある幾つかのモデル/フレームやツールを応用して、人々の言葉をより完全に理解する方法を紹介する。

【注4】:NLP
 ここでNLPについて紹介する必要がある事は認識しているのだが、私が興味を持った頃と違い、現在NLPは一種のブームになっており、色々な団体が乱立状態となっている上に根強い批判もあり、特定のサイトを紹介することがはばかられる状況なので、ホームページや書籍を利用して自分なりに理解して欲しい。
 ただ一つ付け加えると、筆者は複数団体の入門コースを体験したが、インストラクターの上手い下手の差は大きいと感じたと言うことだ。

NLPのメタモデル
 さて、ここではNLPのポピュラーなモデルの一つであるメタモデルを紹介する。
 メタモデルは、人々の使う言葉を、より完全に理解するための道具である。
 メタモデルは、通常の会話で省略されたり一般化や歪曲されることの多い表現を質問によって明らかにする。
 表にメタモデルを一覧で説明する。
   処理パターン    一般的な質問パターン
 省略のメタモデル   明確化要素  
 1  不特定名詞の省略
(抜けている物)
 誰が・どれが・何がを具体的に  「認識の相違だ」⇒「誰と認識が違うのですか」・「どのように認識が違うのですか」
 2  不特定動詞の省略
(抜けている動作)
 何がどのように、具体的に  「私は分かりません」⇒「どのように分からないのですか」・「何が分からないのですか」
 3  比較対象の省略
(抜けている比較)
 何と(誰と)比較して  「もっと頑張る」⇒「誰とくらべてもっとですか」・「具体的にはどれくらい頑張るのですか」
 4  判断省略
(抜けている根拠)
 誰がそう言うのですか、何を基準に〜と判断したのですか  「当社の情報部門は積極性が足りない」⇒「誰がそう判断したのですか」・「何を根拠にそ判断したのですか」
 5  名詞化  誰が、どのように、何について  「会社での人間関係が問題です」⇒「会社の誰の関係ですか」・「どのように問題なのですか」・「人間関係の何が問題なのですか」
 一般化のメタモデル  表現の特徴  
 1  可能性の一般化
(抜けている結果)
 出来ない、言えない、断れない  「敢えてそれをすると(しないと)どうなりますか」・「何があなたをそうさせる(させない)のですか」
 2  必要性の一般化
(抜けている結果)
 べき、べからず、しなければならない  「そうする(しない)と、どうなりますか」・「もし、あなたがそれをしたら(しなかったら)どうなりますか」
 3  普遍的一般化
(抜けている例外)
 全て、いつも、みんな、決して〜ない  「〜でない○○は、一人もいなかったのですか」・「〜は、一度もなかったのですか」・「もし〜があるとすれば、どんな場合がありますか」
 歪曲のメタモデル  歪曲のパターン  
 1  等価の複合概念  あなたは○○だ。だからあなたは××だ。  「どうして○○が××を意味するのですか」・「なぜ○○だと××だと思うのですか」・「○○と××の関係はなんですか」
 2  前提  隠された前提の存在  「なぜそう思うのですか」・「何があなたにそう信じさせたのですか」・前提は他のメタモデル(比較対象の総略など)を持っていることが多い
 3  因果  「XはYの原因である」と言う間違った関係  「Xが、具体的にはどのようにしてYの原因になっているのですか」・「Xが原因でないとすると、Yはどうなっていなければならないのでしょうか」
 4   読心術   人の考えが分かっていると思い込む  「あの顔つきは私を嫌っている顔だ」⇒「一体どのようにして、それが分かるのですか」・「何でそれが分かりましたか」
 人が自分の考えを知っていると思い込む  「なぜ分かり切ったことが出来ていないんだ」⇒「そのことは伝えましたか」・「なぜそれを分かっていると分かったのですか」
 以上、言語による情報伝達の不備不足をメタモデルに当てはめて、適切な質問を行うことで不足する情報を補う訳だ。
 なお、このモデルは言語による情報交換一般を対象としているので、情報システム開発におけるヒアリングだけでなく、システム監査のヒアリング、問題や原因などに関する分析、会議や各種打ち合わせなどに幅広く応用可能である。
 また、組織的にこれらの取り組みを進めることで、情報システムを構築する場合に必要となる情報整理のレベルが明らかとなり、標準・基準として定着するので、是非、組織の共通基盤スキルとして活用して欲しい。

その他の注意点
 ここまで(それ以前の工程も含めて)業務分析/業務設計段階までに行うべき作業としてヒアリングの実践的な方法を紹介して来たが、業務要件全体として考えれば、特に機能要件部分に於いてヒアリングで取得しなければならない情報はあまり多くは無い。
 基本的に情報システムの機能要件は、現行ビジネスおよび現行情報システムの分析から把握可能なので、改めてヒアリングで取得しなければならない情報は、新システムから追加を計画している機能や、このタイミングでビジネス自体を再構築しようとしている部分、つまり、現行のビジネスや情報システムからの変更点に限って考えれば良い。
 また、ビジネス自身の変化は、情報システムを再構築するからと変わるわけでは無く、環境変化や企業の戦略の変化と共に、変わって行くものなので、先を見越したとか、将来計画を前倒しにしたなどと必要性の見極めも付いていない機能を当てずっぽうに盛り込むのは止めた方が良い。

 以上、ヒアリングは単に話を聞けば良いと言う訳ではないと言う事を分かったと思う。
 こうやって文章で書くと、難しく見えるが、慣れれば自然に情報不足を補完する質問が出るようになるので心配ない。
 また、トレーニングにはISMSやPマークの監査、又はシステム監査などの経験が効果的だが、先入観を持って誘導するような事の無いように注意も必要だ。