横着しちゃいかんのです。
IT業界に限った話しではありませんが、説明下手な人っていますよね。
私がIT業界でよく日頃から感じている説明下手(質問下手とも言う)なエピソードについて書いてみます。
例
やらないおさん、落ちちゃうんですけど、getHoge()のこの部分があれで、多分ああなんじゃないかと思うんですけど、どうすればいいですか?
????
え?ごめん。何の話?いきなりソースコードの具体的な箇所の話されても理解できないから、落ち着いて順を追って話してみようか
※ 以降、質問をする側を「やるお」、される側(私)を「やらないお」とします。
※ getHoge() メソッドはやるおが自分で作った独自メソッド。当然やらないおは知らない。
※ やらないおはgetHoge()を知らないし、どのプロジェクトのコードの話なのかも把握できていない。
※ やらないおはプロジェクトを沢山抱えており、複数のプロジェクトを行ったり来たりしている。
こういうケースがあまりにも多いのです。一番最初にソースコードの具体的な箇所について話し始めてしまう人が本当に多いです。
そしてこちらが話についていけていない事に気づかず、こちらに口を挟ませる隙を与えないまま質問口撃を最後まで続け、結局相手に何も伝わらずに徒労に終わるケースが多いです。
この話から私が理解できた部分
いきなりこの話をされて、3秒考えて理解できた部分は以下です。
- やるおから相談されている。
- 落ちるらしい。
- xxxで何か起きてるらしい。(ソースコードのファイルなのか、何なのかは不明)
私に伝わったのはたったこれだけです。
この話から私が理解できなかった部分
やるおからこう言われて、3秒考えて理解できなかったのは以下です。
- 何の件の事を言っているのか解らない。
- 「 落ちる」という言葉の意味合いが不明。今日の運勢が落ちたのか、NullPointerException等のエラーでプログラムが落ちたのか、tomcatのプロセスが強制終了したのか、jvmがクラッシュしたのか。どれ?(多分ヌルポのようなエラーが起きた事は想像できますが)
- xxxって何だ?xxx.javaの事かな?もやっと記憶にあるけど、具体的なソースコードの話されても、ソース見てみないと解らん。
- 「多分◯◯なんですけど」って、いきなり予想を言われても、その根拠とかの説明も無いし、その予想話、完全に無駄じゃない?と思ってしまう。
- 「どうすればいいですか?」って、それはこちらが質問を理解できていないと回答できない。
何も理解できなかったけど、とりあえずやるおが困っている事だけは解りました。
どうして話が伝わらないか
- 何の件の話なのかを伝えていない。
- 相手が今相談に乗る事ができる状態なのか確認していない。
- 相手が話についていけているのかを都度確認しないで自分の話をぶっ続けてしまっている。
- 予測の話は相手が話自体を理解してから話す必要がある。
やらないおはこのプロジェクトのソースコードについての知識は豊富ですが、沢山ファイル数があるので、いきなり具体的なファイルの話しをされても解らない・咄嗟に思い出せない場合があります。更に、相手は色々な件の仕事をしているので、「今どの件の話をしているのか」という事から把握できていません。そんな状態でソースコードの話から始めても、「え?」と返されるわけです。
プログラムを書く人はプログラムの話しが好きな場合が多く、どうしてもプログラムの話から始めたくなってしまうのですよね。しかしそれだと全く伝わらない場合がほとんどです。
どうすれば伝わったか
やらないおさん、◯◯の機能追加の件なんですが、既存バグを先に解決しないと実装できなそうなのですが、今10分程時間いいですか?
ウッス。ダイジョウブデス。(何か問題が起きたようだ)
Redmineのチケットの100番の話なのですが、まずチケット開いて貰えますか。
ウッス。この件っすね。(この件って事はあの辺の機能の話かな)
この機能を実装しようとすると、既存機能でNullPointerExceptionが起きてしまうんです。具体的にソースコード見て貰いたいのですが、今開発ツール起動してますか?
ウッス。開いてるッス。どの辺っすか?
◯◯プロジェクトの◯◯.javaです。
ウッス。このファイルッスね(あ、このファイルはあの辺の変数とか、怪しいかも)
このファイルの250行目の部分で、if文の部分でNullPointerExceptionが起きるのです。
ウッス。このif文っすね。nullチェックが抜けてるのもありますが、それとは別にこの変数に値が入らないケースがあるって事ッスね。
はい。どうも既存機能がこの変数に値を入れてるようなのですが、nullになるケースがあるみたいなのです。恐らく◯◯の定数を追加していないから、値が取得できずnullが返っていると思われます。
ウッス。その予想は多分合っているので、そのバグについて別途チケット起票するので、一緒に対応お願いしまッス。(色々把握できてるな。やるじゃないかやるお)
ウッス。
このやりとりのポイントは以下です。
- 最初に要件と概要を伝えている。
- 相手が今相談に乗る事ができるかを確認している。
- 相手が話を理解できるように、対話して相手の理解を確認しつつ次の話を進めている。
最初の例に挙げたやるおは、このやりとりに時間がかかるし効率が悪いと思っているから、横着して最初に具体的なソースコードの話から始めてしまうのですね。しかしやるおの頭の中の事はやらないおには解らないのです。これが解らないから、相手に話が伝わらないのです。
最初のやるおの話し方だと、やらないおがやるおに逆に質問して状況を整理してあげてようやく理解できるので、トータルすると最初の例のやりとりの方が遥かに時間がかかるのです。更に、やらないおに状況を整理させる仕事を増やしてしまい、印象も悪くなります。印象が悪くなるという事は、やるおへの評価も必然的に下がっていくわけです。
こういう質問が返ってきたら説明下手かも!?
質問をした時に、相手に逆に以下のような事を返されたら、説明下手になっている可能性があります。
- そもそも何の話?
- ごめん。話についていけてない。
- もう少しゆっくり話して。
- で、結局何なの?
雑感
こういう事が「コミュニケーション能力」が低いのだと私は考えています。決して「ウェーイwww」がコミュニケーション能力が高いわけではありません。
この件で重要なのは、「やらないおが理解できていないのは、既存機能にバグがある事ではなく、やるおが何を言っているのか解らない点」です。ソースコードの理解度は、やらないおはやるおより10倍くらい詳しいので、ちょっと単語が出てきただけで大体の内容が頭の中を一瞬で駆け巡る程の知識があります。しかし、そのソースコードで何が問題なのかがさっぱり伝わらないから、やらないおが困っているわけです。
「効率ガー」と言って横着する人は、相手の状況を考えず、自分本位で話を進めてしまっています。相手は今話せる状態じゃないかもしれないし、突然具体的なソースコードの話をされても、すぐには思い出せないかもしれません。なので、結局余計に時間がかかる場合がほとんどです。
横着せずに「どうすれば伝わったか」のようなやりとりをすると、誰に対しても話が最短で伝わるし、やらないおに「やるおは状況が整理できている」という印象を与える事ができるので、好印象になる筈です。
IT業界に関わらず「言わなくても解るでしょ!」だとか「それくらい推測しろよ!」という人がいますが、これは愚かです。例え家族であっても「子供が何も言わなくても親は理解できる」なんて事は絶対にありません。「ちゃんと言葉にして説明しないと相手には何も伝わらない」のです。それが現実です。

- 作者: Patrick Gleeson,青木靖
- 出版社/メーカー: 翔泳社
- 発売日: 2018/01/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る

エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方
- 作者: 開米瑞浩
- 出版社/メーカー: 翔泳社
- 発売日: 2016/12/02
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る