DOAとXEAD　Driverに関する私的な想い

データ指向設計（DOA)でテーブルと機能の仕様書を作成するだけで、プログラミングせずに業務システムが動くというツールがＸＥＡＤ　Ｄｒｉｖｅｒです。

夢のようなツールだと感じられるでしょうが、実は渡辺氏の最初の出版作である「業務別データベース設計のためのデータモデリング入門」の中にこの考えは書かれていました。この本は2001年に出版されたものですから、、氏は１０年以上前からプログラミングは不要だと言い続け、ようやく実現するためのツールを自作され発表されたのです。設計ツールであるＸＥＡＤ　 ＭｏｄｅｌｅｒですらこのＤｒｉｖｅｒへのステップに過ぎなかったのかも知れません。

ＤＯＡの設計だけで何故動くのでしょうか？ＤＯＡという言葉の中には実は画面／帳票の設計も含まれているからです。この辺りはご存じのない方が多いと思いますので、少し長くなりますがＤＯＡの起源から説明したいと思います。

１．ＰＬＡＮ－ＤＢ

一口にDOAと言っても実は多くの手法があります。元祖DOAと呼べるのは椿正明氏が作られた「THモデル」です。ＴＨモデルで多くの企業を幸せにするため、データ総研（株）を創設されました。
このモデルの特徴は、リソース系（ＭＤＭ-Master Data Management）とイベント系（各アプリ）を分離し、会社全体をモデル化する事です。販売管理と生産管理で同じ商品マスタを２つ持つという事態を避けることが出来ます。またＫＥＹ、参照ＫＥＹ、加工データなど属性をもれなく書いて、処理をデータモデル上でトレース出来るようにします。レイアウトルールも細かく決まってますので、誰が書いてもほぼ同じものが出来るようになります。



実際にはデータモデルだけでは完全な設計とは言えないため、業務の流れを表す「ＩＰＦ」と加工データの導出ルールを描く「ＳＰＦ」を含めて「PLAN-DB」と呼ばれています。
※図は、http://www6.airnet.ne.jp/scmbm/seika2008/20080927-tsubaki.pdfからコピーしました


PLAN-DB　＝　THモデル（データモデル）
                    ＋　ＩＰＦ（Information Process Flow)チャート
                    ＋　ＳＰＦ（Schema Process Flow）チャート

２．米国の状況

そもそもＲＤＢを発明したコッド氏がその理論として「正規形」を定義したのが発祥です。主キーと従属項目との間の関数従属性を厳格に保つことで
①冗長データをなくし　　②更新異常を防ごう
という趣旨です。この考えに従って形式的に整理する手法を「構文論モデル」と呼びます。

その後ピーターチェン氏が項目間でなくテーブル間の関係を表すＥＲＤ（エンティティ・リレーションシップ・ダイヤグラム）を発案しました。業務としての意味を図示しようとする手法ですので「意味論モデル」と呼びます。現実との間に指示関係がある事を前提としたからです。この構文論と意味論のバランスをどう取るかで各種手法が生まれているようですが、哲学的な話になるので私はついていけてません。

チェン氏がＥＲＤを発表した同じ学会で椿氏はＴＨモデルを発表されました。奇しくも日米で同時発生的に生まれた２つの手法です。この辺りの経緯は、椿氏ご自身が整理されていますのでお読みください。椿氏が書かれている「一元論」と「二元論」の話は語り出すと深い話になります。私自身は、米国流と日本流のDOAの本質的な違いではないかと考えています。

チェン氏の記法は、日本では（恐らく）情報処理試験くらいしか使いません(笑)

米国のNIST（国立標準技術研究所）が定めたＩＤＥＦ１Ｘか、


ジェ－ムズマーチン氏が発案したＩＥ（information engineering）表記法


が使われます。両者とも線の上に関連（リレーションシップ）を文字で表しているのが特徴です。

※余談ですが、「リレーション」も「リレーションシップ」も関係と訳す事が出来ます。それでは混乱しますので、ｙ＝ｆ（ｘ）というような厳格な関数を「リレーション」、リレーションとリレーションの関係を「リレーションシップ」と呼び、「関連」と訳すようです。フレンドとフレンドの関連をフレンドシップと言うのと同じ使い方です。
※コッド氏は主キーから関数的に導き出される項目の集合をテーブルと定義しました。リレーショナルテーブルです。そのテーブルとテーブルの間のゆるい関係がリレーションシップです。

日本の技術者もIDEF1XかIEが主流です。ただ、関連の名称までは書かない事が多いです。これは気づかず一元論で整理しているためでしょう。コッド正規形とＥＲＤが同じものだと考えてる方もいます。また、ＩＤＥＦ１ＸもＩＥも、ＰＬＡＮ－ＤＢのデータモデル（ＴＨモデル）の部分だけだという事に注意して下さい。IPFやSPFに当たる表記は各自バラバラですし、それらが必要だという事に気付いていないＳＥも多いです。

※そもそも何のモデルも書かず画面帳票だけで設計するＳＥが多い事に危機感を覚えます。

３．Ｔ字形ＥＲ

