連載
【改訂版】初歩のUML

第10回
開発プロセスの上手な組み合わせ

萩本順三　株式会社豆蔵
2003/10/8

　今回は、前回「第9回 UMLベース開発プロセスの流れ」説明した開発フェイズの基本知識を基に、いくつかの開発フェイズを組み合わせながら開発を進める方法（開発プロセス）について説明をしていきます。UMLの使い方について例題を使って説明する予定でしたが、プロセス関連でお話ししたいことが山ほどあり、今回は例題まで話をつなげることができません。よって、例題については次回に回します。皆さん気長にお付き合いください（笑）。

開発フェイズとUMLモデリング

　前回説明したように、オブジェクト指向型開発プロセスでは、表のような開発フェイズを持っています。実際、これらの開発フェイズの名前や、その中で行う作業の定義については、開発プロセスの中で定義されているのですが、どの開発プロセスを利用するにしても、下記のフェイズを理解して開発を進めることが重要です。これは、前回の順平君の体験例にてお分かりいただいたと思います。

　表は、それぞれのフェイズで、利用する代表的なUMLの図について表しています。このUMLとフェイズの対応について、どのフェイズでどのUML図を利用するのかという明確な定義はありません。例えば、組み込み系システムにおいては、状態（ステートチャート）図がシステム分析の段階から使われることになるでしょう。また、ビジネスアプリケーションにおいても、業務自体に複雑な状態がある場合、ビジネス分析の段階から状態図が使われることになるでしょう。この説明は、あくまで一般的なビジネスアプリケーション開発におけるUML図の利用法と考えてください。なお、状態図のように、まだこの連載で取り上げていない図もありますが、それらの図については今後取り上げていく予定です。まだ本連載で取り上げていない図は、ビジネスアプリケーションの開発において、利用頻度、重要度、利用効果のいずれかが低いものと考えてください。

フェイズ名	目的	利用される代表的なUML図	概要
ビジネス分析	ビジネスの理解、ビジネスの視覚化	アクティビティ図、クラス図	ビジネスを視覚化し、ユーザー、開発者間で共有、理解する。そのうえで改善点やシステム化対象を洗い出す
要求分析	要求の把握（ユースケース=システム利用例の視覚化）	ユースケース図、ユースケース記述	システム化対象の要求についてユーザーの視点でユースケースモデルを作成することで明確化する
システム分析	要求の概念構造の理解、視覚化	クラス図、オブジェクト図、相互作用図、パッケージ図	要求の中に現れる用語を利用して、要求の意味、概念構造をとらえるためにクラス図を作成する
システム設計	ソフトウェア構造の理解、視覚化	クラス図、オブジェクト図、状態図、相互作用図、パッケージ図、コンポーネント図、配置図	実装されるアーキテクチャを含んだソフトウェア構造をモデル化
実装・テスト	ソフトウェアの実現	なし	設計に合わせて実装を行い、単体、複合テストを行う
表 開発フェイズと利用されるUMLの図 （赤色で表記した図は、この回までに説明していない図）

フェイズ戦略

　フェイズ戦略とは、開発プロセスで定義されている表で示したそれぞれのフェイズを、どのようなポリシーで開発スケジュールに組み込ませるかという戦略のことをいいます。以下に代表的なフェイズ戦略について説明します。

◇ウォーターフォールモデル

　一番単純なフェイズ戦略は、ウォーターフォールモデルと呼ばれているものです。ウォーターフォールモデルは、名前のとおりフェイズが滝のように流れます。要求分析フェイズが完了しないとシステム分析フェイズが始まらず、システム分析フェイズが完了しないとシステム設計フェイズに移れないというように、前フェイズが終わらない限り次フェイズに進めないというやり方です。ウォーターフォールモデルは、マネジメントがやりやすいというメリットがあります。しかし、残念なことに、オープン系の開発では致命的な問題があります。どういうことかというと、オープン系の開発では、さまざまなOS、ミドルウェア、コンポーネントを寄せ集めて作ります。その結果、後フェイズ（設計と実装）に多大なリスクが潜むのですが、ウォーターフォールモデルではこのようなリスクを早期にヘッジできないのです。

