前回「RUPをパターン言語として考える」はRUPのベースとなっている6つのベストプラクティスをパターン言語としてとらえてみました。パターン言語の考え方は仏教の四諦(したい)すなわち苦集滅道(くじゅうめつどう)という人生いかに生きるべきかの方法論と相通ずるものがあります。ソフトウェア開発は「苦」である。では苦の原因を分析しよう(集)。その原因が分かったらそれを取り除こう(滅)。そのための方法(道)が6つのベストプラクティスであり、その1つの具体的実践方法がRUPである。RUPにより開発の「苦」から解放される。人生いかに生きるべきかという問題の解決手法は、ソフトウェアはいかに開発すべきかという問題解決のヒントになります。
開発プロセスのデファクトになりつつあるRUP(Rational Unified Process=ラショナル統一プロセス)は2006年に大幅な変更が加えられました。より顧客志向のソリューションが提供できるようなプロセスを目指していることが感じられます。今回はRUPのバックボーンとなっているベストプラクティスに注目し、RUP2003からRUP7への変更点について、前回に引き続きパターン言語の視点で考えてみたいと思います。
RUP2003からRUP7への大きな変更点の1つは6つのベストプラクティス(Best Practices)が6つの基本原則(Key Principles)に置き換えられたことです。従来のベストプラクティスは具体的で分かりやすかったのですが、基本原則に書き換えられて内容がより抽象的となりカバーする範囲も拡大されました。それに伴い表現方法も次のようにより形式化されました。
従来の6つのベストプラクティスは実質的にすべてこのパターンに包含されました。前回の記事にも書きましたが、ベストプラクティスはパターン言語の定義によるパターン(繰り返し起きる問題とその解決策の組)として表現できるものです。
アンチパターンは繰り返し起きる失敗に陥る悪いパターンです。良いパターンに従わないとどのような結末に陥ってしまうかを警告するものです。
ここでRUPとXP(eXtreme programming)を比較してみましょう。RUPは大規模開発、XPなどアジャイル系は短期開発を主眼に置いた開発プロセスです。どちらも過去の経験、提唱者の体験に基づいたベストプラクティスをベースに組み立てられています。XPは「価値(values)―基本原則(principles)―実践(practices)」という構成になっています。RUPにはいままではこの「価値―基本原則」に当たる部分がなく、いきなり6つのベストプラクティス(最善の実践原則)から始まっていましたが、今回改訂されたRUP7では1ランク抽象レベルが上がって基本原則となり、従来の実践原則はパターンとしてその下に位置付けられました。価値に当たる部分は特に明示されていません。
ちなみにXPの価値を見てみましょう。XPも第2版が出て改訂されたので、最初のものをXP1、第2版をXP2と呼ぶことにします。XPの価値はXP1では次の4つです。
これらの価値はRUPでも暗黙的に認められているようですが、一部は基本原則やパターンに明示されています。
大きく見るとRUP7には2つの基本原則が新たに追加され、以前からある6つのベストプラクティスはすべて4つの基本原則の中のパターンに再構成されています。
この 6つの基本原則を次に示します:
Adapt the process. (プロセスの適合)
Balance competing stakeholder priorities. (優先順位の調整)
Collaborate across teams.(チーム横断の協力)
Demonstrate value iteratively. (反復的に価値を実証)
Elevate the level of abstraction. (抽象化のレベルアップ)
Focus continuously on quality.(継続的品質注視)
なおこれらの詳細は「Key principles for business-driven development(IBM|DeveloperWorks)」に公開されています:
このように先頭文字がAからFと動詞でアルファベット順に並ぶように工夫されています。図1にベストプラクティスと基本原則の主要な包含関係を示します。
仏教の四諦・苦集滅道(したい・くじゅうめつどう)の最後の「道」は八正道(はっしょうどう)と呼ばれ、その内容は8つの反省のプラクティスと考えることができます。結果には必ず原因がある。結果が望ましくないものであれば自分にその原因がないかを反省してみよう。正見(しょうけん)、正思(しょうし)、正語(しょうご)、……、自分は客観的に見て正しい見方をしたであろうか、自分の思いは正しかったであろうか、自分の言葉で他人を傷つけなかっただろうか……。
ちなみにXP2の基本原則には反省(Reflection)が挙げられていますね。この人生の問題を解決する8つのプラクティスとソフトウェア開発の問題を解決する6つの基本原則を対比して考えてみるのも参考になるのではないかと思います(図2)。
パターンの表現形式は前回同様とします。日本語のパターン名は内容を考えて筆者が付けたものです。英語はオリジナルの基本原則です。
「アンチパターン――ソフトウェア危篤患者の救出」(ソフトバンクパブリッシング)を参考にしましたが、同書から引用したアンチパターンは《パターン名(AP*)》と表記しました。
(A)プロセスの適合 ― Adapt the process.
状況:
プロジェクトの規模と開発プロセスが必ずしも合っていない。一度決めたプロセスに基づく開発計画を重視し、計画との差異を基に進ちょく管理を行い、プロセスの見直しをしない。《計画倒れ(AP*)》
問題:
解決策:
(B)優先順位の調整 ―Balance competing stakeholder priorities.
状況:
さまざまな利害関係者のニーズの調整が不十分で、エンドユーザーにとってもシステムのイメージがまだ十分理解できない状態で要求仕様を凍結してしまう。
問題:
解決策:
(C)チーム横断の協力 ― Collaborate across teams.
状況:
プロジェクトメンバーのコミュニケーションが十分でなく、共同作業が円滑に行われない。納品すべき最終製品に対する顧客満足の意識が開発者に希薄。《組織硬直(AP*)》
問題:
解決策:
(D)反復的に価値を実証 ― Demonstrate value iteratively
状況:
ウォーターフォール型開発の問題は、リリースされるまでエンドユーザーにシステムが見えないことである。従ってユーザーからのフィードバックが遅れ、システム完成後の手直しを余儀なくされ、新たな設計上の問題を引き起こす。
問題:
解決策:
- 反復ごとにユーザーからのフィードバックを得る
(フィードバックはXPでは価値として挙げられている)
- インクリメンタルにユーザーに価値を実証し、リスクを早期解消する
(E)抽象化のレベルアップ― Elevate the level of abstraction.
状況:
ソフトウェアは本質として複雑なものである。単純化することにより生産性と品質向上を図る必要がある。《システムのおんぼろ煙突化(AP*)》《文書化軽視(AP*)》
問題:
解決策:
(F)継続的品質注視 ― Focus continuously on quality.
状況:
初期の要求どおりに開発を進めても必ずしも顧客満足を得られない。製品の品質は顧客満足が第一である。(D)反復型に価値を実証によりフィードバックが得られ製品の品質を高めることができる。
問題:
解決策:
今回は改訂されたRUP7の基本原則をパターン言語として簡単に整理してみました。従来の具体的ベストプラクティスはより抽象化された基本原則の中のパターンとして吸収される形になり、RUPの適用範囲も一回り拡大されました。開発プロセスのカバーする範囲は一般的には設計フェイズからであったのがRUPでは要求分野がカバーされ、今回の改訂でさらにビジネスと顧客に近づいた形になり「顧客志向のソリューション提供のためのプロセス」という思想が一段と強まったと感じます。
次回は話題を変えて、独自のスタイルで一連の一般向け哲学啓蒙(けいもう)書を発表され続け、先月(2月)惜しくも急逝された池田晶子氏をしのび『ソクラテス編―池田晶子氏に捧げる』というタイトルで一文を書いてみたいと考えています。
河合 昭男(かわい あきお)
大阪大学理学部数学科卒業、日本ユニシス株式会社にてメインフレームのOS保守、性能評価の後、PCのGUI系基本ソフト開発、クライアント/サーバシステム開発を通してオブジェクト指向分析・設計に携わる。
オブジェクト指向の本質を追究すべく1998年に独立後、有限会社オブジェクトデザイン研究所設立。 OO/UML 関連の教育コース講師・教材開発、Rational University認定講師、東京国際大学非常勤講師。 ホームページ:「オブジェクト指向と哲学」
Copyright © ITmedia, Inc. All Rights Reserved.