» 【160号】「PLAN―DBの出自」

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【160号】「PLAN―DBの出自」

■DOA40年
2000年に社長を、2006年に会長をやめ、フェローの肩書きで勤めていまし
たが、この2月でDB研と中断中のK2Wを締めくくって、社員も辞めることにい
たしました。そこで、DOA40年にわたるPLAN-DBの出自と今後の展望を
つづってみることにしました。

■千代田化工での化工設計
私は1959年工学部化学工学を卒業して、化学プラントの最上流の設計「化工設
計」に携わりたいと、千代田化工建設に入社しました。石油化学はなやかなりし頃
で、反応・分離・加熱・冷却などの単位操作(処理工程)を組合わせて、所定の物
質を作るプロセスを設計する仕事です。設計結果はプロセスフローシートと呼ばれ
る図面に表現されます。図面の書き方は、ほぼ標準化されていて、設計者によって
若干の違いはあるものの、読む人にとって気になるほどのものではありません。図
面言語としては完成度の高いものが確立していたと言えるでしょう。

設計の中心は、顧客の要求する製品を作り出すための物質・熱収支計算です。これ
は機器と機器のインターフェース「ストリーム」の整合性を保証するものとなって
います。これを実現するための機器の形状・寸法・材質・強度などの設計は、物質
・熱収支計算の後で行います。すなわち実装独立の整合性を保障し、その結果をも
とに実装設計を行う手順となっています。

入社当時はまだコンピュータはなく、気液平衡の試行錯誤計算も、計算尺や手回し
の計算機を使ってやっていました。入社5年後くらいにIBM360が導入され、
技術計算はFORTRANで、事務計算はCOBOLで機械計算ができるようにな
り、手計算は機械計算に移行していきました。

化工計算では機器に出入りするストリームは、エタン、プロパンなどの各分子のモ
ル流量を表すベクトル(アレイ)で表現されますので、これを処理する機器の働き
は変換マトリクスで表現することができます。このベクトルとマトリクスによる、
リニアモデルと呼ばれる表現が、所期の製品を作るための最も単純化されたプロセ
スの表現となります。私はこれをベースにプロセスシミュレータを作るべく、かな
り早い段階に化工エンジニアから足を洗うことになりました。と同時にこのいわば
GOA(Goal Oriented Approach)は、「整合性のとれた実装独立設計先行」とと
もに、私の体にしみ付いて、以後の活動に影響を与えて行ったように思われます。
実装独立すなわち「概念」と「論理」の区別の曖昧なシステム屋を見かけますが、
この真の理解にはユーザ部門での原体験が必要なのかもしれません。

当時はまだ、インプットはカードパンチ、アウトプットは紙です。事務計算のアウ
トプットは、早めに順次ファイルに移行していきましたが、プログラマーの関心事
は処理をいかに機械化するかでした。千代田化工の仕事は、最上流の化工計算から、
反応器・蒸留塔・熱交換器・ポンプなどの機器や配管の形状・寸法・材質決定・強
度設計、これら機器・配管の調達、工事計画、工事管理と続きます。この各作業で
コンピュータが使われるわけですが、このままいくと「人間はコンピュータのアウ
トプットを見て次のインプットを作る係りになるな」と思いました。

■Information Algebraをベースに
そこで早晩、各作業を連携するために各アプリケーションがどのようなデータを受
け渡ししているかを解明しなければならないと考えました。データをどう表現すべ
きかを考えているときに遭遇したのが、CODASYLのInformation Algebraという文献
でした。そこでは、V=A(E)すなわち
 Value=Attribute ( Entity )
が紹介されていました。「われわれの眼にする値は、あるエンティティの属性であ
る」とのこと。したがって縦軸にエンティティ(インスタンス)を、横軸に属性を
並べ、その交点に値を書きこれを適宜並べ替えると、エンティティタイプおよび共
通の属性が見えてくるはずです。これを基にTH(椿・穂鷹)モデルの原型を作り、
種々の下流工程の帳票を分析して行きました。1970年頃、40年前のことです。
「これによって、上流から下流に至る各アプリケーションを連携できると」いう確
信を得ることができました。そこで個別業務の機械化と同時に、これらを統合する
CHEIS(CHiyoda Engineering Information System)の開発が必要であると、
その構想を提案しました。

