ObjectSquare [2000 年 10 月号]

[レポート]


オブジェクト指向2000シンポジウム参加報告+α

written by

株式会社 オージス総研
京都大学大学院
藤井 拓



1   はじめに

   去る8月30日から9月1日に渡って開催されたオブジェクト指向2000シンポジムに2日間参加しました。筆者が参加したセッションは、チュートリアルT8「Rational Unified ProcessとeXtreme Programming」、T6「Multi Paradigm Design for C++」の2セッションです。この2セッションのうちT6についてはシンポジウム後に考えたことも含めてRUPとXPの相違点を記し、T8については聴講した所感を記します。


2   T8「Rational Unified ProcessとeXtreme Programming」

2.1   最初に反省の言葉

   本チュートリアルは、筆者がRUP (Rational Unified Process)の概要説明を担当し、平鍋さんと梅澤さんがXP(eXtreme Programming)の概要と実践経験を担当し、最後に羽生田さんがコーディネータとして加わりRUPとXPの類似点と相違点を議論する形で進行しました。
   RUPの説明を行った当事者としての反省点を一言述べるとすると、「迎合的なスタンスで発言してごめんなさい」ということです。筆者はシンポジウムの性格上XPのファンが圧倒的に多いことを想定しており、袋叩きに会わないように慎重に発言しました。激しくXPを罵倒し、RUPをプロモートするようなエンターテイメント性を期待した向きにはもの足りなかったかもれません。今現在でも、XPが罵倒すべき対象でもなく、RUPと直接的に競合するプロセスだとも考えていませんが、RUPとXPの共通点と相違点についてセッション後に再度考えた点を以降少し述べてみたいと思います。


2.2   XPとRUPの共通点と相違点

  XPの基本コンセプトで特徴的なのは、以下の4つの価値と12のプラクティスを提案している点です。
XPの4つの価値
 1)  Communication
 2)  Simplicity
 3)  Feedback
 4)  Courage

XPの12のプラクティス
 5)  Playing games
 6)  Small releases
 7)  Metaphor
 8)  Simple Design
 9)  Testing
10)  Refactoring
11)  Pair Programming
12)  Collective ownership
13)  Continuous Integration
14)  40-Hour week
15)  Onsite Customer
16)  Coding Standard
これらのXPの価値やプラクティスをRUPの対応するコンセプトやプラクティスと対比すると、いくつかの共通点と相違点を見つけることができます。


2.2.1   対象としている開発プロジェクトの規模、性格、形式性

   たぶん、XPとRUPの1番大きな相違点は対象としている開発プロジェクトの規模や形式性にあると思います。XPは、10人以下の開発プロジェクトで、開発対象のシステムの仕様が不明確な研究開発的な性格を持つプロジェクトを主として想定しているようです。それに対して、RUPは開発対象のシステムの仕様が不明確な前提は共通ですが、100人を超える大規模開発プロジェクトもカバーすることを目指しており、その点でXPよりは"きまじめ"な形式性の高いプロセスとなっています。すなわち、RUPでは多数の人が効率良く分業して中規模以上のシステムを開発することを想定しているためにより多くの成果物、作業、開発者の役割が必要となっています。
   開発対象のシステムの仕様が不明確な前提はXPとRUPで共通していますが、顧客との関係において少し前提としている点に違いがあります。XPは、顧客をシステムに対する要求内容やフィードバックの情報提供者として位置付けるだけではなく、開発チームの一員としてテスト作業等に巻き込むようにかなり友好的な関係が築けることを前提としています。それに対して、RUPでは顧客をシステムに対する要求内容やフィードバックの情報提供者として位置付ける点は共通していますが、必ずしも友好的な関係が築けることを前提としていません。その結果、RUPでは顧客の要求をかなり形式的に管理することや開発の長、短期的な計画、達成目標を明示的に立案することを推奨しています。すなわち、RUPでは顧客と開発チームの双方がそれぞれの責任をより明確にすることを求めているのです。
   一言でまとめると、XPは少数精鋭の開発者から構成され、顧客との関係がかなり友好的である状況を前提とした開発プロセスです。それに対して、RUPは中、大規模プロジェクト向けの汎用の開発プロセスといえると思います。


