　図4のように1つに集中するモデル図は、センスの良くないモデル図です。クラス図などでありがちなモデル図ですが、センターとなっているクラスの負荷が大きすぎます。きっとCenterは仕事を頼まれたら断りきれない優柔不断な何でも屋になっているでしょう。もちろん、Centerを作ってしまったモデラーが犯人で、Centerはその被害者です。そして、その結果、このCenterは借金で首が回らないクラスになっていて、周りのクラスに迷惑を掛けることになります。このように、このモデル図から、将来の悲惨な運命が浮かんできます。蜘蛛の巣モデル図で除霊をした方がいいかも知れません。

図4. 集中型のモデル図

　図4の集中型モデル図は、何も考えずにモデリングすると、このような図になってしまう可能性があります。このモデル図を第三者が見ても、その意図はセンターになっているもの以外は分かりません。まるで理解しにくい図になっています。またこのように集中してしまうと分散できず拡張性に乏しいものになり、ますますセンターに集中するようになります。

　集中型にしないためには、それぞれに役割を決め、適当にその責務を分散させることです。Aに関してはクラスAが全責任を持って担当し、Bの仕事に関するものはクラスBがとにかく最初に受け付けるなどのように、役割の分担を常に頭の中に置いて、モデリングすることです。そして集中しているものが見つかったら、他の誰かにその仕事を割り振れないかを考えてみてください。これはきっとモデリングだけに限らず、日常業務にも適用できることでしょう。

追跡できないモデル図

　モデリングは1個のモデル図だけでなく、複数のモデル図を記述することが普通です。この失敗例は登場人物を複数のモデル図で追跡できなくなってしまった例です。例えば最初のモデル図で出てきた登場人物が別のモデル図では消滅してしまったり、最初のモデル図で登場していないばかりか、伏線も全く張っていなかったにも関わらず、次のモデル図では突然登場して主人公のように振舞っているものです。まるで最後の10ページに初登場する人が犯人であるようなB級の推理小説のようなものです。

図5. 追跡できないモデル図

　例えば、図5にあるようにユースケース図（左図）に描かれていた b のユースケースが、クラス図（右図）になったときにどこかに消えてしまったことや、逆にユースケース図では全く出てこなかった c がクラス図ではBの操作として急に現れたことなどです。ユースケース図とクラス図では粒度や詳細度が違う場合が多いので、クラス図にのみ現れる突然変異種はあるのも多少なら許せますが、粒度が荒いであろうユースケース図で描かれていたユースケースがクラス図で見当たらないと問題です。きっと機能不足になっているか、要求分析のときに不要なものまでユースケースにしてしまったか、どちらかです。

　この失敗の原因でよくあるものは、それぞれのモデル図を描く人（モデラー）が違い、モデラー同士でコミュニケーションが取れておらず、モデル図の登場人物の過不足や用語の使い方が違ってくる例です。1人で描いていてこうなってしまうのは、きっと働きすぎで頭の整理ができていないのでしょう。しばらく休養を取ってください。

　追跡できないモデル図は、モデル図の保守がされていない場合にも起こります。仕様変更でクラス図は修正したがユースケース図は修正していなかった場合、このような怪奇現象が出てしまいます（こちらの原因の方がよくあります）。そして軽視されがちなのはユースケース図です。こうしてユースケース図とクラス図などと整合が取れていなかった場合、ユースケース図は信用されなくなってしまいます。

　そして面倒なことに、この失敗例は非常にやっかいです。この理由はそれぞれの各モデル図においては矛盾が生じていないので、単独のモデル図では誤りを見つけられません。要求モデリングをした人と設計モデリングをした人が会って話してみて、やっと分かる失敗です。

　モデリングツールを利用していると、ある程度はこの不整合を見つけることができます。しかし、このためには、複数のモデル図で用語や粒度などを統一して描く必要がありますが、これが行われているぐらいであれば、不整合は生じないでしょう。逆に用語や粒度が統一できないとこのような不整合が生じます。

　この失敗例から学ぶ教訓は複数のモデル図を見比べること、1個のモデル図だけで信用するなということになります。デザインレビューのときにも関連するモデル図も見て、それらと矛盾がないかを見る必要があります。

矛盾があるモデル図