多国籍チームで意見が合わないときは？文化の違いで片づけない話し合い方

「合わない」と感じた場面を、観察できる言葉にする

最初に、反対された提案と、相手が実際に言ったことを書き出します。「相手はいつも否定的だ」では、次に何を聞けばよいか決まりません。「改善案を見せたら、運用担当への確認が済んでいないと言われた」なら、必要な確認を具体化できます。

「自分の案に賛成しなかった」は観察できる出来事です。一方で、「自分を信用していない」「あの国の人は議論が好きだ」は、自分が付けた解釈です。解釈をそのまま質問にすると、提案の話が相手の性格を評価する話に変わってしまいます。

GitLabは公開している価値観で、人物と仕事を分けています。提案する対象は、人物そのものではなく仕事の具体例です。ここでも、相手の属性を説明するより、どの資料・判断・行動を確かめたいのかを示してみましょう。GitLabの仕事と人物を分ける考え方

言い方に負担を感じた場合は、その点も切り分けて伝えられます。「提案の懸念点は確認したいです。その前に、最後まで説明する時間をもらえますか」と、進め方の希望を具体的に言います。ただし、侮辱や差別的な発言、威圧を、受け止め方の工夫だけで処理する必要はありません。安全やハラスメントに関わる場合の相談は、後半で分けて扱います。

言葉と目的の違いを、短い質問で確かめる

反対の理由を聞くときは、「なぜ分かってくれないのですか」より、「どこで判断が分かれていますか」と論点を絞ります。順番は固定せず、食い違っている箇所から確認してください。

• 目的：誰の、どんな困りごとを解決したいのか。速く出すことと、問い合わせを減らすことなど、別の結果を優先していないか。
• 言葉：「ready」「simple」「urgent」などが指す状態は同じか。確認用の案なのか、そのまま公開できる完成版なのか。
• 制約：変えられない期限、必要な承認、使える人員・予算、守るべき安全・品質条件は何か。
• 根拠：同じ期間・対象・版の情報を見ているか。実測、顧客の声、過去の経験、未確認の見込みを区別できているか。
• 判断基準：どの条件を必ず満たし、満たした案の中では何を優先するか。最終的に判断する権限を持つのは誰か。

たとえば、相手が「ready」と言っただけでは、確認に出せるという意味か、顧客向けに公開できるという意味かは確定しません。単語の辞書的な意味を知っていても、今回の作業に当てはめて聞く必要があります。

話す速さや略語の多さで追いづらいときは、要点を書いてもらい、略語を正式な名称に直して確認します。相手にも読み返す時間を取り、「ここまでの理解で違う点はありますか」と確かめましょう。発言が短いことや沈黙を、国籍や意欲の説明に使わないことも大切です。

自分の理解を言い換えて戻すことも役立ちます。ただし、言い換えは賛成の表明とは分けましょう。理解したうえで、別のリスクを指摘してもかまいません。

文化や過去の職場の習慣が関係しそうなら、本人に希望を聞きます。「会議中と、資料を読んでから書く方法では、どちらが話しやすいですか」と尋ねてみましょう。国全体の代表として説明を求めたり、出身地を理由に希望を決めたりしないでください。意見を尋ねる言い回しを増やしたい場合は、相手の意見を聞く英語フレーズも参考になります。

上司と担当範囲や完成条件が食い違っている場合は、海外の上司と仕事の期待をすり合わせる方法で、今回の仕事の前提から整理できます。

架空例　ヘルプページの改善案を同じ基準で比べる

ここからは、多国籍のサポートチームで働くMikaとJordanが、顧客向けヘルプページの改善について話す架空例です。Mikaは「全体の案内構成を変える案A」、Jordanは「初期設定の6ページを先に直す案B」を提案しています。国籍と提案の傾向は結び付けていません。

最初の会話では、Mikaは「部分修正では探しにくさが残る」、Jordanは「全体を変える時間が足りない」と主張し、議論が止まりました。二人は、いま決める対象を次回更新でどこまで変更するかに絞ります。将来の全面改善まで否定・承認する会議にはしません。

事実と、まだ確かめていないことを分ける

先月の問い合わせ60件のうち、18件に初期設定の困りごとが含まれていました。二人が確認したのは、この集計です。これは問い合わせをした人の記録で、全利用者の30％が困っている証拠にはなりません。また、「ガイドが見つからない」のか「読んでも操作が分からない」のかは、まだ分けて集計していません。

