規定されている作業が多すぎる
| ||
|
以上，RUPの掲げるベスト・プラクティスに沿って留意点を整理してきた。しかしこれ以外にも，RUPを実プロジェクトに適用する上で注意すべきことはある。開発作業と，プロジェクト・マネジメントという二つの観点から見ていこう。
開発作業の観点から最も重要なのは，多くの作業を含む「重い」プロセスをいかにスリム化するかである。RUPは，開発プロセスのひな形（プロセス・フレームワーク）となるものである。さまざまなプロジェクトに適用できるようにするため，汎用的なプロセス構造になっている。その結果多くの作業を含む重いプロセスになっている。適用するプロジェクトに合わせて，簡略化することが必要だ。
中でも多くの作業を含んでいるのが，分析設計のワークフローである（図3[拡大表示]）。ソフトウェア開発の中心的な工程なので当然ではあるが，規定された作業をすべて実施するのは非常に手間がかかる。プロジェクトに不要な作業を極力減らすことが重要である。
そのよい例が，近年利用が増えているWebシステムの構築である。Webシステムの場合，アーキテクチャは決定済みで，それに従って開発するケースがほとんどである。RUPで規定している作業をすべて適用する必要はない。
WebシステムはほとんどのケースでWebアプリケーション・サーバー（以下，APサーバー）上で動作する。さらにAPサーバーは，J2EE（Java 2 Platform, Enterprise Edition）に準拠している。開発するシステムはJ2EEアーキテクチャを前提にしたソフトウェア構造となるため，新たなアーキテクチャを一から構築する必要はない（図4[拡大表示]）。さらにAPサーバーの上位レイヤーにフレームワークを利用した開発が一般化しつつある現在では，アプリケーションの基本構造から構築しなければならないケースは稀である。
見積もりや開発環境にも注意が必要
一方視点をプロジェクト管理に転じると，留意すべきことは他にもある。最も大きいのが，(1)の反復開発導入に関するものだ。
まず，開発工数の見積もり方法を新しく考える必要がある。反復開発を採用するRUPを導入した場合，見積りの手法は従来の開発プロセスとは明らかに異なる。しかし，RUPには見積りに関する明確な記述がない。このため別途新たなコストモデルを採用する必要がある。コストモデルとしては，COCOMO IIが既に実証済みの手法である。
もう一つ，開発環境を揃えるタイミングがウォータフォールと異なることにも注意したい。意外に見落とされがちだが，反復開発では開発工程の初期段階で開発に必要なすべての環境が揃っていなければならない。テストツールやソフトウェア構成管理ツールなど開発者が利用する環境すべてである。ウォータフォールでは開発の後半になるまでテスト環境などは不要だが，反復開発では1回目の反復から必要である。
こうした点に最初から気を配るのは難しい。このため，筆者はプロジェクトにいきなり反復開発を導入することをお勧めしない。RUPでの開発経験がなく，オブジェクト指向開発経験も浅いメンバーによるプロジェクトの場合は反復開発をしない方がよい。RUPのワークフローに沿って，1回のみのウォータフォールで開発を実施することが望ましい。RUPのプロセスを概観すると反復開発をしなければならないと思いがちだが，段階的にプロセスを適用することも必要な場合がある。
山崎靖之 Yasuyuki Yamazaki株式会社テンアートニ 第一事業部長1963年生まれ。ラショナルソフトウェア（現日本IBM）のコンサルタントを経て現在に至る。メインフレーム時代にDOA，その後はオブジェクト指向の開発手法に関わる。現在はRUPを自社向けに仕立て直し，実践的にした「t-SES」を作成している。趣味はサッカー。休日は息子が所属するクラブチームのコーチとして，また自分の所属クラブでサッカーに明け暮れる。 |
