ソフトウェア エンジニアは起きている時間の大半を、先任者が残したコードのぬかるみをかき分けながら進んでいる、と言っても過言ではありません。 過去のコードとの競合で事態が悪化する前に草原へと無事到達できることはまれで、たいていは戦いの最前線に放り込まれることになります。 サービス停止の砲弾があちこちで炸裂する中、塹壕から一歩も動けなくなるのも珍しくありません。 開発の現場では勇敢な戦いが繰り広げられていることもありますが、進捗は亀の歩みです。

そこへ現れるのが、百戦錬磨のベテランです。 彼らは致命的な攻撃に対応した話や虫退治の逸話を喜々として新人に語ります。 ベテランはみな、コードの書き方について個人として経験や学びを吸収してきました。業界もまた、大規模なソフトウェア開発についての経験と学びを集団として積み重ねています。 現場でバグに囲まれ、機能にまつわる炎上に対処しているときは、そのような大きな流れはなかなか感じにくいものです。

20 世紀の哲学者 George Santayana 氏は言いました。「過去を振り返らない者は、過去を繰り返すことになる」。 もちろん、この言葉はソフトウェア開発に向けられたものではありません。とは言え、彼は既に故人なので、私が本来の文脈から外れて引用しても大丈夫でしょう。 パブリック ドメインってすばらしいですね!

さて、このシリーズでは、ソフトウェア開発の手法の歴史をひもときます。特にスポットライトを当てるのは、従来のベスト プラクティスと DevOps が交わるところです。 本シリーズは、いわばシリコン バレー版『シルマリルの物語 (トールキンによる創作年代記)』です (図や写真が多く、テキストは少ないという違いはありますが)。 この激動の時代をのぞき込む前に、注意点が 1 つ。ここに記載する年代記は、理論は網羅していますが、実践はまだ途上です。 理論的には完成している用語やプロセスであったとしても、ベスト プラクティスとして実際の製品に浸透するまでには多くの段階を経るため、時間がかかるからです。 本シリーズも、”多くの段階を経る手法” から始めることにしましょう。

ウォーターフォールモデルとは?

ソフトウェア開発の歴史がまだ浅かった頃、エンジニアの手本はハードウェア分野の業務でした。 ハードウェア分野ではミスの代償が高くつくため、本格的な生産を始める前に不具合を解消するのは当然のことでした。 たとえば、ある玩具メーカーが、ヘラジカのぬいぐるみにウィットに富んだ政治風刺もしゃべらせようと決めた場合、不具合の調査は製造が開始される前に行う必要があります。 でなければ、もの言わぬヘラジカが何千匹も製造されてしまい、まったく売れずに終わることは誰の目にも明らかです。

1970 年に Winston Royce (ウィンストン・ロイス) 情報工学博士が「Managing the Development of Large Software Systems (大規模ソフトウェア システムの開発管理)」(英語) という論文を発表しました。 この論文で提唱されたソフトウェア開発のプロセスは、ハードウェアの世界で広く使用されている手法に非常に似ていました (下図参照)。

ウォーターフォールモデルの参考図

別名 "SSAPCTO"

このプロセスは、複数の工程で構成されています。隣り合った工程でちょっとした反復が行われることはあるものの、基本的には前の工程を完全に終えてからでないと次の工程に進めない仕組みになっています。 元論文では “ウォーターフォール” という言葉は一度も使われていません。このプロセスに初めて “ウォーターフォール” という名前を当てはめたセンスの持ち主は、歴史の中に消えてしまいました。

しかし、今では誰もがこの言葉をすんなり受け入れています。下へ向かって流れるウォーターフォール (Waterfall) は、下流の工程へ向かって進むソフトウェア開発を表すのにピッタリだからです。 水は (普通は) 上へ向かって流れることはありません。水が上にのぼるのは、力が加えられたときだけです。 ウォーターフォールって、すばらしいネーミング センスですよね! ソフトウェア エンジニアに多感で詩人のような心がないなんて言わせません。

直線的で連続的な自然の美しさをご覧ください!

ウォーターフォール モデルに込められた意図は、不測の事態が生じない秩序だった製造サイクルを作ることでした。 ウォーターフォールの提唱者たちは、そのメリットを高らかに喧伝しました。曰く、ドキュメントをしっかり作り込んでからコードの記述を始められる、何を作るのかが事前にはっきり定義される、進捗状況を把握しやすい。 これらは理論上はどれもすばらしいメリットなのですが、ウォーターフォール型の開発をいざ進めてみると、そううまくはいきません。

下流にかかるプレッシャー

