ビジネスシステムとインターネット ·...

1

ビジネスシステムとインターネット

1.1 インターネットの導入

1.1.1 インターネットの普及

我が国の企業活動および個人生活の様々な局面で，インターネットの利用が急速に

広がっている。総務省による通信利用動向調査によると，2002 年末の時点で，我が国

のインターネット利用者は 6942 万人，人口比の普及率で 54.5％であり，2001 年末の

44.0％から大きく増加し，はじめて 50％を超えた。4 年前から約 5 倍の増加である。

2002 末の数値は，世界的に見ても人口で米国に次ぐ第 2 位，普及率で第 10 位と高水

準に達している。

0

10

20

30

40

50

60

70

80

90

100

98年末 99年末 00年末 01年末 02年

総務省　平成14年度通信利用動向調査のデータによる。個人は，携帯電話，PHS，携帯端末，ゲーム機による利用者を含む。は15歳から79歳，01,02年は6歳以上の普及率である。中小事業所とは従業員5人から29人の事業所，中小企業とは従業員1業とは従業員2000人以上の企業を指す。

98,99年は15歳から69歳，00年

00人から299人の企業，大企

0

10

20

30

40

50

60

70

80

90

100

98年末 99年末 00年末 01年末 02年0

10

20

30

40

50

60

70

80

90

100

98年末 99年末 00年末 01年末 02年

総務省　平成14年度通信利用動向調査のデータによる。個人は，携帯電話，PHS，携帯端末，ゲーム機による利用者を含む。は15歳から79歳，01,02年は6歳以上の普及率である。中小事業所とは従業員5人から29人の事業所，中小企業とは従業員1業とは従業員2000人以上の企業を指す。

98,99年は15歳から69歳，00年

00人から299人の企業，大企

末

個人

中小事業所

中小企業

大企業

末

個人

中小事業所

中小企業

大企業

末

個人

中小事業所

中小企業

大企業

図 1.1 我が国におけるインターネットの普及率

23

1. ビジネスシステムとインターネット

1997 年末の同調査によると，従業員 2000 人以上の企業においては普及率 92.3％に

対し，100 人以上 299 人以下の企業では 57.6％，5 人以上 29 以下の事業所において

は 16.7％であった。当時は，インターネットの利用が大企業に偏在していた感がある

が，2002 年末では，100％，95.1％，73.2％と急激に較差が少なくなっている(図 1.1

参照)。

1.1.2 インターネット利用形態の進化

インターネットは，利用者が拡大しただけでなく，利用形態の上でも大きな変化が

現れている。当初は，インターネット登場以前に紙媒体で授受されていたものを単に

インターネット通信に置き換えた利用であったが，ソフトウェアの発達に伴って高度

な連携形態が実現されるようになってきている。インターネットは人手操作によって

表示物を見る道具として便利な存在であったが，さらにプログラムでシステムを自動

連携する方向で発展している。また授受される情報も，単純な文書から，構造やスキー

マを持つデータに対象を広げ，ビジネスの概念の表現を授受することへの挑戦が開始

されている。

このようなインターネット利用形態の変化を，時代を代表する利用装置と結び付け

て述べてみる(図 1.2)。

印刷物(PDF等)

メールで送られたもののみ利用可能

Web表示(HTTP)

すべての情報を

閲覧可能

人手操作で表示物を見る

システム(XML)

連携システムから情報

自動的に取得

連携

を

　　　　文書　　　　構造化文書

紙媒体

利用形態

データ交換

連携方法

データ表現

インターネット通信利用

データスキーマ

印刷物(PDF等)

メールで送られたもののみ利用可能

Web表示(HTTP)

すべての情報を

閲覧可能

人手操作で表示物を見る

システム(XML)

連携システムから情報

自動的に取得

連携

を

　　　　文書　　　　構造化文書

紙媒体

利用形態

データ交換

連携方法

データ表現

インターネット通信利用

データスキーマ

Webサｰビス(XML)

あらゆる情報を自動的に

取得，加工・・・

Webサｰビス(XML)

あらゆる情報を自動的に

取得，加工・・・

プログラムでデータを連携

業務概念構造

プログラムでデータを連携

業務概念構造

図 1.2 インターネット利用形態の進化

24


① 印刷物送付の代替としての電子メール

電子メールの基本機能は，郵便と対比することができる。郵便物を電子媒体とし，

郵送をインターネット通信に置き換えたものである。郵便と同じように，指定した宛

先に送り届けることが可能である。インターネットの利用者は，送り届けられた情報

のみ手元で扱うことができる。

