海外リモート業務委託の時差マネジメント｜発注側の運用設計5原則

海外在住のエンジニアに業務委託でリモート参画してもらったものの、日本時間の夕方に投げた仕様確認の質問への回答が翌々日の朝に返ってくる。その間タスクは完全に止まり、スプリントの消化率は想定の 6 割。経営層からは「本当に回るのか」と問われ始めている。こうした状況に心当たりのある発注担当者は少なくありません。

やっかいなのは、この状況で誰を責めればいいのか分からないことです。委託先のエンジニアは誠実に働いていますし、稼働時間もきちんと報告されています。それでも成果が出ない。「時差があるから仕方ない」と片付けたいところですが、それでは経営層への説明になりません。かといって「時差の小さい国を選びましょう」という一般的なアドバイスは、すでに契約して稼働が始まっている相手には使えません。

この問題の本質は、時差そのものではなく「意思決定の待ち行列」にあります。発注側が回答を一晩保留すると、委託先の翌営業日がまるごと消える。この構造に気づかないまま「連絡をこまめにしよう」と精神論で対処しても、遅延は再現し続けます。逆に言えば、時差を所与の制約として受け入れたうえで、重複勤務時間・応答期限・意思決定権限といったパラメータを数値で設計すれば、時差が大きい相手とでも安定した進行は可能です。

本記事では、海外リモート業務委託におけるタイムゾーン差異のマネジメントを、発注側が先に決めるべき 5 つの原則として整理します。重複勤務時間を業務から逆算する方法、緊急度別の応答期限の決め方、日次ハンドオフによる進捗可視化、そして稼働時間帯を業務委託契約にどう書けば偽装請負と見なされないかの線引きまで、明日から合意形成に使える形で解説します。

海外リモート業務委託で時差が問題になる本当の理由

海外リモート業務委託で「時差がつらい」と言うとき、多くの発注担当者が想定しているのは「会議の時間が合わない」という症状です。しかし実際にプロジェクトを遅らせているのは会議ではありません。ここでは、時差が遅延に変換される構造を分解し、主要な委託先国との実際の重なり時間を数字で確認します。

遅延の正体は「連絡の遅さ」ではなく意思決定の待ち行列

日本との時差が 13 時間ある地域に委託しているケースで考えてみます。日本時間 18:00 に発注側が仕様確認の質問を投げたとします。このとき相手の現地時刻は 5:00。相手が 9:00 に業務を始めて質問に気づき、11:00 に回答を返すと、日本時間では深夜 0:00 です。発注側がそれを読むのは翌朝 10:00。つまり、たった 1 往復のやり取りに 16 時間かかります。

重要なのは、この 16 時間が「相手の反応が遅かったから」発生したのではないという点です。双方とも自分の勤務時間内に、気づいてから 2 時間以内に返しています。それでも 1 往復で 16 時間が確定的に消える。これがタイムゾーン差の本質です。

そして、この待ち時間は往復回数に比例して増えます。

「この仕様どうしますか？」という曖昧な質問を投げ、相手から「A と B のどちらでしょうか」と聞き返され、さらに「B でお願いします、ただし条件は……」と返す。国内であれば 30 分で終わるこのやり取りが、時差 13 時間の相手とは 2 営業日を消費します。

もう一つ見落とされがちなのが、待ち行列の向きです。発注側は「相手からの回答を待っている」と認識しがちですが、多くの場合、待っているのは相手のほうです。委託先が仕様の判断を仰いだ時点で、そのタスクは発注側の意思決定を待つ状態に入ります。発注側が「明日の会議で決めよう」と一晩保留すると、相手の翌営業日はそのタスクに着手できません。代替タスクが用意されていなければ、稼働は丸一日空きます。

つまり、時差環境における最大のボトルネックは委託先の作業速度ではなく、発注側の意思決定リードタイムです。ここを認識できているかどうかで、打つべき対策がまったく変わります。

主要委託先国のタイムゾーン差と、日本と重なる勤務時間の実際

