DADとラショナル統一プロセス(RUP)の比較(パート1)

先日、私(訳注:Mark、DAD本原作者の一人)が初めての顧客とDADについて議論していた際、DADはRUPのアジャイル版なのか? という質問を受けた。ひと言でいえば、ノーである。DADは以下の図にあるように、複数の手法やプラクティスのハイブリッドで構成されたフレームワークである。ここには、スクラム、エクストリーム・プログラミング(XP)、アジャイル・データ&モデリング、そしてもちろん統一プロセス(UP)も含まれる。DADにはまた、これらの手法では示されていない、アジャイル・ガバナンスのような追加部分も含まれる。この図を見ていただければ分かるように、DADに最も大きく寄与しているのは、UPではなく、おそらくXPだろう。

hybrid-of-methods11

ラショナル統一プロセス(RUP)は、主に反復的なライフサイクルでのソフトウェア構築を想定し、扱いやすい小さなプロセスフレームワークとして始まった。しかしその後、ラショナル(そして後にはIBM)は、パッケージ実装、保守プロジェクト、J2EEや.Netのような技術特化のガイド、システムエンジニアリングなど、あらゆる種類のプロジェクトにRUPの適用可能性を拡張するべく、付加的なガイドや成果物を徐々に追加していった。結果として、重すぎて扱いづらく、正しく理解して適用するのが難しいプロセスとなってしまった。事実、RUPはしばしば間違って使用される(例えば、推敲フェーズがBRUF – “最初にまとめて要求定義する” フェーズとして扱われる)。このような誤った使い方を、Julian HolmesはRINO(名ばかりRUP)と言っている。誤解のないように言っておくと、RUPは正しい環境で適切に適用されればとても効果的だ。しかし、不幸なことに、その逆のことが頻繁に発生している。RUPフレームワークをさまざまなタイプのプロジェクトに適用する際の問題のひとつは、それが「ユースケース駆動」のアプローチとして示されることだ。要件をユースケースとして記述し、それらのユースケース実現からコンポーネントベースのアーキテクチャーを作成していくことは、RUPの基本である。これは、ユースケースを作ることがほとんど意味をなさない可能性のある保守プロジェクトやパッケージ実装では、大きな壁となる。

DADはユースケース駆動のアプローチを強いていないし、サービスやコンポーネントを構築する際に厳格にOOAD(オブジェクト指向分析設計)を適用することも主張していない。ユースケース駆動アプローチを適用することは可能だが、アジャイルに逆行するような包括的で詳細な要件定義につながる危険性は否定できない。我々はどちらかと言えば、皆さんのプロジェクトの状況下で道理にかなう範囲での、ユーザーストーリー駆動のアプローチをお勧めする。ユーザーストーリーも常に正しい選択とは限らない。もしかしたら皆さんは昔ながらのソフトウェア要件定義書(SRS)を要求されるような規制のある環境にいるかもしれない。重要なポイントは、皆さんが自身の置かれている状況に適応しなければならないということである。これが、ユーザーストーリーで構成されているスクラムのバックログではなく、(訳注:各項目をユーザーストーリーに限らない)作業項目一覧を、チームの作業の優先順位付けに使用するゆえんである。作業項目一覧を使うことで、バックログにあらゆる種類の作業を入れることができ、RUPやスクラムが理想的とするプロジェクト以外にも、多くの種類のプロジェクトにDADを適用することができるようになる。

DADはゴール駆動であり、成果物駆動ではない。特定の成果物やプラクティスも指定していない。むしろ、ライフサイクルのある時点で適用可能な代替手段を、それぞれのメリット・デメリットと共に提案するが、そのどれを選択するかは皆さんに任されている。

次の投稿では、統一プロセスのどの側面がDADに受け継がれたかということと、その理由を解説する。

オリジナル:Comparing DAD to the Rational Unified Process (RUP) – Part 1

Comparing DAD to the Rational Unified Process (RUP) – Part 1


 (翻訳 中佐藤麻記子)

 

Pocket