不確実性を減らすコミュニケーションのコツ

はじめに

こんにちは！
株式会社ココナラの募集部のマーシャです。７年くらい前に日本に来て、６年間日本で働いています。私はコミュニケーションの専門家ではありませんが、西洋文化圏から来ており、内向的で、見た目も異なるため、コミュニケーションの違いに気付きやすく、それがなぜそうなるのか、どうすればより効率的にできるのかを考える傾向があります。今までの経験を通じて、以下で具体的にお話ししますが、いくつかの一般的なコミュニケーションパターンに気づきました。これらの一部は文化に起因し、効果を発揮しています。しかし、それらを認識し、少し努力することでさらに職場でのメリットを得ることができると思います。また、コミュニケーションをより親しみやすくするために絵文字を使用するような一般的なアドバイスではなく、実践的な戦略に焦点を当てていきます。

※ 研究大学出身で論文のように固く書く傾向がありますが、基礎的な話なので、ぜひ一回読んでほしいです！

そもそもなぜこの話をしたいのか？

スタートアップの急速な世界では、効果的なコミュニケーションは単なるソフトスキルではなく、プロジェクトの成否を左右する重要な要素です。技術的な専門知識や革新的なアイデアが必要であることはもちろんですが、これらのアイデアを伝え、タスクを調整し、フィードバックを提供する方法が成功を決定づけることがよくあります。当社では、すでにしっかりとしたコミュニケーションと仕事の文化の基盤があり（株式会社ココナラの文化について興味がある方は、是非カルチャーブックをお読みください）、オープンで直接的なコミュニケーションが容易です。しかし、個々人がコミュニケーションをさらにスムーズに進めるためにできることはまだたくさんあります。

三つの一般的なコミュニケーションパターン

曖昧さ

文化的曖昧さ

世界中ではローコンテキストとハイコンテキスト文化が存在しているというのはみなさんご存じだと思います。日本はハイコンテキスト文化であり、半分以上のコミュニケーションは雰囲気やボディランゲージなどに依存します。なので、的確に話さないような傾向があります。この文化によって、半分意識的に曖昧さが生じます。私の経験では、この種の曖昧さが最も一般的なコミュニケーションパターンです。大規模なレベルでは、知識が足りない時にキャッチアップ時間を与えたり、他部門とのコミュニケーションを円滑にすることができます。例えば、全社的なプロジェクトで部門間の調整が必要な場合、このような曖昧さは一時的な猶予を与えてくれます。

しかし、小さなチームや特にスタートアップでは、誤解やミスコミュニケーションの温床となり、時間の浪費やフラストレーションを引き起こします。例えば、明確なスコープやタスクの分解、リーダーシップがないプロジェクトの一般的な方向性だけで作業することを想像してください。それを、タスクやプロジェクトのマイルストーンや目標が明確なプロジェクトと比較してみてください。間違いなく後者のプロジェクトの方が取り組みやすいと思います。

このような場合、私は大抵、シンプルな「なぜ/何/どこ」の質問をします。「なぜこのタスクが必要なのか？」「具体的に何を達成すべきか？」「どこでその情報を得られるのか？」といった質問です。これにより、同僚から驚かれることもありますが、常に前向きな経験に繋がります。回答を得たり、必要な議論を始めたり、答えを探す場所を指示されたりします。最悪の場合、自分で答えを見つける必要がありますが、その過程で多くを学ぶことができます。

知識や視点の差で生じる曖昧さ

時にはコミュニケーションにおいて、文脈や小さな詳細が欠けていることがあります。これは特定のタスクを完了するために必要な情報が不足していることで、意図せずに発生することが多いです。特に異なる分野の人々の間では、文脈や視点、知識の違いによってギャップが生じやすくなります。

例えば、新しい機能を実装している際に、デザイナーが「デザインファイルと同じように見えないのでボーダーを修正してほしい」と頼むことを想像してください。このような指示は、特にページに複数のボーダーがある場合、少し曖昧に聞こえるかもしれません。どのボーダーを指しているのか、どのように間違っているのかが明確でないため、具体的な指示があるとよりスムーズに作業を進められます。

このような状況では、具体的な質問をし、チームミーティングで他のメンバーの意見を求め、「この理由で、これをこうしてくれると助かります」という具体的な理由を添えたフィードバックを提供することが効果的です。

抽象化の不足

異なる分野の人々とのコミュニケーション

異なる分野の人と話す際によく見かけるのは、抽象化不足というパターンです。これは、異なる分野の同僚が同じプロジェクトに関わっている場合、専門用語の使いすぎなどでコミュニケーションがうまく進まないことです。意識的か無意識的かは私に判断できませんが、異なる分野の人と話す際に「え？」という表情や反応が見られることがよくあります。

