モデルとは何か

実に楽しかったです。会議室をお貸し頂いたテラスカイの皆さま、特にセッティングと後片付けをお手伝い頂いた方々に感謝致します。

初めての東京開催でした。集客を心配していましたが、何と募集2日でほぼ満席。10名ほどの補欠登録までして頂きました。椅子を増やして頂き全員にお越し頂きました。佐藤正美さんはマスコミにほとんど出られませんので知らない技術者も多いかも知れませんが、今でも熱狂的なファンが多くおられます。

ネットで偶然佐藤さんの名前を見つけて来て下さった方もいらっしゃいました。大阪等からも常連者が10名近く来て頂いていました本当にありがとうございました。2次会はなんだか秘密基地のような所で座る場所がないほどの人数でワイワイやりました。3次会は１：３０ごろまで飲んでました。最後まで付き合ってくれたのは大阪（および岐阜・名古屋）から来てくれたいつもの常連さんでした(笑)

＜今回の勉強宴会資料＞
１．株式会社テラスカイ　今岡純二さんの資料
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-06-26_imaoka.pdf

２．株式会社ＳＤＩ　佐藤正美さんの資料
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-06-26_sato.pdf

＜Salesforceにおけるモデルドリブン開発＞

株式会社テラスカイ　今岡純二さん

１．セールスフォースについて

　当社テラスカイは100名ほどの会社規模で、セールスフォースをはじめとするクラウドを専業として導入・開発を行っています。セールスフォースは生産性５倍と言われます。各種調査会社の結果でもほぼ5倍の生産性が出ていますのでこの数字は客観的なものではあります。ただし、標準的な画面や機能を使えば抜群の生産性が出ますが、リッチな画面などプログラム開発してしまうと一般の言語とそれ程生産性は変わりません。

２．メタモデルについて

セールスフォースはマルチテナントのクラウドシステムです。内部のメタ構造は単純化されています。まず＜メタデータテーブル＞として、利用者が定義したオブジェクト（＝テーブル）と項目名が格納されています。＜データテーブル＞として全ユーザのデータが一つのところに格納されます。処理を高速化するためのインデックスなど＜ピポットテーブル＞もあります。この単純化された構造の中で、あらゆる組織（ユーザ企業＝テナント）の異なるデータを扱いつつ一定のパフォーマンスを確保しています。




　ところが、ひとりの開発者の視点から見ると単なるＲＤＢに見えます。ただしPrimaryKeyはセールスフォースが勝手に付番します（オブジェクトキーに近い）

３．データモデルについて

セールスフォースで開発する時にはデータモデリングが大変重要です。それは主に３つの意味があると思っています。まずオブジェクト関連（ER）によってユーザインターフェースが決まってきます。次に良くないモデリングでは生産性が悪くなります。また保守性も悪くなります。
　デモを見てもらいます。
（１）注文ヘッダオブジェクトを新規に作成する手順
（２）テキストエディタのメタモデルで注文明細を作りデプロイする手順
（３）SkyVisualEditorを用いて注文のヘッダ＋複数明細を一画面に出す手順
　※これはセールスフォース標準で行う時にはプログラムが必要です


TerraSky Tech Blog
http://blog.terrasky.co.jp/blog/
もご覧ください。

＜モデルとは何か（論理的意味論として）＞

株式会社ＳＤＩ　佐藤正美さん

１．モデルを考えだしたきっかけ

私は80年初頭、日本にRDBを持ち込んだ技術者の一人です。東京で大きなプロジェクトを行っている時に、社長のビル・トッテンに「大阪でトラブっているから行ってくれ」と言われて3日間の予定で行きました。何もわからず行ったのでお客様に状況を教えてほしいと言うと「CPUを80%削減してくれ」と言われました。無茶な話ですが、設計を見ると問題点がわかりましたので2日で60%削減まで出来ました。お客さまも喜んで接待してくれました。
　飲みながらお客様に言われたのは、従来のファイルと内部構造が違うのなら運転の仕方が違うのだろう。それは理解できるが、内部構造を知ってまで使いたくない。それに向いた設計の仕方があるはずだ。

　それからRDBに向いたモデルの方法を考えました。それまで数学などやったことがなかったのですが、40歳代は数学の勉強に費やしました。私のモデルは数学の技術を使っているだけです。数学と言っても、数学基礎論（現代集合論）という分野です。特にゲーデル、チューリング、フォン・ノイマンが重要です。ゲーデルの完全性定理は簡単ですが不完全性定理が基礎になっています。

　数学的基礎論は大きく４つの分野で出来ています。
（１）集合論　　（２）関数論　（３）モデル論　（４）証明論
「モデルとは何か？」を語って欲しいというお題をもらいましたが、私の方法は単に数学の技術を使っているだけですから改めてモデルとは何かを定義出来ません。ちなみに昔はＴ字形ＥＲと呼んでいましたが、今はＴＭと呼んでいます。数学の世界ではＴＭはチューリングマシーンの省略形ですが、Theory of Modelsの略として命名しました。

