RUP vs. XP Reports -オブジェクト指向2000シンポジウム　聴講レポート-

ObjectSquare

[レポート]

RUP vs. XP Reports
-オブジェクト指向2000シンポジウム　聴講レポート-

株式会社オージス総研オブジェクトテクノロジー・ソリューション部
赤坂英彦

■ はじめに ―― オブジェクト指向2000シンポジウム(OO2000Sympo.)

オブジェクト指向2000シンポジウム(OO2000Sympo.)

去る8/30(水)～9/1(金)の3日間、明治大学にて「オブジェクト指向2000シンポジウム」が開催されました。私は初日と最終日に参加しました。学会開催(産学共催)のこのシンポジウム、参加された人数は200人を超えたそうです。しかし、昨今のオブジェクト指向の普及度を考えると、少し寂しい人数のように感じてしまいます。私自身もオージス総研の社員でなかったら、その存在すら知らずにいたかもしれません。もう少し、積極的にコマーシャルしてもよいのではないかと思います。

■ Rational Unified Process vs. eXtreme Programming (RUP vs. XP)

エンジニアリングを目指す普及型の開発方法論(RUP)とエンジニアの間で人気沸騰中の開発方法論(XP)の対決

日時：8/30(木) 13:00～15:00
講師：[RUP]藤井拓(オージス)、[XP]平鍋健児(永和システム)、梅澤真史(オージス)

私にとって、今回のシンポで受講した全てのセッション中、一番楽しかったものだった。これは、エンジニアリングを目指す普及型のRational Unified Process (RUP)と、かなり尖がった最近エンジニアの間で人気沸騰中のeXtreme Programming (XP)という２つのホットな開発方法論の対決である。最近のXP-Jpメーリングリストの異常な盛り上がりを受けて、エキサイティングなXPにエンジニアの魂は奪われてしまった感がある(もちろん、私もそのひとり！)。

Rational Unified Process (RUP) -適用範囲の広い、Heavy weightな開発プロセス

先攻のRUPは、藤井さんがXPに負けまいと、当日、講演直前まで控え室で4枚も追加ページを書いていたけど、残念ながらRUPには新鮮味はない。しかし、RUPはさまざまな手法の集大成だけあって、その適用可能プロジェクトの範囲では敵なしといったところ。様々な経験から導き出されたベストプラクティスを実践できるように開発プロセスを定義しているこのRUP、確かに正しいことばかりだ。ただ、自分達のプロジェクトに上手く適合させるには優先順位の整理を行い、ワークフローの採用、未採用を決定しておくことが必要になってくるだろう。このため特定のアプリケーションドメインに適合させた反復ワークフローの例がロードマップとして提供されているそうだ。裏を返せば、そうでないとあまりに膨大で使えないとも考えられる。残念なのは、RUPは既にあるベストプラクティスの実践に基づいた開発プロセスであるため、カスタマイズ可能であるといっても、大胆なプロセスの改善は期待できないことだ。GEの例を見ればベストプラクティスは常に考えていくものであるが、RUPでは固定されてしまっている。この部分はRUPのバージョンアップに期待(つまり依存)するしかないのだろうか。とはいえ、現時点で様々なプロジェクトに適用できるこのRUPは凄い。構築フェーズ以降の低いリスクによるプロジェクトの安定感は素晴らしい。

補足的にUSDP(ヤコブソン)の話しもあった。RUPを区別する必要があるのか疑問だが、こちらの方がスリム化していてまだましなのだろうか?。

eXtreme Programming (XP) - Light weightでPeakyな開発プロセス