対策を設計する前に、自社と委託先の勤務時間が実際に何時間重なるのかを数字で把握します。海外エンジニアへの業務委託でよく選ばれる国・地域について、日本の標準的な勤務時間（9:00〜18:00）と、相手が現地 9:00〜18:00 で稼働した場合の重複時間を整理すると次のようになります（各国の時差はモンスターラボ「オフショア開発拠点国を選ぶ際に知っておきたいポイント」などの公開情報に基づく標準時での整理です）。

この表から読み取るべきは 3 点あります。

第一に、ベトナムのように時差が 2 時間の開発拠点であれば、何も工夫しなくても 7 時間が自然に重なります。「ベトナムは時差が小さいから進めやすい」と言われるのはこのためで、実質的には国内リモートに近い運用が成立します。

第二に、インドや東南アジアの一部のように時差が 3〜4 時間になると、重複は 5〜6 時間に縮まります。この帯であればまだ同期的な運用が可能ですが、日本側の午前中は完全に非同期になるため、朝一番に質問を投げる習慣は機能しません。

第三に、欧州・北米・南米は重複が 0〜2 時間しかありません。この領域では、同期コミュニケーションを前提とした運用設計そのものが成り立ちません。どちらかが標準勤務時間をずらすか、完全な非同期運用に切り替えるかの二択になります。

なお、欧州・北米は夏時間（サマータイム）の導入により年に 2 回、時差が 1 時間変動します。日本は夏時間を採用していないため、相手側の切り替え日に合わせて会議設定が 1 時間ずれる事故が起こりがちです。ベトナム・インド・フィリピンなどアジア圏の主要拠点には夏時間がないため、この点では扱いやすくなります。カレンダー招待は必ずタイムゾーン付きで発行し、固定時刻をテキストで書かない運用にしておくと事故を防げます。

「時差の小さい国を選ぶ」だけでは解決しない 3 つのケース

時差に関する一般的な記事の多くは、解決策として「時差の小さい国を選ぶ」を挙げます。これは委託先を選定する段階では正しい助言ですが、次のようなケースでは使えません。

1. すでに委託先が決まっている、または稼働が始まっている場合

契約締結後に「時差が大きいので国を変えます」という判断は現実的ではありません。採用・オンボーディングにかけたコストが失われますし、委託先との信頼関係も損なわれます。この場合は時差を前提に運用を組み直すしかありません。

2. 求めるスキルが特定の地域に偏っている場合

生成 AI や特定のクラウド基盤、ニッチな言語・フレームワークの専門家は、供給地域が限られます。日本語で仕様のやり取りができる在外フリーランスを探した結果、たまたま欧州や北米在住だったというケースもあります。スキル要件を優先すれば、時差は選べません。

3. 単価と供給量の制約がある場合

同じスキルレベルでも、地域によって単価は大きく異なります。予算制約から特定地域を選ばざるを得ない、あるいは時差の小さい地域の人材が採用競争で確保できないという事情は珍しくありません。

これら 3 つのケースに共通するのは、「時差は変数ではなく定数である」という点です。定数を動かそうとする助言は役に立ちません。動かせるのは運用のほうです。

なお、委託形態そのものから見直したい場合、つまりベンダーへの一括発注と個人単位のリモート委託のどちらが自社に合うかを検討したい場合は、オフショア開発とは？メリット・デメリットと外部委託の選び方もあわせてご覧ください。本記事は「時差を所与の制約として受け入れた場合の運用設計」に絞って解説します。

タイムゾーン差マネジメントの5原則｜発注側が先に決めること

海外リモート業務委託でタイムゾーンの違いへの対策を考えるとき、多くの発注担当者は「委託先に何をしてもらうか」から発想します。しかし前章で見たとおり、ボトルネックは発注側の意思決定リードタイムです。したがって最初に決めるべきは、発注側が自分の振る舞いをどう変えるかです。

本記事では、時差前提の業務委託運用を次の 5 原則に整理します。

