» 【第11号】工程統合から分野統合へ

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第11号】工程統合から分野統合へ

DRI通信11号 「工程統合から分野統合へ」 1997.8.1
今年は、エルニィーニョ、空梅雨、台風3個とは言いながら、結構まともな夏本
番を迎えておりますが、いかがお過ごしですか。
さきのDRI通信10号では、ハードウエア:ソフトウエアの2レベルでなく、
ハードウエア:ソフトウエア:ビジネスモデルの3レベルで考えるべきだと提言
しました。ソフトウエアとビジネスモデルを分離することによって、ITの変化と
ビジネスニーズの変化を、掛け算でなく足し算で受け止めようと言うわけです。
保守を合理化するには、保守の発生を減らす仕掛けが最も有効だからです。
■平松さんのご意見
これに対して、東レの平松さんから「理解できるが、多くの人の共通認識を得る
には、エンティティタイプ、データ項目、ドメイン、画面・帳票、ファイル、表、
JCL、プログラム、モジュール、ほかマンマシンインターフェース、パーフォ
ーマンスなどとの関係を明らかにする必要がある」とのご意見をいただきました。


確かにごもっともな意見と思います。PLANーDOAでは、IRMコンポーネ
ントを整理しておりますが、いままではデータ系、プロセス系、実行担当系に分
類するだけで、ビジネスモデルとソフトウエアの観点では分類していませんでし
た。これについては今年度の課題として見直しをかけていますので、早晩、より
明快な説明ができるようになると考えています。
■Sapiensのデモから
7月14日、サピエンスジャパン社のご好意によりイスラエルのCASEツール
Sapiensのデモを見せていただきました。まず印象に残ったことは、業務アプリ
ケーションについてですが、PLANシリーズと非常に似たコンセプトによって、
プログラムレスを実現していることでした。われわれはかねてからDOAは本来
プログラムレスを、あるいはプログラム仕様書1/10を実現すべきものと主張
していましたが、まだ改良の余地を残すとはいえ、すでに実証する事例があると
の感触を得ることができました。
ただしSapiensでは、ビジネスモデルとは言っていません。むしろDB2などを
意識して実装従属に動く仕掛けーソフトウエアーを作ろうとしているかに見えま
す。しかし実際に定義登録すべきものの主体は、実装独立のデータモデル、デー
タ制約/データ定義にほかなりません。したがってビジネスモデルリポジトリと
ソフトウエアリポジトリを分離し、サブタイプの扱いを取り込むことができれば、
さらに完成度の高いCASEツールができるのではないかと思いました。
ソフトウエアを考えるときは、これとソフトウエアリポジトリのコンテンツを、
たとえばつぎのように、分けて考えなくてはならないと思われます。
  (ソフトウエア)      (リポジトリ・コンテンツ)
  プログラムステートメント  ロジック仕様
  DDL           物理ファイル定義
プログラムレスでは、このソフトウエアはなく(または隠蔽されてユーザから見
えなく)なりますが、ソフトウエアリポジトリのコンテンツはいぜん存在し続け
ます。たとえデフォウルトデータの活用により入力がどんなに簡便化されるとし
ても。
■DOAによる工程統合
DOAではデータの仕様を固めからプロセスの仕様を決めようとします。データ
中心とはデータ先行のアプローチだということができます。データやその塊とし
ての概念ファイル(エンティティ)、IOを固め、これを作り出すプロセスを対
応づけてオブジェクト指向!(?)を実現します。
さきにIBMが失敗したAD/Cycleは、この工程統合を試みるものでした。とこ
ろがSapiensは、これにかなり成功している。工程統合はプログラマーの夢です。
プログラマーの仕事を全自動化するもの、生産性を飛躍的にあげるものだからで
す。しかし行程統合は狭い分野を対象とした、視野の狭い戦術的なDOAである
ことも否めないところでしょう。
■DOAによる分野統合
「DOAは大規模システムには向かない」などといった声もありますが、それは
プログラマーの指向する戦術的DOAだったのではないでしょうか。われわれは
「DOAは大規模システムを扱うためにある」と考えます。
そのためには実装独立のDOAを行い、概念データモデル、すなわちビジネスモ
デルを扱わなければなりません。これによって、営業、生産、経理、人事ほかの
分野統合を行います。基幹業務、全社、関連企業、グローバルとオープンに拡大
してゆきます。
一般にシステムの複雑さは、含まれる要素の数(n)の2乗に比例します。これ
はn個のものの2個づつの組み合わせの数が、n(n−1)/2となることから
分かります。これを私は「n2乗の負荷」と言っています。大規模システムでは
データ項目の数が少なくとも2千、多いとn万になりますが、このような膨大な
「n2乗の負荷」に対処しなければなりません。
また規模が大きければ大きいほど、1個1個のデータ項目の品質も上げなくては
なりません。煉瓦を積むような仕事ですから、品質が悪いと途中で崩れてしまう
からです。
したがってこのような大規模システムのための分野統合では、「方法論」と「こ
れをマスターした人」が決め手になります。ツールを否定するわけではありませ
んが、ツールで解決できるものではありません。ITの課題ではなく、経営、ビ
ジネスの戦略的課題だからです。実際データ共有のための標準化においては、見方
/使い方の違う二つのユーザの文化の衝突が発生することも多く、その調整に当
たるデータ管理者は、「データの弁護士」の役割を演じなければなりません。
 
■おわりに
先回も申し上げましたが、業務アプリケーションソフトウエアとしてはそんなに
大規模なものを作るべきではありません。むしろSEの手に負える、そのプラッ
トフォームの特徴を100%生かした心憎い、ユーザの心に訴えるものをつくる
べきです。しかしビジネスモデルは、データの広域的流通のため、十分広い範囲
で整合性の取れた、大規模なものでなければなりません。
これまでPOAからDOAへ発想の転換を図るのに随分時間がかかっています。
ソフトウエアとビジネスモデルを分離するにも、また時間がかかるかもしれま
せん。システム関係者の発想を、まずプログラム中心からデータ中心へ、つぎに
ソフトウエア中心から経営/ビジネス中心の発想に転換/拡張/解放しなければ
ならないからです。頭で覚えた知識の変革は容易ですが、身体で覚えた文化の変革
には時間がかかります。しかしシステム問題の解決は、ビジネスモデル中心、
データ中心以外にはないと思われます。がんばりましょう!
                               椿 正明
DRI通信は1996年10月から発信しています。
DRI通信不要の方、また逆にバックナンバーご希望の方はご連絡ください。