２．モデルについて

それでもあえてモデルとは何かを考えると、【理論式】の事になるのかと思います。集合Xのすべての元が集合Yの１つの元に対応しているとき、この対応を写像または関数と呼びます。ｙ＝ｆ（ｘ）を理論式と呼びます。これに対して、理論によらないで実験したデータに合うように作った関係式を実験式と呼びます。

　さて、モデルの構成です。TMは論理的意味論という手法を使っています。まず事業過程から事業がどう営まれているか（現実事態）を見ます。事業過程は人から人に情報を申し送りすれば成り立ちます。その申し送りしている情報をいかに正確に持ってくるか。これが大変重要です。
　FormalなものもInformalなものもあります。同じ会社なら文脈で解釈出来る事も、文脈がわからない我々には最初から正確な意味がわかるわけありません。そのためざくっとエンティティを取ります。
　※エンティティという言葉は正確じゃないので変えたいのですが反対されています

（１）集める
　主題（何について言っているか）と条件（その属性）を集めます。主題は番号やコードがあるものです。「区分コード」は主題でなく条件とします。
（２）並べる
　構造をとり、正確な意味を取ります。　並べると足らない物がわかるので再度「集める」に戻るという行ったり来たりしてＬ－真（論理的に正しい）を作ります。
　この時にはand/or/notしか使いません。「どんな天才でも論理規則を破る事は出来ない」と言う通り100%これとこれは関係あり、100%関係ないと証明できまでやります。【関係の網羅性】＝文脈から再度集合を作り関連を見ます。
　同じ現実からＬ－真は何通りでも書けます。例えば１→３という関連を見出した時、１＋１＋１でも１×３でもＬ－真です。それが文脈的にどちらが正しいかを次に確認します。
（３）現実との一致（値の充足）
　実際に値を入れてみて、現実と一致するかを見ます。これをＦ－真（事実的に正しい）と呼びます。Ｆ－真は一つしかありません。【制約束縛の網羅性】（これはロジックではチェック出来ません）

　

　論理的意味論では、構文論が先で意味論が後です。

３．タルスキの真理原則

文「ｐ」が真であるのは、事態ｐと一致したとき、そしてその時に限る。という原則は当たり前のようですが、大変重要な原則です。
※（佐野注）この頁の[補遺]を見るとこの文の深さが少し理解出来ると思います
http://www.sdi-net.co.jp/sdi_328.htm

４．関係Ｒと関数ｆ

関係　R(a,b)：aはbに対して関係Rである
　　→対称性　　(a,b) ＝ (b,a)　　（aはbの恋人である）
　　　非対称性　(a,b) ≠ (b,a)　　（aはbの父親である）
　関数　f(a,b,c）
　　→全順序　大小関係などで並べる事が出来る
　　　半順序　なんらかの（辞書的配列など）並べ方がある。値の大小関係ではない。

　集合を作った時の全順序と半順序をどう判断するかで一年悩みました。事業過程は（情報の伝達で成り立つため）イベント主体です。そのため日付が帰属するものをイベント（全順序）とみなし、それ以外をリソース（半順序）としました。
※リソースと言う言葉を変えたいと思っています。案を募集中です。

　モデルを読む時は箱でなく一歩下がって線を読みます。論理で作れば読めます。技術者が自分の想いで勝手に書かれると読む事は出来ません。

５．簡単な例でモデルを作る手順
　（詳細は省略しますが、資料を見て下さい）
　・セットで作ってクラスで整える。
　・多値関数（クラスを入れる）・・・ファンクタ（関数の関数）を使う
　・区分コードは右（条件）に置く
　・得意先かつ仕入先はセットでない
　・任意入力は現実にはあるが、形式的構造に持ち込まないこと
　　何故ならnullの4値論理(Yes/No/unknow/undefine)を意識することになるから
　・Ｌ－真がＦ－真なのかはお客様に考えてもらう。
　　例えばこの３つの例を書いてどれが正しいのかを示してもらいＦ－真を取る
　
　

＜所感＞

発表していただいたお二人とも時間ぴったりで流石に手慣れておられました。今岡さんのデモはプログラムに詳しい人には驚きの内容だったようです。テーブル構造をテキストエディターからapiを用いでセールスフォースに登録出来たり、テラスカイさんのツールで作ったプログラムソースをapiで登録してコンパイルしたりが目の前で実行される内容でした。

佐藤さんのモデル論というかＴＭの基礎になっている理論は、今世間で流行っているドメイン駆動設計とはかけ離れて数学的な構造でした。若い方々にも参考になったと思います。

実は準備段階でＴＭ大好きな方から個人的にメールを頂いていました。
＜佐藤さんの仕事の仕方は、コンサル先のＳＥを指導し、彼らが「普通に仕上げる」ので
あまり成果が喧伝されないし、「彼らが普通にこなす」ので保守の仕事も基本無いという損なやり方です。＞

興味があれば、早稲田大学のオープンカレッジやセミナーなどに行ってみて下さい。

以上