モデルとは何であって、何でないのか

金曜日に開催された吉祥寺.pm19でタイトルの通りのLTをしたのだけど、ちょっと補足したほうがいいかなと思ったのでブログを書いてみる。

kichijojipm.connpass.com

ちなみに資料はこちら。

speakerdeck.com

モデルって何?

「そもそもモデルって何?」みたいなツイートを数日前に見て、僕も最近そもそもモデルって何だっけって考えることが多くなってたのでこのLTをした。僕の中での定義は資料の中にも書いたけど

モデルとは解決したい問題領域から必要だと思われる情報だけを抽出し、特徴づけ、記号化や可視化をおこなったもの

である。

何のことやらって思うかもしれないけど、思考や設計を支援する概念的なものがそもそもモデルであって、決してクラス図やER図や状態遷移図や(ry のことをモデルって言うわけじゃないんだよっていうのを強調したかったのであえて抽象的な言い回しを使った感じ。

モデルの役割

発表では「記号化や可視化」っていう表現を使ったんだけど、その結果を人間が読むかコンピュータが読むかによって大きく2つに役割が分かれると思う。

  • 問題対象の俯瞰、理解促進、解決方法の模索
  • 演算可能なように(=ある演算を利用可能なように)する

後者は特に数理モデルとかって呼ばれるやつだと思うんだけど、今回扱った「 3 + 5 = 8 」みたいなやつもこっちに入る。

3 や 5 という記号化をおこなった時点で、それが 3 つのみかんなのか、3 匹の子豚なのか、焼肉を 3 人に奢るってことなのかという情報が失われる。失われるのだが、その代わりに四則演算という強力な計算体系を手に入れることができ、もともとの問題領域と無関係に、先人たちが研究して体系化した知識/手法を利用可能になるってことが言いたかった。

前者のやつはソフトウェア開発の文脈だと分析モデルとか概念モデルとかって呼ばれるやつだし、模型とかジオラマみたいなのもそうかなって思う。僕たちはガンダムをそのまま認識して「ここにこういう武器を装備したら強くなりそう」みたいな提案はガンダムが大きすぎて難しいんだけど、1/100や1/144のスケールのガンダムなら全体を俯瞰できて「これだと右側からの攻撃に対応できないからシールドを持たせようか」ってなる。*1

LTの中でも挙げたんだけど、地図っていうのもひとつの記号化で、これは微妙にどっちに分類すればいいか難しい。たとえばメルカトル図法は距離や面積という情報の正確性を損なう代わりに、ある地点から別の地点への方角が正しいことを保証する図法で、これは航海において舵取りが楽であるという多大な価値をもたらした。昔だったら地図を人間が見て「◯◯に行くには北北東の方角」みたいに判断して人間が舵をとってたと思うんだけど、今どきだと(船舶技術詳しくないから知らんけど)コンピュータに任せられると思うので後者の数理モデルに似たような恩恵を受けれるかもしれない。*2 (ちなみにわざわざ言うほどでもないけど、メルカトル図法において正しいのは方角であって、その方角にまっすぐ進んだ航路が最短距離となるわけではない。上述した通り、距離や面積は正確ではない。特に赤道から離れるほどに。)

いろいろな構造と演算体系

5 分の LT だったらあまり話せないから間違いなく誰もが知ってる四則演算と連立方程式を使って記号化の説明をしたんだけど、実際にはみなさんにもっと馴染み深い記号化はたくさんある。

たとえばリレーション、つまり RDB のテーブルがそれで、リレーションという形に記号化(この場合、構造化と言ってもよい)することによって関係演算(≒SQL)という演算体系を手に入れることができる。

また、関数という形に変換すれば、それらは関数合成、メモ化、部分適用などができるようになる。

ここで演算体系と言ってるものはアルゴリズムと言い換えてもよくて、グラフにすれば最短経路問題を解きやすくなるし、ツリーにすれば深さ優先とか幅優先とかの探索アルゴリズムを適用できて、もとの問題を数学的あるいはコンピュータ工学的に解きやすい別の問題に変換できる。

モデリングとは何か

以下のスライドを見て欲しいんだけど、これを見ると人間がやることは 2 つしかない。

ひとつは問題をどう捉えてどういう構造に変換するか、もうひとつはモデルの世界での演算結果を現実世界の概念にどのようにマッピングしなおすか、だ。

前者は説明不要だと思う。自分の立ち向かおうとしてる問題を効率的に解くのはグラフがいいのか、ツリーがいいのか、関数か、オブジェクトか、はたまたリレーションかっていうの考えるってことで、それによって上述したような演算を手に入れることができる。演算体系を手に入れたら(クエリを書いたり、パラメータを渡したりはしないといけないとはいえ)基本的にはコンピュータの恩恵が受けられるので、ここはそんなに難しくない。

問題は結果をどのように現実世界に戻すかってことである。「 3 + 5 = 8 」という演算結果自体は正しいんだけど、この結果である 8 というのを現実世界では 8 個の何かと捉えるはずで、その何かは何なのかが問題になる。これは他のモデルでも一緒で、関数合成した結果の関数は一体どういうものなのか、リレーションを結合したり選択したりして得られた結果セットは現実世界の語彙ではどのように表現できるのかを考える必要がある。

オブジェクトモデル

エリック・エヴァンスという人がドメイン駆動設計という本を書いているわけだけど、そこではソフトウェア開発のモデリングパラダイムの主流はオブジェクトモデルだと言ってる。念のため、言っておくけど、彼は他のモデリングパラダイムを一切否定はしていないし、オブジェクトモデルが主流である"べき"ともたぶん言ってない。

エリック・エヴァンスはモデルがそのまま実装可能であることということを強く強調していて、そのため

  • モデリングパラダイム自体の学習に時間をかけなくて済むこと
  • 技術者でない人でもモデルを理解できること
    • 技術者以外にも理解できないと、分析モデルや論理モデルと実装モデルが別になってしまうため
  • 実装技術が成熟していて、コミュニティやツールのサポートがあること
    • 実装自体で時間をかからないように

ということを重視している。

論理モデルパラダイムでルールエンジンのドメインモデルを構築してそれを Prolog で実装するという例も挙げている通り、エリック・エヴァンスはいろいろなモデリングパラダイムが存在することに対しては寛容のように見えるが、実際問題としてオブジェクトパラダイムがもっとも世の中で普及している以上、それを選択することを第一に考えたほうがよい、みたいな主張のように読める。*3

オブジェクトモデルが一体どういう記号化で、どういう演算を手に入れる手段なのかっていうのを書こうと思ったけど、疲れたのでまた別の機会に書く。とりあえず以前のツイートだけ置いていくのでこれでご容赦。

まとめ

  • クラス設計がモデリングではない(関連はしている
  • テーブル設計もモデリングではない(関連はしている
  • エリック・エヴァンスはモデルがそのまま実装可能であるべきだと言っててそれはよい考え方だと思うけど、概念モデルや分析モデルも忘れないようにね

*1:実際、子どもの頃、他のガンダムの武器をもたせたりしてた。

*2:そもそもこの分類が妥当かって話もあるんだけど、エンジニアだと実装可能なものに着目しがちで、概念モデルや分析モデルを軽視しそうな人が観測範囲に一定数いるのであえてこう分類した。

*3:オブジェクトっぽくないものもデザインパターンを適用すればオブジェクトで表現できるよ、仕様とかね。って言ってる。