地理的に分散したアジャイルチーム

 

多くのアジャイルチームは、何らかの形で地理的に分散している。この記事では、地理的な分散がどのようにアジャイルチームに影響を与えるかを説明する。そのため、下記の一連の質問に対処していく。

  1. 地理的に分散しているとはどういう意味か?
  2. アジャイルチームは実際に分散しているか?
  3. 地理的な分散は他のスケールファクターにどの程度関連しているか?
  4. 地理的な分散の潜在的な利益は何か?
  5. 地理的な分散にともなうリスクは何か?
  6. これらのリスクはどのように減らせるか?
  7. 地理的に分散したアジャイルチームをどのように組織するか?
  8. 地理的な分散はツールの選択肢にどのような影響を与えるか?
  9. 地理的な分散は得策か?
  10. どこからはじめるか?
  11. その他の参考文献

地理的に分散しているとはどういう意味か?

チームが 同じ拠点と考えられるのは、開発者と主要な利害関係者がみんな同じ作業部屋にいるときである。そうでなければ、何らかの形で、地理的に分散・拡散しているといえる。仕切りで区切られる、あるいは、分離されたオフィス内のチームメンバーがいる場合さえ、わずかに分散している。最初、はっきりしないかもしれないが、人がキューブによって分離され、数メートル離される、このレベルでさえ地理的な分散である。それがチームにコミュニケーションリスクをもたらす。さらに悪い場合がある。チームメンバーが、同じビルの異なるフロアで働いていたり、地理的に同じエリアでも異なるビル(チームによっては同じ市内の異なるビルや、数日間は家)で働いたりする。あるいは、同じ国の異なる市で働いているかもしれないし、地球のどこかの都市で働いているかもしれない。多くの場合は、これらの組み合わせである。

図1は、地理的な分散と、地理的な拡散の違いを表している。どのメンバーも一緒に居ないとき、チームは完全に拡散している。この場合、彼らは異なるキューブにいたり、同じビルの異なるオフィスに居たり、離れたビルで働いているかもしれない。異なる場所に、一つ以上の同じ拠点のチームがある場合、それは分散サブチームとして知られている(同じビル、同じフロアの異なる部門の場合もである)。多くの場合、同じ場所に居ても、何人か別の場所(おそらくキューブ内や家)に居て、部分的に分散している。それから、もちろん、分散したサブチームのうち、一つ以上のサブチームが部分的に拡散している場合もある。(図に現れないが)この記事では、以下の用語を使っている。

  • 地理的に分散したチーム。 便宜上、これは、地理的に分散と拡散したチームメンバーを含んでいる。
  • 同じ拠点。 チームが一つの部屋、しばしば ”War room”、”pod”、”Tiger team room” と呼ばれる部屋で働いている。
  • 近い拠点。 車でいける距離内にすべてのチームメンバーがいる(言い換えるなら、必要あれば、毎日みんなが一つの場所に集まることができる距離にいる)。
  • 遠い拠点。 物理的に会うために奮闘するほど離れている人が一人以上いる。

図1 地理的な分散と拡散
team-distribution-ja

アジャイルチームは実際に分散しているか?

いかにも、多くのアジャイルチームは地理的に分散している。図2の2014年ソフトウェア開発のスケール調査では、39% のチームがほぼ同じ拠点にいる。23% のチームが、近い拠点におり、38% のチームが遠い拠点にいる。この調査は、開発チームのメンバーにのみ質問しており、同じ部屋に利害関係者がいるかどうか質問していないことに注意しよう。以前の調査では、利害関係者が開発者チームと同じ拠点にいるのはかなり珍しいことを示していた。つまり、同じ拠点にいるアジャイルチームが39%であるという数値は、非常に楽観的な見積もりである。

図2 アジャイルチームと地理的な分散

