インドのエンジニアを迎え、担当する機能を決めても、日本側の確認待ちが続くことがあります。その場合、人数や技術力より先に見直したいのがマネジメントの単位です。すべてを日本側が承認すると、現地メンバーは判断材料を持っていても先へ進めません。反対に、「任せる」と伝えるだけで決定権を渡すと、どこで相談すべきかが人によって変わります。

必要なのは、国籍に合わせた特別な管理ではありません。優先順位、設計、実装、リリースのうち、誰が何を決められるのか。どの変更はレビューを受け、どの状態になったら管理者へ相談するのか。仕事の境界を成果物と判断で示すことが、複数拠点のチームを動かす土台になります。

立ち上げ後に決める権限とレビュー条件

たとえば、認証画面の改善を一つ任せる場合でも、実装方法だけでなく、既存ライブラリを変更してよいか、公開日を動かしてよいか、追加のログを取得してよいかという判断が発生します。これらを一律に「担当者判断」または「日本側承認」とすると、権限が広すぎるか、確認が多すぎるかのどちらかになります。

マネジメントの出発点は、担当する機能ではなく、変更の種類ごとに決定者を置くことです。一般に、元へ戻しやすく影響範囲が小さい実装上の選択は、担当者へ渡しやすい領域です。セキュリティ、個人情報、契約、予算、公開日のように影響が広い判断は、指定した責任者の確認を残します。何を任せるかは、出身国ではなく、変更の影響と専門性で区切ります。

四つに分けた決定権と任せる範囲

一枚の表に「担当者」とだけ書くのではなく、優先順位、技術設計、実装、リリースの四つに分けます。プロジェクトによって項目は増減しますが、少なくとも次の情報があれば、質問の行き先を特定できます。

最終的に決める人と実行する人を分ける場面

最終的に決める人が、調査、実装、確認をすべて一人で行う必要はありません。GitLabは公開ハンドブックで、活動ごとにDirectly Responsible Individual（DRI）を置いています。DRIは担当範囲内の最終判断を担い、関係者から必要な情報や意見を集め、作業を分担します。製品の優先順位はプロダクトマネージャー、開発の完了はエンジニアリングマネージャーが担う例も示されています。

この考え方を使うなら、「日本側が決める」「インド側が実装する」という拠点単位の分け方は避けます。機能の優先順位を決める人、設計を承認する人、実装を進める人を明記し、現地の技術リーダーが設計について判断する場合は、その範囲も同じ表へ入れます。

表には、決める人の名前だけでなく、不在時に判断を引き継ぐ人と、判断を見直す条件も加えます。たとえば、通常は現地の技術リーダーへ任せる選択でも、共通基盤へ影響する場合は日本側の責任者が確認する、と書けます。担当者が休暇中でも、判断そのものを止めるのか、別の人が同じ条件で引き継ぐのかが分かれば、個人への依存を減らせます。

判断した後は、結論だけでなく、選ばなかった案と理由も短く残します。同じ前提で再び質問する時間を減らし、新しく加わった人も過去の経緯をたどれるようにするためです。記録先を判断の種類ごとに固定すると、会議の録画や個人のチャットを探す必要もなくなります。

参考：GitLab Handbook「Directly Responsible Individuals」

三段階の委譲レベル

任せる範囲は、「自由に決めてよい」「毎回承認が必要」の二択にしない方が運用しやすくなります。最初は、次の三段階で置くと確認条件を説明できます。

1. 実行前に相談：顧客データ、認証、料金、公開日など、影響が広い変更。
2. 実行後に共有：既存の設計方針に沿い、テストで戻せる変更。担当者が進め、同じ営業日内に判断理由を残す。
3. 担当者に委ねる：命名、局所的な整理、定めた範囲の不具合修正など、チームの規約で判断できる変更。

この区分には、具体例を一つずつ添えます。「重要な変更は相談」のままでは、重要かどうかを判断するために再び質問が必要になるからです。運用開始後に相談が集中する区分は、担当者の問題と決めつけず、境界の書き方が粗くないかを見直します。

工程別に分けるレビューの目的

マネジメントのためにレビューを増やしすぎると、担当者は確認用の資料づくりに時間を使い、日本側には確認待ちが積み上がります。一方、完成後だけを見ると、要件や設計の方向が違っていた場合に大きな手戻りが生じます。そこで、レビューを「いつ見るか」だけでなく、「何を判断する場か」で分けます。

着手前は目的と制約、実装中は戻しにくい選択

着手前に確認するのは、利用者、解決したい問題、対象範囲、変えてはいけない条件、完了時に観測できる結果です。ここで実装の細部まで指定する必要はありません。実装を担当する人が選べる余地と、選べない制約を分けることが目的です。

