ウォーターフォールプロセス

ソフトウェアの世界では、「ウォーターフォール」という言葉は、ソフトウェアプロセスのスタイルを表すのに一般的に使われており、反復型やアジャイル型のスタイルと対比されます。ソフトウェアにおける多くのよく知られた用語と同様に、その意味は曖昧で、起源も不明瞭ですが、私はその本質的なテーマは、大きな取り組みをアクティビティに基づくフェーズに分解することだと考えています。

「ウォーターフォール」という言葉がどのように普及したかは不明確ですが、ほとんどの人はその起源をウィンストン・ロイスの論文、特にこの図に基づいていると考えています。

この論文は、タスクが下向きに連なる形状から、ウォーターフォールの概念の源として広く認められているようですが、「ウォーターフォール」という用語は論文には一度も出てきません。この名前が後からどのように登場したかは不明です。

ロイスの論文は、当時の（60年代後半の）ソフトウェア開発プロセスに関する彼の観察と、通常の実施手順をどのように改善できるかを記述しています。[1] しかし、「ウォーターフォール」はさらに広がり、ソフトウェア開発のスタイルの一般的な記述として使われるようになりました。ソフトウェア会議で講演する私のような者にとって、この言葉はほとんど常に軽蔑的な意味でしか登場しません。私が長年、会議の講演者がウォーターフォールについて良いことを言っているのを聞いた記憶はありません。しかし、企業の実務担当者と話すと、実行可能で、好ましい開発スタイルとして語られることがあります。確かに90年代よりも現在は少なくなっていますが、プロセス専門家の話を聞いて想定されるよりも頻繁に耳にします。

しかし、正確には「ウォーターフォール」とは何でしょうか？ソフトウェアにおける多くの事柄と同様に、明確な定義がないため、答えるのは簡単ではありません。私の判断では、人々がウォーターフォールに使う定義を支配する共通の特徴が一つあり、それは、取り組みをアクティビティに基づいたフェーズに分解するという考え方です。

そのフレーズを分解してみましょう。ソフトウェアを構築する必要があり、その構築に約1年かかると考えているとします。1年間姿を消して、終わったら教えてくれ、と快く言う人はほとんどいないでしょう。代わりに、ほとんどの人はその1年をより小さな塊に分解して、進捗状況を監視し、物事が順調に進んでいると確信したいと思うでしょう。問題は、この分解をどのように行うかです。

ロイスのスケッチが示すように、ウォーターフォールスタイルは、実施しているアクティビティによって分解します。したがって、1年のプロジェクトは、2か月の分析、それに続く4か月の設計、3か月のコーディング、および3か月のテストに分解される可能性があります。ここで対照的なのは、反復型スタイルです。反復型スタイルでは、大まかな要件（図書館管理システムを構築するなど）を取り上げ、それらをサブセット（カタログ検索、書籍の予約、貸し出しと返却、延滞金の評価など）に分割します。次に、これらのサブセットの1つを取り上げ、その機能を実装するワーキングソフトウェアを構築するために数か月を費やし、ステージング環境、またはできればライブの本番環境に配信します。1つのサブセットでそれを行った後、さらにサブセットを続けます。

この考え方では、ウォーターフォールとは「すべての機能について一度に1つのアクティビティを実行する」ことを意味し、反復型とは「一度に1つの機能についてすべてのアクティビティを実行する」ことを意味します。

「ウォーターフォール」という言葉の起源が曖昧であるならば、このフェーズベースの分解がどのように始まったのかという概念も曖昧です。私の推測では、特に建設などのアクティビティをインスピレーションとして見ると、大きなタスクをさまざまなアクティビティに分解するのは自然なことです。各アクティビティには異なるスキルが必要なので、すべてのアナリストが分析を完了してから、すべてのコーダーを投入するのは直感的に理にかなっています。要件の誤解は、特に60年代後半のコンピュータの状態を考えると、人々がコーディングを開始する前に修正する方が安価であるように思われます。最後に、機能ベースの分解を教えるのが難しい一方で、同じアクティビティベースの分解は多くのプロジェクトの標準として使用できます。[2]