　例えば、開発期間が2年のプロジェクトで、実装フェイズが15カ月後に始まったとしましょう。その段階で実現不可能な要求を受け入れたり、欠陥のある設計を発見してしまったりという問題が発覚した場合、開発を納期に合わせて進めることができなくなります。また、現代のソフトウェア要求は非常に複雑多彩になってきており、すべて最初に要求を固めてしまうということ自体に無理があります。それを無理やり推し進めてしまうことによってユーザーが望んでいない要求を作り出してしまうというリスクがあるのです。このように、ウォーターフォールモデルは、楽観的で官僚的なフェイズ戦略です。開発がうまくいくと低コストを実現できますが、うまくいくかどうかは一発勝負というリスキーな要素があります。また、なにがなんでも前フェイズを終わらせないと後フェイズに移れないという非現実的なやり方を採用させようとする戦略でもあります。これでは、プロジェクトのリスクを管理することができません。

図1 ウォーターフォールモデル

◇繰り返し型開発モデル

　ウォーターフォールモデルの欠点を補うため、いまでは、繰り返し型の開発モデルがメジャーな戦略となっています。繰り返しの戦略にはいろいろな種類がありますが、ここでは、典型的なパターンであるインクリメンタル開発とイテレーティブ開発を説明します。

図2 繰り返し型開発

◎インクリメンタル開発（漸増型）

　インクリメンタル開発は、新規の増分（開発部分）を積み上げていく方法です。この方法は、繰り返しの単位となるＮ回目、Ｎ＋１回目で対象となるソフトウェア構造がまったく異なるものや、依存関係のないものに適しており、繰り返しの単位の独立性が保てるので非常に分かりやすいというメリットがあります。もし、Ｎ回目、Ｎ＋１回目の中に、共通するソフトウェア構造が含まれていた場合は、共通部分を別々に開発してしまうことになり、ソフトウェアの保守性に問題が出ます。

図3 インクリメンタル開発

◎イテレーティブ開発（反復型）

　イテレーティブ開発は、ソフトウェアの全体、あるいは部分について、最初は薄く作り、少しずつ肉付けしていく方法です。この方法は、非常に重要かつ複雑なソフトウェアの個所について、徐々に確認しながら肉付けし、中身を濃くしていけるというメリットがあります。

図4 イテレーティブ開発

　以上、インクリメンタル開発とイテレーティブ開発の説明をしましたが、実際の繰り返し型開発では、この両者をミックスした戦略が採られることになります。例えば、機能単位で開発を行う際には、インクリメンタル戦略を採用し、コア・アーキテクチャを開発する際には、イテレーティブ戦略を選ぶといった具合になります。

　統一ソフトウェア開発プロセス（UP：Unified Process ）やラショナル統一ソフトウェア開発プロセス（RUP：Rational Unified Process）を例に取り、このことを説明しましょう。UP、RUPのフェイズ戦略にはユースケース・ドリブンとアーキテクチャ・セントリックという重要なポリシーがあります。

　ユースケース・ドリブンは、ユーザーから見た機能（ユースケース）単位（Ｎ個のユースケースが対象）に開発を進めることです。また、アーキテクチャ・セントリックとは、重要なコアとなるアーキテクチャをできるだけ開発早期に確立できるように、アーキテクチャを中心にして開発を進めるということです。ユースケース・ドリブンは、インクリメンタル戦略、アーキテクチャ・セントリックは、イテレーティブ戦略が採られるのです。

　これを説明する図5を見てください。UPやRUPといった繰り返し型開発プロセスでは、ユースケース単位に開発を進めながらも、コアとなるソフトウェア・アーキテクチャは共通化するということが重要となります。ではなぜ、ユースケース単位に開発を進めるのでしょうか。それは、ユーザーから見た機能（ユースケース）単位に開発を繰り返すことで、開発の進ちょくが明確になりやすく、ユーザー要求を的確に実現しているかどうか、繰り返しの中で細かくチェックできるからです。また、なぜ、コアとなるソフトウェア・アーキテクチャは共通化するべきかというと、ユースケース単位にバラバラに開発を進めていくと、本来共通化すべき共通部品やアーキテクチャがユースケースごとに作成されてしまい開発効率が低下し、保守性にも大きな問題が生じるからです。

図5 イテレーティブ・インクリメンタル開発

　このように、ほとんどの繰り返し型開発プロセスにおいては、インクリメンタル／イテレーティブ両戦略をミックスさせた開発ポリシーを持つのが普通なのです。

　さて、もう一度、図5を見てください。両戦略による進め方について、何か疑問を感じませんか？ そうです。ユースケース・ドリブンをインクリメンタル戦略で進めても、その土台となるアーキテクチャがイテレーティブ戦略で作成されるなら、ユースケース単位で開発を進めることで独立性を保とうとするインクリメンタル戦略の恩恵を受けられないのではないかという疑問です。実はそうなのです。よくよく考えると、アーキテクチャ部分とユースケース部分を明確に区切ることもできません。しょせんは、ユースケース実現部分で共通化すべき重要個所がアーキテクチャ部分になるわけですので、その境目はかなりグレーなものなのです。この問題は、Ｎ＋1回目の繰り返しで開発した部分が、Ｎ回目の繰り返しで開発したユースケース部分に影響を及ぼしてしまう、つまりバグを組み込んでしまう可能性があります。ですから、繰り返し型開発では、今回の繰り返し部分だけテストを行うのではなく、以前の繰り返しで作成された部分も再テストすることが必要となります。

