ウォーターフォールじゃない開発について

ご無沙汰してます。所属変わって、新設されたサービスデリバリーセンター(SDC)の「むらたん」です。

先日、同僚から「アジャイル開発とスパイラルモデルは何が違うの?」という質問を受けました。本来、ウォーターフォールと呼ばれる「手法」とアジャイルと呼ばれる「状態」は比較できないものですが、世の中的にはプロジェクトの進め方や、重視することなどで比較されることが多く、対比表をあちこちで見かけます。
2000年台初頭のシステム開発の教科書的なものには「プロトタイプモデル」や「スパイラルモデル」という言葉がありましたが、最近はあまり見かけなくなりました。

PMIからもアジャイル実務ガイド(日本語版)が刊行されましたが、「プロトタイプ」というキーワードはあっても、「プロトタイプモデル」や「スパイラルモデル」という開発手法に関するキーワードはなく、逆に「予測型」「漸進型」「反復型」「アジャイル型」というライフサイクルの区分けになっています。

今回のエントリーは、今一度、このあたりを整理してみたいと思います。

 

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

要求定義、設計、開発、テストとトップダウンで成果を作成する手法です。アジャイル実務ガイドでは「予測型」に分類されます。
プロジェクト発足時点で欲していた成果を、約束された納期とコストで手に入れる事ができますが、これを実現するには要求を明確に定義し、要求を実現する計画が正しくなければなりません。

プロトタイプモデル

要求事項から成果のプロトタイプを作成し、要求事項の確認や洗練を行う手法です。
プロトタイプは必ずしも、最終成果と同じ形式である必要はありません。例えば、モバイルアプリケーション開発時に作成するペーパープロトタイブも、立派なプロトタイプになります。
プロトタイピングを繰り返すことで要求定義や設計の精度を上げることができますが、プロトタイピングを続ける間は最終的な成果の納期とコストが定まりません。

スパイラルモデル

想定している成果を機能分割し、分割された機能ごとに要求定義、設計、開発、テストを繰返し行い、小さな成果を顧客に引き渡していく手法です。
開発プロセスを小さく回せることで、成果や開発プロセスに対するフィードバックが得られるため、要求変更や計画変更に柔軟に対応していくことが出来る反面、要求を提示・変更する機会が多い為、プロジェクト活動が収束しないこともあります。

プロトタイプ+スパイラル=アジャイル??

成果を徐々に作り上げて顧客に引き渡し、環境や要求の変化のフィードバックを得て、適応していくという考えは、昨今のアジャイル開発と同じように聞こえます。
アジャイルソフトウェア開発宣言背後にある12の原則が全て守られていないから、アジャイルじゃない!」という話は置いておいても、ここに違いの本質が存在します。

アジャイルは「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する」

ここでいう「価値」とは、ソフトウェアをいつでも顧客に提供できて、顧客からフィードバックが得られる状態にあることを指します。ただし、早く提供するには、規模の大きなソフトウェアでは実現が難しくなるので、規模は小さいながらも実際に使える状態でソフトウェアを作り上げていきます。こういうソフトウェアはMVP(Minimum Viable Product:実用可能な最小製品)なんて呼ばれたりします。
また、実用できるからと言って、市場投入する価値があるかは別の話です。顧客満足に至らなければ、価値はないですから。。。

具体例として、名前、メールアドレス、住所、電話番号などを入力するエントリーフォームを作り、ユーザー情報を収集したいという要求について考えてみたいと思います。
プロトタイプモデルでは、UIデザインや振る舞いの確認のためにプロトタイプを作成しますが、これは自分たちが作るものを明確にするための行為であり、「ユーザー情報を収集したい」という要求を満たす価値にはなっていません。
スパイラルモデルでは、入力画面→確認画面→完了画面→トランザクション処理と機能分割して開発するかもしれません。入力画面単体が出来上がったところで、顧客としては「ユーザー情報を収集したい」という要求が満たされていないので、価値自体は無いものとなります。

市場投入できる状態にするのであれば、私だったら、メールアドレスの入力だけを持つ入力画面、トランザクション処理から実現します。
メールアドレスが収集できれば、エントリーのあったユーザーに対して顧客側からアプローチが出来るので、小さいながらも「ユーザー情報を収集したい」という要求に対して価値はあると考えたからです。このあたりが、スクラムでいうプロダクトオーナーの腕の見せどころかもしれません。

アジャイルは「変化を味方につける」

先程の例で、もし、メールアドレスだけで事が足りてしまった場合、当初の要求にあった「名前」「住所」「電話番号」の入力項目や確認画面、完了画面は要らないが、エントリ完了を通知するメール送信は欲しいとか、当初の顧客の要求が変化します。小さい機能を少しずつ作り上げていけば、作りすぎのムダを避けることができ、迅速に顧客のニーズに対応していくことができます。曖昧な要件のままスパイラルモデルの開発を続けて、顧客に引き渡しもせずに、要求仕様を変え続けてしまうのは、変化を味方に付けられていません。

アジャイルは「効率を高められるか振り返り、やり方を最適に調整する」

アジャイルは素早く効率的に価値を届けることにフォーカスしていますが、現状の活動方法に満足せず、常に見直しを掛けていきます。

その他の原則も大切な要素ではありますが、このあたりの原則が、意識できているか、意識できていないか、がアジャイルかどうかの違いになると思っています。

最後に

ここまで読んでいただいて、頭に?が浮かんだ方も多い方も多いかと思います。冒頭の質問をしてくれた方も「結局、普段担当してる開発業務はアジャイル開発だなんて言っていないが、違いが分からない」という感想でした。
冒頭にも申したとおり、アジャイルは「状態」の話で、ウォーターフォール、プロトタイプ、スパイラルは開発「手法」の話なのです。
極論を言えば、どのような開発手法であっても、アジャイルになり得ますし、スクラム開発をしていても、アジャイルにならないこともあります。

みなさんの現場は、アジャイルですか?