本ドキュメントの利用は、https://github.com/kae-made/kae-made/blob/main/contents-license.md に記載のライセンスに従ってご利用ください。

本稿は、“Art of Conceptual Modeling ～ 概念モデリング教本”を完読していることを前提としています。概念モデリングに関する基礎知識を習得した後の、実際のビジネスへの適用にむけた、実践的なスキル獲得を支援します。
ここでは、“商品販売”という主題領域（以下、ドメインと記載します）を例に、概念情報モデル構築の流れと留意点を解説していきます。
商品を販売する具体的なプロセスは、それを提供する企業の数だけ存在し、論理的帰結として、“商品販売”に関する概念情報モデルも同数異なるものが存在しえます。ここで紹介するモデルが絶対的に正しいという事ではないことに注意してください。

※ 教本でも“商品販売”を例にしたサンプルを使っていますが、そちらはあくまでも、概念情報モデルの基礎を解説するためのモデルなので、一旦忘れてください。

また、概念モデル作成作業は、複数人がチームで行うことを想定します。概念モデルを作成する人のことを、以降、“モデラー”と呼ぶことにします。

最初の一歩

先ず、モデル化対象のドメインを簡単に定義します。
ここでは、非常にシンプルに、

- 商品を販売するコマースシステム
- お客様は、Webのページやスマートフォンアプリなどから、商品を注文する
- 注文された商品は、お客様の支払い完了後、登録した住所に配送される

で始めます。
この、非常にシンプルなステートメントを元に、クラス、特徴値、関係になりそうな候補をリストアップします。

この段階では、モデラーそれぞれがモデル化対象のドメインに対するイメージはバラバラのはずです。開発対象のシステムが扱うビジネスに詳しい人がいなければ、誰一人正しいイメージを持っていない場合もあり得ます。まずは、各自が思い描いているビジネスシーンを絵に描いて説明しあう、ビジネスに詳しい人達やステークフォルダー達も交えてディスカッションを行うのが良いでしょう。説明やディスカッションの中で出てきた用語やキーワードは、クラス、特徴値、関係の候補になるので、絵に描きこむなどしてメモしておき、後から参照できるようにしておきましょう。
この過程では、それぞれのシナリオ内、または、関連するシナリオ間の矛盾や相反する内容、一見するとバカげた事に思えるようなシナリオなども出てくるはずですが、まだまだ概念モデル作成開始直後であり、また、ビジネスはどうあるべきというような決定の場でもないので、明らかにおかしい内容は別ですが、可能な限り排除せずに残しておきます。本当に矛盾や相反なのかは、概念情報モデルの作成過程で論理的に検証が可能なので、気にせずに候補をリストアップしていきましょう。

もう一つ注意点を挙げておきます。特に初学者やプログラミング脳に染まっている人の場合は、システムのUIに気を取られないよう注意が必要です。アプリケーションドメインの概念情報モデル作成の目的は、あくまでも、ビジネスの中身をモデル化する事であり、システムにアクセスするアプリケーションのUIや操作性を定義する事ではありません。教本で解説した通り、UIはサービスドメインに分類される別のドメインとして扱うので、ビジネスが扱う本質的なエンティティを見つけることに集中してください。

初期のディスカッションを通じてリストアップされた、クラス、特徴値、関係を元に出来上がった第一版のモデルが図２になったものとします。

出来上がったモデルを吟味します。各クラス、各特徴値、各関係が、ビジネスの何を抽象化したものなのかを一つ一つ見ていきます。

商品って何？

この例では、“商品”というクラスを定義しています。概念情報モデルのクラスのインスタンスは、現実世界の、モノやコト、役割に対応付けられます。
それぞれのお客様（“顧客”クラスのインスタンス）は、商品インスタンスの中から購入したいものを選んで注文するので、“商品”クラスのインスタンスが、実際の売り物となる商品と一対一に対応付けられるなら、この概念情報モデルは正しいといえます。スーパーに陳列されている野菜や果物を購入する、あるいは、オークションサイトに出品された商品の購入のようなビジネスイメージです。しかし、一般的なコマースサイトでの購入を想像してみると、注文対象は、鉛筆でも、家電製品でも、食器でも構いませんが、お客様は、一本一本の鉛筆や、個々の電子レンジや冷蔵庫の筐体そのものではなく、鉛筆や電子レンジ、冷蔵庫という種類のカタログ情報を選んで注文するという、品物そのものを選ぶのとは異なる注文方法がありえます。モデル化対象ドメインが扱うビジネスが後者の場合は、“商品”として抽出されていた概念は、商品そのものではなく、商品の仕様なので、クラスの名前は“商品仕様”が妥当でしょう。この考察を元に、概念情報モデルを変更すると、以下の様なモデルになります。

