序文
本記事は、特にオフショア開発の開始または拡大を検討している開発者や開発チームに対して、国内開発との対比におけるオフショア開発の一般的な特性を踏まえて、より小さなコストと時間で、より効率的かつ円滑にオフショアを活用するためのノウハウを 一般論として 提供することを意図するものです。簡単に言えば、オフショア開発における適材適所を議論することが目的です。
もちろん、十分なコストと時間をかけて長期的・段階的に国内側／海外オフショア拠点側の双方を育成することができたり、または属人的・偶発的にあらかじめそのような資質を有した人材を擁すことができる場合には、本記事の議論（＝適材）を超える範囲の開発業務を、オフショア開発によって開発することも可能となるでしょう。国内側／海外オフショア拠点側の双方の人員・組織の資質や能力、努力、創意工夫によって、オフショア開発を阻害する要因や制約を乗り越えることができるようになるためです。
しかしながら、開発者や開発チームのすべてが、オフショア開発の開始または拡大にあたって育成に十分なコストと時間をかけられるとは限りません。従って、本記事は、育成に十分なコストと時間をかけることが難しい場合においても、属人的・偶発的な要因に頼ることなく、オフショア開発を効果的に進めるための手法・領域を一般論として議論することを目的としています。
はじめに
コストの削減や開発力の確保のために、業務の一部または全部を海外、つまりオフショアに委託する事例は、日本のソフトウェア開発業界においていまなお広く一般的なものであると思います。しかしながら、文化や言語の違い、業務知識の多寡、品質や生産性の問題、また物理的に拠点が隔たることそのものの弊害などから、どのような開発でも無条件に海外オフショア拠点に任せてよいというわけでは決してありません。わたしがこれまでに経験したプロジェクトにおいても、開発作業のうちどのような内容や工程を海外オフショア拠点に割り当てるかについては、継続的な議論の対象となっていました。
わたしが、オフショア開発を担当するにあたり、教科書としてきた 標準テキスト オフショアプロジェクトマネジメント 【SE編】 は、オフショア開発との相性が悪い領域として、以下の4つを挙げています。
1. 業界知識や独自仕様のカスタマイズの度合いが高い領域
2. 日本語への依存度が高い領域
3. 開発環境依存の度合いが高い領域
4. 日々の相互確認、相互連携の度合いが高い領域
上記の領域がオフショア開発に向かない理由は、感覚的にも理解しやすいものだと思います。要するに、海外オフショア拠点に欠けている要素（固有の知識、日本語能力、設備・環境、対面での会話・ペアワークなど）が強く要求される領域は、原則として「オフショア開発には不向きである」と言ってよいでしょう。
では、逆に、どのような領域であれば「オフショア開発に向いている」と言えるのでしょうか。理想的には、まず「オフショア開発に向いている」と考えられる領域があり、それを海外オフショア拠点に委託することでコストの削減や開発力の確保といった目的の達成を目指すべきですが、現実には、事業をとりまく環境の変化や技術の変遷などにより、海外オフショア拠点を利用することは大前提とされたうえで「で、何をやってもらうか？」ということを考えなければならないケースも多いのではないかと思います。
品質や生産性、また日本国内の管理や受入のコストを鑑みて、どのような領域を海外オフショア拠点に委託すべきか──以下、わたしのこれまでの経験と見聞から、特に「オフショア開発に向いている」と考えられる領域を挙げていきます。
「オフショア開発に向いている」と考えられる領域
1. 軽微な不具合の修正
オフショア開発と相性が悪いとされる領域とは、外的要因（業界知識、言語、環境、利害関係者）の制約を多く受ける領域であると言い換えてもよいでしょう。その複雑な事情ゆえに外部からの制約を受け、海外オフショア拠点での開発が難しくなるのであれば、逆に言えば、単純で外的要因の制約を受けにくい領域は、海外オフショア拠点での開発に適していると言えることになります。
「単純で外的要因の制約を受けない領域」の例は、開発体制やプロダクトの状況によってもさまざまでしょうが、ひとつには、既知の不具合のなかでも軽微なもの、特に影響範囲が小さく明確となっているものの修正を挙げることができると思います。たとえば、ユーザインタフェースに表示上の不具合があり、不具合の内容とおおよその修正方針が明らかになっている場合、不具合を修正して定められた品質担保の手続きをおこなうことは、特定の知見が必要になったり仕様が途中で見直されたりすることのない、一本道・一方通行の「単純な」開発となることが想定され、制約を受けることなく海外オフショア拠点で遂行することができるはずです。
2. テスト
しかし、当然ながら、「軽微な不具合の修正」の委託だけでは、海外オフショア拠点を有効に活用しているとは言えない（と少なくとも経営者は思う）でしょう。
上述の「軽微な不具合の修正」は、開発の対象の性質（複雑⇔単純、重大⇔軽微）によって国内開発拠点と海外オフショア拠点の分担を最適化する試みの一例ですが、他方では、開発の工程によって国内と海外で分担することも可能です。もっとも、要求分析や要件定義などのいわゆる上流工程を国内、それ以降の下流工程を海外で──といった工程による分担はごく一般的なものですが、仮に開発の内容そのものが「オフショア開発には不向き」とされる類のものであり下流工程の全体を海外オフショア拠点に委託することが困難であると考えられる場合にも、下流工程の中でもテストだけを委託することは、海外オフショア拠点の内情にも左右されますが、十分に実現可能です。
ここで、下流工程の中で特にテストを「オフショア開発に向いている」とする理由はふたつあります。
1. 海外オフショア拠点には、品質管理（Quality Control）の専任の責任者やチーム、そしてその実働部隊としての「テスター」が置かれることが一般的です。つまり、ソフトウェアテストの手法や技法については、場合によっては日本国内の開発拠点よりも、専門的かつ体系的な知識を期待することができ、仕様が適切に伝達されていることが前提にはなりますが、たとえば振る舞いに対するブラックボックステストは何の問題もなく遂行できるものと考えられます。
2. 一方で、仮にソフトウェアテストに関する高度な技術や専門性を期待できない状況であったとしても、日本国内で適切にテスト設計をおこなうことができれば、テストの実施は労働集約型の作業、つまり人海戦術によって遂行できるものとすることが可能です。なお、労働集約型の作業を委託することは、ともすれば海外オフショア拠点を「下請け」と位置づけることにもなり、日本国内の開発拠点と海外オフショア拠点の長期的な関係性（パートナーシップ）という観点では最適とは言い難いですが、ここでの議論はあくまでも「オフショア開発に向いている」領域かどうかという観点に閉じたものとします。
3. 自動テストの整備
主に、プログラムコードに対する単体テスト（xUnit）や、UIテスト（Selenium、Appiumなど）、負荷検証テスト（JMeterなど）など、ソフトウェアの品質を継続的に担保するためのテストコードの作成がこれに当たります。この活動は、上述の1と2の利点を併せ持つ（比較的単純な開発であるがソフトウェアテストの専門性を活かせる）だけでなく、海外オフショア拠点の成果物そのものがプロダクトに含まれない点にメリットがあります。つまり、万が一テストコードに欠陥があったとしても、もちろんそれはテストの不備として品質に大いに影響しますが、欠陥それ自体がプロダクトの不具合とはならないため、成果物に対する品質要求を下げたり国内拠点による受入のコストを抑えたりすることを選択することも可能となるでしょう。
まとめ
このように、品質や納期に対する要求、事業環境の変化、技術革新、（特に海外オフショア拠点側の）労働環境や社会体制の変化など、内外のさまざまな要因により、一時的または部分的に理想（あるべき姿）に反して、本稿で挙げたものをはじめとする 「オフショア開発に向いている領域」＝「労働集約型の単純な作業」 を全うすることが求められる場合があることを、日本国内の開発拠点と海外オフショア拠点の双方があらかじめ認識しておくことが重要だと思います。
その一方で、理想（あるべき姿）としては、日本国内の開発拠点と海外オフショア拠点の関係は、上下ではなく相互に対等であり、長期にわたって同じゴール（開発の成功）を共有するパートナーであって然るべきです。従って、海外オフショア拠点の責務は本来、単なる「労働集約型の単純な作業」であってはならないはずです。「労働集約型の単純な作業」を超えてより高度な開発をオフショア開発によって成功させるために、「序文」で述べているように、十分なコストと時間をかけて長期的・段階的に双方を育成していくことが必要となるでしょう。