ウォーターフォール型プロセスについて考えてみた

システム開発プロセスについての話の中で、ウォーターフォール型 vs. アジャイル型という観点で議論されることは、よくあることです。その場合、ウォーターフォール型を、単なる思想とか文化として捉えられていることが多いように感じます。

ウォーターフォール型プロセスの誕生の背景的なことが、こちらに説明されています。
ウォーターフォール・モデル

当時は、そのときの環境に適したプロセスとして、採用され、広まっていったものと考えられます。
個人的には、当時の開発環境が、1つの大きなポイントだったのではないかと推測します。
1980年代くらいまでは、メインフレームが開発環境の中心でした。メインフレームで運用されるアプリケーションだけでなく、ワークステーション上で実行されるプログラムも、メインフレームでクロスコンパイルすることもありました。なので、多くの開発者が、1つのホストコンピュータを共同利用して作業を進めていました。
ところが、端末はすべての開発者に1つずつ行き渡っているわけではなく、限られた数しか用意できませんでした。そのような環境下では、よほどの理由がない限り、一人の開発者が占有するなどということは許されませんでした。端末は、「作業場所」であり、ものを考える場所ではなかったのです。
では、ものをじっくり考える場所はどこかというと、「机上」です。「机上」の作業だけで、ある程度精度の高い設計ができていることが前提で、開発プロセスが策定されていました。ソースコードまでも、紙に書く場合がありました。
このような環境の中では、必然的にウォーターフォール型になるように思います。すでに、基本アーキテクチャは決まっており、開発という側面では、技術は安定していました。それにより、技術的リスクがあまりなかったということも背景としてあったと思います。

そのような状況からの変化が始まったのは、90年代前半くらいからかなと記憶しています。「ダウンサイジング」「クライアント/サーバ」「EUC(End User Computing)」などのキーワードとともに、それまでメインフレームでしか動かせなかったアプリケーションが、ワークステーションやPCという、ユーザに近いところに降りてきました。当然、基本アーキテクチャは大きく変わりました。それまで、書類が並んでいた「机上」に個人専用のPCが置かれ、インターネットを通じて、さまざまな情報にアクセスできるようになりました。言うまでもないですが、前段で述べたときとは、かなり環境は違います。
私の観点では、主要な変化として捉えるべき点は、以下のようなものだったかなと思います。

• 各自が専用のPCを持つことによって、考えながら開発することができるようになった。


• 技術トレンドの変化が激しくなり、「初物」に出会う確率が高くなった。


• マルチベンダー化により、1つのことを実現するための選択肢が増えた。

当たり前の話ですが、このあたりの開発では、「R&D」や「プロトタイピング」といった「トライ & エラー」を経由せずに、「机上」の理論だけで作業を進めて行くことは、不可能であり、やりにくいということは明白ですね。こういった環境の中では、仮にウィータフォール的にスケジュールが策定されていたとしても、実態はアジャイルっぽくなるのが必然ですね。

前置きがちょっと長くなってしまいましたが、ここで言いたかったのは、ウォーターフォール型 vs. アジャイル型というのを、単純に思想とか文化として考えたり、どちらか一方に偏るのではなく、必要に応じてやりやすい最適な方法を選ぶことが重要だと言うことです。
現在、企業システムの世界は、JavaEEによって基本アーキテクチャがかなり安定して来ており、90年代や00年代前半に比較すると、「初物」に出会う機会もかなり少なくなってきました。それでも、メインフレームの時代にくらべると、「トライ & エラー」が必要な場面は多いと思います。
ウォーターフォール型だけではやりにくい部分があるのは明白です。現実的に、最もやりやすいと思われる方法を検討し、柔軟に計画を策定することを考えて行くことが適切なのでしょう。