この段階で「構成が原因だ」「説明文が原因だ」と決めず、問い合わせの内容を確認できる担当に分類を頼みます。顧客情報は、閲覧を認められた範囲で扱ってください。分類に間に合わない情報は、推測で埋めず、判断の限界として残します。

作業には、編集担当2人が3営業日を使えます。変更箇所の内容確認と、公開承認も必要です。既存リンクを壊さず、内容の正確さを確認できることを必須条件にします。その条件を満たす案の中で、初期設定の困りごとに対応できる範囲と、必要な作業量を比べることにしました。

自分の案にも、同じ基準を当てる

Atlassianが公開するDACIの手順では、関連データ、判断に使う要素、検討した選択肢を整理し、決める人を明確にします。この表は、その考え方を参考に編集部が作った例です。DACIの役割名や、今回の比較項目をすべての職場に導入する必要はありません。AtlassianのDACI意思決定フレームワーク

点数を付けるなら、配点の理由や優先順位も合意が必要です。小数点まで並べても、元の見積もりが不確かなら判断の確かさは増えません。まず「必須条件を満たすか」「何が未確認か」を書くだけでも、次に集める材料が見えます。

この比較では、案Aがいつでも悪く、案Bがいつでも正しいと結論づけることはできません。今回の期限と確認体制では、案Aをそのまま進める材料が不足しています。全面変更の見積もりが取れれば、選択肢が変わる可能性を残します。

まだ出ていない視点を集める

二人の案だけで判断すると、変更の影響を受ける人が抜けることがあります。例のヘルプページなら、日々問い合わせを読む人、ページを管理する人、公開を承認する人が、別の材料を持っているかもしれません。会議にいた人の人数より、必要な知識や影響範囲がそろっているかを見ます。

GitLabの意思決定ガイドは、判断者が関連するデータや経験を持つ人の意見を求める運用を示しています。参加者にも、有用な情報を持つ他の人の参加を促すよう勧めています。これは同社の役割設計であり、自社の決裁権限を置き換えるものではありません。GitLabの意思決定ガイド

その場で発言しなかった人を「関心がない」「賛成している」と扱わず、何について意見がほしいかを具体的に伝えます。突然指名して答えを求めるだけでなく、資料に書き込む時間を設ける方法もあります。AtlassianのSparringでは、対象の仕事と背景を共有し、黙って書く形で意見を集める方法も紹介されています。Atlassianのフィードバックを集める手順

必要な回答の期限と、その意見を誰が判断に使うかも伝えます。会議外で返す人がいるなら、受け取る前に「全員が確認済み」と記録しません。特定の国籍の人へ、その国の顧客や同僚全員の考えを代弁するよう求めることも避けます。

勤務時間が重ならず、文章で意見を集める場合は、海外リモートの非同期コミュニケーションも参考になります。ここでは、返信方法だけでなく、誰の知識が判断に足りていないかを確かめます。

決定と、解消していない懸念を一緒に残す

材料を集めても、全員が同じ案を最善と思うとは限りません。話し合いの終了条件を「全員の好みが一致すること」だけにすると、結論を出せない場合があります。自社の手順に沿って、誰がどの範囲を決めるのかを先に確認します。決裁権限を持たない参加者同士で、公開や予算を約束しないようにしましょう。

架空例では、公開責任者のLeeが比較表と担当者の確認結果を見て、今回の更新は案Bを採用すると決めました。Mikaは全体の探しにくさへの懸念を残しています。記録には、Mikaまで案Bが最善だと考えたかのような「全員一致」を書かず、選択した理由と懸念を分けます。

今回の決定と判断者

Leeが2026年10月15日に、初期設定の6ページを修正する案Bを今回の更新方針として採用。これは個々の修正原稿の公開承認とは別。

理由

既存のURLと案内構成を維持し、確保した3営業日で修正・内容確認を行えると担当者が確認したため。公開前の最終承認は引き続き必要。

残った懸念と未決事項

全体の探しにくさは残る。問い合わせの原因別集計は未完了。案Aの効果や工数はまだ判断できず、全面変更は承認していない。

次の対応