② Web 参照

Web の参照は，いわばインターネット利用の入門と言えるものであり，国民全般に

普及した利用法である。Web 参照によれば，原理的にはインターネット上のあらゆる

情報を閲覧可能である。Web に窓口を設けて，そこにアクセスすることで買物や申請

などを行うことも広まりつつある。しかし，手動で Web ページを呼び出す必要があ

り，また，いつ，どこに有用な情報が掲載されるかは自明でないので，実際には限ら

れた情報しか得ることができない。

③ システム連携

インターネットを介して必要な情報をシステムのデータとして連携させる。システ

ム連携により情報の取得は自動化され，対話的な応答も実現することが可能である。

しかし，あらかじめ認知され，連携を実現した情報しか利用することができない。ま

た，システムのデータにおいては，データの名前や形式が明確に定義され，検定され

て使用される必要がある。

④ Web サービス

Web サービスとは，インターネット上での情報の形式を標準化し，情報のあ

在りか

処を

登録することを前提として，情報を自動的に収集，加工，比較または分析した結果を

提供するサービスである。Web サービスで授受されるデータは，単にコンピュータ処

理のデータである以上に業務情報そのものであり，意味と関係を表現したデータ構造

を持っている。Web サービスの方式と動向に関しては第 2 章で述べる。

インターネットの利用は，上記のような過程を経て進化している。国民的に共通な

利用形態としては①②を挙げることができるが，企業活動をより直接的，積極的また

は包括的に支援するには③④の形態が期待される。③④の利用形態は，企業ごともし

25


くは企業の部署ごとに動作するコンピュータシステムをインターネット経由で連携さ

せることにより実現される。システムの連携をインテグレーション(統合)と呼ぶ。

1.1.3 インターネットシステムへの期待

インターネットによってインテグレーションされたシステム(インターネットシス

テム)は，下記のような観点で効果が期待される(図 1.3)。

⑤ビジネスプロセス最適化

⑥情報共有

⑦個客管理

⑧コミュニティ形成

①大量情報の利用

③短納期で安価

④標準化技術

インターネットの基本特性インターネットの基本特性

②日常的な親しみ

企業革新の推進

①大量情報の利用

③短納期で安価

④標準化技術

インターネットの基本特性インターネットの基本特性

②日常的な親しみ



社外ネットワークの強化社外ネットワークの強化

⑤ビジネスプロセス最適化

⑥情報共有

⑦個客管理

⑧コミュニティ形成


社外ネットワークの強化社外ネットワークの強化

図 1.3 情報システムにおけるインターネットへの期待

(1) インターネットの基本特性

インターネットの技術的性格から，下記の効果を直接的に期待することができる。

• 大量情報の利用

インターネットは，全世界的な情報網であり，不特定の利用者が参加すること

が可能な開放された環境である。企業情報システムにおいて利用する場合には，

セキュリティを考慮して利用者の範囲を限定することが多いので無制限の情報が

対象となるわけではない。しかし，従来に比べてはるかに多くの情報を取得する

可能性と機会に恵まれるようになったことは間違いない。また，企業からの発信

においても，Web やメール等を利用することにより，従来以上に多くの人々に情

報を伝達することが可能である。

26


• 日常的に親しんだインタフェース

Web 画面のインタフェースは，企業の様々な業務のみならず個人生活において

も普及しており，利用者は日常的に親しんだインタフェースとして利用すること

ができる。PC だけではなく，PDA，携帯電話，ゲーム機など，インターネット

機能を含む機器に日頃触れる機会も多い。企業の作業のための特別な機器として

ではなく，手についた便利な道具(コモディティ)として扱うことができる。シス

テム利用にあたっては訓練の必要がなく，積極的な利用を期待しやすい。また，

ユビキタス(ubiquitous)という形容詞によって，いつでも至る所で利用できるこ

とが特徴として語られることも多い。

• 短納期で安価なシステム構築

インターネットの通信や Web 画面への表示に関する機能は，基本機能に関す

る標準化が進んでおり，システム構築費用を低価格に抑えることができる。イン

ターネットシステムでは，特別な機能をあまり強く求めず，標準的な基盤機能に

従ってシステムを構築する傾向が強く，情報の流通やシステムの互換面でもそれ

が推奨される。例えば，通信伝達速度に関しては無理に到達時間保証の設計をせ

ず，設備容量を先に決めて最大努力性能を提供するに留めることが基本である。

画面表示に関しては，無理に利用者固有の機能を作り込まず，Web 一般の基本画

