インドのオフショアチームと上手に働く実践ガイド

ソフトウェアを開発している企業であれば、その一部がバンガロール、ハイデラバード、プネで作られ、テストされ、リリースされている可能性は十分にあります。インドはいまやグローバルなエンジニアリングを支える屋台骨であり、インドのオフショアチームと働くことは、エンジニア・エンジニアリングマネージャー・プロダクトマネージャーにとって、もはやニッチではなく中核的なスキルになりました。

それでも、その「うまいやり方」を体系的に教わった人はほとんどいません。私たちは試行錯誤で身につけていきます。引き継ぎのすれ違い、かみ合わないスタンドアップ、そして「はい、できています」が実は「ご要望は理解しています」という意味だった、というような経験を重ねながらです。良いニュースは、効果的な日印協業は学べるということです。それは、時差・コミュニケーション・文章による明確化・信頼という、いくつかの具体的な習慣に集約されます。

これは実践的なガイドです。抽象的な「異文化への配慮」を説くつもりはありません。インドのオフショアチームをマネジメントし、一緒にプロダクトを出していくうえで、実際に成果を左右するポイントだけを扱います。

時差という現実：IST と 10.5 時間のギャップ

まずは物理から始めましょう。すべてはこれを軸に動くからです。インド標準時（IST）は UTC+5:30 で、この中途半端な 30 分のズレが、カレンダー計算をしょっちゅう狂わせます。日本との関係でいうと、IST は日本時間（JST、UTC+9:00）より 3 時間 30 分遅れです。一方、本社や顧客が米国にある場合は、おおむね次のようになります。

米国東部時間（EST）より 10.5 時間先行
米国西部時間（PST）より 13.5 時間先行

つまり、インドの就業時間は欧米側の夜にあたり、欧米側の就業時間はインドの夕方にあたります。重なる時間は薄く、意識して守らなければなりません。日本（JST）から見ると、インドの 9:30〜18:30 の標準的な就業時間は、JST のおよそ 13:00〜22:00 に対応します。つまり日本の午後がそのまま「黄金の重なり時間」になります。米国チームとの関係も含めて整理すると、次のとおりです。

こちら側の開始時刻	こちら側の体感	インド現地時刻	重なりの質
13:00 JST	昼食後・日本の午後	9:30 IST	日本にとって最良の窓
6:30 AM PST	早朝・コーヒー前	19:00 IST	きつい — インドの一日の終わり
8:00 AM PST / 11:00 AM EST	午前	20:30 IST	インドには遅い時間。多用は避ける
7:30 AM EST	東海岸の早朝	18:00 IST	米国側にとって最良の相互窓

要点はこうです。日本の午後、米国の 東部の朝／西部の早朝 が、インドの 昼〜夕方 にきれいに重なります。これがライブで意思決定し、デモを見せ、ブロックを解消するためのリアルタイムの窓です。これを「聖域」として扱い、ドキュメントで済むステータス共有に浪費しないでください。

その窓の外にあるものは、すべて 非同期（async） で回す必要があります。これは妥協ではありません。正しくやれば非同期はむしろ強力な武器です。なぜなら、明確さを強制してくれるからです。次の習慣を身につけましょう。

決まったことはその場で書き残す。 翌日に両側が読めるチャンネルに記録します。
一日の終わりは「質問」ではなく「引き継ぎ」で締める。 インド側が 12 時間あなたの返信を待たずに済むよう、ブロックの解けたタスクをまとめて渡します。
質問はまとめて送る。 一日に 5 回 Slack を飛ばす代わりに、一度で答えられる構造化された 1 通を送ります。
デモや重要な会議は録画する。 反対側の時間帯では誰も起きて出られない会議より、5 分の Loom 動画のほうが価値があります。

コミュニケーションの作法：遠回しな「Yes」と言いにくい「No」

