» 【第38号】概念先行

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

DRI通信38号「概念先行」 1999.11.1
金木犀が散り、セイタカアワダチソウも盛りを過ぎて、遅い秋が進行していま
す。10月10日に海での泳ぎ収めをしましたが、まだあちこちクラゲに刺さ
れました。ジョギングがようやく楽になり、スキーシーズン前のトレーニング
となります。小渕政権は財政赤字を積み増しながら日本経済を維持しています。
われわれは赤字解消と必死にがんばっていますが、皆様はいかがですか。
■レイヤードアプローチ
われわれは、「データ先行、概念先行、リソース先行のレイヤードアプローチ
は、システム開発の鉄則である」と考えていますが、今月はこのうちの概念先行
について考察します。
データ先行すなわちDOAは、ようやく大方の市民権を得てきたようです。
DOAとはインターフェース先行です。インターフェースを先行して決めれば、
これを介して動くプロセスは独立した存在になり、その動き方を事前に規定し
たり、コンカレントに動かしたりすることができる。


すなわちWHATをHOWに先行させることによってシステムをより小さな
独立したサブシステムに分解する事ができるわけです。インターフェースとは
データの集合ですから、データ先行によって、まず課題をブレークダウンし、
より小さな課題にすることができる。次にインターフェースを構成する
データ項目のうち、共通化・標準化すべきものの仕様を事前に整備することに
よって、整合性・品質の問題をプロセスに先立って解決することができることに
なります。
■概念とは
しかしこのインターフェース仕様に、物理すなわち実装技術が含まれていると、
技術革新/IT技術の変化によって影響を受け、最悪、せっかく標準化した
インターフェース仕様のすべてを捨てて再構築しなければならなくなります。
多くの担当者は、「当分大丈夫」と考えていますが、2000年問題と同様、
問題は思ったより速く発生してくるもののようです。「独立したシステムに
分割するためのインターフェースはまず実装独立に規定すべき」が今回のテーマ
「概念先行」です。
概念という言葉は、誤解を生みやすい言葉ですが、ほかにあまり良い言葉があり
ません。Conceptual の翻訳です。概要という意味ではありません。自動車の
オートマ・ミッションは、ユーザがその実現手段としてのギヤを意識しません
ので、概念の接続と言えます。インターネットもユーザはどのような経路で信号
が伝えられているかを意識しませんので、概念のネットワークと言えます。
■RDBの功罪
インターネットが大きなインパクトを持った理由は完全に実装独立、すなわち
完全概念ネットワークだったからだと、私は考えています。これに対し
RDBMSとSQLは残念ながら完全概念ではありません。ユーザにエンティ
ティでなくテーブルを見せているからです。
たとえば、受注データのアウトプットとして、品番と品名が要求された場合、
品名を結合して出力すべきか、あらかじめ持っている冗長(非正規化)データ
を出力すべきかを意識しなければなりません。また社員の基本給を出力する
とき、社員名と基本給がおなじテーブルにあるか、別テーブルに実装されて
いる(縦分割)かを意識しなければなりません。またユーザの意識する加工データ
の加工元データとの関係や整合性は守備範囲から外されたままとなっています。
すなわちRDBMSは、物理的なテーブルをどう作るかを規定しているので
あって、ユーザの見るエンティティをユーザの立場から規定しているわけでは
ありません。たしかにストレージの使い方やインデックスの詳細は隠蔽し、その
意味で論理モデルという言葉が使われていますが、使う側のビジネスユーザ
(本当のユーザ)の見方ではなく、造る側のSE(ベンダーから見たユーザ)の論理
から設計されていると言えます。
したがってRDBMSをインターフェースとする限り、ITの変化の影響を
受け、ビジネスモデルが変わらないのにメンテナンスが発生したり、ユーザと
しては変わり易く難しい――というより設計者の決めた本質的でない煩瑣な
約束事の――IT技術を習得しなければならないという負担を強いられることに
なります。
ERモデルは、1975年第1回VLDB(Very Large Data Base)国際学会
において概念モデルとして提唱されました。RDBが図表現を持たないため
これを補完する意味で、広く活用されるようになったわけですが、RDB
(物理DB)実装の便宜を追求したため、概念モデルの側面は、多くのユーザ
からほとんど忘れられてしまっています。CASEツールERwinも、この
傾向を助長することになったと言えるでしょう。
■概念と物理を分けて関係づける
われわれがPLAN−DBで用いているTHモデルは、完全概念モデル――
すなわち実装独立にビジネスユーザのデータの意味――を表現するものです。
人間の行うビジネスは、かつては紙を介して行われていました。今は画面や
電文などが使われますが、論理的にはデータの集合であり、今後何百年経って
も変わらないものと考えられます。したがってその実装独立のデータ仕様の
標準は、RDBをベースにした標準などに比較して格段に安定したものと考え
られます。
しかし概念モデルは、物理モデルに変換しなければなりません。これを紐付け
不整合が発生しないよう連動処理を支援しなければなりません。若干複雑な
仕掛けが必要になりますが、これは避けて通るべきでなく、不可欠の課題として
取り組むべきものと考えます。これによって標準化の成果は長くまた広域で使用
できます。標準化はメリットも大きいわけですが、コストも思ったより掛かる
ものです。概念モデルによってこの寿命を長くすることは十分ペイする事と考え
ます。
概念モデルはデータだけにあるものではありません。プロセスにも実装独立の
仕様と実装従属の仕様とがあり、分離して考える事ができます。「顧客が注文
を当社営業に発行する」「営業が物流部門に出荷を依頼する」などは概念レベル
のプロセス仕様になります。そのとき「電話で」とか「FAXで」とか規定する
と実装手段を記述した事になり、ITの変化によるメンテナンスが発生しやすく
なります。つい近視眼的に実装手段こみで記述したくなりますが、これを分けて
記述するのが「プロの設計」ということになります。
ネットワークと同様に、DBも完全概念になったとき、データも01の信号で
なく、意味が共用・流通することになり、コンピューティング・パワーも電力
と同様のユーティリティとして、インターネット以上のインパクトを持つように
なるのではないかと期待されます。