マーチン・ファウラー特別ラウンドテーブル 現場レポート [後編](マーチン・ファウラー特別ラウンドテーブル 現場レポート [前編] ――パターンを学べばどんな技術にも対応できる――)は、アナリシスパターンの有効性と開発作業への具体的な適用方法をめぐる議論を中心にお送りする。「まだいまのところはアナリシスパターンを使ってエンタープライズアプリケーションを構築するところは少数派」だとファウラー氏がいうように、アナリシスパターンの普及は今後の課題でもあるようだ(ラウンドテーブルの参加者は下記を参照)。
萩原 では少しアナリシスパターンについて話をしましょうか。それではファウラーさん、どうぞ。
ファウラー アナリシスパターンは単一モデルと複合モデルの両方に関連した概念です。アナリシスパターンによって、利用しようとする概念モデルの大部分を得ることができます。アナリシスパターンはまた、抽象レベルでも具象レベルでも利用できますが、抽象レベルのアナリシスパターンに移行していくに従って、具象レベルでの利用には厳密になっていくことでしょう。なぜなら複雑なビジネスプロセスをコントロールするために単一モデルで表現しようとすれば、ほとんどそれは誤りにすぎないからです。それに比べて複合モデルのいいところは、具象レベルから逃れられるということです。それは開発における苦痛をかなり和らげてくれます。
私自身も日々学んでいて、自著「アナリシスパターン」(Analysis Patterns: Reuseable Object Models、Addison Wesley)の最新版では、コードサンプルを盛り込みました。なぜなら正確なコードというのは、パターンを例示するのに非常に役に立つからです。中には分析にコードは必要ないといってこれを嫌がる人もいます。しかし、私はそうは思いません。コードはパターンを説明する助けとなります。たとえ、アナリシスパターンや概念モデルについてよく知っていたとしても、コードというのは、そこで何が起こっているのかを正確に説明するのに最適なのです。私のWebサイトではコードを記述する言語としてここ2、3年Javaを使ってきましたが、将来的にはC#などほかの言語を混在させていこうと思っています。
企業情報システムを構築するアーキテクトは、アナリシスパターンを理解しておく必要があると思いますね。これこそがエンタープライズアプリケーションを構築するコンポーネントだといえますから。しかし、まだいまのところはアナリシスパターンを使ってエンタープライズアプリケーションを構築するところは少数派だといえます。
羽生田 ですが、少なくとも日本では、アナリシスパターンの利用は難しいと思います。アナリシスパターンは基本的に概念的な“モデリングツール”ですが、概念モデリングの主たる目的は、コンセプトやアイデアを開発者や部門ユーザー、その他の利害関係者と共有することにあります。そのためモデルはできるだけシンプルでなければなりません。アナリシスパターンは、すべての人が理解するには難し過ぎるのです。
ファウラー 確かに、すべての人が理解するにはアナリシスパターンは難し過ぎるでしょう。しかし、業務が複雑なら当然、モデルは複雑になります。概念モデルを部門ユーザーと共有するなら、正しい人を選んで、そのモデルを少しやさしくし、注釈を付け、図版も添えて、一生懸命に説明することです。
そこで、絶対にしてはならないのは、許される範囲を超えてモデルを単純化することです。概念モデルが理解できないのなら、その部門ユーザーは開発プロセスに参加すべきではないでしょう。これまでは、部門ユーザーが理解できないのをいいことに開発者だけで勝手に進めるということも往々にしてありました。しかし、これはこれでうまくいきません。私は部門ユーザーが選択した言語を使うことにしています。これは非常に効果的です。繰り返しますが、コミュニケーションは必要であっても、そのために複雑なモデルから逃れようとしてはいけません。業務に複雑な問題があることは否定できません。それに立ち向かわねばならないのです。
平澤 「アナリシスパターン」の中で、多重分類(multiple classification)が紹介されていましたが、あれには驚き、正直いうと混乱しました。現在、多重分類を紹介されたことをどのようにお考えですか。
ファウラー いまならもっと慎重にやったでしょうね。純粋な概念モデリングの観点からいえば、多重分類は非常に価値が高く、合理的で効果的な技術です。ただ、エリック・エバンズ(Eric Evans、「Domain-Driven Design」の著者)がいっているのですが、開発者や部門ユーザーと会話する目的で使うときは、気を付けなければいけません。多重分類は、開発言語ではサポートされておらず、コードの中では意味を成さないからです。それ故、開発言語の中で使うときは気を付けなければなりません。私が本に書いたときは、クラシフィケーションの異なった実装方法を紹介できるということに夢中だったのですが、開発者とのコード中でのコミュニケーションを難しくするということは気付いていました。私がいま「アナリシスパターン」を書き直すとしたら、もっと多重分類の利用を遠慮していたでしょうね。
平澤 その意見には私も賛成です。
ファウラー 概念的な問題を単純化してくれるものなので、絶対使うなとまでいう必要はないと思いますが、いまではもう少し気持ちが後ろ向きです。本に書いたときはあまり心配していなかったんですが。これは本を執筆後にいろいろ学んで私の考えが変化した部分ですね。もう、エリック・エバンズと多重分類についてどんな話をしたか覚えていないんですよ。でも、彼とはもっと協業を深めたいと思っています。
◆ 長瀬嘉秀(テクノロジックアート 代表取締役社長)
◆ 萩原正義氏 (マイクロソフト デベロッパーマーケティング本部 Software Architect)
◇ マーチン・ファウラー(Martin Fowler)氏 (Chief Scientist,ThoughtWorks)
◇ 斉藤信也氏(NTTデータ 公共システム事業本部 技術統括部 オープン技術推進担当 部長)
◇ 鈴村幸太郎氏(日本総合研究所 事業化技術センター マネジャー)
◇ マイケル・ダイクス(Michael Dykes)氏(マイクロソフト EPGエンタープライズサーバービジネス本部 アプリケーションプラットフォーム推進部 ソリューショングループ ソリューションスペシャリスト)
◇ 巻山展輝氏(電通国際情報サービス 産業ソリューション事業部 コンサルティング1部)
◇ 平澤章氏(ウルシステムズ テクノロジディレクター)
◇ 山田正樹氏(メタボリックス 代表取締役社長)
◇ 羽生田栄一氏(豆蔵 取締役会長)
◇ Gregor Hohpe(Integration Architect,ThoughtWorks)氏
Copyright © ITmedia, Inc. All Rights Reserved.