反復開発でリスクを軽減
(1)の反復開発を実現するには，ウォータフォール型に比べてプロジェクト管理に高いスキルが必要となる。管理者は適切な開発計画を立て，正しく実行できたか評価しなければならない。状況に応じて開発計画を練り直す必要もある。
反復開発の目的は主に二つある。開発プロジェクトが持つリスクを早期に解消することと，変化する顧客の要求を上手に取り入れることだ。
従来，開発プロセスの主流となってきたのはウォータフォール型だった。システムの要件分析，設計，実装，テストという行程を水が流れるように順番に実施する。どの行程もミスなく進めば，この流れはシンプルで運用しやすい。しかし，ミスのない開発作業などないに等しい。例えば設計に致命的なミスがあり，それがテスト段階で初めて明らかになったとする。ウォータフォール型では後戻りが難しい。顧客の要求が変化した場合にも同じことが言える。
| ||
|
これに対し反復開発では，小さなウォータフォールを複数回繰り返す。このため早期にミスを発見しやすい。さらに反復のたびに顧客の要求を取り込める。従って早期にリスクを軽減でき，状況の変化にも対応しやすい（図1[拡大表示]）。
反復の計画管理が困難
だが反復開発を実現するには，反復の計画をきちんと立てて結果を厳密に評価し，次の計画にそれを反映させることが必須となる。それぞれの反復で達成すべき目標（マイルストーン）と解消すべきリスクを厳密に計画していないと，無意味な繰り返しになるからだ。RUPには大まかなマイルストーンは用意されているが，実際のプロジェクトでそのまま利用できるものではない。
RUPではソフトウェア開発の時間軸を四つのフェーズで区切り，それぞれのマイルストーンを示している。具体的には，方向付け（Inception），推敲（Elaboration），作成（Construction），移行（Transition）である。方向付けのフェーズではシステム化する範囲を決定し，既存のアーキテクチャが利用できるかどうかを見極める。推敲は，安定したアーキテクチャ基盤を確立するフェーズである。作成のフェーズで，システムに求められる機能を実装する。最後が，開発したシステムをユーザーの環境に導入するための移行のフェーズとなる。
しかしこれらのマイルストーンはあまりに抽象的だ。実際の開発では，各反復ごとにもっと詳細で具体的なマイルストーンを設定しておく必要がある。これは容易な作業ではない。解消すべきリスクの優先度や，顧客のニーズはプロジェクトによって異なる。こうした点を的確に把握し，プロジェクトに適したマイルストーンを設定するにはかなりのプロジェクト管理経験が必要だ。
結果を正しく評価する
反復の結果を正しく評価し，それを次回以降の反復計画に適切に反映させることも重要である。まず，反復の目標が達成されたかどうかを判断する基準を設定しておかなければならない。RUPにはこの点に関しても明確な規定がない。このためプロジェクト管理者には，現在の反復で何を評価すべきかを事前に（反復計画作成時に）十分検討して決定することが求められる。この評価基準は，意外に軽視されることが多い。曖昧な基準で評価すると，後の反復で大きな手戻りが発生する原因となる。また手戻りに気が付いた時には，致命的なダメージとなっていることが少なくない。
さらに難しいのが，評価の結果，マイルストーンまで到達できていなかった場合である。即座に，次回以降の反復計画に対策を反映しなければならない。ソフトウェア開発には予期せぬ事態がつきものである。反復完了時の結果が計画時に期待していたものと乖離していることも珍しくない。例えば想定していた機能が間に合わなかったり，完成時期が大幅にずれ込むといったことだ。こうした想定外の状況に機敏に対応し，反復計画を適切に練り直すのにはかなりのスキルが要求される。最悪の場合はプロジェクトの中止も考慮する必要がある＊1。
既存システムの要件と整合性をとる
(2)の要求管理を実現するため，RUPには「要求定義」という詳細なワークフローが用意されている。しかし既存のシステムを変更する作業にRUPを導入する場合，そのワークフローはそのまま適用できない。RUP以外の方法によって顧客の要求が既に定義されているからだ。
要求定義は，RUPの中でも非常に完成度が高いワークフローである。システム化の対象となる業務を，いかに的確にソフトウェアに落としこんでいくかが丁寧にガイドされている。最終的には，ソフトウェアの要求項目がユースケース・モデルとして作成される（図2[拡大表示]）。
ユースケースとは，システムに求められる振る舞いをシステム外部の条件（システムの利用者など）ごとに定義したものだ。RUPではユースケースを基にシステムを作り上げていくため，「ユースケース駆動」の開発プロセスとも言われる。つまり要求定義段階で作成したユースケース・モデルがシステムの要となる。逆に言えば，要件がユースケースになっていなければならない。
しかし，既存システムは当然何らかの要求定義に基づいて作られている。そして既存システムの要求項目は，RUPで用いられるユースケース・モデルに基づいて作成されているとは限らない。従って既存システムを改変する場合は，要求項目をユースケースの形に定義し直したり，RUPのプロセスに変更を加えるといった作業が求められる。
コンポーネント化には高度なスキルが必要
ソフトウェアの再利用効率を高め，柔軟な変更を可能にするためコンポーネント・アーキテクチャを採用する。これが(3)だ。ただ，RUPを頼りにこれを実現するには，深い経験と知識が必要となることに留意しなければならない。
RUPの各ワークフローには，システムをコンポーネント化するための規定が盛り込まれている。しかしその定義は抽象的で，難解である。正しく理解するのにそれなりの知識や経験が要求される。まして，適切に実行するのは非常に困難である。具体的にどのような設計をすれば効率的なコンポーネント化が実現できるかは設計者のセンスに依存する部分が多く，機械的な手順として示せるものではないからだ。
コンポーネント・アーキテクチャの特性を生かしたシステムを構築するためには，高度な技術力や設計能力が要求される。教科書通りに実行すれば実現できるといったような生易しいものではない。相応の知識や経験を備えた人材を確保する必要がある。
表記法の理解がモデリングの課題
(4)のビジュアル・モデリングに関して，RUPではUML（Unified Modeling Language）を全面的に採用している。従ってRUPを適用する場合，UMLが抱える課題を認識しておくべきだ＊2。
UMLを利用するには二つの課題を克服しなければならない。まず，システム開発の関係者がUMLを理解するのに必要な知識を身に付ける必要がある。UMLは9種類もの図の書き方を規定しており，さらにそれぞれがたくさんの表記法を使う。一つひとつがどのような意味を持っているかを知らなければ，図を読み取るうえで誤解が生じてしまう。
次に，モデリングのガイドラインを確立させる必要がある。UMLの表記ルールは多岐にわたっている。例えばUML 1.4のドキュメントは，1000ページを超える。これだけの表記を好き勝手に使っては，すべての関係者が共通する認識を持つのは困難である。利用する表記をある程度限定する必要がある＊3。
テストツールの導入コストがかかる
(5)の品質の検証に関しては，ツールを導入するコストを考慮しておかなければならない。RUPではテストの手間が多く発生するため，ツールで効率化することが必須になるからだ。
RUPでは，各反復ごとにテストのワークフローを設けている。機能テスト，性能テスト，負荷テストなどさまざまなテストを挙げ，それらを実行すべきことを述べている。
こうしたテスト自体は，ウォータフォール型でも実施する必要があった。しかし反復型では，テストの回数がウォータフォール型よりも多くなる。2回目以降の反復終了後に，前回の反復で既に実施したテストを再度実行する必要があるからだ。これを回帰テストという。回帰テストによって，新しい部分が以前の結果に悪影響を与えていないことを確認する。
これらのテストをすべて手動で実施すると，非常に多くの工数を要することになる。RUPが推奨するように，信頼性テスト，機能性テスト，負荷テストにテストツールを導入する必要がある。
変更管理が困難である
(6)の変更管理は，既に別の変更管理方法が存在する組織にRUPを導入する際の注意点がある。RUPと既存の方法が一致しない場合，両者をうまく融合させなければならない。
変更管理は，ソフトウェアの品質保証上重要である。ソフトウェアにいつ，どんな変更が加わったかを管理しておかなければ，あとから発覚した問題に対処するのが難しいからだ。RUPでも「構成および変更管理」というワークフローの中で，変更管理に関して規定している。それほど細かな定義ではないが，自分がシステムを変更したり他人に変更を依頼する場合，どんな手順を踏むべきかといった大まかな規定がある。
ただし，変更を管理するためのスキームを既に確立している組織も少なくない。従来の開発プロセスにおいても，変更管理は重要だったからだ。このような組織にRUPを適用する場合，RUPと既存のスキームの融合方法が重要である。RUPの規定を無視し，現状の品質保証規約をかたくなに守りすぎるとRUPとしての変更管理がうまくいかない。逆に，RUPを重視するあまり既存のスキームを変化させすぎるのもよくない。今あるスキームをなるべく変更せずに，RUPとうまく組み合わせることが重要である。
山崎靖之 Yasuyuki Yamazaki株式会社テンアートニ 第一事業部長1963年生まれ。ラショナルソフトウェア（現日本IBM）のコンサルタントを経て現在に至る。メインフレーム時代にDOA，その後はオブジェクト指向の開発手法に関わる。現在はRUPを自社向けに仕立て直し，実践的にした「t-SES」を作成している。趣味はサッカー。休日は息子が所属するクラブチームのコーチとして，また自分の所属クラブでサッカーに明け暮れる。 |
