» 【第80号】情報システムのサイエンス・工学

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

DRI通信80号「情報システムのサイエンス・工学」   2003.5.1
桜が咲いて1ヶ月経つと、緑、緑、緑のゴールデンウイークです。皆様お元気ですか。
システムを開発するときは、「10年先は分からない、とりあえず5年くらい先を考えて」と構想を立てるけれど、できてしまえば10年も15年も使い続ける。そうすると生き残っているシステムは皆賞味期限を過ぎたものばかりとなってしまう。このジレンマをどう解決すべきなのでしょう。
ところで5月20日(火)K2W勉強会を行います。テーマは「オブジェクト指向アーキテクチャとDOA」です。MSの萩原さんから「DOAと.NETのSOAの融合」また豆蔵の萩本さんから「J2EE、.NETアーキテクチャをベースとするオブジェクト指向開発」のプレゼンがあります。ご出席になりたい方は会員登録の上お申し込みください。
さて今月は「やはり勘と経験の世界」と言われてきた情報システムへの、サイエンスやエンジニアリングの適用はどうあるべきかについて考えてみました。
■ 情報システム
ここで「情報システムとは、企業などの業務アプリケーションシステムを指す」ことにします。ソフトウエアパッケージならばテレビや自動車の仲間かもしれませんが、オーダー品として建物やプラントの仲間として位置づけるべきものを考えます。実際その建設にかかわるSI業のデータ構造は、建設業/プラント建設業のデータ構造と酷似しています。
これら「ものづくり」にかかわる製造業・建設業では、電気工学、機械工学、建築工学、化学工学などの工学があり、図面の書き方が決まっていて、これをベースにユーザ要件/RFP(Request for Proposal)がつくられます。ところが情報システムの場合は、これに類する工学や図面の書き方が確立していません(情報工学という言葉はあっても内容が整っていないようです)。まだまだART、属人的な職人技から脱していません。今回はこれをテーマに考えてみたいと思います。


■ 工学
工学は理学に対応するもの、そして理学はサイエンス、工学はエンジニアリングの翻訳とのことです。サイエンスは真理、普遍的原理を追究するもの、工学はこれを踏まえて実利を追求するもの、したがって、「サイエンスは決まっているものの発見」、「工学は決めることによる発明」と対比できるようです。これを荒っぽいですが、
 工学=理学*実利
のように、書いておきましょう。ただし「ものづくり」は工学だけでは足りませんので
 「ものづくり」=理学*(実利+α)