面配置や入出力機能を用いて設計することが基本となる。基本機能に従ったシス

テム構築となる傾向が強いため，短納期と安価が達成されやすくなっている。

• 標準化技術の発展

インターネットの技術は進化を続けている。データ交換のための標準化言語で

ある XML は機能拡張が進められている(第 2 章参照)。XML 文書の発信，受信，

登録等の利用機能の標準化も進められている。企業システムでは必須となるセ

キュリティに関しても，署名，暗号化，利用者認証の利用や相互運用に関して標

準化が進められている。J2EE や.NET などインターネット利用を前提としたシ

ステム基盤では，トランザクションや分散システム管理の標準化が普及している。

インターネットシステムでは，これらの標準に準拠した製品群を順次導入してシ

ステムを強化していくことが大いに期待できる。

27


(2) 企業革新の推進

伝統的な企業システム構築の観点からは，下記の点が注目される。これらにおいて

は，インターネットシステムの持つ柔軟性が引き金となり，従来からの企業システム

構築における重要課題への取り組みをより現実的なものにしている。インターネット

は，社外とのネットワークとして格別の存在であるが，実際のシステム利用では，企

業内システムで利用されている場合の方が多い。

• ビジネスプロセス最適化

企業部門の統廃合や，担当業務や扱い商品の拡張に対しては，迅速に企業シス

テムを対応させることが求められる。また企業システムの運用コストを低減化す

るために，常に企業全体の効率化を目指して，システムの機能分担や運用法を見

直す必要がある。インターネット(社内ではイントラネットと呼ぶ)を用いれば，

部門システム間の接続を再構成することが容易である。

また，新しい部門システムを短期に開発することも可能である。ビジネスプロ

セス再構築においては，初期の設計も重要だが，それ以上に次々に発生する案件

に対して拡張する，もしくは運用しながら改善していくことが重要である。こう

した継続的開発の効率の上でもインターネットシステムの適性が注目されている。

• 情報共有

顧客情報，商品情報，生産情報などを社内で共有し，各部門での業務の品質改

善，効率向上を図る上で，インターネットの利用が効果的である。部門間におい

てこれらの情報の形式と登録法を統一化して，各部門システムで情報を共通的に

利用する。XML を用いた文書の定義，保存，授受の機能を有効に利用すること

ができる。情報共有の効果を上げていくには，新たな情報を容易に登録すること

や，運用しながら登録や利用の方法を改善していくことが重要であるが，インター

ネットと XML 文書を用いることで，柔軟に改良していくことが可能である。

(3) 社外ネットワークの強化

企業システムの新たな機能として，インターネットによる顧客や取引先との情報交

換，もしくは顧客や取引先の候補に関する調査や問い合わせチャネルの強化が進めら

れている。

28

1.3 ビジネス仕様標準化へのアプローチ

• 個客管理

顧客それぞれの購買に関する商品分野横断での履歴，問い合わせや催し物への

参加など関心の動向，案内状など販売促進履歴，性別，年齢など知り得る基本属

性等を収集し，個人別の販売促進を実行していく。顧客 1 人 1 人の個人に焦点を

当てることから，「個客」という呼び方がたびたび用いられる。個客に関するあ

りとあらゆる情報を集める手段として，インターネットが有効に利用される。

• コミュニティ形成

Web サイトを通じた情報交換により，顧客や取引先の組織化を図ることができ

る。または顧客候補や当該商品の市場全体にわたるグループ，または取引先候補，

業界全体にわたるグループとの交流促進を図る。Web によって，企業や商品の紹

介や利用者からの問い合わせと回答だけではなく，利用者間での幅広い，当該商

品以外の話題を含む情報交換を活性化する。こうしたコミュニティ作りにより，

顧客や取引先にとって企業をより身近な存在とし，需要を早期に摘出することを

容易にしていく。

1.2 インターネットによるシステムインテグレーション

1.2.1 基幹システムへのインターネット導入

(1) 基幹システムとインターネット

企業の多くの部署においては，インターネットの登場以前からコンピュータシステ

ムによる業務の自動化や支援が実施されている。ホストコンピュータやクライアン

ト・サーバ・システムを用いた，いわゆる基幹システムである。

基幹システムは，多くの投資と時間をかけた資産であり，多くの企業において業務

の屋台骨を支えている。インターネット上の Web システムがネットワーク社会との

コミュニケーションを実現する「自由」の手段とするならば，基幹システムは固いシ

ステムであるが，定められた計算を確実に実行する「信頼」の手段である。インター

ネットが登場した現在においても，基幹システムの有効な機能の継続活用が強く望ま