また、商品販売においては、“商品仕様”に該当する、お客様の注文に対して、決済して納品するためにはその商品仕様に該当する品物・商品を、販売する側は保持していなければならず、今ある在庫数を超えた顧客からの注文の扱いを、ビジネスとしてどうするかの検討が必要になります。
上の図では、どうするにしても在庫数に関する情報は最低限持っていなければならないよね、ということで、“商品仕様”クラスに“在庫数”という特徴値を定義しています。
図2のモデルで定義されている、注文対象が販売対象商品の品物そのものの場合でも、カタログ仕様の様な概念を持つ“商品仕様”クラスを定義して、商品の種別と商品の品物の概念から分離しても構いません。そのように分離した概念情報モデルは図４の様になります。

それぞれの“商品仕様”のインスタンスと“商品”のインスタンスは一個づつ対応しているはずなので、図４では、二つのクラスの間で定義された関係の多重度は1：1としています。
図2で示した概念情報モデルについても、“商品仕様”に対応する在庫品を概念クラスとして定義することも可能です。その場合の概念情報モデルを図５に示します。

この場合は、一つの”商品仕様“インスタンスに対して、複数の”在庫品“が対応するので、クラス間の関係の多重度は、1：* になります。

※ “在庫品”側の多重度は0を許容していますが、ある“商品仕様”インスタンスに対して、関係づけられている“在庫品”が無い場合は、つまり、在庫切れの状態にあることを意味しています。
※ 現実の世界で仕入れている在庫品一個一個が、在庫商品のインスタンスに対応します。
※ “商品仕様”の“在庫数”は、モデリング教本で解説した“計算可能な特徴値”です。“在庫数”の値は、関係している“在庫品”のインスタンス数に一致していると考えてください。

モデル化対象ドメインが扱うビジネスの内容に応じて、図3、図4のどちらが適切かが決まります。ちなみに、どちらの場合もありうるようなビジネスの場合は、スーパークラス、サブクラスの関係を使って、顧客の注文対象が、どちらの“商品仕様”にもなるように概念情報モデルを作成するとよいでしょう。

これまで考察してきた内容に加えて、注文時には10個口以上からしか注文できないとか、複数の商品をまとめて購入すると安くなるようなセット販売など、様々なビジネスシナリオがありえます。それぞれのシナリオに応じた概念情報モデルを構築していきましょう。

顧客とは？

図２～６で示した概念情報モデルは、当たり前のように“顧客”というクラスを使っています。ここでは、“顧客”クラスについて一段深い検討を加えてみます。
まず、モデル化対象ドメインが扱うビジネスの商品販売において、不特定多数のユーザーが商品仕様を眺めて、購入したいものを見つけたら注文し、決済を経て、受注側が該当商品を発送するだけである場合を考えてみます。このケースでは、“注文”クラスのインスタンスの特徴値に、誰が購入したか、どこに送付すればいいか、という情報があれば十分なので、実は、“顧客”クラスは概念情報モデル的には必要ありません。図７に示すような概念情報モデルで事足ります。

このケースに限らず、特徴値の定義場所の見直しにより二つの概念クラス候補が一つのクラスにまとまることはよくあることなので、覚えておきましょう。

では、“顧客”クラスが必要な場合を考えてみます。
図5の概念情報モデルを使って、考えてみます。関係R1の“商品仕様”側の多重度が*になっています。これは注文が無くても顧客のインスタンスが存在できることを意味します。現実世界を思い浮かべれば、ユーザー登録や会員登録に対応すると考えていいでしょう。つまり、図７との違いは、図７の場合は、商品を注文する際、ユーザーは自分が誰であるか、配送先はどこか、（加えて決済に必要な情報も）を入力すれば注文が可能なのに対し、図5のモデルでは、注文を行うには予めユーザー登録が必要なことを表明しているわけです。
繰り返しになりますが、どちらが適切なモデルか（正誤ではない）は、どちらのモデルがより正確にビジネスを表現しているかで判断します。