ロイス博士は、ウォーターフォール モデルをコンセプトとしては優れていると信じる一方で、現実に実践すると「リスクが大きく、失敗を招く」と考えていました。 このモデルは、柔軟性が低いことで評判 (悪評) だったのです。 問題は、工程を最初からきっちりと順番どおりに行わなければならない点にあります。 テスト工程で得られた気づきを設計工程に反映する余裕はほぼありません。そのせいで、不測の事態が生じず確実で一貫性があるというウォーターフォール開発の本来の目的がかえって損なわれてしまいかねません。これらの特性はいずれも、開発をじっくり着実に進めるために欠かせない要素です。

つまり、ウォーターフォール型の開発は、名前のイメージとは裏腹に、流動性の低い手法なのです。 開発のテンポが速くないため、規模が大きくなると、ソフトウェアならではのスピードを活かしたり市場ニーズの変化に対応したりすることが難しくなります。 スケジュールの厳守が何よりも優先されるため、予定どおりの進捗を維持しようと、大量の先送りが発生し、結果的にデスマーチを招きがちです。

Winston Royce 博士 「ソフトウェア開発は、ただハードウェア開発の手法をマネすればよいわけではない」 — Winston Royce (ウィンストン・ロイス) 博士

ウォーターフォール型の開発が善意で動いていることは、今も昔も変わりません。ただ、ソフトウェア開発の最先端にあるとは言えないようです。 ウォーターフォールの原則を固持してプロジェクトを進めると、結果的に下流の作業が山積みになり、手に負えなくなってしまうケースが少なくありません。 ソフトウェアの世界で言えば、設計や計画に何か月も費やしてから、ようやくコードの記述が始まるような状況です。 開発が終わってみると、できあがった製品が構想当初とまったく別のものになってしまっていることさえあります。

アジャイル開発とウォータフォールの違いとは?

数年前まで、ソフトウェアやプロダクト開発はウォーターフォール開発手法をベースとして管理されていました。ウォーターフォール開発モデルでは、各タスクは段階的に実行され作業が滝のように進行します。これらの各フェーズは個別のステップとして表され、次のステップを開始する前に、前のステップを完了する必要があります。ウォーターフォール型開発モデルの開発工程は、その性質上、一定の予算、限界、時間、品質で完了するというメリットがあります。しかし、現実には顧客から強い不満が寄せられるケースが多かったため、現在ではアジャイル開発手法が多く活用されています。

ウォーターフォールとアジャイルの違いとは?

ウォーターフォール開発手法とアジャイル開発手法の一番の違いは、予測型適応型かということにあります。

ウォーターフォール開発モデルは予測型であり、開発プロジェクトの最初の段階で完璧な計画を立て、プロジェクト開始後に計画を変えることはありません。これに対し、アジャイル開発モデルは適応型であり、計画をすべて事前に決めるのではなく、開発プロジェクトの実行結果に基づいて計画を柔軟に変えながらプロジェクトを進行させます。

予測型 適応型
ウォーターフォール アジャイル開発
開発プロジェクトに変更がないものと想定し、事前の計画通りに進める プロジェクト開発要件に変更があるものと想定し、事実を把握しながら開発プロジェクトを進行させる

ウォーターフォール開発手法のメリットとは?

ウォーターフォールモデルの主なメリットには、以下のものがあります。

  • 進捗状況やスケジュール管理の把握が楽に
  • 予算や限界、納期のわかりやすさ
  • 関係者や参加者の入れ替えが簡単

ウォーターフォール開発手法のデメリットとは?

それでは、次にウォーターフォールのデメリットを確認しましょう。

  • 前提状況等が変更した場合には、計画を立て直す必要がある
  • 製品やサービスに対するテストが行えない
  • 顧客の意見を取り入れるのが困難になる

アジャイルという発想

ソフトウェアはハードウェアの上に作られます。

初期のソフトウェアはハードウェアからポインターを受け取っていました。他に良い方法を知らなかったためです。 したがって、当時のソフトウェア開発では、コードの記述に最適とは言えない開発手法が慣例になっていました。 やがて、世界の変化の速度が速まると、企業は即応性を高める必要に気付きました。

ソフトウェア開発手法を論じる際に、ウォーターフォール モデルはピエロ扱いされることが少なくありません。 それは、最新の手法へ歩を進められない “時代に逆行する伝統主義者” から距離を置きたい者たちの気持ちの表れです。 一方で、ウォーターフォール型の開発が、ある時点では現実解だったのも事実です。ウォーターフォール モデルがベースラインでなければ、試行錯誤しながら未来へ進むことはできなかったでしょう。

どんな道のりにも出発点は欠かせないものです。 このブログ シリーズで取り上げたケースでは、その出発点が、ストレスや過度の緊張を招く時代遅れの手法だったということです。

しかし、その緊張は、次回の記事で取り上げる “アジャイル” というムーブメントで解消されます。お楽しみに!

ウォーターフォールモデル参考情報