図3の2012年のAgility at Scale 調査 では、すべての地理的分散レベルにおいて、成功する組織があることがわかる(緑のバー)。また、それぞれのレベルに失敗している組織があることもわかる(赤のバー)。この調査では、地理的に分散したチームがどれくらい離れているかに関係なくアジャイル開発に成功する可能性があるが、また、実際に成功する保証がないことも示している。この事実は、この記事のアドバイスに読者が関心を持つ動機となるだろう。

図3 地理的な分散によるアジャイル開発体験

肝心なことは、少なくともいくつかの組織では、地理的に分散しているチームにアジャイルテクニックを適用することに成功している。実際、図2を見れば分かるように、地理的に分散しているアジャイル開発は、アジャイルに関する主流の議論以上にはるかに一般的である。

地理的な分散は他のスケールファクターにどの程度関連しているか?

図4を見ると、Software Development Context Framework (SDCF) は6つのスケーリングファクターがあり、そのうち一つは地理的分散のファクターである。他に、地理的な分散に関連しているファクターは以下の3つである。

  1. ドメインの複雑さ。 ある複雑な問題は、しばしば大規模チームの必要性を促す。それはつまり、地理的に分散したチームの必要性を促す。
  2. チームサイズ。 一つの拠点からいつでも大規模アジャイルチームを調達できるわけではない。相応しい技術力をもった十分な人すべてが一つの拠点にいるわけではない。結果的に、大きなチームほど、少なくとも部分的に分散される可能性が大いに高くなるだろう。
  3. 組織の分散。 多くの場合チームが地理的に分散している理由は、仕事の一部がアウトソーシングされていることにある。

図4 SDCF におけるスケーリングファクター
Context Factors

地理的な分散の潜在的な利益は何か?

実際、地理的な分散の潜在的な利益はいくつかある。

  1. 技術力のある人材の大きな貯蔵庫へのアクセス。 特に特殊な技術が必要とされる場合、多くの組織は、ローカルのIT部門内での人集めに苦労する。
  2. 低開発コスト。 国々の賃金の違いの結果、同じ国内の市との違いの結果さえ、表面上は節約になる。しかし、これらの節約は、地理的な分散に関するオーバーヘッドの増加によって、すぐに無くなることがある。- プログラマの時間的単価だけでなく総保有コスト(TCO)を考え、コスト節約を計算しなければならない。コスト節約を実現するためには、オーバーヘッドを抑えられるよう、開発要員が意識的にことにあたらなければならない。
  3. 市場への投入時間の短縮。 チームが「follow the sun」アプローチをとるために十分に意識的に活動していれば、すばやい納期を実現するチャンスがある。 基本的な考えは、グローバルに分散したサブチームが、自分たちの日中に作業をし、その後、別のチームに作業を引き継ぎ、チームがいくつかのタイムゾーンに分かれるようにすることである。あるチームが作業を行い、その後、その作業を次のチームに引き継ぐ。実際に仕事をするのはかなり難しく、確たるアーキテクチャ、高品質なコード、開発規約、自動のRT、洗練された構成管理を必要とする。全サイクルを2、3チームで構成するとうまくいくところはあるが、ほとんどの組織は、実際には、この戦略的作業に苦労する。課題の一つは、プロダクトオーナーまたは代理のプロダクトオーナーに、”唯一信頼できる情報源”として24時間アクセスできるかという点である。

地理的な分散にともなうリスクは何か?