ソフトウェア開発において、なぜこのウォーターフォール思考が適切でないかを説明する人を見つけるのは難しくありませんが、ここではウォーターフォールスタイルに対する私の主な反対意見を要約しておく必要があります。ウォーターフォールスタイルは通常、テストと統合をサイクルの最後の2つのフェーズとしていますが、これらは開発プロジェクトで最も予測が難しい要素です。これらの段階での問題は、初期段階の多くのステップの再作業と、プロジェクトの大幅な遅延につながります。後半のフェーズ以外はすべて「完了」と宣言するのが簡単すぎて、多くの作業が抜け落ちているため、プロジェクトが順調に進んでいるかどうかを判断するのが困難です。すべての機能が完了する前に早期リリースする機会はありません。これらすべてが、開発作業に大きなリスクをもたらします。

さらに、ウォーターフォールアプローチは、予測型の計画スタイルを強要します。つまり、要件分析などのフェーズを完了すると、その結果として得られる成果物が、後のフェーズが作業の基礎となる安定したプラットフォームになると想定しています。[3] 実際には、ほとんどのソフトウェアプロジェクトでは、ドメイン、ソフトウェア環境の特性、ビジネス環境の変化について誰もがより深く理解するため、数か月以内に要件を大幅に変更する必要があることがわかります。実際、機能のサブセットを配信することは、次に何をする必要があるかを明確にする上で何よりも役立つことがわかっています。したがって、反復的なアプローチにより、実際のソフトウェアニーズが何かを学習するにつれて計画を更新する適応型計画アプローチに移行できます。[4]

これらが、私が「成功させたいプロジェクトでのみ反復開発を使用すべきだ」と軽率に述べた主な理由です。

ウォーターフォールと反復は、互いに入れ子になる可能性があります。6年間のプロジェクトは、2つの3年間のプロジェクトで構成され、それぞれのプロジェクトがウォーターフォールスタイルで構成され、2番目のプロジェクトでは追加機能が追加される可能性があります。これをトップレベルでの2回の反復プロジェクトとして考えることができ、各反復はウォーターフォールとして機能します。規模が大きく、反復回数が少ないため、私はそれを主にウォーターフォールプロジェクトと見なします。対照的に、各反復がウォーターフォールスタイルで計画されている、それぞれ1か月の16回の反復を持つプロジェクトを見るかもしれません。私はそれを主に反復的と見なします。理論的には分類が難しい中間のプロジェクトの可能性がありますが、実際には、どちらのスタイルが支配的かを簡単に判断できます。

初期段階（要件分析、ハイレベル設計）をウォーターフォールスタイルで実施し、後の段階（詳細設計、コード、テスト）を反復的な方法で実施するという、ウォーターフォールと反復の組み合わせも可能です。これにより、後半のテストおよび統合フェーズに固有のリスクは軽減されますが、適応型計画は有効になりません。

ウォーターフォールは、アジャイルソフトウェア開発の代替としてよく挙げられますが、それは厳密には真実ではないと思います。確かに、アジャイルプロセスには反復的なアプローチが必要であり、ウォーターフォールスタイルでは機能しません。しかし、反復的なアプローチ（つまり、非ウォーターフォール）に従うことは簡単ですが、アジャイルである必要はありません。[5] たとえば、100個の機能を、今後1年間の10回の反復に分割し、各反復が計画された機能セットで時間どおりに完了することを期待するかもしれません。これを行う場合、私の初期計画は予測計画です。すべてがうまくいけば、作業は計画に厳密に従うはずです。しかし、適応型計画は、アジャイル思考の不可欠な要素です。反復間で機能が移動し、新しい機能が登場し、多くの機能が十分な価値がないとして破棄されることを期待します。

私の経験則では、「予定どおりで予算内だったので成功した」と言う人は誰でも、反復プロセスに従っているとしても、予測的な計画の観点で考えているため、アジャイルの考え方を持っているとはいえません。アジャイルの世界では、成功とはビジネス価値のすべてであり、数か月前に計画に何が書かれていたかは関係ありません。計画は作成されますが、定期的に更新されます。次に何をすべきかの決定を導きますが、成功の尺度としては使用されません。