話し相手の意思決定ロジックを理解して業務コミュニケーションをサクサクにする

こんにちは！Dev Branch で Engineering Manager をしている大坪です。この記事は Coporate HR 主催のは「明日をチョット良くするスキルうぉんてっどり塾」(internal) の第一回「業務コミュニケーションをサクサクにする研修」の資料として執筆した社内報を一部修正して作成しました。（ウォンテッドリー社員向け：社内報リンク）

ざっくりまとめ

コミュニケーションは丁寧さだけではなく内容をチューニングしよう
相手が知りたいことを伝えよう
相手が知りたいことを「相手の意思決定ロジック」から逆算しよう

はじめに

今回の研修では、業務コミュニケーションをサクサクにする方法について考えます。コミュニケーションの先には必ずコミュニケーションの受け取り手に変化が生まれます。業務においてはその変化の中で特に重要なものに意思決定/行動があります。この2つをスムーズにして決めるべきこと、やるべきことがサクサクと決まっていくことを目指していきます。この力をつけると個人からチーム、チームから会社とより大きな単位での意思決定をしていくことにつながっていきます。

ウォンテッドリーは「情報を受け取り情報を出力する大きな箱」

我々は物理的な意味での価値は生んでいない

ウォンテッドリーの活動は価値を生んでいます。売上はその対価を支払うだけの価値があると感じている人がいる紛れのない証拠です。ただ、ウォンテッドリーは「物理的な価値」を生む会社ではないということは念頭に入れておかなくてはなりません。

価値は情報の整理と伝達によって生じている

ではウォンテッドリーが提供している価値とは何でしょうか。それは情報の整理と伝達です。Wantedly Visit は人と会社の最高のマッチングが達成されるための情報を両者に提供しています。気づけば我々は社外とのコミュニケーションはほぼ全てコンピューターを通してできています。社外の人から見るとウォンテッドリーという会社はひとまとまりのなにかであり、そこに情報を入れたり情報を引き出したりできます。他の SaaS ビジネスも基本的にはすべてそうなっていますね。ウォンテッドリーは情報を受け取り情報を出力する大きな箱だと思うことができます。

まずは社内の情報共有

ではこの箱のパフォーマンスを良くするにはどうすればいいでしょう。その方法の一つにその箱の中の小さい箱のパフォーマンスを上げるという手があります。

小さな箱の集合としてのウォンテッドリー

外部から見たらウォンテッドリーという会社は一つの箱に見えるかもしれません。ただ実態としてその中身には Dev Branch/ Biz Branch/ Corp Branch が存在しています。Dev Branch はプロダクトデザイン、コーディングによってプロダクトの変更情報を AWS に伝達していると言えます。Biz Branch では Wantedly を使うと良い人にその魅力と使い方を伝え、プロダクトの改善案を受け取ります。Corp Branch は会社を運営するために、適切な情報処理が求められます。これらの間のやり取りも基本的には物理的なものではなく情報です。

小さな箱のパフォーマンス向上

ウォンテッドリーという大きな箱のパフォーマンスを上げるためにその中の小さな箱のパフォーマンスを上げることが大事です。チームに分解し、さらにミクロまで見ていくと、最終的に個人がでてきます。

個人が情報を受け取りそれを処理して誰かに伝える時、それはなにかに付随するものではなく仕事で生んでいる価値そのものなのです。

相手のロジックでコミュニケーションする

会社には立場が違う人のほうが多い

ウォンテッドリーのミッションは「究極の適材適所により、シゴトでココロオドルひとをふやす」ことであり、それに向かって行くことはどのチームでも個人でも変わりません。しかし、行き着くミッションが同じであることは立場が同じであることを意味しません。社内のどの2チームをとってもどの2人も責務範囲が同一であることはありません。

責務が違うと当然守るべきことも違います。サッカーや野球などのチームスポーツにおいても「勝つために戦っている」ということは同じであっても選手ごとにポジションは違うし、守らなくてはいけないものも違います。ゴールキーパーに「勝つために君もシュートを打ってくれ！」と言ってもチームは勝てません。

守るべきことが違えば意思決定のためのロジックも異なります。その意思決定ロジックの差分があっても全体最適を取るために One Team という value があります。ただし、「全体最適さえ考えればロジック差分が問題にならない」という考えではいけないと思っています。