後攻のXPは、まず平鍋さんがXPの概説、続いて梅澤さんが実戦経験を面白おかしく紹介する。繰り返しになるが、内容の面白さから言って、エンジニアの興味をどれだけ惹くかという点ではこちらの圧勝の感は否めない。
Embrace Change(変化ヲ抱擁セヨ)は、早期に要求をFIXすることは無理という最近の常識をもっと突き進めて、変更コストの増加カーブを減らしてしまえ！という無謀ともいえる愉快な戦略だ(笑)。
4つの価値(Communication、Simplicity、 Feedback、Courage)はとても人間的なものだ。12のプラクティスの目玉(受講者の関心)は「Pair Programming」(梅澤さんいわく「ペアプロ」)だ。また、「40-HourWeek」の響きは残業漬けのエンジニアにはいっそう心地よい。
忘れちゃいけないのは、「Simple Design」と「Testing」だ。これらのプラクティスは、『リファクタリング』を使ってソフトウェアを常にシンプルに変更しやすく保つための実践事項である。しかし、ほんとにドキュメントを書かないでメンバー全員がシステムを理解しているなんて、従来の常識では想像も出来ないことだ。出来る顧客を「On-siteCustomer」として開発チームに拘束し、「Planning Game」でプロジェクトを楽しみ、機能テストでモグラ叩きならぬバグ発見をさせるなんざぁ、今の日本の商習慣では不可能としかいえない。
設計戦略はまた面白い。「You're Not Going to Need It(YAGNI).」(今必要なければやらない)とは、従来の、変更を予想して拡張性を持たせるのを良し、としたエンジニアの良心を否定していて妙である。しかし、これ位の潔さがないと、変更コストの増加は無視できないであろう。でも、こんなやり方で本当にうまくいのか不安になってくる(笑)。

