ウォーターフォールモデルは，設計～実装～検証までのプロセスを，下図に示すような，大きなシステムを分解しながら詳細な部分までの設計を行い，それら詳細な部分の検証を確実に行いながら，規模を大きくし，最終的なシステムの検証を行うと云うプロセスで，各規模での設計が各々検証に対応しており，Ｖ字を示すことからＶ字モデルと云われている。
■プロジェクトマネジメントの応用 １０（ソフトウェア開発編）
◆ソフトウェア標準（Ｖ字モデル）プロセスを実施する
①ウォーターフォールモデルとは？
ソフトウェア開発には，ウォーターフォールモデル，反復型，アジャイルモデルと言った開発プロセスがあり，従来はウォーターフォールモデルでの開発が中心だったが，変化が激しくリスクを最小にすることから反復型，或いは最近ではアジャイルモデルといった計画重視よりも，変化に対応できる適応型開発が進んできている。これらには一長一短の特長があり，ここでは，ソフトウェア開発の基本であるウォーターフォールモデルについて述べる。
ウォーターフォールモデルとは，言葉通り「滝」で水が落ちていく様を示し，ソフトウェア開発が順序立てられ，各工程毎に確実に終え，次の工程へ進んで行く。つまり，前の工程で確実に問題が無いように作られていることを前提に進められるために，前工程に問題があると後戻りが発生する。前工程が完全な出来映えになることは皆無に近く，後戻りは殆ど発生することにはなるが，確実なもの（と思われるもの）を後工程へ渡すことは品質の基本であり，このスタイルでの開発が続けられている。
一方で，反復型やアジャイルモデルと云った月単位や週単位で検証しながら進める方法もあり，リスクを最小に確実に進める方法としてはこれらの方法が好んで使われることもある。月単位や週単位と短期間でのフィードバックが掛かる方法であるが，基本は短い単位でウォーターフォールモデルを行っていることである。従って，ウォーターフォールモデルでの開発を基本的に理解し，習熟しておかないと，いい加減な，曖昧なやり方で開発を進めることが当たり前（習慣化）になってしまうことで，反復型やアジャイルモデルでも，計画通りになかなか進まないことがあるので注意したい。
②ソフトウェア標準プロセス（V字モデル）とは何か？
ウォーターフォールモデルは，設計～実装～検証までのプロセスを，下図に示すような，大きなシステムを分解しながら詳細な部分までの設計を行い，それら詳細な部分の検証を確実に行いながら，規模を大きくし，最終的なシステムの検証を行うと云うプロセスで，各規模での設計が各々検証に対応しており，Ｖ字を示すことからＶ字モデルと云われている。
③なぜ，V字モデルが重要なのか？
大きなシステム開発を行う場合，システム全体を把握した内容理解と共に，それを詳細に分解できるスキルを必要とされる。つまり，大きなシステム開発は一人ですべてできる訳ではないので，多くのメンバーの協力を必要とする。従って，システム全体の要求仕様をシステム仕様として設計されるものに変換しなければならない。次に，システム全体の仕様を機能仕様や制御仕様として分解し，各コンポーネントに落とし込み，さらにはその部分の詳細設計をして，実装即ち，プログラムとして書き下すことになる。このように大きなシステムから，順次確実に，漏れの無いように設計して行くことが求められ，各々の工程は，前工程が正しいものとして受け継がれてプログラムされる段階へと進む。
プログラムされたものは，テスト・検証されるのであるが，ここでは個々に分解された逆の経緯を遡ることになる。先ずは単体テストと呼ばれる最小のユニット単位で検証され，各々ユニットの品質が担保されて次のユニット同士を結合するテストへと進む。結合されたコンポーネントがさらに規模が大きくなった機能としてテストされ，各機能の働きの品質が担保され，全体のシステムテストへと進んで行く。
ここでの各工程のテストであるが，テストの直前にどのようなテストをするかを検討するのではなく，各工程の設計段階でテスト内容も検討される。つまり，詳細にブレークダウン設計すると同時に，出来上がったものをどのように評価すべきかを検討しておくことが重要である。何故ならば，どのような評価をするかは出来上がったものから考えるのではなく，求められる全体システム，即ち，上の機能からどのような評価が必要か見定めなければならないからである。そうしないと，下から（詳細な部分から）出来上がったもので検討していては，全体が判らないまま部分最適で検証してしまうリスクがあるからである。
もちろん，下から（詳細な部分から）は確実な品質が検証されているものでなければならないことは当然である。良品同士を組み合わせることは品質確保の基本中の基本である。組み合わせしてから品質を確認するやり方は，単体の品質が担保されていないと，問題が生じたときの解決に時間を浪費することは先人が教えている。（単体テストでのバク対策とシステムテストでのバグ対策では，後者の方が４０倍から100倍も時間を要すると言われている）
この図から判るように，評価する部隊も設計完了からではなく，設計段階から参画して，テスト工程を確実なものにすることが品質確保には重要であると共に，テスト日程短縮にも有効なことが判る。もちろん，設計段階で参画する評価部隊は，キーマンになる人が入れば十分である。
④どのように実施するか？
上図からも判るように，大きなシステムの要求仕様を満たすために，自分たちが開発設計するシステム仕様に置き換え，それを機能単位，制御単位に分解することから始まる。ここで重要なことは，確実に分解することで，当にＭＥＣＥ（Mutually Exclusive and Collectively Exhaustiveの略）に，つまり漏れなく，ダブリ無く分解することである。
全く新規のシステムの場合，ＭＥＣＥを実現することは容易なことではないが，全体をしっかり把握してリーダが率先して実施し，それをメンバーで，抜けが無いかどうか確認することになる。既存のシステム開発の経験があったり，似通ったシステム開発の経験がある人に参画して貰って，進めることも大切なことである。なぜなら，前工程の抜け，漏れの発見が遅れれば遅れるほど，後戻りの工数が増加し，スケジュールに大きく影響を及ぼすリスクが高まるからである。
開発のプロセスとしては，次の章で示すレビューとセットで実施することが必要で，品質確保などプロジェクトの成功に向けて重要な役割を果たす。
⑤アジャイルモデル
全体システムのまとめがある程度進まないと確実なものにならない，或いは，状況変化が激しく当初計画だけでは出来上がり成果が期待通りにならないなど，従来型のウォーターフォールモデルでは成果が芳しくないことが予め予想されるプロジェクトもある。そうした場合，設計・検証を繰り返し早く廻すことで期待通りの成果を得ようとする反復型，アジャイルモデルなどのやり方が行われている。アジャイルモデルのメリット・デメリットは他のところで詳細に述べられているのでここでは省略するが，プロジェクト・マネジメントとしての基本形はウォーターフォールモデルと思う。
プロジェクト・マネジメントとしては，プロジェクトを如何に成功させるかであり，アジャイルモデルでの早い段階で形を見えるようにして顧客要求とのズレを無くすことは上手いやり方の一つではある。だからと言って，何でもアジャイルモデルで進めると，いずれ変更があるとか，後で見直しすれば良いと計画段階での検討，ドキュメントでの検討が疎かになるリスクがある。結果的にプロジェクトのシステムの決定がなかなかできずにズルズル延びたり，ステークホルダーの要求がころころ変わり膨大な費用が掛かるような結果になることもある。
アジャイルモデルを最近のやり方で優れたやり方と見る前に，プロジェクトマネジメントとして，ウォーターフォールモデルを確実に実施できるスキルを付ける方が賢明であると考えている。つまり，計画がしっかり立てられ，ドキュメントが確実に設計できることが最初にありきで，その応用としてプロジェクトの内容によってアジャイルモデルで開発を進めると云うのが，技術者としての取るべき道であると感じている。
[Reported by H.Nishimura 2011.08.22]
Copyright (C)2011 Hitoshi Nishimura