ここで多くのマネージャーがつまずきます。そしてそれは能力とは無関係です。インドのビジネス文化の多くでは、コミュニケーションが調和と、依頼してきた相手への敬意に傾きます。マネージャーにはっきり「No」と言うこと、あるいは「これは詰まっている」「遅れている」と公の場で認めることは、失礼にあたる、あるいは相手の面子を脅かすと感じられがちです。そのため、本来はもっと弱い意味の、楽観的な「Yes」を耳にすることがよくあります。

これは不誠実なのではありません。礼儀の「初期設定」が違うだけです。あなたの仕事は、本当のステータスを安全かつ簡単に表に出せるような質問をすることです。直すべきはほとんど あなた側 です。質問を変えれば、返ってくる答えも変わります。

聞こえてくる言葉	実際の意味	真実を引き出す聞き方
「はい、できています」	「自分の担当は終わった／内容は理解した」	「いいですね — マージ済みで CI も通っていますか、それともまだレビュー中ですか？」
「やってみます」	「これは危うい。自信がありません」	「金曜に間に合わせるには何がうまくいけばいいですか？一番のリスクは？」
「問題ありません」	「聞きました」（必ずしも合意ではない）	「認識をそろえたいので、どう進めるか手順を話してもらえますか？」
通話中の沈黙	反対意見、または上位者への遠慮	「私と違っていても構わないので、率直なところをぜひ聞かせてください」

一貫して効くルールをいくつか挙げます。

Yes/No で答えられる質問ではなく、オープンな質問をする。 「できましたか？」は礼儀正しい「はい」を誘います。「残っている作業を順に教えてください」は真実を誘います。
ステータスを表す言葉ではなく、次の具体的な成果物を求める。 PR のリンク、スクリーンショット、通ったテストなどです。
悪い知らせを伝えやすい空気をつくる。 リスクを早めに挙げてくれたことに感謝しましょう。「これは詰まっています」に一度でも険しく反応すれば、チーム全体に「報告するな」と教えてしまいます。
反対意見は 1on1 で扱う。 グループの場ではあなたに反論しない人も、1 対 1 ではしばしば率直になります。

この背景にある文化的な仕組みをもっと深く知りたい方は、インド英語完全ガイドもあわせてご覧ください。階層・面子・直接さといった要素を、より詳しく整理しています。

言語というレイヤー：通話に出てくるインド英語

コミュニケーションの作法の下には、もう一段、言語そのものというレイヤーがあります。インド英語（IndE）は、完成度が高く、流暢で、れっきとした英語の一変種です。ただし独自の語彙・慣用句・アクセントのパターンがあり、米国人や日本人の耳を一瞬だけ戸惑わせることがあります。同僚が「EOD までに revert します」と言ったら、それは「元に戻す（undo）」ではなく「返信する」という意味です（EOD は End of Day、その日の終わりまで）。「Do the needful」は「必要な対応をお願いします」、「Prepone」は postpone（延期）の反対で「前倒しする」という、便利でとてもインドらしい語です。

これらは「直すべき誤り」ではありません。数億人が話す方言の特徴であり、すばやく読み解けるようになると、日々の摩擦が驚くほど減ります。アクセント（音節を等間隔で刻むリズム、そり舌音、異なる強勢の位置）も同じ話で、難しさの問題ではなく慣れの問題です。

このギャップを埋めるためにつくられたのが、まさに SpiceTalk です。本物のインド英語で耳を鍛えることで、スタンドアップで聞こえてくる語彙やアクセントが「障害物」ではなく、ただの「英語」になっていきます。まず読み物から入りたい方は、語彙についてはインド英語完全ガイド、リスニングについてはインド英語のアクセントから始めてみてください。

本当に機能するスタンドアップと引き継ぎ

重なる時間が薄いほど、同期で使う時間はその価値を証明しなければなりません。とくにスタンドアップがそうです。

スタンドアップは原則として非同期にしましょう。 文章によるスタンドアップ（各自がブロッカー・進捗・予定をチャンネルに書く）は、時差を尊重し、検索できる記録を残します。ライブの通話は、本当にリアルタイムのやり取りが必要なものに絞ります。設計の議論、デモ、ブロック解消、そして関係づくりです。

