ウォータフォールモデルの起源と言われた1970年の論文を読んでみた

　最近はソフトウェア開発に強みを持っているわけではないチームで仕事をしている。個人としてはなんちゃってウォーターフォール、なんちゃってアジャイルで開発している風に感じられる。プロジェクトの特性に合わせて開発プロセスを改善しているという感じでもなく、これまでのやり方で開発まわっているからそこを踏襲していると（個人的に）感じられた。いわゆるウォーターフォール対アジャイルとか、Spotifyモデル [※1] とかと言っているがそれらの特徴は理解しているつもりである。一方で、どのような過程を経て生まれてきたものなのか時代背景まで含めてちゃんと説明できるか、と言われると正直自信がない。アジャイルソフトウェア開発宣言が出たのも 2001 年と 20 年前である。  90 年代はまだテストコードを書くことが一般的でなかった（今でも書いていないソフトウェアを複数見たことはあるが）頃である [※2] 。ウォーターフォールの元となる概念が提唱されたのはそれからさらに 30 年も前の 1970 年である。 C 言語が登場したのが 1972 年なので今とは大きく事情が異なるのが容易に想像がつく [※3] 。

　2021 年にもなって半世紀前である 1970 年の論文かいとは思いつつも読んだのでゆるく内容をまとめておく。 IEEE WESCON に収録された "Managing the Development of Large Software Systems" というタイトルの論文である。著者の Winston W. Royce は TRW の航空宇宙局のプロジェクトマネージャーをしており宇宙船開発に関わっていた。時代を考えるとアポロ計画に関わっていたのかと思われる。脱線とはなるが、アポロ計画で活躍したアフリカ系の女性科学者を描いたドリーム（原題： Hidden Figures ）という映画は非常に面白いのでおすすめである。

　閑話休題、当該論文は "Managing the Development of Large Software Systems" というタイトル（翻訳すると巨大なソフトウェアシステムの開発管理）からわかる通り、巨大なソフトウェアの開発する上での方法論を記載している。現代で言われているいわゆるウォーターフォール型開発とは乖離がある。内容をまとめると以下の通りとなる。

・システム開発は分析と製作という2ステップに分けられる。
・開発者と使用者が同一人物ならうまくいくかもしれないが、この2ステップだけで巨大なソフトウェアの製作をすれば失敗するのは目に見えている。
・分析と製作ほど最終成果物に直接的に寄与しないが、他にも複数の開発ステップ（要求分析、設計、テスト、運用）が必要である。
※いわゆるよく見るウォーターフォールの図
・それらの開発ステップは反復することもあるし、テストから設計のように時には2ステップ前に戻ることもある。
・このやり方はリスキーで、テストフェーズで動かし始めて問題に当たると大規模な再設計または要件変更が発生する。
・リスクを減らすのに 5 つの方法を提示する。
・分析の前に予備設計を実施し、間違っているリスクを負ってでも機能やデータベースなどなどの設計を行う。これによりテストフェーズでの再設計を防止する。
・かなりの量のドキュメントを作成することを徹底する。これにより、認識の相違や進捗の管理（例えば常に 90% 完成していると報告する人とか）が適切に行われる。
・ 2 回作成する。ミニチュアの試作版をまず作ることで、判断に迷う部分の正確な検討、開発スケジュールの見積もりが立てられる。
・テストの計画、管理、監視を行う。テストフェーズでこけることがコスト面でもスケジュール面でも最大のリスクである。そのため、予備設計や豊富なドキュメントの作成、試作品の作成を行うことで問題の早期発見を試みている。テストの設計はテストの専門家が行い、エラーかどうか目視で確認し、全ての論理パスは最低一度は行う必要がある。
・カスタマー（納品対象者）を巻き込む。事前に合意した後でも解釈が分かれることがあるので、出荷前の早い段階からカスタマーを巻き込む必要がある。
・全部をまとめた図が本記事の見出し画像である。

　なんということであろうか！　この当時から試作版を作ることが推奨されており、 MVP (Minimum Variable Product) に近い概念が提唱されている！　そしてウォーターフォールという単語はまだ作られていない！

　現代ではあまり考えられないが、当時は計算資源の事情で発生している出来事もある。例えば、テストフェーズでの再設計の話だ。まとめには雑にしか書いていないが、ストレージが足りないとか I/O の要件を満たせない。などだ。もちろん現代でもそのようなことは起こり得るが、全く新しいソフトウェアのリリース時点でストレージが足りないことはあまり考えられない。あるとしたら大規模データを対象としたソフトウェアだろうか。

　他にもテストは目視で行うことや全ての論理パスを通すことは現代ではむしろアンチパターンである。

　ドキュメントを大量に作成するのもまた現代とは異なる。依然としてドキュメントは大事であることは間違いないが、変化が多い現代ではそのメンテナンスコストとの兼ね合いになる。現代でもそれこそロケットや原子炉のような仮説検証を試すことが許されないようなシステムではやはりドキュメントを徹底して進めていくかと考えられる。著者には知見がなく予想でしかないが、もしかするとシミュレーションでだいぶ進められるかもしれない。これはこれで今なお一つの大きなテーマである。

　まとまりがなくなってきたが、手法一つとっても古い原点となる論文を読むと、その思想に触れ、現代に通じるものと現代とは異なるものを考えると学びにはなるものだ。まる。

脚注

※1　ユニコーン企業のひみつを読んだばかりなので、この言葉を使いたかっただけ。

※2　リファクタリングで Martin Fowler も、 Clean Code で Bob Martin も、 Coders at Work で Joshua Bloch も 90 年代当時はテストは手動で確認するものだったと述べている。

※3　この当時の言語を調べてみたところ、著者が名前を聞いたことのあるは FORTRAN ALGOL58 COBOL LISP Simula である。 LISP は流石である。余談であるが、著者が初めて触れたプログラミング言語は LISP の方言である Scheme だ。