多重度の検討

教本で解説した通り、関係の多重度は概念モデリングにおいて非常に重要です。ここで、図5の関係R1の両端の多重度を意図的に変えて、それぞれの場合にビジネス的な観点からどう意味づけられるかを見てみます。

顧客 0..1 – R1 – 0..1 商品仕様
一人の顧客は、商品仕様に対して注文していなくても情報として存在する。一つの商品仕様は全く注文が無くてもカタログ情報として存在する。一人の顧客は、一つの商品仕様に対してのみ注文ができ、2つ以上に対しては同時に注文することはできない。一つの商品仕様に対して注文が行えるのは同時には一人の顧客のみである。

顧客 0..1 – R1 –1 商品仕様
商品仕様に対して注文を行っているときだけ、各顧客の情報は存在できる。一つの商品仕様は全く注文が無くてもカタログ情報として存在する。一人の顧客が注文できるのは、ただ一つだけの商品仕様に対してだけである。一つの商品仕様に対して注文が行えるのは同時には一人の顧客のみである。注文が完了したら顧客の情報も削除される。

※ 「注文が完了したら」がビジネス上どんな意味を持つかは図4では触れられていないことに注意

顧客 0..1 – R1 –* 商品仕様
商品仕様に対して注文を行っているときだけ、各顧客の情報は存在できる。一つの商品仕様は全く注文が無くてもカタログ情報として存在する。一人の顧客は複数の商品仕様に対して注文できる。一つの商品仕様に対して注文が行えるのは同時には一人の顧客のみである。

顧客 0..1 – R1 –1..* 商品仕様
商品仕様に対して注文を行っているときだけ、各顧客の情報は存在できる。一つの商品仕様は全く注文が無くてもカタログ情報として存在する。一人の顧客は複数の商品仕様に対して注文できる。一つの商品仕様に対して注文が行えるのは同時には一人の顧客のみである。注文が完了したら顧客の情報も削除される。

顧客 1 – R1 – 0..1 商品仕様
一人の顧客は、商品仕様に対して注文していなくても情報として存在する。一つの商品仕様は全く注文が無い場合はカタログ情報としては存在できない。一人の顧客は、一つの商品仕様に対してのみ注文ができ、2つ以上に対しては同時に注文することはできない。一つの商品仕様に対して注文が行えるのは同時には一人の顧客のみである。注文が完了したら、商品仕様のカタログ情報は削除される。

顧客 1 – R1 –1商品仕様
商品仕様に対して注文を行っているときだけ、各顧客の情報は存在できる。一つの商品仕様は全く注文が無い場合はカタログ情報としては存在できない。一人の顧客が注文できるのは、ただ一つだけの商品仕様に対してだけである。一つの商品仕様に対して注文が行えるのは同時には一人の顧客のみである。注文が完了したら顧客の情報と商品仕様のカタログ情報も削除される。

顧客 1 – R1 –* 商品仕様
商品仕様に対して注文を行っているときだけ、各顧客の情報は存在できる。一つの商品仕様は全く注文が無い場合はカタログ情報としては存在できない。一人の顧客は複数の商品仕様に対して注文できる。一つの商品仕様に対して注文が行えるのは同時には一人の顧客のみである。注文が完了したら、商品仕様のカタログ情報は削除される。

顧客 1 – R1 –1..* 商品仕様
商品仕様に対して注文を行っているときだけ、各顧客の情報は存在できる。一つの商品仕様は全く注文が無い場合はカタログ情報としては存在できない。一人の顧客は複数の商品仕様に対して注文できる。一つの商品仕様に対して注文が行えるのは同時には一人の顧客のみである。注文が完了したら顧客の情報と商品仕様のカタログ情報も削除される。

顧客 * – R1 – 0..1 商品仕様
一人の顧客は、商品仕様に対して注文していなくても情報として存在する。一つの商品仕様は全く注文が無くてもカタログ情報として存在する。一人の顧客は、一つの商品仕様に対してのみ注文ができ、2つ以上に対しては同時に注文することはできない。一つの商品仕様に対して同時に複数の顧客が注文を行える。