日本にＲＤＢが入ってきた当初、相当大きな混乱が生じました。レスポンスが出ないのです。そのトラブルシューティングのため当時アシスト社から米国ＡＤＲ社に派遣されていた佐藤正美氏が駆り出されコンタルティングを行い劇的な改善をされました。その障害対応のコンサルティングで毎回同じことをやっている事に気付き、手順化して「Ｔ字形ＥＲ」を編み出されたそうです。


この手法は、元々すでに動いているデータベースをチューニングする手法から来ているためか、業務を分析するというトップダウンの手順ではありません。すでにある（または作りたい）画面／帳票を元に整理する手法です。つまりＴ字形ＥＲ手法を使う前に画面／帳票が存在することが前提になっています。

すでにある画面／帳票を要素ごとに分解し、データモデルの図として、業務の流れに従って左から右に記述します。そのため、Ｔ字形ＥＲはデータモデルを読むことで業務フローの代わりになる（と理解しています）。正しく分析し記述された図を読むと、その会社の実態が赤裸々に見えてしまうそうです。たとえば、リソースが少なくてイベントが多い会社はビジネス的発展性が望めないとか、顧客第一主義と言いながら顧客の属性が少ない会社は顧客に対して（会社として）興味を持っていないため組織として危険だとかです。この辺りは「データベース設計論 T字形ER」などを読まれて、この手法が現実の業務をいかに厳格に設計するかを理解して頂かないとピンとこないでしょう。

手順は単純なのですが、理論ベースにヴィトゲンシュタインさんやらカルナップさんなど哲学者がおいでになると混乱します。この手法は、私の知ってる限り唯一「その設計自体が正しいか」を検証する手順を持っています。主キーすら定義しないという手法ですから採用するには勇気が必要ですが、大手自動車会社など大規模システムで採用され効果を上げているそうです。

４．三要素分析法

渡辺氏の「三要素分析法」のデータモデルは、直接的にはＩＥ表記法を洗練させたものです。線の書き方はほぼ同じですが、属性項目を縦でなく横に羅列することで、項目の実際の値を書けるようにしたことが工夫です。


三要素の２つ目は、業務モデル（業務定義）です。アクションツリー形式で「仕事の進め方を定義したもの」で、個々の業務モデルが業務マニュアルの１単位となります。渡辺氏の本の中で、設計が終わった段階で業務マニュアルを書けるべきと書かれているのは、この業務モデルを必須要素とされているためです。



ここではいくつかの業務定義の連携様式を示す図面を紹介します。渡辺氏はＤＦＤと呼ぶこともありますが、悪名高い（？）ＤＦＤと混同される事を恐れてここでは業務フローと呼びます。この業務フローの工夫は「発生タイミングを記述できる」事です。実際の業務はイベントドリブンで発生します。それを設計段階でお客様とレビュー出来るため思い違いを避ける事が出来ます。また、四角と丸だけの無機質なアイコンでなく具体的なイメージを使うため専門家でないお客様にもわかりやすく工夫されています。


三要素の最後が「機能モデル」です。これは何と、画面／帳票（パネル）そのものを設計してしまいます。実際には外部インターフェースなども機能モデルになりますが大部分はパネルです。一つずつの項目がデータモデルのどの項目をどう計算して表示するのかまで定義します。

しかも、データモデルのテーブルとテーブルの関連に依って、パネルのパターンはほぼ決まっていると主張されます。パネルは単機能とすべきであり、新規登録／修正／削除は別々のパネルにすることを推奨されています。この辺りは「業務システムモデリング練習帳」を読むまで私自身も重視していなかった部分ですが実は三要素分析法から動的制御システムへの橋渡しのカギはここにあったのだと考えています。

この三要素は、どれが先という事でなく繰り返しレビューしながら同時にトップダウンで設計します。この手法で設計が終われば、画面も帳票も、計算ロジックまで設計が終わっている事になります。

５．そして動的制御へ

一番の違いは、三要素分析法は設計のアウトプットとしてパネルを定義している事です。メモがあるとか人によって作るとかでなく必須要素とされています。そしてそのパネルは、データモデルの関連から自ずと数パターンに収斂させ得るし、それぞれのパターンにもとづいてまとめられた仕様書を用意すれば、その内容にもとづいてパネルを動的に立ち上げることが可能だと主張されています。「コードの自動生成」ではなく「仕様書にもとづく動的制御」なのです。

※収斂されうるのか、収斂しない時は自動実行をあきらめるのかは今後の検証が必要でしょう。
ＣＯＮＣＥＰＴＷＡＲＥというフリーの業務設計結果を公開されていますので、その業務群が問題なく動くようにする事が検証になるでしょう。

この事を１０年以上前から主張されていた事は慧眼としか思えません。そしてその主張を実現できるツールを一人で作られようやく完成し日の目を見ようとしています。まだβ版ですが、日本発のフリーツールとして世界で使われ、無駄なＩＴ投資が抑制されることを願っています。

－－－－－－－－－－－－－－－－
長文におつきあい頂きありがとうございました。もし渡辺氏の本をまだ読まれた事がなければ、「上流工程入門」をお勧めします。

正式リリースの最初のお披露目は、この関西ＩＴ勉強宴会でやって欲しいなぁと期待しています。その節は是非多数のお越しをお待ちしておりますm(__)m