非ウォーターフォール・モデル
プロトタイプ・モデル
1980年代後半になり、ウォーターフォール・モデルの問題点が明確になるにつれて、その問題点を解決すべく、非ウォーターフォールの（ウォーターフォールではない）開発モデルが提唱され、広まっていきました。ここでは、非ウォーターフォールの開発モデルとして、プロトタイプ・モデルとスパイラル・モデルについて説明します。
プロトタイプ・モデルとは、開発の早い段階で試作品（プロトタイプ）を作成し、その試作品をエンドユーザーが確認、評価することにより、システムの仕様を確定していく開発プロセスです（図1）。プロトタイプ・モデルでは、試作品に対するエンドユーザーの評価を受け、試作品を改良して完成品に近づけていくことにより開発を進めます。これにより、ウォーターフォール・モデルにおける「実物は工程終盤にできる」というデメリットを解決しよう、という考え方です。
そのため、プロトタイプ・モデルにおいては、試作する機能範囲やエンドユーザーが確認、評価するポイントの絞り込みが非常に重要になってきます。絞り込みが弱すぎる（試作品で実装する範囲が大きい）と、試作品を作るコストが大きくなりますし、スケジュールとしても、早い段階で試作品を完成させるのが難しくなります。また、絞り込みが強すぎる（試作品で実装する範囲が小さい）と、エンドユーザーが確認、評価するために十分な機能を持たない試作品となってしまいます。
このあたりのさじ加減が難しいこともあり、現場においては、プロトタイプ・モデルの考え方（試作品を作って確認、評価する）のみをウォーターフォール・モデルに適用することも少なくありません。例えば、画面モックで画面レイアウトだけを確認する、技術的に困難な部分だけを試作して実現性を確認する等、皆さまの現場でもよくやられるのではないでしょうか。
プロトタイプモデルのメリット／デメリット
プロトタイプ・モデルのメリットは、次の点が挙げられます。
・要件漏れを防げる、仕様の精度が向上する
ウォーターフォール・モデルのデメリットにもなっていましたが、通常、システム開発において「動くシステム」ができるのは、開発の終盤と言って良いでしょう。そのため、要件定義～設計といった上流工程では、エンドユーザーは設計書や仕様書といったドキュメントで、システムの挙動や使い勝手を確認することになります。
当然、ドキュメントでは記述レベルに限界がありますので、どうしても要件漏れは発生してしまうことが多いのではないでしょうか。また、実際に作ってみないとわからないこともありますので、動くシステムを早い段階で作ってしまう、という進め方が生み出すメリットは、非常に大きいのです。
対して、デメリットとしては、次の点が挙げられます。
・開発コストがかかる（そのリスクが高い）
プロトタイプ・モデルでは、試作品とは言え、エンドユーザーに確認、評価してもらえるだけの機能を作りこむ必要があります。システムの機能や特性にもよりますが、完成品の全機能を試作品として開発しないと意味がない、というシステムも中にはあるでしょう。その場合は、ほぼ完成品という試作品を作る必要があるので、開発コストが膨らむのは目に見えています。
逆に、エンドユーザーが確認、評価できないような、中途半端な試作品を作ったとしましょう。その場合には、試作品に対する十分なフィードバック（エンドユーザーの確認、評価）を得ることができず、「要件漏れを防ぐ」「仕様精度の向上」といった本来の目的を達成することができません。この場合、試作品を作ったこと自体が無意味になってしまいます。
スパイラル・モデル
スパイラル・モデルとは、システム全体を幾つかの部分に分け、分けられた部分を単位として開発を進める開発プロセスです（図2）。スパイラル・モデルでは、システム全体を分割した単位で、設計～テストのサイクルを繰り返しながら開発を進めていきます。これにより、ウォーターフォール・モデルにおける「工程の最初の段階でしか要件を決められない」というデメリットを解決しよう、という考え方です。
スパイラル・モデルと一口に言っても、「反復型」と「インクリメンタル型」に分けることができます。
・反復型
サイクルを繰り返していくことで、実装する機能を深めていく。システム全体を部分に分ける際には、機能の深さ（優先度や重要度）によって分割するイメージ。各部分を、プロトタイプ・モデルとして進めていくと考えて良い。
・インクリメンタル型
サイクルを繰り返していくことで、実装する機能を広げていく。システム全体を、機能ごとにサブシステムとして分割するイメージ。各部分を、ウォーターフォール・モデルとして進めていくと考えて良い。
このため、スパイラル・モデルにおいては、システム全体を分割する単位が非常に重要となります。反復型においては、プロトタイプ・モデルと同じような問題点（さじ加減の難しさ）がありますし、インクリメンタル型においては、システム全体の境界線をうまく引けるかどうかが難しい、という問題点があります。
スパイラルモデルのメリット／デメリット
スパイラル・モデルのメリットとしては、以下の点が挙げられます。
・開発単位が小さい
開発の局面において、「動くシステム」を比較的早い段階でリリースすることができます。これにより、リリースしたシステムの評価や新たに発生した要件等のフィードバックを、これから開発する部分に適用できるため、要件の追加や変更に対応しやすいと言えるでしょう。
また、稼働の局面においては、システム変更によるインパクトを小さく抑えることができ、また、段階的な稼働も可能となります。例えば、企業への業務システム導入等は、業務変更へのインパクトがエンドユーザーへの大きな負担となることがあるので、段階的稼働のメリットは無視できません。
対して、デメリットとしては、次の点が挙げられます。
・開発の初期段階でシステム全体を見通せない
スパイラル・モデルでは、ある意味、開発の初期段階ではシステム全体を詳細に見極めないでも、開発を進めることが可能となっています。そのため、分割された各部分をそれぞれ進めていく中で、進むべき方向性が違うことに気がつくことがあります。この場合には、すでに完成している部分を修正するコストが膨らんでしまいます。
また、システム全体を詳細に見極めていないことから、部分への分割がうまくいかないこともあるでしょう。例えば、システム全体を機能ごとにサブシステムとして分割することは、よくあると思います。この際、各サブシステムの開発を進めていった過程で、関連が弱いと思われていたサブシステム間での密な連携を行わなければならないことが判明した場合には、連携機能を別途開発しなければならなくなります。このような分割ミスもスケジュール遅延やコストを押し上げる要因となります。
ウォーターフォール・モデルとの違い
ウォーターフォール・モデルと非ウォーターフォール・モデル（プロトタイプ・モデルやスパイラル・モデル）との違いを下記のようにまとめてみました（図3）。これらの内容からもわかる通り、非ウォーターフォール・モデルは、反ウォーターフォール・モデルという訳ではなく、ウォーターフォールの拡張版ととらえて良いかと思います。
・開発単位の大きさ
ウォーターフォール・モデルは、システム全体を一気に作るため、開発単位は「システム全体」となります。これに起因するウォーターフォール・モデルのデメリットの影響が大きくなってきたため、非ウォーターフォール・モデルでは、機能の深さや機能ごと（サブシステムごと）のように、開発単位を小さくする方向で改良されています。
・上流工程の位置付け、開発の進め方
ウォーターフォール・モデルは、上流工程で「すべてを見通す」というものでした。これは、上流工程をきちんと行えばすべてを見通すことができる、という前提に基づいています。この点が「現実的ではない」というゆえんにもなっているので、非ウォーターフォール・モデルでは、上流工程における要件の考慮漏れに、ある程度、柔軟に対応できるような進め方になっています。
また、ウォーターフォール・モデルの各工程は、一発勝負です。通常、工程をやり直すことはありません。しかし、現実問題としては、要件や仕様の変更、ドキュメントの不備等の影響により、実質的には工程をやり直すのと同じ位の大きな手戻りが発生し、プロジェクトがデスマーチ化することも少なくありません。ウォーターフォール・モデルでは、そのような手戻りがあまり考慮されていないのに対し、非ウォーターフォール・モデルでは、ある程度の手戻りを開発プロセスに明示的に織り込まれていると言って良いでしょう。
こぼれ話
ここでは、スパイラル・モデルでの良くある落とし穴として、私が携わったPJでの話を披露したいと思います。皆さまも十分注意してください。
・「画面を見ないとわからないなぁ」
設計書レビューの段階での、ユーザー側担当者のお言葉。その開発PJは、ウォーターフォールで開発を進めていたが、急きょ、画面モックを作り、プロトタイプ的に進めることになった。数日後、画面モックのレビューを行ったら「んー、ある程度動かないと。画面だけではわからないなぁ」と……。
プロトタイプにせよスパイラルにせよ、エンドユーザーに「ドキュメントよりは完成品に近い何か」を確認してもらいます。ドキュメントよりは確認しやすいとは言え、しょせんは試作品。通常は、完成品から機能ドロップされているので、イメージがわかないケースもあります。
事前に、試作する範囲や試作品で確認するポイントを明確にエンドユーザーと認識を合わせておくのはもちろんのこと、エンドユーザーのやる気を引き出すのも非常に重要なのです。「やる気のある人はドキュメントでも確認できる、やる気のない人は完成品でも確認できない」ということですね。
Think ITメルマガ会員登録受付中
他にもこの記事が読まれています
全文検索エンジンによるおすすめ記事
- 開発プロセスモデル
- 開発手法を徹底比較！アジャイル vs.ウォーターフォール
- アジャイル開発とは？プロジェクト推進からチームビルディング、見積もりのコツまでを完全解説
- DX時代に求められるエンジニアでも知っておきたいスキル・知識
- さまざまな開発手法
- いろいろなプロセス ～V字モデルとスクラム～
- エンタープライズモバイルに必要なアプリの品質とは？―Think IT Mobile Developer Seminar 2016レポート
- CNDT2021、大規模ウォーターフォール開発をクラウドネイティブにするためのヒントをNTTデータのエバンジェリストが解説
- インフラの中核を担う「サーバ」を知ろう
- 開発ドキュメントを何で作成するか？