Jordanが変更箇所と確認結果をまとめ、Leeへ公開承認を依頼。Mikaはページ管理担当と案Aのリンク影響・工数を調べ、10月22日の確認会へ持ち寄る。

判断を戻す条件

案Bでも必要な内容確認を終えられない場合は、公開前にLeeへ相談する。案Aの見積もりや問い合わせ分類がそろったら、次回改善の範囲を再検討する。

採用されなかった案は、提出者の評価とは切り離します。後から新しい事実が出たときも、「負けを認めなかった」と扱うより、どの前提が変わったかを確認しましょう。決定後に変更を提案する場合は、権限を持つ人へ戻し、元の決定を黙って変更しないようにします。

会議後の決定・対応・未決事項を英語で共有する書き方は、英語の議事メモと会議後メールで練習できます。ここでは、記録を短くするために反対理由まで消してしまわないことが大切です。

話し合いが進まないとき、相談先を変える

同じ主張を繰り返しているときは、「何が分かれば次へ進めるか」を一つ決めます。数字が食い違うなら、集計条件を確認できる人へ相談します。担当部門の利害がぶつかるなら、部門間の判断権限を持つ人に相談しましょう。承認者が不明なら、案件の責任者に確かめます。相手を説得できなかったと訴えるより、判断が必要な論点と影響を伝えます。

案を試して比べる方法もありますが、許可された範囲、担当、期間、確認する結果、やめる条件を先に決めます。「小さな実験だから」と顧客データを社外へ出したり、本番の設定を権限なく変えたりすることはできません。比較のための作業自体に費用や他部署の負担があるなら、その承認も必要です。

侮辱・差別・威圧や安全の問題は、通常の意見調整と分ける

出身国や人種などへの侮辱、繰り返す威圧、報復への不安、安全や情報管理上の問題がある場合、本人同士の話し合いで解決することを前提にしないでください。「文化の違いだから」「英語が上手になれば」と、受け手だけに改善を求める問題でもありません。

安全を優先し、社内の定められた相談・報告経路を利用します。上司自身が関係しているなら、人事、コンプライアンス窓口、別の指定相談先など、利用できる経路を確認してください。差し迫った危険や事故は、通常の会議調整を待たず、会社や現地の緊急対応手順に従います。

相談時は、日時、具体的な発言や行動、影響、関連する記録の場所を、社内規程に沿って整理します。秘密録音や社外への資料持ち出しを勧めるものではありません。会社だけでは対応が難しい場合の相談先や、個別の法的な判断は、該当する国・地域の公的窓口や専門家に確認してください。

次の話し合いに持っていくメモ

次に意見が分かれたら、話す前に以下を短く書いてみてください。全部を埋めるために一人で調査し続ける必要はありません。「相手に確かめたいこと」「判断できる人に相談すること」が見つかれば、次の一歩になります。

1. 今回、何を決めるか：対象の仕事と、今回決めないこと。
2. 確認できたこと：相手の発言、資料の版、観測した事実。自分の解釈は分ける。
3. 違いがありそうな点：目的、用語、制約、根拠、判断基準のどこか。
4. 比較する案：各案の利点、必須条件への適合、未確認の点。自分の案にも同じ条件を使う。
5. まだ必要な視点：影響を受ける担当者、確認できる人、答えやすい方法と期限。
6. 判断と次の確認：決める人、決定理由、残る懸念、次の担当、見直す時点・条件。

話し合いの後は、何の違いが分かったかを振り返ります。必要な人の意見が入ったか、未決事項の担当が決まったかも確認しましょう。「全員を説得できたか」だけでは判断しません。文化を理由に結論を急がず、目の前の仕事で確かめられることを増やすと、意見が異なるままでも次の判断へ進めます。

よくある質問

情報の確認日・出典

情報の確認日：2026年10月18日。以下は企業ごとの公開実践です。海外企業すべての規則や、対立解消の効果を保証する根拠としては扱っていません。

• GitLab Values：People are not their work：人物と仕事の具体例を分ける考え方
• Atlassian：DACI：判断者、判断材料、選択肢、決定理由の整理
• GitLab：Making Decisions：関連する知識・データを持つ人の意見を集める運用
• Atlassian：Sparring：背景と対象を共有し、文章でも意見を集める手順

比較表・確認メモ・日英例は、編集部による学習用の提案です。各社の公式テンプレートや実際の受講成果ではありません。