「その話興味ないな」とか「結局何の話なんだろう」と思いながら聞き流したことは誰しもあるでしょう。この状況では言い方が丁寧であったり、思いやりを感じたり、全体最適を目指していることが伝わっても「適切な情報伝達ではない」という問題は変わりません。
人はコミュニケーションに不安がある時、丁寧さで解決しがちだと私は考えています。もちろん敬意や丁寧さは重要です。しかし実際のところ多くの場合改善されるべきなのはその内容です。「お疲れ様です！」とか「大変お忙しいかと思いますが...」といった前置きは相手の心理的負担の軽減には貢献しますが、業務の本質である「良い意思決定」には貢献できません。コミュニケーションの負荷は、丁寧さを足すことではなく内容の改善で軽減していきましょう。
多くの人が「相手の知りたいことを伝える」、ということを意識はしていると思います思います。しかし、その知りたいことを当てることに苦戦しているケースもあるのではないでしょうか。その場合には「相手のロジック」を理解すると良いでしょう。相手のロジックとは「相手の意思決定フロー」とも言い換えられます。
[...]とすると当然ながら「意思決定に足る情報を提示できているか」が重要になります。(後述しますが情報が足りない場合、それは質問という形のフィードバックされます)
実際にはそんなフローチャートを整理している人はいないでしょうが、ここに週末の誘いに行くのか決めているフローの例を見てみましょう。
- その日別の予定がある -> yes なら断る
- いきたい or いったほうがいい -> no なら断る
- 予算が自分の都合に合う -> no なら断る
- 次の日に仕事がある -> no なら行く
- 仕事に影響しなさそうな内容である -> yes なら行く
- ここまで来たら no にする
ざっくりこんな感じだとすると
- 日曜日の13:00から一緒に東京ドームに野球見に行かない?
- 一人3000円になると思う。
- 月曜仕事だし試合後はちょっとお茶して解散のイメージ
と言われれば、使う時間もかかる費用もイメージできるので意思決定できそうです。
意思決定をしてほしい場合、大坪は下の順に伝えています。
- 意思決定をしてほしいという事実
- 理由 (相手のロジックに合わせて)
- 判断の余地
- 自分の意見
- 補足リンク
具体例を示すと下のような感じです
- @プロダクトオーナー
- リリース日を1週間遅らせていいですか? (意思決定のお願いの明示)
- 重要なバグがまだあり品質を担保するために必要です (理由1)
- 遅れは1週間の予定です。直し方は見えています (理由2)
- 広報 / CS としては問題ないことを確認しました(理由3)
- 中途半端な見え方になるので自分としては遅らせるのが妥当だと思います (意見)
- ただ、最悪 A 機能を落とせばそのままでもいけます (判断の余地
- 補足: バグの詳細のリンク
理由の1つ目はわりと「先週から解消しようとしているバグがどうしても直りきらず...」というような経緯を話してしまう事が多いと思います。大事なのは「品質担保のためである」という事実です。
理由の2つ目と3つ目は抜けがちです。意思決定者からすると「品質のためである」とだけ言われても「それはズルズルと無限に遅くならないか?」とか「Dev は良くても他の部署的に困ったりしないのか?」とかが気になったりするでしょう。このあたりは意思決定者のロジックを想像することで補えます。