としておきます。いずれにしても情報システムの世界に工学のアプローチを持ち込みたい、そのための理学/サイエンスや工学とは何かを、私は実は30年間考え続けてきました。
■ プラントエンジニアリングから
そのきっかけは、プラントエンジニアリングにおける成功体験だったのだろうと思います。1965年ころ、熱交換器・反応器・蒸留塔やこれらから成るプロセス全体の物質収支・熱収支計算にコンピュータが使われ始めました。化学工学に熱力学、特に物性論や(化学)プロセスシステム工学の成果が付加され発展していった時期ですが、コンピュータを使うために厳密な数式モデルが要求され、サイエンスの部分が経験/ノウハウの部分から明快に分離されて、大きな進歩があったと記憶します。このプラントエンジニアリングにおける化学プロセスへのアプローチを、今度は情報処理プロセスへ適用し、サイエンスに基づくエンジニアリングに進化させたいと、これを自分の課題とした次第です。
■ 情報システムの要素
化学プロセスでの製品は、たとえばLPGですとプロパン、ブタンを主体とするいろいろな要素(分子)からなる混合物です。情報システムの製品は、たとえば出荷指図書ですと、出荷指図#、届先#、届先名、住所、品番、品名、倉庫#、数量、出荷日、受注#などから成る要素(属性)の混合物です。プロパン、ブタンなどは神様の決めた天然のものですから、人/企業による差は発生しません。しかし情報システムの製品を構成する要素は、人/企業が決めた物ですから標準化の範囲によって種々のバリエーションが発生します。要素がまちまちでは、サイエンスは登場できません。
そこで要素(属性)を客観的に識別する基準からスタートしなければならないと考えました。1962年CODASYLという標準化団体から、Entity, Attribute, Valueをベースにした情報代数という論文が出されました。実装独立に実務の世界の情報を整理する基本的な枠組みです。プラントエンジニアリングの複雑なデータに当てはめてみると、うまく整理できそうです。そこで結果的にはこれを公理としてデータモデル論を展開していくことになりました。
■ データの分類学
Entityとして、社員、部署、顧客、品、プロジェクト、発注、受注、出荷、給与などのあることはすぐに分かります。Valueは数量、コード、テキストの3種に大分類できること、またAttributeにはEntityを定義するための(主)KEY、Entityを参照するためのRKEY(参照キー/外部キー)、さらにEntityの性質を表すための各種数量データやテキストデータがあることがわかります。
Entityは企業の経営資源を表すリソース(社員、部署、顧客、品、プロジェクトなどのコード類)、業務によって発生するイベント(発注、受注、出荷、給与など)、これによってつくられる在庫型や要約などいくつかの種類(ファイル類型)に分類できます。
また数量データには、直接入力されるデータのほかに、他のデータから計算される加工データ(導出データ)があり、この加工の仕方に、たとえば次のようないくつかのパターンがあることがわかります。
 S:要約(品別地域別月別売上数量など)
 I:在庫(品別倉庫別在庫数量など)
 T:断面(品別倉庫別月末在庫数量など)
 G:不定形(管理職給与金額など)
 X:チェック(在庫状態(きれ/きれそう/十分)など)
そしてS、I、Tなどは加工元データとの関係さえ分かれば、汎用ロジック1つを用意すれば計算できるが、G、Xはデータ項目対応の個別ロジックを用意しなればならないことがわかります。
このほかにもサブタイプ、粒度、役割など種々のデータ項目に関する性質が見えてきました。これらは情報代数のEntity, Attribute, Valueを公理とする限り、実際にわれわれが遭遇するデータ項目を仔細に観察することによって、個人差なく到達できる分類学的な普遍的原理のように思われます。素粒子論、物性論、動植物の分類などは天然物を対象にするため、誰しもサイエンスと認めるわけですが、情報やその素材としてのデータも実装手段独立に考える限り恣意的なものは含まれず、サイエンスとして扱うべきもの、と私は考えています。
■ 工学のための標準化
工学のためには、サイエンスの分離に加えて実利を提供しなければなりません。速い・安い・高品質のための最適化、これを多くの人が多様な対象に対して効率的に実現するための「型」の標準化が課題となります。最適化といっても数値による判定は困難ですから、「VHSかベータか」のような人気投票的多数決の介入する余地が残ります。
情報システムの場合は、図面化のための標準化とその電子化がポイントになるように思われます。建物やプラントなどのハードウエアは目に見えますので、その図面の書き方は自ずと決まってきますが、情報システムは目に見えませんので千差万別となりがちです。実際情報システムの難題の多くは、そのドキュメンテーションに関わっています。
私は、「人間のコミュニケーションに関わる言語には3種類ある」と勝手な仮説を立てています。すなわち
? 図面言語(地図、建築図面、機械組立図、DB構造図など)
? テーブル言語(時刻表、部品表、データ定義書、EXCEL表など)
? テキスト言語(日本語、COBOL、JAVAなど)
の3種ですが、「エンジニアリングドキュメントは?、?に限る、?は摘要程度に抑えるべき」と主張しております。?は関係の表現が不得意かつ定型化/標準化が不可能なため、抜けや不整合の摘出が本質的に困難だからです。実際プラントの仕様は?、?によって疑義なく記述されていたと記憶します。ところが情報システムでは?が主体となっているではありませんか。これでどうして正しいコミュニケーションができるのでしょう。
そんなことから、これも勝手ですが、情報システムのRFP記述の4基本ドキュメントとして、
 A.概念DB構造図(図面言語、粒度と役割/時系列によりレイアウト)
 B.データ定義書(テーブル言語)
 C.情報処理フローチャート(図面言語、論理組織と時系列によりレイアウト)
 D.画面・帳票イメージ(図面言語)
