モデルおよびモデリングとは？
「モデル」とは「対象を如何に認識しているかを形式的に描いたもの」と説明できるでしょう。このことを分解していきます。まず、「対象の認識の仕方についての方法論」があるでしょう。どうやって対象を観測するか、観測結果をどのように認識に取り込むか、といったところの方法についてです。次に、認識された対象は、表現されないと第三者が認知できません。よって、その認識されたモノやコトを表現する道具としての文法（語彙群とそれらの構成パターン群）が必要で、その文法に則ってモデルは描かれます。
しかして、モデルやモデリングを語るときには、下記各事項それぞれについて如何なる想定を持っての話なのか、事前に明らかにしておくあるいは擦り合わせておく必要がありそうです。
(1) そのモデルもしくはモデリングは、どういったモノやコトが対象なのか？明示的にまたは暗黙的に、モデリングが対象とするモノやコトの範囲、対象領域についての想定があるはずです。
(2) そういった対象を認識するときの認識の仕方＝インプットの方法とは、具体的にいかなるものか？観測手法や観測結果の解釈方法についてです。
(3) 認識したモノやコトを具体的に表現する＝アウトプットするための文法（語彙群とそれらの構成パターン群）は、具体的にどういったものとなるか？
ところで、ここでは一旦は理屈として、インプットたる認識手法とアウトプットたる表現手法を、モデリングの構成要素として分離して捉えましましたが、実際的には、表現手法から独立した認識結果の内的イメージというものを、おそらく実際の心的内的機構として特定の表現手法に依存しない内的イメージというのは存在しないと思えるし、いずれにしても表現手法独立の内的イメージというものは少なくとも第三者的に取り扱うことが不可能なので、以降は「観測結果の解釈方法」と「アウトプットするための文法」とは同義だとして、話をすすめます。
つきまして、以上の「想定する対象領域」と「認識の方法としての観測手法と観測結果の解釈の表現手法としての文法」の、その両者への関わりの組み合わせより、「モデリング」に関して以下のような課題設定があり得る、と言えます。
(a) ある具体的な「対象領域」において、最も“最適”な「認識の仕方としての観測・表現手法」とはどういったものか？またその対象領域において“最適”とは何を意味するのか？
※「対象領域」を固定して、「認識の仕方としての観測・表現手法」を探る、という課題設定
(b) ある具体的な「対象領域」において、ある特定の「認識の仕方としての観測・表現方法」を用いたとしても、実際のモデリングを行ったとき、異なるモデラーは異なる対象認識やその表現を行うだろから、一般に異なるモデルを描くといえます。そうだとして、その中で「よりよいモデル」とはどういったモデルなのか？
※「対象領域」と「認識の仕方としての観測・表現手法」の両者を固定して、その中でのベストプラクティスを探る、という課題設定
(c) （少なくともある限定的な「対象領域」において有用とされている、）ある特定の確立した「認識の仕方としての観測・表現手法」があったとき、その手法が適用可能な「対象領域」はどれほど広げることができるだろうか？そのとき適用可能であるとの判定方法はどういったものとなるか？
※「認識の仕方としての観測・表現手法」を固定して、適用可能な「対象領域」を探る、という課題設定
(d) おおよその「対象領域」についての想定とおおよその「認識の仕方としての観測・表現方法」についての想定がある。それらを具体的に確立したものへと落とし込みたい。しかし、「対象領域」の取り方と可能な「認識の仕方としての観測・表現方法」の間には依存関係があるので、その依存関係を紐解きつつ「モデリング」として最も"effective"な落としどころを探りたい。「対象領域」と「認識の仕方としての観測・表現方法」との間の依存関係を紐解くこと自体と、「「モデリング」として最も"effective"」ということの具体的な評価方法の確立を含む。
※「対象領域」と「認識の仕方としての観測・表現手法」の両者を可変にして、「モデリング」としての最適解を探る、という課題設定
用語定義：モデリングの対象領域＝「ドメイン」？
モデリングの対象領域が「世界の全て」、とまでは言わなくとも、「全ての情報システム」くらいを捉えている場合もあるでしょう。また、「エンタープライズ向けの業務システム」や「組み込み系のリアルタイム制御に関して」などくらいの対象感を持っている場合もあるでしょう。あるいは、「生命保険業務」とか「生産管理における部品管理」とか「携帯端末向けUX」とか「Javaプログラムにおけるモジュール構成」とか「機械学習を利用した特異的利用者行動検知」、「リアクティブ処理系におけるデータ処理フローに関するモデル」、「Graph構造をとる組織情報に対する一般的データ更新に関するモデル」など、さらに具体的な対象の領域の認識を持っている場合もあるでしょう。
ここで、モデリングが想定する対象領域のことを「ドメイン」と言う、、ということに異論はあるでしょうか？
・・・とりあえず、本記事では以降は「ドメイン」の語を用いていきます。
モデリングの対象領域（＝ドメイン）とモデル表現文法の抽象度の関係について
直感より、「ドメインが狭ければ狭いほどモデル表現文法の抽象度はあげられ、ドメインが広いとあまり抽象度は上がらない。」という仮説を持っています。
「全ての情報システム」というドメインをモデリングするに用いることのできる文法は、おそらく「チューリング完全なプログラミング言語」以上には抽象度を上げられない。つまり、「全ての情報システムをドメインとするような場合のモデリング」というのは、一般的な「プログラミングのモデル（※Object-Oriented ProgrammingとかFunctional Programmingとか）」の問題におそらく帰結する。この推定が正しいなら、「全ての情報システム」というドメインを扱うのは、「モデリング」というテーマとしては実際的な意味を持たない、と言えることとなります。
一方で、ドメインが狭すぎると、「特定のタスクをこなすための便利ツール」になってしまうでしょう。たとえば、「Javaプログラムにおけるモジュール構成」のモデル表現文法の一つであるmavenのpom.xmlは、その典型例の一つです。
「モデリング」というテーマでは、可能な限り広いドメインに適用できる可能な限り高い抽象度の文法、を獲得しよう、というのも目標の一つとなっているはずです。（※これは上述のモデリングに関する課題設定の(d)に相当するものです。）
＜'15/8/12追記＞
下図は、横軸Dを「ドメインの広さ」（右が広い）、縦軸Asを「モデル表現文法の抽象度」（上が抽象度が高い）として、モデリングのドメインとモデル表現文法の抽象度の関係のイメージを描いたものです。（※あくまでイメージです。）
横軸の最も右端は「全ての情報システム」というドメインを対象にするとしています。そこではモデル表現文法の抽象度は高くありません。そこでの文法は「プログラミング言語」と称される群に含まれるでしょう。横軸の最も左端は「単一タスク」というドメインが対象だとしています。これは、例えばmavenによる「Javaプログラムのモジュール構成」などを想定したものです。ここでの文法は最も抽象度の高いものを用意できます。ここでの文法は「設定ファイル」と称される群に含まれるでしょう。モデリングの狙い目は、図の中央付近に位置します。そこそこのモデル表現文法の抽象度とそこそこのドメインのカバー領域の広さのバランスを探ります。設定ファイルからプログラミング言語までを含めた形式言語の広がりを見ると、いわゆる“モデリング”としての狙い目は結構狭いものです。
モデルの実行可能性（executability）に対する二つの姿勢
モデリングに関する別観点のテーマとして、「モデル」の実行可能性に対する二つの姿勢について整理しておきます。
（第一の姿勢）
モデルはモデルとして、モデルのレベルで、ドキュメンテーションとしての論理性や整合性が取り扱えればよくて、モデルが直ちにコンピューターによって実行可能かどうかについては積極的にスコープ外である、もしくは消極的に期待するポイントではない。
（第二の姿勢）
適切に考案されたモデリングであれば、直接インタープリットやコードジェネレーションを経て、実行可能である。実行可能なモデリングを考案することが目的である。
「複合モデリング」
応用的解法として、一つの大きめのドメインを解決するために、それを複数のサブドメインに分割し、各サブドメイン毎に最適なそれぞれ異なる文法を採用する、といった方法も想定できることを記しておきます。この方法を、本記事では仮に「複合モデリング」と称することとします。
＜'15/8/12追記＞一つのドメインとして単一文法でモデル表現しようとすると、あまり文法の抽象度が上げられない場合でも、特性の異なる各サブドメイン向けそれぞれに抽象度の高い文法を用意し、それら複数の文法を使い分けることで、トータルで高めの抽象度のモデル表現が可能となります。
“モデリングというドメイン”のモデリング
本記事の以上の論は、、、実は、“「モデリング」というドメイン”はいったいどのように認識可能でどのように表現可能か、すなわち、「「モデリング」についてのモデリング」を概念レベルで行っているに他なりません。「メタモデリング」ですね。『本記事が言及するモデリングの対象ドメインは「モデリング」です』、ということです。
◇
＜追記１＞
「DDD（ドメイン駆動設計）」とはどんなモデリングでしょうか？私の理解は次のようなものです。
(i) 戦略レベルの話、つまり「境界付けられたコンテキスト」や「ユビキタス言語」に関する論議は、「境界付けられたコンテキスト」＝モデリングの対象領域としてのドメイン、「ユビキタス言語」＝そのドメインにおけるモデル表現文法、にそれぞれマップ可能です。よって、DDDの戦略レベルの話は、モデリング一般において、大きめのドメインはサブドメインに分割して各サブドメイン毎に固有の文法を採用するという、本記事でいう「複合モデリング」の話にアプローチしている、と捉えることができます。いずれにせよモデリング一般に対する取り組み姿勢を論じているように理解できます。
(ii) 一方、戦術レベルの話、つまり「集約」、「エンンティティ」、「リポジトリー」などに関する論議は、エンタープライズ分野の業務システムにおいて（のみ）有用と思える設計パターンについての話です。すなわち、DDDはモデリング一般について論じている訳ではなく、エンタープライズ領域における具体的なモデル認識・表現手法を提唱している、と捉えられます。（※本記事前半に示したモデリングに関する課題設定の(a)として、一つの手法を提唱している、と理解できます。）
(iii) (ii)を踏まえると、(i)について、「境界付けられたコンテキスト」や「ユビキタス言語」の概念は「複合モデリング」を想定しているというよりは、一つのモデリングにおいてよりよいモデルを生み出すために押さえるべき概念を説明している、と捉えた方がよいような気がしてきます。（※本記事前半に示したモデリングに関する課題設定の(b)として、一つの手がかりを示している、と理解できます。）
＜追記２＞
私自身はと言えば、「エンプラ向け業務システムのバックエンド・サービス」という“ドメイン”において、実行可能なモデリングを実現するための文法を探る、という点に関心を持つ者です。
＜追記３（'15/8/12）＞
※重要です。
先日、株式会社匠ビジネスプレイスの萩本順三氏らによる「匠の夏まつり」という勉強会に参加いたしました。萩本氏は株式会社豆蔵の設立者で、「要求は開発するものである」という「要求開発」を提唱していた方です。その後モデリングを上流、超上流へと極めていき、現在「要求は「価値」に裏付けられなければならない」という観点を含む「匠メソッド」という集大成を構築されている、ということです。この度聴講させていただいて、例えばビジネス企画の在り方の分析結果を表現するような、人間系の思考や行動を描くことが目的の、そもそも情報システムを対象としないモデリングもある、ということに気付きました。いえ、認識していたつもりでしたが、例えば当初このブログ記事を書いたときにその認識が曖昧だったことに気付かされました。本記事の前半は、そういう意味でおおよそ「モデリング一般」についての論になってると思います。しかし後半は、対象とするドメインの広さとモデル表現文法の抽象度の関係性を論じるあたり以降は、「情報システムのモデリング」に限られています。
◆以上
