顧客にもわかるモデリング　オブジェクト図を“ポンチ絵”にするメリット

自分が理解しているかをモデルで意識合わせする

神崎善司氏：こんばんは。バリューソースの神崎です。今日はモデリングとか設計とかオブジェクト指向のお話ということだったので、私のほうでは、30年ぐらいやっているモデリングのあたりで、興味のあるところをお話ししたいと思います。

私は仕事柄、要件定義まわりで関わることが多いのですが、初めて関わる業種の場合、自分がどこまで理解しているのかに非常に関心がある。というか、間違ってしまうとあとの工程でひどい目にあうので、「自分が本当に理解しているのか」というのをなんとかお客さんと認識合わせしたいというモチベーションが非常にあります。

それをなんとかモデルでやりたいと長年ずっと思っているんですが、実際問題なかなか難しい。なので今日は、そんな中で私が昔から心掛けていたちょっとしたテクニックをご紹介したいと思います。

ありそうな案件をモデリングしてみると……

実際に例を使って説明したいと思います。例えばホールディングス会社傘下のグループ会社の勤怠システムを考えてみます。

グループ会社間の出向が多いので、グループ会社で統一した勤怠管理を行って、会社ごとの勤怠管理に再ログインしたくない。出向をしている人だと自分の会社と出向先で2つの勤怠を入れないといけないという話がよくあるので、「そういうのはやめたいね」という話です。それから派遣社員もいるので同じように管理したいという要求もあります。

出向している社員は所属する会社と出向先会社の両方の社員証を持っています。このグループ会社では、各々の社員を識別するために、所属社員とか出向社員とか派遣社員みたいな呼び方をしています。会社を識別するために、所属会社とか出向先会社とか派遣先会社といったような言葉を使っています。

これはプレゼンなので、こういうある程度整理された文章で示していますが、実際はこんな箇条書きはないわけですね。ヒアリングしたりホワイドボードなんかでメモを書いたり、そんな中でこちらが理解したことを確認しないとならないときに、どうしましょうという話です。

四角と線と、集約の記号。そんなのお客は「わからん」

例えば、今こういうモデルを書きました。「この認識であっていますか？」ということを確認したいわけですね。「再ログインしたくない」みたいな話とか、「個人が複数の会社に所属している」とか「出向社員というのがあるから、個人と社員を分ける」みたいなこととか、会社についても、派遣先の会社とか、所属している会社とかいろいろとあります。

そういう言葉を派遣社員や所属社員、所属会社、派遣先会社など、ちゃんと定義していきたいと思うわけですね。これらの言葉の意味を確認するためにモデルを作り、これでなんとか確認できないかと思うんですが、「わからん」と言われるわけですよ。ほとんどの場合はわからないわけですね。こんなただの四角と線で書いてこんな集約の記号を書いても「わからん」と言われるわけです。

それでどうしようかという話なんですが、ロールの表現がわかりにくいのかな？　ということで、例えば具体的な名前をクラスとして書きました。すると、社員を継承した各々の社員が出てみたり、会社を継承してみたりするわけですけど、「もっとわからん！」と、言われるわけです。継承の概念などは「ぜんぜんわからん！」と、言われるわけです。なので、どうしようかという話になるわけです。

なんとなくはわかるんですよ。こういう言葉を使っているので、なんとなくはわかるんだけど、この線のつながりが意味するものがやっぱり理解できない。これでもって私が「理解していますか？」という確認をしようとしてもほとんど無理なわけです。これをどうやって理解してもらうかなんですが、1つは先ほど書いたみたいに文章にするというのがあるんですけど、文章にすると行間が伝わらなくなるんですね。

ポンチ絵風にあればお客さんがわかってくれる

モデルと同じものを全部文章で書くということができないので、やっぱりモデルほどの表現力が出ない。それでどうしようかと考えたのが、オブジェクト図をポンチ絵風にするというアイデアです。例えば「AさんがいてAさんは所属会社の社員証を持っていて、出向先会社の社員証も持っています。各々の会社は社員証を発行しているんですね」という確認をします。

これは1つだけだとダメなので、これをいくつか書きます。いくつか書くという意味は多重度を知りたいんですね。多重度を知りたかったら、これは1対多だなと思ったらコピーして複数を表現し名前を付ける。これもオブジェクト図になります。「Bさんは？　××物産の正社員で××工場に出向しているんですね。Cさんはホールディングスに派遣社員で行っているんですね」となります。

多重度とロールが表現できるか

ただのポンチ絵だけですと、派遣会社とか派遣社員とかの言葉が失われるので、それはやっぱりロールっぽくポンチ絵のアイコンの近くにクラス図のロール名みたいにして書いていくということで理解してもらう。結局このロールもわざわざ出しているのは、とにかく出てくる言葉をきちっと定義したいという思いで表現しています。

この書き方の工夫としては、絵はクラスと考えています。なので、絵がクラスでこの名前がオブジェクトです。これは何を表しているかというと、オブジェクト図です。クラスを絵で表現するだけでもかなり理解してくれます。