顧客 * – R1 –1 商品仕様
商品仕様に対して注文を行っているときだけ、各顧客の情報は存在できる。一つの商品仕様は全く注文が無くてもカタログ情報として存在する。一人の顧客が注文できるのは、ただ一つだけの商品仕様に対してだけである。一つの商品仕様に対して同時に複数の顧客が注文を行える。注文が完了したら顧客の情報は削除される。

顧客 * – R1 –* 商品仕様
一人の顧客は、商品仕様に対して注文していなくても情報として存在する。一つの商品仕様は全く注文が無くてもカタログ情報として存在する。一人の顧客は複数の商品仕様に対して注文できる。一つの商品仕様に対して同時に複数の顧客が注文を行える。

顧客 * – R1 –1..* 商品仕様
商品仕様に対して注文を行っているときだけ、各顧客の情報は存在できる。一つの商品仕様は全く注文が無くてもカタログ情報として存在する。一人の顧客は複数の商品仕様に対して注文できる。一つの商品仕様に対して同時に複数の顧客が注文を行える。注文が完了したら顧客の情報は削除される。

顧客 1..* – R1 – 0..1 商品仕様
一人の顧客は、商品仕様に対して注文していなくても情報として存在する。一つの商品仕様は全く注文が無い場合はカタログ情報としては存在できない。一人の顧客は、一つの商品仕様に対してのみ注文ができ、2つ以上に対しては同時に注文することはできない。一つの商品仕様に対して同時に複数の顧客が注文を行える。ある商品仕様に対する全ての注文が完了したら、その商品仕様のカタログ情報は削除される。

顧客 1..* – R1 –1 商品仕様
商品仕様に対して注文を行っているときだけ、各顧客の情報は存在できる。一つの商品仕様は全く注文が無い場合はカタログ情報としては存在できない。一人の顧客が注文できるのは、ただ一つだけの商品仕様に対してだけである。一つの商品仕様に対して同時に複数の顧客が注文を行える。各注文が完了したら対応する顧客の情報は削除される。ある商品仕様に対する全ての注文が完了したら、その商品仕様のカタログ情報は削除される。

顧客 1..* – R1 –* 商品仕様
一人の顧客は、商品仕様に対して注文していなくても情報として存在する。一つの商品仕様は全く注文が無い場合はカタログ情報としては存在できない。一人の顧客は複数の商品仕様に対して注文できる。一つの商品仕様に対して同時に複数の顧客が注文を行える。ある商品仕様に対する全ての注文が完了したら、その商品仕様のカタログ情報は削除される。

顧客 1..* – R1 –1..* 商品仕様
商品仕様に対して注文を行っているときだけ、各顧客の情報は存在できる。一つの商品仕様は全く注文が無い場合はカタログ情報としては存在できない。一人の顧客は複数の商品仕様に対して注文できる。一つの商品仕様に対して同時に複数の顧客が注文を行える。各注文が完了したら対応する顧客の情報は削除される。ある商品仕様に対する全ての注文が完了したら、その商品仕様のカタログ情報は削除される。

以上、くどい気もしますが（苦笑）、初学者向けに全てを記載してみました。多重度がちょっと変わるだけで意味が全く異なることを理解いただけたと思います。読者が頭に描いていた商品販売がどんなものかによって、16通りある組合せの幾つかは奇妙なシナリオに思えるものもあるかもしれません。販売する商品や販売管理の手法によっては、16通り全て当てはまるケースがあるはずです。具体的なビジネスシーンを思い浮かべながら、それぞれの多重度の組に当てはまる具体的な事例を見つけ出してみてください。
概念情報モデルの作成過程での、クラス間の関係の定義においては、「意図的に両端の多重度を変えてみる」テストを、必ずやってみることを推奨します。それぞれが、モデル化対象ドメインのビジネスにおいてどういう意味を持つのかを検討し、両端の意味も吟味しながら、現実を正しく表現する概念情報モデルを作っていきます。

※ 余裕のある読者は、16通りのうちから2つ以上ピックアップして、ピックアップした多重度が同時に満たされるような概念情報モデルを作ってみてください。