梅澤さんの実践XPは面白かった。会場も大いに盛り上がった。
さすがに実践してみないと分からないXPの短所としては、ペアプロのため、会話がにぎやかになり (というかうるさい!!)周りの他のチームにとっては迷惑だということ。できれば隔離されたスペースが欲しいところか。また、このペアプロは、思考の硬直化を防ぐためローテーションしていくのだそうだ。1日に何度も、設計実装の帽子とリファクタリングの帽子を適宜被り換えていくという徹底ぶりだ(帽子は役割のことだが、実際にはこれらの帽子(ハット)は見たことない(^^;;)。
しかし実践してみるとペアプロはもの凄く疲れるとのこと。その代わり、士気は猛烈に上がるとは羨ましい限りだ(傍目で見ていてもそれは良く分かった)。その他、Communicationの促進(および疲労回復)のため、メンバーをお菓子付けにすることがポイントだそうだ(笑)。

RUP vs. XP

最後に、RUPとXPの比較を行ったが、特に白黒をつけるものではなかった。藤井さんはXPにRUPとの共通点を見出して勝負を避けようとしていたが、以前あった「XPは RUPのインスタンスなのか」のような話しに対して、梅澤さんの「(XPのフィーバーにあやかって、)あれってRUP側が勝手に言ってるだけですよね？XP側は――、気にしちゃいないですよ」に会場は大爆笑。

■ まとめ ―― 感想

私なりに考えてみたXPの適用可能なプロジェクトは、以下の条件を満たすことが必須だろう。

要求は顧客と一緒に育てるもので、開発者は「勇気」を持って変更を受け入れること。

チームメンバーが少なく(4名～8名程度)、過半数はデキる人であること。

メンバーはお互いを尊重し、議論可能で、引き際を心得ていること。

メンバーはペアプロで疲れても、お菓子とジュースで復活できること。

メンバーはまずテストを考えないと設計も実装もできないこと。

メンバーはSimpleを良しとし、変更することは「勇気」だと信じていること。

上記の条件を満たすためには、あらかじめ(On-site Customerを含む)メンバーをマインドコントロール(要は洗脳)しておくことが肝要(!?)だ。XPにおいてプロジェクト開始時点のキックオフミーティングは、別名、イニシエーションと呼ばれるらしい(私が言ってみただけ(^^;;)。その他、予め要求が確定しておらず、システムの仕様をお客様(On-site Customer)と一緒に考えながら、システムをどんどん開発していくというスタイルになるため、お客様の技術的スキルの高さも見逃せないポイントだ。イニシエーションだけではなく、既にスキルの高いお客様をプロジェクトに拘束するための手段(従来なかったスキル)が求められている(!?)。

RUPにXPの良い所を利用するとすれば「Testing」だろうか。まず、テストを考えるという姿勢だ。しかし、本来そもそもこうあるべきなのだが(笑)。「Coding Standard」は当たり前だが、レビューのタイミングでチェックするRUPに対して、ペアプロで日々チェックしているXPの方が徹底されるだろう。どちらも繰り返し型の開発なので「Small Release」なのは一緒のような気がするが、イテレーション(1回の繰り返し単位)が2,3ヶ月のRUPと最大2週間のXPではそのSmall加減が桁違いになるだろうことは容易に想像できる。しかし、結局のところ、RUPはさまざまな手法の集大成だけあって、実際のプロジェクトへの適用可能性という点では、4～6名チームで最適だというXPには手も足も出ないところ。
広く適用することを良しとするか、(プラクティスもメンバーの人数も)限定的な範囲でピーキーにいくのを良しとするか、の違いであろう。

どちらの開発方法論にも共通しているのは、良いシステムを開発しようということは当たり前として、重要なリスクに対応するということだと思う。しかし、大きく違うのはそのアプローチだ。RUPはスキルの高いアーキテクトによって、安定したアーキテクチャ・ベースラインを早期に確立することでリスクを軽減する。これに対して、XPは顧客を巻き込んで、開発者同士と顧客との間のコミュニケーションを最大限に活用し、一緒に良いシステムを作り上げようとするもので、「勇気」を合い言葉に「変更」というリスクに対処する。

XPの「Metaphor(比喩)」についてはイマイチ掴み所がなくて良く分からない。RUPの推敲フェーズで構築される「アーキテクチャ」と関係がありそうだが、もっとシンプルなものらしい。しかも、これはキックオフならぬイニシエーションにも有効なため、プロジェクト開始時点で考えてしまうものではないかと想像する。書籍で例えるなら、G.M.ワインバーグの著書(例えば『スーパーエンジニアへの道』(共立出版))やブルックスの『人月の神話』(アジソン・ウェスレイ)やエドワード・ヨードンの『プログラマーの復権』や『デスマーチ』(トッパン)などを見ていただければ分かると思う。各章のはじめのことわざとか寓話などの引用部分がMetaphorである。この先、どんな話しなのかを連想させる(私には良く分かんないんだけど(^^;;)。一方、各章の中身がRUPのアーキテクチャ(ドキュメント)になる。この文章を見て、構築フェーズ以降を少ないリスクでガンガン開発するのだ。と、言ってみたものの、本当にそうなのかはかなり怪しい(笑)。

ちなみに、初日に行われた懇親会のとき、偶然トイレで平鍋さんに出くわした。そのときの平鍋さんの言葉「でも、なかなかXPで開発って出来ないよねぇ」を忘れることができない。また翌日、NK-EXAの児玉さんから頂いたメールの「平鍋さんの話によると，Coplien(※)はＸＰには近づかない方がいいと言っていたとか。」(※ Coplien氏は今回のシンポジウムの基調講演をされた方で、『C++の筋と定石』などの著者としても有名)という意見も覚えておこう。

RUP vs. XP - 私の結論

私なりにRUPvs.XPの評価をしてみたいと思う。
まず、プログラマの帽子をかぶった私。断然、XP!!、だって、開発者としてこっちの方が楽しそうではないか。
次に、コンサルタントの帽子をかぶった私。断然、RUP!!、だって、属人性を排した方が安全じゃないですか。
どちらにしても、デスマーチプロジェクトからの脱出を助ける救世主ではないことは確かなようだ。
もちろん、上手く開発しているチームにとって、更なる向上を目指すには(どちらも)強力なツールであることは間違いない(だろう)。

結局のところ、私の好きなTVドラマは先日最終回を迎えた三谷幸喜の『合い言葉は勇気』(Smapの香取慎吾ちゃん出演)だったし、愛用のG-SHOCKはX-tremeなのである(^^;;。