何かの問題点を伝える場合、実際に起こったできごとの内容ではなく、「起こったできごとに対して自分が感じたこと、それを元に危惧していることを丸めて伝える」ということがありがちです。 このとき、具体的な出来事の情報や、何が問題だと捉えているかの情報が整理されて伝えられていればよいですが、情報を丸めて伝えるケースもあります。この場合、事実と異なる伝わり方をしたり、ズレた意思決定につながる場合があります。
こういったケースの問題点についてまとめます。
丸めて伝えるまでの思考の流れ
問題の発生
何かの問題が発生します。これは純粋な出来事であり、事実です。
問題の解釈
発生した問題を解釈します。ここは主観が入り、その解釈が事実に即している場合もあれば、解釈に飛躍がある場合もあります。
問題の影響を推測
解釈した結果を元に、問題の影響を推測します。妥当な推測をする人もいれば良くも悪くも大きく飛躍した推測をする人もいます。
影響の対策を検討
推測した影響を元に対策が必要だと考えたら対策を検討する人もいます。
情報の伝達
問題について一緒に取り組みたい相手や問題の当事者と考える相手に問題に関する認識と対策案の情報を伝えます。 この際に問題点の事実や、解釈の背景を詳細に伝える人もいれば、内容を端折って丸めて伝える人もいます。
この際に、伝えられた側が知ることができるのは伝えられた情報のみです。伝えた人の思考プロセスは知りません。そのため、情報を丸めて伝えると
- そもそもどんな出来事が起こったのか相手に伝わらない
- 出来事の解釈が間違っていた場合、その事実に気づきにくくなる
ということがありえます。結果として誤った意思決定に至りやすくなります。
出来事を丸めて伝える例
ここまでで説明した流れをもとに、具体例を考えてみます。なお、以降の例は今考えたものです。
問題の発生
SaaSのプロダクトの新機能について、リリース時にユーザーガイドへの反映が漏れていたとします。機能の実装担当とユーザーガイドの担当は別々で、今回は機能の実装担当はBさん、ユーザーガイドの担当はCさんでした。 そして、Cさんが有給休暇をとっている事に気づかなかったことで、ユーザーガイドの準備をしないまま実装を終え、リリースをしていた、というのが実態でした。
問題の解釈
ユーザーガイドへの反映漏れを見つけたAさんは、該当機能を実装したBさんのミスと考えました。 また、そのミスは職務怠慢で、意識の低さが原因だと解釈しました。
問題の影響を推測
Aさんは、Bさんの職務怠慢が他の業務にも悪影響を及ぼすと推測しました。
影響の対策を検討
Aさんは、マネージャーにBさんの勤務態度について厳しい指導をしてほしいと考えました。
情報の伝達
Aさんは、マネージャーに「Bさんはミスばかりで職務怠慢です。厳しく指導してください」と伝えました。
事実と丸めて伝えた場合の問題点
- ユーザーガイドの担当はBさんではなくCさんである
- ユーザーガイドの対応が漏れた原因はBさんのミスではなく、リリース管理として機能とユーザーガイドの両方のリリースがなされていることを確認していないこと
- 仮にユーザーガイドの対応が漏れた原因がBさんだったとしても、ミスをした原因が職務怠慢とは限らない
- 問題の原因も確認できていない状態で、Bさんの職務怠慢が事実である前提でマネージャーに提案をしている状態
- マネージャー目線だとBさんがどんなミスをしたのか、それが職務怠慢なのかどうかに関わる情報がない
まとめ
「起こったできごとに対して自分が感じたこと、それを元に危惧していることを丸めて伝える」際に、情報が丸められた伝えられた場合の影響についてまとめました。
受け取り手が違和感を感じて具体的な背景や辻褄が合わなそうな部分を確認してくれる人であればズレを補正できることもありますが、そのまま流されてしまうこともありえます。 具体的な物事への懸念を誰かに共有する際は、具体的な背景を添えて伝えるのが大切です。