“注文”とは？

当たり前の話ですが、通常の商品販売ビジネスでは、ユーザーから注文を受けたらそれで終わりではなく、在庫の引当て、決済、配送といったプロセスが続きます。発注の数によっては、在庫が足りず、取引業者への追加発注、製造販売業者の場合は追加生産などが行われるでしょう。また、発送についても、配送業者に外部委託している場合は梱包した荷物の発送依頼があり、配送部門を持っている会社は配送管理部門が動くことになります。概念情報モデルの作成においては、それぞれの現実に応じて概念情報モデルに概念を追加していくわけです。

モデル作成者は、この作業を進めるにあたり、以下の決断をしなければなりません。

- そのまま、同じドメインとして概念情報モデルの作成を続ける
- 異なるドメインとして分割して、それぞれの概念情報モデルを作成する

このケースでは、在庫がない場合のビジネスプロセスと、配送に関するビジネスプロセスが対象になります。どちらを選択するかはケースバイケースです。目安としては、例えば少数商品を製造から販売まで一貫して管理しているような、対象領域が目下の概念モデリング対象で扱っている主題に密接に関連している場合は前者で、様々な商品を扱っていて別ルートでの販売等も行っているなど、複数の製造パートナーと連携しているような、比較的疎な場合は後者を選択するのが良いでしょう。

複数の顧客が同時に同じ商品仕様に対して注文を行う場合、在庫の数は有限なので、当然、競合が発生します。競合状態は、ビジネスの観点から解決すべきものであるので、そのための概念や関係を概念情報モデルに追加しなければなりません。この様な競合状態は、一般的によく発生しうるものなので、“Assigner”パターンとして教本で解説しているので、そちらを参照してください。

これまでの説明の中で、“決済”という言葉が何度か出てきています。これまで示した図には、決済に必要な特徴値は敢えて入れていませんでした。クレジットカード情報や引き落とし用の銀行口座情報等がそれに相当すると思われますが、どれを使うかはビジネス上の判断なので、それに従ったモデルを作成しましょう。概念情報モデルとしての観点からは、決済情報をどのクラスに割り当てるかによって、ビジネスシナリオが変わりうることを紹介しておきます。

ユーザーが顧客登録する（＝顧客クラスのインスタンスを一つ作成する）際に、決済情報を登録して、全ての注文において、その決済情報を使う場合は、顧客クラスの特徴値として定義します。ユーザーがそれぞれの注文毎に決済情報を変えられるようにしておきたい場合には、決済情報は注文クラスの特徴値として定義します。

16通りの多重度の組の説明で、「注文が完了する」について図5のモデルは一切何も表明していないとコメントしておきました。これは実際のビジネスシナリオでどうするかを決めないとモデル化できません。逆に言えば、「注文が完了する」ことに関する概念を含む概念モデルを作成することは、具体的なビジネスシナリオを決定することに相当します。
ここでは、これまでの注文に関する議論を元に、
- 在庫がない場合は、発注業者に発注する
- 配送は、商品梱包後に、委託業者にお願いする
として、委託業者に配送を依頼した時点で「注文が完了」すると想定した場合の概念情報モデルを参考までに挙げておきます。

この概念情報モデルはモデル化に当たっての想定をすべて満たしていますが、よりビジネスプロセスを明示するために、振舞モデルも図10で示しておきます。

“顧客”再考

ここで、更に、“顧客”クラスについての考察を追加しておきます。
前述の通り、場合によっては“顧客”クラスは必要なく“注文”クラスで十分であるにもかかわらず、あえて、“顧客”クラスを定義する意味について考えてみます。
例えば、一度に大量の商品を注文する顧客や、頻繁には注してくれるお得意様が注文する場合に、販売価格のディスカウントを行ったり、在庫引当の際に他の顧客と競合した場合の優先的な割当てなど、ビジネスシナリオとしてよくありそうなケースです。この様なことに対応するためには、そのための情報が概念情報モデルとして保持できるようになっていなければなりません。具体的には顧客の購入履歴が必要になるわけです。この様な情報を概念情報モデルで保持できるようにするためには、“顧客”クラスの様なクラスが必須になります。
以上を踏まえ、図10にそのような概念を加えた概念情報モデルを示します。

