TL;DR: 多分伝わるだろうという思い込みは辞めてちゃんと言おう。
僕の会社
僕が働いている会社は小山工業高等専門学校の同級生と起業した会社です。
高専に入学したのが確か2005年なのでかれこれ10年ぐらいの付き合いになります。
メンバーの入れ替わりはあるものの、役員3人は全員同級生です。
弊社にはそれに加えて1名の従業員がいて彼は同級生ではないですが僕と個人的な付き合いがあって、入社と同時に一瞬で馴染んでいます。
なぁなぁでコミュニケーションしてない？
さて、そんな付き合いの長いメンバーが沢山いるとスムーズなコミュニケーションができるんだろうなと思う人も多いと思います。
まさにその通りで阿吽の呼吸や、以心伝心で特に詳細まで話さなくてもなんとなく考えを理解することができます。
「彼はこういう時はこういう風に考えるから、多分こういうことを言ってるんだろうな..」 的な雰囲気です。
でも、これは結構危険です。
阿吽の呼吸が成立するのは良いことだとは思いますが、それに頼ってコミュニケーションをしていると非常にマズいことになります。
細かく説明しなくなったり発言者も詳細まで考えなくなったりする
これは「細かいところまで説明しなくても伝わるだろう」という甘えから、何かを説明するときに自分自身が細かいところまで考えなくなってしまう思考に陥ってしまうという問題です。
- 多分伝わるだろうから細かいところまで説明しなくてもいいや
- そもそも説明しなくていいから考えなくていいや
- 細かいところはあっちで考えてくれるっしょ
という順序でどんどん考えが甘くなって、指示が正確に伝わらないというよりそもそも指示が正しくないという状態になってしまう可能性があります。
このままいくと脳みそが退化しそうですね。
最終的には…
そんなこんなで雑なコミュニケーションをとっていると最終的には重大な問題に繋がる可能性があります。
「言わなくてもわかるよな〜」とか「多分気がついてるよな〜」って思って、ちょっとした疑問をそのままにしておくと、どうなるかというのはこの画像がよく説明してくれると思うのでまた貼り付けておきます。
この画像はコミュニケーションアドベントカレンダー 1日目で話題にした コミュニケーションって何をすることなの？ でも使いました。
ヤバイですね。
僕が気をつけていること
そういう背景もあり、僕が会社でコミュニケーションを取るときに気をつけていることを書きたいと思います。
予め断っておきたいのですが、これらのことが全て常にできているわけではありません。
しかし、こういったことを意識することによって毎日今日の自分を振り返った時に「あの時はあそこも説明したほうが良かったかな？」とか「あの話をしてた時は若干適当に理解しちゃった部分があったからもっと細かく聞いたほうが良かったな」といったことに気がつくことができるのでより良い明日を過ごすことができます。
では話を戻して僕が気をつけていることです。
あえて聞く
まず最初はあえて聞くことです
- これってどうするんだっけ？
- そもそもなんでそうなってんだっけ？
と言った基本的なことです。
当り前すぎることかも知れませんが、意識しないと意外となんとなくの理解で話が進んでしまいます。
よく、「分からないことが分からない」みたいに言われますけど、まさにその通りでなんとな〜く話してると分からないことが分からないまま話し合いが終わって何のために話してたのか意味が分からなくなります。
せっかく時間を取って話すのでしたら、しっかりと話し込みましょう。
目安としては自分の言葉で説明ができるレベルに理解できてれば大丈夫だと思います。
なので僕は話を聞いている時にしょっちゅう「それってこれこれこういうことか」という感じで自分の言葉でちょっと話して見るようにしています。
これで上手く言葉が見つからないようなら理解が不足していると考えています。
またこれに関しては逆も然りで、自分が話しているときは相手に説明してもらうことで相手が理解しているかを把握することができます。
的はずれな答えが返ってきたら相手が理解できていないので、スタート地点よりも前に戻ってしっかりと説明する必要があると思います。
実際に見せる
百聞は一見にしかずというように実際に見せるのは凄く良い方法です。
- 図にしてみる
- コードにしてみる
- UIを作って見せてみる
といったことをよくやります。
まず 1 の 図にしてみる はソースコードの設計を行う段階でよく用います。
A というモジュールが B というモジュールを内包していて...
などと細かく説明するより、ホワイトボードに四角と矢印を書いて説明したほうがわかりやすいです。
そしてそれを写真にとって issue に貼り付けておけばなお良しです。
例えばこんな感じです。 文字でくどくど説明するよりはわかりやすそうですね。
次に2の コードにしてみる は何か説明するときにコードを書きながら説明することです。
例えば Java とかのジェネリックってどういう時に便利なの？
とか聞かれた時に、言葉でくどくど説明してもジェネリックがよく分かってない人にとってはポカーンだと思います。
なのでそういう時は実際にコードを書いて、「こういう時にこういう理由で困るじゃん！」「でもジェネリックがあればこういう風に解決できる」みたいな感じで実際に動かしながら、あるいは開発環境が発する警告を見せながら説明ができるので理解が早まります。
そして最後は UIを作って見せてみる です。
これは、アプリの UI をどういう感じにするかみたいなときによく使います。
例えば、ボタンの押した時のアニメーションの具合とかを言語化するのはかなり難しいです。
「ふよ〜んって感じ」っていきなり言われてもよく分かりません。
なので、とりあえず参考になる他のアプリの UI を見せて説明したり、もしくは自分で似たようなものを作ったことがあればそれを見せたりします。
またアニメーションに限らず画面の遷移なども言葉にするのは難しいです。
言語化するのが難しい物に関しては、実際に見せるのが大事です。
「なんかいい感じにお願い！」は危険！！！！！！！！
自分の考えを細かく提案する
ある事柄について自分自身の考えを細かく述べます。
これには
- 自分自身の考えをまとめる段階で自分の中で考えがまとまる
- 1 により自分の理解が不十分な所が明確になる
- そもそも考える必要がないという指摘をもらえる
- 全体でもう一度考えなおすきっかけになる場合もある
といった効果があります。
これは僕はある事柄について一定以上の不安要素が溜まった場合に発動させます。
例えば issue の運用方法などで一応は運用方法があるけど、最近守られてなかったりして疎かになってるな...? って思う頃に「こういう風に issue を運用すべきじゃない？」という感じで細かく提案します。
そうすると、「そもそも issue はなんのために作るのか？」といったことを考えるきっかけになったり、他のメンバーから「そこまで決めると手間がかかるから辞めたほうが良くね？」といった意見を貰えたりします。
こうすることで各々がどのように考えているのかも把握できるのでその上で、より良い方法を模索したりすることができるようになります。
ふわふわした状態で議論を行うのではなく、色々と細かく定まった状態から議論を始めると前提条件が一致した状態で話し合うことができるので比較的スムーズに話が進むと思います。
今回は僕が日常的なコミュニケーションで意識していることについて説明してみました。
他にも沢山意識していることがあるとは思いますが、めちゃくちゃに長くなりそうなのでこのぐらいにしておきます。