スパイラルモデルとウォーターフォールモデル、そしてアジャイルモデル

以前Slideshareにあげたことをブログでも紹介したが、アジャイル開発について僕のチーム内の勉強会で紹介をした。

この勉強会の中で「アジャイルモデルとスパイラルモデルの違いって何？」という質問をもらい、ちょうど僕も頭の中で整理出来ていたことなので以下のように図を書きながら説明したので残しておきたい。

スパイラルモデル

f:id:hnishim:20140824004515p:plain

まずは図の説明から。「品質」と「スコープ（機能充足性）」の2軸をとっている。これに対し矢印が時間だ。

スパイラルモデルのキーワードは「プロトタイピング」だ。ソフトウェアのプロトタイプ、つまり品質が高くない状態（網羅的なテストを行わず、バグも多く存在している「とりあえず動いている」状態）のものを顧客・ユーザに見せ、ソフトウェアがどのように動くかをプロジェクトの早い段階からイメージを共有する。

プロトタイピングの最初期であればソフトウェア自体を作る前段階として、画面イメージを図形描画ソフトやパワーポイントなどで作成して紙芝居形式で見せる場合もあるだろう。（僕の前のプロジェクトではこれを"コラージュ"と呼んだ。俗称"アイコラ"。）これは建築業などで模型を作る過程に似ている。

ウォーターフォールモデル

スパイラルモデルの利点や欠点を考えるにあたり先にウォーターフォールモデルの図を示しておこう。

f:id:hnishim:20140824010214p:plain

話の流れで言えばウォーターフォールモデルの図を先に示すべきなのだが、見てもらえれば逆にした理由が分かるだろう。ウォーターフォールモデルの図だけでは意味が分からないのだ。

ウォーターフォールモデルは、スパイラルモデルとは違い顧客・ユーザの目に触れる最初の段階で高い品質まで保証する。同時に要件定義したフルスコープの機能についても一度に用意するため、図の全体を覆ったものを一気に開発する。

スパイラルモデルの利点と欠点

この2つの図を見比べるとスパイラルモデルの利点と欠点が理解出来るだろう。

利点は、プロトタイピングの時点で顧客は挙動のイメージが大きく異なれば開発チームにフィードバックすることが出来るため、大きな手戻りが発生しにくくなること。そしてそれにより最終的な要求適合度はある程度高いものになる。

一方欠点は上述の利点の裏返しにある。早期に顧客・ユーザとイメージを共有するため、顧客・ユーザに「思ったものと違う」と言わせてしまう"余地"を与えてしまうのだ。システム開発受託会社(SIer)やIT部門としては遅くとも要件定義完了時点ですでにソフトウェア開発予算は確定してしまっているはずだ。ウォーターフォールモデルであればその完成形を見せるのはユーザ受入テスト（UAT）の段階、つまり本番リリース直前の段階であり、この段階で「思ったものと違う」と言われても大方の予算は使い果たしており後戻りは出来ない。後戻りが出来ないことと、「要件定義通りに作った」ことを盾に、ウォーターフォールモデルでのSIer、IT部門は顧客・ユーザにとって価値の無いソフトウェアをそのままリリースしてきたのである。それに対してスパイラルモデルでは上述の通り早期にフィードバックする余地が顧客・ユーザにあるため、その段階であれば軌道修正出来てしまう。これが経営層まで論理的・合理的に理解されれば軌道修正に見合った追加予算の獲得なども可能であろうが、現実は往々にしてそうはいかない。ユーザの要望に合ったものを予算内で作れと言われ終わることになるだろう。

こういった政治的駆け引きの難しさが大きな利点を有しながらもスパイラルモデルが流行らない理由だと思っている。

アジャイルモデル

f:id:hnishim:20140824002833p:plain

一方、アジャイルモデルの場合はこの動きが縦横逆になる。

つまり第一に、アジャイルモデルの場合は一定の品質というのは常に保証していると考えている。ストーリーカードという形で顧客の要件をまとめ、顧客自身が要件の出し元としてチームに動員される。顧客とプロジェクトマネージャ、そして開発者が密連携してプロジェクトを推進することによってひとつひとつの要件に対しての品質は高いものがアウトプットされる。

そしてそれを可能にしているのはスコープを絞っているからである。いくらアジャイル的なフレームワークを使用したとしても、フルスコープの機能を同時に相手にしてしまっては顧客・プロジェクトマネージャ・開発者が蜜連携して事にあたる余裕はなくなってしまう。したがってアジャイルモデルでは「イテレーション」（XPの場合はスプリント）に区切って必須度の高い機能から定義・開発していく。

そのため最初のイテレーション終了後にリリースされるソフトウェアはバグなどはあまり存在せず仕様に耐えうる品質ではあるが、便利機能などは省かれた必要最低限の機能のみのものとなる。これに対して後続のイテレーションで前のイテレーションで省かれた機能のうち優先度の高いものから追加していく、という形でソフトウェアを成長させていくというのがアジャイルモデルだ。

アジャイルモデルの利点は2つ。1点目は最低限の機能ではあるが使用可能なソフトウェアを早期にリリース出来る点。2点目は優先度の低い開発を後続のイテレーションに後回しに出来るため、時間が経過し要件の変更・入れ替えが発生しても手戻りが発生しにくいこと。

一方欠点としては一度完成されたソフトウェアに対して後続イテレーションで手を入れる必要があるということだ。これはつまりリグレッション、またはデグレードと呼ばれる「新しい機能追加改修を行ったことによって、これまで正常に動いていた機能に不具合が発生する」ということがイテレーションの度に懸念される。

これを回避するためにはソフトウェア全体に対してリグレッションテスト（回帰テスト）を実施する必要があるが、これをイテレーションの度に人の手で行っていては膨大な追加工数が必要となってしまう。それを避けるためにテスト自動化、継続的インテグレーション（CI）といった手法がアジャイルモデルに組み込まれたと考えるべきだろう。

スパイラルモデルで問題となった点がアジャイルモデルでも問題となるケースはある、というより多いだろう。つまり後続イテレーションで際限なく追加機能要望が発生するけれども予算は限られている、という状態だ。しかしそれを諦める、出来るところまでしかしないというのがアジャイルの本質だ。結局その本質を顧客・ユーザ側、経営層側とも認識一致させることがアジャイルでの成功・不成功を決めるはずだ。