【インフラエンジニアブログ】ウォーターフォール型の設計構築とは

こんばんわ。
齋藤です。

昼職の忙しさにかまけて長らく書けていなかったのですが、とにかく何か書かないと！と。
という事でnoteの入力フォームまでたどり着きました。

という訳で今回はウォーターフォール型の設計構築とはなんぞや。
という所に焦点を当てて書いていきたいと思います。
最近、現場で明らかにウォーターフォール型で開発したこと無さそうな人が書いた設計書を見たのですが、見てて辛くなったのです。
何が辛いか。
基本設計フェーズだったのですが、
"基本設計書にディスクサイジングの具体値やパラメータなどが平気で山ほど書いてあった"のです。
ここで、あーウォーターフォールなのにそれはアカンわ。とピンと来る方は正しい感覚の持ち主です。
そんな基本的な事知ってるわ！今更何を言ってんの！！って人は閉じてもらって大丈夫です。すいません。
何がダメなの？？となった方は、これ以降の文章も読み進めてみて下さい。
きっと今後役に立つはずです。

これはウォーターフォールでの開発をやった事ない人が最近、ひょっとして多いのでは？と思ったので書いてみます。
少しでも参考になれば幸いです。

ウォーターフォール型とはなんぞや

そもそもウォーターフォールって何のこと言うてるの？

ウォーターフォール・モデル - Wikipedia

Wikipedia抜粋
概要
プロジェクトによって工程の定義に差はあるが、開発プロジェクトを時系列に、「要求定義」
「外部設計（概要設計）」「内部設計（詳細設計）」「開発（プログラミング）」「テスト」
「運用」などの作業工程（局面、フェーズ）にトップダウンで分割する。
線表（ガントチャート）を使用してこれらの工程を一度で終わらせる計画を立て進捗管理をする。
原則として前工程が完了しないと次工程に進まない
（設計中にプログラミングを開始するなどの並行作業は行わない）事で、前工程の成果物の品質を確保し、
前工程への後戻り（手戻り）を最小限にする。
ウォーターフォール・モデルの利点は、工程の進捗管理がしやすいことである。

要するに手戻りせずに一つひとつ工程を進めていくプロジェクトの進め方になります。
簡単な図を書くと以下の様な形です。

オンプレミス環境の場合、後からCPUやメモリなどのリソースの追加は簡単には出来ない為、案件当初からきっちり必要なリソースを見積もって決めていく必要があります。
その為、ほぼウォーターフォール型の開発になると言っても過言ではありません。
オンプレミス環境のインフラ構築は必ずウォーターフォール型になる。
これを覚えていて下さい。

そして、先ほどの一文をもう一度読んでみましょう。
"基本設計書にディスクサイジングの具体値やパラメータなどが平気で山ほど書いてあった"
基本設計書は言うまでもなく基本設計フェーズで作成する物です。
では、ディスクのサイジングや具体値、パラメータなどはどこで決めるべき物でしょうか。
正解は詳細設計フェーズとなります。
設計フェーズの住み分けですが、

〇基本設計：ポリシーの定義
〇詳細設計：基本設計で定義したポリシーに従って、各MWやOSのどの機能を使って実現するかを定義
〇パラメタ設定書作成：詳細設計定義した機能を使用する為の設定パラメータに落とす。
〇構築：パラメタ設定に従って設定する。

となります。
基本設計書にパラメタ設定値を書くという事はこのフェーズを2つ分飛ばしていると考えて下さい。
では何がまずいのか。
基本設計の合意も取っておらず、詳細設計の合意も取っていない中、パラメータまで書いているのです。
レビュの結果、方針が変われば全て書き直しになります。
テストの結果、パラメータを変更する必要が出た場合も同様です。

また、仮に奇跡的にレビュでもテストでも全く問題が無くパラメタを変える事も無く無事にサービスイン出来たとします。
しかし、その後、運用していく中で設定変更や追加となった場合に、基本設計書から全てのドキュメントが修正となってきます。
運用フェーズでの設計書修正工数も嵩むドキュメント構成という事になります。
ここまで読んで頂くとわかるかと思いますが本当に百害あって一利なしなので、そういう基本設計は辞めて頂きたい・・・というお話でした。