海外ソフトウェア開発チーム運用における三つの組織パターン

現在エンジニアリングマネージャーとして働いていますが、これまでのキャリアでベトナムチームとの協業、メンバーが複数国に分散しているチームなど、ソフトウェア開発メンバーが海外に居るパターンをいくつか経験しました。

本記事では、海外に開発メンバーが居る場合のチーム構成を3パターンに大別し、それぞれの制約や条件、そしてメリットやデメリットについてまとめます。

Globally distributed teams (国際分散チーム)
Local teams (国別チーム)
Subcontracting teams (業務委託チーム）

Globally distributed teams (国際分散チーム)

この構成では、単にチームメンバーが各地に分散しているだけで、国による境界は存在しません。

最も自由度が高く、小規模から大規模まで問題なくスケールします。

共通言語として英語を採用した場合、採用市場も大きく広がります。大手企業が公用語の英語化に踏み切って居るのは、この観点からも理にかなっていると言えます。

そもそもこの構成は、時差を無視してしまえば、「リモートメンバーが複数人居る国内チーム」と全く同じです。こう考えると、なぜこの構成が最も自由度が高くスケールもしやすいかわかりやすいと思います。コロナ禍以降でこのチーム形態に移行した日本国内の開発チームも多いのではないかと思います。

必要条件

全メンバーが1つの言語で意志疎通を取れること
タイムゾーンの差がチームの必須アクティビティにおいて許容範囲であること

メリット

チーム構成の自由度や柔軟性が最も高い
- 1チームからスタート可能
- 必要に応じてチームの組み直しも容易
国による分断がなくチームとしての一体感が高い
多様性が非常に高いチームが作れる

デメリット

分散チームであるためリモートワークが基本
多文化理解の必要性が高まる

Local teams (国別チーム)

独立した自律的な開発チームが各国に存在する構成です。

アーキテクチャや開発プロセス的に複数チームでの開発が可能であったり、そもそもプロダクトが複数ある場合など、それぞれのチームが自律的に動ける土壌がある場合に力を発揮します。

各国に大きな拠点があり、拠点毎に違うプロダクトや機能を開発しているような大企業でこのパターンが採用されていることが多いと思います。

実際にエンドユーザー的には同一プロダクトだったとしても「機能 A は A 国のとあるチーム、機能 B は B 国のとあるチーム」のような構成取る大企業をいくつか知っています。

最低2チームが必要になるため、スタートアップや中小規模の会社でこれを行う場合、プロダクトの成熟度や採用がボトルネックになり、この形態を取れないこと多い印象です。

必要条件

各国でそれぞれチームが形成できる人材が揃っていること (e.g. Product Manager, Engineering Manager, Tech Lead)
アーキテクチャや開発プロセスが複数チームによる開発を想定した設計になっていること

メリット

独立した自律的な開発チームの集合体となるため、チーム内において海外協業関連のデメリットがほぼ存在しない
- チーム内における言語の壁が存在しない
- 同一タイムゾーンで働ける
- オフィスを基本とした労働形態も取れる

デメリット

各国に個別の開発チームを構成できるだけの人材が必要になる
各国による分断が起きやすく、企業全体としての文化醸成の難易度が高い
複数チーム開発に耐えうるアーキテクチャや開発プロセスの成熟度が求められる

Subcontracting teams (業務委託チーム）

上流下流分離型とも言えます。一部の下流工程を海外メンバーに委託する形態です。

具体例として、日本側の Product Manager や Tech Lead がチケットを海外メンバーにアサインし、開発は海外側、レビュー以降は日本側で行うというのが挙げられます。

また、完全に上流下流が分離する必要はなく、国内メンバーはフルサイクルで開発をしつつ、海外メンバーは一部の下流のみを担当、ということも可能です。

図を見てわかる通り、コミュニケーションやタスクの流れが複雑化しており、効率性が悪いです。もし通訳が必要となった場合は、さらなる効率性の低下が懸念されます。

「各メンバーが同一言語でコミュニケーションを取れないが、プロダクトおよびプロダクトバックログは共有」という場合などに出現します。「海外メンバー用のチケットを選ぶ・準備する」のような作業が発生しているのであれば、このパターンに陥っているかなと思います。

陥っている、とネガティブな言い回しをしていますが、個人的には業務委託のデメリットと海外協業のデメリットの掛け合わせが発生するので、アンチパターンだと思っています。

Team Topologies などを参考に、チーム分割（その際アーキテクチャの見直しやプロダクト分割も必要になるかも）を行い、Local Teams (国別チーム) に早急に移行したいな、と個人的には思います。もしくは共用語を英語にして、Globally Distributed Teams (国際分散チーム) へ移行したいです。

必要条件

特になし（強いて言うなら、数多くのデメリットを受け入れられること）

メリット

既存のチーム、プロダクト、アーキテクチャなどに対する変更が少なくて済む
- 深く考えずに「とりあえず海外メンバー入れてみる」とこうなるということでもあるので、正直メリットなのか怪しい
SIer 方式（下請け方式）でのスケールが可能
- 言語の壁も委託先においては存在しない
- ウォーターフォールでの大規模開発には合いそう

デメリット

コミュニケーションのオーバーヘッドが大きい
- チーム全体ミーティング（デイリースクラムやレトロスペクティブ）を開くことが言語の壁により困難
- バックログの翻訳が必要になるケースが多い
海外メンバーが実態として下流工程のみを担当するため、いわゆる上流下流分離によるデメリットが出現する
- 海外メンバーが「チームへの帰属意識」や「Sense of ownership」を感じにくい
- 国内メンバーが海外メンバーへのチケットアサインやレビューで忙殺される
- 上流下流間での手戻りや質問などのやり取りのオーバーヘッド
実態として「大きく相互依存したサブチームの集合体」チームになるので、真に自律的な開発チームを作ることが難しい