それぞれのビジネスシナリオに相当する振舞の中で、特定の顧客のインスタンスを起点として、関係R11でリンクされた注文履歴のインスタンスを収集することにより、ビジネス上の判断が可能になります。

ここで、一点、注意が必要です。教本のテレメトリードメインの項でも言及していますが、販売履歴は、ITシステムの運用保守で必要な操作ログの管理とは全く異なるもである点に注意してください。販売履歴は、あくまでもビジネスプロセス上の判断に必要なものなので、“商品販売”ドメインの概念情報モデルで定義しています。一方で、操作ログは、観点がITシステムの安定的な運用・保守、トラブル発生時のシステム解析で必要な概念世界に属する概念です。“商品何倍”ドメインの概念情報モデルを組み込んだITシステムにおいては、販売履歴だけでなく、顧客や商品仕様、注文といった全てのクラスのインスタンスの生成・削除、特徴値の更新、参照、全ての関係のリンクを張る、切るに関する更新情報を扱うべきです。この様な、“概念情報モデルの概念情報モデル”があれば、特定のアプリケーションドメインの定義の中身に言及せずに、操作ログの概念世界を構成できるので、サービスドメインとして扱い、“商品販売”ドメインの様な各アプリケーションドメインには混入しないように心がけましょう。
概念モデリングになると、何でもかんでもモデル化したくなる欲求にかられがちですが、モデル化対象にするもの、しないものを冷静にかつ合理的に割切るスキルが必須です。

※ これまでの筆者の経験上、実務上使えるレベルの概念モデルが作成できるかどうかは、このスキルの有無にかかっているように思えます。概念モデル作成では、常にモデル化対象の主題は何かを常に意識し続けることが重要です。
※ 難しいことを言っているようですが、異なる問題は別々の問題に切り分けてそれぞれ対応しましょうと言っているだけです。概念モデリングに限らず、異なる問題は異なる問題として扱うことは日常的に遭遇する様々な問題を解決する時に非常に重要なスキルですね。

最後に

以上、非常にシンプルな商品販売を例に、概念モデル作成の要点を解説してきました。

このチュートリアルで紹介した要点を挙げておきます。

1. 先ずは自分の頭にあるビジネスに対するイメージを絵にしてみる
2. モデル化するのはビジネスそのものであり、システムの操作方法ではない
3. 概念（クラス）と個々の存在（インスタンス）の違いを常に明確に意識する
4. クラス候補のインスタンスとインスタンス間のリンクがビジネスシナリオ上の何に相当するのか吟味し、ビジネスシナリオで扱う全てのエンティティを網羅する
5. 関係の多重度を意図的に変えて、それぞれのビジネス上の意味を検討する
6. サービスドメインを上手く活用して、アプリケーションドメインのモデルをビジネスそのものに特化する
7. 特徴値の定義場所を吟味する
8. クラスのインスタンスは複数存在し、同時並行的に変化していくことに常に留意する

日本語は英語と異なり、定冠詞や不定冠詞が無いので、ある言葉が、概念を表しているのか、具体的な個々の存在なのかが曖昧です。加えて単数形・複数形もないので、関係の多重度で定義されるような、関係するインスタンスが複数なのか単数なのかも曖昧です。そのため、ビジネスを支援するITシステム開発時には非常に重要なこれらに関する記述が、日本語による文章では、非常に曖昧になるか、あるいは、とてもくどくてわかりにくくなってしまうかして、開発に参画するメンバーの共通理解を妨げてしまいがちです。そしてそのような齟齬はシステムが動き出してユーザーが使い始める開発後半になって発覚し、開発期間に多大な影響を及ぼしてしまいます。
概念モデリングを通じてこれらの重要な事柄を開発初期から明確にすることができるので、この様な事態を避けることができます。

概念モデリングのコツをつかんだ後は、各自のビジネスを対象にした概念モデリング構築に進みましょう。

概念モデルを描くには、BridgePoint というツールが便利です。「ビジネスをモデル化する ～ BridgePoint を使ってみよう」を読んで、概念モデルによるビジネスモデリングを実践しましょう。

概念モデリングのガイドが必要な方は、Knowledge & Experienceにご相談ください。