この 5 つは独立していません。原則 3（意思決定権限の委譲）が甘いと原則 1（重複勤務時間）をいくら伸ばしても待ち行列は解消しませんし、原則 4（引き継ぎ単位）が固まっていないと原則 2（応答時間）を決めても何に対して応答するのかが曖昧になります。順序としては、まず 1 と 2 を暫定的に合意して運用を回し始め、2〜4 週間かけて 3 と 4 を精緻化し、契約更新のタイミングで 5 に落とし込むのが現実的です。

以降の章では、この 5 原則をそれぞれ具体的な数値と手順に展開します。

重複勤務時間（オーバーラップ）の設計｜必要時間を業務から逆算する

時差のある海外業務委託において最初に合意すべきなのが、双方の勤務時間をどれだけ重ねるかです。ここで多くのチームが「できるだけ長く重ねたほうがよい」と考えますが、これは誤りです。重複時間を長く取れば取るほど、どちらかの生活時間が犠牲になり、長続きしません。必要な時間を業務から逆算して、それ以上は重ねないのが正解です。

フェーズ・職種別に必要なオーバーラップの目安

オーバーラップさせる勤務時間の長さは、プロジェクトのフェーズによって変わります。要件が固まっていない時期は同期的な確認が頻発しますが、仕様が安定した実装期には大幅に減らせます。

職種・役割によっても必要量は変わります。

具体的な逆算の手順は次のとおりです。1 日に必要な同期イベントを列挙し、所要時間を積み上げます。

• デイリー同期（進捗とブロッカーの確認）: 15 分
• ブロッカー解消のための即席通話: 30 分（週の半分程度で発生）
• 仕様確認・コードレビューの口頭補足: 30〜60 分
• 予備枠（想定外の相談・割り込み）: 30 分

合計すると 1 時間 45 分〜2 時間 15 分。実装期であれば「2 時間」が最低ラインという計算になります。この積み上げをせずに「3 時間は重ねてほしい」と要求すると、根拠を示せないため相手も納得しませんし、実際には使われない空白の重複時間が生まれます。

重複時間を確保する目的は、会議をするためではありません。発注側の意思決定を、相手の稼働時間内に届けるためです。この目的から逆算すると、重複帯に発注側の「判断できる人」が必ずいることが条件になります。判断者が会議で埋まっていて重複帯に不在なら、重複時間を何時間取っても待ち行列は解消しません。

コアタイムの決め方と、早朝・深夜負担のローテーション

海外リモートでの会議の時間調整は、次の 3 ステップで進めます。

ステップ 1: 双方の標準勤務時間を UTC に揃えて書き出す

日本（UTC+9）の 9:00〜18:00 は UTC 0:00〜9:00 です。相手側も同様に UTC に変換すると、重なりが機械的に判定できます。時差の暗算で議論すると必ず食い違いが出るため、最初の合意は UTC で行うのが確実です。

ステップ 2: 自然に重なる帯を確認する

双方が標準勤務時間のままで重なる時間を確認します。必要量を満たしていれば、そこをコアタイムに設定して終了です。

ステップ 3: 不足分をどちらがどれだけずらすかを配分する

必要量に足りない場合のみ、どちらかが勤務時間をずらします。ここで重要なのが、負担を片側に固定しないことです。「委託先が日本時間に合わせるのが当然」という運用は、短期的には回りますが、相手の離脱リスクを高めます。

負担配分の例としては、次のような形が考えられます。

• 日本側が週 2 日は 8:00 始業、委託先が週 2 日は 1 時間遅い終業とする
• 隔週で早朝担当を入れ替える（今週は日本側が早朝、来週は相手側が夜間）
• 3 拠点以上が関わる場合は、月次で会議時間帯をローテーションする

もう一つ、実務的に効果が大きいのが会議を重複帯の「前半」に置くことです。重複帯の終わり際に会議を設定すると、決まった内容を相手が作業に反映できるのは翌営業日になります。前半に置けば、会議で決まったことをその日のうちに相手が着手できます。同じ 1 時間の会議でも、置く位置によって半日から 1 日の差が生まれます。