チームがより分散するにつれて、プロジェクトのリスクは、いくつかの理由で増えていく。

  1. コミュニケーションの課題。  二人以上の人間のコミュニケーションで最も効果的な手段は、ホワイトボードや紙切れのような共有したスケッチ空間での face-to-face のコミュニケーションである。もちろん、これは、同じ部屋に一緒にいる必要がある。分散が進めば進むほど、図5にあるようなあまり効果的でないコミュニケーション戦略に頼りはじめるが、明文化された情報が永続化されやすい効果もある。face-to-face のコミュニケーションが取れない場合、その最中にさらに多くの価値ある情報を読み取ることができるボディランゲージを観察することができない。
  2. 時間的な課題。 異なるタイムゾーンにいる場合、共通の作業時間を見つけるのは難しくなり、コミュニケーションの課題が増えることになる。 これらの課題に取り組むには、図5に暗示されているように普段以上に多くのドキュメントを作る必要があることに気づくだろう。詳細はこのあと説明する。
  3. 文化的な課題。 チームが分散するにつれて、拠点間の文化的な課題はしばしば増える。異なる文化においては、異なる労働倫理があり、知的財産も異なって扱われ、コミットメントについては異なる考えがあり、あまり自己組織化を受け入れる傾向にないかもしれない。また、休日が異なったり、物事に対するアプローチが異なったりする、などがある。ある人が “yes” という場合、それが単純に何を意味していることさえ、実際には非常に困難な可能性がある。

図5 コミュニケーション戦略の比較

リスクはチームが分散するにつれ増えるので、アジャイルプロジェクトの成功率はチームが分散すればするほど低くなっていく。図6の 2008年 IT Project Success Survey では、同じ拠点のアジャイルチームの成功率は 79%である。近い拠点のチーム(メンバーが地理的に同じエリアにいる場合)の成功率は73%である。そして、遠い拠点のチームの成功率は 55%である。この成功率は、他のパラダイムに従うプロジェクトにおいても、同様に減っている。

図6 地理的な分散の度合いによる成功率

これらのリスクはどのように減らせるか?

地理的に分散したソフトウェア開発は、明らかにリスクのある命題ではあるが、これらのリスクを克服するために採用される戦略がある。

戦略1: 前向きなチーム文化を構築する

これはどのチームにとっても重要だが、とりわけ、地理的に分散したチームにとっては、コミュニケーションや協調に関して難しさが増大するため、極めて重要である。協調と尊敬に基づく文化と、そして、たとえお互いがかなり離れても一緒に働きたいと思える文化を醸成したい。

戦略2: 最初にキーチームメンバーを集める

プロジェクトの最も危険な時期の一つは初期である。これは効果的なチームの基盤を築く時期であり、チームが目指す共通のビジョンを開発する時期であり、正しい方向に進み始める時期だからである。もし集めることができなければ、ビジョンもできず正しい方向に進み出すこともできない時期になる。

できる限り努力し、少なくともキーとなる人々(チームリード、プロダクトオーナー、アーキテクチャオーナー、重要な利害関係者)を最初の時期に集め、どのように一緒に働いていくかという重要な側面に対処することを提案する。これは、スコープや技術戦略の初期モデリング、初期のハイレベル計画、初期リスクアセスメントを含んでいる。ビジョンを合意するために、理想的には、最初の時期に、チームメンバーとキーとなる利害関係者すべてを集めるべきであるが、少なくともその時点で関連する人すべてを集めるべきである。明らかに、これはキーとなる人々だけを集めるより費用がかかる。しかし、チームの成功のためにより強固な基盤にすることができる。

これは、何人かの人たちを出張させる必要があることを意味し、初期費用を増やし、多くの組織がためらう投資となる。現実には、結局、出張費を支払うことなる。なぜなら、プロジェクトのあらゆる期間でコミュニケーション費用が高くなるからである。多くの場合、プロジェクトの初期に人を集めることは、そうしないよりずっと費用はかからない。

戦略3: 少し多めに先行モデリングを行う

地理的に分散したチームに関して増えたリスクのために、少し多めに先行要求モデリングや先行アーキテクチャモデリングをしたい。 図7は、初期スコープを探索するためのプロセスゴール図を描いている。図8は、初期の技術戦略を特定するためのプロセスゴール図を描いている。両方のケースで、ドキュメントを少し多めにフォーマルにする必要があり、wikiのような電子ツール、Visio などの描画ツール、Blueprint やEnterprise Architect のようなモデリング/CASEツールを使ってモデルを記録することになる。また、通常、同じ拠点のチームと比較して、いくつか多めにモデルビューを作る必要があることに気づくかもしれない。それは、完全に異なる拠点で、戦略を十分に理解するよう促す必要があるからである。

