» 【第4号】アプリケーションソフトウエア

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第4号】アプリケーションソフトウエア

DRI通信 4号                    1997.1.1
あけましておめでとうございます。いよいよ1997年の始まりです。良い年で
あることを祈ります。
3号に対して「参考になる」など励ましの言葉をいただきました。今回も、私な
りのオブジェクト指向序論的なものを展開してみました。その道の権威の方にレ
ビューしていただいたものでないので、おかしいところが多々あるかもしれませ
ん。仮説、叩き台です。大いに叩いてみてください。
「アプリケーションソフトウエア」
■基本ソフトと業務アプリケーション
「アプリケーションソフトウエア」、「アプリケーション」、またときに「アプ
リ」などといかにも分かり切った言葉として用いられているが、案外誤解の原因
を作っているように思われる。
マイクロソフトに言わせれば、ACCESS、EXCEL、WORDはアプリケ
ーションであるが、われわれはこれらを基本ソフトと呼び、販売物流システムや
経理システムなどをアプリケーションと呼ぶ。正確には業務アプリケーションと
呼ぶべきであろう(CAD、やエンジニアリングを含めるので事務アプリケーシ
ョンとは呼びたくない)。


根本的な違いは何かといえば、得られる結果が業務を実行するための直接的情報
−データの塊−であるか否かである。業務アプリケーションの結果は、出荷指図
書、原価計算書などで、そこには顧客番号、品名、出荷数量、勘定科目コード、
部門コード、原価など業務固有のデータが含まれる。
基本ソフトは、このような固定的な情報を扱うものでない。むしろ汎用的に、「
検索入力」を受け取って「検索結果」を返す、とか「入力データ」を受け取って
「ファイル」を作るといった(専門的にいうとメタデータについての)処理を行
う。扱うデータの形式は問題にするが、意味内容は問わないのである。
■業務アプリケーションはデータ中心で
アプリケーションと呼ばれるこの二つのソフトウエアは、したがって大いに性質
を異にする。データ中心アプローチが叫ばれているのは、データの塊を成果物と
する業務アプリケーションであって、基本ソフトはプロセス中心とならざるを得
ない(基本ソフトへのデータ中心的アプローチも興味あるテーマであるが別次元
のテーマとしてである)。オブジェクト指向の議論もこの二つの違いをわきまえ
て行わないと、誤解が先行しきわめて非生産的となる。
出荷指図書、請求書、原価計算書、総勘定元帳など業務アプリケーションの成果
物こそが、ユーザの求める情報システムの製品である(話しを簡単にするために
今情報系を除いている)。これらはビジネス環境の変化に応じ種々微妙に変化す
る。この対応を誤るとき、保守地獄が生ずるのである。製品を構成する部品−デ
ータ項目−も変化するが製品に比較すれば、その変化ははるかに少ない。そこで
これを標準部品として識別管理し、この組み合わせによってイージーオーダー的
に製品を作ろうというのが、データ中心の発想である。
したがってデータ中心は、成果物主導となる。出荷指図書を決めてからそのプロ
セスを考える。請求金額の定義を決めてからこれを算出するプロセスを考える。
原価の定義を決めてからその算出プロセスを設計する。このデータ(データの塊
や1個のデータ項目)とプロセスのペアをオブジェクトと呼ぶならば、プロセス
はデータの裏に隠蔽されてオブジェクトが形成される。
■基本ソフトはプロセス中心で
基本ソフトはプラットフォームソフトといってもよいだろう。もともとハードウ
エアを動かすためのソフトである。メモリサーチ、計算回路、ディスク読み取り
、キーボードタッチを検出する基本ソフトを進化させたものであり、入力に対す
る出力、すなわち処理が課題である。
そこにどのようなデータが存在しどのような処理が行われるかが問題なのではな
く、その処理への入力、およびその処理からの出力だけが問題なのである。した
がって、そのオブジェクト指向も、抱えているデータを隠蔽した処理についての
オブジェクト指向であると限定するとよく分かる。CORBAも、OLEも、D
COMもこのようなプラットフォームのインターフェースを標準化するプロセス
中心のオブジェクト指向と考えるべきであろう。
ソフトウエアの研究は、OS、コンパイラー、DBMS、など基本ソフトから発
生している。プロセス中心のメーカーの文化の中で育っている。ソフトウエア工
学として要求定義などが論じられても、ここに述べたような業務アプリケーショ
ンと基本ソフトの区別は論じられず、業務アプリケーションにたいしてもプロセ
ス中心的に、ゴリゴリパターン化するやりかたが主流だったように見受けられる。
■企業組織と対比させると
データ中心アプローチの仕事の流れは、画面・帳票:製品、データ項目:部品と
するとき
  製品設計→部品設計→部品調達→製品組立→販売
の順序をとるので、これはまさに製造業の事業部門の流れに等しい。するとプラ
ットフォームは総務・人事・経理などの管理部門に相当するもののようである。
事業部門は、ビジネス環境の変化に追随して製品を変え、これに応じて組織も変
わるが、管理部門は比較的安定している。実際、事業部門は製品の個性を反映し
たものになっているが、管理部門はどこの会社でも似たりよったりである。業務
アプリケーションはどんな画面・帳票を提供すべきかによって決まるが、OS、
DBMS、WPなどは画面・帳票の内容によらず同じものが使える。
さきの「DRI通信3号」では、工作機械はDBMSなどに、金型は個別アプリ
ケーションに相当すると述べたが、今回とあわせると次のようにまとめられよう。
 対象     製品・部品処理系 製品・部品系
 特徴     汎用的      個性的(製品・部品から決まる)
 処理機械   工作機械     金型
 会社組織   管理部門     事業部門
 ソフトウエア 基本ソフトウエア 業務アプリケーション
 アプローチ  プロセス中心   データ中心
業務アプリケーションは、整合性のとれたデータを共用するために、データベー
スを中心にした、フラットなアーキテクチャにすべきであるが、その範囲/空間
は有限である。別データベース空間の間のやりとりは、EDIとして検討されて
いるが、やりとりすべきデータが限定できるので、一見プロセス中心的アプロー
チで解決できそうにみえる。しかしn個のデータベース空間がからむのでやはり
「ピアツウピア」を避けるためにデータ中心アプローチが必要になる。やはり業
務の個性を担うデータ項目を扱うソフトはデータ中心で、これを意識しない管理
部門的ソフトはプロセス中心で構築すべきなのであろう。オブジェクト指向を論
ずるときの基本的姿勢として問題提起したい。
                                椿 正明