相手の知りたいことに根ざしたコミュニケーション

「その話興味ないな」とか「結局何の話なんだろう」と思いながら聞き流したことは誰しもあるでしょう。この状況では言い方が丁寧であったり、思いやりを感じたり、全体最適を目指していることが伝わっても「適切な情報伝達ではない」という問題は変わりません。

人はコミュニケーションに不安がある時、丁寧さで解決しがちだと私は考えています。もちろん敬意や丁寧さは重要です。しかし実際のところ多くの場合改善されるべきなのはその内容です。「お疲れ様です！」とか「大変お忙しいかと思いますが...」といった前置きは相手の心理的負担の軽減には貢献しますが、業務の本質である「良い意思決定」には貢献できません。コミュニケーションの負荷は、丁寧さを足すことではなく内容の改善で軽減していきましょう。

相手のロジックから知りたいことを逆算する

多くの人が「相手の知りたいことを伝える」、ということを意識はしていると思います思います。しかし、その知りたいことを当てることに苦戦しているケースもあるのではないでしょうか。その場合には「相手のロジック」を理解すると良いでしょう。相手のロジックとは「相手の意思決定フロー」とも言い換えられます。

今一度相手を「情報を渡したら何かが出てくる箱」だと思ってみることにしましょう。(もうお気づきかもしれませんがエンジニアはいろんなものを箱に例えがちです)

とすると当然ながら「意思決定に足る情報を提示できているか」が重要になります。(後述しますが情報が足りない場合、それは質問という形のフィードバックされます)

フローチャートの想像

足りないケースの例として友達に「今週末あいてる?」と聞かれる状況が当てはまります。これを聞いた皆さんの率直な反応は(よほど仲の良い人でない限り)「あいてると言ったら何が起こるのかによる」でしょう。上のメタファーでいうと、あなたは「今週末」という情報だけで「遊びに行くか」という意思決定を迫られています。

ではどんな情報があればいいでしょうか。それを想像するには「意思決定のフローチャート」を想像してみると良いでしょう。「箱」とざっくりいっているもの中には意思決定のフローチャート、つまり意思決定ロジックが隠れています。

実際にはそんなフローチャートを整理している人はいないでしょうが、ここに週末の誘いに行くのか決めているフローの例を見てみましょう。

その日別の予定がある -> yes なら断る
いきたい or いったほうがいい -> no なら断る
予算が自分の都合に合う -> no なら断る
次の日に仕事がある -> no なら行く
仕事に影響しなさそうな内容である -> yes なら行く
ここまで来たら no にする

ざっくりこんな感じだとすると

日曜日の13:00から一緒に東京ドームに野球見に行かない?
一人3000円になると思う。
月曜仕事だし試合後はちょっとお茶して解散のイメージ

と言われれば、使う時間もかかる費用もイメージできるので意思決定できそうです。

もちろん意思決定は実際には有機的な営みです。ただ「この人の意思決定フローはどんな形だろうか?」と想像してみることで相手に渡すべき情報はグッと整理できます。

自分の理由と相手の理由は違う

理由や情報をしっかり入れてコミュニケーションしているつもりでも、自分にとっての理由に終止してしまうケースがあります。まずはこの２つを区別してみましょう。

自分の理由

自分の理由とは「自分が相手にしてほしい理由」です。自分視点のことであり、これだけを伝えて理由を伝えた気になっても相手に取っては意味のない情報になることがあります。デパートで店員さんに「買ってもらえないと私の売上目標が未達になります」と言われてもそれは店員さんにとっての理由であって購入するかの意思決定をする自分には関係ありません。

流石にこんなことないでしょう、と思うかもしれませんが「どうしても進めたいので特例で予算増額の承認お願いします」というようなコミュニケーションは業務においては簡単におきえます。あえてすごくドライな書き方をすると「あなたがどうしても進めたい」と「特例を認めるべき事象であるか」は関係ありません。ここで伝えるべきはコミュニケーション相手にとっての理由です。

相手の理由

相手の理由とはコミュニケーション相手の意思決定根拠であり、まさにフローチャートに必要な情報です。繰り返しになるので例だけにとどめます。特例を認めるかを決める人のフローチャートを想像すると、おそらくこんなことを考えるのではないでしょうか。

認めることにメリットが有るか?
特例が増えることにデメリットはないか?
- 不公平になったりはしないか?
- その分犠牲になるものがないか?
そのデメリットをメリットが上回るか?