れている。そこで，企業システムにおけるインターネット利用を進める上では，基幹

システムと Web システムとの連携が大きな課題となる(図 1.4)。

29


経営環境の激しい変化経営環境の激しい変化

Web

様々な個人活動支援ネットワークの自由度

早く！安く！柔軟に！

何を見せるか？

どう使うか？

連携の実現連携の実現

経営環境の激しい変化経営環境の激しい変化

Web

様々な個人活動支援ネットワークの自由度

早く！安く！柔軟に！

何を見せるか？

どう使うか？

連携の実現連携の実現

システムの安全重視改造困難な固い構造システムの安全重視改造困難な固い構造

データ

処理

インタフェース

基幹システム

データ

処理


基幹システム

図 1.4 基幹システムと Web の連携

インターネットシステムの構築を，従来の基幹システムの側から，インターネット

の導入という視点で考察する。

(2) インターネット時代の企業システム計画

基幹システムの再構築や全般にわたる改造を推進するためには，企業全体の支援か

らの計画作業(企業システム計画)が必須である。企業システム計画においては，イン

ターネット普及と同時に進行する企業経営環境の変化を十分考慮した調査計画が必要

である。

インターネットを導入した業務システムでは，事業環境の中でも特に顧客の動向に

注意が必要である。Web 画面では，他社の製品と機能や価格の比較が容易であり，他

社製品購入に切り替えることも容易である。企業は，顧客に対して，常に魅力ある商

品を個客へのサービスも含めて提供しなければならないし，ホームページも快適でな

ければならない。企業は，Web システムを顧客の確保のために作成するが，次の段階

では顧客の交渉力増大となって企業の脅威となる。企業は常に対策しなければならな

い(図 1.5)。

30


同業者間の競争・価格を随時下げやすい・商品拡大が容易

買い手の交渉力・機能や価格の比較が

容易・他社切り替えが容易

新規参入者の脅威・開発投資が少なくて済む・グローバル参入容易

代替手段の脅威・標準化とデファクト

製品による席捲

同業者間の競争・価格を随時下げやすい・商品拡大が容易

買い手の交渉力・機能や価格の比較が

容易・他社切り替えが容易

新規参入者の脅威・開発投資が少なくて済む・グローバル参入容易

代替手段の脅威・標準化とデファクト

製品による席捲

売り手の交渉力・情報仲介者の台頭売り手の交渉力・情報仲介者の台頭

図 1.5 インターネット導入業務の経営環境 (5 フォース分析による)

インターネットを導入した業務において，標準化は大きな脅威である。顧客は比較，

代替が可能で発展性のある標準仕様製品を好む。標準化の進行は，市場のシェアに激

変を生じさせる。このため，インターネットシステムは，常にビジネス標準化の動向

に注意し，できるだけ早期に標準化に対応することが求められる。また，自らの仕様

をオープンにし，標準化への影響力を維持することが望ましい。

インターネットが導入された企業システムにおいては，計画手順にも従来との違い

が生じている。従来の企業システム計画手順では，通常，①自社の現状業務を確認し

た上で，②事業環境を確認し，③戦略を立案し，④システムを計画し開発を進められ

ていた。インターネット時代の大きな変化の 1 つは，①と②の手順が逆になる傾向で

ある。顧客動向や標準化など目まぐるしく変化する事業環境の中で，自社の本業や組

織，従来からの業務手順に捉われることなく，その時点の環境と将来予測に従って自

社の業務を見直すことが求められている。

もう 1 つの大きな変化は，企業システム開発を 5 年～10 年のライフサイクルで捉え

て調査～分析～計画を順に進めてきたものが，常時並行して実施する傾向に変わりつ

つあることである。事業環境は目まぐるしく変化し，常時監視しなければならない。

自社の取るべき戦略を一度の調査分析で明確化することは難しく，①～④のシステム

開発およびそれに基づく事業推進と並行しながら，いわば走りながら小刻みに策定し

ていくことが必要となっている(図 1.6)。

31


自社現状確認

環境変化の確認

戦略立案選択

環境確認

自社確認

戦略立案

計画実行

従来の計画手順

変化１：事業環境指向

環境確認

Web時代の計画手順

変化２：常時監視反映

自社現状確認

環境変化の確認

戦略立案選択

環境確認

自社確認

戦略立案

計画実行

従来の計画手順

変化１：事業環境指向

環境確認

Web時代の計画手順

変化２：常時監視反映

計画実行計画実行

自社確認

戦略立案

自社確認

戦略立案

