本特集では第1回から第4回までを「基礎編」と位置付け、アジャイル開発の経験が少ない日本企業が組織や文化を大きく変革せずに、SoR（System of Record）領域の業務システムのアジャイル開発を成功させるために、理解しておきたい基礎的なポイントを解説した。続く第5回から第9回までは「実践編」との位置付けで、実際のアジャイル開発プロジェクトを運営する現場で必要となる項目に焦点を当てて、より詳細に掘り下げて解説してきた。
今回（第10回）からは締めとなる「応用編」として、現場での最先端のアジャイル活用について事例を交えながら3回で説明していく。応用編第1回の今回は、1つのプロジェクトの中でウオーターフォール型開発とアジャイル開発の2つを効果的に組み合わせる「ハイブリッド型」の開発プロジェクトについて紹介する。ポイントはスコープ（要件）の線引きと、ウオーターフォール型／アジャイルのそれぞれで進めてきた作業をいかにスムーズに合流させるかである。
ウオーターフォール型開発とアジャイル開発を組み合わせる
ハイブリッド型開発が適しているプロジェクトは、比較的要件の固まりやすい業務領域と、要件のまとまりにくい業務領域が混在するプロジェクトである。例えば会計領域の業務は企業の財務会計のルールが大きく変わらないため、「要件の固まりやすい業務領域」といえ、ウオーターフォール型開発で刷新するほうが効率的である。
一方、営業領域の業務は「要件のまとまりにくい業務領域」といえる。時代や環境の変化に対応すべく常に営業体系や運用ルールなどを変え続けなければいけないからだ。
現場ではシステム外で対応している仕事も少なくない。例えば制約条件が多いシフト作成や運行管理といった、専門的な知識や経験を必要とする特殊な業務領域で使う業務システムを刷新する際は、仕事の進め方やノウハウが一部の現場担当者の頭の中にしかないケースが多い。要件を正確にまとめようとしても膨大な時間がかかりがちである。
既存システムの刷新でも、現場の業務内容とシステムの機能がかけ離れてしまっているようなケースは、ユーザーの要望が多くなりがちで「要件のまとまりにくい業務領域」といえる。
こうした場合はアジャイル開発の選択が適している。つくり込みと検証を繰り返すことで、要件や仕様の明文化に時間がかかる業務ルールやノウハウ、ユーザーの要望について、ウオーターフォール型開発よりも短期間に実装しやすいからだ。特殊な業務領域の開発の遅れに、システム刷新全体のスケジュールが引っ張られることもなくなる。
ハイブリッド型開発では最初にやることは、ウオーターフォール型開発とアジャイル開発でそれぞれ進める対象を決めることだ。その際は、インプット（入力画面）系やバックエンド系といった機能で切り分けるのではなく、営業系や会計系といった業務領域で切り分けたほうがよい。
例えばインプット系をアジャイル開発、バックエンド系をウオーターフォール型開発と切り分けるとしよう。すると、インプット系の要件とバックエンド系の要件は強く結び付いているため、インプット系のアジャイル開発でその特性を生かして仕様変更を受け入れていると、バックエンド系のウオーターフォール型開発で仕様変更が多発してスケジュールが遅れる結果となってしまいかねない。
一方、業務領域で切り分けると、インプット系からバックエンド系まで一連の業務処理の流れに沿って整合性を取って開発を進められる。業務によって要件の固まりやすさも変わり、ウオーターフォール型かアジャイルかを選択しやすい。最近では会計など、あらゆる企業に共通する業務にはSaaS（ソフトウエア・アズ・ア・サービス）やパッケージソフトを使い、各社固有の業務機能をアジャイルで追加開発するケースも多い。
基幹システムの構築や刷新にハイブリッド型開発で取り組む場合、ウオーターフォール型開発側（以下WF側）のシステムとアジャイル開発側（以下AG側）のシステムの合流地点は外部結合テストとなる。つまり互いのシステムを外部システムとして位置付けるのである。
重要なのは、プロジェクト初期にグランドデザイン（全体像）を描く段階から、WF側システムとAG側システムを可能な限り疎結合にしておくことだ。密結合にすると、AG側でデータモデルに影響する仕様変更をした場合、WF側で大幅な手戻りが発生し、スケジュールの遅延やコストの増加につながる恐れがある。疎結合にしておくことで、AG側の仕様変更がWF側に及ぼす影響を最小限に抑えられる。
