RUP7で開発の「苦」から解放される：オブジェクト指向の世界（20）

» 2007年04月10日 12時00分 公開
[河合昭男，（有）オブジェクトデザイン研究所]

　前回「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

　ここでRUPとXP（eXtreme programming）を比較してみましょう。RUPは大規模開発、XPなどアジャイル系は短期開発を主眼に置いた開発プロセスです。どちらも過去の経験、提唱者の体験に基づいたベストプラクティスをベースに組み立てられています。XPは「価値（values）―基本原則（principles）―実践（practices）」という構成になっています。RUPにはいままではこの「価値―基本原則」に当たる部分がなく、いきなり6つのベストプラクティス（最善の実践原則）から始まっていましたが、今回改訂されたRUP7では1ランク抽象レベルが上がって基本原則となり、従来の実践原則はパターンとしてその下に位置付けられました。価値に当たる部分は特に明示されていません。

　ちなみにXPの価値を見てみましょう。XPも第2版が出て改訂されたので、最初のものをXP1、第2版をXP2と呼ぶことにします。XPの価値はXP1では次の4つです。

  • コミュニケーション（Communication）
  • シンプル（Simplicity）
  • フィードバック（Feedback）
  • 勇気（Courage）
*XP2 になって1つ追加されました

  • 敬意（Respect）

　これらの価値はRUPでも暗黙的に認められているようですが、一部は基本原則やパターンに明示されています。

RUP7の基本原則

　大きく見ると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にベストプラクティスと基本原則の主要な包含関係を示します。

ALT 図1 RUP2003 vs. RUP7

四諦・苦集滅道と八正道

　仏教の四諦・苦集滅道（したい・くじゅうめつどう）の最後の「道」は八正道（はっしょうどう）と呼ばれ、その内容は8つの反省のプラクティスと考えることができます。結果には必ず原因がある。結果が望ましくないものであれば自分にその原因がないかを反省してみよう。正見（しょうけん）、正思（しょうし）、正語（しょうご）、……、自分は客観的に見て正しい見方をしたであろうか、自分の思いは正しかったであろうか、自分の言葉で他人を傷つけなかっただろうか……。

　ちなみにXP2の基本原則には反省（Reflection）が挙げられていますね。この人生の問題を解決する8つのプラクティスとソフトウェア開発の問題を解決する6つの基本原則を対比して考えてみるのも参考になるのではないかと思います（図2）。

ALT 図2 四諦（苦集滅道）とRUP7の基本原則

RUP7の基本原則をパターン言語で考える

　パターンの表現形式は前回同様とします。日本語のパターン名は内容を考えて筆者が付けたものです。英語はオリジナルの基本原則です。

　「アンチパターン――ソフトウェア危篤患者の救出」（ソフトバンクパブリッシング）を参考にしましたが、同書から引用したアンチパターンは《パターン名（AP*）》と表記しました。

（A）プロセスの適合 ― Adapt the process.

状況：

　プロジェクトの規模と開発プロセスが必ずしも合っていない。一度決めたプロセスに基づく開発計画を重視し、計画との差異を基に進ちょく管理を行い、プロセスの見直しをしない。《計画倒れ（AP*）》

問題：

  • 短期開発にもかかわらずプロセスが大掛かりでドキュメント類も多い
  • 大規模開発にもかかわらずプロセスが大ざっぱでドキュメント類も正確に定義されていない

解決策：

  • 開発規模に合わせてプロセスを決める
  • プロセスを常に改善する

（B）優先順位の調整 ―Balance competing stakeholder priorities.

状況：

　さまざまな利害関係者のニーズの調整が不十分で、エンドユーザーにとってもシステムのイメージがまだ十分理解できない状態で要求仕様を凍結してしまう。

問題：

  • 初めに要求仕様を確定してしまい、要求変更や資産の再利用に柔軟に対処できない

解決策：

  • 要求管理（RUP2003）：反復型開発で優先順位の調整を行う
  • 資産の再利用とニーズのバランスを取る

（C）チーム横断の協力 ― Collaborate across teams.

状況：