定例会議そのものは最小限に絞ってください。時差環境では会議 1 つが双方の生活時間を圧迫するため、「1 日 1 回 15 分のデイリー」と「週 1 回 30〜60 分の同期」の 2 枠に収め、それ以外は非同期に寄せるのが現実的なバランスです。

オフショア開発の時差を「引き継ぎ」に転換できる条件と、できない条件

オフショア開発の時差を語る際、しばしば「時差を活かして 24 時間開発体制を組む」という発想が紹介されます。日本の終業時に作業を引き継ぎ、相手の終業時に戻してもらうことで、実質的な稼働時間を延ばすという考え方です。

これは条件が揃えば有効ですが、揃わない場合は逆に遅くなります。判断の目安を整理します。

引き継ぎに転換できる条件

• タスクが疎結合で、引き継ぎ地点を明確に定義できる（「ここまで実装済み、次はこの関数」と言い切れる）
• 完了の定義とテストが自動化されており、相手が結果を機械的に確認できる
• ドキュメント文化があり、作業の状態が文章だけで伝わる
• 24 時間連続で回ること自体に価値がある業務（監視、障害の一次対応、データ処理バッチ、テスト実行、翻訳・QA など）

引き継ぎに転換できない条件

• 仕様が流動的で、作業中に判断を要する場面が頻発する
• 同一モジュールを双方が編集するなど、相互依存が強い
• 引き継ぎコストが節約時間を上回る

3 つ目は具体的に見積もれます。引き継ぎメモの作成に 15 分、受け取り側の読解と状況把握に 15 分かかるとすると、1 回の引き継ぎで 30 分が消えます。引き継ぎによって節約できる時間が 1 時間に満たないなら、割に合いません。加えて、引き継ぎのたびに文脈が失われるため、実装の一貫性が下がるコストも発生します。

現実的な結論としては、実装タスクを日跨ぎで引き継ぐのは推奨しません。引き継ぐべきは「作業」ではなく「状態と判断待ち事項」です。次章以降で扱う日次ハンドオフメモは、この考え方に基づいています。

非同期コミュニケーションの運用ルール｜即レス前提を捨てる

重複勤務時間を確保しても、海外業務委託における 1 日の大半は相手と時間が重ならない非同期の時間です。この時間をどう設計するかが、時差マネジメントの実質的な勝負どころになります。非同期コミュニケーションのルールを明文化せずに運用すると、「返事が来ない」「催促されている気がする」という相互不信が静かに蓄積していきます。

1 往復で決めきる依頼の型（背景・受入条件・期限・判断者）

前章で見たとおり、時差 13 時間の環境では 1 往復あたり 16 時間が確定的に消えます。したがって、非同期運用における最重要の改善は「往復回数を減らすこと」です。返信を速くすることではありません。

往復が増える原因のほとんどは、依頼文に必要な情報が欠けていることです。次の 7 要素を含む型を使うと、多くの依頼が 1 往復で完結します。

• 背景: なぜこの作業が必要か（1〜3 行）
• 依頼内容: 具体的に何をしてほしいか
• 受入条件: どうなれば完了とみなすか（箇条書き）
• 期限: 日本時間と相手のローカル時刻を併記
• 判断者: この件を最終決定する人の名前
• 判断が必要な点: 選択肢（A / B）と推奨案、そう推奨する理由
• 不明時の既定動作: 期限までに確認が取れない場合、どう進めてよいか

最後の「不明時の既定動作」が、待ち行列を断ち切る核心です。「確認が取れなければ A で進めてください。後から B に変更する場合の手戻りは 2 時間程度と見込んでいます」と書いておけば、発注側の回答が遅れても相手の稼働は止まりません。手戻りのリスクを見積もったうえで、待ち時間とどちらが安いかを判断する。この習慣がつくと、遅延は大きく減ります。

