ある出版社プロジェクトにおける事例
出版社は「書籍」と「雑誌」を制作している。制作した「書籍」と「雑誌」は、取次（※出版業界における卸のような位置付けの業態）や書店へ卸す。
「書籍」には返品があり得て、また在庫は会計上資産として扱われる。「雑誌」は返品はあり得ず、また在庫は資産として扱われない。
-
「書籍」には「ジャンル」という販売管理上の分類がある。具体的には下記の通り。
- 一般書籍
- 企画書籍（※雑誌と書籍の中間的なもの、書籍だが決して重版しない）
- 音響・映像媒体付き（※特別扱い）
- 成人向け（※特別扱い）
-
販売管理観点では、「雑誌」もある種の一つの「ジャンル」として扱っている。販売管理観点での「ジャンル」は、つごう下記5つという認識。
- 一般書籍
- 企画書籍
- 音響・映像媒体付き書籍
- 成人向け書籍
- 雑誌
「取引条件」という売価、支払サイト等に関わる諸条件が、おおよそ取引先（＝取次や書店）×ジャンルの数分定められてる。「取引条件」は特定の書籍や書籍群に対して、個別に定められたものもある。つごう、取引条件は大分類で8つ、小分類で20くらい、全部で500程度ある。
営業上、制作上の業務プロセスはジャンル毎に相当異なっていて、営業部門と販売管理部門では、各ジャンル毎に担当を置いている。営業部門、販売管理観点では、個々の取引条件は（一度決まったら）普段は気にしていない。
一方、経理部門の関心は、売れた書籍または雑誌は、どの「取引条件」が適用されているものか、という点に置かれている。営業・販管の言うところの「ジャンル」には関心が無い。ところが、「取引条件」が大きくは「ジャンル」毎に定められていたことから、経理部門において「取引条件」の分類（※大分類で8つ、小分類で約20）のことを「ジャンル」と称していた！
◇
これには苦戦させられた記憶が。。概要レベルでは話は通るのだ。掘り下げていくといつの間にか迷子になっていることに気付く。販売管理部門から「ジャンル一覧」をもらっていたので、無意味と思いつつ、経理部門で「ジャンル一覧を具体的に見せてもらえますか？」とお願いしてみた。そうして「取引条件一覧」が出てきたとき、全ての謎が解けたのだった。
実際の所、資料上「取引条件」、「大分類」、「小分類」、などと書かれてはいたのだ。ではあるが、会話ベースではすっかり「ジャンル」が定着していた。経理の担当に再確認して「そうそう、取引条件の分類です。販管はジャンルをいつも曖昧に扱ってて困る。」という証言を得られた。
◇
この状況において、ユビキタス言語の語彙セットをどのように構築したのか？当時の開発チームは次のように対応した。
コード記述上としては、「販売管理の言うジャンル」を『ジャンル(Genre)』、「経理の言うジャンル」を『取引条件分類(Category of Terms and Conditions)』と名付けることとした。クラス名やカラム名にはこれらを適用した。
販売管理担当と会話するときは、『ジャンル(Genre)』、『取引条件分類(Category of Terms and Conditions)』をそれぞれ、「ジャンル」、「経理の言う取引条件」という言い方をした。経理担当と会話するときは、それぞれ「販売管理の言ってる（ゆるい方の）ジャンル」、「取引条件のジャンル」という言い方をすることとした。
形式的にまとめると、、namespace概念を導入しつつ、下記のような四つの語彙を定義した、ということになる。（※ダブルコロンはC++での名前空間区切り記号で、下記表記はそれを借用している。）
| 名前(日) | 名前(英) | 備考 |
|---|---|---|
| ::ジャンル | Genre | |
| ::取引条件分類 | Category of Terms and Conditions | |
| 販売管理::ジャンル | - | 『::ジャンル』と同じ |
| 経理::ジャンル | - | 『::取引条件分類』と同じ |
ユビキタス言語的に、この実践を解釈してみるとどうなるか。二つの解釈が可能である。
一つ目は、「一つの境界付けられたコンテキスト内に四つの語彙を定義している」というものである。ただ、そうすると語彙に重複というか方言というかを残していることとなる。結局「ジャンル」がユビキタス言語化されてない気もする。
二つ目は、「「販売管理」、「経理」という二つの境界付けられたコンテキストがあって、それぞれのコンテキストにおける「ジャンル」を定義している」というものである。解釈としては、こちらの方が素直ですっきりしているように思う。しかし、システム開発チームとしては、「「二つの境界付けられたコンテキストがある」とするならば、その二つを同時に扱う必要がある」、という話になるだけである。いちいち「販売管理のジャンル」、「経理のジャンル」と言い分けるのも少々だいぶまどろっこしい。まさにコンテキストスイッチが頻発するということで、開発チーム内の会話が効率化されない。（＝ユビキタス言語構築に伴って得られるはずの効果を、開発チームが享受できない。）システム開発チームの立場から見る限り、販売管理、経理の両方を統合した一つの境界付けられたコンテキスト、として扱えた方が扱い易いのだ。
◇
では、この状況において、どのように対処したらよかったのだろうか。
(案1) 境界付けられたコンテキストと、加えて開発チームも分割すべきだった。
(案2) 経理部門で「取引条件分類」を「ジャンル」と呼称していたのが実際のところ"誤り"なので、経理部門へ「ジャンル」と「取引条件分類」の語を正しく用いるように働きかけるべきだった。
(案3) コンテキストとは階層的なものである、という現実を受け入れるだけでよくって、当時実施した対応でよい。
案1のデメリットは、、結局統合の段階では両方のマッピングをしなければならない。しかも今回の状況では、開発チームとしては、既にその二つのコンテキストとそのマッピングを掌握してしまっていて、統合された形での"ドメイン"を描けてしまっている。にも関わらず、それをまた二つの射影（部分像）に戻して、二つの"非正規化ドメイン"を作るというのは、、どうにも無駄にしか見えない。根本問題は実際経理部門での誤用だと思えるので、案2でいきたいと思うのだ。
案2のデメリットは、、システム構築目線では綺麗になる対処法なのだが、これは単に現実には実施不可能だという点にある。"経理部門のドメインエキスパート"からは、販売管理部門こそが曖昧に運用していると見えている。
案3のデメリットは、、システム開発チームが、このような語彙が交錯している状態を、そのまま受け入れなければならない点である。語彙の別名管理など、それなりに複雑な構成管理を追加で実施しつつ、"サブ・コンテキスト"間のインタープリター（通訳者）役を担い続けなければならない。
さて、あなたならどうするか？各位考えてコメントいただければ幸いである。
◇
ちなみに念のため何点か補足しておく。
- 上記では例として一つの語彙だけを挙げているが、開発スコープに登場する語彙のおよそ20%くらいがこのような状況にあった。もうひとつ例を挙げてみる。：
- 「在庫」といったとき、商品管理部門では「書籍」と「雑誌」の両方に関心を置いていた。書籍については返品分も関心対象となっていた。
- 営業部門でも「書籍」と「雑誌」の両方の在庫に関心を置いていたが、返品分は関心外で、現在在庫というより配本計画といった観点からのものであった。
- 経理部門においては、資産となる「書籍」のみが対象で、「雑誌」の在庫は関心外であった。
- 販売管理と経理など、確かにコンテキストが分かれてるのだ、と理解するのが素直ではあるのだが、結局は、前項の20%の語彙の対応構造を紐解かない限り、統合して動くシステムが作れない。
- 語彙のマッピングできた時点で、既に統合されたドメインができ上がっている。というか、仮説として統合ドメインを仮設しながらでないと、語彙（のマッピング）を紐解けないのだ。
更に補足しておく。当時のプロジェクト進行は実際にはもっとひどかった。当初は、まさに担当チームを分割して並行に走っていたのだ。そうして結合フェーズになって、、繋がらなかったのだ。何せ語彙マッピングは実質未設計に等しい状態だった。いやもうドメイン分析からやり直すしかなかった。「二つのコンテキストの語彙を統合的に理解している人」が皆無だった。それで経理部門への再インタビューなどを敢行して、、本記事冒頭のような状況が明らかになった、、という次第である。
最後となるが、本記事のお話はフィクションである。