アジャイルとウォーターフォール (従来型とも呼ばれる) は 2 つの開発方法論であり、アジャイルは反復的なアプローチを使用する一方、ウォーターフォールは順次的です。
新しいプロジェクト、プログラム、製品に取り組むとき、プロジェクトマネージャーはどのような展開手法を使うかという決断を迫られます。 展開方法とは、基本的に、作業の計画、開発、実行、修正、モニタリング、レビューなどを組織的に進めるための 1 つか複数のプロセス、すなわちフレームワークを指します。 現在最も広く使われているのは、従来型のウォーターフォールフレームワークと、新しいアジャイル方式の 2 つです。 また、従来型手法とアジャイル手法を組み合わせた第三の手法も広く定着しつつあります。
アジャイルとは、自己組織化された機能横断的なチームのコラボレーション重視を目標とする反復型のソフトウェア開発手法です。 アジャイルの詳細についてご覧ください。
アジャイルは、割り当てられたリソースが特定のタスクを実行し、その後、次のフェーズや割り当てられたリソースにプロジェクトを移していくという、従来の順次的な方式とは異なり、 共同作業と同時進行を行うことができる専門チームに依存します。 これらのチームは同時にタスクを実行するため、タスクの完了を待つ必要がなく、ニーズの変化や突発的な問題に対処するための方向転換を容易に行うことができます。
前述したように、アジャイルは反復的であり、連続的なリリースに対応します。アジャイルでは、作業を反復と呼ばれるサイクルを繰り返す複数のシーケンスに分割します。 これにより、プロジェクト完了時に一度に価値を提供するのではなく、継続的にエンドユーザーに価値を提供することができます。 アジャイルは、継続的デリバリと継続的な改善における重要な役割を担っています。
チームによってアジャイルのアプローチは様々ですが、アジャイルでは、常に以下の基本原則が順守されます。
- 適応性
アジャイルプロジェクトでは、アーキテクチャ、設計、成果物、要件、その他の要素をプロジェクトの途中で変更する柔軟性を備えている必要があります。 - リーン開発
アジャイルでは、不要なステップや冗長なステップを排除して、最もシンプルなアプローチで開発を進めます。 - チームワーク
アジャイルは、効果的なチームワークとコミュニケーションを持つことで、複数のタスクを同時に完了できます。 - 顧客参加型
アジャイルでは、反復によって少しずつ価値を提供するため、新しいアイデアの導入や製品の修正において、お客様とコラボレーションすることが可能です。 - 持続可能性
アジャイルでは、アウトプットを重視してチームに負担をかけるのではなく、成果に基づいて顧客に価値を提供するために、持続可能で一定の開発ペースを作り出すことを重視します。 - 時間
アジャイルプロジェクトに費やす時間は、「スプリント」という小さな単位に分割され、その単位の中で特定のタスクを完了させて、その後レビューを行います。 - テスト
プロジェクト全体の完了を待つのではなく、アジャイルプロジェクトのすべてのフェーズでテストが行われます。
2000 年代初頭に導入されて以来、アジャイルは大きな人気を博しています。 アジャイル手法のメリットには、以下のようなものがあります。
事前に定義されたスプリントにより、新機能を迅速に、予測可能な形で提供することができます。 また、ベータテストを他の手法よりも早期に実施することができます。
アジャイルはシンプルさとコラボレーションを重視しているため、チームは自己組織化と重要な意思決定において他の手法では見られない自由度を発揮できます。
アジャイルにおけるチームの自律性によって、チームは望む結果に最も適した手法やテクニックを柔軟に選択することができます。 同時に、プロジェクト自体の適応性も高まり、開発の途中で新しいバックログ項目を導入したり、変更したりすることが可能になります。 また、早期にベータテストを行うことで、開発者が重要な変更を行う際に参照できる重要なフィードバックも得られます。
アジャイルの成功は、チームの内外で効果的なコミュニケーションを行う能力にかかっています。 アジャイルでは、直接的で明瞭なコミュニケーションを重視し、定期的な対面でのコミュニケーションを行います。
アジャイル手法では、機能の優先順位を決定するのは顧客かエンドユーザーです。 これにより、開発チームは、どの機能が組織にとって最大の価値をもたらすかについての明確なインサイトを得ることができます。
厳しい納期や困難で長期的な目標に直面すると、開発者は顧客の重要性を見失いがちになります。 アジャイルは、顧客ニーズやユーザーからのフィードバックを製品改善の基盤として活用することで、焦点をあてるべきことの再調整を行います。 これは、顧客満足度の向上だけでなく、収益の改善にもつながります。
アジャイルは、多くの場合、優れた方法論とみなされますが、完全に導入する前に注意すべきいくつかのデメリットがあります。 以下にその例を示しています。
顧客が開発チームと密接に連携する時間や関心を持たない場合、プロジェクトを進展させるために必要なフィードバックやインサイトを得ることができません。
チームメンバーがプロジェクトを効果的に、また効率的に完了させることに熱心に取り組まない場合、アジャイルの自己管理という側面が崩壊します。
一部のタスクや特定のサブタスクが、1 回のスプリントで完了するには時間がかかりすぎる場合があります。 このような問題に対処するためには、チームは優先順位を変更するか、費用をかけてスプリントを追加する必要があります。
アジャイルの反復的で漸進的な性質は、プロジェクトのガバナンスや監視と相性がよくありません。 自己統治ができないチームは、効果的に管理できない可能性が高くなります。
アジャイルは、ドキュメントの作成よりもソフトウェアを動かすことを優先させるため、重要なことの記録が後回しにされる場合があります。 包括的なドキュメントは、実装をより共有しやすくし、特定の決定の背後にある考え方を明らかにして、チームはより容易に初期のステージに戻ることができるようになることから、ドキュメント不足は問題となることがあります。
多くの場合、すでに定着している組織のプロセス、ツールセット、ポリシー、組織構造、管理体制は、アジャイルに適していません。 そのため、アジャイルを効果的に導入するには、組織全体で文化的な変化を広める必要があります。 これは、より伝統的な慣行に慣れている個人や部門からの反発につながる可能性があります。
より伝統的な開発手法であるウォーターフォールとは、ソフトウェア開発のライフサイクルを明確なフェーズに分割し、前のフェーズが完了した場合にのみ次のフェーズに進むことができる、直線的で順次的な手法です。
ウォーターフォールは最も古い開発手法であり、使いやすく、理解しやすい手法で、作業の前倒し、調査、文書化、計画に大きく依存します。 これは「十分に確認してから実行する」アプローチであるため、すべてのプロジェクト要件はプロジェクトの開始時に明確に定義され、これらのニーズに対応するために詳細な計画が作成されます。
従来の開発手法では、プロジェクトを 7 つの明確なステージに分割します。 これらの各ステージは他のステージから独立しており、一般的に前のステージが完了する前に新しいステージを開始することはできません。 さらに、ほとんどのステージは「ステージゲート」によって分割されています。これは、プロジェクトが次のステージに移行する前に完了しなければならない一連の要件と、管理上の決定を表すものです。 ステージには次のようなものがあります。
- 構想
開発チームは、価値・効果や潜在的なコストなど、今後のプロジェクトを評価することから開始します。 - ドキュメント
システム要件、ソフトウェア要件、そのプロジェクトに必要なその他のリソースを収集し、文書化します。 - 分析と設計
チームは、プロジェクトを分析して、製品やサービスをどのように機能させるかを決定します。また、必要な作業を特定して、それらの作業の計画を立てます。 - コーディングと単体テスト
ソフトウェアの各単体のコーディングを開始し、その過程でテストを実施します。 単体は、前のステージで定義されたソフトウェアアーキテクチャへ組み込まれます。 - システム全体のテスト
システム全体のテストを行います。これにはバグテストやユーザー受入テスト (UAT)、その他必要なテストが含まれます。 - 問題解決
前のステージで特定されたバグ、非効率性、問題点を解決し、改善を行います。 - デリバリ
完成した製品やサービスをエンドユーザーに提供します。
1970 年に発表されたウォーターフォール手法は、約半世紀に渡って開発チームの間で一貫して使用されてきました。 以下のようなメリットがその理由となっています。
ウォーターフォール手法は、ステージごとに特定の成果物があり、明確なレビュープロセスがあるため、最も管理しやすい方法と言えるかもしれません。
外部システムとの統合のために複数のコンポーネントを設計する必要があるプロジェクトでは、ウォーターフォールの (プロセスの早い段階で設計を完了させる) アプローチは明らかな利点となります。
開発開始前に製品要件を文書化し、合意しておくことで、一連の機能を予測可能で具体的なものにすることができます。
計画性を高め、文書化を先行させることで、潜在的なコストの概要を明確にできます。 これにより、正確な予算編成が可能になります。
作業の範囲全体を事前に把握できるため、進捗の測定が簡単で正確になります。 進捗は通常「ステータスレポート」で測定され、スケジュール、予算、リソースについて、作業項目が緑、黄、赤で定義されます。
ニーズの変化に応じて流動的であり続けるのではなく、開発作業を開始する前に、目標を特定して確立しておきます。
チームメンバーは、他のプロジェクトに参加することもでき、指定されたステージにのみ時間を割くことが求められます。
ウォーターフォール方式は、顧客にとっては「お任せ」すればよく、楽です。「要件定義」と「レビュー」のステージを除いて、エンドユーザーの関与は必要ありません。
計画と文書化を明確にすることで、プロジェクトは確立された道筋をたどり、レビューが容易になり、結果をより明確に判断することができます。
アジャイルの台頭によって、次に挙げるような従来のウォーターフォール手法の 欠点のいくつかが明らかになっています。
ウォーターフォールは、初期の詳細な計画に依存しているため、予期せぬ問題、障害、ニーズの変化に遭遇した場合、プロジェクトが適応できない可能性があります。 また、ウォーターフォールは一方向にしか流れないため、初期のステージに戻って変更することが不可能、あるいは非常に困難である場合があります。
要件が厳密に定義されているため、インスピレーションやイノベーション、創造性を発揮する余地がほとんどなく、開発者が開発中に出くわす予期せぬ機会を生かすことができない可能性があります。
開発プロセスへの関与が少ないため、顧客は蚊帳の外に置かれたと感じる可能性があります。 さらに問題となるのは、恐らく、プロジェクトが完了するまで、何が提供されるのかが分からないことです。 逆に、開発者自身が、顧客の求める成果がどのようなものか分からないこともあり、ギャップはさらに広がってしまいます。 さらに、テストはプロジェクトの最後にしか行われないため、バグや UX の問題が潜んでいる可能性が高くなります。
特定のステージの締め切りが明確に定まっていないと、プロジェクトが予定より遅れることがあります。 それを埋め合わせるために、チームは場合によっては、テストを含む最終ステージを急いで終わらせることになります。 このような状況は、粗悪な製品につながる可能性があります。
作業が開始する前に、要件が明確に特定され、承認される必要があります。 これを行っておかないと、各チームメンバーによって要件の解釈が異なり、すれ違いの原因となります。
計画や文書化に多くの労力が費やされるため、実際に製品を構築するために使えるリソースが少なくなります。
アジャイルとウォーターフォールには、それぞれ長所と短所があります。 このことを念頭に置いて、両方の選択肢の具体的な使用事例を理解することは、組織がプロジェクトごとに最適な方法論を選択するのに役立ちます。
どの手法にするか判断する際には、以下を考慮してください。
プロジェクトの要件が厳しい場合はウォーターフォールが適しており、要件や規制が少ない場合はアジャイルの創造性と自由度がメリットとなります。
プロジェクトの要件が厳しい場合はウォーターフォールが適しており、要件や規制が少ない場合はアジャイルの創造性と自由度がメリットとなります。
厳格なプロセスは、アジャイルの展開を非常に困難なものにするため、従来型のウォーターフォールアプローチの方がより多くの価値・効果を得ることができます。 アジャイルはプロセスがより柔軟であるほど効果的です。
ウォーターフォールは、顧客、エンドユーザー、プロダクトオーナーが、開発チームと密接に協力することを求めていない場合に有効です。 ユーザーがより深い関わりを求めている場合は、アジャイルからより多くの価値・効果を得ることができます。
機能がすでに十分に定義され、統合が確立されている既存のレガシープロジェクトを強化する場合、ウォーターフォールアプローチの恩恵を受けることができます。 一方、新境地を開拓するプロジェクトでは、アジャイルの反復的なアプローチにより、チームは学びながら適応していくことができます。
ウォーターフォール方式は、結果が予測可能であるため、期限が明確に定義された長期のプロジェクトでうまく機能します。 より柔軟で短い納期のプロジェクトの場合は、アジャイルが効果的です。
ウォーターフォールの予測可能性は、柔軟性に欠ける予算にも適しています。各アクションや経費はプロセスの初期に文書化する必要があります。 アジャイルでは、機能や開発スピードに重点を置いており、コストにはそれほど厳しい見方をせず、予算内に収めることにはそれほどこだわりません。
小規模でしっかり定義されたプロジェクトには、多くの場合、ウォーターフォールが適しています。 大規模で複雑なプロジェクトの場合、アジャイルアプローチが有効です。
リモートワーカーと調整を行ったり他の組織と連携したりする場合、ウォーターフォールは対面でのコラボレーションの必要性が少ないため、より良い選択となります。 単一の組織で同じ場所にいるメンバーが単独でプロジェクトに責任を持つ場合は、アジャイルがより効果的です。
アジャイルとウォーターフォールはどちらにも大きなメリットがあるため、世界中の組織がデメリットを抑えながらメリットを組み合わせる方法を模索しています。その結果生まれたのが、「ハイブリッドプロジェクト管理」です。
ハイブリッドプロジェクト管理は、アジャイルとウォーターフォールを一緒にすることで、時間、リソース、ユーザー満足度を最適化するソリューションを実現しています。