■ミドルウエアDPLSの開発
当時はまだデータベースという言葉はありませんでした。化工関係のアメリカの学
会で、プロジェクトファイルというアイデアが発表されました。プロジェクトの上
流から下流をコンピュータ上で繋ごうという、似たアイデアです。CHEIS実現
のためには、「OSの機能だけでは難しい、ミドルウエアが必要である」と考えま
した。IBMにPLANというソフトがあることが分かりました。必要なサブプロ
グムを事前にリンクしておかなくても、実行時にリンクするダイナミックリンクの
機能があります。今のStored ProcedureないしWeb Servicesに近い機能です。顧客
ごとに異なった機器構成からなるプロセスを扱うには非常に好都合です。またコマ
ンド言語があり、これによりユーザは処理とそのためのパラメータを、アプリによ
らず統一的な形式で定義できます。まだGUIはなく、CUI(Command User
Interface)の時代ですが、今のXMLに似た形式の言語です。当時プログラマーが
思い思いのユーザインターフェースを設計し、ユーザはその対応にまごついていた
わけですが、これが解消できます。そこでこのPLANにDBMS機能を付加し、
DPLS(Database Programbase Languagebase Support)というミドルウエアを開
発することになりました。

DBMS機能はISM(Information Structure Model)、DSM(Data
Structure Model)、SSM(Storage Structure Model)の3階層からなる、今で
言う概念、論理、物理を分離したモデルでした。また今でいうリソースDB、また
プロジェクトごとに用意すべき複数個のイベントDBなどn個のDBから成る環境
を管理するために、DD/D-今で言うリポジトリ-を内蔵するものとしました。
当時SIerの部長だった穂鷹さんと共同で、THデータモデルをほぼ完成させま
したが、彼は「DPLSは自己記述型の先進的DBMS」と評し、大手メーカーへ
の説明会をアレンジしてくれました。私は1975年ボストンの第1回VLDB
(Very Large Data Base)学会で発表しましたが、それはP. P. ChenのERモデル
と同時でした。

社内で、説明のためデモシステムを作りましたが、高い生産性を確認することがで
きました。私は35年後の今でも非常によくできたエンジニアリングDBMSだっ
たと思います。うまく活用できれば、最も難しいエンジニアリング企業のミドルウ
エアとして大きな貢献ができたのではないかと残念に思います。しかし、会社はD
PLSでなく、当時ようやく登場したIMSを使うと決めました。「DPLSを使
うには広汎なデータの洗い出しと整理が必要だ。IMSならその必要がない」と言
われました。技術でなく、人間との戦いは人生の浪費になると思って千代田化工を
辞めることにしました。

■方法論PRIDEとの出会い
そこで入ったのが、日本システミックスというシステムコンサルティングの会社で
す。アメリカのMBA社からシステム開発方法論PRIDEを輸入販売していました。
「情報システムはInformation Resource から構成すべき、だからInformation
Resourceの管理が鍵だ」という、組立加工製造業的な方法論です。その思想に問題
は無いのですが、データモデルの面で不十分な点があったので、THデータモデル
でこれを補うこととしました。

「PRIDE+THデータモデル」による先進企業に対するコンサルは、非常に高
い成功率だったと思います。THモデルに加えて、これを補強する業務フローを記
述するIPF(Information Process Flow)チャート、SPF(Schema Process
Flow)チャートも実プロジェクトに適用し有効であることを確認することができま
した。PRIDE技法では、「サブシステム」という処理粒度の基準、またIOか
らDBを決めるべきとする考え方が参考になりました。

なお、同社に在籍したとき、n個のDBから成る環境を前提としたミドルウエアD
BCMS(DB Complex Management System)に関する調査レポートを作り、IPA
に納入しました。私の今の3階層DHアーキテクチャはこの延長上にあると言えま
す。

■PLAN-DBコンサルテーション
しかし1985年、「THデータモデルによるDOAは、PRIDEユーザ以外に
も普及すべき」との思いからDRIを創立することにいたしました。当時はシステ
ム部門主導で、メインフレーム上に基幹系システムのRDB構築を行っていた時代、
THモデルを中核にした、弊社の方法論PLAN-DBは好評でした。「リソース
DBは全社に1個、個別アプリと切り離すべき」という主張はほとんどの顧客で受
け入れられ、1980年代に今で言うMDM(Master Data Management)が実現で
き、その企業では後の混乱を避けることができました。それから20年以上経過す
るわけですが、「保守や開発の合理化は1%台ではなく10%以上と考えられるの
で、顧客には大変なROI-大きいところでは5千万円が100億円になる-を提
供できたはず」とは、私の皮算用です。

