設計の話『ウォーターフォール』

こんにちは、松本です。

設計について書くと言いつつすっかり間が空いてしまいました。

今日は、普通に設計の話を書きます。

伝統的な設計モデル『ウォーターフォールモデル』では、システムの設計を下のようなステップで行います。

水が流れ落ちるように上から順に設計と開発を行うのでウォーターフォールと言います。

１．要件定義

どんなシステムを作るのか？どんなハードウェアで動かすのか？
開発期間、金額、開発者の数、などなど開発の『前提』を決める段階です。

業務をシステム化する場合は実務を行っている人に聞き取りをして、どういう機能や流れが必要なのかを定義します。

システム開発においていちばん大事なのは要件定義なのですが、見積もりと混同されたりして軽視されがちです。

概要設計に進むには顧客の承認が必要です。

２．概要設計

システム全体は複数のサブシステムやプログラムに分かれたりします。画面も複数出てきます。
そのような、各サブシステムや画面の構成、データの流れや連携の仕方を決めるのが概要設計です。
一部では外部設計とも呼ばれます。

詳細設計に進むには顧客の承認が必要です。

３．詳細設計

各プログラムの動作、流れを詳細に決める段階です。

ここまで来たらほとんどプログラムを書くのと同義だったりするので、個人的には詳細設計は無駄だと思っています。

だって、プログラムを書いちゃったほうが早いし。プログラムにしちゃったほうが間違いを見つけやすいし。

設計はWordやExcelで作りますが、頭のなかで動かしての内容なので、大体大量のバグを生みます（だから無駄だと思うんですよね）。

一部では内部設計と呼ばれます。

実装に進むには顧客の承認が必要です。

４．実装

設計が終わったらいよいよ実装です。設計を元に画面を作りプログラムを書いていきます。

基本的に、設計には大量の問題が隠れているので、それが一気に火を噴きます。

問題は、バグがあることではなくそれを修正するにはウォーターフォールを遡らなければいけないことです。

遡って修正すると下の段階に多大な影響を及ぼします。

詳細設計のミスならまだマシで、概要設計に問題があって必要な機能がごっそり抜けていたりすると大変です。

概要はもちろん詳細設計も直さなければいけませんし、もちろん実装済みのコードにも影響を与えます。

無間地獄です。

５．テスト、バグ修正、リリース

このような地獄をくぐりぬけ、果てしないテストとバグ修正の先にリリースがあります。

ある者は家に帰れず、ある者はカフェイン中毒になり、ある者は去ります。

過去、ウォーターフォールの大波に押し流された多くのプログラマーは、この設計モデルを呪って死んでいきました。

誰が悪いのだ！

ウォーターフォールだ！

こんな、間違いに対する耐性の低いモデルを生み出したやつに死を！

ウォーターフォールに変わる新しい設計モデルが必要だ！

プログラマーたちはフランス革命の民衆みたいに叫びました。

「バグが嫌ならプログラマーを辞めればいいじゃない」と言ったマリー・アントワネットは斬首されました。

そうして生まれたのが『アジャイル』です。

次回はアジャイルについて書きます。