井上 研一 最近、オブジェクト指向関係のことばかり書いているのですが、「いまさら」感もありながら、その有用性は失われていないと思うからなのです。
その有用性とは何なのか。今日は、オブジェクト指向分析における鍵となるドメインモデリングについて、私がプロジェクトの初期に行っていることを書いてみようと思います。
顧客担当者からの問い合わせ
私は顧客先に常駐して業務システムの開発を行うという仕事を長く続けてきました。昨年起こしたアルティザンエッジ合同会社のメイン事業もそれです。
私の席に顧客担当者がやって来ました。
「○○をするシステムを作りたいと思うのだけど・・・」
ここ3年くらいは同じ顧客先で、大規模でも3〜4人で1年くらい、小規模なら1人で1か月くらいのシステムを作っているのですが、プロジェクトの発端は大抵このような問い合わせから始まります。
顧客の目の前でユースケースを描き始める
一通り顧客担当者のお話を伺ったところで、私は顧客先からあてがわれた大きめの画面でAstah（チェンジビジョン社による著名なUMLモデリングツール。Astah Communityなら無料で使えます）を立ち上げます。
まず、ユースケース図を描き始めて、伺った話の整理を始めます。この時点で、顧客担当者は私の横にいるので、私なりの言葉で説明をしながらモデリングしていきます（顧客の目の前でライブでモデリングをするわけですね）。誤解があれば、指摘してもらって修正したり、私から質問を投げかけることもあります。
クラス図も顧客の目の前で
ユースケース図に顧客の要望がまとまってきたら、次にクラス図を描き始めます。まだ、顧客担当者は私の横にいるので、引き続きライブでのモデリングが続きます。
クラス図はシステムの静的側面（有り体に言えばデータ構造）を示すので、顧客担当者が最初に持ってきた話には直接的には現れません。
ユースケース図を描きながら話した内容、私なりの理解やもともと持っていた知識を総合しながら、クラス図を起こしていきます。
昨日記事にしたカラーUMLの知識も活用します。カラーUMLではMoment-Interval、Role、Party/Place/Thing、Descriptionの4つのアーキタイプと、その関係を示したドメインに特化しないモデルが提供されています。
ユースケースにはMoment-Intervalが示されていることが多いので（顧客担当者もだいたい「○○を管理したい」という思いを持っていて、その○○がMoment-Intervalのことが多い）、それを中心に書いて、Role→Party/Place/Thing→Descriptionの順に、それぞれのアーキタイプに当てはまるクラスは何だろうと考えたり、聞いたりしながら進めていくのです。
もちろん、この時点では、それをどうやって作るか？という視点、例えばCakePHPを使うから○○Controllerがあって・・・というようなクラスは出てきません。あくまで、ドメインモデルの範疇だからです。
共同作業で共通理解を得ることの重要性
このような作業を顧客担当者の目の前で進めることで、顧客担当者と私の間で、システム化したい業務に対する共通理解が生まれてきます。
クラス図まで描いているので、単なる機能一覧ではなく、業務に特化された用語の使い方、おおよそのデータ構造、顧客担当者自身がその業務をどのように理解しているのかといったところまで、共通理解は進んでいます。
業務システムの開発において、開発者が顧客と同一（単一）の業務理解を持てるというのは、非常に大きなことです。さらに、モデリングをライブでやることによって、開発者の描いたモデルをレビューするというのではなく、顧客と開発者が一緒に作ったことになるというのも重要です。
UIプロトタイプで良いのではないか？
顧客との共通理解を進めるにあたって、UIプロトタイプを作って議論するという方法があります。情報システムの専門家ではない顧客は、実際に目に見える画面でないと議論が進まないだろうという考えがあるからです。
たしかにそうした面は否定できません。現に、私もUIプロトタイプを作ることで顧客の声を吸い上げるということを多くやっています。
ただ、最初の段階からUIプロトタイプを作ってしまうと、議論が些少な点に集中しやすく、大筋の議論をし損なうおそれがあります。いざ実装が始まり、動くものが出来はじめてから、「そもそもこういうことじゃなかったのでは・・・」という声が出て来たりするのです。
それに、開発者が全く業務を理解出来ていない時点で、どうやってUIプロトタイプが出来るのだろう？という疑問もあります。
そのため、まずはドメインモデリングをやって（分析中毒に陥っては仕方ないので、出来るだけ迅速に。軽量に。ライブモデリングは顧客の時間も拘束するので、ある程度のレベルで終了できます）、それからUIプロトタイプという流れが良いと思っています。
もちろん、UIプロトタイプによって深まった理解によって、ドメインモデルを洗練させていくのは言うまでもありません。