エンジニアならバグ票を書き慣れているので『事実と意見』を分けて話せる

仕事をしていて、状況をヒヤリングしていると、事実と話し手の意見の混同というか、話し手が質問を理解できなくて自分の思い、いや、感想を話し出すことはしょっちゅうある。

一方的に話し手の思いがダダ漏れしているというよりは、コミュニケーション自体、質問する側からの投げ掛けがキッカケなのだから、受け側の話し手のリアクションが期待するものでなければ、問いかけ側の質問が悪い。

例えば、次のエントリの中に出てくる会話はよくある上司と部下の日常的な風景に思えるかもしれないが、であれば部下へ聞きたいことを効率的に聞こうと思ったら、部下の返答の癖（事実と意見を区別できないこと）を知っているわけだから、上司の聞き方は上手とは言えない。

そういうときの質問の仕方も曖昧だったりする。聞き手が最短で聞きたいことを質問するなら枕詞として、

「先に事実だけ教えて。そのあとに意見を教えて」

と誘導すればいいだけの話だ。業務として区別して話すことを必要とするならば、OJTで指導すべきことだ。それをせずに、グダグダと事実と意見を区別できないというのは管理監督者の職務としてやることをやっていないのではないか。

話し手自身が何を聞かれているかを注意を向けられるように質問を続ければいいだけの話である。

エンジニアもこの事実と意見（意見というよりはエンジニアの思い込みの方が多い）を混ぜて話し出す人が割と多い。

では混ぜて話してはいけないのかと言えば必ずしもそうではない。使い分けてくれれば割とどうでもいい。

ただ、事実と思いを分けて欲しいときには、TPOに合わせて分けて欲しい。それはいつかと言えば、バグ、障害、インシデントを共有するときである。

エンジニアは予定していた作業をしてたとき、作業内容に応じて状況を共有（報告）する必要に迫られることがある。トラブルを起こしたときがそれである。

そのとき、

について時系列で報告してくれないと何が起きているか、どこで事象が起きたか理解できない。

特に監視中の環境でトラブったらトラップがバンバン上がってたまらない。

まあ、作業ログは残っているだろうから、それを確認しながら教えてくれればいいのだけれど。

幸い、エンジニアは全ての人がバグ票か障害報告書（とても形式張っているやつ）を書き慣れているので事実と思いを分別して言語化することは訓練されているから問題ない、と信じたい。