一般にオフショア開発は、コスト削減、人材不足の解消を目的に実施されることが多いのですが、一方で、文化・言語の違いによるコミュニケーション不足、発注仕様の理解不足、品質に対する認識不足等が原因で、当初の目的を達成できないことがあります[1]。弊社でも、約10年前からオフショア開発に取り組んでおり、同じような問題に直面しました。本稿では、そのようなオフショア開発の問題点をアジャイル開発で効果的に解決できた事例（プロジェクト）を紹介します。
1.プロジェクト概要
今回紹介するプロジェクトの概要を表1に示します。開発当初は、基本設計以降をオフショア側に委託し、弊社は要求の説明と受入検査のみを実施しました。なお、委託する際は、国内で委託する場合と同様の開発手順書、要求仕様書を作成して委託しました。
2.顕在化した問題点
当初、「1.プロジェクト概要」で紹介した方法で開発を進めたのですが、品質が悪く、受入検査と改修を繰り返す事態になり、結果的にコストメリットが得られない状況になりました。品質が悪い原因として、以下の4つが問題点あると考えられます。
1). あいまいな要求
2). 品質に対する考え方の違い
3). 情報共有不足
4). オフショア側のモチベーションの低下
それぞれの問題点について、もう少し詳しく見てみます。
1). あいまいな要求
これは発注者側（日本）に起因するものです。
要求にあいまいな部分がある場合、日本のベンダーは設計時に発注者に質問するなどして補正します。
一方、オフショア（中国）の場合は、オフショア側で独自に判断する傾向にあるため（これは、後述する「情報共有不足」にも関係します）、発注者側とオフショア側に理解のずれが生じ、結果として発注者の「真の」要求が反映されていない成果物が納品されることになります。だからといって、理解不足を補うため詳細な要求仕様書を作成すると、発注者側の作業が増えコストの増加につながります。
2). 品質に対する考え方の違い
発注者側（日本）とオフショア側（中国）では、品質に対する考え方に違いがあります。
日本では、品質に対する要求は非常に厳しく、納品前に可能な限り不具合を検出し、検出した不具合は全て改修してから納品する、と考えています。一方、中国では、一通り動くものを納品し、不具合は納品後ユーザから指摘があれば改修すれば良いと考えています。そのため、単体テストレベル（しかも正常ケースのみ）のテストしか実施せず、非機能要求も軽視される傾向にあるため、結果的に発注者側が期待する品質より低いものが納品されます。
3). 情報共有不足
中国には「質問は恥」という考え方があり、発注者側の説明に不明な部分があっても、発注者側に質問せずオフショア側だけで解決しようとします。そのため、発注者とオフショア間で情報共有が不足することになります。また、同じ理由でチーム内（要求管理者－開発者－テスター間）での情報共有も不足しており、品質の低下の原因となっています。
4). オフショア側のモチベーションの低下
開発手順書で、作業フロー、納品ルールなどを細かく設定すると、開発の自由度が低下し、機械的な作業が増えモチベーションの低下につながります。中国は日本と比べて離職率が高く、モチベーションの低下が、優秀な人材、仕様を理解した人材の離職につながり、結果的に品質の低下につながります。
3.アジャイル開発の適用
2001年に発表されたアジャイル宣言では、共有する価値が以下のように定められています[2]。
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
表2に示すように、これらの価値観は上記の問題点の解決に役立つと考えたため、弊社アジャイル開発センターの協力のもと、アジャイル開発の導入を検討しました。
具体的に適用したアジャイル開発のプラクティスは以下の通りです。
1).プロジェクト管理フレームワーク
プロジェクト管理には、アジャイル開発のScrumフレームワークを適用しました。Scrumでは、開発体制の役割分担という縦割りの壁を取り払い、チーム、プロダクトオーナー、スクラムマスターが一丸となって協調してシステム開発にあたります。実際の開発体制は、移行を容易にするため、プロジェクト要員の追加・変更は行わず、役割のみをシフトしました（表3）。
また、コミュニケーションの方法を、Scrumの手法にのっとり、指示型から協調型に変更しました。（図1）
2).技術プラクティス
アジャイル開発の技術プラクティスである、テスト駆動開発、継続的なインテグレーション(CI)を採用しました。テスト駆動開発では、チームメンバー（要求管理者・開発者・テスター）がペアとなり要求を確認しながらプログラム開発と並行してテストケースを作成します。また、CIとして、毎日定時刻の自動ビルド、自動テストを採用しました。
3).ツール
オフショア開発にアジャイル開発を適用する場合、遠隔地同士の頻繁なコミュニケーションが必須となります。本プロジェクトでは、いつでもコミュニケーションが可能なように複数のコミュニケーションツール（Team Foundation Server (TFS) 、Web会議(SOBA)）を用意し、状況に応じて使い分けました。
以下、各ツールを簡単に紹介します。
① Team Foundation Server(TFS)
プロジェクトの管理ツールとしてマイクロソフト社製のTeam Foundation Server(TFS)を採用しました。TFSは、本プロジェクトの開発ツールである、VisualStudioに付属するWebベースのプロジェクト管理ツールです。また、TFSには、Scrum用のテンプレート(Visual Studio Scrum)が用意されており、これを使用してプロジェクトに関する情報を一元管理しました（図2）。
② Web会議(SOBA*)
いつでもコミュニケーションが可能なように、自席から利用できるコミュニケーションツールであるSOBAを採用しました。SOBAでは、音声、映像によるコミュニケーションの他、画面共有も可能です（図3）。
4.アジャイル開発適用の効果
アジャイル開発適用の効果をまとめたものを以下に示します（表4）。
以下、各々の問題点に対し、どのような効果があったかを紹介します。
1).あいまいな要求
「あいまいな要求」に対して特に効果があったのは、技術プラクティスの適用です。今回、技術プラクティスとして、CIとテスト駆動開発の2つのプラクティスを適用しましたが、いずれも効果がありました。CIの適用により、プロダクトオーナーはいつでも動作するもので要求が確認できたため、早期に理解のずれを補正することができました。
テスト駆動開発では、要求管理者を含んだチームメンバーがペアとなってテストケースを作成するため、チームメンバー内で要求の理解が深まりました。更に、テストケース作成の際に要求のあいまいな部分に気づくことができ、早い段階で確認することができました。
2).品質に対する考え方の違い
「品質に対する考え方の違い」に対しても、技術プラクティスの適用が効果的でした。CIを実現するためには、常に動作するものを作る必要があり、結果的に不具合の早期検出、早期改修が可能になりました（図4）。
不具合の早期検出、早期改修が可能になったことにより、修正コストも少なく済むようになり、更に、開発とテストを並行して実施することでメンバーの負荷を平準化することができました。
3).情報共有不足
「情報共有不足」の解消には、Scrumの適用が効果的でした。縦割りの壁、指示の壁を取り払ったことでコミュニケーションが円滑になり、プロダクトオーナーがチームメンバーに対し、ターゲットとなる機能が必要となった背景や使い方を説明する機会が増え、双方の認識のずれが少なくなりました。これは、「あいまいな要求」の解決にもつながります。
また、チームメンバー間のコミュニケーションも円滑になり、各人がそれぞれの立場（要求管理、開発、テスト）で持っていた考え方、課題を共有することができました。
ツールについても、SOBAの提供する音声・映像・画面共有機能を利用することにより、距離を意識することなく円滑なコミュニケーションが実現でき、効果がありました。
また、プロダクトオーナーの立場としては、TFSによりプロジェクトの情報が一元管理され可視化されていることで、いつでもプロジェクトの状態を確認することができ、安心感を得ることができました（図5）。
4).モチベーションの低下
「モチベーションの低下」にも、Scrumの適用が効果的でした。オフショア側では、指示されたものを機械的に作るのではなく、チームでより良いものを作るにはどうすれば良いかを検討し、プロダクトオーナーに提案しながら開発することになったため、チームメンバーのモチベーションが向上しました。結果として、自律性が高いチームとなり、離職率が一番低いチームになりました。
最後に、オフショア側の声を紹介して本章を締めたいと思います（表5）。
オフショア側でも、同じ意識を持っていることが理解いただけるかと思います。
5.アジャイル開発適用時の注意点
前章では、オフショア開発の問題点をアジャイル開発を適用することにより効果的に解決できることを紹介しましたが、アジャイル開発を適用するには、いくつか注意すべき点があるので、本章ではそれを紹介したいと思います。
1).コミュニケーションツールの利用は必須
オフショア開発の場合、遠隔地同士の頻繁なコミュニケーションが必要となるので、それに適した（いつでも使える、映像、音声、画面共有ができる）コミュニケーションツールが必須です。適当なコミュニケーションツールが用意できれば、遠隔地同士でも円滑にコミュニケーションでき、物理的な距離を意識する必要がなくなります。
2).プロダクトオーナーにはプロジェクトマネージメント（PM）のスキルが必要
プロダクトオーナーは、ユーザ調整、リソース配分、プロジェクト全体の整合性への配慮等を行う必要があり、PMのスキルが必要になります。一般的には、プロダクトオーナーは発注者であり、発注者はユーザ企業になる場合が多くPMの経験が無いケースが考えられます。この場合、受注側の経験者が補佐する等の工夫が必要になります。
3).エンドユーザの協力が不可欠
アジャイル開発では、エンドユーザが実際に動作するもので要求の実装を確認する機会がウォーターフォールモデルの開発に比べ、短期間で頻繁に訪れます。そのため、エンドユーザにも今まで以上に協力してもらって、迅速に確認結果をフィードバックしてもらう必要があります。エンドユーザの確認が滞ると、そこがボトルネックとなりアジャイル開発のメリットである「俊敏さ」が損なわれる可能性があります。
4).大きな粒度の要求には注意が必要
Scrumには、要求の管理ルールとして「要求を小さく（単機能に分解）して管理する」というのがあります。しかし、要求によっては、ユーザの仕様が固まっていない、あるいは、ロジックが複雑等の理由で、開発当初から要求を小さくできない場合があります（そのような理由があるが故にアジャイル開発を適用しているとも言えます）。このような場合、最初にストーリレベルの要求を作成して、CIを通じて動作するものを見ながらQ&Aを重ね、要求を詳細化していくという流れになります。
しかし、一部の要求ではQ&Aが頻発し（多いもので100程度）以下のような問題が発生しました。
- 最初のQ&Aと最後のQ&Aで時間がたっており、整合性が取れていない。
- 検収時に要求を確認するのに、Q&Aを追う必要があった。
Q&Aが頻発するような場合は、途中でQ&Aをまとめる時間を設けるなどの工夫が必要になります。
5).オブジェクト指向での設計は重要
アーキテクチャとしてオブジェクト指向を採用していることが重要です。オブジェクト指向（モジュール化、疎結合）による設計がなされていない場合、継続的なインテグレーションや臨機応変なリソースの割り振りができなくなり、プロジェクトが上手く回らなくなります。
終わりに
今回の事例紹介で、オフショア開発の問題点の解決にアジャイル開発が効果的であることが理解いただけたのではないでしょうか？本事例が参考になれば幸いです。
参考
- [1] IPA 独立行政法人情報処理推進機構(2012)「オフショア動向調査郵送アンケート調査結果」 ＩＴ人材白書2012 データ編 pp.21、pp.37
- [2] Kent Beck、Mike Beedle ら(2001)「アジャイルソフトウェア開発宣言」https://agilemanifesto.org/iso/ja/ (2012/09/12アクセス)
- [3] 張嵐, 茨木良昭 (2012)「オフショア開発における アジャイル開発の取り組みと評価」, SPES 2012 講演資料
- [4] 張嵐, 中川三千雄 (2012)「発注者としてのアジャイル開発体験報告」, AgileConferenceTokyo 2012 講演資料, pp.14-32
- [5] 藤井拓, (2012)「オージス総研アジャイル白書」https://www.ogis-ri.co.jp/pickup/agile/agile_wp.html(2012/08/13アクセス)
- [6] 茨木良昭, 藤井拓, 張嵐, (2011)「オフショア開発におけるアジャイル開発のプラクティス」, SPES 2011 講演資料
- [7] 茨木良昭, (2010), 「オフショアにおける受入検査の考慮点」, ソフトウェアテストシンポジウム 2010 関西 講演資料