「ウォータフォールモデル」を超えた「エクストリームウォータフォール」 #agileto2010
Agile Tour Osaka 2010の長瀬さんの講演で印象的だったのは「エクストリームウォータフォール」という言葉でした。たぶん、ウォーターフォールモデルをベースにして「極めたプロセス」なのだと思います。
アジャイルとかウォータフォールの議論で「言葉の定義」の問題はウォータフォールにもあります。
元々、ウォータフォール(滝)と言うのはプロセスをモデル化したものです。モデルと言うのは、細かなところはそぎ落として主張したいところだけを単純化して示したものです。
ブルックスさんの「人月の神話」を読むと良く分かります。この本の中でブルックスさんは、「一つは捨石にするつもりで」と言うのは誤りだったとしています(P.256)。そして、ウォータフォールモデルでは各工程が1回だけであることを仮定していることが誤りで、漸増的モデルの方が優れているとしています。
これは間違いなくそうです。初期開発だけで終わるソフトウェアがほとんどなく、毎年のように保守という名のバージョンアップが繰り返されている現実からも、開発は一度だけで済むわけがありません。
この漸増的モデルは「アジャイル」を含みますが、アジャイル「だけ」ではありません。「1回だけ」という形だけを示したモデルに対応するのは「繰り返し」だからです。
この議論は明確で多くの人が賛同できるでしょう。モデルとモデルを、比較しているからです。
モデルでアジャイルと比較するなら、例えばスクラム本
の2段ループのモデルでなら明確な比較ができるでしょう。このモデルでは、全体の流れの中で、スプリントや日次スクラムを繰り返すことによって、「コミットメント」と「集中」が実現できるという議論ができると思います。
さて、長瀬さんの「エクストリームウォータフォール」は、モデルではなく日本式開発法と言うべきものです。問題点を示すための表現である「ウォータフォールモデル」をベースに、管理の強化によって問題を解決する日本式の開発法を示しておられるからです。
昔は「仕様の凍結」などという言葉があり、それが「ウォータフォールモデル」をベースにした際の前提でした。しかし、凍結は現実的でないので、ベースライン+変更管理が行われたのでした。ルーツは仕様の凍結ですから、変更が容易なわけはありません。
(このようなプロセスの特性はウォーターフォールモデルではないので、ベーム先生の本
では「規律(Discipline)」と呼んで、アジャイルの特性である「アジリティ(Agility)」とバランスをとるように提案したのでしょう。)
「エクストリームウォータフォール」は、1回だけの工程を成功させるためにわざと手戻りさせます。レビューや工程会議などで検査して問題が見つかれば、もう一度やり直しになって品質は向上するものの計画が遅れる方法です。手戻り工数をあらかじめ見積もることができれば計画通りに進む可能性はあるのですが、効率は良くないでしょう。
そのようなプロセスに、日本の企業がこだわる理由の一つは「品質」それも「信頼性」です。プロセスが計画的に行われるので、定量的な管理が可能になり、ソフトウェアの信頼性を飛躍的に向上できます。
講演の中で長瀬さんは日本に比較して欧米7割品質、中国3割品質と言われていましたが、実はもっと差があります。
先日亡くなられたハンフリーさんのTSPの本「ソフトウェアでビジネスに勝つ
」pp.75-76のテラダイン社のデータでは、最終システムテストとフィールド保守では、20欠陥/KLOCでしたが、TSPによって1欠陥/KLOCに改善したとあります。以前、秋山義博先生にうかがった時には、
「システムテスト後だと0.1欠陥/KLOC以下でないとはずかしい」
と言われていましたので、欧米は1割以下の品質ということになります。
長瀬さんが言われたように、そのような高信頼性を生み出していたのですから、アジャイルの導入が難しいと言うのはその通りなのでしょうね。
信頼性の低いソフトウェアは後々多大な被害をもたらします。しかし、実際のビジネスは変わりつつあります。ブルックスさんは利用者にとっての「扱いにくさ」を挙げていますが、信頼性以外のもの、使いやすさ、短納期、魅力的な機能などが求められたときに、ビジネスにならない可能性が出てきます。
では「エクストリームウォータフォール」で信頼性をほどほどに下げて、他の競争力を上げることができるかと言うと、なかなか難しい。そこで、アジャイルに目が向いていると思います。
長瀬さんはスクラムを言われていました。管理の視点が含まれているので、実際に多くの企業が使われているようです。
しかし、そのような動きに乗れないところで身を守るには「リーン開発
」と「チケット駆動開発
」ではないかと、とんでもプロジェクトの中でもがきつつ考えている今日この頃です。
« アジャイルの定義 #agileto2010 | トップページ | アジャイルプラクティスの副効果 »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
コメント