海外リモートで会議に頼らず働くには？非同期コミュニケーションの基本

こんにちは、Kredo Blog編集部です。

企業の公開資料は各社の実践例として参照しています。本文の人物・業務・日付・日英メッセージは、説明のために編集部が作成した架空例です。所属先の勤務時間、権限、情報管理、緊急連絡のルールを優先してください。

非同期コミュニケーションとは

非同期コミュニケーションは、全員が同じ時刻に参加しなくても進められるやり取りです。文書へのコメント、タスクへの依頼、録画した説明への返答などが当てはまります。会議や通話のように、その場で話し合う方法は同期コミュニケーションと呼びます。

使うアプリだけでは区別できません。チャットで常に即答を求めていれば、相手が同時にいることへ依存します。反対に、目的・資料・返答期限がそろったチャットの依頼は、時間をずらして扱えます。

GitLabの公開ハンドブックは非同期のやり取りを出発点にし、口頭で話した結論も書き残す方針を示しています。37signalsは社内コミュニケーションガイドで、重要な議論の文章化を勧めています。真の緊急時以外は即答を要求しない、という考え方です。これは各社の運用であり、すべての海外企業が同じルールで働くという意味ではありません。

非同期に向きやすいのは、参照する資料があり、返答まで待てる依頼です。状況が刻々と変わる障害や、前提を共有できず説明がすれ違う話は、そのまま待たせないほうがよい場合があります。会議数をゼロにすることより、いま必要なやり取りに合う方法を選ぶことが大切です。

依頼と決定を追う場所を決める

メールに依頼、個人チャットに補足、別の文書に最終版があると、後から読む人が全体を探す必要があります。まず、仕事一件について「ここを見れば現在の状態が分かる」という記録の置き場所を決めます。タスク管理ツールの一件、共有文書の決まった項目など、会社ですでに使っている場所で構いません。

通知はチャットでも、詳しい説明と更新はその記録へ戻す運用にします。通知文には対象と必要な対応を短く書き、該当箇所へのリンクを付けます。同じ本文を複数箇所に複製して、それぞれ別々に直すのは避けましょう。37signalsも、作業や文書に関する議論をその対象へひも付ける運用を説明しています。

最初にチームで確認しておきたいのは、次の点です。

• 記録する場所：依頼・最新資料・決定をどこからたどるか
• 返答する人：意見がほしい人、作業を引き受ける人、最終判断をする人
• 返答の目安：通常の連絡を勤務時間内にいつ確認し、期限が難しいときにどう知らせるか
• 待てない場合の連絡先：緊急と判断する条件、使う経路、不在時の担当

Atlassianの非同期コミュニケーションの解説でも、チームの連絡方法や返信時間について合意することを勧めています。「海外なら24時間以内に返す」といった共通基準は置かず、自分たちの業務と勤務時間に合わせて決めます。

共有範囲も確認が必要です。関係者が読めることと、誰でも読めることは別です。個人情報や顧客情報を広いチャンネルへ転載せず、許可された保存先へ必要な人だけがアクセスできるか確認してください。画面のスクリーンショットや録画にも、不要な情報が写っていないか気を配ります。

会議なしで伝わる依頼文を作る

「これを見てください」だけだと、読む人は修正が必要なのか、承認を求められているのか、参考共有なのか判断できません。依頼の冒頭で、相手にしてほしい行動を一つ示しましょう。その後に理由と資料を続けます。

例えば「新しいファイル共有機能の社内説明ページ」を作る架空のチームを考えます。Akiが原稿を作成し、Samが操作手順を確認し、Meiが社内への案内を承認します。依頼前にSamの勤務予定と確認時間を確かめ、対応可能な日程を相談済み、という前提です。

何をしてほしいか

Samに、手順3・4と画面画像の一致を確認してもらう。文章全体の校正や公開承認は今回の対象外。

何のためか

10月22日の社内案内前に、サポート担当が同じ手順を再現できる状態にするため。

どこを見て、どこに返すか

タスクにある「説明ページ v3」の手順3・4を確認し、修正点を同じ文書のコメントへ残す。実際の依頼では閲覧できるリンクを付ける。

いつ、どの形で返してほしいか

2026年10月20日18:00 JST（09:00 UTC）までに、修正点または「この範囲は問題なし」を返す。

間に合わない場合

対応可能な時刻をタスクに知らせてもらい、Akiが日程や代替の確認担当を調整する。無回答を確認済みとはしない。