逆に避けるべきなのが「この仕様どうしますか？」「ここ、ちょっと相談したいです」といった、選択肢を提示しない依頼です。これらは必ず往復を 1 回以上増やします。委託先から発注側への相談についても同じ型を使ってもらうよう、最初に依頼しておくと効果的です。

緊急度 3 段階と応答期限の目安を決める

「即レスは求めない」と決めても、では何時間待ってよいのかが曖昧なままだと、結局どちらも落ち着きません。緊急度を 3 段階に分け、それぞれの応答期限とチャネルを明文化します。

この表を運用するうえで、2 つの補足が重要です。

応答期限と解決期限を分ける

応答期限は「見ました。いつまでに回答します」を返す期限であり、問題を解決する期限ではありません。ここを分けないと、すぐ答えられない依頼を前にして誰も反応しなくなり、ルールが形骸化します。「明日の設計会議で決めて、日本時間の 17:00 までに回答します」という応答自体が、相手にとっては十分に有用な情報です。

「営業日」がどちらの営業日かを明記する

P3 の「1 営業日以内」は、どちらの国の営業日を指すのかを決めておきます。相手国の祝日を含めるのか、日本の祝日を含めるのか。ここが曖昧だと、旧正月やクリスマス休暇の前後で必ず認識のずれが起きます。

同期・非同期のツール使い分けと、決定事項を残す場所

チャットに何でも流す運用は、時差環境では特に相性が悪くなります。相手が読むのは数時間後であり、その間にスレッドは流れていくためです。目的別に使い分けを固定します。

記録の原則は一つです。決定事項はチャットに残さず、課題管理ツールまたはドキュメントに書きます。時差がある環境では「後から読む人」が必ず存在するため、決定の置き場を 1 箇所に固定しないと、同じ議論が何度も繰り返されます。

会議の議事録は、会議終了後ではなく会議中に共同編集で書き切ることを推奨します。会議後に清書して共有すると、その作業が発注側の終業後になり、相手が読めるのは翌営業日になります。同期の時間内に文字にして、その場で合意を取れば、決定事項は即座に非同期の記録へ変換されます。

進捗が見えない不安を消す｜時差前提の進捗可視化とハンドオフ設計

海外リモート業務委託で発注側が最も不安を感じるのは、「今どうなっているのか分からない」状態です。国内であれば雑談や様子から察知できた遅れの兆候が、時差のあるリモート進捗管理では見えません。ここでは、遅れを日次で検知し、かつその原因を切り分けられる仕組みを設計します。

タスク粒度と完了の定義（Definition of Done）を先に揃える

時差環境では、タスクの粒度が進捗の可視性を直接決めます。

粒度の目安は 0.5〜2 日で完了する単位です。国内であれば 1 週間サイズのタスクでも途中経過を口頭で拾えますが、時差があると「詰まってから解消するまで」に 1 日かかるため、粒度が大きいと詰まりの発見そのものが遅れます。加えて、1 つのタスクに含める不確実性は 1 つまでに制限してください。「新しいライブラリを検証しつつ、仕様も詰めながら実装する」というタスクは、必ず判断待ちが複数回発生し、その都度 1 日ずつ消えます。

完了の定義（Definition of Done）は、チーム共通の文書として明文化します。最低限、次の項目を含めます。

• 実装が完了し、自動テストが通っていること
• レビュー依頼が出されていること
• 関連ドキュメントが更新されていること
• 動作確認の手順が記載されていること（発注側が非同期で検証できる形）

最後の項目が特に重要です。完了判定が発注側の目視確認に依存していると、その確認待ちで 1 日消えます。プレビュー環境の URL と確認手順がタスクに書かれていれば、発注側は自分の都合のよい時間に検証でき、待ち行列に入りません。

日次ハンドオフメモに書く 4 項目

各自の就業終了時に、次の 4 項目を投稿する運用を設けます。

1. 今日やったこと: 完了・未完了をタスク ID とともに記載
2. 明日やること: 着手予定のタスク
3. ブロックされている点と、それを解消できる人: 「誰の判断待ちか」を名指しで書く
4. 相手の稼働時間中に確認してほしいこと: 期限つきで記載

