伝えたことを意図通りにやってもらえない経験はありますか
「きちんと伝えたはずなのに、意図した通りにやってもらえなかった」
ソフトウェアのチーム開発において、こうした経験をしたことがある方は多いのではないでしょうか。
私自身も、仕事を進める中でその経験は何度もありました。
恥ずかしい話ですが、過去の私は、伝えたことを意図通りにやってもらえなかった原因が、相手にあると思い込んでいました。
しかし、今、振り返ってみると、その原因は私にあったと思います。
そのような恥ずかしい自分の行動を戒めるために、私が実際に失敗してきた原因と、その対策を紹介します。
「伝えたのに意図通りにやってもらえなかった」という悩みを減らし、スムーズなコミュニケーションを実現するためのヒントになれば幸いです。
伝えたのに意図が伝わらない原因と対策
主な7つの原因と、その対策を紹介します。
1. 口頭で言ったことは忘れる
口頭で伝えた内容は、思った以上に記憶に残りません。
特に、複雑な指示や細かいタスク内容は、時間が経つにつれて曖昧になったり、忘れ去られてしまうことがあります。
たとえば、会議でタスクの優先順位を口頭で伝えた場合、その場では理解してもらっていても、翌日には忘れて間違った順番で進めていることがよくありました。
＜対策＞
たとえ突発に起きたことに対して、口頭で依頼したことであっても、その後に文章として記録して送ることが重要です。
たとえば、会議の後に「今日話したタスクの優先順位はこれです」と要点を簡単にまとめたメモを共有すると、記憶違いや認識ズレを防げます。
私のチームでは、突発的にビデオ通話で相談した時は、決まったことを分報に書き込みながら話すことが多いです(分報についてはこちらの記事を参照)。
2. メンタルモデルの違い
メンタルモデルとは、ある事象に対する個人の認識や理解の枠組みのことです。
新人と経験者では、同じ用語であっても、経験と知識の違いにより、解釈が変わってしまうことがあります。
それを前提にして用語に対する認識を揃えないと、意図した通りにやってもらないことが多く発生します。
例として、新人に「このクラスはリファクタリングして、もっとシンプルにしてください」と依頼した時の話を紹介します。
リファクタリングを指示した意図としては、「機能や挙動は変えずに、重複している処理を共通化してコードの保守性を向上させてほしい」ということでした。
しかし、新人は機能をシンプルにするため不要そうな処理を削除してしまい、もとの機能から重要なビジネスロジックが欠落してしまうことが起きました。
＜対策＞
メンタルモデルの違いを埋めるためには、抽象的な説明ではなく具体的に説明することが有効です。
例えば、上記の例の場合、「リファクタリングして、もっとシンプルに」と言うのではなく、以下のように目的と作業内容を具体的に説明した方が伝わりやすくなります。
「XXXメソッドとYYYメソッドが重複している処理があり、このままでは今後機能追加する時に、片方のメソッドだけ変更して、もう片方のメソッドの変更が漏れてしまうなどの問題が起きます。そのため、重複している処理を共通化するメソッドを作って保守性を高めてください。」
特に新人に対しては、上記のように伝えることでメンタルモデルの違いによる認識の齟齬は減ります。
3. ダニング＝クルーガー効果による理解のズレ
ダニング＝クルーガー効果とは、「自身の能力や知識が不足しているにもかかわらず、過大に評価してしまう」という心理現象です。
例えば、新人にAPI設計の考え方を説明したとき、その場では「分かりました！」と返事をもらったとします。
しかし、いざ実装してもらうと「意図とは違う形になっていた」ということがよくあります。
これは、本人が「理解した」と思っていても、実際には深く理解できていないケースです。
人は、自分の理解度を過信しがちです。
説明を聞いたときは「分かった！」と思っていても、いざ実践すると「思っていたのと違った」となることがあります。
したがって、相手の「わかりました」という返事だけで、理解度したとみなしてはいけないのです。
＜対策＞
この問題を防ぐには、説明をした後に「では、どういう理解をしましたか？」と相手に説明してもらうのが有効です。
例えば、「今説明したAPI設計の方針について、自分の言葉で説明するとどうなりますか？」
と質問すると、相手がどこまで正しく理解できているか確認できます。
もし理解がズレていれば、その場で補足説明をすればよいのです。
また、一度に大量の情報を伝えるのではなく、こまめにフィードバックをもらいながら進めることも重要です。
例えば、メンバーに難しいタスクを任せるときは、いきなりすべてを説明しきってから理解度を確認するのでなく、「ここまでの説明に対して、どういう理解をしましたか？」と説明の途中で理解度を確認していくことも重要です。
4. 文章だけでは伝わらないこともある
伝えたいことをしっかり文章で書いたのに、意図が正しく伝わらないことがあります。
特に、仕事に慣れていない新人の場合、書かれた内容を正しく理解できなかったり、読み飛ばしてしまうことがあります。
過去の私は「書いてあるのに、なぜその通りにやらないのか」と考えていました。しかし、誰でも慣れていないタスクの場合は焦ったり慌てたりして落ち着いて考えられないため、基本的なミスをしてしまうことはあります。
だから、相手にとって慣れていないタスクに対しては、書いただけでは伝わらない前提に立つことが重要です。
＜対策＞
この問題が発生しやすいときは、文章だけでなく口頭でも補足説明をするのが有効です。
さらに、説明を受けた相手に「どのように理解したか」を自分の言葉で説明してもらうと、理解のズレを確認できます。
5. 目的が伝わっていない
タスクの作業手順だけを伝えて目的を伝えていない場合、その作業手順を少し読み飛ばしたり、わずかな解釈違いがあるだけで、まったく意味のないことをやってしまうリスクがあります。
たとえば、テスト仕様書を作成するタスクにて、ある機能のテストケースを「XXXしてYYYした後にZZZを確認する」というテスト実施手順だけ伝えて、そのテストでどんな不具合を検出することが目的なのかを伝えていない場合は、検出したい不具合を検出できないテストケースが作られてしまうことがありました。
＜対策＞
依頼するときは作業内容と一緒に、その目的が何であり、その成果がどのように活用されるかを伝えるようにします。
これは、伝える側と伝えられる側の両方で意識した方が良いことなので、チーム全体として、コミュニケーションを行う時に目的を共有することの重要性を繰り返し共有することをお勧めします。
そうすると、目的を伝えることをうっかり忘れていても、依頼された側が「その目的は何ですか」と確認してくれます。
過去の私のチームで、チーム全体で目的を伝える意識が低かった頃は、以下の施策を活用していました。
6. 心理的安全性が低いため質問をためらう
心理的安全性が低い状態だと、質問しづらい雰囲気ができてしまいます。
その結果、タスクを依頼された人は分からない点があったとしても、質問をためらってしまいます。
これは「分かったふりをしてしまう」ということになります。
これが原因で後で問題が起きると、依頼した方からすると、
「いつも正直に分からないことを聞くように伝えているのに、なぜ分かったふりをしたのですか？そこで嘘をつかれたらどうしようもないし、分かったふりしても、結局、後で困るから意味ないですよね？」
という旨を言ってしまうことがあります。
こうなると、さらに相手は質問しづらくなり、負のスパイラルが起きます。
過去の私はこの失敗をやったことがあります。
＜対策＞
心理的安全性が低いと、質問をすることが「無能だと思われるのではないか」「怒られるのではないか」と感じ、疑問があっても言い出せなくなります。
したがって、そう思われないように、自分の弱みを見せ、質問には感謝を伝えることが対策になります。
- 弱みを見せる
- 完璧で隙のない人に対して「分からない」という発言をするのはためらいます。「分からない」と発言するのは、意外と勇気が必要で、それを安心して言えるようにチームの皆がお互いに気兼ねなく弱みを見せられる環境を作る事が重要です。その点で、マネージャーやリーダーが自分の弱みを見せることは効果的です。そういう人でも分からない事があると素直に弱みを見せてくれると分かれば、他のメンバーも「分からない」と発言しやすくなります。
- 質問に対して感謝を伝える
- 質問してくれた場合に「いい質問ですね！」や「聞いてくれてありがとう」と感謝を伝えます。質問する＝ポジティブフィードがあるという認識に変えることで、分からないことを質問することへの抵抗感を減らします。
7. 伝わらなかった原因が自分にあると思っていない
結局、ここが一番大きい点ですが、伝わらなかった原因を相手に求めてしまうと、伝え方を改善する活動が行われません。
その結果、いつまで経っても問題が解消されない状態となります。
逆に、伝わらなかった原因が自分にあると考えることができれば、それだけで問題は解決します。
なぜなら、そこから改善意識が生まれ、伝え方を改善する施策をいろいろ試していくことになるからです。
ここまでに紹介した対策は、その施策の一例に過ぎません。
＜対策＞
伝わらなかった原因が自分にあると思っていなかった人が、意識だけを変えようとしても難しいものがあります。
そこで、行動を変えることで、その意識し続けやすくできます。
具体的には、正しく意図が伝わらなかった場合に、伝えた自分が謝るのをくせになるまで繰り返し続けましょう。
そうすると、「伝わらなかったのは自分が原因」という意識を保ち続けることができます。
私の上司の振る舞いを例として紹介します。
私が上司に言われたことを間違って解釈してしまった場合、上司の方が「私の伝え方が悪くて申し訳有りません」と謝ってくれます。
そう言われた私は「いえいえ、私の方が曖昧な理解になっていた点をしっかり確認せず申し訳有りません」という気持ちになります。
つまり、伝えた相手が謝ると、伝えられた側も「自動の行動を改善しよう」と自然に思う効果があります。
チームとしてコミュニケーションの失敗があった場合に、伝えた側と伝えられた側の両方が改善意識を持つ方が、今後のコミュニケーションがよくなります。
だから、結局、今回紹介した対策のうち、この対策が一番大きな効果を持つので、これだけでも実施することをお勧めします。
まとめ
「伝えたことを意図通りにやってもらえなかった」という悩みを減らすために、以下の対策を紹介しました。
- 口頭で伝えたことを記録する
- メンタルモデルの違いを認識し、抽象的でなく具体的に説明する
- 理解度確認のために相手に説明してもらう
- 書いた上で口頭でも説明する
- 目的を伝える重要性をチーム全体で共有する
- 自分の弱みを見せ、質問には感謝を伝える
- 伝わらなかったら謝るくせをつける
私自身が、これらの対策を実施することで「伝わらなかった」という問題が大きく減りました。
ただし、今でも私はこれを完璧にできていません。
ときどき、「ちゃんと書いて伝えたじゃないですか」と言ってしまうことがあります。
この記事を書くことで、あらためて自分の行動を戒めたいと思います。
ちなみに、この記事を投稿した同じ日に、私がIT月刊誌「Software Design」で連載しているマネジメントの記事の知見を楽しく学ぶためのライトノベルを公開しました。第1話は、この記事の「伝えたことを意図通りにやってもらえない原因」をまさにやってしまっているので、よろしければ参照ください。
第1話 自信を喪失させるコードレビュー
X(旧Twitter)でも役立つ情報を発信しますのでフォローしてもらえると嬉しいです → @kojimadev