とすると伝えるべきことは「XX というメリットが有り、デメリットは YY という理由で軽微」という内容になるでしょう。

経緯と理由はちがう

意思決定やアクションをしてほしい理由を伝えるときに経緯を伝えてしまうケースもよくあります。もちろん経緯を伝えたほうがイメージがしやすくなるなど良いこともありますが、経緯それ自体は理由ではありません。例として購入したい物品が予算策定時より値上がりして予算を逸脱するケースを考えましょう。経緯ベースで伝えると下のようになるかもしれません。

A という物品ですが、ふとたまたまニュースを眺めていたら気づいたのですが、値上がりしてました。気になって予算シートを見たら予算策定時は考慮外だったようです。予算を 100万円で取っていましたが、110万円になりそうです。問題ないでしょうか。

ただ、「なぜ起こったか」と「それを認めてよいか」は関係ないケースがたくさんあります。今回のケースだと経緯は分かっても認めていい理由はわかりません。これも意思決定フローを想像すると下のようなことを考えそうです。

質や量を下げる選択肢はないか
代替品はないのか
値下げ交渉の余地はないか
それがないと何が困るのか

質問はフィードバック

ここまでで、経緯や自分の理由ではなく相手のロジックに根ざした理由を伝えていることがわかりました。とはいえそれを知るだけですぐに実践するのは簡単ではありません。そこでこのスキルを磨いていく方法を紹介します。それは「質問をフィードバックとして捉える」ということです。

質問を通して「相手のロジック」を理解する

なにか意思決定のお願いをするコミュニケーションをして質問が来る場合、それは「意思決定フローチャートが情報不足でとまったからだ」と捉えましょう。自分が相手のロジックをしっかり想像して説明を加えたのに質問が来た場合、それは自分の想像する相手のロジックと実際の相手のロジックに差分があったことを示しています。その差分を一つずつ埋めていくことで最終的に相手の意思決定ロジックを完全に想像できて、最終的に質問が来なくなります。そこで何かを伝えて質問が返ってくる場合は「自分の考えが足りなかったところに対するフィードバックだ」と捉えて聞いていくとよいでしょう。

前回よりも質問が減るように伝える

何かを伝えたときに質問がない状態まで毎回チューニングするのはむしろコストのほうが大きいので目指さなくても良いでしょう。ただ、一つのメトリクスとして質問が少なくなる状態を目指し続けると自分のお願いしたいことが簡単に伝わるようになります。

余談 - 逆に質問したりロジックを明かしたりしよう

これを読んでいるみなさんは誰かに情報を伝えるだけでなく、受け取ることや意思決定を求められることがあるでしょう。コミュニケーションは共同作業なので伝え手が今後改善できるように、フィードバックをすると自分の仕事がどんどん楽になりチームとして良い意思決定ができるようになります。

そこで下のようなことをやってみてもいいかもしれません。

足りない情報がある場合は(自分で調べることができるとしても)あえて質問してみる
返信/返答で意思決定ロジックを明示する
- 例: Aという成約が守れれば ok で今回は B でそれが担保されているのでいいと思います！

フォーマット

あえてここまで抽象論と具体例にとどめてきました。フォーマットなど小手先の技術を覚えるのではなく意味として何が良いコミュニケーションであるか理解してほしいと考えたからです。これを書いている大坪もフォーマットを気にして書いているわけではありません。とはいえ、明日から実践してみることが少ないのはそれもイメージし辛いと思うのでフォーマットを示します。下のフォーマットは状況によっては冗長すぎたり情報不足になったりします。順番もそこまで強い意図があるわけではありません。「なにか伝えるべきことが漏れてる気がするな」と思ったときに立ち戻るヒントにする、という使い方をしてください。

意思決定

意思決定をしてほしい場合、大坪は下の順に伝えています。

意思決定をしてほしいという事実
理由 (相手のロジックに合わせて)
判断の余地
自分の意見
補足リンク

具体例を示すと下のような感じです