ライブのスタンドアップをやるときは、

小さく、焦点を絞って。 ステータスは文章に。通話は意思決定とブロッカーのために使います。
ブロッカーを明示的に促す。 「何が妨げになっていますか？」を、温かいトーンで毎回問う固定アジェンダにしましょう。
担当を声に出して確認する。 各項目の最後に「では水曜までに X はあなたが担当、で合っていますか？」と確認し、後で文章に残します。

引き継ぎこそ、オフショアチームの勝負どころです。 こちらの一日が終わる頃に相手の一日が終わりかけ、その逆もまた然り。あらゆる引き継ぎは 12 時間のギャップをまたぐバトンパスです。バトンを落とせば、まる一日を失います。だからこそ、

一日の終わりは 文章の引き継ぎ で締める。何が終わり、何が詰まり、次は何で、誰が何を決めるのか。
タスクだけでなく 背景（コンテキスト） を前もって渡す。「エンドポイント X を作って」は命令です。「モバイルチームが Y のローンチで必要としているのでエンドポイント X を作ってほしい、これが仕様です」はパートナーシップです。
あいまいなブロッカーを一晩あなた待ちにしない。 インド時間の 14:00 に質問にぶつかりそうなら、ログオフ前に先回りして答えておきましょう。

時差を越えて伝わるチケットと仕様の書き方

肩を叩いて聞ける相手がいないとき、あなたの「文章」がそのままマネジメントになります。対面なら 30 秒で済む不明点も、あいまいなチケットでは非同期のやり取りでまる一日を溶かしかねません。文章の明確さを、コストではなく「効果を何倍にもする装置」として扱いましょう。

オフショア対応の良いチケットには、次が含まれます。

「何を」だけでなく「なぜ」。 背景があれば、現実がチケットからズレたとき（必ずズレます）でも、エンジニアが良い判断を下せます。
明確な受け入れ条件。 「完了」とは具体的にどういう状態か。箇条書きにしましょう。これは「はい、できています」のあいまいさを、根本から取り除いてくれます。
エッジケースと非ゴール。 スコープに 入らない ものを、入るものと同じくらいはっきり書きます。
すべてへのリンク。 デザイン、関連 PR、該当の Slack スレッド、過去の実装などです。
未決事項の決定者を名指しで。 「誰が Yes と言えるのか」を探すために作業が止まらないようにします。

判断基準はこうです。あなたと一度も話したことのない有能なエンジニアが、あなたの深夜 23 時にこのチケットだけを見て、正しいものを作れるか。作れないなら、作れるようになるまで背景を足しましょう。

信頼と関係を築く

分散チームは信頼で動きます。そしてその信頼は、「相手を遠隔の作業要員ではなく対等な仲間として尊重している」という、数十もの小さなシグナルを通じて積み上がります。

カレンダーを尊重する。 インドの祝祭日は豊かで、地域色も強いものです。ディワリ（光の祭り、通常 10〜11 月）が最大の祝祭で、多くの人にとっては正月とお盆が一緒に来たような、家族と過ごす数日間です。ほかにも ホーリー、ポンガル、オナム、イード など、地域ごとの祝日も数多くあります。これらにローンチや当番の山場、「ちょっとだけ」の締め切りをぶつけてはいけません。どの祝日が 自分たちにとって 大切かを早めにチームに尋ね、その日付を共有カレンダーに載せ、元日やお盆と同じ真剣さで守りましょう。ディワリに締め切りを設定するほど、「あなたは二の次だ」と伝えてしまうものはありません。

階層と年功を尊重する — ただし正しく読み取りましょう。インドのビジネス文化は、フラットなエンジニアリング文化に比べて、上位者への敬意がより強く働くことがよくあります。若手のエンジニアは、グループの場でリードや上位のマネージャーに公然と異を唱えないかもしれません。その階層を自分が採り入れる必要はありませんが、意識はしておきましょう。若手の声が出る余地を能動的につくり、率直なフィードバックは安全に感じられる経路を通して受け取ります。

