Yahoo! JAPAN

こんにちは、しんざきです。

最近職場に知らない人が増えて、仕方ないから手当たり次第に挨拶していたら、いつの間にか隣接オフィスの別会社の人にも高頻度で挨拶してしまっていたらしく、明確に別会社だと分かる人からも挨拶されるようになってしまいました。絶対謎の挨拶妖精おじさんだと思われている。つらい。

この記事で書きたいことは、以下のようなことです。

・会社の先輩に教わったことですが、会話で情報を伝えるのが苦手な人には、大きく分けて三つのタイプがあるようです

・その三つとは、「情報量が足りていない人」「情報量が多すぎる人」「情報のつなげ方が適切でない人」です

・きちんとタイプを把握した上で話を聞くと、情報の取捨選択をして適切なレスポンスを返せる可能性があります

・情報量が足りていない人には、明確な「聞きたい項目」を提示するのが比較的有用です

・情報量が多すぎる人には、防御線の不要と取捨選択の基準を明示することで改善する場合があります

・情報のつなげ方がおかしい人は、テンプレートを用意するか、答え方を限定した会話を繰り返すことで改善することもあります

・情報の伝え方は練習で改善するものなので、(助言出来るような関係性であれば)助言すれば改善する可能性もあります。新人指導で重要です

・情報伝達はとても大事なので、新人さんに適切な指導が出来ると嬉しいですよね

以上です。よろしくお願いします。

さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。

しんざきは昔、とあるシステム開発の会社に所属しておりまして、いくつか開発案件も経験したんですが、その際客先常駐になったことが何度かありました。

どうも「多少荒れた現場に放り込んでもストレスでぶっ倒れたりはしないヤツ」と認識されていた節があり、技術力もないのにわけが分からん炎上案件に放り込まれて、鉄砲玉のように客先の喫煙室に突入しては、文字通り煙たがられながら色んな話を聞き出していました。

当たり前の話ですが、受注開発案件では「顧客とのスムーズな情報のやり取り」がとても重要です。

そして、そのためには、「相手先企業とどうでもいいような会話が出来る関係性」が案外大事だったりします。

もちろん要件定義やら運用整理やらで、きちんとしたヒアリングやレビュー会も行うんですが、それだけで細大漏らさず必要な情報が整理出来れば誰も苦労はしません。

情報の抜け漏れは必ず、間違いなく、絶対に発生するもので、「あれ、この要件どうなってんの？」とか「そもそもこの運用抜けてない？」みたいな話が思いもよらないタイミングで飛び出して、大事故になって数人の死者が発生することは全く珍しくありません。

それを察知して事前に対処するためには、可能な限り色んなルートで情報経路を確保して、色んな人と情報をすりあわせておかなくてはなりません。

埋もれた情報というのは、正規ルートに乗らないからこそ埋もれているのであって、ヒアリングを何度重ねても埋もれたままです。網から漏れた情報をキャッチするには、「なんか知らんけどいつも話しかけてくるヤツ」という程度でも、とにかく顔を売っておくことがとても重要です。

そういう意味で、あの頃の私が「なんなんだこいつは」という顔をされながら色んな人に話しかけていたのも、何ほどかの意味はあったのでしょう。当時は右も左も分からず、他にやることもないからひたすら話を聞き回っていただけでしたが。

さて。

とある案件で、私は業務システムのワークフローについて、当時私がいた会社でいう「裏取り」を試みていました。

要件定義で整理した要件について、重大なずれや漏れがないかどうか、直接要件定義に携わっていない色んな人にヒアリングしてみる、という仕事です。これ自体は雑談というわけではなく、ちゃんと要件定義の業務内で行っていました。

その中で感じたことは、「話が分かりやすい人と分かりにくい人がいるなあ」ということでした。元々の私の聞き方が悪いということももちろんあるんですが、同じ質問をして返ってきた話をメモってみても、ちゃんと中身が分かる情報になることと、なんだかよくわからない情報になることがありました。

「聞いた話は取り敢えず全部メモって持ってこい」と言われていたので、当時コンビを組んでいた先輩のところに、何も考えずに持っていきました。

先輩はメモをちょっと見て、すぐ「相手によって質問の仕方を変えよう」と言いました。

「この人には多分、事前にアンケート項目みたいな感じで聞きたいことを整理して伝えた方がいい」

とか、

「この人は、色々話が発散してそれはそれで有益だから、項目は制限しない方がいい、けど業務整理の進み具合と、飽くまでインタビューであってそれ自体が要件になるわけじゃない、ってことは最初に共有しておいて」

とか、

「この人はちょっとノンテーマで話聞くの難しいかも。業務は分かってる人っぽいから、yes/noで確認出来る質問だけ用意して持っていこう」

とか。

先輩の方針に沿って質問すると、最終的には大体の人からちゃんと「整理された情報」を得られたので結構びっくりしました。