@プロダクトオーナー
リリース日を1週間遅らせていいですか? (意思決定のお願いの明示)
重要なバグがまだあり品質を担保するために必要です (理由1)
遅れは1週間の予定です。直し方は見えています (理由2)
広報 / CS としては問題ないことを確認しました(理由3)
中途半端な見え方になるので自分としては遅らせるのが妥当だと思います (意見)
ただ、最悪 A 機能を落とせばそのままでもいけます (判断の余地
補足: バグの詳細のリンク

理由の1つ目はわりと「先週から解消しようとしているバグがどうしても直りきらず...」というような経緯を話してしまう事が多いと思います。大事なのは「品質担保のためである」という事実です。

理由の2つ目と3つ目は抜けがちです。意思決定者からすると「品質のためである」とだけ言われても「それはズルズルと無限に遅くならないか?」とか「Dev は良くても他の部署的に困ったりしないのか?」とかが気になったりするでしょう。このあたりは意思決定者のロジックを想像することで補えます。

ここまでの議論では触れていませんが、自分の意見を伝えることも大事だと考えているのでいきなりですが紹介です。最終的に意思決定するのは今回のケースではプロダクトオーナーかもしれません。しかし品質と期限のようなトレードオフのどちらを取るべきかは一番目の前で見ている人の意見が当然欲しくなります。誰かに意思決定をお願いする時、意思決定者は相手かもしれませんが専門家に近いのは自分になります。そこで、意思決定をお願いする場合も自分の意見は何であるかのスタンスは取るようにしましょう。

最後に判断の余地です。意思決定は一つのアイデアに yes/no を返す仕事ではなく、複数ある選択肢からベストなものを選ぶ仕事です。するとせめて第2案が何であるかわからないと決められません。そこで第2案としては何があるか、何が変われば意思決定が変わる余地があるかがわかる情報をつけるとよいでしょう。

発展 - ホップ数を増やす

ここまでで相手のロジックを念頭においてコミュニケーションをすると、自分のお願いしたいことがサクサクと伝わっていくのではないかと思います。最後に発展としてホップ数を増やす考え方を説明します。

あなたのコミュニケーション相手にもコミュニケーション相手がいる

例えば上長に承認をもらう時、その上長にも上長がいます。営業における商談相手にも上長がいます。自分が眼の前に人に理解をしてもらっても、それを受け取った相手はそれを別の意思決定者にパスしないといけないケースがあるわけです。上長でなくても情シスや法務などのケースもあるでしょう。何か自分のやりたいことがある場合、自分と担当者との間のコミュニケーションだけでなくその先のコミュニケーションもうまく行かないと成功しません。

2ホップ先のロジックの想像

そこで大事なのが、眼の前のコミュニケーション相手が再変換をしなくていいコミュニケーションのパッケージングです。眼の前の人とはコミュニケーションの1ホップ目が生じているわけですが、そこでもう1ホップの想像、つまり2ホップ先のロジックを想像ができると仕事がさらにサクサク進みます。

ここではわかりやすさのために所属チームのチームリーダーとその上司をグループリーダーとして説明してみます。(ウォンテッドリー社内ではそれぞれ Squad Leader / Tribe Leader と呼んでいます)。自分はチームリーダーの意思決定ロジックを想像して情報を組み立てるわけですが、チームリーダーはグループリーダーの意思決定ロジックを想像してその受け取った情報を組み立て直すわけです。その変換を自分がしてしまえば。チームリーダーは自分の提案を最速でグループリーダーに提案することができます。つまり、チームリーダーの意思決定ロジックとグループリーダーの意思決定ロジック用の情報の両方を作るかどちらにも対応できる情報のセットにしてしまえばいいのです。

この「チームリーダー / グループリーダー」のペアが実際には「営業相手/その上長」だったり「協力会社/その法務」だったりします。

ホップ数を増やすと「会社の意思決定」ができる

ウォンテッドリーは大きい会社ではありません。どんな人もコミュニケーションで4~5ホップも行けば株主までいけます。究極的には会社を変えるような大きな意思決定も、そのホップに入る人全てにとって「たしかにそれが妥当である」という情報が出せれば会社全体の意思決定までできます。もちろん会社全体の意思決定までできるようになるというのは簡単なことではありません。でも、眼の前のコミュニケーションとしての1ホップ目がうまくなれば自分だけの意思決定ではなくチームとしての意思決定ができるようになり、もう1ホップ足せれば開発組織、営業組織クラスの意思決定に入っていけます。日々の自分の意思決定そして出す情報が影響を与える箱の大きさをどんどん大きくしていきましょう。