書式は 3〜5 分で書ける分量に制限します。詳細な日報を要求すると、数週間で誰も書かなくなります。

そして、このメモは委託先だけでなく発注側も同じ書式で書きます。片務にすると「監視されている」という印象を与えますし、何より発注側のメモが「自分が抱えている未回答リスト」として機能します。3 番目の項目に自分の名前が並ぶのを見ると、意思決定リードタイムを縮める動機が自然に生まれます。

このメモがあることで、遅延の原因を切り分けられるようになります。「ブロックされている点」に発注側の名前が並んでいれば意思決定の問題、空欄なのに進捗が出ていなければ見積もりか難易度の問題、というように、感情ではなく記録で判断できます。

なお、時差だけでなく拠点が複数に分かれる場合の役割分担やオンボーディングを含めた運用モデル全般については、多拠点リモート開発の運用マネジメントで扱っています。本記事は時差という単一の変数に絞っています。

障害・緊急時のエスカレーション経路と、深夜連絡の事前合意

相手が就寝している時間帯に本番障害が起きたとき、連絡してよいのかどうかを都度悩むのは避けたいところです。次の 3 点を事前に合意しておきます。

1. 深夜・時間外に連絡してよい条件を列挙する

条件を「本番障害でユーザー影響が出ている」「セキュリティインシデントが疑われる」「リリース作業中の切り戻し判断が必要」のように具体的に列挙します。そして「これら以外は翌稼働時間まで待つ」と明記します。列挙されていれば連絡する側は迷わず、受ける側も「該当しない連絡は無視してよい」と安心できます。

2. 緊急連絡の手段を通常チャネルと分ける

通常のチャットで緊急連絡をすると、通知を切っている相手には届きません。電話、または通知設定を別にした専用チャンネルを緊急用として確保します。

3. 時間外対応の対価を先に決める

オンコール手当や時間外の割増単価を、運用開始前に決めておきます。無償の善意に依存した体制は、必ずどこかで破綻します。金額の多寡よりも、「時間外の対応は本来の契約範囲外であり、対価を伴う」という認識を双方が共有していることが重要です。

加えて、一次対応者と判断者を分けておくことを推奨します。判断者が就寝している前提で、一次対応者が独断で実行してよい範囲（サービスの切り戻し、機能フラグの無効化など）を事前に委譲しておけば、深夜の連絡そのものを減らせます。

業務委託契約への落とし込み｜稼働時間帯・応答時間の書き方

ここまでの運用ルールを口頭合意やチャットのやり取りだけで終わらせると、遅延やトラブルが起きたときに責任の所在が曖昧になります。海外リモート業務委託であっても、時差前提の運用条件は契約書または発注書に明記しておくべきです。一方で、稼働時間を細かく縛りすぎると偽装請負と評価されるリスクが生じます。この章では、その両立の考え方を整理します。

なお、以下は一般的な考え方の整理であり、個別の契約が適法かどうかは実態を踏まえた総合判断になります。実際の契約書作成にあたっては、必ず自社の法務担当者や弁護士に確認してください。

準委任・請負で変わる「時間」の書き方

まず、契約の類型によって「時間」の位置づけが変わることを押さえます。

請負契約（民法第 632 条）は仕事の完成に対して報酬を支払う契約です。受託者が何時間働いたかは、本来は報酬の算定基礎ではありません。したがって稼働時間帯を義務として書き込むと、契約の性質と齟齬が生じます。

準委任契約には、2020 年 4 月施行の改正民法により 2 つの類型が整理されました。履行割合型は事務処理の割合に応じて報酬を支払う形、成果完成型（民法第 648 条の 2）は成果の達成に対して報酬を支払う形です。準委任契約における時間の扱いは、この類型によって変わります。

実務上、海外リモートのエンジニア委託では準委任（履行割合型）が選ばれることが多く、この場合は月間稼働時間の幅を定めたうえで、重複帯を「勤務義務」ではなく「連絡調整が可能な時間帯」として合意する書き方が現実的です。