図 1.6 インターネット導入による企業システム計画手順の変化

1.2.2 インテグレーションの形態

基幹システムと Web システムとの統合(インテグレーション)を進める上では，経営

環境の激しい動きに対応するため，「早く」「安く」「柔軟に」実現することが求め

られる。基幹システムから Web へ何を見せるか，あるいは Web から基幹システムを

どう使うかの設計には，企業として一定の基準が必要となる。このような課題に対応

するインターネット連携の汎用方式として， EAI(Enterprise Application

Integration)と呼ばれる方法がある。EAI には，以下の 3 つのアプローチがある(図 1.7

参照)。

① データ統合型 EAI

基幹システムに含まれるデータと Web システムのデータを連携させる。連携の仲

介として，データ分析のための倉庫であるデータウェアハウス(Data Warehouse)を用

いることもある。基幹システムと Web システムもしくはデータウェアハウスのデー

タ連携の実現に際しては，ETL(Extract Transform Load)と呼ばれるツールがしばし

ば用いられる。

32


② サービス統合型 EAI

基幹システムのサービス(大機能やサブシステム)に注目し，サービスを実行するア

プリケーション・インタフェースを含むオブジェクトを作成して，オブジェクトを介

して Web システムと連携する。オブジェクトでは，単にアプリケーション・インタ

フェースを呼び出すだけではなく，基幹システムの持つ固有の機能を抽象化して，様々

な Web システムから汎用的に利用できるようにする。

③ プロセス統合型 EAI

基幹システムのプロセス(処理過程)に注目し，プロセスを実現するモジュールを単

位として Web システムのモジュールと組み合わせて業務システムを実現する。モ

ジュールの組み合わせに際しては，ワークフロー基盤をしばしば利用し，ビジネスプ

ロセスを単位としたフロー制御を実現する。

データ

データ

処理処理



基幹システムビジネス

オブジェクト

接続部品

アダプタ

接続部品

アダプタビジネス

オブジェクト

サービス統合型 EAI

プロセス統合型 EAI

ポータル

画面要素

画面要素

ビジネスプロセス定義

データ

データ

処理処理



基幹システムビジネス

オブジェクト

接続部品

アダプタ

接続部品


オブジェクト

サービス統合型 EAI

プロセス統合型 EAI

ポータル

画面要素

画面要素


データ統合型 EAIデータ統合型 EAI

DWHDWHETLETL

図 1.7 インターネットシステム連携の汎用方式ーEAI の体系およびポータルー

3 つのアプローチの中では，対応付けの分かりやすさや基幹システムからの接続の

容易さから，データ統合型 EAI が最も普及している。次章以降で述べる XML による

標準化も，多くはデータの標準化である。続いて普及しつつあるのがサービス統合型

EAI である。汎用性の高いオブジェクトの設計には熟練を要するが，Web サービスと

しての実現に期待が集まっている。プロセス統合型 EAI は最も一貫性の高い形態であ

り，ビジネスプロセスと対応するモジュール機能が確立されている成熟した分野に適

している。

33


④ ポータル

より進んだ Web システムにおいては，Web 画面同士の連携が求められる。Web 画

面同士の連携の作成法としてポータル(portal)が挙げられる。ポータルとは，Web に

おける情報の玄関であり，企業における情報共有の玄関を構築する場合には

EIP(Enterprise Information Portal)と呼ばれる。EIP では，業務担当者が情報入手の

ために必要とするいくつかの Web 画面を呼び出すための画面を設ける。もしくは，

必要とする Web 画面のうちの画面要素(portlet)を取り出して，必要な画面要素だけを

組み合わせた新たな画面を提供する。

EIP におけるユーザ中心のインタフェース統合の考え方を，システムインテグレー

ションに応用することができる。日立製作所が提案する EAP(Enterprise Application

Portal)では，Web の画面要素ではなく，画面要素を介してアクセスされるデータとそ

の参照・更新の操作を統合する。ユーザの業務に最適な画面を作成し，画面要素にデー

タ操作を割り当てていくことで業務手順を実現していく(図 1.8)。

ポータルの拡張：　表示の統合(EIP)　　→　　情報と操作の統合(EAP)

6月1日Portlet

APortlet

B

PortletC

AB

C

1600円

EIP画面

既存

既存

leap

既存

既存

新規

leap（EAP基盤＋開発環境）によるコンポーネント指向システム開発

ポータルの拡張：　表示の統合(EIP)　　→　　情報と操作の統合(EAP)

6月1日Portlet

APortlet

B

PortletC

AB

C

1600円

