PR

 「ポスト・ウォータフォール」として最も有力な開発プロセスは,UP(Unified Process)であることに異論のある人は少ないだろう。しかし,UPのコンサルティングを手掛ける岡大勝氏(ソフトウェアプロセスエンジニアリング 代表取締役社長)は「『UP=反復開発』と誤解している人が多い。ユースケースごとにUMLで設計して実装する作業を繰り返すのがUPだと思っている」と語る。

 岡氏は「もっと重要な作業があるのに,多くの現場で抜け落ちている」と言う。では,抜け落ちている作業とは何か。大きく三つある(図1)。

図1●UPで本来実施すべき作業範囲は広い
図1●UPで本来実施すべき作業範囲は広い
開発プロセスとして「RUP」あるいは「UP」を採用している多くの開発現場では,ユースケース駆動,UMLモデリング,反復開発しか実施していない。しかし,これらよりもアーキテクチャ構築やフェーズの順守,分析モデル作成のほうがはるかに重要である

 一つは「分析と設計の分離」。分析とは.NETやJavaといった実装技術に依存しないUMLモデル(分析モデル)の作成。設計とは,実装技術に依存するより詳細なUMLモデル(設計モデル)の作成を指す。しかし多くの現場では,機能要求(ユースケース)からいきなり設計モデルを作っている。

 なぜ分析が必要なのか。大きな理由は保守性が良くなることだ。分析クラスは設計クラスよりも粒度が大きい。設計クラスが1000個,分析クラスが100個あったとすると,分析クラスを見ることで大事なクラスを見つけやすくなるので,保守が容易になる。

 二つ目は「アーキテクチャ」の構築。「多くの人がハードやミドルウエア,フレームワークなどの製品の組み合わせ=アーキテクチャと思っているが,UPのアーキテクチャは全く違う」(同)。図2に示すように,分析クラスの中からプロジェクト内で再利用できる汎用的なクラスを設計・実装した,実際に動く“環境”がUPのアーキテクチャ。このアーキテクチャのAPIを使いながら,ユースケースを実装していく。プロジェクト内でクラスを再利用することで生産性と品質が高まる。

図2●UPのアーキテクチャ
図2●UPのアーキテクチャ
プロジェクト内で再利用できる汎用的なクラスをインフラ上に実装したものが「アーキテクチャ」。アーキテクチャ構築の完了が遂敲フェーズの完了基準になる

 三つ目はフェーズの順守である。岡氏は「反復よりもフェーズの方が100倍重要」と言う。UPでは「方向付け」「推敲」「作成」「移行」の四つのフェーズがある。推敲フェーズで,先述したアーキテクチャの構築を完了する。これにより,作成フェーズでは複数のユースケースの並行開発が可能になり生産性が大幅に向上するほか,見積もり精度も上がる。