6. ドメインとITシステム構築
本ドキュメントの利用は、https://github.com/kae-made/kae-made/blob/main/contents-license.md に記載のライセンスに従ってご利用ください。
Date：2026/1/11 - Version：1.6.0
ブリッジに関する、圏I、圏Cの観点からの考察
ブリッジの明確かつ厳密な定義の追加
はじめに
「概念情報モデルをITシステムに組み込む」では“概念情報モデルの概念情報モデル”を紹介し、簡単に主題領域（ドメイン）に言及しました。この節では、“主題領域（ドメイン）”についてより深く説明していきます。
概念モデリングにおける、“主題領域”の正式名は、“概念ドメイン”なのですが、本節ではシンプルに“ドメイン”という用語を使います。
ドメイン
ドメインとは、「なぜシステム化したいのか」という背景を同じくする、システム化したいビジネス対象に含まれる主題や観点などの集まりです。ネット上でシステム開発の文脈で“ドメイン”という用語を検索すると、本稿での意味付けとは異なるものしか出てこないので、それらは全て無視して忘れてください。
ドメインとは
概念モデリングでは、モデル化対象となる現実世界のことをドメインと呼びます。モデル化は、解決したい問題や、理解を深めたいテーマ等の観点のもとに行います。それらを構成する主題の集まりでもあるので、ドメインは、モデリングに対する主題領域の世界とも言えます。
モデリング開始時点でのドメインの定義は、モデル作成チームメンバーの意識合わせのための簡潔な三行程度のシンプルな説明文や、いくつかのビジネスシーンを描いたスケッチなどがあれば十分です。何しろ、その詳細が分からないからモデルを作成していくのですから、曖昧な記述しかしようがありませんから。
ドメインは、概念クラスとそれを特徴づける特徴値の組、特徴値の値を規定するデータ型、概念クラス間の意味的な関係（Relationship）、概念クラスに紐づいた状態モデル（事象、状態、遷移）、データフローモデルを基本としたエントリアクションのアクション記述、つまり、概念モデルの記述によって、その、意味を伴なった在り様の詳細が規定されます。言い方を変えれば、
ドメインの厳密な定義 ＝ 概念モデル
です。モデル化の対象である、解決したい問題や、理解を深めたいテーマ等は、ビジネス要件だけでなく、意味的に深く関連してまとまった主題群で構成されるものであれば、何でも（概念モデリングそのものさえ）ドメインとして扱って構いません。
モデリングに必須なドメイン ～ ”意味の場” あるいは ”領野”
ある目的のもと何らかの意図をもって対象を抽出する、それが、モデリングという作業です。これは概念モデリングに限らず、あらゆるモデリング技法の基本です。モデリングにおいて抽出されるのは、実際の世界にある何かを、モデリングの目的や意図によってモデル作成者が認識、あるいは解釈した存在です。目的や意図が異なれば、抽出された存在の性質は異なります。概念モデリングでいえば、抽出された概念クラスとその特徴値の組、Relationship、そして、状態モデルが異なります。
自転車に乗ってサイクリングに出かけることを考えてみましょう。サイクリングに出かけるという観点からすれば、主題になるのは、目的地や経路、走行中のスピードや疲労具合による休憩の取り方、遠出の場合宿泊地です。しかし、これらの主題群は、自転車だけからは出てこないでしょう。自転車はサイクリングを行うための物質的条件という必要条件ではありますが、サイクリングの十分条件ではありえません。自転車だけの観点で考えられるのは、ハンドルやサドル、タイヤ、チェーン、変速機の有り無し、それぞれのパーツの製造会社、自転車全体、あるいは各部品の価格、走行距離に応じたメインテナンス、防犯登録、などといった主題が抽出されるでしょう。加えて、ユーザーの視点、自転車の販売業者、製造会社の視点によって、抽出された主題の性質が異なる（＝特徴値や状態モデル）のは容易に想像がつくでしょう。
この様に、モデル作成時に抽出される対象は、それぞれの目的や意図という視点の違いによって、変わってきます。新実在論という哲学の一分野では、過去数千年に渡って議論されてきた成果の元、
「存在すること」＝ 何らかの意味の場のなかに現れること
とされています。更に、
「限りなく数多くの意味の場が必然的に存在する」
とされています。”意味の場（Field of Sense）”、これは邦訳では、”領域”、”意味の領域”、”対象領域”、”領野”…と様々な用語が使われていますが、概念モデリングにおける”ドメイン”の何たるかは、新実在論の”意味の場”がベースになっているとするのが、一番妥当な解釈である、というのが、筆者の現時点での見解です。
新実在論の”領域”は、一般的に用いられている”Domain”とは若干異なることには留意が必要でしょう。あえて”領野（Field）”という言葉を使ってDomain と明確に区別した論考を行っているからです。一般的に存在論で使われてきた Domain という用語は、人間が意図的に構築したものという意味合いがあるようです。概念モデリングにおける Domain は、一般的な存在論の Domain ではなく、新実在論の Field であることに注意してください。
～ 以下、”マルクス・ガブリエルの哲学” P27 より抜粋 ～
私の領野概念（Field）の使用法は、存在論における領域概念（Domain）にとって代わることを意図している。領野は一般的に構築されるものではなく、その効力は対象が入り込むことで感じ取られる。〔中略〕領野は客観的構造を提供し、その構造内で現出する対象と相互行為をなす。領野は既に存在し、対象はその領野を通じて自身の性質を転換する。領野は水平でも地平でもない。事物の在り方を知る手立てを説明するために導入された、認識論的存在者ないし客観ではない。領野がなければ何も存在しないというなかでの、事物の在り方の本質的な部分のことである（2015 157-158)
～ 以上、抜粋終わり ～
以上を踏まえ、”Art of Conceptual Modeling”におけるドメインという用語をフィールドと書き換えるべきか、とても悩んでいました。
しかし、その後の調査・読解を基に、以下に述べるように、”意味の場”をその状態を指す用語とし、”（概念）”ドメインを、そのスキーマとして考えれば整合性が取れるので、そのように用語を定義することとしました。
概念モデリングにおける”ドメイン（意味の場・領野）”は、単なるモデリング上のテクニックではなく、対象を記述する時の本来的な基本単位です。
加えて、複数の”ドメイン（意味の場・領野）”が存在することも本来的です。加えて、”ドメイン”は並列であり、階層化はしないことも、”ドメイン（意味の場・領野）”の本質から自明です。
IT システムを構築する際にも、以降で説明するドメイン（意味の場・領野）群が必須であると心得てください。
”意味の場”と”ドメイン”の関係
概念モデリングにおいては、概念情報モデル、状態モデル、アクション記述を用いて、現実の世界をある一つの”意味の場”から見て、その概念、及び、その振舞いを含めた意味の構造を厳密に記述します。”概念”に関する記述を行うので、”ドメイン”とは、正確には”概念ドメイン”と呼ぶのが適切です。つまり、”意味の場”を通じて眺めた場のスキーマが”概念ドメイン”です。
逆に言えば、”意味の場”に存在する全てのモノゴトとその振る舞いは、”概念ドメイン”をひな型として存在する、概念インスタンス、その特徴値、概念インスタンス間の意味的リンク群、及び、出来事の生起によって生じる状態遷移、及び、遷移に紐づいたアクションの実行の集合です。圏論の用語を借りれば、
意味の場に現象する事柄の意味的構造 ＝ 概念ドメイン：圏Cのモデル
意味の場に現象している事柄の状態 ＝ 圏Cをひな型（スキーマ）とする圏Iのモデル
です。人間の思考は言語を基に成り立ちます。言語哲学を踏まえれば、意味の構造とは、
分類
分類が持つべき特徴値の組
分類間の意味的な関係
で記述されるものです。この組合せは概念情報モデル、状態モデル、データフローモデル、それぞれの道具立てに一致します。特に概念情報モデルは、状態変化の基盤となる事柄の意味の構造を規定、つまり、対象の意味の場の存在を意味付けします。これは、概念モデルは人間の思考における存在の意味付けの基本に則って組み立てられていることを意味しています。これが、どんな主題領域にも概念モデリングが適用可能であるという根拠です。
また、意味の場の状態を記述する圏Iのモデルは、そのスキーマである概念ドメインに従います。概念ドメインは概念モデルで厳密に記述されており、概念モデルを使うことによって、圏I 上の命題文を導出することができます。概念モデルは、対象の意味の場の状態（概念モデルをスキーマとする圏Iのモデル）の意味的構造の記述であるので、その命題は有意味です。その意味の場にとって妥当な概念モデルであれば、その命題は常に True｜です。
ドメインの種別
ドメイン毎に考える
概念モデリングの過程において、別のドメインのクラスとして定義したほうが良い概念が候補として抽出されることが良くあります。クラスの抽出に当たっては、モデル化対象のドメインに属するクラスか否かを常に吟味します。適切なクラスかどうかは、対象ドメインの他のクラスとの関係を考察することで判断します。
同じドメインに属するクラスの間では、そのドメインの主題や観点において適切な関係が定義できます。異なるドメインに属するクラスの間ではそのような関係を定義することはできません。モデル作成の過程でそんなクラス候補が出てきたら、そのクラス候補が意味するところや背景などを検討し、必要であれば別のドメインのクラスとして切り出していく、そんな風に進めていくのが良いでしょう。
※ 本稿で“ドメイン”と呼んでいるものを簡潔に説明するのは大変難しいのですが、例えば、複数人で何らかのテーマで議論をしている最中に、同じような言葉を双方が使っているのにも関わらず議論が全くかみ合わないことがあります。これは議論の当事者それぞれが頭に描いている主題がそれぞれ違っている、あるいは、観点が異なっていることに起因します。概念モデリング的には、それぞれの議論の当事者が思い描いていることがそれぞれ独立した“意味の場”を頭に描いて、議論をしていると考えます。他者と、より良い議論をするために、議題の意味の場（概念ドメイン）を明確化しましょう。
現在確認中ですが、本稿の”ドメイン”は、ベースとなっている Shlaer-Mellor 法の提唱者の一人、Sally Shlaer さんが数学者であること、方法論の提唱時期から考えて、”領域理論 - Wikipedia” がベースになっているのではないかというのが、著者の現時点での見解です。
ドメインはその特性上、以下の４種類に分類できます。
アプリケーションドメイン
サービスドメイン
インフラストラクチャドメイン
アーキテクチャドメイン
これらの分類は、適切なドメイン定義の指針にもなりえます。
アプリケーションドメイン
IT化したいビジネス要件の主題を扱うドメインです。ネット上でよく見かける定義はこの分類に近いです。「概念情報モデル」の章で例として挙げた、“商品販売”や、“装置管理”等がこの分類にあたります。“人事”や“経理”も含め、ビジネスに関するものでIT化したい対象には必ず１つ以上のドメインが存在します。
サービスドメイン
この分類に属するドメインは、アプリケーションドメインを、IT技術を使って実現するための、“仕組み”に関する概念群で構成されます。
例として“装置管理”を使って説明します。
これまで述べてきたように、概念情報モデルが定義する制約に従って存在する、インスタンス、インスタンスの特徴値の値、他のインスタンスとのリンクは、常に今どうなっているかを示しています。そのため、このモデルでは、“今どうなっているか”という問いにしか答えられません。ある装置インスタンスに着目して、
その装置インスタンスの温度の値が過去のある時点でどういう値だったか
過去のある期間どんな変化をしていたのか？
という問いかけは、記録された現実のデータをもとに最適な制御を模索する上では必須のものです。概念情報モデルの道具立てを使って、素直にモデル化するとすれば、
というクラスと、装置との間の関係を定義するのが自然に思いつく方法でしょう。
しかし、過去の変化という事では、“消費電力”という特徴値についても当然同じ問いが可能であり、さらに言えば、その装置インスタンスの設置場所の履歴、さらには、インスタンスが作成された（現実世界では装置が設置されてシステムの管理下に置かれた）時点や、リンクの切り貼りの履歴も見たいはずです。この様な様々な履歴に関する情報についてクラスと関係を定義していくと、概念情報モデルはあっという間に蜘蛛の巣の様な不様で汚い図になり果てます。
※ 不様な様は、テキスト形式で描いているときには気が付きにくいものですが、モデルを図で書いたときに際立ちます。
この様な無様な状態が、正に、別ドメインの概念が混入してしまっている状態であり、モデル作成者の頭の中が図と同様混乱しきっていることの証明です。混乱している脳味噌が良いアイデアを生み出すことはまずないでしょう。
この様な状況に対しては、“興味ある値の経過を管理して可視化したい”という意味の場があると考えて、その意味の場に現象する概念群を抜きだし、別の独立した概念ドメインを定義します。名前は、便宜上、“テレメトリ”とします。このドメインの概念情報モデルを以下の様にモデル化すると、
“装置管理”ドメインの“装置”インスタンスの“温度”の履歴は、このドメインの“Time Series Instance”と“Time Series Data”のインスタンスとして保存することになります。“消費電力”についても同様です。
図の“Time Series Data”クラスの“Value”という名前の特徴値は、アプリケーションドメイン側での時系列データとして保持したい、様々な特徴値と対応付けられます。対応付ける特徴値は数値の場合もあり、テキストや列挙値の場合もあり、様々なデータ型の値を保持する必要があるので、この特徴値のデータ型は、なんでも格納できるデータ型という意味を込めて、“ANY”型としています。
この、“テレメトリ”の様なドメインが、サービスドメインという分類に属するドメインです。対応付けられる側の概念情報モデルは、あくまでも、モデル化対象のドメインが、どんな概念で構成され、その概念はどんな値のセットで特徴付けられるかという表明にすぎません。その値の変化を記録するのは、過去の履歴を見るための仕組みであって、元々のモデル化対象になっていたドメインとは異なる主題である、と考えるわけです。
この様な考え方で、“テレメトリ”というドメインを定義しておけば、“装置管理”のクラスだけでなく、“商品販売”をはじめとする、様々なドメインの概念情報モデルを汚すことなく、インスタンスや関係、特徴値の過去履歴を保持・参照が可能な仕組みを適用できます。
サービスドメインは、“テレメトリ”のほかにも、様々な意味の場に対して、同様な考え方を適用して、抽出できます。
例えば、ITシステムのビューを作成するためのGUIや、３Dモデル、AI学習や学習済みモデルの配置方法、セキュリティ、認証基盤、データベースなどもサービスドメインとして定義可能です。
自己言及的な説明になってしまいますが、作成するアプリケーションドメインの概念情報モデルの良し悪しは、いかにサービスドメインをうまく抽出できるかにかかっています。
また、全てのサービスドメインは、特定のアプリケーションドメインとは意味的に切り離されているので、様々なアプリケーションドメインに対して利用可能です。ソフトウェア開発における汎用ライブラリのような特徴を持っているので、抽出したサービスドメインは全てカタログ化し、チーム内で資産として共有し、再利用します。
読者の参考になるよう、セキュリティやGUI、3Dモデルなど、よく使われるサービスドメインのサンプルをまとめた、「ドメインカタログ」を公開しているので、ご参照ください。
アプリケーションドメインは「ビジネスで何がしたいか」を主題した概念モデリングであり、そのビジネスに詳しい専門家が行う領域なのに対し、サービスドメインは、セキュリティならセキュリティの専門家、GUIならユーザーインタフェースの専門家、AIならAIの専門家と、それぞれの分野の最新動向や、利用可能な技術やサービスを熟知した専門家が担当する領域です。それぞれのドメインは独立していて概念的には無関係なので、ドメイン毎にそれぞれの専門家が並行して概念モデリングを進めることができます。
このセクションの説明は、ドメインが、ソフトウェア開発上の技巧の結果、切り出されていくような印象を与えるかもしれません。
しかし、それは説明上のギミックにすぎません。
”テレメトリ”という意味の場を切り出す以前は、アプリケーションの意味の場における、特定の特徴値の変化について思考を巡らしていました。そこから、特徴値だけでなく、様々な事柄の変化という意味の場がそもそもあったことを発見した、と捉えるのがより本質的です。
インフラストラクチャドメイン
アプリケーションドメインとサービスドメインを使って実際のITシステムを構築する際に使用する利用可能なサービスやライブラリ、フレームワークを扱うドメインがインフラストラクチャドメインに分類されます。ロジックを実装するプログラミング言語も該当します。
例えば、前に紹介した概念情報モデルをそのまま実装できる Azure Digital Twins や、現実世界に設置された機器とITシステムの接続・相互通信の機能を提供する Azure IoT Hub、テレメトリデータを蓄積し高速なクエリーを可能にする Time Series Insights、リレーショナルデータベース等、ソフトウェアの実装で必要な道具や部品は全てインフラストラクチャドメインとしてモデル化の対象となりえます。Microsoftが提供しているサービスのみ例として挙げましたが、Amazon Web Service や Google、オープンソースプロジェクトが提供する近しいサービスやフレームワークも含まれます。これらすべてを便宜上、“実装部品”と呼ぶことにします。
Time Series Insights は、2025年現在、残念ながらマイクロソフトから提供されていません。その代わり、Azure Digital Twins × Azure Data Explorer、または、Microsoft Fabric の Real-Time Intellegence など、より強化されたサービスが、マイクロソフトから提供されています。
上に挙げた各種サービスは、ほとんどの場合、サービスプロバイダーから公開された説明ドキュメントがあり、サービスを利用するための REST API やライブラリの API が記述付きで公開されています。これらのドキュメントをよくよく熟読してみると、用語の定義や機能の説明はあっても、用語が意味する概念間の関係、特に多重度は曖昧な場合が多々あります。原文が英語なら原文を読み下したほうが良いのですが、不定冠詞や定冠詞、単数や複数を厳密に使い分ける英語ですら、細かい部分の説明が曖昧な場合が多いので、日本語での説明の場合はなおさらです。
インフラストラクチャドメインに対する概念モデリングは、二つの目的で行います。
その実装部品を深く理解する
アプリケーションドメイン、サービスドメインの実装戦略を考えるための基盤を作る
例えば、Azure IoT Hubを例にすると、このサービスは非常に沢山の機能や設定を持っていて、かつ、操作対象としての概念もたくさんあるので、“概念情報モデル”を使って自然言語で説明されている内容を明確化すると理解が深まるとともに、ドキュメントには明確に記述されていない部分も発見できます。モデル化により理解が深まるだけでなく、サービスプロバイダーへのはっきりした質問が可能になったり、複数のサービスプロバイダーから提供されている一見似たようなサービスの違いを見つけることもできます。
参考までに Azure IoT Hub に対して、筆者が作成した概念情報モデルの一部を図で紹介しておきます。
インフラストラクチャドメインに対する概念モデリングの、二番目の目的である“実装戦略を考える”は、ITシステムの一般的な開発工程における“設計”に相当します。
アプリケーションドメインやサービスドメインのそれぞれの概念情報モデルは、インフラストラクチャドメインが対象とする実装部品を使って、構築したいITシステムの一部として実際に動くソフトウェアとして、“変換”され“実装”されます。
アプリケーション、サービスドメインのそれぞれの概念情報モデルで定義された、クラス、クラスのプロパティ、関係、及び、概念情報モデルに対する操作、のそれぞれが、インフラストラクチャドメインの概念情報モデルの要素にどのように対応付けるかを、ビジネス要件から求められるITシステムへの非機能要件を元に決定しルール化する過程を、本稿では、“設計”と呼びます。一般的なソフトウェア開発における設計においても、“与えられた機能要件と非機能要件を、ソフトウェアを利用可能な実装技術を使って実現する方法を決定すること”なので、本質的な相違点はありません。
設計に関するルールが決まれば、それぞれのドメインの概念情報モデルであらかじめ定義しておいたインスタンス群の初期状態から、順にインスタンスを取り出して、ルールを適用してくことにより、ソフトウェアが扱うデータ構造を記述するソフトウェアコードや設定スクリプトが出来上がります。また、状態モデル、アクション記述も同様に、概念モデルの記述内容に対してルールを適用していくことにより、振舞いに関するソフトウェアコードを導出可能です。結果として、実際に動くソフトウェアコードや設定スクリプトが一式を手に入れることができます。
つまり、“モデル”から“ソフトウェア”に“変換”できるわけです。この過程は、人手でもできますし、概念モデルのリポジトリと変換ルールをデジタル化して、コンピュータ技術を駆使すれば自動化できます。脳味噌をふり絞って脂汗をかきながら、コンピュータが扱えるぐらいの厳密さで作成した概念モデルのおかげで、旧来のソフトウェア開発プロセスで、最も人出が必要な後半の工程が自動化できるわけです。勿論、自動生成では不可能な、人が書かなければならないソフトウェアコードの部分も若干残りますが、旧来型のソフトウェア開発プロセスに比べれば微々たるものになります。
本稿で解説している概念モデリングを活用したITシステム開発方法では、設計と実装の工程は、複数のドメインを統合する作業が該当します。
ドメインの統合では、概念モデルの概念情報モデルを使って、あるドメインの要素と別のドメインの要素の対応付けと、コードを実装するためのパターンを定義していきます。
”概念モデルの概念情報モデル”は”メタモデル”とも呼ばれます。
ソフトウェア化可能な対象であれば、あらゆる対象に対して概念情報モデルを定義することができるということは、概念モデル自体も、モデルを構成する、概念クラス、特徴値、Relationship、データ型、イベント、状態、状態遷移、アクション、プロセス、データフロー、…、という全てのモデル要素を概念情報モデルとして定義可能という事を意味します。概念モデルを意味の場として作成した概念情報モデル、それが、”概念モデルの概念情報モデル（メタモデル）”です。
何度も繰り返して恐縮ですが、概念モデリングでは、“意味の場”ごとに概念モデルを作成します。概念モデリングのモデル体系は、言語をベースとした人間の思考の基本的構造を道具立てとして採用していることから、モデル化対象の“意味の場”に制限はありません。結果として、どんな意味の場に対しても、概念モデルの作成は可能です。メタモデルから見ると、それぞれの意味の場に対する概念モデルの記述内容は、メタモデルをスキーマとした、圏I のモデルです。結果として、丁度、リレーショナルデータベースに格納されたデータを、そのスキーマを基に記述した SQL で全て取り出せるように、それぞれの意味の場に対して記述された概念モデルの記述内容を、メタモデルをスキーマとして、全て取り出せることになります。これが、先程述べた、モデルにルールを適用してソフトウェアコードに変換していく際の、モデルの記述要素の取り出しの仕組みです。詳しくは、“Technique of Transformation” をご覧ください。
また、この変換プロセスにおける手書きコードの必要性にも言及しましたが、このコードの設計は、それぞれの意味の場ではなく、メタモデルが対象になります。概念モデルの定義は有限なので、メタモデルもまた有限であり、メタモデルの規模は一定です。加えて、概念モデルの定義は、そうそう頻繁に変わるものではなく、メタモデルは安定しています。結果として、メタモデルを設計対象とする手書きが必要とされるコードの規模は一定であり、一度実装されたコードは、システムに要求される非機能要件を満たすものであれば、様々な意味の場の概念モデルに対して再利用可能です。
概念モデルのメタモデルもまた、概念モデルとして記述されます。このことを自己言及的と考える読者もいるかもしれません。確かに、数多の高名な哲学者が陥っている無限の階段的な論法に則ると、そのように捉えられなくもないでしょう。しかし、何度も繰り返しますが、概念モデリングは、現象学、新実在論、言語哲学、論理学を基に、人間の、言語をベースとした思考の道具立てから構成されているモデリング体系です。概念モデリングという意味の場に対するモデリングの結果記述されるモデルもまた、思考の基本的な道具立てで記述されるのは、むしろ当たり前であり、自己言及的との指摘は適切ではないでしょう。
ちなみに、前述の”テレメトリ”という意味の場についてですが、その意味の場を考える以前の段階では、メタモデルをスキーマとする圏Iのモデル（アプリケーションドメイン）においての変化を対象とした思考であったのが、”テレメトリ”という意味の場を考えるという段階は、メタモデルを対象とした思考に変化した、と言えるでしょう。メタモデルを明確に意識することは、モノゴトを一般化して考えるということと同義です。適切な意味の場の抽出において、メタモデルを意識することはとても重要だということを、留意しておきましょう。
次節で、アプリケーションドメインとサービスドメイン、サービスドメインとインフラストラクチャドメインなど、統合するドメインの特徴に応じた対応付けのパターンを紹介していきます。
ドメインを統合する
この節では、ドメイン毎に作られた概念モデルを統合して、実際に動くITシステムを構築していく方法をより詳細に解説します。
ドメインをインフラストラクチャドメインにマップする
「概念情報モデルをITシステムに組み込む」の章の「グラフデータベース、あるいは、オブジェクト指向データベース」の節で、アプリケーションドメインの概念情報モデルを、Azure Digital Twins で実装する方法を解説しました。
これは、ビジネスを記述するアプリケーションドメインの概念情報モデルと、Azure Digital Twins という実装技術に対するインフラストラクチャドメインを統合することに相当します。統合は、アプリケーションドメインに対し、
概念情報モデルで定義された各種制約＝スキーマの管理
概念インスタンス群の状態保持方法
概念インスタンスへの操作
の3つについて、最も適切と思われる実装技術を選択し、選択した実装技術に対応するインフラストラクチャドメインにどう対応付けるかというルールを決めるというものでした。
この作業は、アプリケーションドメインに限らず、サービスドメインとインフラストラクチャドメインの統合においても、基本的には同じ作業を行うことになります。違うのは、アプリケーションドメインの場合は、概念情報モデルの概念情報モデルを扱うのにふさわしい実装技術を選ぶのに対して、それぞれのサービスドメインに適した実装技術をそれぞれ選択し、そのインフラストラクチャドメインと統合するという点だけです。
より具体的に言えば、それぞれのサービスドメインに対して定義された、概念情報モデルを構成する概念群と近しい概念群を扱う実装技術を選択することになります。
例えば、テレメトリドメインならば Time Series Insight（に代わって Azure Digital Twins × Azure Data Explorer や Real-Time Intellegence）、セキュリティなら Active Directory といった具合です。
勿論、近しい概念群を扱う実装技術であれば、他のベンダーやオープンソースプロジェクトが提供するサービスやフレームワークでも構いません。
実装技術の選択においては、扱う概念群が近しいという条件に加えて、ビジネスを支援するITシステムへの非機能要件を満たす事も、重要な選定基準です。ITシステムを構成するアプリケーションドメイン、サービスドメイン、全てに対して概念情報モデルが作成されている場合は、非機能要件は、概念情報モデルの用語を使って、以下の項目で表せます。
扱えるインスタンスやリンクの最大数
操作のパフォーマンス
インスタンスやリンクの数や操作数に応じた運用コスト
ビジネスを支援するITシステムの構築プロジェクトにおいては、利用ユーザー数や管理対象の機器数、応答性能、運用コストの上限等は、大抵の場合、投資対効果の観点から、概要が決まっているはずです。
それらに基づき、概念情報モデルの制約に従ってインスタンスの状態を設定すれば、ここで挙げた最初の2つの項目の数値を確定でき、利用候補の実装技術の利用料と照らし合わせることにより、最後の項目を算出できます。実装技術を提供するベンダーが公開している利用料金の定義があいまいな場合は、ITシステムのプロトタイプを作成して少数のインスタンスとリンクを設定して実際に動かしてみて利用料を確認するのも有効な見積手段の一つです。
インフラストラクチャドメインへの対応付けを考えるにあたっては、様々なケースで適用可能な実装パターンを知っていると非常に役立ちます。
マイクロソフトが公開する「Azure アーキテクチャセンター」では、様々なパターンを紹介しているので、読み込んでみるのもよいでしょう。
※ 概念モデリングの初学者の素直な感想は、「めんどくさくね？」だと思います（笑）。しかし、ある程度の正確な見積を行うには、パフォーマンスやコストに関わる項目の洗い出しが絶対に必要です。今、別の有効な手段があるならそれを使えばいいですが、ないなら、ここで解説している方法にトライしてみることをお勧めします。
※ IoTやビッグデータを扱うITシステムの構築について、よく、「小さく始めて大きく育てる」と言われますが、これは、「とりあえず出来るところから始めて成功事例を作って横展開してく」という意味ではありません。このやり方では、たとえ成功したところで、変化を望まない保守的な人達からは「たまたまやりやすい部分ができただけの特殊な事例」と言われて横展開はできないでしょう。ビジネスのIT化は、経営トップ層が関与して全社的に進めなければいけない組織レベルの戦略的な取り組みです。本稿で紹介してる概念モデリングによる開発においては、「小さく始めて」は、一部のドメインの試験的な実装で、少数のインスタンスやリンクの状態から初めることを意味し、その結果を元に、概念情報モデルの修正、実装技術の再選定、対応ルールの修正を行い、順次実装するドメインを増やす、あるいは、扱うインスタンスやリンクの数を増やすことが「大きく育てる」に該当します。
アプリケーションドメイン、及び、サービスドメインと、インフラストラクチャドメインの対応付けの概要は以上の通りです。
それぞれのドメインの特徴に応じたより具体的なやりかたについては、「ドメイン実装に関する実践ガイド」を参照してください。
以上、主に、概念情報モデルに関するデータ構造の実装を例に解説してきましたが、状態モデルやアクション記述についても、求められる非機能要件を満たす、プログラミング言語（C#、Java、Python、Ruby、C/C++、アセンブラ、…）、実行環境（クラウド、PC、スマートフォン、組込みOS、…）への、変換ルールによる実装を行えます。
Microsoft Azure のクラウド環境なら、C# のコードに変換し、Azure Function で動作させるソフトウェアコード一式を生成することも可能です。もちろん、理屈は一緒なので、ハードウェアリソースが潤沢でない組込み機器で動くソフトウェアコード一式の生成も可能です。
アプリケーションドメインとサービスドメインの対応付け
この対応付けは、アプリケーションドメインで定義された概念情報モデルをITシステムに実装する場合に、時系列データの扱いや更新履歴管理など、特定の主題領域に依存せず再利用可能な汎用的な概念を追加したり、ユーザー認証やアクセス管理、データの保存など、ITシステム化する際に必要な機能の追加に関するルールを定義します。
テレメトリドメインのアプリケーションドメインへの対応付けを考えます。
アプリケーションドメインの概念モデルで定義されたクラスの特徴値の一部を時系列データとして扱うという事なので、“概念情報モデルの概念情報モデル”の“property（特徴値）”クラスと、テレメトリドメインの“Time Series Instance”クラスには、以下の様な関係があると表現できます。
概念情報モデルの操作の観点からすると、
アプリケーションドメインの概念情報モデルの、テレメトリ管理したい特徴値に対して“時系列データセット指示”クラスのインスタンスを作成（同時に関係の多重度の定義に従って“時系列データセット”のインスタンスが一つ出来上がる）する
というルールを定義したことになります。後は、“時系列データセット”のインスタンスを順次取り出し、“テレメトリ”ドメインをインフラストラクチャドメインに対応付けるルールに従って、実装に変換していけば、“テレメトリ”ドメインをアプリケーションドメインに対応付ける作業が完了します。
アプリケーションドメインを Azure Digital Twins で実装している場合は、Azure Digital Twins のTwin Property 更新通知のエンドポイントで更新情報を受信し、“テレメトリ”ドメインの実装にデータを供給するような構成になります。
アプリケーションドメイン側の、特徴値のテレメトリ管理指定は、人が手動で行います。「概念情報モデル」の章で紹介したYAML風のテキストで概念情報モデルを定義している場合は、特徴値の“description”の下位要素で、“@telemetry: true”のようなメタデータ指定を行い、それをプログラムで読み込み、メタデータ指定があった場合は、該当する特徴値の更新のみをウォッチするフィルターを持つ Azure Digital Twins の更新通知エンドポイントを作成するスクリプトを生成するような仕掛けを作っておけば、実装工程の自動化が可能です。
ここで紹介したテクニックは、C# の属性や Java のアノテーションでも使われているテクニックと同じです。
以上、“テレメトリ”ドメインを例に説明してきました。手順をまとめると
概念情報モデルの概念情報モデルのクラスと、サービスドメインの概念情報モデルのクラスの対応を、定義する
アプリケーションドメインの概念情報モデルのインスタンスの対応する要素に印をつける
アプリケーションドメインの概念情報モデルのインスタンスを順次取り出し、印のついた要素に対して、サービスドメインのインフラストラクチャドメインへの変換ルールに従って実装する
となります。
機器からのテレメトリは、また、別の見方による、別の対応付けも可能です。
図13 の”装置”という概念クラスには、”温度”という特徴値が定義されています。”装置管理”というドメインでは、製品の一連の製造過程の幾つかの時点で、この”温度”という特徴値を参照するだけだとすると、”装置管理”というドメインを対象とした概念モデルの記述において、”装置.温度”は単に参照するというアクションがどこかに存在していれば十分で、”装置.温度”の値の更新に関するアクションは記述する必要はないと、考えるのが概念モデリングの流儀です。
「え？でも現実世界の装置の実際の温度の変化に合わせて概念モデル上の”装置.温度”を更新しないといけないよね？」という読者の声が聞こえてきそうですね。「Art of Conceptual Modeling」で解説している概念モデリングにおいては、
”装置.温度”の更新の仕組みは、”装置管理”ドメインを元に作成した概念モデルを、ソフトウェア成果物（プログラムコード）に変換する時に織り込めばよい
と考えます。例えば、現実世界の装置には、その装置の温度を計測する温度センサーが装備された IoT 機器が装備されていて、その機器が一定間隔で温度を計測し、ネットワーク越しにテレメトリデータとしてサービス側に送信している場合、
予め、IoT 機器のアイデンティティと”装置管理”ドメインの”装置”の概念インスタンスのアイデンティティを対応付けておく
ある IoT 機器がテレメトリデータとして計測した温度をサービス側で受信した時
送信元の IoT 機器に対応する”装置”の概念インスタンスを検索し特定する
特定した概念インスタンスの”温度”特性値を、受信した温度の値で更新する処理を起動する
という実装上の仕組みを用意すれば十分です。
他のケースとして、”装置管理”ドメインにおいて、装置の温度が、事前に決められている温度を超えた場合に特別な振舞をするようなシナリオがあるとします。この様な場合は、”装置”という概念クラスに状態モデルを定義し、その状態モデルで、例えば、”許容温度超過”という名前の事象（イベント）を受信し、”温度異常状態”に遷移して何らかのアクションを行うような記述を行うのが一般的です。
この場合も”装置.温度”特徴値の更新の時と同様、”許容温度超過”という事象を”装置”のある特定の概念インスタンスに送信する様なアクションを概念モデルで記述する必要はありません。
例えば、IoT 機器からのテレメトリーデータを、”装置.温度”の更新サービスに流しつつ、並行して Azure Stream Analytics にテレメトリーデータを逐次入力し、
”装置.閾値温度”を参照データとして使いながら、温度の超過を検出して後段に超過したことを示すデータを流す
送信元の IoT 機器に対応する装置”の概念インスタンスを検索し特定する
特定した”装置”の概念インスタンスに”許容温度超過”という事象（イベント）を送信する処理を起動する
といった仕組みで実現可能です。
これは、
ビジネスシナリオを記述するアプリケーションドメイン
現実世界の物理状態の収集・更新を担う、”IoT 機器” というサービスドメイン
インプリメンテーションドメインとして ”Azure IoT Hub” をマッピング
連続的なデータ流への統計処理や機械学習による条件抽出を担う、”データストリーム分析”というサービスドメイン
インプリメンテーションドメインとして、”Azure Stream Analytics” をマッピング
というドメイン群に分割してモデル化し、システムに統合する、一つのパターンです。
以上、取り上げた例は、およそ考えられる様々な実装のパターンのごく一部ですが、他のサービスドメインについても、アプリケーションドメインへの対応付けは、基本的にここで上げたような要領で進めます。
この節のタイトルは、「アプリケーションドメインとサービスドメインの対応付け」としていますが、「アプリケーションドメインの概念情報モデルにサービスドメインを対応付ける」といったほうが、実態をより正確に表現しています。作業を進める際、先にアプリケーションドメインの概念情報モデルがあって、それにサービスドメインを適用して実装に変換するのが基本です。
また、サービスドメインのインフラストラクチャドメイン対応は置き換えが可能です。つまり、同じアプリケーションドメインのモデルに同じサービスドメインを対応付けていても、サービスドメインの実装技術を変えれば、異なる実装技術上で動くソフトウェアモジュールが出来上がります。この特徴は IoT の様に、同じ機能ロジックを、クラウド上だけでなく、現場側に設置されたサーバー上や、専用機器向けのボックスHW上で動かしたいようなケースで威力を発揮します。
概念情報モデルのどの要素と関連付けるか、どういうルールを決めるかは、利用するサービスドメインによって様々です。より実践的なガイドは、“Technique of Transformation”をご覧ください。
アプリケーションドメインとアプリケーションドメインの対応付け
製品を製造販売している会社を考えてみます。この会社のビジネスとして、“生産管理”、“商品販売”、“装置管理”といった複数のドメインが定義されているとします。ほかに、“人事”や“経理”などもIT化の対象として、ドメイン定義がなされているものとします。それぞれのドメインは、会社の事業部や部課がそれぞれの業務として担当し、それぞれの流儀で使いやすいITシステムが構築され運用されるのが一般的でしょう。経営トップ層が、今後のビジネス戦略を決定するための、「今会社のビジネスはどうなっているか」を把握する仕組みを構築する場合、業務毎に運用されているITシステム間の連携が必要になります。
仮に、全社的な統制がなく、現場のボトムアップ主導により、それぞれの業務用ITシステムが、それぞれの流儀で開発されていて、データの扱い方や実装方法がバラバラでサイロ化してしまっている場合、統合は現実的には不可能でしょう。逆に、経営層がトップダウン主導でシステム化を決定し、各事業部の業務をよく理解していない開発チームが、全社横断的にそれぞれの業務向けのITシステム構築を担当した場合は、現場の担当者が、かゆいところに手が届かないITシステムを、苦痛をこらえながら使い続けることになるかもしれません。
概念情報モデルを使ったITシステム開発は、このような事態を解決する手段を提供します。各事業部それぞれの主題を扱うドメイン毎に、概念情報モデルが同じ形式で定義（もちろん業務に詳しい現場の担当者の概念モデリング作業への参加は必須です）され、共通のサービスドメインの利用と設計パターンに基づいたITシステム構築がなされるからです。
例えば、“装置管理”と“商品販売”を紐づけてみたい場合は、それぞれのドメインの概念情報モデルを使って、対応するクラスを見つける手助けができます。
工場の稼働状況の最適化と商品販売の在庫管理を結び付けたい場合も、同様に手がかりとして概念情報モデルを利用できます。
更には、装置管理で装置のインシデントの担当者を、人事管理を目的として横串で見たいときには、人事ドメイン上の社員クラスとの紐づけで行えます。
この様な、アプリケーションドメイン間の対応付けは、“概念情報モデルの概念情報モデル”を使うと、図の様に定式化できます。
異なるドメインに属するインスタンス間の対応付け情報は、“概念情報モデルの概念情報モデル”に記載した Instance クラスを使って、図の様に Mapping クラスのインスタンスとして表現可能です。Mapping クラスのインスタンスの表を思い浮かべれば、データベースで保持するような仕組みを用意してITシステムに組み込めることが理解できるでしょう。
この作業は、それぞれの開発対象の主題領域を定義して、概念情報モデルを作っておけば、後付けできるのがポイントです。つまり、概念情報モデルを使ってそれぞれの業務用ITシステムが構築されていれば、ビジネス上必要になった任意の時点で、ITシステムへの機能追加ができるので、ITシステムのアジリティを高めます。
※ 「でも概念モデルとかいうめんどくさいもの造らなきゃいけないんでしょ？」という読者の声が聞こえてきそう（苦笑）ですが、そもそもの話として、特定の業務に特化して使いやすいITシステムを開発すれば、特化した概念構造、特化した操作感になるのは論理的な帰結です。更に、特に開発プロセスを規定せずに各開発チームの流儀でばらばらにシステムを構築すればサイロ化するのは当然でしょう。
”特定の業務に特化して使いやすいITシステム”とは、その部門の対象業務の意味の場を的確に認識・理解したシステムとも考えられます。その意味の場は、同じ社内の他部門が直面している意味の場とは、当然ですが異なります。もし同じ意味に対峙している部門が複数あったとしたら、それは、社内派閥抗争等不穏な事態が生じた結果かもしれません。
複数の部門が、それぞれの意味の場に則った IT システムを構築するとしましょう。多分それが、その会社にとっての業務品質・生産性を上げる最適解になるはずです。しかし、それぞれの意味の場は意味的に独立していることから、IT システムが扱うデータ（そのデータの意味の構造は、それぞれの意味の場で異なる由）がサイロ化することは原理的に必然でしょう。ただし、それぞれの意味の場のデータを、その概念ドメインを対応付けるブリッジを定義することによって、システム間のデータを結びつけることは原理的に可能です。この状況は一見すると、同じようなデータ項目が重複して複数の IT システムに散らばっているように見えるかもしれません。しかし、同じ項目のように見えるからといって、重複を排除してしまうと、それぞれの意味の場における意味的つながりが消えてしまうので、その行為は浅はかといえるでしょう。ITシステム・データの統合とは、異なる意味の場に現象するデータ項目を対応付けることであって、安易なデータ重複削除ではありません。
コンサルタントの口車に乗って、サイロ化している IT システムの統合作業はやめた方が良いでしょう。問題はサイロ化ではなく、ITシステムが統合されていないこと、あるいは、統合するのが難しいことです。この問題を解く唯一の方法は、「全開発チームが共通のルール・形式に従ってデータ構造や操作感を定義し実装する事」です。読者の組織が既にそのような手段を持っているならそれを使えば良し、なければ、本稿で解説する概念モデリングと実装方法の利用をお勧めします。
以上、ドメイン群を統合することにより、IT システムを組み立てる方法を解説してきました。本稿で何回も言及しているように、主にモデルの規模により便宜的に分割したアプリケーションドメインは例外として、基本的にドメインは意味論において独立した存在（数学的に言えば直交関係ともいえる）であり、直接的で論理的な依存関係はありません。IT システム構築の段階で、ソフトウェアへの変換において対応付けが行われ、実装という意味論においてはじめて論理的な関係が生じます。
サイクリングというドメインは自転車なしでも記述できますが、実際にサイクリングを行うには自転車が必要なのと、同じです。
ドメイン・チャート
IT システム構築において、ドメイン間の実装上の論理関係を図示化したい場合は、下図の様に、楕円で表したドメインと、ドメイン間の論理関係を矢印で示した図を使うと便利です。
この様な図を”ドメイン・チャート”と呼びます。
ドメインとドメインをつなぐ矢印は、Shlaer-Mellor 法の時代から、”Bridge” と呼ばれてきました。”Art of Conceptual Modeling” においても、”Bridge”（日本語表記ではブリッジとする）と呼ぶことにします。
一見すると Bridge は、ドメイン間の階層を記述しているように見えますが、それは誤解です。Bridge もまた、二つのドメインを選択したときに生じる、意味の場・領野です。つまり、ドメインの一種ということになります。
”Bridge が意味の場・領野である”ことは、Bridge もまた、その意味の場を対象とした概念モデルが作成できることを意味します。その際の概念情報モデルは、二つ（以上）の概念ドメインの対応付けの構造に関するスキーマであり、状態モデルは、一方の意味の場の状態変化が他方の意味の場の状態変化にどう伝搬するか、あるいは、両方の状態の同期など、対応付けに関する振舞いを表すことになります。
問題解決 ⇐ 複数ドメインの組み合わせ
これまで、システム構築は複数ドメインの組み合わせだと解説してきました。
ここで、“0. 概念モデリングとは” の“概念モデリング ‐ なぜモデルが必要か”のセクションを今一度読み直してみてください。そこでは、
問題解決には問題を明確に記述することが必要
問題＝“現状の姿”と“あるべき理想の姿”のギャップ
つまり、二つの姿の明確化が必要
それぞれの姿は、複数の意味の場で構成される
それぞれの意味の場は概念モデルで記述される
とし、“だから概念モデリング的な体系は必須だよ”と解説していました。
この論に従えば、それぞれの姿が、複数の意味の場で記述される以上、システム構築に限らず、ビジネスや日常においても、複数の概念ドメインの組み合わせが問題解決の基本だということになります。
問題解決の種類
人間が認識する意味の場は実数無限だけ存在しえます。実際には、そのうちのいくつかだけに対して概念モデルを作成することになります。概念モデルが作成できたら、その意味の場は明確に定義できた、ことになります。
この道具立てを基に、問題解決のパターンを考えてみます。
まず、ある一つの意味の場にのみ、着目することにします。その意味の場は、ビジネス上の主題に近いものとします。
この時、問題として浮上しそうなパターンを挙げてみると、
概念モデル（圏C）がうまく作れない
現状に論理的矛盾が存在する
複数の意味の場が混在している
概念モデル（圏C）は作れたが、振舞いに齟齬がある
現状に論理的間違いが存在する
概念モデル（圏C）は作れたし、振舞いに齟齬もないが、目標値が未達
現状の圏I の規模などが不足
という3種類が存在します。最初の項目は、例えばビジネスプロセスや要件が、自然言語で記述されていて、曖昧な部分を精査したら、項目間で矛盾があった、というような、ありがちなケースです。
二番目の項目は、何かを実施するのに必要なリソースの取り合いで競合し、要求者が双方待ちになって、プロセスが滞るような状況です。現実を適切にモデル化すること＝現実が間違っていれば、モデルの文法・形式的には適切でも、そのモデル内容は不具合を抱えていることに注意しましょう。
この二つは、そもそも今の現実に不具合があるのですから、“あるべき理想の姿”は、それらの不具合が解決された、新たな概念モデルを記述することが、問題解決になります。
三番目の項目は、“現状の姿”の意味の構造をなすスキーマとしては適切なのにも関わらず、概念インスタンスの数の過不足や特徴値の値の不具合があって、“あるべき理想の姿”ではない、という状況です。“商品販売”であれば、注文数に対して商品の在庫が少ない、あるいは担当者に多寡がある、“製造管理”であれば、要求される生産数を達成できるだけの製造ラインが足りていない、といった状況です。このパターンでは、概念インスタンスの数、特徴値があらわす意味の場の存在を調整することが、問題解決の基本になります。
複数ドメインが関与するパターン
二つ以上の意味の場の組み合わせの場合を考えてみます。それぞれの意味の場の概念モデルは、前セクションの三番目の項目を満たしたレベルのモデルであるとします。
前のセクションで例示した、“商品販売”と“製造管理”を思い浮かべてください。商品販売で売る商品は、製造管理のモデルで規定された製造ラインで製造されるものとしましょう。商品販売の意味の場の側で、売り上げが20％アップした姿が“あるべき理想の姿”であるとしましょう。商品販売の意味の場としては、売り上げが20％アップするような圏Iのモデルを出来上がっている概念モデル（圏C）を基に構成すれば終わりです。その圏Iのモデルが、売るべき商品の納品が単位期間あたり、20％多く納品されるようなモデルだったとしましょう。この時、“製造管理”の側の意味の場でも、出来上がっている概念モデル（圏C）を基に構成された圏Iのモデルが、単位期間あたりの製造数が20％向上できるものでなければなりません。しかし、何時もそうなるとは限らないというのが現実世界のつらいところです。
このような状況はいたるところで生じる可能性があります。例えば、
IT ソリューションの構築において、利用しようとしているサードパーティー製のサービスが、想定するパフォーマンスとコストが折り合わない
リアルタイム制御システムにおいて、処理に対応するメモリが足りない、あるいは、応答性能に対して計算能力が不足している
営業目標達成のための施策は立案されているが、人、予算が足りない
納品日・品質厳守と言われているのに、残業禁止のお達しが出た
事業拡大に向けたビジネスプランを作ったが、必要な職能を持つ人の採用や、資金調達が進まない
経営計画で提示された改善指標に対して、現場の施策による効果が不足している
など、挙げればきりがありません。それぞれ、どんな意味の場の組み合わせなのかは、読者の皆さん、それぞれ考えてみてください。
“現状の姿”と“あるべき理想の姿”のギャプである問題の定義には、目標指標としての数字が伴います。この数字は、概念モデリングの場合、
概念インスタンスの数
それぞれの特徴値の値
ある事象（イベント）生起から、ある状態に移行するまでの時間
に関わる数値、もしくは、それらの数値を使って何らかの数式で計算された数値で表現されます。
精緻なモデル無しの概算値は常に胡散臭さが伴いますが、概念モデルを基に算出された数値は、論理的かつ合理的なのは言うまでもないでしょう。
前に説明したドメイン間のマッピングは、アプリケーションドメインにマップされる概念ドメインが、アプリケーションドメインが想定している数値の目標値を満たすものでなければなりません。
しかし、それぞれの意味の場は、無関係で独立しているというのが基本的な考え方であり、何時も都合よく、目標値が満たされる保証はありません。
むしろ、都合よくマッピングできるのは稀である、と考えた方が良いのかもしれません。
マッピングできない場合、目標値の数値目標を変える（概念モデル（圏C）はそのままで圏Iのパラメータを変える）か、その意味の場自体のモデルを見直す（発見する）かのどちらかしかありません。その際、概念モデリングにより、表現形式が統一されていることは、ステークホルダー間の共通理解の促進に役立つことでしょう。
IT システム開発の場合、大きな組織であればあるほど、組織階層が複雑になっていて、それが、更に事態を複雑にしてしまいます。経営層と現場部門に限ると、
それぞれの階層ごとに、問題設定がなされることになります。こちらも、概念モデリングの道具立てとの対応付けが可能です。
この図では、それぞれの層では異なる意味の場を扱っている、との考え方が基本になっています。一般的に見られる齟齬や混乱は、そもそも階層が違えば、意味の構造が全く違う、という事実を軽んじているから生じているのではないでしょうか。
大規模な組織では、更に、階層が増えることになります。参考までに図を添えておきます。
工程の自動化
最新のIT技術を活用した、概念モデリングを電子化と概念情報モデルのデジタル化により、インスタンスやリンクの設定、ドメイン間の対応付けの作業支援アプリケーション構築が可能になり、対応付けのルールも含めてデジタル化すれば、従来のソフトウェア開発における実装工程を大幅に自動化できます。また、デジタル化された資産、作業工程は、今流行りの DevOps とも相性が良く、DevOps環境にも容易に組み込めます。
ソフトウェアエンジニアリングに対する深い理解と実装技術に関する幅広い知識と豊富な経験を持っているソフトウェア技術者にとって、概念モデリングから実装までを自動化する開発環境の構築活動はとても魅力的な作業であり、腕に覚えがあればあるほど、100％の自動化環境を作りたくなる誘惑にかられるものです。しかし、自動化を進める場合には、
構築した環境を使うのは、一般的なレベルの技術者を含む複数の他人である
中途半端な自動化はかえって手間を増やすだけである
への留意が必要です。自動化が威力を発揮するための前提は、
開発に参加する全ての技術者が、概念モデリングの有効性を理解している
自動化環境構築にかかるコストが、自動化対象工程自動化による削減可能なコストに見合う
ことが最低条件です。
自動化を進めるにあたり、並行して、概念モデリングと自動化環境のトレーニングを用意し、適宜開発チームに提供していきましょう。
本稿で説明した概念情報モデルを使ったソフトウェアの実装は、概念情報モデルのインスタンス状態にルール化されたパターンを適用して実装ロジックを作っていくので、実装工程にかかる工数は、
実装工数 ∝ Σ（インスタンスの規模 × パターン数）
であり、この工数は自動化によって省力化されます。
※ 従来型の開発のケースで、設計や実装方針が各担当者に任されている場合、概念モデリングによるシステム開発における、対応付けルールとパターン定義をそれぞれの担当者が実施していることになります。サービスドメインやインフラストラクチャドメインに相当する概念に対応するための基本方針的なものは、流石に従来型の開発でもあるでしょから、概念モデリングの開発工程の規模を Σ（ドメイン一個当たりの工数）とすると、従来型では、≒ 07 × 担当者数 × Σ（ドメイン一個当たりの工数）ぐらいではないかと思われます。
概念モデリングを活用したシステム開発の自動化は、見方を変えれば、システム開発工程を電子化し、デジタル空間上に写しを作る、システム開発工程のデジタルツイン化であり、それを活用したシステム開発工程のデジタルトランスフォーメーションであるという見方もできます。
ビジネス向けのITシステムと同様、小さく始めて多く育てる進め方も有効でしょう。
変換による自動生成の技術体系を、より詳しく理解したい方は、
「Art of Auto Sofutware Development Deliverables Generation」を、概念モデルからの”変換による自動生成”が、実際どういうものか、興味のある方は、以下をご参照ください。
「BridgePoint で作成した概念モデルを In Memory で動作する C# アプリケーションライブラリに変換する」
アーキテクチャ再考
“アーキテクチャ”という用語は、普段のソフトウェア開発においても、よく使われる用語です。大抵の場合、開発対象のシステムの機能構成図やデータの流れを概観する図と補足情報をアーキテクチャと呼んでいる事が多いです。
実は、アーキテクチャは、ISO/IEC/IEEE 42010 で明確に国際標準として定義された用語です。
この標準において、Architectureとは、
⟨system⟩ fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
であり、
An architecture is what is fundamental to a system — not necessarily everything about a system, but the essentials.
と定義されていて、システムを構成の全てではないが、その本質を記述するモノだとしています。
更に、“fundamental”とは、
That which is fundamental to a system may take several forms:
- its elements: the constituents that make up the system;
- the relationships: both internal and external to the system; and
- the principles of its design and evolution.
であると定義されています。本稿で解説してきた概念モデリングと実装方法は、主題領域ごとに elements=概念クラス と relationships=関係 を抽出して定義し、principles of its design and evolution=それらを実装技術に対応付けるルール を定義するという対応が成り立つので、本稿で紹介した“概念モデリング”ד変換による実装”という作業工程は、アーキテクチャを厳密に定義する過程であると、言ってよいでしょう。
思考と概念モデリング
人間は思考する生き物です。マルクスガブリエルによれば、考えることは、感覚の一種であり、考覚なのだそうです。
え？と思うかもしれませんが、「ふと、考えが浮かんだ」とかよく言いますよね。一般的には、人間は五感を通じて得たそれぞれの結果を情報処理していると言われます。五感を通じて現実世界の情報を得ているのは仕組みとして正しいとしても、実際には、視覚、聴覚、嗅覚、触覚、味覚を統合した情報が頭に浮かんでいるのが実情です。例えば、海岸で景色を眺めている場合、単に色の点の集合が見えているのではなく、時空間にマップされた、あれは海、波、島、船、魚、砂浜、といった意味付けされた考覚が浮かぶといった具合です。また、目にできたり触ったりできるもの以外でも、例えば、数字のイチ、二、サン、や、加減乗除の記号、方程式、といった意味付けされた考覚を感じています。これらは、概念モデリングの観点からすると、対象世界と一対一対応の付いた圏Iのモデルと同等であると言えます。新実在論によれば、考覚は、意味の場ごとに複数の感覚がある、つまり、人間が考覚を通じて得た感覚は、意味の場ごとの圏Iのモデルであると言ってよいでしょう。先程挙げた、海や波という意味付けに感じられたものに対し、見方を変えて、今浜辺にいる人間は何人いる、とか、魚が何匹見られる、とか、船が単位時間当たり何隻航行していく、など、眺めている世界に対して、別の意味付けを行って同時に感じることも、人間には可能です。この際、一つ目の空間的なマップがなされた感覚は、無意識のうちに、その意味の場のスキーマ（圏C）のモデルと紐づけられていると考えられます。また、後者の統計的な見方は、無意識にも意識的にも、別の意味の場のスキーマ（圏C）で規定される1対1の圏Iのモデルだと感じているわけです。
また、見えたり触ったりできるものだけでなく、数学や自然科学、法律、など、頭の中でしかイメージできない世界も含めて、それらに対したのが初めての時には、それを構成する事柄が何を意味するのかは、理解できないでしょう。
何回かそれに対しているうちに、「あ～○○は○○なのね」となっていくのが普通です。この過程は、圏I のモデルを構成しながら、そのスキーマである圏C のモデルを構築していく過程と同等だと考えられます。考えの精査、別の視点から考えを認識する、考えから新しい視点を発見する、これらの過程は、一般的には、”思考”と呼ばれるものです。
また、人間は何かの分野に習熟すると、単なる空間的なマップ的な意味のスキーマではなく、より高度な知識体系に基いた判断を、半自動的に下すことも可能です。これは、思考により構築された圏Cのモデルが考覚に組み込まれたと考えてよいでしょう。
人間はさらに、ある仮定の状況を想定して、その状況がどう変化していくことを推論することができます。これも“思考”の一種です。
この考覚を基にした思考を行っている主体が、意識と呼ばれるものだと著者は考えています。もしかすると、考覚を通じた同時並行的に生じる圏I のモデル群を統合するという場で、意識が生じるのかもしれませんね。
ここまでをまとめると、思考とは、
考覚で感じたモデル（圏I）を精査する
複数の異なる意味の場のスキーマ（圏C）で、モデル（圏I）を考覚として感じる
考覚で感じたモデル（圏I）からスキーマ（圏C）を構成する
あるスキーマ（圏C）を基にモデル（圏I）の初期状態を構築し、推論を行う
であると考えられます。最初の二つは、概念モデリングの用語を使うと、あるスキーマ（圏C）を基にした、Domain Function のクエリー実行であると言えます。三つめは、圏Iの要素から、メタモデルをスキーマとした圏I のモデルの構築であると考えられるので、Domain Function の状態変化を伴うモデルの操作アクションであると言えるでしょう。最後は、初期状態の構築には、三つ目と同じ、Domain Function の状態変化を伴うモデルの操作アクションであり、推論は、Domain Function のイベント生成、そして、そのイベントに応じた状態モデルをひな型とする状態機械の実行、及び、Domain Function のクエリー実行による状態確認だ、ということになります。
ここで述べたことは、あくまでも現時点での著者の解釈にすぎません。もしかすると、識者からの多数の反論が来るかもしれませんね。
しかし、概念モデリングは、フッサールの現象学、ウィトゲンシュタインの言語哲学（論理学）、マルクスガブリエルの新実在論、圏論をベースに、Shlaer-Mellor 法を Refine & Redefinition したものなので、結果的に、人間の思考をモデル化したものになっていると考えれば、概念モデリングの道具立てを用いて、考覚、思考を記述可能なのは、論理的帰結なのかもしれません。
現実の世界＝概念ドメインとブリッジの組合せ
命題は、一つの意味の場においてだけ成立する
これまで説明してきた通り、概念モデルは、一つの意味の場ごとに作成します。概念モデルは、意味の場のスキーマである概念ドメインの厳密な記述であり、意味の場の状態は、概念モデルをスキーマとした圏I のモデルで表現されます。圏I のモデルは
概念クラスをひな型とした概念インスタンス
概念インスタンスは、値が確定した、概念クラスに付与された特徴値の組を持つ
関係（Relationship）をひな型とした、概念インスタンス間の意味的リンク
で構成されます。この構成は、概念モデルの記述に従って導出された命題文としてあらわすことが可能であり、それは、有意味な命題文です。
有意味とは、現実世界の状態との対応付けが可能で、かつ、対応する状態があれば、True、対応する状態が無ければ、False であるということです。
話はそれますが、Digital Twins の IT ソリューションがあったとすると、Digital Twins の Twin Graph が圏I、Twin Model が概念モデリングの概念情報モデル（圏C）に相当し、Digital Twins が現実世界の写しであるという定義に従えば、Twin Graph は圏Cのモデルから導出された命題文が、常に True でなければならない、ということです。
話を元に戻しましょう。”4．概念振舞いモデル”では、概念モデルを使ったシミュレーションについて解説していますが、このシミュレーションが有意味なのは、概念モデル（の圏）が、対象とした意味の場のスキーマ（の圏）と自然同値であることに加えて、概念モデルから、圏I のモデルの命題文が導出でき、その意味（True or False）を判定できることに由ります。
同時に在る複数の意味の場の可能条件
これまで述べてきた概念モデルによって導出した圏Iのモデルの命題文に関するお話は、全ての意味の場について成り立ちます。
ここで、例として挙げた”製造管理”について考えてみます。対象となる製造装置は、ある会社で稼働している生産ラインだとします。
会社組織なのですから、製造装置を動かす社員や担当する生産部門、製造した商品の販売、営業、商品を製造するための原材料の調達部門、製造装置の購入や減価償却といった固定資産管理、社員の給与や売上げ、工場をはじめとする会社組織運営にかかわるコスト、売上などを管理する財務部門、組織や社員を管理する人事部門など、様々な役割を担う、人、モノ、金、組織が同時に存在します。それらの組織が無ければ製造管理は成り立たないのは自明でしょう。
この状況を概念モデリング的な観点に眺めると、それらは全て、それぞれの意味の場であることになり、複数の意味の場の状態（圏Iのモデル）が並存していることになります。前述のとおり、概念モデルは任意の意味の場を対象とできるので、並存する全ての意味の場についての概念モデルが存在することになります。
また、製造管理において、どこかの装置を担当する社員がいるとすれば、その社員を人事的な観点から意味付ける人事部門が存在することになります。ほかにも、生産ラインで商品の製造を担う製造装置は、総務部門では固定資産として意味付けられることでしょう。
つまり、事柄は一つの意味の場の一存在であるだけでなく、別の意味の場においても対応付けられる事柄が存在するということです。よって、複数の意味の場は、単純に無関係に併存しているのではなく、同時に、意味の場を対応付けるブリッジも、複数同時並行的に存在することになります。
この時、全ての意味の場の概念モデルをスキーマとした、ある時点の現実世界の状態の記述は、
全ての意味の場において、導出された命題文は有意味でかつ、True である
複数の意味の場を対応付けるブリッジについても、同様である
でなければなりません。
意味の場ごとだけを考えれば、その概念モデルをスキーマとした、有意味な命題文が導出可能な圏I のモデル（意味の場の状態）はいくらでも記述は可能ですが、実際に現実世界に即せるのは、同時に並存する全ての意味の場で、命題文が True であるときだけです。
小難しい説明で恐縮ですが、このことは、考えてみれば当たり前のことでしょう。人・もの・金という資源や、製造技術、スキルといったものを無視して製造管理だけを最適化することはできません。リアルタイムの制御システムにおいても、制御対象の物理法則や計算資源を無視した制御は不可能です。我々人間が道具なしには空を飛べないことも、ワンピースの悪魔の実が実際には存在しないのも、概念モデリング的な観点からの説明は上述の通りです。
「あたりまえじゃん、そんなの…」と思う読者も多いとは思いますが、ビジネスにおける改善タスクや、イデオロギーが絡んだ主張では、案外、こんな当たり前のことが平然と無視されるケースが多いようにおもえてなりません。ある意味の場だけにフォーカスを当てて最適化したとしても、ブリッジで対応付けられた別の複数の意味の場が並存する場合には、こちら立てればあちら立たず、という状況が生じてしまいます。
前述の”ビジネスにおける問題解決”における評価指標の対応付けは、本セクションで説明している、対応付けのある複数の意味の場の並立においての話になります。アプリケーションの意味の場での夢想物語を現実のものとするには、評価指標に紐づけられた別の全ての意味の場の状態を整合させなければなりません。どう整合をとるか、これが問題解決において一番の難題なのかもしれません。残念ながら概念モデリングは、難題の解決策を提供する手法ではありません。しかし、いったい何が難題を生み出しているのか、その原因を具体的に認識・共有しなければ、解決するのは不可能です。原因を認識・共有するための技法が、概念モデリングです。
概念モデリングを実践する際には、一面の意味の場だけを取り上げるのではなく、同時に並存する別の意味の場がないか、常に気を配ることが重要です。
意味の場を存在可能にする概念ドメイン
前のセクションでは、製造管理という意味の場は、会社に関する様々な役割の意味の場と同時並行的に存在すると説明しました。見方を変えれば、製造管理という意味の場は、それら同時並行的に存在する意味の場無くしては存在しえないともいえるでしょう。
我々を取り巻く世界を思い浮かべてみましょう。我々の体も、体を保つための食物も、周りにある道具や家具、機材、建物、我々を取り巻く自然環境も全て、分子の構成体です。分子は原子でできており、原子は、電子と原子核、原子核は陽子と中性子からなっています。更に電子も含め、物質は素粒子から構成されています。また日常において、我々の行動はニュートン力学に支配されていますし、我々が住まう地球を含む大宇宙は相対性理論に、極微の世界は量子力学の法則に従います。
これらの物理学の基本法則なしには、我々の日常は存在しえません。
また、これを書いている私も含め、これを読んでいる皆さんの思考は、物理的な法則に則って存在する脳細胞から構成されたニューラルネットが無ければ存在しえません。
ほかにも、この文章で書いているような思想の展開、会社における業務遂行や日常生活が安穏と過ぎていくのは、日本国という安定した国があるからですし、日本に存する様々な制度のおかげです。
物理法則、社会制度、その他、我々、及び、我々の活動を支える全ての仕組み・役割は、全てそれぞれの意味の場であると考えられます。そのような別の意味の場がそもそも存在できるようにしているような意味の場のスキーマのことを、”意味の場を存在可能にする概念ドメイン”と呼ぶことにします。
業務の改善、日常生活をより有意義に過ごすこと、などなど、そんなことに思いを馳せている時、物理法則や社会制度まで考えるのは、よほど変わった人でしょうし、そんなことを深く意識しなくても、日々は滞りなくやり過ごしていけるのは、本来的に日常生活を送るための意味の場と、それを支える意味の場が、意味的に独立しているからだ、というのが概念モデリングからの回答になります。ただし、支える側の意味の場と、日常生活に関わる意味の場との間には、両方を対応付けるタイトなブリッジが存在するため、夢想の限りのパフォーマンスは出せませんが。
このような考え方からすると、ビジネスやリアルタイム制御に関するソフトウェア開発において、そのアプリケーションに相当する意味の場を、コンピュータ上で実現するための、”インプリメンテーションドメイン”もまた、”意味の場を存在可能にする概念ドメイン”であると言えるでしょう。Digital Twins に限らず、ビジネス系の IT ソリューションでは、現実世界のビジネスプロセスのモデルが、ソリューションの中に何らかの形式で存在するのは間違いないですし、リアルタイム制御についても、その制御対象の現実世界の物理モデルが必ず存在しています。ソフトウェア開発とは、現実世界の”意味の場を存在可能にする概念ドメイン”を、コンピュータテクノロジーによる実行環境という概念ドメインに置き換える作業だと言えます。
補足ですが、小説や漫画、映画など、虚構の世界は、物理法則で縛られた物理的実世界を必要としません。もちろん、それらを表記するための、紙やフィルムという意味の場は必要ですが。それら虚構の世界も、複数の意味の場から成り立っています。対応付けられる物理的実世界の意味の場で現象している存在群は存在しませんが、それぞれの意味の場では、その概念ドメインをスキーマとして有意味な命題を導出できるので、意味論的な破綻はありません。更に複数の意味の場間の対応付け（こちらもブリッジの概念モデルで命題の導出が可能なので有意味である）ができている、それが、良く出来た虚構の物語だといえるでしょう。
表現のための概念ドメイン
次に、モデル図について考えてみましょう。概念情報モデルは、図で描く場合は、概念クラスを長方形で表し、長方形の上部に概念クラスの名前を書いて、その下に左詰めで特徴値の名前を、”:”で区切ってそのデータ型の名前を、更に、”{}”で囲って、識別子であることや参照特徴値であることを示す記号を記述します。関係（Relationship）は、長方形を結ぶ線で表現し、中ほどに関係の名前、両端に、述語と多重度を書くようになっています。”1．概念情報モデル”でも解説していますが、概念情報モデルを図で描かなければならないという決まりはありません。YAML や JSON、XML を使ったテキスト形式でも、表現方法は問いません。このことは、概念情報モデルに限らず、状態モデル、アクション記述でも同様です。圏I のモデルに至っては、正式な記法すら、概念モデリングでは規定していません。
重要なことは、モデル化対象の意味の場を正確にモデル化することであり、奇麗な図を描くことではないからです。概念モデルは、概念モデリングのメタモデルをスキーマとする圏Iのモデルであると、前の方で説明しましたが、本当に重要なのは、この圏Iのモデルです。モデルを図で表記するということは、この概念モデリングのメタモデルに対して、図形を対応付けることを意味します。つまり、モデリングの記法とは、図形の意味するところとメタモデルの構成要素との対応付けに関する意味の場だよ、ということです。
テキスト表記の場合も、本質は一緒です。概念モデリングのメタモデルの構成要素に、単語と文法・形式を対応付ける意味の場が、テキスト表記の記法だということです。このような意味の場のスキーマのことを、”表現のための概念ドメイン”と呼ぶことにします。
図表記にしろ、テキスト表記にしろ、その意味の場自体は、その記法に従って表現される対象の意味は持ちえません。逆に、持っていないからこそ、様々な意味の場のモデルを表現可能なのです。
概念モデリングに限らず、皆さんが何らかのモデルを図やテキストで表記する時、同時に二つの意味の場のモデルを作っていることになります。より正確に言えば、そのモデリング技法のメタモデルの状態（圏Iのモデル）を構成しつつ、メタモデルの要素に紐づいた図やテキスト・記法を選択する、になるでしょうか。
xtUMLの専用ツールの BridgePoint では、モデラーが描いたモデル図が、xtUMLのメタモデル（概念モデリングのメタモデルとほぼ一致）に従った圏Iのモデルと、図表記法の概念情報モデルに従った圏I のモデルを分けて保存しているのが、実際に確認できます。
プログラミング言語も、そのスキーマは、”表現のための概念ドメイン”と言ってよいでしょう。数学や論理式の記法もまた、同様でです。
テキスト表記の場合、その概念ドメインの概念情報モデルは、通常、ASN のような抽象構文で代替されます。
既存の意味の場を基に新たに創発？する概念ドメイン
最近、データ分析に生成系AIを取り入れる動きが加速しています。データ分析自体は、エクセルのマクロ活用、データウェアハウスによるビッグデータ分析技術など、昔から活発に行われており、Digital Transformation（DX）においても欠かせない手段でしょう。
データ分析において、自分が何のデータに対して何を目的として、分析を行うのかを理解していることは非常に重要です。それが無ければ、なんとなく流行っている小難しいデータ分析技法なるものを使いこなして、結果得るのは達成感だけということになりかねません。
”何のデータ”は、当然のことながら、”何らかの意味の場の状態”に相当します。データがリレーショナルデータベースに格納されている場合は、そのデータスキーマが存在します。そのスキーマが、概念モデリングの概念情報モデルと同等かどうかは微妙ですが、”何のデータ”かに対するデータモデルであることは間違いありません。データがExcelやNoSQLデータベースに格納されている場合は、複数の意味の場の状態が混在しているような状況かもしれません。いずれにせよ、分析対象となるデータが何なのかを理解することは、データ分析を始める第一歩であることに間違いはなく、その作業はいわゆるデータモデリングです。データモデルの作成に関する書籍やネット上の記事は山ほどあるので、どれか適当と思われる技法を用いてデータモデルを作成することになります。データモデリングは、既に存在するデータ群の意味付けを確認する作業とも言えるので、採用した技法は、概念モデリングのそれと本質的に同じ作業を行うものであるはずです。
分析作業は、分析対象のデータに対して様々なルールを設定して、別の観点からのデータセットを生み出します。この”別の観点からのデータセット”もまた、概念モデリング的に考えれば、ある意味の場（＝別の観点）の状態であり、そのスキーマとしてのデータモデルが必要であり、分析作業に当たっては、その観点の意味の場の概念モデルを作成すること相当します。
そして、”様々なルールを設定”は、概念モデリングにおける”変換による実装”と本質的に同じ作業です。もちろん、”変換による実装”を実践するには、変換元となるデータセットに対して概念モデルが必要になりますが。
日本においては、リレーショナルデータベースを活用しているシステムでさえ、妥当なスキーマが定義されていることは少ないような印象を持っていますし、データが Excel や NoSQL の場合はそもそもスキーマがありません。
稼働しているリレーショナルデータベースのスキーマを変更することは、全く不可能なので、殆どのケースで、分析＝変換のソースとなるデータモデルを作る必要が生じます。この作業は、既存のデータセットをもとに、潜在している意味の場の発掘と、意味の場ごとのデータスキーマ（＝概念情報モデル）の作成、既存データの整頓によるデータスキーマに基づいた圏Iのモデル作成によって完遂されます。
このような作業を経て、既存データの整理整頓を行っておけば、別の観点からのデータ分析を行う際にも、手間が省けることでしょう。しかし、既存データは、日々の業務データであり、また、IoT 機器が連動したシステムであれば、時々刻々とデータが更新されていきます。既存データの整理整頓は、一回やれば終わりというものではなく、データ分析を行うタイミングでの更新が必要です。
加えて、現時点で、ビジネスが今どうなっているかを把握し、問題生じていればイベントを発することが可能なダッシュボード経営を行うならば、既存のシステムのデータ更新に合わせて、整理整頓を実行する必要もあるでしょう。
実際にこの一連の作業・運用を行うには、それぞれの項目の実行が可能な IT環境が必要です。Microsoft Azure や Amazon Web など PaaS 型サービスを組み合わせることによって、そのような IT 環境の構築が可能です。Microsoft Fabric という SaaS 型のサービスでは、生成系AIとも連動した、このような IT環境が既に提供され始めています。Microsoft Fabirc では、データモデリングの環境として、セマンティックモデルやオントロジモデル、グラフモデル、などといった道具立てが提供されています。ある意味、Microsoft Fabric は、このセクションで紹介した一連の作業を概念モデリングをベースとして、実践可能な環境であると、筆者は考えています。
以上、データ分析について紹介してきました。その中の、分析結果用のデータモデルについて考えてみます。
このデータモデルが対象とする意味の場は、前述の作業の流れからすると、既に存在している複数の意味の場の状態を基に派生した意味の場であるように見えます。しかし、”考え方１）データ分析とは、ある目的に対して分析を行うものなので、データ分析で作成するデータセットは、その分析目的の意味の場の状態でなければならない”というのが、本来的な考え方であるべきでしょう。
一方で、”考え方２）分析したいという動機は、対象となる既存の状態があればこそ生まれるものであるとも考えられます。そうであれば、分析目的の意味の場・概念ドメインとは、既存の複数の意味の場の概念ドメインから創発されたもの”であるとも言えます。
データ分析に関するこの二つの考え方は、どちらかが正しい・間違いだというものではないので、実践においては、既存データの在り様、使用可能なIT環境で、二つを織り交ぜて作業を行うのが実践的なプラクティスでしょう。
このような分析はアドホックに、必要に応じて行われることになりますが、各社のビジネスは大同小異でしょうから、創発された概念ドメインを一般化することも可能です。それが、いわゆる、MBA で教えられるようなビジネステンプレだと言ってよいでしょう。
MBA におけるビジネステンプレが出来上がる過程を考慮すると、”考え方２）”がまずあって、それが一般化されると”考え方１）”になると考えるのが妥当なように思えます。そうであれば、分析結果のデータモデルに関する意味の場・概念ドメインは、やはり、”創発的”として良いように思えます。
これは哲学的な問いを含んでいるように思えます。
我々の日常を取り巻く世界に関する様々な”意味の場”に現象する存在群は、”物理学”でモデル化可能な意味の場があるから存在が許されています。果たして我々の日常を取り巻く”意味の場”は、創発的なのでしょうか？
数学や相対性理論は、人間が考え出した論理であることは間違いないものの、その自然同値なモデルは、人間が考え出す前から本質的には存在しているとも考えられます。そうであれば、これらは人間が創発・発明したのではなくて、そういう意味の場を発見したことになります。
データ分析における目的も、既存のデータセットが存在すれば、少なくとも概念ドメインは記述できる、つまりは人間が創発・発明するのではなく、単に、発見しているだけなのではないか？
この考え方を突き詰めていくと、意味の場とは、人間が意識するしないに関わらず、無限に存在していて、人間がそれに意識を向けたとき、その意味の場を曖昧に発見するという考え方に至ります。これはマルクスガブリエルが唱える新実在論の無数の意味の場という論に近いように思えます。そして、その意味の構造を理解した時、その概念ドメインを発見した、ことになるのでしょう。そうであれば、概念モデリングによるモデリングとは、モデルを作ることではなく、モデルを発見すること、なのかもしれません。
概念モデルを作るのか、発見するのかは、とりあえず脇に置いておきましょう。「さぁ、概念モデル作るぞー」、という時点では、どんな意味の場があるのか、具体的には分かっていないものです。フッサールの現象学には、”エポケー”という、認識したものが何であるかを判断する直前で止める、という考え方があります。”認識したものが何であるか”、を、”認識した何らかの実在を、意味を伴なった実在として認識すること”とすれば、エポケーは、意味の場を明確に切り分ける直前のことを指すと考えられるかもしれませんね。
自然同値な関係にある概念ドメイン
それぞれの意味の場と、そのスキーマである概念ドメインは、数学の圏論を使って、それぞれ圏として定義が可能です。
ある二つの概念ドメイン（＝概念モデルで記述）の圏が、自然同値な関係にある場合、一方の概念ドメインをスキーマとした意味の場の状態（圏I）の振舞いと、他方の概念ドメインをスキーマとした意味の場の状態（圏I）の振舞いは同じであることが保証されます。
自然同値な関係にある二つの概念ドメインとは、概念モデルの構造が完全に同じであることを意味します。つまり、モデルで使われているテキストの違いは無視して、形式的に、
概念情報モデルの構造の一致
データ型の構造が一致している
特徴値のデータ型が一致している
概念クラスに付与された特徴値の組が一致している
概念クラス間のリレーションシップが一致している
リレーションシップの多重度が一致している
状態モデルの構造の一致
概念クラスの状態モデルが一致している
状態モデルのイベント、状態、状態遷移が一致している
アクション記述の構造の一致
エントリアクションのデータフローモデルが一致している
プロセスの入出力データの構成が一致している
であることです。ある事項について、一見全く関係のないような事項で説明する、アナロジーやメタファーが成り立つとすれば、双方が自然同値にあると言ってよいでしょう。
また、物理学の様々な方程式が現実世界の現象をうまく予想できたり、概念モデルを使ったシミュレーション結果が、モデル化対象の現実の意味の場の状態と一致するのも、この原理によると思われます。
ブリッジ
ブリッジの厳密な定義
以上を踏まえて、最後に、概念モデリングによるブリッジの厳密な定義について述べておくことにします。
ブリッジとは、複数の意味の場に現象する存在を対応付けるものである
ブリッジは、”複数の意味の場の対応付け”という意味の場である
ブリッジは意味の場に関するものであるので、ブリッジに対する概念モデルの作成が可能です。対応関係は、対応付で対象となる意味の場ごと、対応付ける目的ごとに、異なるので、概念モデルのメタモデルのような汎用のモデルは存在しません。
ブリッジに対する概念モデルの解釈、及び、満たすべき要件を以下の通りとします。
具体的な対応付け関係
⇒ 概念モデルをスキーマとする圏I のモデル
対応関係に関するスキーマ
⇒ 概念モデル
対応関係に関する意味的構造 ⇒ 概念情報モデル
双方の対応付けの変化・振舞い ⇒ 状態モデル
対応付けに関するルール
エントリーアクション
ドメインファンクション
ブリッジの厳密な定義を行う際には、これらの道具立てを使うものとします。
ブリッジの種別
これまで述べてきた通り、ブリッジは、以下の二種類に分類されます。
アプリオリなブリッジ
ポストプリオリなブリッジ
最初の種別は、実際の世界を眺めて、複数の意味の場の概念モデルで記述したとき、既に存在している、意味の場の状態の間の対応付けです。
二番目の種別は、複数の意味の場を実際の世界にはもともとなかった複数の意味の場を、様々な目的において対応付けを後付けしたブリッジです。この種別のブリッジは、実践上二つの種類に分別があると考えられます。
仕組みの対応付け
新たな目的の対応付け
前者は、問題に対する解決策の対応付けるブリッジです。ソフトウェア開発は、このブリッジを案出することであり、Shlaer-Mellor 法の”アーキテクチャドメイン”に相当します。
後者は、既存のデータを基にした分析作業において案出されるブリッジです。
まとめ
以上、概念情報モデルの基盤となるドメインの深堀と、複数のドメインの対応付けによるITシステムの設計・実装、及び、その自動化について解説してきました。
これまで説明してきた内容を踏まえ、もう一度、「概念振舞モデル」を読むと、概念モデルを使ったITシステム開発に関する理解が深まります。
本コンテンツでの解説は、あくまでも概念モデルを使ったシステム開発を行うための基礎知識に関する内容です。より実践的なテクニックを学びたい方は、「概念モデリング・システム構築実践ガイド」や、”概念モデリング ～ 虎の巻”に進んでください。
また、”IoT・Digital Twins を極めよう！”でも、豊富な実例を取り扱っているので、そちらもご熟読いただければ幸いです。
本稿を含む、”Art of Conceptual Modeling” の一連の記事は、私がマイクロソフトを退職した2022年に書き始めたものです。その時点では、概念モデリングとは Shlaer-Mellor法（xtUML）を ITシステムやビジネス問題解決に対象を拡張した、技巧的な方法論という認識において執筆を進めていました。
その後、2024年4月あたりから、哲学、言語学、数学、論理学などで概念モデリングを見直す作業を進めてきたわけです。
2022年当時に書いた記事は、その領域には全くの素人で、1990年代から2000年前半にかけての Shlaer-Mellor 法実践経験と、マイクロソフトでの最新技術普及・啓発活動、及び、最新技術導入支援の経験だけを踏まえて描いたものであり、ソフトウェア開発を前提とした技巧的な説明に終始していました。
二年近くの調査を経て、毛が生えた程度ではありますが、哲学、数学、言語学、論理学の理解が進み、それから得た見解を書き加えているのが、今現在の記事ということになります。そんな理由で、技巧的な話と、深淵なるそもそも論が混在してる記事なってしまっているのが現状です。
今後も、整理・見直しを進める所存でございます。
マルクスガブリエルの新実在論によれば、意味を伴なう実在はそれぞれの意味の場で現象し、世界は複数（無限）の意味の場から成り立っているとされています。そして、意味の場は人間の思考には関係なく、それがリアルだとのことです。概念モデリングは、意味の場ごとに概念モデルを作成し、その意味の場の意味的構造を作成します。
”意味を伴なう”とは、概念モデルをスキーマとすることであり、意味の場に現象する実在は、概念情報モデルをスキーマとする、値が確定した特徴値を伴なう概念インスタンス、及び、概念インスタンス間の意味的リンクです。
そうであれば、概念モデリングとは、”リアルな実在を対象とし、その意味的構造を探るするモデリング体系”である、といってよいでしょう。