EIP画面

既存

既存

leap

既存

既存

新規

leap（EAP基盤＋開発環境）によるコンポーネント指向システム開発

EAP画面EAP画面

6月1日

1600円

6月1日

1600円

図 1.8 ポータルによるデータ操作統合 EAP(Enterprise Application Portal)

34


EAP を実現するための基盤として，leap(light-weight EAP)が開発されている。

leap は開発環境と実行基盤を有する。leap 開発環境は，Web 画面の開発ツール上

で，データ操作の統合を編集する機能である。つまり，既存の画面の画面要素に割り

当てられたデータ操作をオブジェクトとして取り出し，それを体系的に管理すること

ができる。さらに，新たに作成された画面の画面要素にデータ操作オブジェクトを適

用するためのマークを付ける。以上の操作はすべてプログラムレスで可能としている。

leap 実行基盤は，画面が操作されるたびにマーク付けられたデータ操作を呼び出して，

データ操作の統合を実現している(図 1.9)。

開発環境：プログラミング・レスで

既存データのマーク付けを定義

Web画面上から既存データを対応付けWebの統合

leap基盤: マ

の自動対応付

ーク付けしたデータ

けを実現

ＥＡＰ開発環境

ＨＴＭＬエディタによる定義ファイルの作成

受注アプ

開発環境：プログラミング・レスで

既存データのマーク付けを定義

Web画面上から既存データを対応付けWebの統合

leap基盤: マ

の自動対応付

ーク付けしたデータ

けを実現

ＥＡＰ開発環境

ＨＴＭＬエディタによる定義ファイルの作成

受注アプ

ＥＡＰ実行環境

在庫管理アプリケーション

管理リケーション

ＥＡＰエンドユーザWebブラウザ

データ抽出プログラム

データ統合プログラム


ＥＡＰ実行環境

在庫管理アプリケーション

管理リケーション

ＥＡＰエンドユーザWebブラウザ


データ統合プログラム


図 1.9 leap(light-weight EAP)開発環境と実行基盤

EAP によるインテグレーションでは，情報処理の基本となるデータやプログラムを

そのままにしたまま，操作画面だけを統合する。したがってインテグレーションによっ

て実現可能なことは限定されるが，開発のほとんどを GUI 環境においてプログラムレ

スで可能である。より速い変更速度を求めるインターネット・ビジネスシステムのスー

パーユーザにとって有効な機能と考えられる。また，多数の適用サイトを抱えるイン

ターネット・ビジネス・パッケージのシステムエンジニアにとっても，ユーザごとの

画面仕様の調整作業を効率化するツールとして有用と考えられる。

35


1.2.3 インテグレーションのための設計技術

基幹システムと Web システムのインテグレーションを実現する上では，下記のよ

うな設計技術が本質的である(図 1.10)。

データ

データ

処理処理



基幹システム


ビジネスオブジェクト

接続部品

アダプタ

接続部品


オブジェクト

コンポーネント設計（再利用資産形成）

データ

データ

処理処理



基幹システム


ビジネスオブジェクト

接続部品

アダプタ

接続部品


オブジェクト

コンポーネント設計（再利用資産形成）

リエンジニアリング（既存資産再生）

リエンジニアリング（既存資産再生）

DWHETL DWHETL

図 1.10 インテグレーションのための設計技術

ーコンポーネント設計と既存資産再生ー

(1) コンポーネント設計

コンポーネント(component)とは，オブジェクト指向でいうオブジェクト(object)の

別称である。オブジェクトと呼ばれる設計モデルやプログラム単位の中で，比較的大

きな粒度(大きさ)のものを指すことが多い。

コンポーネント指向設計は，ソフトウェアの保守性，再利用性を高めるためのソフ

トウェア設計法である。コンポーネント指向(オブジェクト指向)にはいくつかの特徴

があるが，第一に基本的な特徴はカプセル化である。カプセルとは，関係の深いプロ

グラムとデータを収納する単位である。コンポーネント指向以前の設計法，例えば構

造型設計ではプログラム・モジュールを構造化するが，各モジュールでは様々なデー

タを参照する場合がある。逆にデータ中心設計では，データ構造は整然とされるが，

それぞれのデータを参照するモジュールは交錯する場合がある。そのため，保守時に

36


おいて，変更箇所が拡散し，分析，設計，テストの負荷が大きくなりがちである。そ

こで，業務の観点で関係の深いプログラム・モジュールとデータをコンポーネントと

いうカプセルにまとめる，コンポーネントを単位として，保守作業の局所化とソフト

