MENU

blog
スタッフブログ

dot
開発初期の重要さ
技術

開発初期の重要さ

どうも、ソリューションSecの大浦です。
開発初期の重要さについて書いていこかと思います。

開発モデル

システム開発で一番有名な設計モデルとしては「ウォーターフォール」が上がるのではないでしょうか。
他にも「アジャイル」、「プロトタイプ」、「スパイラル」等などがありますが、今回はウォーターフォールに注目してみます。

ウォーターフォールは要件定義~試験までを順に行っているのですが、基本的に前工程がしっかりとできている前提で次へ進むので、基本的に後戻りできません。
厳密には戻る事が出来るのですが、後になればなるほど些細な変更でも全体に大きく影響してくるので、想像以上の時間を消費することになります。

ウォーターフォールのV字モデル

上記が有名なV字モデルと呼ばれる図ですが、要求分析から始まり要件定義設計コーディング各種試験へと続いていきます。
図からもわかるように各工程に紐づく工程があり、結合テスト基本設計に内容をベースに行い、単体テストであれば詳細設計の内容をベースに行います。
※余談ですが一般的には設計を上流工程、実装や試験工程を下流工程と呼び、上流の方が単価が高く、下流の方が安くなります。
新人の方は基本的には試験から実務経験を積み、試験設計や考え方を身に着けた後にコーディングに進むのが一般的に多いかと思います。これは試験設計や確認するポイントや動作確認に対して重要な部分を知ることで、コーディングの際に動けば良いという考えではなく、バグを生み出さないような実装を意識できるメリットがあります。

少し話がずれたので戻します。
V字モデルからわかるように、設計後に実装、実装後に試験を行う流れになりますが、仮に以下のパターンだとどうでしょうか。
①:設計時に設計漏れを発見した場合
②:試験時に設計漏れを発見した場合

①の場合、設計フェイズで設計を修正する
②の場合、設計フェイズまで戻り設計を修正する、再設計内容を元に実装を修正する、実装修正を元に再試験を行う

圧倒的に②の方が対応する内容が多いですね。
もう少し深堀すると実際はこれだけで済むことは稀で、変更を行ったことで影響範囲も修正する必要が発生し、修正した内容はさらに再試験で確認する必要がある。ドキュメントが厳しい案件場合はドキュメント修正も行わなければならない。
後工程であればあるほど対応内容が倍々ゲームの様になっていき、待っているのは地獄ですね・・・

ちなみに上流工程をいい加減に進めたPJは経験上100%失敗方向に進みます・・・
ただ、完全に上流工程を完了して次に進めることは昨今の開発スピードでは非常に難しくなってきています。
特にUIを使用するWebやアプリケーションでは修正を前提としていたり、機能追加のアップデートを前提としているのでアジャイル開発の方が一般的になってきており、完全にウォーターフォールで開発を行うのは制御、組み込み、基幹システム等の大規模開発に偏っています。

ただ、ウォーターフォールの考えは継承されており、例えばアジャイルの場合は大雑把に言ってしまうと、小さな規模でウォーターフォールを繰り返すイメージなので、根本の重要性は変わりません。
結局上流で手を抜けば、その後に何倍にもなって返ってくることは変わらないかと思います。

そのほかに重要な内容として、V字モデルでは下流工程に行くほど人員が増加する傾向があります。
それは設計を行った後に実装、試験を複数人で行い期間短縮するのが一般的だからです。
下流工程を行うメンバーは設計を元に実装や試験を行いますが、「口頭のみで伝える」、「設計書が文字のみ」、「ドキュメントを残さない」等の伝達部分でも手を抜くと、想定と違うものが完成してしまい、後でまた修正が発生してしまします。これも地獄の入り口ですね・・・

その他に考慮する事

Aさんが一人で要件定義~試験までをトータル3人月で完了できる案件があったとします。
AさんBさんCさんの能力が完全に一緒の3人で同様の案件を行う場合は同様に3人月で完了できるでしょうか?
トータル三人月に近づけることは可能ですが、おそらく3人月以上かかる事が予想されます。

これは他人に対して意思疎通を行う為にはコミュニケーションが必用であり、言葉だけでは足りずに図などを用いて説明するコストが発生するからです。

まとめ

雑にまとめると、いろんな事に共通して言えることですが、できることを後回しにしたり、伝える事や確証を取らずに物事も進めてもいい結果は生まれないってことですね!

では今回はこのへんで。

dot
dot
PAGETOP