| [ Home > Academic > R&D > Waterfall ] |
Waterfall: Development Process (3/30/99)
開発プロセスの名前です。あまりにも有名でしょう。ウォーターフォールモデル。R&Dの一環として、マイクロソフトを取り上げたのですが、その戦略論のキーワードのひとつとして、その「開発手法」 (Development Process) が取り上げられました。
ウォーターフォールモデルはソフトウェア開発業界では常識です。しかし、ここでは、すでに過去の歴史を学ぶかのような扱いです^^; いや、確かにそれは日本でもそうなのですが、ちゃんとその特性をマネージメントの観点から、その向き不向きを明確に議論している。。というところがいかにもアメリカらしいです。
ウォーターフォールモデル (Waterfall Model)
ここで、ウォーターフォールに馴染みのない方のために簡単に説明しましょう。
ソフトウェアの開発というのは、ユーザニーズや、企画、マーケティングから事の端を発し、そのソフトができあがるまでの作業の事を言います。ユーザのニーズなど、開発に要求される項目を「要求仕様」 (Requirements) といいます。これはたとえばブラウザを例をとるなら、「ブックマーク機能が欲しい」など、かなり大まかなレベルです。これを逐次詳細化していきます。そしてプログラミングします。 implementation といいます。できあがったプログラムには100%絶対バグが入っています。ですから、ここでデバッグ（試験）というバグ取り作業を行います。このデバッグという作業は、先ほどの要求仕様とは、逆に、細かいところから試験していき、最後に全体試験を行います。
- 要求仕様策定 Requirements Specification
- 詳細設計 Detailed Design
- 単体コーディング、デバッグ Module Construction & Debug
- 統合・試験 Integration & System Test
- 出荷 Ship
という手順です。この工程の系列が、水が流れ落ちる様子に似ているところから、ウォーターフォールと呼ばれます。
ウォーターフォールの是非
この開発手法には大きな特徴があります。とくに技術革新や、マーケットの動きの昨今にあっては、この手法の最大の問題点は、
多くの手順を逐次踏むため、開発に時間がかかる。（期間の問題）
ということです。時間・期間というのは相対的に語られるべきです。ソフトウェア開発が始まった頃、たとえば30年前には、誰も、これは時間がかかる方法だ、などと言わなかったでしょう。ここで時間がかかるというのは、言うまでもなくマーケット側のスピードです。マーケットの動きが激しすぎて開発が追いつかない。。今までの方法じゃだめだ。。。というわけです。
ただし、全部が全部だめだという訳ではなくて、いまだ非常に適している分野も存在します。
Works fine with stable product requirements and products whose complexity (interactions of components) is relatively well-understood.
と言われています。STABLE。つまり製品に対する要求仕様が確固としていれば、ウォーターフォールは力を発揮するというのです。具体例として出されたのが、
メインフレームやミニコンピュータのオペレーティングシステムやアプリケーション。特に、IBMや米国政府、国防省や日本のようなStable Market！
ほう？なるほど。日本はマーケットとしてはよほど動きが遅いように写っているようです。確かにアメリカのダイナミズムから比べればその通りかも＾＾；
超安定したシステムのバージョンアップ。旧来の通信用交換機や交通機関。
ここで通信交換機は、conventional telecom switching です。＾＾； インターネットに代表される最近のネットワーク機器はもはや、この範疇には入りません。
逆にこのウォーターフォールがだめな場合。
要求がよくわからない（新しすぎて、あるいは複雑すぎて） 外部仕様が、内部仕様変更や、利用者の入力や、世の中の技術革新や、市場競争に影響を受けてしまう場合。つまり「変化」するものはだめ。 開発がサイクルが長すぎて設計変更が入る場合。（よくある^^;） 具体的な例としては、
パソコンのオペレーティングシステムとアプリケーション。 パソコンのアプリケーションや、最近の通信システムみたいに、安定を求められてるけど、実は強烈な市場競争にさらされているもの。 ニュアンスが伝わるでしょうか。もうだめなんです。上記のような業界では。ウォーターフォールは使い物にならないと、大学院マネージメントスクールで教えているのです。
開発現場からは、「そうはいっても。。。」という言い訳も聞こえそうです。＾＾；
既存開発人員のノウハウ。ドキュメント仕様。手法には多くの標準化が伴います。多くの人間が携われば携わるほど、こういった標準化なしでは開発の効率化は不可能ですし、いまさらそれを変えろといわれても。。。
簡単です。この際、言い訳が深刻かどうかは問題ではありません。そういう言い訳をしているところは、死ぬだけ。。市場から消えていく。ただ、それだけです。
マイクロソフトのやり方 N+1 モデル
もう1994年といいますから、今から5年も前の情報ですので、最近はまた違うかもしれません。しかし具体例を目の当たりにすると、結構興味深いので参考までに記しておきます。
"N+1" Development Process と呼ばれるやり方で、大まかには以下の手順を踏みます。このステップをだいたい12ヶ月から18ヶ月で回します。
- Vision Statement - Product & Program Management によるまぁ、青写真という感じでしょうか。
- Specification Skeleton - ここでカスタマサポートや開発者からの意見を取り込みます。機能的な概略設計。
- Development Schedule & Feature Team Formation - どんなに大きくても Program Manager 1人、開発者 5人、テスター5人。プロジェクト全体のスケジュールや昨日項目までかなり細かく設計します。
- Phased Development in 3 or 4 Milestones - 設計、コーディング、デバッグ。テスターは開発者とペアを組みます。実際の開発です。
この4番目の工程の中身は以下のようになります。
Milestone 1
Development (Design, Coding, Prototyping) Usability Lab ユーザインタフェースはやはり専門家がいる模様 Nightly Builds コンパイルに一晩くらい。。。かかるんでしょう^^; Private Release Testing Code Complete Feature Debugging Feature Integration Code Stabilization (no more Severity 1 bugs) Buffer Time (eg. 20%) 予備 (以下同様です)
Milestone 2
Development (Design, Coding, Prototyping) Usability Lab Nightly Builds Private Release Testing Code Complete Feature Debugging Feature Integration Code Stabilization (no more Severity 1 bugs) Buffer Time (eg. 20%) 予備 Milestone 3
Development (Design, Coding, Prototyping) Usability Lab Nightly Builds Private Release Testing Code Complete Feature Debugging Feature Integration Code Stabilization (no more Severity 1 bugs) Buffer Time (eg. 20%) 予備 (ここまできたら、後は出荷に向けた総合試験です)
Alpha & Beta Test Final Debug / Stabilization Ship マイルストンは、盛り込み予定の全機能の1/3とか、2/3とか、その盛り込み量によって設定している模様です。なんとなく、Internet Explorer の開発の様子が目に浮かびます。膨大な機能盛り込みリストを元に、小さいサイクルでマイルストン開発を繰り返していく。。
最終的には、α、βテストを通して市場のフィードバックも。
Usability = 操作性に関しては、やはり専門家チームの存在が伺えます。アプリケーション間での統一性や、モデルとなる操作パターンの蓄積など、ソースコードよりもこちらの方のノウハウの方が価値があるかもしれません。
Buffer Time。果たしてこの考え方は日本で通用するでしょうか。ソフト開発業界の人間は、ソフトのリリース時期がよく延期になることは知っています。当初予想も付かなかったいろんな事が発生します。このタイムラグを思い切って、Buffer Time として割り当てるあたりに、潔さというか、いい加減さを感じます^^;
