開発形態での適用度合い
先ほど請負開発とプロダクト開発を比較しましたが、厳密には図3に示すように請負開発にはイチから手作りする「テーラーメード開発」と、パッケージをベースにする「パッケージカスタマイズ」があります。また、プロダクト開発も新規の製品を企画／開発する「新規開発」とそれを機能改善していく「バージョンアップ」の2通りあります。
テーラーメード開発と新規開発は、何もないところから作り上げていく作業です。これに対して、パッケージカスタマイズとバージョンアップはすでにあるものに機能を付け足したり、変更を加えたりする作業です（既存システムの機能変更、機能追加もこれに相当します）。
どちらがアジャイル向きかと言えば、機能追加／変更する形態のほうでしょう。パッケージカスタマイズやバージョンアップは、基本的にはすでに土台ができているうえでの変更作業なので方式設計部分にまで入る必要はありませんし、全体システムとしての整合性はきちっとしています。アジャイル開発は、最初に重要な機能をコアとして作成し、次に重要とされる機能を追加拡張していくような開発スタイルが基本なので、このような“土台ありき”の開発にはぴったりなのです。
反面、アジャイルは個別の機能を満足度高く作り上げるにはぴったりなのですが、システム全体を大きくとらえて整合性を見極めるというような部分はちょっと苦手です。こうした観点から見て、アジャイル適用の容易さから便宜的に4段階で評価したのが図3の◎○×△です。
ただし、冒頭に述べたように苦手部分はウォーターフォール式を部分採用し、ウォーターフォールの利点とアジャイルの利点をうまく組み合わせたハイブリッド型の開発を行なうのが最近の傾向になっています（連載第4回で詳しく述べます）。
アジャイルは、請負開発よりもプロダクト開発や社内システム開発に取り入れやすいです。しかし、以前から請負開発にもアジャイルを適用している企業も少なからずあるし、ここにきて再評価される中でオフショア開発にもアジャイルを取り入れる企業が増えています。
先日、中国のソフト開発企業を訪問した際にフロアを案内してもらいましたが、英国の企業からの仕事を準委任で請け、アジャイル開発をしていました。顧客と開発が一緒でないハンディはMessengerやTV会議システムなどのコミュニケーションツールで補い、毎日のようにユーザーと会話ができているので順調にプロジェクトが進んでいるとのことでした。
この2、3年、欧米系の仕事で“アジャイルで”という指定が増えてきたそうで、うかうかしていられないと感じました。日本では多くの企業が「中国にオフショア開発を出す際は、微に入り細を穿ち詳細まで仕様を記載しないとダメ」などと言っていましたが、隔世の感があります。
本連載の共同執筆者であるディーバ社（第2回以降から執筆）も海外オフショア開発にアジャイルを実践しています。また、国内企業向けの請負開発にアジャイルを適用している話もあちこちで聞こえてきました。アジャイルは一時のブームからは抜け出しましたが、水面下でじわじわと浸透しています。請負開発においてもいろいろと工夫をしながら適用していく時代がすぐそこまで来ている感じがします。
契約形態での適用度合い
請負開発でもアジャイルが適用しやすい形態があります。それは工数契約や派遣契約など、顧客と開発側が一緒に開発を行なうような場合です。基本的に常駐スタイルなので開発現場は一緒ですし、1人月いくらというような契約なのでスコープにこだわり過ぎることもありません。ユーザー企業のところに元請けが下請けや孫請けを引き連れて常駐する形ですが、元請けにアジャイルの覚悟があればそこにユーザーと下請け、孫請けが集結したりというようなこともあります。
最近は、オフショア開発でアジャイルを適用するケースも増えてきました。欧米の顧客からの仕事などで中国やインドなどのオフショア会社が一歩先にアジャイル開発を実践していたというようなケースもあります。アジャイル開発の場合、オンライン顧客が開発チームの一員として一緒にいることが重要なので、先方に常駐するのをためらってはいけません。
ただし、最近はWeb-TV会議や進捗確認ツール、バグトラッキングシステムなど便利なコミュニケーションツールが充実しているのでかなりカバーできます。これらのツールを活用できる時代になったのがオフショア開発でアジャイルが普及しつつある背景でしょう。プロジェクトの最初に仕様確認方法やQ＆A、進捗、品質などの情報共有をどのような手段で行なうかを先方と協議し、お互いがやりやすい方法をルール化してスタートすることが大切です（図4）。
対象規模による適用度合い
一般にアジャイル開発のチームは、5～10名の間が適していると称されています。では、中規模の基幹業務システム開発のように工期が1年でピーク時に30人にもなる規模だと無理かと言うと、そんなことはありません。7名くらいの開発チームを4つくらいに組織し、これらのチーム間の調整や共通化などを図る2、3名くらいの共通支援チームを1つ作るような組織体制で取り組むことになります。
ただし、アジャイルの適用度合いがシステム規模に無関係かというと、これまたそうではありません（アジャイル信者は反論するでしょうが……）。システム規模が大きくなると、全体の整合性や統一感、サブシステム間の連携などで困難が増えてきて、初期段階でかなりしっかりしたデザインをする必要があります。このように計画をきちんと立てないと、後で収拾がつきにくくなる傾向のものはアジャイル方式ではやりにくいです。
極端なケースで考えてみましょう。1人か2人で1ヶ月で完成できるような小規模なシステムを作るとします。これは完璧な設計をしなくても軌道修正しながら開発作業を進めるアジャイル方式で完成させることができますね。
反対に、100人が2年がかりで作り上げるような大掛かりなシステムはどうでしょうか。100人のうち7人の開発チームを12、4人の共通支援チームを4つ作ったとしましょう。これら全員に対して、標準化や共通ルール、システムの全体構造、各チーム間のインターフェイスなどをきちんと伝え、そのでき栄えをその都度確認し、2年間の長期にわたってチーム間で情報交換して整合性あるシステムを作るのは至難の業です。
こうしたケースでは、やはりウォーターフォール式できちんとしたルールを設定し、後で整合性が破たんしないような設計ドキュメントを作成し、統制を取ってプロジェクトを進めるべきだと思います。
