多様なチームを動かす「共通言語」としてのロジック
〜プロジェクトを通して再認識した、コミュニケーションの基礎〜
0. はじめに
現在のプロジェクトは、「国籍・会社・業務経験」がバラバラな混成チームです。そこで痛感したのは、これまでの阿吽（あうん）の呼吸」や「言わなくてもわかるだろう」という甘えは、多様なメンバー間ではリスクでしかないということです。
背景が違う者同士が最短距離で成果を出すために必要なのは、感情やニュアンスではなく 「ロジック（論理）」という共通言語 でした。今回は、私が現場で学び直したコミュニケーションの3つの基礎を共有します。
1. 相手の期待値を把握する（ゴールの定義）
コミュニケーションの失敗の多くは、「何を話すか」ではなく 「相手が何を求めているか」のズレ から起こります。
期待値を外さないための3ステップ
- 目的の確認: 相手は「ただの報告」が欲しいのか、「具体的なアドバイス」が欲しいのか、あるいは「意思決定」をしてほしいのかを見極める。
- 着地点の共有: 「この話が終わった時、どういう状態になっていればよいか」を合意してから本題に入る。
- 時間軸の把握: 「今すぐ結論が必要」なのか、「時間をかけて検討したい」のか、スピード感の期待値を合わせる。
事例：目的を持つ話し方
NG：「この改修、なるはやでいい感じにお願い」
結果：1週間後に「期待と全く違うもの」が出てくる
OK：「目的は明朝のデモ用。範囲はログイン画面のみ。精度はモックレベルでOK。今日の18時に一度見せて」
Point：「何を・いつまでに・どのレベルで」 を定義する。ロジカルシンキングの基本「目的の明確化」を徹底します。
2. 質問を正しく理解する（問いの構造化）
相手の言葉を自分の勝手な解釈で受け取らず、論点を整理して打ち返します。
事例：質問の型を把握した上で話す
不透明なやり取り
メンバー: 「仕様、A案とB案どちらがいいですかね？」
PL: 「Aの方がユーザーには親切かな。あ、でもBの方が実装は楽だよね。検討してみて。」
結果: メンバーは「判断」を求めているのに、PLが「感想」を返したため、意思決定が停滞する。
ロジックによる構造化
PL: 「 『どちらにするか、今、私が判断すべきか？』 という質問ですね。結論、Aで行きます。」
理由: 「今回の最優先事項が『UX向上』だからです。工数増はスケジュール側で私が吸収します。」
Point: 相手の問いを「事実の確認」なのか「意思決定の依頼」なのか構造的に捉える。
3. Talk Straight で話す（結論と根拠の提示）
背景が違うからこそ、遠回しな表現は「ノイズ」になります。まず結論から話すことが、チームに対する最大の誠実さです。
事例：進捗確認への回答
NG（状況が見えない） 「あー、API連携の件ですね。一応メールはしたんですけど、時差もあって返信がまだで。マニュアルも読んだんですが、仕様が特殊みたいで……。まあ、週明けにはなんとか……」
OK（Talk Straight）
「結論から言うと、API連携の実装は現在ストップしています。」
- イシュー: 認証認可の仕様が不明確であること。
- 答え: 現状では実装不可能です。
- 理由: 先方からの技術回答が届かない限り、セキュリティ要件を満たせないため。
- 事実と判断: 昨夜から回答待ち状態です。経験上、回答に3日はかかるため、その間は別タスクを優先します。
Point： 結論から話す (PREP法) 結論（Point）→ 理由（Reason）→ 具体例（Example）→ 結論（Point）の順で構成し、相手の脳の負担を減らします。
まとめ：ロジックはチームへの「敬意」
ロジカルに考え、ストレートに伝えることは、冷たいことではありません。
- 期待値を数字と期限で示す
- 質問の意図を構造化して捉える
- 結論を根拠（事実＋経験）と共に示す
背景の違う多様なメンバーが、お互いの時間を尊重し、プロフェッショナルとして信頼し合うための「架け橋」がロジックです。この共通言語を磨き、最高のチームを作っていきましょう。
