» 【第45号】ビジネスシステム工学

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第45号】ビジネスシステム工学

DRI通信45号「ビジネスシステム工学」 2000.6.1
新緑とつつじの5月もあっという間に過ぎて、雲はどんよりと垂れ込めたり、
かっと太陽が照りつけたり、梅雨近しを思わせます。皆様お元気ですか。
データ総研も今年の10月で15周年を迎えます。「出し物は」と言われ、本
(仮題「情報システム成功のシナリオ」、マネージメント向け)を出版したいと考
え、連休中は原稿書きに終始しました。26日のビジネスモデルノウハウ
セミナー、11、18日のXMLセミナー、7月セミナーのレジメ2件、さら
に3件の特注顧客企業内講演、それとこのDRI通信というわけで、業績は少
しも良くないのに、日程的にはなかなか厳しい5月でした。
先の「3種類の通信モデル」については、やはり戸田忠良氏から、示唆に富む
コメントを頂きました。その一部を紹介します。
<コメント氏名=’戸田忠良’>
情報場の一部であるDB通信場は、実はそう易々と組織全体で統一などで
きないし、多義性を保証しないと機能しないと考えています。偏見には適切な
有効スコープがあり、全社統合などと幅広くとらえ過ぎると、あるone factの
解釈にも場所により多義性が生じるということです。そして、それはそれぞれ
の役割の違いが引き起こすもので、違いの所以をきちんと突き詰めることは必
要ですが、いたずらに統一することを目指すべきではないだろうと思います。
その意味で、オブジェクト指向は、それぞれのオブジェクトを正当と理解する
暗黙の有効スコープを持っているのではないでしょうか。つまり、あるクラス・
ライブラリーの利用者に同じ情報場の共有がないと普及は難しいということです。
人類の進歩とは、自分の経験を軸に偏見を生み続けることにより引き起こされ
ると考えます。その意味で、人類は意味や意思をどうのように伝えているのか
という通信の本質の議論はとても重要と考えます。それに対する小生の仮説が、
「情報場を介して行う」というものです。</コメント>


さて今月は「ビジネスシステム工学」という題にしました。私は概念にこだ
わったDOAを主張していますが、これは「ビジネスシステムモデリング」
といった表現がふさわしいと思ったからです。1965年頃、千代田化工に
おいて、われわれは化学プラントの基本設計にコンピュータを応用すべく、
モデリングのベースとなる「化学プロセスシステム工学」を模索しておりま
した。それとあまり変わらないことを、今は化学プラントならぬ企業ビジネ
スに適用しているに過ぎないと感じたからです。
いずれも、物質かデータかの違いはありますが、次のようにその処理/変換
(P)と成果物/状態(D)からなるシステムです。 処理/変換(P)
成果物/状態(D) 化学プラント: 蒸留、反応などの単位操作ストリーム
の成分別流量 企業ビジネス: 受注、生産指図などの業務データ項目ごとの
値成果物を生まない処理は意味がありませんから、1個の成果物には1個の処
理が対応するものとします(話しを簡単にするために、蒸留のように1個の
処理がn個の成果物を生むものは今除外します)。逆に1個の処理にはn個
の素材(他の成果物)が使われ、また1個の成果物はn個の処理に使われる
とします。
これを図示します。図aは処理/変換を重視したもの、図bは成果物/状態
を重視したものです。重視とはこれをノード(箱)で書くことを意味するも
のとします。 図a 図b P1(d1)―――→P3(d3)
(p1)D1―――→(p3)D3 ↑ ↑ P2(d2)――――┘
(p2)D2――――┘
文字だけで書こうとしているのでやや読みにくいですが、図aでは線の上を
データが流れるように、また図bでは線は処理を表すように見えます。
多くの場合、常識的な人間の直感に素直な図aが使われますが、これはプロ
セス中心の図になります。図bは、「成果物、状態、インターフェースを押
さえれば処理は従属的に決まる」とする、一回ひねったデータ中心の図といえ
ます。
化学プロセスの場合、われわれはまずストリームを決定するための「リニア
モデル」法において、図bの表現を用いました。今、ビジネスシステムに
われわれの用いている概念DB構造図やIPFチャートは、図bのものです。
多くの企業で用いているシステム関連図やDFDは図aの形式かと思われます。
日頃図aを用いているか、図bを用いているかによって、その人/会社の文
化が、POA的か、DOA的か判断できるかもしれません。
わたしは情報システム設計の原理として、レイヤードアプローチ、すなわち
データ先行・概念先行・リソース先行を主張していますが、化学プロセスシ
ステム設計の場合との対比は次ぎのようになるかと考えます。
情報システム:データ先行、 概念先行、 リソース先行
化学プロセス:ストリーム先行、平衡論先行、物性計算独立
ストリーム先行とは、蒸留装置や反応器などの機器の詳細を考えるより、先ず
その入り口・出口の成分組成を確定させようと言うことです。化学プロセス
シミュレータはこれを行います。平衡論先行とは、蒸留塔ですと、
実段数=理論段数*段効率
として、先ず平衡論により理論段数を計算し、装置の性能は後で段効率=
60%などとTakeして決めるやりかたです。私が終始概念モデルと物理
モデルを分離してアプローチしてきたのは、この化学工学の常識をそのまま
持込んだためかとも思います。物性計算独立とリソース先行は、対比にやや
無理があるかもしれませんが、いずれも共通ルールを個別アプリから切り離
し独立資源として管理しようというものです。
データ先行、概念先行など、すべてを一挙にでなく、観点を分けて順次解決
しようというアプローチも、化学プロセスシステム工学研究において、ダイ
ナミックプログラミング(DP)として学んだものでした。また「システム
設計におけるコミュニケーションには、図と表を活用するエンジニアリング
アプローチが基本」とプラント設計から学びました。プラント設計から学べ
なかったのは、データベースをハブとする思想だけだったのかもしれません。
データベースのコンセプトは、私はFORTRANのCOMMONから学び
ました。
先日ある顧客から「椿さんは昔から同じ事しか言ってない」と言われました。
「実装独立の世界は、人とIOの世界、昔は紙、これが画面・帳票・電文に変
わっても本質は変わりませんから」と答えましたが、もう一つ、化学プロセ
スシステムでの経験をお手本にしているため、遅遅とはしていますが、善し
悪しはともかく、変節の必要性がなかったからと思います。実装がからむと
ファッションのように「今度はこれ」となるのでしょうが、概念のデータの
整合性を問題にするDOAは永遠に陳腐化しないと、私は考えます。
今回は、是非化学工学出身者、化学石油プラント設計経験者などからコメン
トを頂きたいものです。