人としての層に投資する。 名前の正しい発音を覚えましょう。尋ねて、そして正しく呼ぶ。通話の最初の 2 分は仕事以外の話に使う。祭りや節目を祝う。この数分は無駄ではありません。後で難しい会話を可能にしてくれる土台です。

ありがちなオフショアのアンチパターンを避ける

うまくいかなくなるオフショアの関係の多くは、才能で失敗するのではありません。「組み立て方」で失敗します。次に気をつけましょう。

チームを「指示の受け手」として扱う。 背景も裁量も与えずチケットを投げれば、指定したものがそのまま返ってきます。それ以上は何も — あなたの間違いまで、忠実に実装されて返ってきます。タスクではなく、問題とオーナーシップを渡しましょう。
背景を抱え込む。 オフショアチームは、ビジネス・顧客・ロードマップから「遠い」位置にあります。それは彼らのせいではなく、あなたが能動的に埋めるべきギャップです。「なぜ」を惜しみなく共有しましょう。顧客の声、戦略の変化、本当に大事な指標などです。
犯人探しの文化。 何かが壊れたとき、反射的に「反対側の誰のせいか」を探し始めると、人はリスクを取らなくなり、問題を早めに表に出さなくなります。「犯人を探さないポストモーテム」を、本気で実践しましょう。心理的安全性は、海を越えると築くのが難しく、壊すのは簡単です。
二層構造のチーム。 オンショアが「面白い」アーキテクチャを担い、オフショアが「雑用」を担う。これは有害で、しかも自己成就します。意味があり、あいまいで、オーナーシップの大きい仕事を、両側に配分しましょう。
引き継ぎ地獄。 すべてのタスクに本社の承認が要るなら、スループットは重なる時間の幅で頭打ちになります。意思決定の権限を、作業に最も近いチームへ押し下げましょう。

敬意あるフィードバックを伝える

文化と時差を越えたフィードバックには、より少なくではなく、より多くの配慮が必要です。目指すのは、相手の立場への打撃ではなく、支援として届く率直さです。

称賛は公の場で、是正は個別に。 公の場での批判はとくに面子を脅かしがちです。是正フィードバックには 1on1（あるいはダイレクトメッセージ）がほぼ常に正解です。
具体的に、行動について語る。 決して人格についてではありません。「この PR は、合意していたエラーハンドリングが入らないまま出ました」と言い、「あなたは不注意だ」とは言いません。
基準と人を切り離す。 あなたが高い基準を持つのは、相手にそれを満たす力があると尊重しているからこそだ、と明確に伝えましょう。
改善のループを閉じる。 誰かがフィードバックを受けて動いたら、それを言葉にして感謝しましょう。そうやって「正直であることは安全で、リスクを取る価値がある」と証明していきます。

そして、逆方向のフィードバックも招きましょう。協業をもっとやりやすくするために あなたに 何ができるかをオフショアの同僚に尋ね、そして実際に何かを変えるのです。インド側が伝えたことをもとにマネージャーが行動を変える — これほど早く信頼を築くものは、そう多くありません。

最初の 1 か月のチェックリスト

これからインドのオフショアチームのマネジメントに踏み込む方へ、具体的な 30 日間のスターターを用意しました。

どれも特別なことではありません。インドのオフショアチームと上手に働くことは、その多くが「良い分散エンジニアリングマネジメント」を、本物の敬意とほんの少しの文化的な流暢さとともに実践することにほかなりません。重なりの時間を守り、書き残し、「なぜ」を共有し、カレンダーを尊重し、真実を伝えやすい空気をつくる。これを一貫して続ければ、あなたとチームの間にある海は、障壁ではなく「24 時間動き続ける強み」へと変わっていきます。

#オフショア#インド#リモートチーム#協業#マネジメント