こんにちは、しんざきです。
最近職場に知らない人が増えて、仕方ないから手当たり次第に挨拶していたら、いつの間にか隣接オフィスの別会社の人にも高頻度で挨拶してしまっていたらしく、明確に別会社だと分かる人からも挨拶されるようになってしまいました。絶対謎の挨拶妖精おじさんだと思われている。つらい。
この記事で書きたいことは、以下のようなことです。
・会社の先輩に教わったことですが、会話で情報を伝えるのが苦手な人には、大きく分けて三つのタイプがあるようです
・その三つとは、「情報量が足りていない人」「情報量が多すぎる人」「情報のつなげ方が適切でない人」です
・きちんとタイプを把握した上で話を聞くと、情報の取捨選択をして適切なレスポンスを返せる可能性があります
・情報量が足りていない人には、明確な「聞きたい項目」を提示するのが比較的有用です
・情報量が多すぎる人には、防御線の不要と取捨選択の基準を明示することで改善する場合があります
・情報のつなげ方がおかしい人は、テンプレートを用意するか、答え方を限定した会話を繰り返すことで改善することもあります
・情報の伝え方は練習で改善するものなので、(助言出来るような関係性であれば)助言すれば改善する可能性もあります。新人指導で重要です
・情報伝達はとても大事なので、新人さんに適切な指導が出来ると嬉しいですよね
以上です。よろしくお願いします。
さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。
しんざきは昔、とあるシステム開発の会社に所属しておりまして、いくつか開発案件も経験したんですが、その際客先常駐になったことが何度かありました。
どうも「多少荒れた現場に放り込んでもストレスでぶっ倒れたりはしないヤツ」と認識されていた節があり、技術力もないのにわけが分からん炎上案件に放り込まれて、鉄砲玉のように客先の喫煙室に突入しては、文字通り煙たがられながら色んな話を聞き出していました。
当たり前の話ですが、受注開発案件では「顧客とのスムーズな情報のやり取り」がとても重要です。
そして、そのためには、「相手先企業とどうでもいいような会話が出来る関係性」が案外大事だったりします。
もちろん要件定義やら運用整理やらで、きちんとしたヒアリングやレビュー会も行うんですが、それだけで細大漏らさず必要な情報が整理出来れば誰も苦労はしません。
情報の抜け漏れは必ず、間違いなく、絶対に発生するもので、「あれ、この要件どうなってんの？」とか「そもそもこの運用抜けてない？」みたいな話が思いもよらないタイミングで飛び出して、大事故になって数人の死者が発生することは全く珍しくありません。
それを察知して事前に対処するためには、可能な限り色んなルートで情報経路を確保して、色んな人と情報をすりあわせておかなくてはなりません。
埋もれた情報というのは、正規ルートに乗らないからこそ埋もれているのであって、ヒアリングを何度重ねても埋もれたままです。網から漏れた情報をキャッチするには、「なんか知らんけどいつも話しかけてくるヤツ」という程度でも、とにかく顔を売っておくことがとても重要です。
そういう意味で、あの頃の私が「なんなんだこいつは」という顔をされながら色んな人に話しかけていたのも、何ほどかの意味はあったのでしょう。当時は右も左も分からず、他にやることもないからひたすら話を聞き回っていただけでしたが。
さて。
とある案件で、私は業務システムのワークフローについて、当時私がいた会社でいう「裏取り」を試みていました。
要件定義で整理した要件について、重大なずれや漏れがないかどうか、直接要件定義に携わっていない色んな人にヒアリングしてみる、という仕事です。これ自体は雑談というわけではなく、ちゃんと要件定義の業務内で行っていました。
その中で感じたことは、「話が分かりやすい人と分かりにくい人がいるなあ」ということでした。元々の私の聞き方が悪いということももちろんあるんですが、同じ質問をして返ってきた話をメモってみても、ちゃんと中身が分かる情報になることと、なんだかよくわからない情報になることがありました。
「聞いた話は取り敢えず全部メモって持ってこい」と言われていたので、当時コンビを組んでいた先輩のところに、何も考えずに持っていきました。
先輩はメモをちょっと見て、すぐ「相手によって質問の仕方を変えよう」と言いました。
「この人には多分、事前にアンケート項目みたいな感じで聞きたいことを整理して伝えた方がいい」
とか、
「この人は、色々話が発散してそれはそれで有益だから、項目は制限しない方がいい、けど業務整理の進み具合と、飽くまでインタビューであってそれ自体が要件になるわけじゃない、ってことは最初に共有しておいて」
とか、
「この人はちょっとノンテーマで話聞くの難しいかも。業務は分かってる人っぽいから、yes/noで確認出来る質問だけ用意して持っていこう」
とか。
先輩の方針に沿って質問すると、最終的には大体の人からちゃんと「整理された情報」を得られたので結構びっくりしました。
どうやってメモだけで区別出来るのか、あとから先輩に聞いてみました。
「ヒアリング山ほどやってると大体分かるよ、そういうの」
「でも、現場によって聞く内容って全然違いますよね？共通のノウハウとかあるんですか？」
と聞いてみると、ちょっと考えてからこんな話をしてもらえました。印象的な話だったので、今でも大体覚えてます。
「情報を伝えるって難しいことだから、当然苦手な人もいる。でも、ただ「苦手」ってだけじゃなくて、ざっくりと傾向別に分類出来る。
大雑把に言うと
「①情報量が足りない人」
「②情報量が多すぎる人」
「③情報と情報のつなげ方がおかしい人」」
「①の人は、伝えるモチベーションが低いか、どんな情報が必要なのかが分からないから聞かれたことだけ答える、ってパターンが多い。だから、「どんな情報が必要なのか」をある程度限定して、伝達のコストを下げてあげる必要がある。情報は発散しなくなっちゃうけど、アンケート項目みたいな形で一旦絞っちゃうのがいい」
「②の人は、伝えるモチベーションは高いけど情報の取捨選択が苦手なのか、あるいは「誤解を与えないように」って意識が強すぎて前提や防御線を張り過ぎちゃう人か。こっちは「気付いてないこと」について知りたいわけだから、色々出てくるのはむしろありがたい。ただ、防御線ってあんま有益な情報じゃないことが多いから、「防御線不要」ってことは事前に納得してもらった方がいいし、「ここまでは知ってる」ってことは最初に伝えるのがいい。そうすると情報の取捨選択がしやすくなる」
「③の人は色んなパターンがあって難しい。元々話があっちこっち飛びやすい人か、頭の中では話がちゃんとつながってるんだけど接続のための情報が漏れちゃう人か。こっちが知らない前提を知ってるものと思い込んで話しちゃう、ってパターンもある。遠慮なく話せる関係性なら、話の優先順位をテンプレートにしてすりあわせるのがいいんだけど、客先だとそうもいかないから、yes/noのQA形式にした方が混乱しないかな」
ははーー、と思ったわけです。
ちなみにこの時は、ものの見事にでかい業務要件が一個丸々漏れていました。簡単に言うと、通常の処理とは別に、ある条件では例外フローで業務を処理しなくてはならず、その時参照するDBが別システム上にあるのに、要件定義の担当者がその条件分岐自体を知らなかった、みたいな感じです。
後から判明すると即死する類いのヤツなのですが、上で言う③の人へのヒアリングから「なんかおかしいぞ？」というのが判明して、深掘りした結果発見出来た要件でして、「裏取り」が功を奏したサンプルになりました。
この助言のおかげで、というだけでもないんですが、その後も色々ありつつ案件はなんとか無事に収束しまして、私は以降も色んな現場でこの先輩と一緒になり、色々教えてもらいながら仕事をこなしていきました。
そのあと、色んな現場・職場を経験して、同じような分類を何度も試して、この時の先輩の話ってかなり普遍的な話だったのかもなあ、と思うようになりました。
なんだか情報のやりとりが上手くいっていないな、と思った場合、自分か相手のいずれか、あるいは両方が、「情報量不足」「情報量過多」「論理展開がおかしい」のどれかに大抵当てはまっているんですよ。
分かってみると自分で訂正することも出来ますし、「この人はこういう傾向があるから、こう対応すると上手く意思疎通しやすいな」という対応もある程度は出来るようになります。
情報の伝え方って根本的なことなので、他人から指摘して改善するようなものでもないんですが、新人さんの指導の場のような「ノウハウを教えるべき場」では上記のような話を伝えることもあります。
やっぱり、仕事をする上で「きちんと情報を伝えるためにはどうすればいいか」ってとても重要なノウハウですし、その際「言葉足らずになりがち」とか「防御線を張り過ぎ」みたいな自分の傾向を知っておくことも、ある程度役には立つと思うんですよ。
ここ最近は特に、昔以上に新人さんの指導役になる機会が多くなっているので、折りに触れてこの「タイプ別処方箋」の話をします。それと同時に、自分の話がうまく伝わってないな、と思う時は、この三つのどれかに当てはまっていないか考えてみるといいかも、というような話もします。
先輩からのただの受け売りですが、こういうのがノウハウとして誰かに伝わっていくのも、お世話になった恩返しとしては悪くないんじゃないかと。
新人の皆さんが、ちょっとでもこういうノウハウのいいとこ取りをして、いい感じで仕事をこなしていってくれるようになるならありがたいことだなあ、と、そんな風に考える次第なのです。
今日書きたいことはそれくらいです。
人手不足 × 業務の属人化 × 非効率──生成AIとDXでどう解決する？
今回は、バックオフィスDXのプロ「TOKIUM」と、生成AIの実務活用支援に特化した「ワークワンダース」が共催。
“現場で本当に使える”AI活用と業務改革の要点を、実例ベースで徹底解説します。
営業・マーケ・経理まで、幅広い領域に役立つ60分。ぜひご参加ください！
こんな方におすすめ
・人材不足や業務効率に悩んでいる経営層・事業責任者
・生成AIやDXに関心はあるが、導入の進め方が分からない方
・属人化から脱却し、再現性のある業務構造を作りたい方
＜2025年5月16日実施予定＞
人手不足は怖くない。AIもDXも、生産性向上のカギは「ワークフローの整理」にあり
現場のAI・DX導入がうまくいかないのは、ワークフローの“ほつれ”が原因かもしれません。成功のカギを事例とともに解説します。【内容】
◯ 株式会社TOKIUMより（登壇者：取締役 松原亮 氏）
・AI活用が進まないバックオフィスの実態
・AIだけでは解決できない業務とは？
・AI活用の成否を分ける業務構造の見直し
・“人に任せる”から“AI×エージェントに任せる”時代へ
・生産性向上を実現した事例紹介
◯ ワークワンダース株式会社より（登壇者：代表取締役CEO 安達裕哉 氏）
・生成AI活用の実態
・「いま」AIの利用に対してどう向き合うか
・生成AIに可能な業務の種類と自動化の可能性
・導入における選択肢と、導入後のワークフロー像
登壇者紹介：
松原 亮 氏（株式会社TOKIUM 取締役）
東京大学経済学部卒業後、ドイツ証券に入社し投資銀行業務に従事。
2020年に株式会社TOKIUMに参画し、当時新規事業だった請求書受領クラウド「TOKIUMインボイス」の立ち上げを担当。
2021年にはビジネス本部長、2022年より取締役に就任し、経費精算・請求書処理といったバックオフィスDX領域を牽引。
業務効率化・ペーパーレス化の分野で多くの企業の課題解決に携わってきた実績を持つ。
安達 裕哉 氏（ワークワンダース株式会社 代表取締役CEO）
Deloitteで大手企業向けの業務改善コンサルティングに従事した後、監査法人トーマツにて中小企業向け支援部門を立ち上げ、
大阪・東京両支社で支社長を歴任。2013年にティネクト株式会社を設立し、ビジネスメディア「Books＆Apps」を運営。
2023年には生成AIに特化した新会社「ワークワンダース株式会社」を設立。生成AI導入支援・生成AI活用研修・AIメディア制作などを展開。
著書『頭のいい人が話す前に考えていること』（ダイヤモンド社）は累計71万部を突破し、2023年・2024年と2年連続でビジネス書年間1位（トーハン／日販調べ）を記録。
日時：
2025/5/16（金） 15:00-16:00
参加費：無料 定員：50名
Zoomビデオ会議（ログイン不要）を介してストリーミング配信となります。
お申込み・詳細
こちらウェビナーお申込みページをご覧ください
(2025/5/8更新）
【著者プロフィール】
著者名：しんざき
SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。
レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。
ブログ：不倒城
Photo：Buddha Elemental 3D