繰り返し型開発にすべきか否か？

　繰り返し型開発においては先に述べたように、繰り返しのたびにすべてをテストする必要があり、テスト工数が増えるという欠点があります。また、開発作業を繰り返すため、管理工数も増えます。どうして、このようにリスクがあるフェイズ戦略を採用しなければならないのでしょうか？

　その理由は２つあります。まず、ウォータフォール型開発のような、楽観的・官僚的な開発プロセスでは、現在のオープン系開発においては致命的であるということ。次に、劇的に変化するシステム環境においてはユーザーのIT化要件を最初から的確に捉えることは困難であるということです。だからといってむやみに繰り返し型開発を行ってしまうとますますリスクが増えることになるでしょう。では、どうすべきか？ これについては、もう少々辛抱して本記事を読み進めてください。読者にとって開発プロセスを正しく理解するためのヒントが見つかるかもしれません。

繰り返し型開発プロセスにおけるフェイズの考え方

　繰り返し型の開発プロセスでは、各フェイズが何度も繰り返されることになります。これをしっかり理解するためには、少し高度なフェイズのとらえ方をしなければなりません。でもあまり心配しなくてもいいですよ。読者に開発経験があり、ごく自然にフェイズという概念をとらえさえすれば、その本質が見えてくるはずです。この本質面が一見高度なフェイズのとらえ方に見えるだけです。

　繰り返し型開発プロセスでは、先に述べたフェイズは繰り返されることになります（図5）。また、この繰り返しの戦略がイテレーティブ・インクリメンタルであることも説明しました。このような繰り返しにおいて、「何の目的や目標を持って繰り返すのか？」ということが重要となります。無計画に繰り返しをしてもテスト工数、管理工数だけが増大して何の意味もありません。そうなると、この繰り返しの目的や目標をグループ化したものについて名前を付けたくなるでしょう（図6）。

図6 目的や目標をフェイズ名とする

RUP、UPにおけるフェイズの考え方

　RUPやUPといった繰り返し型開発プロセスでは、この目的をグループ化したものをフェイズとして見せています。RUP、UPでは、「ビジネス分析、要求分析、システム分析、システム設計、実装、テストといった、いままで説明してきたものは、もはやフェイズというものではなくワークフロー（最新バージョンではDisciplines＝ディシプリン）と呼ばれます。

　図7は、UPの開発プロセスについてのオーバービューです。UPでは、それぞれの目的に「方向付け」「推敲（すいこう）」「作成」「移行」という名前が付けられています。この図の見方は、それぞれのデシプリンが作業の重み付けとして表されています。また、反復型開発は各デシプリンに対してN回行えることを示しています。当然のことですが、開発の規模によってこの反復回数は決められます。1回の反復期間は3週間〜2カ月程度です。小規模開発では、このデシプリン内の反復回数が0回ということもあり得るでしょう。

図7 UPの開発プロセス

　RUPは、IBM（旧Rational Software）が定義している開発プロセスですが、UPはRUPのサブセットと考えることができます。RUPは、UPのプロセスオーバービューと似ていますが、ビジネス分析というデシプリンが開発の中に加わっていたり、構成管理部門のデシプリンが別に定義されていたりと、かなり本格的な開発プロセスとして仕上げられています。

　Rational Softwareは今年IBMに買収されました。Rational SoftwareがIBMの配下に入ることで、UMLベースでの反復開発プロセスは、ますます洗練され、強化されることになるでしょう。RUPに、興味がある方は、IBMのRationalトップページをご覧ください。これからさまざまなイベントやRUP関連の資料が公開されることになるでしょう（http://www-6.ibm.com/jp/software/rational/）。

ウォータフォール型と何が変わったのか？

　さて、ここから既存の手法、製品にこだわらずに、どのような開発パラダイムの変化が起こっているのかという本質面を観察していきましょう。まず、ここまで読まれた方の中には、反復型開発の目的に名前を付けたフェイズだけを見ると、従来のウォータフォール型と何が違うのだろうかと疑問を感じた人も多いのではないのでしょうか。