ウェアの再利用を図ることができる(図 1.11)。

コンポーネント

データ

ﾌﾟﾛｸﾞﾗﾑ

データデータ




データ

データ

データ

ﾌﾟﾛｸﾞﾗﾑﾌﾟﾛｸﾞﾗﾑ

データ


データデータ


データとプログラムを業務の単位でカプセル化

１つあちこち

１つのプログあちこち

◇ 保

◇ 再利

◇ 業

のデータを変更するのにのプログラムの変更が必要

ラムを変更するのにのデータの変更が必要

守・拡張がしやすい

用しやすい

務としても分かりやすい

◇ 保

◇ 再

◇ 業


従来技法の


利用しやすい


課題


データ


データデータ




データ

データ

データ


データ


データデータ


データとプログラムを業務の単位でカプセル化

１つあちこち

１つのプログあちこち

◇ 保

◇ 再利

◇ 業

のデータを変更するのにのプログラムの変更が必要

ラムを変更するのにのデータの変更が必要


用しやすい


◇ 保

◇ 再

◇ 業


従来技法の


利用しやすい


課題

図 1.11 コンポーネントの基本概念ーカプセル化ー

EAI によるインターネット・インテグレーションにおいて，コンポーネント設計は

共通的に必要とされる技術である。

サービス統合型 EAI では，連携のためのオブジェクトを設計する。呼び出すべき

サービス機能と呼び出しに用いる変数のほか，変数の調整のための補足処理，サービ

スの結果と結果に対する補足処理などを一かたまりのオブジェクトとして設計する。

これらの補足処理は，サービス機能をなるべく汎用化するための調整である。また，

類似したサービスは 1 つのオブジェクトにまとめて，利用者にとって分かりやすい分

類体系を実現する。これらは正しくコンポーネント設計である。

データ統合型 EAI では，連携の仲介となるデータ・スキーマを設計する。仲介とな

るデータ・スキーマは，多くの基幹システムや Web システムのデータとの対応付け

37


を容易にするという観点から，サービス統合型のオブジェクトと同様に汎用性を与え

る設計が必要である。論理データ設計と呼ぶ場合もあるが，データ的要素の強いコン

ポーネント設計と位置付けることができる。

プロセス統合型 EAI では，業務過程処理を実行するモジュールを，接続部品を介し

て呼び出す。接続部品の設計では，モジュール呼び出しを汎用化し小規模かつ少数の

部品で実現することが求められる。接続部品は技術的要素の強いコンポーネント設計

と位置付けられる。

これらのコンポーネントの保守性や再利用性を確保するためには，開発したコン

ポーネントを継続的に管理し，保守や継続開発の技術者全般にわたって，コンポーネ

ント群の役割，機能，制限事項等の情報を共有する必要がある。情報共有の体系，運

用法，ツールなどが基本技術として求められる。

コンポーネント設計は，1980 年代からオブジェクト指向の考え方に基づく言語

(Java，C#など)や分散処理基盤(J2EE, .NET など)の発展に伴って普及してきた。1990

年代からは UML(Unified Modeling Language)という設計文書のための標準記述方

式も一般化し，現在ではベンダ各社において，UML を用いた開発手順やフレームワー

ク(コンポーネント処理の共通的枠組み)が整備されている(図 1.12)。

構想要求基本設計詳細設計計画

企業再構築計画支援

コンポーネント保守管理・洗練化

コンポーネント型EAI設計（システム連携）

開発手順設定運用

コンポーネント抽出・再利用設計

フレームワーク適用

コンポーネント指向システム設計（大規模開発向け/ 中規模開発向け）

設計

EAPポータル設計（インタフェース中心データ連携）

企業システム資産管理

構想要求基本設計詳細設計計画

企業再構築計画支援

コンポーネント保守管理・洗練化

コンポーネント型EAI設計（システム連携）

開発手順設定運用

コンポーネント抽出・再利用設計

フレームワーク適用

コンポーネント指向システム設計（大規模開発向け/ 中規模開発向け）

設計

EAPポータル設計（インタフェース中心データ連携）

企業システム資産管理

実装実装

図 1.12 コンポーネント設計技術体系の例

(日立製作所のコンポーネント設計技術サービス体系)

38


コンポーネントによる設計対象のモデリングは，ソフトウェアの本質的設計作業で

あり，常に手ごわい仕事である。利用者観点(ビジネス観点)から近接した機能とデー

タを全体から切り出していくことの難しさは，開発手順や設計技法だけで乗り越える

ことはできない。むしろインターネットシステムにおいて対象システムと関与者の範

囲が拡大するにつれ，設計者に与えられる課題はますます大きくなっている。

(2) 既存資産再生

基幹システムの多くは，ホストコンピュータ上で動作する古いシステムであり，し

ばしば設計ドキュメントが散失している場合がある。存在しても度重なる改変のため

現行システムと内容が一致していない場合も多い。こうした基幹システムの管理実態

を踏まえて既存資産を再生するには，ソースプログラムなどからプログラム仕様を回

復し，それをもとに既存システム資産の再利用判定とデータ連携設計を進める必要が

ある。

業務データ処理条件表

DORE（Data Oriented Re-Engineering)