図7 初期スコープを探索するためのプロセスゴール
goal-inception-explore-initial-scope

図8 初期の技術戦略を特定するのためのプロセスゴール
goal-inception-identify-initial-technical-strategy

戦略4: 少し多めに先行計画を行う

地理的に分散した拠点での開発は同じ拠点での開発よりリスクが高いので、計画を考えることにもっと労力をつぎ込みたいと思うだろう。それは、巨大で1000以上のタスクガントチャートを作成するわけではなく、主要な依存性とマイルストーン日を特定すべきである。効果的なチームは、分散した拠点の開発者(結局は分散した拠点の開発者もチームの一員)とともに活発にこの計画を行い、関連するすべてのコストを考える。とりわけ、プロジェクトキラーとなるような、確率は低くくても衝撃の大きいリスクを見逃さない。 図9は、初期のリリース計画を策定するためのプロセスゴール図を描いている。地理的分散チームの場合、簡易に予測型のような戦略をファシリテートするマネージャ/リードが、多くのチームで自然にうまくいくことに気づくだろう。

図9 初期のリリース計画を策定するためのプロセスゴール

goal-inception-develop-initial-release-plan

戦略5: 定期的に統合する

アジャイルチームは、定期的に、できれば一日に何度も統合するべきで、それによって、フィードバックを減らし、生産性を増やしていく。同じことが地理的分散チームの真実といえるが、チームが複雑で大きな問題を引き受けた場合、難しいこともある(複雑なソリューションであればあるほど、一般的に統合するのは難しい)。大きいチームか、地理的に分散したチームでは、全体の統合と、ソリューション全体のend-to-end テストを特別に任せる一つのサブチームが必要なことに気づく。他のサブチームは自分たちの作業範囲を全力で統合しテストすることで、理想的には、この追加チームは必要としない。しかし、一般的に、大きなプログラムや地理的に分散したチームでは、チーム間の統合やテストの問題を見逃しやすいので、それを扱うチームを分離させることはしばしば無駄がなく理にかなっていることが分かっている。

Scaled Agile Framework (SAFe) では、この戦略は統合チームと呼ばれているが、 DAでは、独立テストチーム、あるいは、独立テスト・統合チームと呼んでいる。実際に、主要な取り組みがテストに焦点をあてているように見受けられるからである。

戦略6: コミュニケーションがクリティカルであると認識する

GDD (Geographically Distributed Development)は、多くのコミュニケーションの壁を築き、全体的にプロジェクトのリスクを増やしていく。これらのリスクを克服するには、まずこれらを意識し、善処する必要がある。次に、より多くのドキュメントを書く必要がある。遠距離のコミュニケーションに関するリスクは、文化的違い、タイムゾーンの差、ドキュメント記載(実際、情報伝達の効果が最も少ない方法)の課題を含んでいる。自由回答形式質問を尋ねることを習慣とし、他の人々が本当に会話のトピックを理解しているかどうかを見極めるようにすべきである。「はい/いいえ」 形式質問で尋ねてはいけない。なぜなら、「はい」 という単純な答えには、文化に依存した物事の範囲を意味する可能性があるからである。「はい。聞いてます」という場合もあれば、「はい、理解してます」という場合もあり、「はい、賛成です。」という場合かもしれない。他の拠点の人と付き合うとき、会話を要約するよう依頼するのはよいプラクティスである。特に、キーとなるアクションアイテムやそれらのオーナーシップを特定したり、議論したことを全員が賛成していることを確認するのは良い。良いアプローチは、先方のチームリードにサマリをしてもらい、彼らに責任をもってもらうことである。もちろん、これは可能な限り軽い作法で済ませるべきである。

戦略7: 日次調整ミーティングを開く