稼働時間帯の指定が偽装請負と見なされないための線引き

発注側が最も判断に迷うのが、業務委託で稼働時間の指定をどこまで書いてよいかという点です。

判断の出発点になるのが、いわゆる 37 号告示（昭和 61 年労働省告示第 37 号「労働者派遣事業と請負により行われる事業との区分に関する基準」）です。厚生労働省は同告示の解釈について疑義応答集を公開しており、労働者派遣・請負を適正に行うためのガイドにも判断の考え方がまとめられています。基本的な考え方は、発注者が受託者側の労働者に対して直接指揮命令を行っていれば、契約の名称にかかわらず労働者派遣に該当しうる、というものです。

個人のフリーランスに直接委託する場合は、これに加えて「その働き方が実質的に労働者と評価されないか」という論点も生じます。時間的・場所的な拘束の強さ、業務の依頼を断る自由の有無、代替性の有無などが総合的に判断されます。

この観点から、稼働時間に関する記載を整理すると次のようになります。

リスクが高いと考えられる書き方・運用

• 始業・終業時刻を発注者が一方的に指定し、遵守を義務づける
• 日々の作業順序や作業方法を発注者が細かく指示する
• 業務量の増減を発注者が随時指示し、受託者に断る自由がない
• 他社案件との掛け持ちを一律に禁止する
• 勤怠管理システムへの打刻を義務づけ、遅刻・早退を管理する

相対的に許容されやすいと考えられる書き方・運用

• 業務遂行上必要な「連絡が取れる時間帯」を双方の協議・合意事項として定める
• 定例会議の日時を事前に合意し、契約書または個別の発注書に記載する
• 応答期限を、指揮命令ではなくサービス水準（成果条件）として定める
• 納期・中間マイルストーンを定める
• 月間稼働時間の下限・上限を報酬算定の基準として定める

書き方のコツは、「〜の時間帯に勤務すること」ではなく「〜の時間帯に連絡が取れる状態を維持すること」という条件の形にすること、そして時間帯を発注者の一方的な指定ではなく協議・合意事項として記載することです。同じ「日本時間 16:00〜18:00」という実態でも、勤務義務として書くのと、連絡調整が可能な時間帯として合意するのとでは、性質が変わります。

ただし、契約書の文言だけを整えても、運用実態が指揮命令に近ければ実態で判断されます。契約と運用の両方を揃えることが必要です。国内のオンサイト委託を含めた契約設計の全体像については、オンサイト業務委託の偽装請負リスクで契約設計のチェックリストを扱っています。

祝日カレンダー・長期休暇・支払サイクルを明文化する

時差そのものとは別に、海外委託では「相手が稼働していない日」の把握漏れが遅延要因になります。

祝日カレンダーを契約の添付資料にする

年間の祝日一覧を委託先から提出してもらい、契約または発注書の添付資料として共有します。特に注意が必要なのは長期休暇です。ベトナムのテト（旧正月）は前後を含めて 1 週間前後、中国の春節も同様に長期化します。インドのディワリ、イスラム圏のイード（ラマダン明け）、欧米のクリスマスから年始にかけての期間も、稼働が大きく落ちます。

さらに、長期休暇の直前・直後は生産性が下がる前提でスケジュールを引いてください。休暇明けの初週にリリースを設定するのは避けるのが無難です。

稼働できない日の事前通知期限を決める

有給休暇や私用による不稼働について、何日前までに通知するかを決めます。2 週間前を目安とし、スプリント計画に反映できるようにします。

支払条件を通貨・銀行営業日ベースで具体化する

支払通貨、為替レートの参照基準日、送金手数料の負担者、支払期日を明記します。支払期日は「どちらの国の銀行営業日を基準とするか」まで書かないと、実際の着金日でずれが生じます。

取引条件は必ず書面または電磁的方法で明示する

