こんにちは！！iOSアプリ開発グループ 機能開発チームの中山 龍(@ryu_develop)です！
2026年3月1日でChatworkは15周年を迎え、その"15"にちなんで15本のブログリレー企画を実施しています！
ということで、来月で新卒入社から3周年を迎える自分が本日の kubellブログリレー の記事を担当します
自分は去年の7月にiOS機能開発チームのリーダー(現: サブリーダー)に就任し、それから8ヶ月ほどが経過しました。また、去年の1月からプロダクト組織のインナーコミュニケーション活性化も担当させていただいています。
その中でチームメンバーや上長はもちろん、他チームや他職種の方々とコミュニケーションを取る機会も増え、「どう伝えれば相手にちゃんと届くか」を強く考えるようになりました。
今もより良いコミュニケーションのために日々試行錯誤していますが、現時点で自分が意識していることをお伝えします。
#kubellブログリレー
目次
はじめに
相手と上手くコミュニケーションを取ろうと思うと、話す内容はもちろん、話し方、表情、関係性、ジェスチャー…など挙げ始めるとキリがないほど多くの要素があると思います。
その中でも本記事では「伝える」を中心に「内容と伝え方の設計」に焦点を当てて書くこととします。
自分が「伝わり、目的が達成されるコミュニケーション」のために意識しているのは、以下の4つのポイントです。
- なぜ伝えるのか — 自分のゴールを明確にする
- なにを伝えるか — ゴールから逆算して情報を絞る
- どんな粒度で伝えるか — 相手に合わせて調整する
- どのように伝えるか — 心情への配慮と機会の設計
1つずつ見ていきます！
なぜ伝えるのか
何かを伝えようとするとき、自分が最初に考えるのは「なぜ伝えるのか」です。言い換えると、伝えることで自分が達成したいゴールは何か、ということです。
たとえば、以下のようなゴールがあると思います。
- 認識を揃えたい: 相手が必要な情報を知っている状態にしたい
- アクションを促したい: 相手に具体的な行動を起こしてほしい
- 合意形成がしたい: ある方針や決定について合意を得たい
- 相談・議論がしたい: 一緒に考えて、よりよい結論を出したい
「なぜ伝えるのか」を意識するだけで、伝える内容や伝え方が自然と変わってくると感じています。逆に、ここが曖昧なまま伝えようとすると、「結局何が言いたいんだろう？」と相手を困惑させてしまうこともあるでしょう。
プロジェクトのキックオフミーティングを主催することを例に考えてみましょう。「プロジェクト」というと、始動したキッカケや目指したい状態、関係者、具体的に実施したい手段の詳細、現時点で見えているリスク、プロジェクトメンバーの紹介…といった感じで、ぱっと思いつくだけでも伝えられる情報はたくさんあります。
キックオフを「達成したいゴール」が決まっていない状態で実施しても、自分が持っている情報を思いついたままに伝えることとなり、終わった後にメンバーから「結局、自分たちは何をすればいいんでしたっけ？」と聞かれることもあるでしょう。
それは「なぜ伝えるのか」(伝えることで何を達成したいか)が明確でないまま、自分が伝えたいと思ったことをひたすら聞き手に伝えるだけになってしまうからかもしれません。
そこで「プロジェクトチームが協働するための一体感が生まれている状態になっている」「プロジェクトの前提が揃い、直近2週間のアクションが実行できる状態になっている」などといったゴール(「なぜ伝えるのか」)を明確にすることで、それぞれの場合で「なにを伝えるか」を考えるための軸が見えてくると思います。
なにを伝えるか
「なぜ」が定まったら、次は「なにを伝えるか」です。
自分はここで、ゴールから逆算して必要な情報を洗い出すようにしています。
- アクションを起こしてもらいたいなら → その目的を伝える
- 目的に納得してもらいたいなら → 背景や経緯を伝える
- 承認・合意を得たいなら → 影響範囲やリスクを伝える
伝えたいことが多いと、つい全部詰め込みたくなります。でも、ゴールに対して必要な情報を絞ることが大切です。情報が多すぎると、かえって本質が伝わりにくくなってしまうことがあるからです。
先ほどのキックオフの例で考えてみます。「プロジェクトチームの一体感が生まれている状態」をゴールにするなら、プロジェクトが始まった背景やこのチームで取り組む意義、メンバーそれぞれの役割と期待を伝えることが大切になりそうです。一方で、実装の詳細やリスク一覧は、キックオフの場では優先して伝える必要はないと判断できます。
また、「直近2週間のアクションが実行できる状態」というゴールを設定するのであれば、逆に具体的なタスクの割り振りやスケジュール、最初に着手すべきことを伝える必要があります。背景やビジョンの話に時間を使いすぎると、「で、明日から何をすれば？」という状態になってしまうかもしれません。
このように、同じキックオフであっても、ゴールが違えば伝えるべき情報も変わってきます。「あれもこれも」と全部盛り込みたくなる気持ちをぐっとこらえて、ゴールに必要な情報に絞ることが大切になります。
どんな粒度で伝えるか
同じ内容でも、伝える相手によって最適な粒度は変わります。自分が特に意識しているのは、相手の立場と相手の知識の2つです。
相手の立場
マネージャーや執行役員など、上位のレイヤーの方ほど関心は抽象的な方向にあり、大きな方向性や事業へのインパクトが重要なポイントになります。
一方で、現場のメンバーであるほど、関心は具体的な方向に向いており、実装の詳細やタスクの進め方など、日々の業務に直結する情報が大切です。
この使い分けを意識するだけで、相手にとって「聞きたい話が聞けた」という体験につながると考えています。
プロジェクトを進める際の例でいうと、たとえば上長にプロジェクトの概要を報告する場面では「このプロジェクトはユーザーの○○という課題を解決するもので、リリースは△月を目標にしています」のように、事業的なインパクトとスケジュール感を中心に伝えると関心に合いやすいと感じています。
一方で、プロジェクトメンバーへは「最初の2週間でAPI設計とUI実装を並行して進める必要があります。○○さんはこのタスクから着手してください」のように、具体的なアクションレベルまで落とし込んで伝えた方が、すぐに動き出せる状態になると思います。
相手の知識
職種による違い
職種によって持っている知識(専門領域)が違うため、伝え方を変えることを意識しています。
エンジニア同士であれば、技術的な用語や概念をそのまま使うことができます。テクニカルな話をダイレクトに共有できるのはありがたいです。
PdMやデザイナーの方はエンジニアとは専門性が違うので、技術的な詳細をそのまま伝えてもピンとこないことが多いと思います。なので、動作や見た目、ユーザー体験など、相手の専門領域に近い観点で話すとスムーズに伝わります。技術的なことに起因する話をする場面では、なるべく抽象化して伝えるようにしています。
ビジネス職種の方はプロダクト開発の職種と専門性が違うので、よりユーザーから見えるプロダクトに近い観点で話すのがよいと思います。プロダクト・技術的なことに起因する話をどうしてもする場合は、基礎的なところから丁寧に説明するように心がけています。
特にエンジニアは「技術観点で物事を伝えようとしてしまう」というのはやりがちなのではないでしょうか？自分も新卒1年目の頃を振り返るとよくやってしまっていたなと思います。
「自分の専門領域で正確に詳細に伝える」から「相手の専門領域に寄せてわかりやすく伝える」へ意識を変えてみると相手に伝わりやすくなる実感が得られると思います。
相手の社歴や経験による違い
シニアなメンバーであれば、プロダクトに関する前提や過去の意思決定の経緯も共有されている状態なので、比較的スムーズにコミュニケーションが取れます。
一方で、ジュニアなメンバーやまだ入社して間もない方には、プロダクトの背景や前提を丁寧に説明しながら進めた方が、認識が揃いやすいと感じています。ここを端折ってしまうと、「なんでこうなっているんだろう？」というモヤモヤが残ってしまうかもしれません。
また、シニア・ジュニア両者がいる機会では手厚い説明は必要以上にシニアメンバーの時間を奪ってしまったり、わかっている前提での薄い説明ではジュニアメンバーがついてこられなかったりと両者のバランスを取った伝え方をするのは大変難しいです。
そのため、自分の場合は事前にジュニアメンバーへの説明・ケアを行った状態で全体の場を迎えるようにすることが多いです。
どのように伝えるか
最後に、「どのように伝えるか」についてです。自分が意識していることは主に2つあります。
相手の心情に寄り添う
伝える内容によっては相手をネガティブにさせてしまうもの、モチベーションを低下させる可能性があるもの、逆にモチベーションが上がりすぎて権限と責任を超える行動をしてしまう可能性のあるものなどもあると思います。
なので、「これを伝えると相手はどのような気持ちになるか」というのを事前に想像しながら相手の心情に寄り添った伝え方をするように心がけています。
具体例として、伝える内容が相手にとってネガティブに受け取られ得るものであれば、寄り添うような伝え方を心がけています。「自分も同じように感じている部分はあるけれど、一緒に乗り越えていきましょう」といった感じです。
逆に、自由度が高すぎて方向性がバラけそうな場面では、少し厳格に伝えることも大切だと思っています。「みなさんの個性を発揮してもらいつつ、合意形成のプロセスはしっかりやっていきましょう」といった感じです。
相手の心情に合わせてトーンを使い分けることで、メッセージの受け取られ方が大きく変わると感じています。
伝える機会を設計する
伝え方だけでなく、伝える機会そのものを設計することも大切にしています。
本記事で例として扱っている「プロジェクトのキックオフミーティング」も伝える機会の１つです。
また、日常的にアップデートを共有したり、継続的に意思決定が必要な場合は、定期的なミーティングとして機会を設けるようにしています。その際、ミーティングの趣旨や目的を事前に参加者へ共有しておくと、機会の効果が高まります。
全体の場で伝える前後に、個別で伝えた方がより効果が期待される場面もあります。全体の場では発言しづらいけれど思うところがありそうな方や、伝える内容によって受ける影響が特に大きい方に対しては、1on1を事前・事後に設けて、個別に不安を解消したり、詳細な意図を説明したりしています。
全体への共有と個別のフォロー、この両方を組み合わせることで、チーム全体のコミュニケーションがスムーズになると感じています。
具体例として、自分のチームでは各種プロジェクトの情報が属人的になってしまうのを防ぐためにプロジェクトミーティングで意思決定されたことに関して共有を行う「情報共有会」や、チームでのAI活用を推進するためにチームの活用状況やノウハウを共有し合う「Learning Session」といった機会を導入しました。
また、その機会以外にも必要に応じて単発的にプロジェクト担当者へ個別にヒアリングやサポートを行ったり、期初や期末にはチームの目標関連で伝える機会を設計することが多いです。
まとめ
ここまで、自分が「伝える」ときに意識していることを整理してみました。
- なぜ伝えるのか（自分のゴール）を明確にする
- なにを伝えるかをゴールから逆算する
- どんな粒度で伝えるかを相手に合わせて調整する
- どのように伝えるかで相手の心情や場の設計まで考える
これらのポイントを押さえることで、チームや組織を率いる方に限らず、日常的に周囲を巻き込んだり合意形成をする方にも活かしていただける内容だと思います！
また、余談ではありますが、AIエージェントとのコミュニケーションでも、自分の目的を達成してもらうために、コンテキストを考慮しながら必要な伝え方をプロンプトで行うという点でいえば、これらのポイントは大きく変わらないものだと思います。
この記事の内容があなたの「伝わり、目的が達成されるコミュニケーション」のための参考になれば幸いです。