同じ拠点にいるアジャイルチーム間での一般的なプラクティスは、日次調整ミーティングを開くことで、これはスタンドアップミーティングやスクラムミーティングとも呼ばれる。分散したチーム間では、同じ地域の人たちがローカルで同様にスタンドアップミーティングを開き、そして、各拠点からの代表者がサブチーム間の調整する共有会議を開く。この戦略は、”スクラムオブスクラム”と呼ばれ、5から6チームぐらいまでうまくいくが、大きな取り組みでは 境界連結者戦略(後述する)に置き換える必要がある。

タイムゾーンが異なるとさらに難しくなる。ローカルだけのスタンドアップミーテイングは午前最初に開かれるが、タイムゾーンが異なる人がいる場合、日次スタンドアップミーティングは普通でない時間に実施する必要があるかもしれない。同様に、タイムゾーンが異なるサブチーム間の調整は、サブチームを尊重した時間に開く必要があり、営業日よりもタイムゾーンの差が大きい場合、会議を開くのは難しいことがある。例えば、トロントとプネの間のタイムゾーンは現在10.5 時間あり、両方の拠点でなく少なくとも一つの拠点の代表者は、都合の悪い時間に開かれる。そんな電話会議の痛みを分かち合ったり、尊重して仕事をするには、多くのチームが、調整会議の時間をローテーションすることを選択するだろう。

戦略8: 遠い拠点に定期的に出張するアンバサダーを用意する

プロジェクトの初期にチームを集めることは、コミュニケーションの基盤を作るが、チーム間の効果的な協調を維持するための継続的な投資がなくなれば、全体の戦略から逸脱するサブチームを生むリスクを負ってしまう。アンバサダーとは、拠点を定期的に出張する人たちで、上級技術者または上級ビジネスエキスパートがなることが多い。彼らはサブチーム間で情報を共有させる。アンバサダーは、自分の拠点から離れ、ほとんどは1週間から2週間の長さの短期間で作業する。なぜなら、実際に出張する人は精神的重圧を受けるためである。結果的に、いつでも誰かが拠点を行き来しているように、合理的なローテーションスケジュールで飛び回る数名の人を用意することになる。 このプラクティスでは、 ローカルチームの部屋にアンバサダーが訪ねてきたとき利用できる机を用意し、受け入れるようにする。

戦略9: 各拠点の境界連結者を用意する。

境界連結者は、拠点にいる人で、サブチーム内と同様に日々サブチーム間とコミュニケーションできる人である。Disciplined Agile Delivery (DAD)チームでは、3つの役割に境界連結者としての責務をもたせている。

  • チームリードは、サブチーム間のプロジェクト管理を調整する。
  • プロダクトオーナーは、サブチーム間の要求管理の問題を調整する。
  • アーキテクチャーオーナーは、サブチーム間の技術的問題を調整する。

境界連結者たちは、同僚と緊密に働き、すべてのサブチームとの定期的な調整会議を開くだけでなく、ときには、個々のサブチームで発生する特別な問題に対応するため一対一緊急会議を開く。

地理的に分散したアジャイルチームをどのように組織するか?

