[#Agile] FDDはアジャイル開発、ハイブリッドアジャイルは、、

アジャイル開発というとエクストリームプログラミングやスクラムを思い浮かべられる方が多いと思いますが、アジャイル宣言を実現するものはそれ以外にもたくさんあり、アジャイルと規律には、リーン開発やクリスタルのほか、RADの流れを汲むASDやDSDMなどにも触れられています。

アジャイルと規律ではアジャイル開発と従来型の開発の表(A-2)があり、RUPやTSPとよりもアジャイルな順位が低いアジャイル開発が唯一FDD(ユーザ機能駆動開発:Wikipedia)です。

FDDがアジャイル開発である理由

FDDの特徴はモデル駆動で、初めに製品の全体モデルを作成します。そして、ユーザ機能一覧を作り、計画を作成します。その後にイテレーションでユーザ機能を開発していきます。不正確な表現ですが、アジャイル開発の実装の前に上流が存在します。

アジャイル宣言を読まれた事のある方は、アジャイル宣言(日本語訳)に「包括的なドキュメントよりも動くソフトウェアを」と書かれているじゃないかと思われるかもしれませんが、その下に「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」とされていて、ドキュメントを否定せず、必要なドキュメントは作成します。

アジャイル開発で大切なのは変化を受け入れることです。FDDには「10％吸収ルール」があり、途中で見つかったユーザ機能を受け入れます。また、書籍「アジャイル開発手法FDD」では、コミュニケーションに１節、プロジェクトと人に1章が割り当てられているなど、いかにもアジャイル開発の内容になっています。

ハイブリッドアジャイルをアジャイル開発にする方法

書籍「ハイブリッドアジャイルの実践」によれば、結合テスト以前の一定の工程にアジャイル開発のイテレーションを導入するものの様です。リリースは1回もしくは複数で、複数のものは「ハイブリッドアジャイル（インクリメンタル）」と呼ばれています。

ハイブリッドアジャイルは、アジャイル開発ではありません。 本の中でも表(2-2)にまとめられていますが、インクリメンタルを除いてリリースが1回ですので、少なくとも「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」という原則を満たしません。

表(2-2)はアジャイル開発の原則に対して不完全なところや評価できないところも正当に書かれています。しかし、要求変更の歓迎が全てに対して「該当する」とされている点には疑問があります。

ハイブリッドアジャイルでは発注側が20％のバッファを用意しておき、イテレーションの中で変化を受け入れる開発法ですが、それは単体テストまでです。一方、アジャイル開発の原則には、以下の様に書かれています。

「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」

まとめて結合テストを実施する事で、リリースまで1ヶ月単位の期間が必要になるので、それでは、機敏(アジャイル)ではないですし、アジャイルの名称の次点となった「アダプティブ」でもないでしょう。

インクリメンタルな開発にすれば、テスト工程が分散し、後工程でも変化を受け入れることができると思います。

テストは日本の課題

FDDは10％、ハイブリッドアジャイルは20％のバッファを持ちますが、書籍「本当に使える開発プロセス」(p.40)によればSIベンダーのバッファー値1.5〜2倍とされていますので、より変化に色々対応できそうですが、繰り返していないので 変化をうまく取り入れられません。

（注：そんなにバッファを取った見積もりが通る訳ありませんし、SIベンダーの利益率もそんなにありません。倍率はユーザ見積もりとの対比で、あまり詳細でないことや、アジャイルラジオ 第63回「ミスターTOC登場！」西　東でダイワハウスの松山さんが語られていた様に顧客と牽制し合うことでムダな管理が発生するのかもしれません。）

そこで必要になると思われるのが、複数リリースを支援するテスト技術です。具体的には、自動化によるテストの軽量化と差分テストを可能にするグレーボックステスト、そしてそれを容易にする設計です。

テストの自動化：リリースごとに確認しないといけない内容は、自動化して負担を減らさないとリリース回数を増やせません。アジャイルと規律を除く上述の本で取り上げられていることでも、その重要さがわかるでしょう。

グレーボックステスト：アドホックテストなど自動化が困難な場合は、前回のリリースとの差分をテストします。その際にブラックボックスではなく、内部構造を意識すればテスト工数を減らす事ができます。リリースノートだけでなく、チケットやバージョン管理ツールで修正部分を確認すればより安全でしょう。

テスト容易化設計：良い設計であってもテストが困難ならばその価値は半減します。テストの自動化が容易で修正時に影響範囲が局所化される様な設計が求められます。

日本のソフトウェアの特徴は信頼性が高いことです。安易にブームにのって失敗する 事がない様に、プロセスは改善しないといけません。

アジャイル開発はビジネスの競争力を高める効果があります。日本で実践するには、五月雨ウォーターフォール開発など契約の問題、サーバントリーダーシップなど価値観の問題、そしてここに挙げた複数リリースが可能な高信頼性テストが必要でしょう。