RUPをパターン言語として考える：オブジェクト指向の世界（19）

前回は「ネットコミュニティのQWAN（無名の質）」と題して、昨年大ブレークしたmixiなどのネットコミュニティについて考察しました。SNSの基本となっている友達の友達を巻き込むという仕掛けは、実はSNSとはまったく無関係な「6次の隔たり」理論からも爆発的にメンバーを増やせる可能性のある仕掛けだと述べました。

　次にネットコミュニティが発展・持続していくためには、そこに何らかの居心地の良さのような質が必要であり、この質をパターン言語の提唱者であるAlexanderのQWANとして考察しました。このQWANをどうやって作るのかは、実際のコミュニティ活動の実践・経験を通して、プラスのパターンとマイナスのパターン（アンチパターン）を発見することです。そこからベストプラクティスを集めます。それをパターン言語として整理します。今回はベストプラクティスをパターン言語として整理する１つの具体例としてRUP（Rational Unified Process）を取り上げたいと思います。

　ソフトウェア開発プロセスとしてデファクト・スタンダードとなりつつある統一プロセス（Unified Process）──というより提唱者の名前が付いたRUPといった方が一般的ですが──これを今回はパターン言語の視点で考えてみたいと思います。

　RUPはRUP2003からRUP7にバージョンが上がり大きく改訂されましたが、今回はまず現在主に使用されているRUP2003を取り上げます。

開発プロセス

　統一モデリング言語UMLはソフトウェア開発の世界でかなり普及してきました。ちなみにUMLの認定試験はOMGとUMTPという2つの組織が別々に行っています。どちらを受ければよいか迷いますが、おおむねUMLの文法を重視しているのがOMG、モデリングの実践を重視しているのがUMTPとすみ分けが行われているようです。UMTPの受験者は3年目で1万人を超える見通しです。

　UMLを活用した開発プロセスとしてRUPやXPなどのアジャイル開発も普及しつつあります。ところでUMLは世界標準規格となりましたがRUPやXPなどの開発プロセスはそうではありません。開発プロセスとは、いわば仕事のやり方であり、それは各チームやプロジェクトごと、組織や会社ごとに企業文化など内部の固有の状況に応じてそれぞれで決めればよいことです。

　ソフトウェア開発の世界で伝統的に行われているウォーターフォール型の開発プロセスは、最近オブジェクト指向開発の普及に合わせてRUPやアジャイル系の開発プロセスに移行されるようになってきました。その原因はどこにあるのでしょうか。この問題についてパターン言語の視点で検討してみたいと思います。

開発プロセスの問題

　いままでの標準的な開発プロセスはウォーターフォール型（以下WF型）が主流でした。これは伝統的なメインフレーム系業務システムの開発プロセスとして確立されてきたものです。分析・設計の技法も構造化分析・設計と呼ばれる技法が一般的でした。

　これに対して最近の業務系の主流であるWebアプリの開発プロセスはオブジェクト指向分析・設計技法を用いた反復型開発が一般的になりつつあります。開発言語もCOBOL、Cなどの非オブジェクト指向言語からJava、C#などのオブジェクト指向言語が主流になってきました。分析・設計技法、プログラミング言語の変化に合わせてそれに相応しいプロセスの見直しが問われてきました。

　オブジェクト指向開発を強力にサポートするツールがUMLです。UMLがなければ反復型開発はほとんど不可能でしょう。反復型開発に不可欠なのは変更・拡張に耐え得る頑丈で柔軟性のあるアーキテクチャ設計です。最初の骨組みがしっかりしていることがシステムのライフサイクルを通じて命取りになります。

　システム開発の失敗プロジェクトの例は多数あります。最悪はプロジェクトの中止です。これは当初の見積もり予測が大幅に違うことが明確になった場合です。システムのリリースはできたが納期遅れや予算が想定範囲オーバーの赤字プロジェクトも失敗に入ります。

　プロジェクトの成功・失敗の要因は開発技術上の問題よりも要求にまつわる原因が多いといわれています。ユーザーが要件定義に参加しているかどうかが成功・失敗要因の上位に挙げられます。これをサポートする強力なツールがユースケースです。従来型の機能要求スタイルはユーザーにはイメージがつかめないため、要求仕様のレビューは困難です。ユースケースを用いた機能要求は、自分がアクターとして使用するものをユーザー自身でレビューできます。一方従来型開発では、システムがほぼ出来上がりユーザーが初めて使用してからフィードバックが上げられますが、最早大きな設計変更を伴う仕様変更は困難です。

四諦（苦集滅道）とパターン

　釈迦が悟りを開き最初に弟子に説かれた法は四諦（したい）すなわち苦集滅道（くじゅうめつどう）だといわれています。四諦とは四つの真理という意味です[注1]。

1. 苦：人生は苦である
2. 集：では苦の原因は何なのか分析しよう
3. 滅：原因が分かったらそれを取り除こう
4. 道：それを取り除く方法論は八正道（はっしょうどう）である

　なぜこのような関係のない話を突然始めたのかいぶかられるでしょうが、筆者にはこれはパターン言語だとひらめきました。パターンとは繰り返し起きる問題に対する解決策です。問題（苦）の原因を分析し（集）、その原因を取り除く（滅）解決策（道＝八正道）、つまり人生の問題の救済方法を「ソフトウェア危篤患者の救出[注2]」と重ね合わせてみました。ソフトウェア開発上繰り返して失敗に陥るいつもの悪いパターン（アンチパターン）から抜け出すための1つの処方せんがRUPという名前のパターン言語です。