どうやってメモだけで区別出来るのか、あとから先輩に聞いてみました。

「ヒアリング山ほどやってると大体分かるよ、そういうの」

「でも、現場によって聞く内容って全然違いますよね？共通のノウハウとかあるんですか？」

と聞いてみると、ちょっと考えてからこんな話をしてもらえました。印象的な話だったので、今でも大体覚えてます。

「情報を伝えるって難しいことだから、当然苦手な人もいる。でも、ただ「苦手」ってだけじゃなくて、ざっくりと傾向別に分類出来る。

大雑把に言うと

「(1)情報量が足りない人」

「(2)情報量が多すぎる人」

「(3)情報と情報のつなげ方がおかしい人」」

「(1)の人は、伝えるモチベーションが低いか、どんな情報が必要なのかが分からないから聞かれたことだけ答える、ってパターンが多い。だから、「どんな情報が必要なのか」をある程度限定して、伝達のコストを下げてあげる必要がある。情報は発散しなくなっちゃうけど、アンケート項目みたいな形で一旦絞っちゃうのがいい」

「(2)の人は、伝えるモチベーションは高いけど情報の取捨選択が苦手なのか、あるいは「誤解を与えないように」って意識が強すぎて前提や防御線を張り過ぎちゃう人か。こっちは「気付いてないこと」について知りたいわけだから、色々出てくるのはむしろありがたい。ただ、防御線ってあんま有益な情報じゃないことが多いから、「防御線不要」ってことは事前に納得してもらった方がいいし、「ここまでは知ってる」ってことは最初に伝えるのがいい。そうすると情報の取捨選択がしやすくなる」

「(3)の人は色んなパターンがあって難しい。元々話があっちこっち飛びやすい人か、頭の中では話がちゃんとつながってるんだけど接続のための情報が漏れちゃう人か。こっちが知らない前提を知ってるものと思い込んで話しちゃう、ってパターンもある。遠慮なく話せる関係性なら、話の優先順位をテンプレートにしてすりあわせるのがいいんだけど、客先だとそうもいかないから、yes/noのQA形式にした方が混乱しないかな」

ははーー、と思ったわけです。

ちなみにこの時は、ものの見事にでかい業務要件が一個丸々漏れていました。簡単に言うと、通常の処理とは別に、ある条件では例外フローで業務を処理しなくてはならず、その時参照するDBが別システム上にあるのに、要件定義の担当者がその条件分岐自体を知らなかった、みたいな感じです。

後から判明すると即死する類いのヤツなのですが、上で言う(3)の人へのヒアリングから「なんかおかしいぞ？」というのが判明して、深掘りした結果発見出来た要件でして、「裏取り」が功を奏したサンプルになりました。

この助言のおかげで、というだけでもないんですが、その後も色々ありつつ案件はなんとか無事に収束しまして、私は以降も色んな現場でこの先輩と一緒になり、色々教えてもらいながら仕事をこなしていきました。

そのあと、色んな現場・職場を経験して、同じような分類を何度も試して、この時の先輩の話ってかなり普遍的な話だったのかもなあ、と思うようになりました。

なんだか情報のやりとりが上手くいっていないな、と思った場合、自分か相手のいずれか、あるいは両方が、「情報量不足」「情報量過多」「論理展開がおかしい」のどれかに大抵当てはまっているんですよ。

分かってみると自分で訂正することも出来ますし、「この人はこういう傾向があるから、こう対応すると上手く意思疎通しやすいな」という対応もある程度は出来るようになります。

情報の伝え方って根本的なことなので、他人から指摘して改善するようなものでもないんですが、新人さんの指導の場のような「ノウハウを教えるべき場」では上記のような話を伝えることもあります。

やっぱり、仕事をする上で「きちんと情報を伝えるためにはどうすればいいか」ってとても重要なノウハウですし、その際「言葉足らずになりがち」とか「防御線を張り過ぎ」みたいな自分の傾向を知っておくことも、ある程度役には立つと思うんですよ。

ここ最近は特に、昔以上に新人さんの指導役になる機会が多くなっているので、折りに触れてこの「タイプ別処方箋」の話をします。それと同時に、自分の話がうまく伝わってないな、と思う時は、この三つのどれかに当てはまっていないか考えてみるといいかも、というような話もします。

先輩からのただの受け売りですが、こういうのがノウハウとして誰かに伝わっていくのも、お世話になった恩返しとしては悪くないんじゃないかと。

新人の皆さんが、ちょっとでもこういうノウハウのいいとこ取りをして、いい感じで仕事をこなしていってくれるようになるならありがたいことだなあ、と、そんな風に考える次第なのです。

今日書きたいことはそれくらいです。

***

【著者プロフィール】

著者名：しんざき

SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。

レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。

ブログ：不倒城

Photo：Buddha Elemental 3D