━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■第22回 ソフトウェアのプロセスモデル（前編）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
システム開発には様々なリスクがあります。
度重なる仕様変更、技術不足、納期の変更などによって、品質や収益が確保
できなくなることがあります。
プロジェクトは一旦崩れだすと、なかなか元に戻すことができず、ずるずる
と泥沼にはまってしまいます。
その様子を、デスマーチ（死の行進）と呼ぶ人もいます。
そうならないようにするために、ゴールを明確にします。
その上で、ゴールまでの過程をタスクに分け、メンバーの割り当てやスケジ
ュールを考えていくことになります。
それは、戦国時代の戦（いくさ）前に行われる評定（ひょうじょう）に似て
いるかもしれません。
すぐれた武将がどれだけいても、戦略がなければ相手の策に嵌り、なかなか
勝つことはできません。
システム開発も同じで、優れたエンジニアがいたとしても、度重なる仕様変
更に振り回され、膠着状態になっているプロジェクトを見かけます。
それでも納期は変わらないことが多いので、最後は優秀なエンジニアが力づ
くで解決しなければならなくなります。
結果としてプロジェクトは無事に終わったとしても、メンバーの増員や残業
のため、利益が出ないどころか大赤字なんていうこともあります。
せっかく頑張っても、これでは報われないですよね。
●ソフトウェアのプロセスモデル
とは言っても、戦略を立てるなんて誰でもできる訳はありません。
技術者とは要求される能力が全く異なるからです。
そんな状況を考え、有能な学者さんが研究し、編み出したプロセスモデルが
あります。
ソフトウェアプロセスモデル、開発工程モデルなどと呼び方は様々ですが、
ほぼ同義語なので、ここでは「ソフトウェアプロセスモデル」とします。
今回、次回と２回に分けて紹介していきたいと思います。
●ウォータフォールモデル
最もよく使われている手法です。
文字通り、滝の水が上から下に落ちてくるように、後戻りせず、順番にタス
クを進行させていきます。
大きく分けて、要求定義→システム設計→プログラム設計→コーディング→
テストという流れになり、各フェーズごとに完了基準を設けます。
・要求定義 … 発注者の目的を明確にし、ソフトウェアの機能・対象範囲
を決定します。
・システム設計 … 要求された機能をどのように実現していくかを決定し
ます。他システムとのインタフェースなども検討します。
・プログラム設計 … それぞれの機能をどのようにプログラミングしてい
くかを決定します。技術が実現可能かも確認します。
・コーディング … 設計書に従って、プログラムを作成します。
・テスト … 要求が満たされているかをチェックします。
上記の説明からも分かるように、上流の工程で作成された成果物に従って、
次フェーズが行われるため、上流工程の完成度が重要になってきます。
各フェーズは後戻りすることはありませんので、要求定義での漏れがあると
下流工程で予想以上のコストが発生する可能性があります。
多くの失敗プロジェクトでは、要求定義で要求が固まらないまま、下流工程
に移行していることが原因となっています。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━