和RUPというニセRUPの存在

開発プロセスを設計するという発想
内容そのものは、非常に同意です。ただRUPに関しては誤解があるように思う。
作成フェーズ以降のRUPにおいて開発の軸となるのは「変更要求」。これをインプットにして実装、ビルド、検証していくプロセスは、よくあるバグトラッキングのプロセスと大体同じで、XPのストーリ/タスクカードの扱いと似てるかもしれない。つまり軌道に乗ってしまえばRUPの進め方は派生開発に近いはず。変更管理はRUP*1の最重要プラクティスのひとつだし。
ただソースコードゼロの段階からバグトラッキングを初めてもあまり効果ない。その後の機能追加をバグトラッキング感覚で扱えるレベルになるまで、プロジェクトの骨組みを作る必要がある*2。この骨組みをベースラインと呼び、推敲フェーズ終了時点でベースラインを作成していることが重要なマイルストーンになる。ここがRUPのアーキテクチャ重視と呼ばれる部分で、XPとの大きな違いだと思う。
で、、、
日本のSIer(あー、うちもそうだな。。)がRUP準拠を僭称する場合に、変更管理や構成管理の視点ががっぽり抜け落ちているものが多い。しかも推敲フェーズ終了時点でモデリングまでしかやってないとか、作成フェーズが実質一回しかないとか、全然意味ねー。
ウォーターフォールの悪い面だけ受け継ぐみたいな感じで、本来のRUPとは全然違うニセRUPだと思う。RUPの元ネタ見る機会もあまり無いし、やっぱ分量も多く読みきれないので、誤解が広がるのもしょうがないのだけど。
とりあえず和RUPということばを提唱して、本来のRUPと区別して呼びたいところです。
(本エントリはかんのの個人的な見解につき勤務先とは以下略)

あわせて読みたい

RUPのオープン版最小限サブセットのOpenUP/Basic
The Rational Edge　プロジェクトに1人で果敢に取り組んだあるプロジェクトリーダーの日記

THE BEST of mihimaru GT

*1:RUP2003ぐらいまで

*2:とRUPでは考えてる