» 【第6号】DOAのねらい

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

DRI通信 6号 「DOAのねらい」        1997.3.1
5号の後も、直接あるいはEMAIL上でいくつかコメントをいただきました。
オブジェクトとか部品とかに対する関心の高まりは相当なものです。「どうして
も部品というとサブプログラムを考えがちだ」といった言葉が印象に残ります。
私は情報システムに関してその人の認識がどの程度DOA的かを、まず次の表で
判定できるように思いました。
  製品         部品
  プログラム      サブプログラム  ←POA
  情報(アウトプット) データ      ←DOA
さてDOAを論ずる以上、対象は基本ソフトではなく 業務アプリケーションと
なります。すなわちその成果物は特定の業務を支援する情報であって、たとえば
顧客番号、品名、出荷数量、勘定科目コード、などのデータから構成される画面
・帳票の類である。


和製略語DOA−Data Oriented Approach (英語圏ではDead On Arrival を連想さ
せるのでまずいとの意見もあるが、堀内一教授の主張でもありこれでゆく)もだ
いぶ市民権を得て来たが、意味するところにはかなりの幅がある。プログラムの
なかの定数をテーブル化しようという素朴なものから、情報資源管理やプログラ
ムレスをねらうものまでいろいろなレベルがある。
しかしおおまかにはつぎの2種に分けて考えてみることができ、またこれによっ
てDOA的認識の程度を評価することができるように思う。
        広義のDOA       狭義のDOA
作業の要点   RDBのテーブル設計   データ項目の標準化
評価軸     開発の生産性       開発・保守・運用の生産性
スコープ    1業務分野        全社
対象      ソフトウエア       ビジネスモデル    
処理の検討   実装従属(物理)で    実装独立(概念)で
当然のことながら、広義のほうが従来法とのギャップが少なく、短期に成果が得
られるので広く−80%以上ではないか−受け入れられている。ほとんどの
CASEツールがこの広義を前提につくられており、適切に用いるときそれなり
の効果を挙げることができる。かつてICASEによる失敗が伝えられたが、多
くは広義のDOAの方法論やCASEツールを用いて、全社システムなど狭義の
DOAの目標まで欲張った結果のように思われる。
これに反し、狭義のDOAは長期的・戦略的効果をねらうため、従来法とのギャ
ップが大きく、安易に取り組むことができない。対象が大規模になるだけでなく、
情報システムについての基本的コンセプトや技法が異なるため、その習得にかな
りの先行投資が必要になり、マネジメントの意識改革も必要になる。しかし一つ
の会社のデータはなんらかの形で切れ目なく関連しており、実践的という理由か
らこれを無視して分断処理されることが多いが、その付けは必ず戻ってくる。
短期をねらうか、長期をねらうかは会社の方針によるから、当面どちらが正解か
はケースバイケースであるが、その違いを正しく認識しておくことは重要である。
近ごろ特に感ずることであるが、広義と狭義の根本的な違いは、情報システムを、
片やソフトウエアと考え、片やビジネスモデルと考えるところにあるように思わ
れる。ここにビジネスモデルとは、データの加工/導出を含めた概念データモデ
ルと「誰がいつ、どのような条件が整ったときどんな目的でどんな情報を生成す
るか」というマクロな処理モデルを指すものとする。
狭義の場合は、「万人が疑義なくコミュニケーションできるよう、ビジネスモデ
ルを図と表の形式で表現し、ソフトウエアはこれを実装環境にマッピングして作
ることができる」と考えるのである。ビジネスモデルは顧客指向で、常に市場の
ニーズに適合するよう変化させなければならない。一方ソフトウエアは実装技術
の進歩に応じ最適なものをとりこむ必要がある。
すなわち狭義ではビジネスモデルの存在を認知しこれをリポジトリに記述し、こ
れをベースにソフトウエアを位置付ける。一方広義では、ビジネスモデルを、設
計の過程において一旦は考えても、記述すべき存在とは認知せず、存在するのは
ソフトウエアのみと考える。したがって保守フェーズにおいては、ビジネスニー
ズの変化にたいしていきなりソフトウエアに変更を施すことになる。
ソフトウエアはその名に反してハードであるというのが大方の実感である。元来
はソフトウエア=プログラムであったが、その後ソフトウエア=プログラム+デ
ータ、今やソフトウエア=プログラム+DBといった認識かと思われる。ソフト
ウエアはデータないしDB経由関連している。
インターフェースであるデータないしDBを協定しデータの流通を確保するのが
DOAの第一のねらいであるが、ビジネスニーズの変化によりインターフェース
すら変化する。また個別分野ごとのDBだと、その間のデータの仕様が合わず調
整が必要になる。このときソフトウエアのみが存在するという考え方だと、一旦
破壊してからでないと調整できず、個別開発の積み上げで全体を構成する方式が
難しくなる。
システムの規模とはデータの整合性のとれる範囲と考えられるが、企業競争力強
化に有効なためであろう、これが年々拡大している。存在するのはソフトウエア
だけというアプローチでは大規模システムにおける対応が迅速にゆかない。「総
身に知恵がまわりかねる」システムでは限界がある。最終的にはビジネスモデル
の存在を認知し記録し管理しなければならない時がくるに違いない。
ビジネスモデルへの関心が薄い一つの原因は、「ソフトウエアに持ち込まなくて
は処理が記述できない」との誤解にあるのかもしれない。たしかにERモデルを
用いる一般の方法論ではビジネスモデルとして処理を記述する方法が提供されて
いない。SQLなどでもDBMSがみせかける実装のレコード形式を前提にして
しか処理の記述ができない。
処理は、入力、出力、加工に大別でき、これに分類(処理対象の抽出)がからむ
が、PLANーDBではSPFチャートによりこれを記述することができる。す
なわち、入力・出力のプレゼンテーションロジックは、基本ソフトにかかわる部
分として除くものとし、業務アプリケーションロジックに限定すれば、これらは
SPF操作の、結合・加工・要約・抽出などにより明快に記述されるのである。
複雑な制約条件も、物理ファイル上には見えない臨時加工データを定義すること
によって、実装独立にビジネスモデルとして記述することができる。今回は紙面
の都合上くわしく述べることができないが、この機能はDOAがプログラムレス
を実現するためには不可欠のものである。このような物理ファイル上に実装され
ないデータは、ソフトウエアのみを認知する従来のリポジトリには記述する場所
がない。最近CASEツールを連携するために、リポジトリ標準化の動きが活発
化しているが、これもソフトウエア、すなわち実装従属のレベルにとどまるもの
と思われる。
このようなソフトウエアに囚われた認識からは、ビジネスモデルを記述し管理す
る発想が育ちにくく、BPRにおいても本来果たすべきリーダーシップがとりに
くい。業務とは情報を受信し、新たなデータを生成・加工し、これを加味した情
報を発信することであるから、DOAによるビジネスモデルをBPRのベースに
据え、これを推進することは、情報システム担当者の最も重要な責務のように私
には見える。DOAのねらいはついにソフトウエアから脱皮し「ビジネスエンジ
ニアリングを確立すること」のようになってしまったが、この方向について皆様
はどうお考えであろうか。
                                 椿 正明