アジャイル開発とオフショア開発の台頭

今やアジャイル開発は開発現場では当たり前のものとなっています。

多くの開発現場ではアジャイル開発が積極的に取り入れられていますが、それには理由があります。

アジャイル開発は従来のウォーターフォール開発では難しい急な仕様の変更に対応でき、ユーザーの嗜好が移り変わりやすい昨今、成果を上げるのに適していると考えられているためです。

また一方、オフショア開発も成長してきています。

グローバリゼーションによるコスト競争や開発技術が進化したことによって、既存の開発に置き換わるというよりは補完する役割としてオフショア開発が利用されています。

オフショア開発の台頭は下記の理由が考えられます。

• オフショア開発が一般化してそこそこ経過している。
• 国内のIT人材の人手不足。
• コミュニケーションツールを通してリモートで協力しあうことは、以前ほど難しいものでなくなってきている。

多くの場合で、日本国内の開発と比較して同じ成果をより安価で出すことができます。

ただ、アジャイルやオフショア開発が普及してきたからといって、すべての開発で取り入れればいいというわけではありません。

開発の前提に応じて、どのように導入を検討するか考えてみましょう。

アジャイル開発について

アジャイル開発は短いサイクルで『計画→設計→実装→評価』を繰り返し行うものです。

この手法の大事な部分は、フィードバック、コミュニケーション、コラボレーションです。

この3つ以外にも意識すべき点はありますが、これらがまず進める上で必須となります。

アジャイルを用いた開発手法としては、スクラムとカンバンがよく知られています。

どちらも反復的な開発を実践し、基本的な製品を素早く作り、フィードバックを得て機能を追加していく流れとなります。

スタートアップ企業とアジャイル開発

スタートアップ企業がアジャイルを好む理由は先に述べた点にあります。

アプリやサービスを迅速に市場に投入し、プロダクトオーナーやチームはフィードバックを取り入れすぐに必要とされる機能を生み出すことができます。

流行り廃りのサイクルが短い現代の消費者ニーズにおいて、最初から完成品を目指して全力で時間や資金を投下することはスタートアップ企業には難しいでしょう。

バグのない安定したフル機能のアプリをリリースするよりも、アイデアが他人に使われてしまう前にサービスをローンチするほうが重要なのです。

ウォーターフォール開発について

アジャイル開発に対して、ウォーターフォール開発は進め方が厳格になります。

スタートアップ企業では、アジャイルを採用するかもしれませんが、金融機関のシステムのような安定性が重要なシステムなどは厳格であるべきでしょう。

またほとんどの請負開発では、仕様や予算が決まっている場合は、基本的にウォーターフォール型の開発が採用されます。

オフショア開発とウォーターフォール開発

請負開発では仕様の通り開発を進めるだけなので、ウォーターフォールで進めることができコミュニケーションはそれほど複雑にならず、オフショア開発と相性がとてもいいです。

そのことからも、オフショア開発では請負によるウォーターフォールが主流です。

ウォーターフォールは設計の間違いや大きな不具合がなければ判断が必要な場面がありません。

以前はオフショア開発であれば、日本人が海外拠点に駐在をして開発に加わるということもありましたが、今ではコミュニケーションツールなどでリモートで連絡を取り合うことが一般的です。

オフショア開発とアジャイル開発

もちろん、社内のチームとオフショアを組み合わせたり、オフショアだけの開発チームでアジャイル手法をうまく利用できないわけではありません。

オフショアでのアウトソーシングは安いコストという大きなメリットがあります。

請負の契約でアジャイル開発によって無限にサイクルを回すことは予算上許されることはないでしょう。

固定もしくはフェーズごとによる支払いがされる請負契約に対し、準委任契約（ラボ型契約）はアサインをする人員に対して支払う契約で、アジャイル開発をオフショアで行う場合はこちらを通常は使います。

アジャイル開発のためにオフショアチームを雇用することは、コミュニケーションの問題がありますが、日本人同士であっても仕様の理解のためにはコミュニケーションコストはかかります。

プロダクトオーナーと接する担当者（ブリッジエンジニア）に正しく要件が伝わり、ブリッジエンジニアから開発チームへ正しく伝えることでアジャイルによる開発は可能です。

デメリットはありますが、オフショアによるリソースの方が全体的に安く、しかも良い結果が得られるという事例は多くあるのでチャレンジをする価値は大いにあるでしょう。