2.2.2   反復型プロセス

   XPとRUPとの間の大きな共通点は、反復型プロセスに基づいているという点です。XPの掲げているプラクティスの中でSmall releases、Testing、Continuous Integrationは、反復型開発プロセスを行う際に多かれ少なかれ取り組まざるをえない基本的なプラクティスであるといえます。そのため、これらの3点はRUPで掲げているプラクティスと共通します。但し、RUPが機能テストや性能テストが強調されているのに対して、XPは単体テストが強調されている点で少し趣きが異なります。このスタンスの違いは、変更をどの程度許容するかとポリシーの違いに根ざしているように思えます。このポリシーの違いについては以降の節で再び触れます。
   反復型開発プロセスの実践面でXPがRUPと異なるのは、1週間程度と相対的には短いリリースサイクルを課している点です。RUPでは、一般的なリリースサイクルが2-6週間とされていることと比較すると1週間というリリースサイクルはかなり過激だといえます。1週間という短期のリリースサイクルは、以下のような利点があります。 collective ownershipやpair programmingは、このような短期のリリースサイクルを実現するためには必然となるプラクティスかもしれません。すなわち、XPのように短期のリリースサイクルを実現するためには、成果物の説明やレビューに必要以上に時間を割くこともできませんし、他人の犯したミスを官僚的な態度で高みの見物することも許されません。その点で、collective ownershipやpair programmingのように開発成果物に関して複数の開発者が理解し、責任を持つというアイデアは非常に合理的だと思います。
   但し、このような短期のリリースサイクルはチーム規模が大きくなり、コミュニケーションや管理上のオーバーヘッドが増大すると実行困難になります。またアーキテクチャの検討等2週間を超える期間が必要な検討をどのように実行するかについては課題が残ります。


2.2.3   40-Hour week

   RUPでは、残念ながら週40時間以下の労働時間をプラクティスとして推奨していません。不思議なのは、わざわざこのようなことをプラクティスとして掲げている点です。私自身が見知った限りでは、そもそも週40時間以上働いている米国の開発者がそれほど一般的だとは思えません。その点からすると、このプラクティスはそもそもソフトウエア開発が根っから好きな開発者が過度に仕事をしないように自分自身を戒めるために存在するのではないかと思います。従って、このようなプラクティスの趣旨には賛同できますが、プラクティスとして掲げることの意義については疑問を感じます。


2.2.4   Pair programming

   Pair programmingは、XPでもっともユニークなコンセプトだと思います。RUPにはこれに該当するようなプラクティスは存在しません。Pair programmingには、以下の3点の効能が考えられます。 教育としては、究極のOJTであり、pairを組む双方の開発者にとって学ぶ点は多いのではないでしょうか。また、従来のレビューのように第3者による表面的でバッチ処理的なレビューに留まらず、理解を共有している開発者当事者間でリアルタイムのレビューが実施されるため、間違いを効率的に補足できる可能性があります。最後に、プロジェクトチームから開発者が出入りしても、影響を受けにくい方式(人間系の2重化)だと言えます。
   但し、実践上の疑問点もいくつかあります。1点目の疑問点は、pairを組む開発者間で相性や能力の面で適合する条件がかなり厳しいのではないかという点です。適合しなければ、かなりの軋轢を生じるため、ストレスが高まる可能性があります。2点目の疑問点は、教育的効果が生まれたとしても早晩馴れ合いになってしまって、効果は持続しないのではないかという点です。開発者のペアのローテーションを行うことにより、馴れ合いをある程度防止できると思いますが、それでも長期的な効果を期待できるかどうか疑問です。
   私自身も、かつて米国でいくつかのソフトウエアの国際化を実装レベルで手伝ったことがありますが、その際に1つの画面、キーボード、マウスを共有するpair programmingと似たような状況を置かれたことがあります。その際には、短時間の割には持続的に緊張を強いられ、自分のペースで物事を考えられなかったためかかなり疲れた記憶があります。1,2日の経験なので慣れてないことも影響しているかもしれませんが、pair programmingは本質的にストレスが溜まる開発方式である可能性もあると私自身は思っています。だから、週40 時間以上実践すると精神衛生上危険かもしれません。


2.2.5   Refactoring

   RUPでは掲げていないXPのプラクティスの中で、一番悩ましいのはrefactoringです。RUPでは、推敲フェーズの終わりで開発成果物を構成管理システムの管理下に置き、以降変更は変更管理システムで管理するという方法を推奨しています。すなわち、推敲フェーズまでは変更をそれほど管理せず、作成フェーズ以降は不必要な変更は認めないというポリシーを推奨しています。もちろん、RUPでも作成フェーズ以降でrefactoringを必要な変更として認めることは可能です。このような違いを、XPは"勇気"を持って積極的に変更を行うことを推奨するのに対して、RUPは変更をある程度"許容"できるものであり、一般的には"管理"すべきものであると表現することはできるかもしれません。このポリシーの違いは、pair programming以上に大きな違いといえるかもしれません。
   refactoringは、ソフトウエアをより保守性、拡張性の高いものへと発展させるための現実的な技術だと思いますが、費用対効果や開発期間の制約の下でどの程度実施する(できる)かの判断の点で難しい面があると思います。さらに、XPが掲げているsimple designやYou're Not Going to Need It(YAGNI)というプラクティスとrefactoringというプラクティスがどのように整合し、結果としてXPが目指している変更コストの増大を防ぐための設計構造を実現できているのだろうかという点に関して疑問が残ります。この点に関しては、私自身の研究とも関わる疑問なので、今後XPを適用するプロジェクトがあればぜひ成果物を計測し、その成果物の設計構造の変化や変更コストの推移等の点で分析したいと考えています。


