IT人材の必須スキル ヒアリングの技術(前編)
今回はヒアリングの技術をお伝えいたします。ヒアリングというと言葉は軽く聞こえますが、相手から情報を聞き出す事はとても難しいことです。数年前に、阿川佐和子氏が書いた『聞く力』という本がベストセラーになっていました。
これは、相手から情報を聞き出すことがいかに難しいかを実感している人が多いということのあらわれでしょう。
ITプロジェクトにおいて、IT担当者は、経営者やプロジェクトメンバなど数多くの立場の異なる方から、様々な情報を集める必要があります。
それは、業務の内容から始まり、問題や要望、そして愚痴に近い不満のようなものまで多種多様な情報が含まれます。
ITプロジェクトでは、これらの情報を漏れなく集め、整理して解決策まで導かなければなりません。ヒアリングはとてつもなく骨の折れる作業です。
優秀な営業マンはさておき、システム部門担当者やIT技術者にはヒアリングを苦手とする人が多いという事実もことを複雑にしています。
今回はヒアリングが苦手な方でも、情報を効果的に集めることのできるヒアリングの技術をご紹介したいと思います。ITプロジェクトのみならず、営業や会議など普段の仕事にも応用できる技術です。是非ご一読ください。
ヒアリングの手順
ITプロジェクトにおけるヒアリングは、次の3つの手順にて実施します。
この手順を省略すると、ヒアリングが失敗してしまうリスクが高まりますので必ずこの手順を守るようにしてください。
手順毎に順を追って解説いたします。まずは、ヒアリングの準備からです。
ヒアリングの準備を行う
ヒアリングをする際には、事前の準備が不可欠です。特に重要な点は、ヒアリングを実施する前に「相手側にヒアリングの目的や内容を事前に伝達すること」です。
相手側は事前にヒアリングの内容を把握することで頭の整理ができ、また、自分だけでは答えられないような質問事項については予め調べて準備をすることができます。
これにより当日のヒアリングは中身のある情報を聞き出すことができるようになります。
ヒアリング依頼の文章を書く
ヒアリングの依頼をする際には、必ず文書にて相手側に伝えなければなりません。また、依頼の文書もやみくもに書けば良いということではありません。記述する内容がとても重要です。
ヒアリング依頼をする際には、次のような観点を盛り込んだ依頼文を書きます。それによりヒアリング当日は中身のある情報を聞き出すことができます。次の例文をご覧ください。
例文1
* * *
ロジスティク部 担当者各位
倉庫管理システム刷新に関するヒアリング依頼
システム部 村上
■ヒアリングの背景と目的
先日の経営会議の議題にもあがりましたが、昨今の急激な売上増に伴い、ロジスティクス部門の業務負荷が異常なほど高くなっています。それにより、長時間労働の常態化や大量欠品や誤出荷などの重大事象も発生しています。
これらの問題をうけ、佐々木社長より老朽化した現行の倉庫物流システムを刷新し、現在の当社の実状に見合った倉庫物流システムの構築プロジェクトを進めるよう、システム部に指示がありました。
効果的なシステムを検討するためには、まずはロジスティクス部門における問題を把握することが重要です。しかし、システム部では現状の問題を十分に把握しておりません。
そこで、現状の問題を把握するため、日頃より実務に携わるロジスティクス部の各担当の方々にヒアリングを実施したいと考えております。
■ヒアリングしたい事項
ヒアリングに参加するメンバには「各課を代表する立場」として、「適正な労働時間内でミスの無い出荷業務を実現する」という目標を阻害している「現状の問題」について3〜5点ほどお聞きします。
そして、その問題による影響や問題の原因となっているものについてもお聞きしたいと考えております。
■留意点
・システムの問題ではなく業務としての問題をお聞かせください。
・ヒアリングに時間を割くことによる過勤務時間については中野部長に承認を得ております。
・本音をお聞かせください。
■日時と場所
7月9日(火)13:00 - 17:00(1人あたり30分)
立川ロジスティクスセンター
■お願い事項
箇条書きでも手書きでもかまいませんので、現状の問題やご意見を整理しておいて頂くようお願いいたします。
* * *
例文1の内容を順を追って解説します。
1.ヒアリングの背景と目的
ヒアリングする相手にとっては普段の業務が忙しいなか時間を割く必要があります。ヒアリングが必要になった背景と目的を書くことで、ヒアリングに協力しよう、もしくは、しなければならないという心理的な理解を得ることができます。
2.ヒアリング事項
ヒアリングの背景と目的を記述したら、ヒアリングしたい事項を書きます。その際には、次の観点を盛り込むようにしてください。
2.1.立場や視点
情報を伝える際の相手側の「立場や視点」を書くようにして下さい。例文1では「各課を代表する立場」という文言がそれにあたります。
立場や視点をお伝えしないと、問題があることは知っていながらも、自分の担当業務では無いという理由だけで情報を聞き出せない場合があります。
2.2.ヒアリングしたい内容と量
ヒアリングしたい内容と量を書きます。ヒアリングしたい内容を書く際には、例文のように「問題」だけではなく、「問題の影響」と「問題の原因」も事前に考えて頂くようにすることを推奨します。これにより中身のある情報をヒアリングで聞き出すことができます。
3.留意点
留意点を記述します。よくありがちなケースとしては、システム構築プロジェクトなので、システム機能の問題しかヒアリングできない場合があります。
これだと業務の問題を解決するために必要な情報としては不十分です。例文のように「業務の問題」をお聞きしたいという文言を付け加えることで聞き出せれる情報の量に差が出てきます。
4.日時と場所
日時と場所を書きます。この点については、特にお伝えすることはありません。
5.お願い事項
事前に準備してほしい事項を書きます。メモでもいいので、相手側に事前にまとめさせることを推奨します。相手側も文字として書くことで、頭の中が整理されます。これにより、ヒアリング当日のもれや矛盾を防止することができます。
次回はヒアリングの実施編
ヒアリングが苦手という人は、経験上、準備が足りていない方が多いという実感を持っています。準備次第で、確実にヒアリングで集められる情報に大きな差が出ます。今回ご紹介した手順にしたがって頂くことを強く推奨します。
後編では、ヒアリングの実施方法とヒアリング結果の整理方法についてお伝えいたします。ヒアリングの実施方法では、質問する技術と、話しやすい雰囲気作りの技術をご紹介いたします。
近日中に公開しますので、いましばらくお待ちいただければ幸いです。
終わり
IT人材の必須スキル 論理的な文章を書く方法
IT人材となるためには「論理的な文章を書くスキル」が不可欠です。ITプロジェクトを推し進めていくためには、たくさんの方とコミュニケーションを取ることになります。
社内なら、経営者やスポンサーへの報告、プロジェクトメンバへの依頼や指示、社外のベンダーとのやりとりなど、様々な立場の方々に対して、とにかくたくさんのメールや報告書を書くことになります。
しかし、これだけ重要な文章ですが、残念ながら「論理的でわかりやすい文章」を書ける方は非常に少ないように感じています。わかりづらい文章は、読み手に理解するまでに必要以上に労力をかけてしまいます。最悪の場合には、読み手に誤解を与えてしまい合意を得られない、さらには間違った行動を誘発してしまう危険すらあります。
文章を書くのが苦手と感じる方にとっては、いきなりハードルが高いと感じてしまった方もいらっしゃるかもしれませんが大丈夫です。あるルールに従って文章を書くことで、誰でも「わかりやすい文章」を書くことができるようになります。
ITプロジェクトで必要なのは「わかりやすい文章」であって、相手を感動させたりするような表現や、必要以上に丁寧な言葉は必要ありません。
普段の業務でメールや報告書を書く際に、これからご紹介するルールを意識しながら書くことで必ず文章力が向上します。ビジネス文書の書き方を体系的に学んだ経験の無い方は、是非ご参考にして頂ければと思います。
Ⅰ.ミントのピラミッド原理
ご紹介する文書のルールとは、「ミントのピラミッド原理」と呼ぶれているものです。マッキンゼー社のコンサルティングだった「バーバラ・ミント氏」が考案し、現在ではコンサルティング業界のデファクト・スタンダードとなっている原理です。
この原理は、文章だけにとどまりません。問題解決やプレゼンテーションにも応用されている、とても重要な基礎スキルなのです。
なにやら名前だけを見ると、とても難しい印象を持ってしまいますが大丈夫です。ひとつひとつ解説していきます。
Ⅱ.ピラミッド原理での文章の書き方
手順①導入部から書く
それではさっそく「ピラミッド原理」について具体的にご紹介していきます。最初の手順は、ストーリー形式の導入部から書き始めることです。いきなり結論や伝えたいことから書いてはいけません。
いきなりストーリ形式と言われても、イメージが付きづらいと思いますので、具体例でご説明します。
次の図表1のメール文をご覧ください。池田さんという営業担当が、提案を進めてきた〇〇商事の営業案件について問題が発生し、上司の加藤部長と佐藤課長に相談のメールをしたシチュエーションです。
図表1 導入部の無い文書例
* * *
To:kato@itprojinzai.com;sato@itprojinzai.com
from:ikeda@itprojinzai.com
加藤部長・佐藤課長
お疲れ様です。池田です。
〇〇商事向けの案件で至急対策案を検討したいのですが、会議に参加して頂けないでしょうか。議題は次の通りです。
・案件状況の共有
・リカバリープランの検討
・特価対応時の採算について
日時は、7/7 15:00を希望します。会議室はA会議室を確保しておきました。お忙しいところお手数をおかけしますがご連絡お待ちしております。
* * *
普段の業務で良く目にする形式のメール文です。ただ、このメールには読み手(加藤部長と佐藤課長)にとってはあまりにも不親切な文章です。何が問題でしょうか。
読み手は、〇〇商事案件に何が起こったのか、議題がなぜリカバリープランと特価なのかも理解できないでしょう。読み手にとっては疑問だらけの文章です。恐らく、このまま会議を実施しても、とりとめのない会議となり、十分な結果を得られずに終わるでしょう。
この場合は、次のように導入部を書くことで読み手の理解を得られやすくなります。
図表2 導入部のある文書例
* * *
To:kato@itprojinzai.com;sato@itprojinzai.com
from:ikeda@itprojinzai.com
加藤部長・佐藤課長
お疲れ様です。池田です。
先週末の営業報告で受注確実と報告していた〇〇商事向けの案件で報告です。
本日契約を締結するため〇〇商事を訪問したのですが、競合していたA社が当社よりもはるかに安い価格を同条件で提示したため、A社が最有力となっている状況です。
下期の売上目標を達成するためには、最重要案件のため、至急対策会議を実施したいのですがご都合いかがでしょうか。
議題は次の通りです。
・競合A社の提案内容の共有
・A社と差別化できる提案内容の検討
・差別化できない場合の対応(特価対応等)
日時は、7/7 15:00を希望します。会議室はA会議室を確保しておきました。お忙しいところお手数をおかけしますがご連絡お待ちしております。
* * *
図表1とは全く印象の違う文章ですね。何が違うのでしょうか。ポイントを解説しながら、導入部の書き方をお伝えしていきます。
a.読み手が知っている状況を記述する
図表2には、「先週末の営業報告で受注確実と報告していた〇〇商事向けの案件で報告です。」という状況が書かれています。先週末の営業報告とありますので、読み手が確実に知っている情報なのは間違いありません。
こうすることにより、読み手は書き手と同じ位置にスムーズに立つことができ、書き手の文章を受け入れる心の準備ができるのです。
バーバラ・ミント氏は「書き手と読み手の意見が違うかもしれないことを伝達する前に、絶対に読み手が合意するものから伝える。それは心理学的にも有効な手法だ」と述べています。
b.状況の「変化」を記述する(複雑化)
状況だけでは、既に知っている情報だけなので意味がありません。次に書くのは、状況の「変化」を記載します。ピラミッド原理ではこれを「複雑化」と表現しています。
図表2の場合における状況の変化とは、「本日契約を締結するため〇〇商事を訪問したのですが、競合していたA社が当社よりもはるかに安い価格を同条件で提示したため、A社が最有力となっている状況です。」という文章です。
ビジネスシーンの場合には、ほとんどの場合が「問題」と同義になるかと思います。
c.読み手の疑問をよく考える
なぜ、状況の変化を記述することが重要なのでしょうか。それは、状況の変化(複雑化)が起こると、読み手に「疑問」が発生するということなのです。図表2の場合、読み手に発生する疑問とはなんでしょうか。
恐らく「不利になった商談をどうやって挽回するのか?」という疑問でしょう。疑問が湧くことにより、読み手は、「答えを求めるのです」。これにより、文章へ集中ができるようになります。
d.疑問に対する答えを記述する
読み手に発生する疑問を考えたら、次はそれに対して「答え」を書きます。この答えが、「文章の主題」となります。読み手の疑問には必ず答えを返さなくてはなりません。図表2で答えにあたるものは、どの部分でしょうか。「至急対策会議を実施したい」という文ですね。
読み手の「不利になった商談をどうやってリカバリーするのか?」という疑問に対して、「至急対策会議を実施する」という答えを記述しています。
書き手である池田さんは、一般担当者のため、自分の権限を越えた決定ができないためマネージャ達の判断が必要だという事を伝えているのがわかります。
e.文章は読み手のものであることを理解する
導入部の書き方をご説明しました。導入部を書くことによって読み手の読むことに対する心理的な抵抗が下がり、理解が進むことをご理解いただけたかと思います。実は、これは読み手の理解を引き出すというよりも、書き手が「読み手のことを良く考える」というプロセスなのです。
自分のことを良く考えていてくれて大事にしてくれる人を嫌いな人はいないかと思います。文章の導入部を書くということは、相手の立場を理解し、相手の持つ疑問を考え、それに対する答えを用意するということなのです。
文章が苦手な方にある特徴のひとつに「文章を指摘されると言い訳をする」というものがあります。皆さんの周り、もしかしたらあなたも「私はこういうつもりで書きました」とか「これはこういう意味です」とか読み手の指摘に対して反論したことはありませんか。
こういう発言が出る時は、読み手の状況や疑問を全く考えていないのです。だから、読み手に伝わらないのです。ビジネスシーンにおける文章は「書き手のもの」ではありません。それを受け取って行動が必要な「読み手のもの」であることを良く理解して下さい。
手順②ピラミッドを描く
導入部が完成したら、次の手順は頂上からピラミッドを描くことです。あえて「描く」と表現している点が重要です。ここでも具体例をあげながら解説していきます。まずは、次のシチュエーションをお読みください。
図表3 図表2のメール後の会議
* * *
図表2のメールの後、池田さんと加藤部長と佐藤課長と〇〇案件の会議を実施しました。3人で、競合A社の提案内容を共有し、差別化のポイントを考え抜きましたが、どうやら差別化できるポイントはないことがわかりました。
そこで、〇〇商事の案件を受注することは、将来的なビジネスの拡大も見込めるため今回限りの思い切った特別価格対応をすることにしました。
しかし、鈴木本部長の特別価格の承認が必要であるため、佐藤課長は特別価格稟議を鈴木本部長へ提出することになりました。
* * *
この場合、〇〇商事案件が重要であることくらいしか知らない鈴木本部長へ、佐藤課長はどのような文章を書くべきでしょうか。まずは、手順①で解説した導入部がどうあるべきかを、復習として考えてみてください。
図表4 導入部のキーワード
* * *
状況:営業2課の下期売上目標達成のために〇〇商事案件の受注が必要。
複雑化:競合A社と提示価格の開きが大きく案件をロストする可能性が高くなっている(すなわち下期目標の達成が困難)。
読み手の疑問:受注するため挽回策はあるのか?
答え:提案での差別化は難しいため特価で対応する。
* * *
読み手の鈴木本部長は、営業2課には〇〇商事案件の受注が必要だということしか知りませんので状況はこのような記述になります。複雑化についてもこれで十分です。鈴木本部長がまともな数字達成意欲を持った方であるとしたら、恐らく疑問も図表4の通りになるでしょう。答えは3人で出した結論です。
文章を書きだす前にまずは、図表4のようにポイントを書き出してください。書き出した要素を十分に検討してから、導入部を文章として仕上げます。あくまでも例文なので、単純な値引きは、ビジネスとして邪道だとかいう反論はご了承下さい。
a.答えに対する相手の疑問を考える
ただ、残念ながらこれだけで「はい。わかりました」という言葉は引き出すことはかなわないでしょう。鈴木本部長には、特価対応するという答えに対し「新たな疑問」が発生しています。書き手はその新たな疑問を想定して、丁寧に答えを書かなければなりません。
まずは、読み手の「新たな疑問」を書き出します。「新たな疑問」を書き出すのには、読み手の性格や考え方を十分に考えなくてはなりません。鈴木本部長の「新たな疑問」は次の通りだったとします。
- 本当に差別化することができないのか?
- 本案件は特別価格にする価値はあるのか?
- 特別価格にする場合に最終的な利益はどうなるのか?
b.ピラミッド型の図を書く
新たな疑問を書き出したら、次のようなピラミッド型の図を「描き」ます。ここで重要なのはいきなり文章を書かないことです。どんな文章でも一旦できあがってしまうと、立派に見えてしまうからです。私はデジタルツールを使わず、手書きで次のように書いてしまいます。
このように疑問を考えたら、答えを書く、また新たに疑問がでたら、答えを書くという事を繰り返してピラミッドの図を完成させます。
c.ピラミッドの縦の関係を検証する
ピラミッドができたからと言ってすぐに文章にしてはいけません。ピラミッドの縦の箱の関係は、常に「Q&Aの対話型」でつながっていなくてはいけません。例えば、今回の例の場合だと、「本当に差別化する要素はないのか?」という疑問に対しては、①「競合他社の提案書を受領した」、②「関係者で差別化ポイントを検討した」という2つの点で答えを記述します。
d.ピラミッドの横の関係を検証する
縦の関係はQ&A形式でつなげることができますので比較的容易にチェックができますが、横の箱の関係(キーライン)は、縦の関係より頭をひとひねり必要があります。ポイントは次の通りです。
d.1.横の関係は同一のレベルであること
横の箱の関係はキーラインと呼びます。キーラインは常に同一の種類でなければなりません。極端な例ではありますが、例えば男女の違いについて述べる文章があるとします。男性と女性は同一の種類ですが、男性と子供は同一の種類にはなりません。
d.2.横の関係に漏れや重複がないこと(MECE)
横の関係に漏れや重複が存在していると、読み手にとっては「検討が足りない」ということになり理解を得ることができません。疑問に対して、答えが漏れていないか重複していないかを検証する必要があります。既にご存知の方もたくさんいらっしゃるかと思いますが、これを「MECE」と呼びます。ロジカルシンキングの基礎となる重要な考え方です。
d.3.横の数は5個以下にすること
横の数は常に5個以下でなければなりません。ピラミッド原理によると、人間は5個より多い数の情報を与えられると記憶に残りづらいという性質があります。横の数が5個より多くなるときは、d.1.で述べたように横の関係が同一のレベルになっていない可能性が高いです。コンサルタントによっては3つ以内で整理することを推奨する方も多いです。
d.4.横の関係の順序を考えること
横の関係の順序も重要です。順序を考える際には、次のようなポイントがあります。
- 時間の順序(手順など時間の順序に従うもの)
- 構造の順序(組織図や収益構造など)
- 度合(重要度)
d.5.横の関係は帰納法を用いること
演繹法よりも帰納法を用いる方が文章は簡潔でわかりやすくなります。例えば、子供のバースデイプレゼントを買う際に帰納法の場合は次のように表現します。今回のバースデイプレゼントはゲーム機を買うべきだ。なぜなら、①ゲーム機を欲しがっている、②ゲーム機は予算を満たす、③家族で楽しめるという表現になります。
演繹法の場合だと、①子供のプレゼントを買うかどうかを判断する3つの基準がある、②ゲーム機は3つの基準をみたす、③したがって、買うべきだ、④ゲーム機をバースデイプレゼントに買うべきだという表現になります。
結論はどちらも同じですが、演繹法はとてもまわりくどい表現になってしまいます。文書に慣れないうちは「帰納法的」にピラミッドを組み立てることを推奨します。
手順③ピラミッドを文章にする
ピラミッドが完成したら、後はひたすらピラミッドを文章に変換していきます。ボキャブラリーの数や表現などの差はあっても、ピラミッド構造が論理的になっていると、読み手は確実にあなたの伝えたいことを理解することができます。
文章の表現力をあげる書籍は数多くありますが、ピラミッドの基盤が崩れてしまっては意味がありません。ビジネスシーン(もちろん職業によりますが)においては、文書のピラミッド構造が「幹と枝」で、ボキャブラリーは「葉や花」という程度で理解されたら良いかと思います。
Ⅲ.思考力と問題解決力も向上する
ミントのピラミッド原理に従って文章を書くのに慣れてくると、文章力が向上するばかりではなく思考力や問題解決力も向上します。ミントのピラミッド原理は文章を書くスキルではなく、頭の中にある「もやもや」としているものを、論理的なピラミッド構造に変換するスキルだと私は理解しています。
クライアントや同僚や部下の「もやもや」しているものや「矛盾」を論理的に整理することができるようになりますし、社内や社外のあちこちに転がっている問題や課題を論理的に整理することもできるようになります。
Ⅳ.参考文献
考える技術・書く技術 作者:バーバラミント 出版社:ダイヤモンド社
- 作者: バーバラミント,Barbara Minto,山崎康司
- 出版社/メーカー: ダイヤモンド社
- 発売日: 1999/03/01
- メディア: 単行本
- 購入: 76人 クリック: 775回
- この商品を含むブログ (280件) を見る
本記事は名著「考える技術・書く技術」のピラミッドの原理に従って紹介しています。私は学生時代に本書と出会いましたが、未だに机に常に置いてあります。定期的に読み返していますが、新しい発見が今もあります。私のキャリアに最も役立った書籍のひとつです。まだ、読まれていない方は是非お読みいただければと思います。
終
ブログ開設のご挨拶
本ブログにアクセスして頂き誠にありがとうございます。本ブログは、ヒト・モノ・カネにお悩みの中小企業で働く方のために、わずかながらでも私の持っているIT関連のノウハウを提供することで、日本の中小企業に貢献したいという思いで開設しました。
私は、大手製造業系のIT会社に所属しているITコンサルタントで、大小様々の企業のITプロジェクトをご支援をさせて頂いております。
ただ、残念ながら、クライアントのITプロジェクトに携わる中で、中小企業のITに対する意識は低く、意識があったとしても決して上手く活用できていない状況を実感しております。大手企業は、IT投資により業績を伸ばしていきますが、中小企業はそうではありません。昨今ニュースで騒がれるような格差の広がりを身をもって実感しています。
厳しい経営環境の中で、思い切ってITに投資をしたけども失敗した中小企業や、誤った方向性に進んでいるプロジェクトを数多く見てきました。この理由は、質の高いIT人材のほとんどが大企業に囲い込まれており、方法論も経験も持たないシステム会社や自称コンサルタントに頼らざるをえない状況がより一層中小企業を苦しめていると私は考えています。
この状況を打開するには、「中小企業がみずからIT人材を育成すること」が唯一の答えでないかと私は考えています。中小企業からは「そんな人材を育成している時間もお金も無い」という反論が容易に予想できます。
ですが、私は「できる」と考えています。
IT人材と言うと「プログラミングができる人」と安易に結びつけてしまいますがそうではありません。「ITを経営課題と結びつけて解決案を考えられる人」が、本当に必要なIT人材だと考えています。そして私がそうだったように、きちんと体系だった理論を学べば「ITを企画する能力」は習得することができます。
ただ、著名な先生方やコンサルタントが書いた、IT企画のノウハウやビジネス書の大半は、大企業向けに書かれています。そのため、そのままでは中小企業で使うことができません。
本ブログでは数多くの企業で実践してきた手法を、実践できるノウハウとして中小企業のIT人材育成のために形にしてお伝えしていきたいと考えています。少しでも日本の中小企業が、IT化に成功する際のお役にたてることを願っています。
2019年7月
村上 光夫