グラス片手にアジャイル開発　第4回
－ ハイブリッドアジャイルの実践法

エンタープライズ分野へのアジャイルの適用

　ここ2、3年のアジャイル開発の再評価は第2のブームとも呼ばれています。実際のところは10年前にブームであったものがじわじわと現場に浸透し、それが表面化して見えてきたと言うところでしょう。こうした中、エンタープライズ（企業）系のアプリケーション開発でもアジャイルを適用するケースが多くなってきました。Web上のちょっとしたツールやアプリの開発でアジャイルの成果を実感し、今度は本格的な基幹業務システムの構築でも適用してみようという機運が高まってきたのです。

業務システムへのアジャイル適用の3つの課題

　「業務システムにもアジャイルを適用」という目標を掲げた場合、3つの課題が浮かび上がります。1つは契約の問題です。連載第1回目に述べたようにアジャイルは「変更があって当たり前」というスタンスなので、いつまでもお客様が変更を要求してきたらコストが膨れ上がるのではという恐怖があります。

　2つ目は工程による適用性の問題です。アジャイルは詳細設計やプログラミング、単体テストあたりの工程で有効ですが、システム全体の構想・企画を決定する要件定義や基本設計などの工程はあまりアジャイル向きとは言えません。

　3つ目はドキュメントの問題です。エンタープライズ系の請負開発では、きちんとしたドキュメントの提出を求められます。アジャイル開発の基本は「不要な」ドキュメントを作らないことですが、業務システムでは「設計書」や「マニュアル」などは「必要な」ドキュメントとしてきちんとしたものの提出を求められます。これらの課題に対してどのように対処するか具体例をもとに考えてみましょう。

V字モデルの上側と下側でハイブリッドする

　業務システムの開発と言えば、要件定義に始まり、基本設計、詳細設計、プログラミング、単体テスト、結合テスト、総合テストと一連の工程が続くウォーターフォール手法の牙城です。この手法は図1のように上流工程と下流工程を左右対称に対比させ、上流で埋め込んだ品質を下流で検証するというV字モデルでもよく表されます。

図1：V字モデルにおけるウォーターフォールとアジャイルの混在

　一方、アジャイル開発の方は、図2のように一定期間（イテレーションまたはスプリント）内である範囲の設計・開発・テストを行います。そしてレビューで発生した変更点と次の範囲を後続のイテレーションで作成するという形で繰返しながら開発が進みます。

　このような説明がよく使われているのですが、ここで怪しげなのは、ウォーターフォールでは基本設計、詳細設計と分けていたのにアジャイルでは単に設計と表していることです。また、単体テスト、結合テスト、総合テストと3つに分けているテスト工程も単にテストという表現で済ましています。一体、アジャイルで言う設計やテストはウォーターフォールにおける設計、テストの範囲をすべてカバーしているのでしょうか。

　業務システムのように要件が複雑で規模の大きなシステムでは、実際、アジャイル開発でカバーしているところは詳細設計、プログラミング、単体テストの限られた範囲が一般的です。要件定義や基本設計においてもモックを使ってアジャイル的な要素を入れるケースが増えて来ましたが、本質はウォーターフォールです。つまり図1のようにV字の上側はウォーターフォール、下側はアジャイルというハイブリッド（混在）が業務システムにおけるアジャイル開発の実態と言えます。

図2：アジャイル開発のイテレーション（スプリント）

現代の業務システム開発はパッケージが主流

　こんなふうに解説してきましたが、実はこうした説明は少し時代に合わなくなってきています。今日の業務システムは、パッケージをベースにするケースや既存システムの改善や機能追加などがほとんどで、一から新規に開発することは少なくなっています。それなのに、新規開発モデルをベースにやれウォーターフォールだ、アジャイルだと比較しているのではピントがずれています。そのため、本稿ではパッケージ開発における開発手法を少し掘り下げてみたいと思います。

　まず1つ言えるのは、パッケージベースの開発や既存システムの拡張では、もう少し上流工程までアジャイルを適用できるということです。新規開発の際はシステム構想や方式設計などシステム全体にかかわる企画・設計作業（この部分はウォーターフォール）が必要となりましたが、パッケージや機能拡張では既に基盤があるので不要です。また、既にユーザーに見せるべき画面や帳票が存在しているので、「見せながら進める」というアジャイル方式がやりやすい状況にあります。