昔からあるウォーターフォール開発と、比較的新しいアジャイル開発。
プロジェクトで、どちらを採用すべきか、迷いますよね。
プロジェクトの成功/失敗の方向性が決まる最初の大きな判断を、間違えたくないものです。
アジャイル開発とウォーターフォール開発の違いや、向き不向き、ハイブリッドの可能性、これらを知ることで、自信を持って最初の判断をできるようにしましょう。
プロジェクトで、どちらを採用すべきか、迷いますよね。
プロジェクトの成功/失敗の方向性が決まる最初の大きな判断を、間違えたくないものです。
アジャイル開発とウォーターフォール開発の違いや、向き不向き、ハイブリッドの可能性、これらを知ることで、自信を持って最初の判断をできるようにしましょう。
アジャイル開発とは
まず、聞き慣れない人も多いかもしれませんので、アジャイル開発とはどういったものかについて、歴史、工程、特徴という観点で簡単に見ていきます。
アジャイル開発は、2001年に「アジャイル開発宣言」が発表されました。
もともと「走り」となるXP(エクストリーム・プログラミング)やスクラムなどがベースとしてあったものを総称し、「アジャイル開発」として定義しました。
アジャイル開発は、開発を一定の期間(イテレーション)で区切り、その期間の中で【設計→開発→テスト→リリース】を小さく行い、これを繰り返す手法です。
例
イテレーション1 回目: 設計→開発→テスト→リリース→ふりかえり&次の計画
イテレーション2 回目: 設計→開発→テスト→リリース→ふりかえり&次の計画
イテレーション3 回目: 設計→開発→テスト→リリース→ふりかえり&次の計画
：
：
以下、箇条書きですが、アジャイル開発特徴です。
・開発中も顧客の要求に応えて仕様変更を行う。
・ドキュメントは最小限で、ワードやエクセルなどよりは、ツールやWikiのような形で残す事が多い。
・プロジェクトの中で、チームを成長させるしくみが多く、チームは並列で上下がない。
・イテレーションごとに動くソフトウェアをリリースするので、顧客もチームも安心感を持てる。
関連記事：アジャイル開発とは？簡単な解説と導入のメリットまで
アジャイル開発の歴史
アジャイル開発は、2001年に「アジャイル開発宣言」が発表されました。
もともと「走り」となるXP(エクストリーム・プログラミング)やスクラムなどがベースとしてあったものを総称し、「アジャイル開発」として定義しました。
アジャイル開発の工程
アジャイル開発は、開発を一定の期間(イテレーション)で区切り、その期間の中で【設計→開発→テスト→リリース】を小さく行い、これを繰り返す手法です。
例
イテレーション1 回目: 設計→開発→テスト→リリース→ふりかえり&次の計画
イテレーション2 回目: 設計→開発→テスト→リリース→ふりかえり&次の計画
イテレーション3 回目: 設計→開発→テスト→リリース→ふりかえり&次の計画
：
：
アジャイル開発の特徴
以下、箇条書きですが、アジャイル開発特徴です。
・開発中も顧客の要求に応えて仕様変更を行う。
・ドキュメントは最小限で、ワードやエクセルなどよりは、ツールやWikiのような形で残す事が多い。
・プロジェクトの中で、チームを成長させるしくみが多く、チームは並列で上下がない。
・イテレーションごとに動くソフトウェアをリリースするので、顧客もチームも安心感を持てる。
関連記事：アジャイル開発とは？簡単な解説と導入のメリットまで
ウォーターフォール開発とは
続いてウォーターフォール開発について簡単に説明します。
ウォーターフォール開発の起源を辿ると、1970年代にW. W.ロイスによって発表された論文「Managing the Development of Large Software Systems」が元になったとされています。
ウォーターフォール開発は、【要件定義→設計→開発→テスト→リリース】という工程を、順に進めていきます。
要件定義が終わったら設計工程へ、設計が終わったら開発工程へ、というように各工程を積み上げていきます。
ウォーターフォール開発の特徴を箇条書きで挙げます。
・要件定義以降の仕様変更は基本的には行いません。行うとしても規模・内容によって別費用などを調整する。
・一般的に、納品物としてしっかりしたドキュメントを顧客から求められる事が多い。
・チームはピラミッド型で上下がある。
・工程が明確に分かれているので、リソース計画を立てやすい。
ウォーターフォール開発の歴史
ウォーターフォール開発の起源を辿ると、1970年代にW. W.ロイスによって発表された論文「Managing the Development of Large Software Systems」が元になったとされています。
ウォーターフォール開発の工程
ウォーターフォール開発は、【要件定義→設計→開発→テスト→リリース】という工程を、順に進めていきます。
要件定義が終わったら設計工程へ、設計が終わったら開発工程へ、というように各工程を積み上げていきます。
ウォーターフォール開発の特徴
ウォーターフォール開発の特徴を箇条書きで挙げます。
・要件定義以降の仕様変更は基本的には行いません。行うとしても規模・内容によって別費用などを調整する。
・一般的に、納品物としてしっかりしたドキュメントを顧客から求められる事が多い。
・チームはピラミッド型で上下がある。
・工程が明確に分かれているので、リソース計画を立てやすい。
アジャイル開発とウォーターフォール開発、向き不向き
アジャイル開発とウォーターフォール開発の向き不向きということでいうと、一般的に次のように分けられます。
・銀行などの堅牢なシステムや大規模開発には「ウォーターフォール開発」
・比較的小規模な開発やニーズが変化する開発には「アジャイル開発」
しかし、この「向き不向き」も最近では崩れつつあります。
「エンタープライズアジャイル」など、大規模でもアジャイルを採用するプロジェクトもあります。
この背景には、現代の複雑かつスピード感の求められる開発に、ウォーターフォール開発では対応しきれない、という判断によるものと考えられます。
例えば、Eclipseの開発ではスクラム・オブ・スクラムズ（Scrum of Scrums）という形で大規模な開発が進められています。
参考：Eclipse Foundation Development Process
そして、エンタープライズアジャイルにも、フレームワークがあります。
・ディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery：DAD）
・スケールド・アジャイル・フレームワーク（Scaled Agile Framework：SAFe）
この2つのフレームワークが有名です。
・銀行などの堅牢なシステムや大規模開発には「ウォーターフォール開発」
・比較的小規模な開発やニーズが変化する開発には「アジャイル開発」
しかし、この「向き不向き」も最近では崩れつつあります。
「エンタープライズアジャイル」など、大規模でもアジャイルを採用するプロジェクトもあります。
この背景には、現代の複雑かつスピード感の求められる開発に、ウォーターフォール開発では対応しきれない、という判断によるものと考えられます。
例えば、Eclipseの開発ではスクラム・オブ・スクラムズ（Scrum of Scrums）という形で大規模な開発が進められています。
参考：Eclipse Foundation Development Process
そして、エンタープライズアジャイルにも、フレームワークがあります。
・ディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery：DAD）
・スケールド・アジャイル・フレームワーク（Scaled Agile Framework：SAFe）
この2つのフレームワークが有名です。
アジャイル開発とウォーターフォール開発のメリット、デメリット
アジャイル開発とウォーターフォール開発、それぞれにメリット、デメリットはあります。
・常に動くソフトウェアをリリースしながら進めるので、問題の発見が早く、大炎上が発生しにくい。
・プロダクトとともに、チームも成長する。
・顧客のニーズに応えやすく、本当に必要とされるプロダクトを届けやすい。
・手戻りコストが低い。
・活発なコミュニケーションや短い期限による緊張感など、プロジェクトに動きが出て、仕事が楽しくなる。
・アジャイルで進めるためのスキルが必要で、いきなり全てを導入するにはハードルが高い。
・発注先がアジャイル開発の採用をNGとする場合がある。
・仕様変更は優先順位付けや取捨選択が必須の前提条件としてあるが、機能追加がいつまでもできると誤った認識で変更が発生し続けるなどあるので、顧客側の教育も必要。
・要件定義を最初に完了させてしまうので、比較的見積りやすく、人員も確定しやすい。
・工程をぶつ切りすれば良いので、スケジュールを立てやすい。
・順に工程を終わらせていくことができる。
・後工程のテストなどで問題が発生した場合、手戻りコストが大きい。
・全て決めようとするため要件定義に時間がかかりやすい。
・大きなスケジュールで動いているので、遅延が少しずつ蓄積し、取り返せずに大きな遅れに発展しやすい。
関連記事：システム開発における要件定義の重要性と進め方のコツ
各々のメリット、デメリットを考えると
よほど強力な理由がない限り、今ウォーターフォール開発を採用する利点は少ないのではないのでしょうか。
アジャイル開発のメリット
・常に動くソフトウェアをリリースしながら進めるので、問題の発見が早く、大炎上が発生しにくい。
・プロダクトとともに、チームも成長する。
・顧客のニーズに応えやすく、本当に必要とされるプロダクトを届けやすい。
・手戻りコストが低い。
・活発なコミュニケーションや短い期限による緊張感など、プロジェクトに動きが出て、仕事が楽しくなる。
アジャイル開発のデメリット
・アジャイルで進めるためのスキルが必要で、いきなり全てを導入するにはハードルが高い。
・発注先がアジャイル開発の採用をNGとする場合がある。
・仕様変更は優先順位付けや取捨選択が必須の前提条件としてあるが、機能追加がいつまでもできると誤った認識で変更が発生し続けるなどあるので、顧客側の教育も必要。
ウォーターフォール開発のメリット
・要件定義を最初に完了させてしまうので、比較的見積りやすく、人員も確定しやすい。
・工程をぶつ切りすれば良いので、スケジュールを立てやすい。
・順に工程を終わらせていくことができる。
ウォーターフォール開発のデメリット
・後工程のテストなどで問題が発生した場合、手戻りコストが大きい。
・全て決めようとするため要件定義に時間がかかりやすい。
・大きなスケジュールで動いているので、遅延が少しずつ蓄積し、取り返せずに大きな遅れに発展しやすい。
関連記事：システム開発における要件定義の重要性と進め方のコツ
各々のメリット、デメリットを考えると
よほど強力な理由がない限り、今ウォーターフォール開発を採用する利点は少ないのではないのでしょうか。
ウォーターフォール開発が用いられる典型的な場面
ウォーターフォール開発は、ソフトウェア開発プロセスの古典的なアプローチの一つであり、段階的な進行と文書化を重視します。
しかしここまで見てきて、ウォーターフォール開発にはあまりメリットがないように思われた方がいるかもしれません。
以下、ウォーターフォール開発が現代でも採用される場面について確認しておきましょう。
だいぶ古い話になりますが、代表的なウォーターフォール開発の事例ということで、こちらを紹介します。
アメリカのNASAは、アポロ計画を通じて、人類初の月面着陸を実現しました。この計画では、ウォーターフォールモデルが使用され、要求仕様、設計、実装、テスト、運用といった段階的なプロセスが厳格に守られました。各段階で文書化された設計やテスト計画が非常に重要でした。
航空機の制御ソフトウェアは高い信頼性とセキュリティが求められるため、ウォーターフォールモデルが一般的に採用されています。この分野では、要求分析、設計、コーディング、テスト、および運用といった段階が厳格に区別され、各段階で文書化と厳格な品質管理が行われます。
法執行機関向けの情報システムやデータベース開発プロジェクトでは、セキュリティとデータの正確性が非常に重要です。ウォーターフォールモデルは、要求の明確化、データモデリング、実装、テスト、トレーニング、運用といった段階を効果的に管理するのに役立ちます。
これらはウォーターフォール開発の事例の一部です。ウォーターフォールモデルは特定のプロジェクトや産業に適している場合がありますが、近年ではアジャイル開発などのアジャイルアプローチも広く採用されており、プロジェクトの性質や要求に応じて最適な開発方法を選択することが一般的です。
しかしここまで見てきて、ウォーターフォール開発にはあまりメリットがないように思われた方がいるかもしれません。
以下、ウォーターフォール開発が現代でも採用される場面について確認しておきましょう。
アポロ計画（Apollo Program）
だいぶ古い話になりますが、代表的なウォーターフォール開発の事例ということで、こちらを紹介します。
アメリカのNASAは、アポロ計画を通じて、人類初の月面着陸を実現しました。この計画では、ウォーターフォールモデルが使用され、要求仕様、設計、実装、テスト、運用といった段階的なプロセスが厳格に守られました。各段階で文書化された設計やテスト計画が非常に重要でした。
航空機の制御ソフトウェア開発
航空機の制御ソフトウェアは高い信頼性とセキュリティが求められるため、ウォーターフォールモデルが一般的に採用されています。この分野では、要求分析、設計、コーディング、テスト、および運用といった段階が厳格に区別され、各段階で文書化と厳格な品質管理が行われます。
法執行機関向け情報システム開発
法執行機関向けの情報システムやデータベース開発プロジェクトでは、セキュリティとデータの正確性が非常に重要です。ウォーターフォールモデルは、要求の明確化、データモデリング、実装、テスト、トレーニング、運用といった段階を効果的に管理するのに役立ちます。
これらはウォーターフォール開発の事例の一部です。ウォーターフォールモデルは特定のプロジェクトや産業に適している場合がありますが、近年ではアジャイル開発などのアジャイルアプローチも広く採用されており、プロジェクトの性質や要求に応じて最適な開発方法を選択することが一般的です。
アジャイル開発とウォーターフォール開発のハイブリッドは可能？
併用が可能なのか、これはよく議論にあがる問いです。
ハイブリッドという中途半端なやり方をすると「失敗する」という意見もあり、賛否が分かれる問題のようです。
しかし、筆者の経験から言うと『可能』です。
なぜ可能なのか、
そもそも『プロジェクトの成功確率を上げられるのであれば、結局、手法は何でもよい。』からです。
何をもって、ハイブリッドとするのかしないのか。定義はありません。
アジャイルの一部要素を取り入れて、うまく進められるならそれで良いのです。
ウォーターフォールは○○だから△△すべき、とか、
○○をしていないからアジャイル開発ではない、というのは残念な発想で、手段と目的を取り違えています。
手法ばかりに囚われる必要はありません。
会社、部署、その他プロジェクトを進める上で、アジャイル開発の導入が許される状況ではないが、
ウォーターフォールでうまくいくイメージを持てていない。疑問を持っている。
ではどうすればうまくいくか。
今までのプロジェクトで、駄目だった所は何なのか、良かった所はどこなのか。
駄目だった所を解消する方法として、アジャイル開発のフレームワークのうち、課題を解決してくれそうなメソッドを取り入れる。
というように、要は、ハイブリッドをしたい理由、取り入れどころ、使いどころによって、成功/失敗が分かれるということです。
ハイブリッドをする場合は、理由を曖昧にせず、自問し、自分でも納得した上で自信を持って進めましょう。
ハイブリッドという中途半端なやり方をすると「失敗する」という意見もあり、賛否が分かれる問題のようです。
しかし、筆者の経験から言うと『可能』です。
なぜ可能なのか、
そもそも『プロジェクトの成功確率を上げられるのであれば、結局、手法は何でもよい。』からです。
何をもって、ハイブリッドとするのかしないのか。定義はありません。
アジャイルの一部要素を取り入れて、うまく進められるならそれで良いのです。
ウォーターフォールは○○だから△△すべき、とか、
○○をしていないからアジャイル開発ではない、というのは残念な発想で、手段と目的を取り違えています。
手法ばかりに囚われる必要はありません。
会社、部署、その他プロジェクトを進める上で、アジャイル開発の導入が許される状況ではないが、
ウォーターフォールでうまくいくイメージを持てていない。疑問を持っている。
ではどうすればうまくいくか。
今までのプロジェクトで、駄目だった所は何なのか、良かった所はどこなのか。
駄目だった所を解消する方法として、アジャイル開発のフレームワークのうち、課題を解決してくれそうなメソッドを取り入れる。
というように、要は、ハイブリッドをしたい理由、取り入れどころ、使いどころによって、成功/失敗が分かれるということです。
ハイブリッドをする場合は、理由を曖昧にせず、自問し、自分でも納得した上で自信を持って進めましょう。
まとめ
しばしば比較されがちなアジャイル開発と、ウォーターフォール開発について考えてみました。
プロマネ新人が「プロジェクトマネージャとは？」を学び、身につけるにはウォーターフォール開発は良い手法でもあります。
しかし、情報社会の今、スピード感やニーズ対応の柔軟性を考えるとアジャイル開発になるでしょう。
手法が何にせよ、やはり「あるべき価値の提供を正しくできる」プロジェクトの推進方法を採用したいものですね。
プロマネ新人が「プロジェクトマネージャとは？」を学び、身につけるにはウォーターフォール開発は良い手法でもあります。
しかし、情報社会の今、スピード感やニーズ対応の柔軟性を考えるとアジャイル開発になるでしょう。
手法が何にせよ、やはり「あるべき価値の提供を正しくできる」プロジェクトの推進方法を採用したいものですね。