　そうです。目的ベースでは、両者の違いはあまりありません。それはそうですよね。ウォータフォール型も反復型も、正しいソフトウェア開発を行うための方法を目に見えるように定義したプロセスなのですから。プロジェクトのさまざまな過程で何を目的にして開発すべきかという視点には、あまり変わりがないのです（図8）。

図8 目的から見たウォーターフォールモデル

　では、何が違うのでしょうか？ それは、2点あります。まずは１点目として、ウォータフォール型の場合は手戻りを考えていないということです。すべて初めから完璧に物事を進めるべきであるという考えです。ですから、ウォータフォール型の場合、システムの範囲を決めて、基本的な要件を抽出するという目的で達成すべきゴールが、「できればすべての要件を抽出すべきだ！」という高次元に変わっています。

　RUPやUP(以降、UPと略する)の場合、「本来、要件を抽出するのは理想だが、IT化に対する要求は最初から抽出できず、ユーザーと確認しながらIT化というテーマの中に生まれる要求を正しく整理する」という発想ですので、最初は基本的で重要な要件だけを抽出し、不確定なものは徐々に抽出していくという、人にとって自然なやり方をプロセスとして明らかにしようと試みているものです。このことは分析・設計という仕事の進め方についても同様な考えを持っています。

　2点目は特に重要な違いです。ウォータフォール型の場合は、すべてにおいて完璧さを求めているのですが、設計フェイズにおける成果物は検証されていません。つまり机上だけで描いた産物でしかないのです。なぜなら、実際に作って評価したものではないからです。

　一方、UPでいうところの推敲フェイズは、対象システムの重要なアーキテクチャ（重要な設計）を確立する局面ですが、その結果は、ユースケース（ユーザーから見た機能）という単位で検証（設計、実装、テスト）されています。つまり、検証されたアーキテクチャを提供しなさい、ということが明確にプロセスとして語られています。この点が両プロセスの大きな違いです。最近のオープン系開発では、さまざまなミドルウェア、コンポーネント製品を組み合わせて開発を進めるため、設計、実装に大きなリスクが潜んでいます。これを検証せずに、机上だけで解決することは、実際には不可能なことなのです。

　ですから、ウォーターフォールモデルを採用しているプロジェクトでは、コンポーネントやアーキテクチャについて、プロトタイプなどを作って検証しつつ開発を進めるという裏プロセスが存在しているものです。そのようなプロセスを確立している方々にとってみると、自分たちのやり方とUPのやり方の違いがあまり分からなくなってしまうでしょう。

　しかし、この裏プロセスがくせものなのです。実際には、オープン系開発で、ウォーターフォールモデルを採用して成功を収めている人たちは、この裏プロセスを確立しているのですが、失敗している人は、この裏プロセスの存在を知らないで忠実にウォーターフォールモデルを実践します。それでは開発ができるはずもなく実装段階にさまざまなリスクが噴出し、プロジェクトが破たんします。つまりは、裏プロセスは、優秀なプロジェクトマネージャーやリーダーの隠し技となってしまっているのがウォーターフォールモデルを採用している企業またはプロジェクトの問題と考えるべきでしょう。

　本来、開発プロセスはプロジェクトを成功させるための方法を、目に見える形にすることで、それを多くの開発者に分かりやすく理解させるもので、そのような裏プロセスがあってはならないものです。そこでオープン系開発に適合させやすく、人に分かりやすい形でプロセスをアレンジした一例として、UPが存在するととらえれば、UPのような反復型開発プロセスの本質が見えてくると思います。UPについてもあくまで、オープン系開発をうまく進める方法の事例（プロセスのリファレンスモデル）としてとらえるという観点も必要となるのです。

　重要なのは、実際の開発を行うドメイン（領域）の特性に文化（企業文化）や開発スキル（開発環境への慣れ、不慣れ）を考慮したフェイズ戦略を組み立てることです。この辺のノウハウを習得するにはメンターが必要です。メンターがいない場合は他社のコンサルタントをうまく使う必要があるでしょう。一般にコンサルタント費用は高いと思われるでしょうが、お勉強モードでこのようなことに取り組むと、逆に高コスト、高リスクをプロジェクトで抱え込んでしまうことになりかねません。

　もっとも、皆さんが優秀なメンターになれるよう努力するのも重要なことです。そのコツは、ここで書いたようにプロセスを本質面でどうとらえるかがカギとなります。教科書に頼っていては本質を見極めることができません。要は目的を見失わないことです。目的を見失わないためには、シンプルにやるべきことを分析するよう常に心掛けることでしょう。

IT Architect 連載記事一覧