3   T6「Multi Paradigm Design for C++」

   過去読んでもっとも感銘したC++関係の著作Advanced C++ Programming(邦題:C++の筋と定石)の筆者であるJames Coplienさんの講演をライブで聞けるということで非常に講演を楽しみにしていました。実際に講演を聞いた際に得た印象は、少しきつねにつままれたようなものでした。
   講演は、C++のプログラミング言語の長所を最大限に引き出すための設計手法に関するものでした。講演者は元AT&T(現在はLucent Technology)のBell研に所属しており、C++の生みの親であるBjarne Stroustrupさんの同僚として長年C++の発展や設計手法に関して研究を行ってきた第1人者です。そのような講演者が最初に説明しようとしたのは、C++が単なるオブジェクト指向に特化した言語ではなく、その潜在的なパワーを引き出すためにはマルチパラダイム設計を必要とする言語だということです。
   従来のオブジェクト指向分析、設計では、ドメインの分析の対象が問題領域に限定されていました。それに対して、マルチパラダイム設計においてはまず解ドメインに対するドメイン分析を行うことが提案されています。講演の中では、テキストエディターの例が用いられましたが、この例の場合テキストエディターはコマンドやバッファーやエディターというようなより細分化された解ドメインで構成されるモデルになります。次に、これらの解ドメインモデルに対してドメインの共通性とバリエーションを分析します。その共通性とバリエーションの組み合わせが求まると、それらに対する適切な設計構造が確定します。例えば、共通なデータ構造に対して、バリエーションがタイプ、値、状態だった場合、それらを実現する設計構造としてはC++のテンプレートが適切であることが求まる等々ということです。
   結局、C++の設計を考える際に汎化、関数オーバーライド等のいわゆる一般的なオブジェクト指向モデルだけを考えただけでは不十分だということです。マルチパラダイム設計テクニックを用いた場合、設計結果として得られるクラスを呼び出すアプリケーションは非常に簡単になるというのが利点になります。その反面、2つのテンプレートクラスが互いに相手をテンプレートパラメータとして相互参照するような理解しにくい設計が生まれるような弊害も生じるようです。(講演者は、相互参照はコンパイラが解決するので心配しなくて良い、難しいことはコンパイラに解決させるべきだと主張していました)
   講演者は、パターン、OOA/D、マルチパラダイム設計の3者の関係を以下のように説明しました。
パターン固定した数の問題に対する固定した数の解を適用するテクニック
OOA/D抽象物(オブジェクト)を探すテクニック
マルチパラダイム設計複数の抽象化テクニックを探し、それらの選択肢を減少させる方法
すなわち、この3者は相互に補完的な位置づけになるというころです。ここでパターンとして指しているのは、どちらかというと問題領域のモデリングにおけるパターンとして述べていたように思います。
   講演者は最後に「この講演を聞いて混乱した人はいますか?」と参加者を問いかけました。筆者も含めて数人が手を挙げたら「目的は達したみたいですね」としごく満足げでした。
   本講演で提案している解ドメインの分析は、アーキテクチャ設計段階でメカニズムを考えるという考え方と少し似ていると感じました。両者とも詳細に立ち入らず解ドメインの構造をある程度見極めた上で、ハイレベルの設計を行うという点で類似しています。その一方で、ハイレベルな設計構造において共通性とバリエーションから設計構造を導き出すというマルチパラダイム設計で提案している考え方はかなりユニークだと思います。
   問題は、結果として作成された設計の分かり難さが本質的に避け得ないものであるかどうかという点です。なんとなく、講演者の例を見る限り、テンプレートクラスを多用している点が設計を分かり難くしている原因の一つだと感じました。さらに、一般的な開発プロジェクトで開発初期に共通性とバリエーションを明確に見出せることができるとは限らないことを考えると、このようなマルチパラダイム設計の考え方が一般的に有効かどうか疑問に感じます。一方で、フレームワークのように多数の利用者に対する共通のC++実装基盤を提供する場合には、このマルチパラダイム設計の考え方は非常に重要になると感じました。
   最後に余談ですが、講演者は講演中に現在のJavaのコンパイラーは隠しオプションレベルで既にテンプレートクラスをサポートしており、本講演の考え方は今後Javaでも適用できるようになると語っていました。Java設計者や実装者の皆さんが、マルチパラダイム設計を満喫できる日もそう遠くはないかもしれません。




アンケートにご協力お願いいたします
記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点

© 2001 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP