[2008 年 1 月号]
[突撃インタビュー]
2007 年 9 月にモデリングフォーラムの基調講演を行うために責務駆動設計の主唱者である Rebecca Wirfs-Brock さんが来日されました。その際、オブジェクト広場編集部ではインタビューを実施しました。その様子を、2 回に渡りお届けします。
Rebecca Wirfs-Brock さん (以下、レベッカさん) は、責務駆動設計 ( Responsibility-Driven Design ) の考案者です。また、「Object Design : Roles, Responsibilities,and Collaborations (邦訳： オブジェクトデザイン - ロール、責務、コラボレーションによる設計技法) 」と古典的な名著となった「Designing Object-Oriented Software」の主著者でもあります。
前編のインタビューでは、主に責務駆動設計についてお伺いしました。
-- 最初に、責務駆動設計について質問させてください。レベッカさんは、関係を表現するための構造化役 (structurer) という概念を利用されていますが、初期の設計では、関係の多重度のような詳細な部分は、それほど重要視されていません。なぜそのように考えられるのでしょうか？
以前は、構造や関係がどのようなものかを理解することが重要だと考えていました。 しかし、最初から詳しく設計しすぎると、細かなところに議論が集中しがちになることに気がつきました。 たとえば、クラス間の関係を考える際にも、0 対多 なのか 1 対多 なのかといったことだけに注目してしまいます。 現在は、初期の段階では集約や複雑な構造を持つオブジェクト間の 関係だけを大雑把に理解し、後の段階で詳細化 することが重要だと考えています。関係の詳細も重要ですが、最初から考える必要はありません。
-- 日本では Jacobson の 3 つのステレオタイプ、BCE ステレオタイプ (*1) が非常にポピュラーです。 レベッカさんは、 6 つのロールステレオタイプ (*2) を提唱されていいますが、なぜでしょうか？ 3 つでは不足していますか？
いい質問ですね。ステレオタイプは、アイディアを生み出し、アイディアを元に設計するためにあるものだと思います。 アイディアを生み出すために、バウンダリ・コントロール・エンティティの 3 つでは十分ではありません。 6 つのロールステレオタイプもアイディアそのものではありませんから、十分とは思いません。しかし、設計に関するアイディアや議論を、BCE の 3 つのステレオタイプよりは多く生み出せると思います。
BCE でコントロールとされるオブジェクトは、オブジェクト間で責務を移動することで調整役にも制御役にもなります。もし調整役がなく、コントロールしか存在しなければ、調整役と制御役の違いを表現する手段がなくなってしまいます。 バウンダリの責務を説明するのは難しいですね。エンティティは、6 つの中ではおそらく情報保持役に相当するのでしょうけれど、構造化役なのかもしれないですね。
また、最近は Eric Evans さんの Domain-Driven Design の考え方も設計に取り入れられるようになってきました。Evans さん のドメインオブジェクトや責務の考え方は、ロールステレオタイプと 競ったり対立したりせず、非常にうまく補完しあうものだと思います。特に永続化に対する「エンティティ」、「集約 (Aggregates)」、「集約のルート (Aggregates Roots)」 のようなロールは、ロールステレオタイプとよく馴染むと思います。
-- ロールステレオタイプは、ただオブジェクトを発見し、設計するためだけではなく、 既存の設計をモデル化するためにも使うことができますよね？
ええ、そうですね。また、既存の実装を理解するためだけでも構いません。 コードにどんな種類のステレオタイプが存在するかを理解できますし、また、なぜこのオブジェクトがこのパターンに存在するのか、どんなロールを演じているのか、という感じでデザインパターンを理解し、解釈するためにも使用することができます。
もう 1 つのロールステレオタイプの使い方として、複数のステレオタイプを一緒に用いることができます。そうすることでオブジェクトをより賢くし、委譲型制御スタイル (*3) を進めることができます。情報保持役がサービス提供役になることはよくあるし、サービス提供役が情報を持ち続けることでより賢くなります。これは、BCE では表現できませんね。
-- ところで、BCE ステレオタイプはアメリカでもよく使われているのでしょうか？
私自身は、あまりポピュラーだとは感じていません。 アメリカでは、BCE ステレオタイプを使っ たオブジェクト指向分析を行っている人は少ないように感じます。 ロバストネス分析はほとんど使われていません。 ほとんどの人はユースケース、あるいは要求を収集、定義してから設計を行っているように感じます。
Rational Unified Process (RUP) を利用している人でも、BCE を元に考えてはいないようです。おそらく、ドメイン駆動設計（Domain-Driven Design）を適用するまででもありませんが、ドメインモデルを用いる方法がより一般的だと思います。
-- 責務駆動設計や CRC カードを、大きなプロジェクト、たとえば 100 人以上の開発者が関わるプロジェクトでも利用できると思いますか？
責務駆動設計のテクニックが小さなプロジェクト向けのものだとは思いません。どんな大きさのプロジェクトでも、責務駆動設計の考え方を利用できると思います。 実際、私は数百人が関わっていた非常に大きなプロジェクトで、非常に複雑なシステムの概念モデルを責務駆動設計の原則を利用して開発しました。
90 年代初期でも、以前私が発行した書籍「Designing Object-Oriented Software」を元に、非常に大きなプロジェクトで責務駆動設計を利用した顧客がいましたよ。
ただ、プロジェクトが大きくなると、より形式的なドキュメントが必要になるので、設計ドキュメントが CRC カードだけというのは難しいですね。 そのために責務駆動設計を諦めるのではなく、必要なドキュメントを追加すればよいのです。 CRCカードより詳細なクラスの設計や、実装レベルのクラスの詳細について 知りたくなると思います。
-- そのプロジェクトにはどのくらいの人が関わっていましたか？
私が覚えているのは、開発者 80 人と、たぶん分析者 20 人ほどのものですね。開発者 100 人という状況とは少し違って、かなり大きな分析者グループがいました。
-- そのプロジェクトの人たちは、オブジェクト指向のテクニックをよく分かっていましたか？
彼達はこれまでと違うテクニックを試そうとしていて、そこに私たちの会社がコンサルティングを行い、 私が参画して教えました。言語は Smalltalk でしたね。大規模なアプリケーションで、現在も Smalltalk で動いていますよ。
-- レベッカさんは、Smalltalker ですよね。Smalltalk はレベッカさんの設計に対するアプローチや考え方に影響していますか？
私は Smalltalker 「でした」。どれだけの顧客が今日も Smalltalk を利用しているかは言うまでもないですね。 2000 年を最後に、Smalltalk を利用する顧客は居なくなりました。以降は、Java 、C# 、C++...(笑)
しかし、私の Smalltalk の経験は、Java などの新たな言語を利用する際に 「何が良いオブジェクトか？」を考えたり、設計上必要なオブジェクトを Smalltalk の経験がない人よりも多く見つけたりといった部分で役立っています。
-- Ruby や Python は使われたことがありますか ?
Python は調べたことがありません。 Ruby は最近関わるようになったところです。私自身は Ruby でプログラミングをしたことはないし、密接に関わってはいませんが、顧客に Ruby について話したり、複数のローカル・ユーザグループの人達と話したりしています。 また、私の夫である Allen Wirfs-Brock は、Microsoft のダイナミック言語部門で働いており、ECMAScript （JavaScript）の規格委員会のメンバ であります。彼から、モダンな言語の評価のために、Ruby の評価を依頼されたこともあります。
私は、Ruby は Smalltalk に似ていると思います。 Smalltalk ほどの良いデバッグ・開発環境がないのと、Ruby の実装系はインタプリタ言語として動作するので、Smalltalk の実装系より効率的ではありませんが。今は Smalltalk のような Ruby の開発環境を開発している人たちがいますね。
Web アプリケーションでデータベースにダイレクトにアクセスする際には、Rails フレームワークは素晴らしい環境だと思います。データベースの移行を行う際に、どのように移行するかを指定する必要があるところ気に入っています。(*4)
ただ、現在の Ruby は初期の Smalltalk と同じようにクラスライブラリが洗練 されていません。 Ruby はかつての Smalltalk が辿ったのと同じ道を歩んでい るように感じます。
ところで、Ruby は日本ではポピュラーですか？
-- おそらく Web 開発者にはポピュラーですが、企業のビジネスアプリケーションではまだですね。
ああ、思ったとおりですね。でも、Web アプリケーションでは、Ruby の将来は約束されているように感じます。
-- レベッカさんは、なぜ「良い設計」が開発者や利害関係者にとって重要だと思いますか？
良い設計でなければ、メンテナンスのコストが非常に高いからです。 メンテナンスのコストが高くつくのは当たり前だと思われているので、良い設計を行うことに真剣に取り組まなくなっています。 しかし、設計を注意深く行うことで、新しい機能を追加する際のメンテナンスのコストを劇的に下げることができます。 責務が分散されている設計は、メンテナンス、サポート、新たな機能追加が行いやすくなるでしょう。 良い設計をするということは、最初から完璧な設計をしよう、という意味ではありません。設計は常に改訂し、リファクタリングしていく必要があるものです。
-- もっと一般的に言うと、投資に対するリターンをより大きくするために、とも言えますね。
ええ、ただ、それは長期の投資であって、短期ではないんですよね (笑) 。難しいところですね。 アメリカでは、長期の投資は好まれません。ですので「信頼してください、もし良い設計を行えば新しい機能をもっと簡単に追加できるようになりますよ。」と言っても、「我々は昨日利益を得る必要があったんだ。」と言われてしまうこともあります。
-- またそれが良い「設計ストーリー」を伝えなければならない理由ですよね。
そうですね。なぜなのか、もし行わなければどうなるかを伝えることですね。
面白い話があります。ある経営者たちが「リスクを無視する」ことについて話していました。 彼達は、リスクがあるかないか、つまり白か黒で考えるのです。 したがって、リスクがあれば何もしないのです。もし、このようにリスクのある選択肢を無視すると、それ以外の選択肢で彼らを納得させるのは難しいでしょう。 このような状況を克服するのは難しいですし、このような偏った考えを払拭するのも難しいですね。
私が良い設計ストーリを伝えているときでも、聞き手は既に自分の偏った考え方に入り込んでいて、受け入れないこともあります。
-- 「良い設計」とは何なのでしょうか？たとえば、質であったり、構造の美しさであったりするのでしょうか？
これは面白いところですね。「良い設計」は「十分に良い設計」と異なります。Scott Ambler さんなどは、 just barely good enough modeling (*5) を提唱していますが、私は「十分良い設計」は実のところ十分ではないと思っています。 シンプルなものの中には、シンプル「過ぎる」ものもあります。問題が複雑である場合、その解決策も複雑になりがちです。その際は、コードも分かりやすいものになるとは限りません。複雑であり、シンプルにできないためです。理解できるものである必要はありますね。
「良い設計」とは、将来起こりえると思うことや、減らしたいリスクを考慮しているものです。また、結果としての実装が、安心して使えるものであり、メンテナンスしやすいものである必要もあります。
また、設計は変更に耐えるものでなければありません。設計に何一つ追加できないのは良くないですよね。 将来起こりえると思うことを考慮した、分かりやすさに関する適切なバランスが必要ですね。また、2 年前には良かったものでも、5 年後にはよくないものになる場合もあります。その場合は、新しく作り直したり、考え直したりする必要があります。
-- レベッカさんは書籍内で、UML 図をあまり多く使用されていませんね。いつ、どんな目的で UML 図を利用しますか？
あら、書籍では 1 章丸ごと、書籍の 10 ％ 分 UML について書いていますよ (笑) 。 「書籍で UML について書きすぎだ。」というコメントをもらったことがあるほどです。 実際、私は UML を非常によく使います。 開発初期で、打ち合わせの際に、他の人とモデリングに取り組む際は、CRC カードだけではなく、シーケンス図も利用しています。
私は UML に反対というわけではありません。クラス図は非常に重要だと思います。注意深く良い UML 図を描くことは設計のドキュメント化のためにも必要です。 実際、最近、私は顧客向けに「実践的 UML」というトレーニング・コースを開発しています。 しかし、UML をどう上手く使うかということに関しては他の方が既に書籍で述べていますので、私は詳細には述べませんでした。
ただ、もっと多くの人に、かつ効果的に UML を利用してもらうことはなかなか難しいですね。
-- 私自身は、UML クラス図は設計の初期では形式的で、厳密すぎると感じています。どちらかというと、ホワイトボードや紙に、クラス名と責務などだけを箱に書いていくスタイルが好きですね。
ええ、そう思います。 UML は、「やらなければいけないからやる」ものではなく、何らかの側面を説明したいとき、たとえば、継承や、フレームワークやドメインモデル内のクラスの関係、また設計した階層がどのように機能するかなどを説明したい場合に使います。 これらの作業は、設計の早い段階ではなく、ある程度設計を行った後だから出来ることです。このとき、UML は非常に表現力が豊かで、使いやすいものです。
ただ、このときも、私は、UML 図が形式的になり過ぎないように、図で全てのことを説明しないようにしています。 設計で重要な、特定の部分を説明するために使うべきだと考えています。
私が UML2.0 で好きなところは、省略記法が利用できるところですね。省略記法を使うことで、クラス図の一部だけに注目して説明することができます。この注釈はクラス図のどこにでも、たとえば、操作区画、継承階層、クラスに記入することができます。ほとんどのツールはサポートしていませんが、 Pavel Hruby さんが公開している Visio プラグインは、図に注釈をつけることが出来るのでお勧めです。
以上が、前半の内容です。後半では、テスト駆動開発や、レベッカさんが最近興味を持っておられる技術について伺います。ご期待ください。
オブジェクトデザイン ロール、責務、コラボレーションによる設計技法
| ©2008 OGIS-RI Co., Ltd. |
|