表1にあるように、大きく地理的に分散されたサブチームを組織するために4つの戦略がある。

  1. コンポーネントチーム。 このアプローチでは、各サブチームが1つ以上のサブシステムまたはモジュールの責任を負うことで、異なったチーム間で必要な情報共有とコラボレーションの量を減らすことができる。ただしチームの一部が自宅で働いていると困難なことがありうる。コンポーネントチームを、アーキテクチャーを中心に効果的に組織化するためには、そのアーキテクチャーを確認するのに十分な時間を事前に投資する必要がある。
  2. フィーチャーチーム。 フィーチャーチームは、ユーザーストーリーやユースケースなどの機能要件をエンドツーエンドで実装する責任がある。これは、よくソリューションの垂直スライスの実装と呼ばれる。特定のフィーチャーチームは、例えば金融機関内の仲介または生命保険などの単一ビジネスライン(LoB)の要件に焦点を当てるので、LoBの専門知識を得ることができる。フィーチャーチームが、組織内の特定のアプリケーションまたはシステムに固有の要件を引き受ける場合もある。
  3. ファンクショナル(職能)チーム。 いくつかの大規模チームは、アーキテクチャチーム、開発チーム、テストチーム、デプロイメントチームなどの開発職務チームによって組織される。各チームはそれぞれの専門職務に焦点を当て、成果を他のファンクショナル(職能)チームに引き継ぐ。
  4. 内部オープンソースチーム。 すべての成果物が組織にとって非公開であっても、コンポーネントやサブシステムをオープンソースの方法で開発することがある。他のチームの開発者が、コンポーネントを自発的に開発し、徐々に進化させる。Scott(筆者)がIBMに所属していたとき、この戦略はいくつかのIBM製品で再利用された数個の重要なコンポーネントについて実際に採用していた。この戦略に関する詳細な考え方については、Reuse Through Internal Open Sourceを参照のこと。

表1 チームの組織化戦略の比較

チーム戦略 長所 短所 備考
 コンポーネントチーム
  • サブチーム間のコミュニケーションを減らせる。
  • チームはコンポーネントに固有の技術的専門知識を築ける。
  • 疎結合かつ凝集度の高いアーキテクチャーが必要である。
  • 機能の依存管理は、複雑になるかもしれない。
  • 要件をコンポーネントごとに集約する必要がある。
  • 凝集度が高く、疎結合のコンポーネントまたはサブシステムに適用する。
  •  技術的専門知識を必要とするセキュリティフレームワークやデータベースカプセル化サービスなどの技術指向コンポーネントに適用する。
 フィーチャーチーム
  • チームはビジネスのサブセットに集中できる。
  • フィーチャーをチームに簡単に割り当てられるかもしれない。
  • 共通の、開発の決まりごとが必要である。
  • 洗練された構成管理が必要である。
  • 技術的な依存関係の管理が、複雑になるかもしれない。
  • 要件の依存関係の管理が、複雑になるかもしれない。
  •  開発者が問題のドメインを深く理解することを要求する複雑なLoBやアプリケーションに適用する。
 ファンクショナル(職能)チーム
  •  個人の職務の専門化ができる。
  • 従来のやり方に深い経験を持つ人々が受け入れやすい。
  •  多能工ではなく、専門家になるよう動機付けられる。
  • チーム間のコミュニケーションが重要だが、オーバーヘッドである。
  • より多くの文書とそのレビューが必要である。
  • より一層の監視が必要である。
  • プロジェクト全体および組織のリスクを増加させる。
  •  統合チームがソリューション全体を統合し、エンドツーエンドでテストすることは、多くの場合、理にかなっている。
  • 開発とテストが別々の場所で実行される「follow-the-sun」戦略をサポートする。
 内部オープンソースチーム
  •  共通コンポーネントまたはサブシステムの開発をサポートする。
  • 複数の開発チームにこれらのコンポーネントの開発コストを分散できる。
  •  この作業に取り組むためには、他のチームにも、少なくともパートタイムで、開発者を提供してもらう必要がある。
  • オープンソース開発を反映した管理とガバナンスの構築が必要である。
  •  「パブリックな」オープンソースの取り組みに深い経験を持つ開発者と供に、組織に導入する。

これらの戦略は組合せ可能で、多くの場合そうされることに注意すること。

地理的な分散はツールの選択肢にどのような影響を与えるか?