資料リンクだけでなく、版と確認範囲を書くのがポイントです。資料が長い場合は該当の見出しを示し、前の会話を知らない人にも必要な背景だけを添えます。すべての経緯を本文へ詰める必要はありません。

依頼する側が期限を書いても、それだけで相手の予定が確保されるわけではありません。新しい依頼や短い期限なら、対応できるかの確認を別に置きます。英語は長く丁寧にするより、行動・対象・日時が一通り読める形を優先しましょう。

依頼の目的や担当範囲そのものが上司と食い違っている場合は、海外の上司と仕事の期待をすり合わせる方法で確認項目を整理できます。

引き継ぎは次の一手と受け取り確認まで

自分の終業時刻が来たら、「続きはお願いします」で閉じず、次の担当が何から始めればよいかを残します。次の勤務時間まで自分に質問できなくても、作業を再開できることが目標です。

引き継ぐ記録には、完了したこと、未完了のこと、次にしてほしい作業、止めておく作業を分けて書きます。関連資料の所在と、判断が必要になったときの担当も添えましょう。未完了を曖昧にして「ほぼ終わりました」と書くと、受け手はどこまで信用して進めてよいか分かりません。

一方、受け取る側は「読みました」と「その仕事を引き受けます」を区別します。既読表示や絵文字が何を意味するかはチームによって違うため、担当と期限が変わる場面では文章で確かめるほうが確実です。

この例では、Samが確認担当と期限を受け入れたことまで分かります。受け取りの返答がなければ、元の担当は「受け取り確認待ち」と記録してください。引き継ぎ完了とは区別します。不在中の対応が必要なら、事前に合意した手順で勤務中の代替担当や責任者へ相談が必要です。休暇中の代行依頼や復帰時の照合は、英語の引き継ぎメールの書き方で詳しく練習できます。

提案と決定を分けて記録する

非同期の議論では、複数の案やコメントが時間差で並びます。最後のコメントが自動的に結論になるわけではありません。記録の冒頭に「提案中」「確認待ち」「決定済み」などの状態を示し、決定した人と日時を明記します。

GitLabの公開ハンドブックでも、すでに決まった内容の説明と、意見を集める提案を区別しています。この記事では、それを参考に決定内容・理由・判断者・対象範囲・次の担当と期限を短くまとめる方法を提案します。特定の役職名や決裁制度をそのまま採用する必要はありません。

架空のチームでは、Samの修正指摘をAkiが反映し、Meiが社内案内の承認を明示したとします。その場合の記録は、次のように書けます。

状態と判断者

決定済み。Meiが2026年10月21日09:00 UTCに承認。承認コメントへのリンクを記録。

決定と理由

説明ページv4をサポートチームへ案内する。手順3・4を最新画面に合わせて修正したため。

対象外・未決

顧客向けの公開は対象外。他部署への展開は別途確認する。

次の担当と期限

Akiが10月22日09:00 UTCまでに、承認済みのv4をサポートチームへ案内する。操作画面が変わった場合は案内前に再確認する。

承認がまだなら「決定済み」と書かず、誰のどの確認を待っているかを残します。「期限までに反対がなければ承認」とする運用も、権限と条件を事前に合意していなければ使えません。返信がないことを理由に、案内先や公開範囲を勝手に広げないでください。

決定後に内容を変える場合は、旧版を黙って書き換えるのではなく、変更点と再確認の要否を残します。後から参加した人が、どの版を使えばよいかたどれる形にします。

返答期限と返信がないときの扱い

「今日中」「なるべく早く」では、読む国や時間帯で解釈が変わります。必要な場面では年月日・時刻・タイムゾーンを記し、相手が現地時刻へ換算できるようにします。この記事の18:00 JSTは09:00 UTCです。ほかの地域の時刻を併記するなら、その日付の夏時間を含めて確かめましょう。

もう一つ大切なのは、期限の種類を分けることです。受け取れるかの返事が必要な日時、レビュー結果が必要な日時、仕事全体の締切は同じとは限りません。毎回すべてに細かい期限を置くのではなく、次の作業が止まる箇所を明確にします。

• 参考共有：今のところ返答や行動は不要と書く
• 確認・意見募集：誰に、何への返答を、いつまでに求めるか書く
• 作業依頼：引き受けられるかと、完了予定を確認する
• 判断待ち：判断できる人と、それまで保留する作業を示す