理解するというよりも見る気になってくれるということですね。四角で出すとぜんぜん見る気にもなってくれないんですが、こういうふうにちょっとポンチ絵風にするだけでけっこう見てくれます。そのときに重視しているのは、やっぱり多重度とロール。その言葉は「実体を表しているのか、それともロールを表しているのか」というのをけっこう気にしています。ですから、それが確認できるような書き方をしています。

オブジェクト図をポンチ絵風にするとけっこう確認しやすいです、というのがお話ししたい1つ目です。

お客さんにはバリエーションを見せる

もう1つは話が変わってもうちょっと突っ込んだところです。例えば給与決算は所属社員だけが対象です。まぁ、自社の社員だけが対象です。工場は製品単位で勤怠管理をしています。システムを作る会社はプロジェクト単位に勤怠管理をしています。これも表現したいわけです。せっかくこういう情報があるのでこれを表現したいといったときに、これをクラス図で書いてしまうと、また「わけがわからん」という話になってしまうということです。

だからと言って書かないというわけにはいかない。何か残しておきたいわけですね。じゃあどうするかという話なんです。

先ほどは社員を継承したクラスを作っていたんですが、それをRDRA風に言うとバリエーションとして表現します。ホールディングとか工場、システム会社は「会社」というバリエーションにします。

普通、お客さんはExcelを使い慣れているのでこういう表現は至って自然に理解ができます。ここに出てくる言葉もわりと抽象的なんですが、こうやってバリエーションで補足してあると理解が進むということですね。お客さんに見せるときはクラス図は見せません。見せるのはあくまでもポンチ絵とバリエーションを見せて「会社というのはこうですよね」という話をします。

先ほどの、「給与計算は所属社員だけが対象です」みたいな話は、勤務情報の扱いみたいな表を作って、「所属社員は給与計算で、出向社員は出向元の給与計算で」みたいな整理をします。こういう表形式の整理はお客さんも慣れているのでササッとやってくれるんですね。というかたちで特化はバリエーションでやります。場合分けがある場合は表で整理します。こうやっただけでかなり理解してもらえるし、お客さんのほうでどんどん手を動かしてもらえるようになるということです。

最初はモデリング。それを絵にする

ここで「いきなりポンチ絵やバリエーションが書けるんですか？」と言うと、書けないんです。やっぱり頭の中ではモデリングをやっています。「なんかこういう構造だよね」と考えながらモデリングはやっているんですというお話がしたかったんです。

それからこの図のわかりにくさは何かというと、ある場面においての関係を書いてしまっているのでわかりにくいんです。普遍的な構造を書いているのではなくて、「ある場合はこうだよ」という話をしているので、そういうのが混じるとわかりにくいですし、線だらけになってしまいます。普遍的な構造を書いてあとはバリエーションにするということを心掛けています。

それからこのバリエーションとかは、こういった表がちゃんと書けているのはベースとなる概念があるからなんです。ですから、むやみやたらに表を出すとまたわかんなくなっちゃいます。

いろんなシステムというか、システム化する前にもお客さまはいろんな表とかを持っていたりするんですけど、その表の関わりがぜんぜんよくわからなかったり、いろんな軸で書かれているのでわかりにくいんですが、ベースがあってその上でバリエーションとか表を書くと、いろんなものがつながってくるということですね。

ですから単純にポンチ絵と表でやればいいんだという話ではなくて、モデルがあってその上でポンチ絵や表がありますというふうにします。

最後に、結局このポンチ絵はクラスを絵にしただけなんです。ですから四角だと拒否反応を示されるんですが、絵になった途端見てくれるということです。あともう1点、お客さんは基本的にオブジェクトを認識していて、クラスはあまり認識していません。ただし、抽象的に商品とか取引先という言い方はするので、クラスを指していることもあるんですけど、多くの場合はオブジェクトを認識しています。

具現化された組み合わせは、表だとわかりやすい

それから具象化された組み合わせは、表のほうがわかりやすいです。先ほどこの社員とか会社を継承したものをいろいろ組み合わせて線を引いていたんですけど、そういうのは非常にわかりにくいので、それは表にしたほうがわかりやすいです。

ただし今言ったのは本当に概念モデルのモデリングの話です。ですからこの先、ドメインモデルを書くことで概念モデルも変わると思います。今日お話したモデルは、あくまでもお客さんと話をする中で、その中の普遍的な構造はなんだろうというモデリングのお話でした。とっかかりのクラス図のお話です。極力そこを間違わないようにしたいということですね。

このあとはドメインモデルにいって増田さんが言われていたように設計したりコードを書いたり仕様化したり、みたいな話でこれをどんどん洗練して実装に持っていくというようなかたちを考えています。

ということで私のほうでは、お客さんから聞いた話をいかにモデルとして書いて、お客さんに確認をとるのかという、ちょっとTipsみたいなお話をさせてもらいました。以上です。

司会者：はい、ありがとうございました。