図1 四諦（苦集滅道）とRUPのベストプラクティス

ベストプラクティス

　practiceは実践、best practiceは「最善の実践」が直訳ですが、ベストプラクティスというそのまんまの表現が一般的なようです。RUPは次の6つのベストプラクティスをベースにしています。

1. 反復型開発
2. 要求管理
3. コンポーネントアーキテクチャ
4. UMLによる可視化
5. 継続的品質検証
6. 変更管理

　これらのベストプラクティスをパターン言語として、つまり「繰り返し起きる問題とその解決策」としてとらえてみたいと思います。パターンには制約（フォース）がありますが、今回個々のパターンの制約は外し、全体の共通の制約と考えました。

開発プロセスのパターン

（1）反復型開発

状況：

　WF型開発では開発後半になって実際に動き始めるまで問題が明確にならない。結合テストでモジュール間の不整合が初めて問題となってきて設計見直しとなる。エンドユーザーの評価が始まって初めて要求仕様の問題点が明確になってきて要求仕様の見直しとなる。これらはリリースの遅れ、予算超過につながる。これらの問題を根本的に解決する「反復型開発（1）」を成功させる鍵は「要求管理（2）」「コンポーネントアーキテクチャ（3）」「UMLによる可視化（4）」「継続的品質検証（5）」「変更管理（6）」の実践である

問題：

• 問題の発見が遅れる
• 変更の対応が難しい

解決策：

• 反復型開発により早期にリスクを軽減する
• 反復ごとに評価を行い、以降の反復で修正する

（2）要求管理

状況：

　ユーザーの要求が開発者に正確に伝わらない。多数の利害関係者の要求に一貫性がなく、内容が明確でなく、要求が安定せず、優先順位の調整も難しい。開発が始まってからも変更や追加により開発範囲がなし崩し的に拡大していく。要求の変更や追加により生じる設計変更への影響範囲が不明確。これらの問題を根本的に解決する「反復型開発（1）」を行うためには「要求管理（2）」が不可欠である

問題：

• ユーザーと業務知識の乏しい開発者の間で要求仕様に関する正確なコミュニケーションが難しい
• 利害関係者のニーズの調整、要求変更、追加要求による開発範囲拡大の対処が困難

解決策：

• ユースケースによりユーザーと開発者のコミュニケーションを行う
• トレーサビリティの管理：利害関係者のニーズからソフトウェア要求項目へのリンクを張って管理する
• 要求属性の管理：個々の要求に、優先順位、開発難易度、安定性などの属性を付けて管理する

（3）コンポーネントアーキテクチャ

状況：

　ソフトウェアに変更・拡張は付き物であり、変更・拡張を容易にして影響するモジュールを局所化したい。これは「反復型開発（1）」を行うためにも不可欠である。またモジュールの再利用性を高めたい

問題：

• 設計が複雑になり、開発・変更・拡張・再利用が困難

解決策：

• システムを独立したコンポーネントの組み合わせとなるように全体アーキテクチャの設計を行う

（4）UMLによる可視化

状況：

　従来の設計技法では設計の表現法が限定されていた。一般的に利用されているフローチャート、DFD、ER図などだけでは複雑なシステムの設計詳細を正確に表現・伝達するのが困難であった。従って設計書よりもプログラミングに重点があり、ソースコードが即設計ドキュメント状態であった。「反復型開発（1）」を行うためにも「UMLによる可視化（4）」による明確な設計モデルの保守が不可欠である

問題：

• アーキテクト、デザイナなど設計担当者にとって設計の表現が難しい
• プログラマなど設計書の利用者にとってその理解が難しい
• 修正を重ねるうちに設計書とソースコードの同期が取れなくなる

解決策：

• モデルをUMLで表現する
• UMLツールを用いてソースコードとモデルの同期を取る

（5）継続的品質検証

状況：

　従来型ではプログラムの品質テストに重点が置かれているが、要求仕様や設計書など工程ごとの成果物の品質が悪いと、結果としてシステムの品質保証ができない。また開発プロセスの品質も考慮しなければならない。「反復型開発（1）」では「反復ごとの継続的品質検証（5）」が不可欠である

問題：

• ソフトウェアの品質が悪い
• ドキュメントの品質が悪い

解決策：

• すべての開発工程でその成果物の品質を検証する
• 要求の品質を上げる

（6）変更管理

状況：

　大規模開発ではソースコードやプログラムの構成管理が必須である。また変更依頼の一元管理も必須である。「反復型開発（1）」では特に変更が多いため、「変更管理（6）」が重要である

問題：

• 開発中に発生する要求変更、仕様変更、設計変更の対応が困難

解決策：

• 構成管理：チーム開発ができるように、ドキュメント・プログラムなどの成果物を一元管理する
• 変更依頼管理：変更依頼を一元管理する

　今回はRUPのベースとなっている6つのベストプラクティスをパターン言語としてとらえてみました。パターン言語の考え方は仏教の四諦すなわち苦集滅道の方法論と相通ずるものがあります。ソフトウェア開発は「苦」である。では苦の原因を分析しよう（集）。その原因を取り除こう（滅）。そのための方法（道）が６つのベストプラクティスであり、その1つの具体的実践方法がRUPである。RUPにより開発の「苦」から解放される。人生いかに生きるべきかという問題の解決手法は、ソフトウェアはいかに開発すべきかという問題の解決手法のヒントになります。

　次回はRUP2003からRUP7への変更点についてパターン言語の視点で考えてみたいと思います。