以下は、先ほどの予定どおりに進まなかった場合の別例です。期限までに十分な回答ができないときも、読んだことと返せる見込みを勤務時間内に知らせれば、依頼側は調整しやすくなります。ただし、受領連絡だけでは作業の完了や承認にはなりません。

この返答が来た場合、依頼側は新しい日時でよいか確認し、影響する承認や案内の予定も更新します。返答した側が一方的に締切を変更した扱いにはしません。

返信が来ない場合は、まず元の記録で、相手への依頼が明確か、アクセス権や不在予定に問題がないかを確認します。そのうえで、合意した期限と必要な判断を添えて同じ場所で再確認します。複数のチャンネルへ同じ催促を重ねる前に、事前に決めた代替担当・責任者への連絡経路を使いましょう。期限前に同じ依頼を繰り返したり、勤務時間外の相手を一律に起こしたりする方法を標準にはしません。

急ぐときと行き詰まったときは同期へ切り替える

非同期で続けるほど時間がかかると分かったら、短い通話や画面共有へ切り替えます。GitLabの会議ガイドも、非同期と同期の使い分けを求めています。切り替える目安は、単なる返信回数より、待つことで起きる影響と、文章で解決に近づいているかです。

通常の行き詰まりでは、話す論点を先に絞る

例えば、同じ操作について説明が食い違う、どの画面を見ているか分からない、追加質問に答えても前提のずれが残る場合です。いきなり大人数の会議を入れず、確認したい一点と参加が必要な人を特定します。時間帯も相談し、勤務時間が合わなければ、まず許可された画面画像や短い録画で補足できるか考えます。

緊急時は、普段の返信を待つ前提を外す

サービス停止や情報の誤共有は、待つほど影響が広がる可能性があります。その場合は、通常のコメント欄だけで待ち続けないでください。会社の事故・障害対応手順に従って、定められた当番や担当窓口へ連絡します。判断に迷う場合の相談先も、平常時に確認しておきます。

連絡には、分かっている事実、発生・確認時刻、影響が疑われる範囲、すでにしたこと、必要な判断を添えます。未確認の原因は断定せず、機密情報を不適切な場所へ貼り付けないでください。独断で権限外の操作をすることや、誰にでも一斉通知することを推奨するものではありません。

通話後は元の記録へ、決まったこと・未決のこと・次の担当と期限を戻します。会話に参加できなかった人も、仕事を再開できるためです。録画は必須ではありません。記録・同意・保存に関する会社のルールを確認し、必要な結論を文章に残しましょう。

次の依頼を一件だけ書き直してみる

最初からチーム全体の会議を変更する必要はありません。次に送る通常の依頼を一件選び、下の項目に沿って書き直してみてください。会議を削除したり、会社の連絡ルールを変えたりする場合は、関係者と相談して進めます。

依頼の目的と、してほしい行動

何のために、誰に、どの範囲を確認・作業してほしいか。

参照先と現在の状態

資料のリンク・版、完了済み、未完了、次にすること。

必要な返答と日時

受け取り、作業結果、承認のどれが必要か。日付・時刻・タイムゾーンと、対応可否の確認。

待てない場合と、決定の残し方

期限が難しい場合の相談先、緊急連絡の経路、判断者、決定記録を更新する人。

終わったら、追加で尋ねられた情報や、引き継ぎで止まった箇所を振り返ります。決定を探す必要があったなら、その原因も確認してください。次の依頼では、足りなかった情報を一つ足すところから改善できます。

日々の完了・未完了・判断待ちを英語で整理したい場合は、英語の進捗報告の書き方とテンプレートも参考になります。ここで紹介した運用と組み合わせ、実際の業務内容に置き換えて練習してみてください。

よくある質問

情報の確認日・出典

情報の確認日：2026年10月18日。以下は各社が公開する実践例です。すべての海外企業に共通する制度や、効果を保証する根拠ではありません。

• GitLab：Communication：非同期を出発点にする方針、口頭の結論の記録、提案と決定の区別
• 37signals：Guide to Internal Communication：重要な議論の文書化、即答要求の扱い、作業にひも付けた議論
• Atlassian：Asynchronous communication for distributed teams：連絡方法や返信時間についてのチーム内の合意
• GitLab：All-Remote Meetings：目的に応じた同期と非同期の使い分け

例文・記録様式・確認項目・比較表は、編集部が作成した練習用の提案です。各社の公式テンプレートや実際の受講成果ではありません。