実装中のレビューは、データ構造、外部API、認証、共通部品など、後から戻す負担が大きい選択へ絞ります。完成後はコードだけでなく、受け入れ条件、テスト結果、運用手順、残った課題を見ます。各段階で同じ説明を求めず、次の判断に必要な成果物だけを指定します。

問い合わせ当番と専門家を分ける運用

GitLabのDistributionチームは、問い合わせや障害への対応を受け付ける責任者を週替わりで置き、通常の勤務時間内で対応する運用を公開しています。その人がすべてを解決するのではなく、必要に応じて専門家、エンジニアリングマネージャー、プロダクトマネージャーへ相談します。窓口と問題を最終的に解く人を分けることで、誰へ聞くかを探す時間を減らしています。

海外拠点との開発でも、質問を一人の管理者へ集める代わりに、当番が内容を整理し、設計、製品、セキュリティなどの担当者へつなぐ方法が使えます。当番の勤務時間外に緊急時の対応が必要なら、別の連絡経路をあらかじめ決めます。通常の質問と障害についての連絡を同じチャットへ混ぜないことも大切です。

参考：GitLab Handbook「Distribution Team Workflow」

日次・週次・月次の確認対象

毎日の会議で進捗、品質、役割、評価をすべて確認すると、報告項目が増え、判断したい内容が埋もれます。管理の周期ごとに目的を分けると、会議を増やさずに必要な変化を追えます。

日次で「何％終わったか」だけを聞くのではなく、次に動くために不足している判断を特定します。週次では、個別タスクの報告を繰り返さず、流れを止めた箇所を見ます。月次では、一か月の成果と判断履歴を材料に、どの区分を実行前相談から実行後共有へ移せるかを話し合います。

Slackの遠隔チーム向け公式ガイドは、勤務時間の監視より成果を優先し、非同期連絡の返信期待や、管理者へ相談できる時間を定める方法を挙げています。返信期限はすべてを急がせるためではなく、待ってよい時間を双方が判断するために使います。

参考：Slack「Best Practices for Managing Remote Teams」

相談の遅れを、個人の報告姿勢だけで評価しない

問題が大きくなってから共有された場合、「もっと早く報告してほしい」と伝えるだけでは再発を防げません。相談する条件が書かれていたか、相談先が勤務中だったか、質問に必要な資料がそろっていたかを確かめます。条件が曖昧なら、次の開発で使える形へ直します。

相談時には、少なくとも次の四点をそろえます。今どの状態か、何が未決か、このまま進むと何に影響するか、誰にいつまでに何を決めてほしいかです。緊急度は「急ぎ」だけで表さず、作業停止、本番障害、公開日への影響などの条件へ結びつけます。

AtlassianのWorking Agreementsは、チームで使う連絡手段、会議、フィードバックの方法、問題を引き上げる手順を明文化するための公開Playです。こうしたルールは管理者が一方的に配るのではなく、実際に使うメンバーと決め、一定期間ごとに改訂します。

参考：Atlassian「Working Agreements」

最初の30日で広げる担当者の裁量

最初から完成した管理の仕組みを作る必要はありません。実際の仕事を一つ選び、30日で決定権とレビューの置き方を試します。

1. 1週目：優先順位、設計、実装、リリースの決定者と相談条件を書く。最初の成果物と受け入れ条件を決める。
2. 2週目：一つの機能で三段階の委譲レベルを使う。質問とレビュー待ちの時間を記録する。
3. 3週目：同じ質問が繰り返された箇所、管理者だけが判断した箇所、担当者が迷わず進めた箇所を分ける。
4. 4週目：決定権の表を改訂し、一つだけ任せる範囲を広げる。影響が読めない項目は無理に渡さず、次の検証条件を決める。

確認する数字は、会議への出席時間やチャットの件数ではありません。質問から回答までの時間、レビュー待ち、差し戻しの理由、決定者が不明だった件数を見ます。数字は人を比較するためではなく、仕組みのどこを直すかを決める材料です。

採用要件へつなぐインド開発チームの管理課題

稼働後のマネジメントで見つかった課題は、次の採用要件にもつながります。設計についての判断を現地へ広げたいなら、実装経験だけでなく、選択肢を比較して理由を説明した経験が必要です。レビューが一人へ集中しているなら、人数を増やす前に技術リーダーや領域ごとの責任者を置く方法を検討します。

私たちは、必要なスキルと人数の整理、候補者探索、技術評価、面接、稼働開始の準備までを一続きで支援しています。稼働後に広げたい権限から必要な人材要件を逆算したい場合は、インド高度IT人材と開発体制についてご相談ください。