を、その記法の標準とともに提案してきました。これらはサイエンスではありませんから、普遍的原理ではありませんが、サイエンスで認識したものは、なんらかの形で表現しています。そして同じ対象なら誰が書いても同じ成果物、類似の対象なら類似の成果物が得られ、ノウハウの蓄積・整理にきわめて有効に活用することができます。
■実装独立の意義
実装従属/IT従属ということになると、どうしてもARTの世界になって属人化してしまいます。ITの世界はユーザには分かりにくく、その混入はユーザとのコミュニケーションの障害になります。またITはめまぐるしく変化しますから、IT従属の成果物は陳腐化しやすく、標準化の努力もペイするのが難しい。さらにIT環境は企業によって違いますから、企業横断の使いまわしができません。
こうして実装独立に制約してサイエンスの確立をはかり、また速い・安い・高品質を指向してドキュメンテーション標準を整備してきました。しかし最後は実装に持ち込まなければなりません。残された大きな課題は
・ 操作性の良い画面設計
・ 機械効率の高いハード・ソフト環境の設計・選択
の2つではないかと思っています。これらはIT従属ですから、そのIT環境下での若干の標準化は可能でしょうが、状況に応じたカスタマイズが不可欠となるはずです。またものづくりの世界ですから、アパレル、建築、車ほどではなくとも、意匠・デザイン・創造の要素が入ってくるかと思われます。これが初めに申し上げた(実利+α)のαかと思います。
■ リポジトリ
品名は、たとえばラガー、一番絞り、スーパードライなどを抽象化して一括するメタデータ(データのデータ)の一つです。データ項目名(属性名)は、この品名、顧客名、在庫数量などを抽象化して一括するメタメタデータの一つです。われわれはメタメタデータとして、このほかデータ項目に関しては、データ項目番号、定義域、データ機能コードなど、またエンティティに関しては、エンティティ番号、エンティティ名など多くのものを定義すべきとしています。
メタデータをストアするデータベースはリポジトリと呼ばれますが、これが先の情報システムを記述する基本4ドキュメントを電子化した場合の受け皿となります。人間が図面言語やテーブル言語で共有する情報は、コンピュータにも共有してもらわなければならないと、電子化してDBにマッピングするわけです。メタメタデータは、この受け皿の構造を規定することになりますが、これは情報システムをどう捉えるかによって決まりますので、リポジトリの構造は目下そのベンダーごとにまちまちとなっています。
われわれは実装独立の業務モデルのリポジトリと、実装従属のソフトウエアのリポジトリ、さらにハードウエア構成のリポジトリの3者は分離すべきと考えていますが、これもまだコンセンサスを得るには至っていません。短期的に考えれば、今のIT環境に合わせて考えた方が簡単ではないかということで、サイエンスの出る幕が制約されているのだと思われます。
リポジトリとの関係を吟味すると、メタデータが洗練され、システムドキュメントの品質が進化してくるもののようです。最近、情報システムに図を持ち込もうと、UMLがさわがれています。それ自体は良い傾向だと思いますが、サイエンスとかリポジトリとかの配慮がもっと出てきて、「サイエンスによって、決まる問題を明らかにした上で、これをどう表現すべきかなど、決める問題が議論されるようになれば、もっと良くなるはず」と思っています。オブジェクト指向に限らず、この一文が情報システム開発・保守へのサイエンス導入のきっかけになれば幸いです。