国内のフリーランスに業務委託する場合、2024 年 11 月 1 日に施行されたフリーランス・事業者間取引適正化等法により、発注事業者には取引条件を書面または電磁的方法（メール等）で明示する義務があります（公正取引委員会「フリーランス・事業者間取引適正化等法」パンフレット）。口頭での明示は認められていません。

海外在住のフリーランスへの委託に同法が適用されるかは事案ごとの判断になりますが、法適用の有無にかかわらず、稼働時間帯・応答時間・祝日の扱いといった時差運用の条件を書面またはメールで明示しておくことは、トラブル防止の観点から実務的に有益です。

時差運用が機能しているかを判断する指標と見直しサイクル

ここまでの 5 原則を導入したあと、それが機能しているかどうかを感覚ではなく数字で判断できる状態にしておきます。海外業務委託の時差運用は、経営層から「本当に回っているのか」と問われる場面が必ずあるため、説明可能な指標を持っておくこと自体が発注担当者を守ります。

見るべき 5 指標と取得方法

「重複帯の実利用率」の目安が 30〜50% であることには理由があります。高すぎる場合は会議過多であり、双方が集中作業の時間を失っています。低すぎる場合は重複時間を確保している意味がなく、時間を短縮して各自の集中作業に振り向けたほうが合理的です。

計測を始めるときは、5 つすべてを一度に追わないでください。最初の 4 週間は「意思決定リードタイム」1 つに絞ります。これは発注側自身の振る舞いを測る指標であり、改善に他者の協力を必要としないため、最も早く効果が出ます。この 1 指標が安定してから、ブロック時間と往復回数を追加します。

指標が悪化したときに疑う原則の対応表

指標が悪化したとき、どの原則に立ち返るべきかを整理しておきます。

見直しのサイクルは、スプリントごと（2 週間）に指標を確認し、月次で 5 原則のうち 1 つを選んで点検するのが現実的です。

注意点として、最初の 3 か月は運用ルールを変更しすぎないでください。重複時間と応答期限と依頼テンプレートを同時に変えると、どの変更が効いたのかが分からなくなります。1 か月に変更するのは 1 原則までと決めておくと、原因と結果の対応がつき、経営層への説明もしやすくなります。

まとめ｜タイムゾーン差は制約ではなく設計対象

海外リモート業務委託における時差は、減らすことができない定数です。しかし、時差によって生まれる待ち時間は、発注側の運用設計によって大きく減らせます。

本記事で整理した 5 原則を再掲します。

1. 重複勤務時間の設計: 必要量を業務から逆算する。実装期なら 1 日 2 時間が最低ライン。会議は重複帯の前半に置く
2. 応答時間のルール化: 緊急度を 3 段階に分け、応答期限とチャネルを決める。応答期限と解決期限を分ける
3. 意思決定権限の委譲: 委託先が自己判断してよい範囲を決め、依頼文に「不明時の既定動作」を必ず書く
4. 引き継ぎ単位の固定: タスク粒度は 0.5〜2 日。完了の定義を明文化し、日次ハンドオフメモを双方が書く
5. 契約への明文化: 稼働時間帯は「連絡が取れる時間帯」として協議・合意の形で記載し、祝日カレンダーと支払条件を添える

すべてを一度に整えようとすると挫折します。次の順序で着手することをおすすめします。

最初の一歩は、重複勤務時間の暫定合意と、緊急度 3 段階の取り決めです。この 2 つは委託先との 30 分の会話で決められますし、翌日から効果が出ます。

そして最も重要なのは、遅延の原因を「委託先の稼働」ではなく「発注側の意思決定リードタイム」から見直すという視点の転換です。この視点を持てば、時差は管理不能なリスクではなく、パラメータを決めれば制御できる設計対象になります。

外部人材の活用にあたって、契約形態の選定や発注体制の設計を社内で検討したい方は、関連するお役立ち資料もあわせてご覧いただけます。

海外・国内を問わず外部エンジニアの受け入れ体制の設計や、開発プロジェクトの進行支援をご検討中の方は、お問い合わせフォームからご相談ください。要件の整理段階からご相談いただけます。