地理的に分散したアジャイルチーム(少なくとも効果的なチーム)では、分散開発(Geographically Distributed Development:GDD)の現実を反映したツールも使う。インデックスカードは、同じ拠点のアジャイルチームがユーザストーリーのようなハイレベル要件を明文化するには良い方法であるが、GDDチームのためには電子媒体を使った戦略が必要になる。以下をサポートするツールを考える必要がある。

  1. 長距離コミュニケーション。 ビデオ会議、電話会議、チャットソフトウェア、それに、議論フォーラムソフトウェアにも投資したい。
  2. 情報共有。 サイト間で情報共有するツールが必要になる。これは、wikiのような単純なものや、Dropboxのような共有フォルダ環境のようなものが考えられる。また、成果物のリポジトリも考慮したい。
  3. 計画と調整。 地理的に分散したチームでは、タスクボードを管理するためJIRAやマイクロソフトTFSを採用する傾向がある。
  4. ダイアグラムを記録するツール。 単純なソリューションは、携帯電話カメラを使い、ホワイトボードを記録し、チームの情報共有戦略を通じてそれらを共有することである。多くのチームでは、SmartDraw や Visioのようなシンプルなダイアグラミングツールを使い、重要なダイアグラムを記録する。これらのツールの利点は、将来ダイアグラムを更新しやすいことである。いくつかのチームは、Blueprint や Enterprise Architectのようなソフトウェアベースのモデリングツールを採用し、作業を記録する。

地理的な分散は得策か?

場合によるが一般的に得策ではない。図6で見るように、成功率は人々が離れた場所にいると急激に落ちる。これは、地理的分散のために増えるリスクと同様に、リスクに関連し必要となってくる組織の構造、プロセス、ツール構成の複雑さが増えるためである。アドバイスとしては、まず最初に同じ拠点でアジャイル開発で上達し、次に、近い拠点に挑戦し、成功した際には、遠い拠点で開発することである。言い換えると、最初にハイハイを学び、次に歩くことを学び、最終的に走ることを学ぶということである。

どこからはじめるか?

ここで、GDDに対するアジャイルアプローチについて、下記の重要なアドバイスとともに議論を締めくくる。

  1. 経験を積む。 エンタープライズレベルでの採用で気をもまず、、まず小さいプロジェクトから始める。それから、より複雑なプロジェクトにする。また、オフショアサービスプロバイダーと関係を構築する体験学習をする。このアドバイスは、自分自身のオフショア部門と働いても、独立サービスプロバイダーと働いても良い。
  2. 長期的な要員戦略をもつ。 低コストの国で、短期間仕事をさせるのは良いかもしれないが、保守チームに必要な技術をどのように移管するのだろうか?一つの選択肢は、その仕事もアウトソーシングすることである。しかし、もしその仕事を再びインソースするなら、”自身”のシステムの専門知識を築く必要があるので危険な選択肢となる可能性がある。
  3. 知的財産に関心をもつ。 ルールは世界で異なるし、もし所有権の区切りがはっきりしないなら、気づかずに、新興の海外競合企業の創立に資金を提供することになる。これが、システムのいくつのコンポーネントを、いまだ組織内部で構築する理由である。
  4. グローバル化の前にローカルで実践する。 GDD は管理をより難しくする。もし、ローカルチームを管理するのに苦労しているなら、離れているチームを管理するのにも苦労するだろう。まずローカルで成功を経験し、全体的にアジャイル開発を成功させる。さらに言えば、もしアジャイルGDDプロジェクトが問題を抱えていても、その分散プロジェクトの難しさを理由に、ローカルでのアジャイル採用をやめてはいけない。
  5. オフシェアパートナーにリードさせる。 オフショアパートナーは、分散開発でおそらく多くの成功体験をしている。これは、実績のあるサービスプロバイダーと取り組むときに特に当てはまる。
  6. 南北の分散を選ぶ。 もし、分散開発のコストの優位性を模索するなら、タイムゾーンの違いを最小にするため、東西よりも南北を考慮する。

その他の参考文献

 

オリジナル: Geographically Distributed Agile Teams
http://www.disciplinedagiledelivery.com/agility-at-scale/geographically-distributed-agile-teams/
(翻訳 桐谷朱夏)

Pocket