　プロジェクトメンバーのコミュニケーションが十分でなく、共同作業が円滑に行われない。納品すべき最終製品に対する顧客満足の意識が開発者に希薄。《組織硬直（AP*）》

問題：

  • 各自および各チームが割り当てられた仕事のみに集中し、ほかの人やチームとのコミュニケーションや共同作業はほとんど行われない
  • 全体としての作業効率が悪く、メンバーの長時間労働でカバーする

解決策：

  • チーム内およびほかのチームとのコミュニケーションと共同作業を推進する（コミュニケーションはXPでは価値として挙げられている）

（D）反復的に価値を実証 ― Demonstrate value iteratively

状況：

　ウォーターフォール型開発の問題は、リリースされるまでエンドユーザーにシステムが見えないことである。従ってユーザーからのフィードバックが遅れ、システム完成後の手直しを余儀なくされ、新たな設計上の問題を引き起こす。

問題：

  • 計画との差異でプロジェクトの進ちょくを評価し、製品に対するユーザーからのフィードバックを先送りにする。その結果製品に対する顧客満足が得られない
  • リスクを先送りにする。その結果リリースが迫ってから問題が噴出し、手直しが発生して納品に間に合わなくなる

解決策：

  • 反復型開発（RUP2003）により

- 反復ごとにユーザーからのフィードバックを得る

（フィードバックはXPでは価値として挙げられている）

- インクリメンタルにユーザーに価値を実証し、リスクを早期解消する

  • 変更管理（RUP2003）

（E）抽象化のレベルアップ― Elevate the level of abstraction.

状況：

　ソフトウェアは本質として複雑なものである。単純化することにより生産性と品質向上を図る必要がある。《システムのおんぼろ煙突化（AP*）》《文書化軽視（AP*）》

問題：

  • 要求仕様から十分な設計をせずに実装に入る
  • 変更や拡張に弱い設計
  • 設計書がなく、ソースコードがすべてで開発者のコミュニケーションが困難

解決策：

  • コンポーネントを用いたアーキテクチャ設計を行う（RUP2003）
  • UMLによるモデルの可視化を行う（RUP2003。XPの価値であるシンプルもこれらに含まれる）

（F）継続的品質注視 ― Focus continuously on quality.

状況：

　初期の要求どおりに開発を進めても必ずしも顧客満足を得られない。製品の品質は顧客満足が第一である。（D）反復型に価値を実証によりフィードバックが得られ製品の品質を高めることができる。

問題：

  • 中間成果物に対する開発者のレビューに重点が置かれ、製品に対するユーザーの評価が先送りにされる

解決策：

  • 継続的品質管理（RUP2003）

　今回は改訂されたRUP7の基本原則をパターン言語として簡単に整理してみました。従来の具体的ベストプラクティスはより抽象化された基本原則の中のパターンとして吸収される形になり、RUPの適用範囲も一回り拡大されました。開発プロセスのカバーする範囲は一般的には設計フェイズからであったのがRUPでは要求分野がカバーされ、今回の改訂でさらにビジネスと顧客に近づいた形になり「顧客志向のソリューション提供のためのプロセス」という思想が一段と強まったと感じます。

　次回は話題を変えて、独自のスタイルで一連の一般向け哲学啓蒙（けいもう）書を発表され続け、先月（2月）惜しくも急逝された池田晶子氏をしのび『ソクラテス編―池田晶子氏に捧げる』というタイトルで一文を書いてみたいと考えています。

筆者プロフィール

河合 昭男（かわい あきお）

大阪大学理学部数学科卒業、日本ユニシス株式会社にてメインフレームのOS保守、性能評価の後、PCのGUI系基本ソフト開発、クライアント／サーバシステム開発を通してオブジェクト指向分析・設計に携わる。

オブジェクト指向の本質を追究すべく1998年に独立後、有限会社オブジェクトデザイン研究所設立。 OO/UML 関連の教育コース講師・教材開発、Rational University認定講師、東京国際大学非常勤講師。 ホームページ：「オブジェクト指向と哲学」



「オブジェクト指向の世界」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