全く異なる分野の人に何かを説明する場合、私は抽象化を使っています。例えばエンジニアであるあなたが、おばあちゃんにAPIが何であるかを説明しなければならないと想像してください。「HTTP」「サーバー」「クライアント」といった言葉は使わないですよね？クロスファンクショナルチームで作業する際も同じ状況です。非エンジニアに技術的な複雑さを説明するのは挑戦です。例えば、おばあちゃんには「パソコンや携帯を使うとき、複数のプログラムが同時に動いています。時々、一つのプログラムが別のプログラムから情報を必要とすることがあります。そのときにAPIを使います。APIはどの情報が必要か、そしてその情報を取得してよいかを示し、情報を共有します」と説明することができます。それでも話がうまく進まない場合は、抽象化のプリンシパルを保ちながら比喩を使って説明することも有効です。たとえば、「APIは工場と都市をつなぐ列車のようなもので、都市に必要なものを運び、注文によって異なるものを運ぶことができます」と説明することができます。彼女はすべての詳細を知る必要はなく、コンセプトを理解すればよいのです。

このように抽象化を使うことで、おばあちゃんや異なる分野の同僚と一定のレベルでコミュニケーションをとることができるようになります。

複雑なものの実装

さらに深掘りしてみると、よく見かけるのは自分の作業を抽象化しないというパターンです。これは、自分が何かを実装する際、特に複雑なものに関して、わかりやすくまとめられないことです。その結果、上司が部下に実装やリードを任せて自分の作業に集中したいのに、安心できずにマイクロマネジメントが発生することがあります。最終的に、このような状況はプロダクトの質に悪影響を与え、社員自身の成長やキャリアの進展を遅らせることにもつながります。

そこで、抽象化はプロジェクト管理や進捗確認において非常に有効です。大きな機能を小さなマイルストーンや目標に分解することで、関係者とのコミュニケーションが円滑になります。これにより、プロジェクトの進行状況を具体的に説明しやすくなり、関係者の理解を得やすくなります。例えば、大規模なプロジェクトを実装している場合、マネージャやPMと話す際には、細かいタスクよりも大きなステップごとに進行状況を説明します。「このステップはこの日付までに完了する予定です」といった具体的な目標や課題を抽象化して伝えることで、上司がさらに上の関係者と連携しやすくなります。また、チームメンバーも目標が明確になるため、小さなタスクや実装を調整しやすくなります。

このように抽象化を活用することで、プロジェクトの管理がより効率的になり、全体的な成果が向上し、個々の成長にもつながります。

フィードバックの不足

フィードバックを伝える

フィードバックがあまり重要視されないケースもよくあります。しかし、フィードバックの提供はプロジェクトの成功と個人の成長において非常に重要です。よくあるのは、同じ問題に何度も悩まされるのにフィードバックをしなかったり、困りごとを伝えても解決すべき理由を伝えないため、単なる文句になってしまうことです。フィードバックがない、またはその問題を解決する必要性が伝わらないと、誰も問題を解決できません。その結果、問題が悪化したり、プロダクトの質が低下したりします。

私がフィードバックを伝える際には、伝え方を特に意識しています。例えば、「この部分をこう改善すると、作業がより効率的になると思います」といった具体的なフィードバックを提供することで、受け手にとって分かりやすく、実行しやすくなるように努めています。現実的な例を挙げると、運用フローやタスク管理、開発に関連する情報が複数のツールに散在している場合、チームミーティングで「情報を探すことで情報漏れと時間の浪費が発生しているため、コンテンツ一覧のような入口ページを作成したらどうでしょう？」といったように、問題点とその影響、そして提案（あれば）を伝えることで、ワークフローを円滑にし、小さな問題を早期に解決できます。

このように具体的なフィードバックを提供することで、問題の本質を理解しやすくし、効果的な改善策を見つけやすくなります。

フィードバックを求める

フィードバックを提供するだけでなく、積極的に求めることも重要だと思います。これは主にＤＭや１ｏｎ１の場で行われるため、外からは見えにくいかもしれませんが、自分の改善点を見つけるためには、第三者の視点を取り入れることが大切な行動です。

例えば、自分がどの方向に進むべきか悩んでいる時や、しばらく良い評価ばかりを受けている場合には、マネージャーとの１ｏｎ１ミーティングで詳しくフィードバックを求めたり、尊敬する同僚にアドバイスを求めたらいいと思います。私自身も、経験が足りない時や、困っていることから視点を少し離れてもどうすればいいか分からない時はマネージャーやより経験豊富な同僚からフィードバックを求めます。その際には、自分が一番困っていることとなぜ困っているかを明確に伝えます。こうしたフィードバックはポジティブな刺激となります。その刺激があるからこそ、自分自身の成長や改善を促進するだけでなく、他のメンバーも同様の問題に気づき、全体の改善にもつながります。

最後に

ここで紹介したのは、私がよく目にするパターンの一部であり、必ずしもすべての職場やチームに当てはまるわけではありません。しかし、コミュニケーションは非常に強力なツールであり、チーム間のコミュニケーションをスムーズにすることも、逆に混乱を招くこともあります。この記事が、皆さんが自身やチームに最適なコミュニケーション方法を考えるきっかけとなり、ワークフロー効率化に繋がることを願っています。