既存システム各種仕様書，運用マニュアル等

手作業による仕様情報の調査に比べ，３～１０倍の生産性の実現


コンソールメッセージ

JCLカタプロ

DB定義COPY句

プログラムCOBOLNatural

ワーク

シス･プログ @

人事給与年齢別給与支

処理･

入出･

項入出･種Ｉファ･1 CAGEJYLST 帳出 CAGEJYLST

2 CCKMKYUYO ファ入 CCKMKYUYO

サブプログラム

項ｻﾌ゙ﾌ゚ﾛｸ゙ﾗﾑ/ﾃーﾌ゙ﾙ2 データ1 'YMDCHK' W-HIZUKE-1

2 'DATACHK' I-SHAIN-NO

3 作業用テー KYUYOLST

作日作成

承 2001/8/2

プログ@ パタ･

EC202

概ＪＣ･

コピ外部･ｱｸｾｽﾓーﾄ゙接ﾍSYSPRINT S

CCKMKYUY SYS007 S I-

説

プログラ h

EC202 年齢別給与支

CCKMKYUYO

CAGEJYLST

プログラム処理概要図

ＤＯＲＥ（Data Oriented Re-Engineering）の機能により，最新仕様情報を高品質でリバース出力


業務データ単位で詳細設計情報を回復させることでプログラムに埋め込まれた業務ルールを抽出

業務データ単位で詳細設計情報を回復させることでプログラムに埋め込まれた業務ルールを抽出業務データ処理条件表

DORE（Data Oriented Re-Engineering)

既存システム各種仕様書，運用マニュアル等



コンソールメッセージ

JCLカタプロ

DB定義COPY句

プログラムCOBOLNatural

ワーク



処理･

入出･







作日作成

承 2001/8/2


EC202

概ＪＣ･



説

プログラ h


CCKMKYUYO

CAGEJYLST

ワーク



処理･

入出･







作日作成

承 2001/8/2


EC202

概ＪＣ･



説

プログラ h


CCKMKYUYO

CAGEJYLST

プログラム処理概要図





主な仕様情報

プログラム設計補足説作日

（処理条件ﾍ承

補足･出力残業プログラ h

項条件ま @ 判定条件と1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

1 職給コード OF 新人事給E T2 職給コード OF 新人事給E T3 職給コード OF 新人事給E T4 職給コード OF 新人事給E T5 職給コード OF 新人事給E T6 COMPUTE 残業手当 = 残業時･ E7 COMPUTE 残業手当 = 残業時･ E8 COMPUTE 残業手当 = 残業時･ E9 COMPUTE 残業手当 = 残業時･ E10 COMPUTE 残業手当 = 残業時･ E

ジョブフロー図

データフロー図

・・・・

・・

主な仕様情報




項条件ま @ 判定条件と1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20





項条件ま @ 判定条件と1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20


ジョブフロー図

データフロー図

・・・・

・・

図 1.13 プログラム仕様再生ツールの例ー日立製作所の DOREー

39


基幹システムにおいて調査すべき既存資産の量は巨大である。そこで，プログラム

仕様回復作業をツールによって機械化することがポイントとなる。例えば，日立製作

所の DORE(Data Oriented Re-Engineering)では，JCL，COPY 句，DB 定義，コン

ソール・メッセージなどから，データフロー図，ジョブフロー図，プログラム処理概

要図，業務データ処理条件表などのプログラム仕様書を回復している。業務データ単

位に詳細設計情報を回復し，業務ルールと呼ばれるデータ関連の多くを抽出すること

ができる。こうしたプログラム仕様書だけでは，対象モジュールの機能やデータを完

全に解析することはできないが，仕様調査作業を大いに効率化することができる。前

述の DORE の例では，手作業に比べて 3～10 倍の作業効率向上が謳われている(図

1.13 参照)。

40

ビジネスシステムと インターネット ·...

Documents

ビジネスシステムとインターネット ·...