1990年代に入ると、C/Sによるダウンサイズが流行し、システム部門による
統制が効かなくなりMDMが劣化していきました。バブルがはじけ、パッケージ導
入が多くなり、Y2Kに忙殺され、システム部門のビジネス理解力がダウンしてい
きました。

私は
「情報システム=ビジネスシステム+ソフトウエアシステム」
だと考えますが、「情報システム=ソフトウエアシステム」との誤解があるので
しょうか、パッケージやSIerに丸投げする企業も少なくありません。ユーザ企
業の情報システム部門は、ビジネスシステムを全社横断で可視化し経営をサポート
する役割があるはずです。可視化には分かりやすい正しい図面言語が必須のはずで
す。

これまで統制不十分のままシステム化を進めてきたため、「アプリが1000個以
上ある、データ項目は40000以上ある、パッケージも入れた、さらにグローバ
ル化、M&Aが進められる、これに迅速に対応すべし」など誰の手にも負えないよ
うな状況になりつつある企業も少なくないと思われます。これらの整理は機械では
できません。人手になりますので如何に巧妙に進めるかが問われます。進め方その
ものを試行錯誤により決めていかなければなりません。

私は初めが肝心、分かりやすい主なアプリを選択し、このアプリ間のデータ(先の
DRI通信159号の3階層DHアーキテクチャにおけるE2データ)を手掛かり
にE2(アプリ間のイベントデータハブ)の構造の可視化から進めるのが得策と考
えています。したがって個別アプリ内のE1(アプリ内のイベントデータハブ)の
データは当面眼をつぶります。E2に登場するリソースは共用性の高い重要なデー
タですから、標準化不全ならばこれから手をつけなければなりません。この作業-
2,3ヶ月を想定しています-の中から、その企業に合った効率的な進め方、整理す
べきアプリなどが発見できると考えます。

■今後の課題
これまで40年かけて、DOAの方法論を追求し、コンサルティングを通じて人材
育成を図ってきたわけですが、1990年まではよいとして、その後はなかなか苦
戦だったように思われます。方法論もツールも進化していますので、「規模が拡大
し、体制がとりにくくなった顧客における環境変化」が主な原因かと思われます。
しかし策はあります。MDMは必須条件として、「スパゲッティフリーを実現する
3階層DHアーキテクチャとプログラミングレスを実現するリポジトリツール」が
鍵ではないかと考えています。

以上の記述にあたり、昔を省みたわけですが、実装独立先行、そこでの整合性保障,
GOA、マルチDBなど化工設計やプラントエンジニアリングから習得したものが
多いのに気づきました。その意味では私にとっての化工設計の10年弱は、その後
のDOA開発方法論開発のための準備期間だったのかもしれません。確かに情報シ
ステムと最もよく似たハードのシステムは化学プラントだと思います。都度一品物
を設計して建設します。図面をベースに成果物を共有しなければなりません。この
ため設計方法論も似てくるようです。ただ、ハードシステムは重力が働くため、図
において特に約束を設けなくても個人差は出ませんが、情報の場合は重力の規制が
ないため、各人思いのままに図を書きます。私はエンティティの粒度によって、粗
いものが上、細かいものが下と、配置規則を決めましたが、成功だったようです。
またリソース系は標準部品の定義ですから、これを「システム広辞苑だ」として、
成果物のイベント系データ構造図から分離するものとしました。

私は、Information Algebra以外、参考にしたい文献を発見できませんでした。
1971年頃、E. F. CoddのRDMの論文を読みましたが、意味論が抜けているし、
n個のDBを扱っていないのでツールはできても、企業モデルにはなりえないと考え
ました。また、P. P. ChenのERモデルは意味論的アプローチでしたが、属性よりも
エンティティタイプを優先するので、整合性-特に加工・加工元データの整合性-が
取りきれず、品質が上がりにくい、またサブジェクトエリアの概念ではn個のDBが
構成する全社モデルが裁ききれないと考えました。結局、コンサルで取り組んだ200
近いアプリケーション、特にその画面・帳票と格闘しながら、方法論を作っていきま
した。困ったときは「プラントの場合はどうしているか」を考えました。概念モデル
に限定してですが、3階層DHアーキテクチャによって、スパゲッティフリーが実現
できると考えたので、プログラミングレスを実現できる、私なりのメタデータの決定
版を確定し本にしよう、これを2010年の課題としたい、と考えています。
注文などありましたらお寄せいただきたいと思います。