全文 - 東芝ソリューション株式会社

< 企業統合におけるシステム統合 >
～ IT 技術からみたシステム統合への取り組み～
I T 技術研究所 戦略企画担当 参事　守安　隆
I T 技術研究所　研究開発担当　主務　吉田　和樹
企業統合・ 組織再編が進むなかで， システム統合をいかに進めるかが重要な課題になっています。 本稿では， システム統合を
成功に導くための取り組みとして， リスクの管理，EAの策定，及び SOAの導入について説明します。 リスクの管理では， 統合に
かかわるリスクを評価し， コントロールするための仕組みを確立します。 また，EAの策定を通して， 業務とシステムの理想のアー
キテクチャを明確化し， 統合後も， 理想像に向けて継続的に改善を図ることで， 業務とシステムの整合性を維持します。 そして，
SOAの導入により， 継続的な改善に伴って生じる各種の変更要求に柔軟に対応できるように， システムを構築します。
１． システム統合を成功に導くために
くための基礎になります。
日本企業による M&A の件数は 1993 年以後ほぼ右肩
上がりで増加を続け，2006 年 1－6 月には 1409 件と半
金融庁が 2002 年 12 月に公表した 「システム統合リス
ク管理態勢の確認検査用チェックリスト」 [3] は， システム
統合リスクの管理について検討する際に， 重要な着眼点
期ベースで過去最高を記録しました [1]。 このように企業統
合 ・ 組織再編が進むなかで， 業務とそれを支える情報シ
ステムの統合をいかに実現するかが重要な課題になってい
ます。 CIO や情報システム部門にとって， システム障害
発生への対策は万全か， 現行システムからの移行を順調
に進められるか， 業務効率の低下や保守 ・ 運用費の増大
を招かないか， 統合後のシステムの性能・可用性・信頼性 ・
セキュリティを保証できるか，などは大きな懸念事項でしょう。
本稿では， これらの懸念を払拭 （ふっしょく） し， シス
テム統合を成功に導くための取り組みについて紹介しま
す。 このような取り組みは，大きく次の 4 点に分類できます。
① 統合にかかわるリスクを評価し， コントロールするため
の管理上の仕組みを確立すること
② 統合後にも業務とシステムの整合性を維持できるように，
アーキテクチャを確立すること
③ 統合時， あるいは統合後に生じる各種の変更要求に
柔軟に対応できるように， システムを構築すること
④ 統合後のシステムに対する非機能要件を明確化し， そ
の要件を満たすように， システムを構築すること
これらの中で， 本稿では， 分類①～③の取り組みにつ
いて， それぞれ第 2 節， 第 3 節， 第 4 節で説明します。
分類④については， 特集記事 3 で説明します。　２． リスク管理で障害の発生を防止
2002 年 4 月に発生した某金融グループでのシステム
障害について， 金融庁は， その後の立入り検査から， “根
本原因は， 旧経営陣がシステム統合に係わるリスクを十分
認識していなかった”と指摘しました [2]。 このことは，逆に，
リスクを十分に認識し， それをコントロールできていたなら
ば， 障害の発生は未然に防げていた， あるいは， 障害
の影響は最小限に抑えられていたかもしれないことを意味
しています。
システム統合にかかわるリスクは，IT ガバナンスの活動
のなかで体系的に検討されるべきものです。 検討の結果
導入される管理上の仕組みは， システム統合を成功に導
を示すものとして金融機関で利用されています。 リスクの
認識とその管理態勢の整備を中心に， 統合前の状況を確
認する質問で構成されています。 更に， 文献 [4] には，
一般の事業会社でもこのチェックリストを利用できるように，
リストに対して項目を追加 ・ 変更したものが示されています。
３． EA 策定で業務とシステムの整合性を維持
企業間や組織間でシステムを統合する場合には， 前提
としている業務の内容やシステム上の取り決めに差異があ
るのが普通です。 統合のきっかけが買収や吸収合併の場
合には， システムの統合は， 一方を採用して他方を廃棄
するという， 強引ではありますが， 差異による問題が比較
的起こりにくい方式 ( 吸収型 ) で進めることになります。 し
かし， 対等合併の場合には， 双方のシステムの良いとこ
取りをする方式 ( 組合せ統合型 ) か， 一方のシステムを
基盤システムとして， 他方のシステムのうち必要不可欠と
考えられる機能だけを基盤システムに追加する方式 ( 片寄
せ統合型 ) で進めることになります。 差異はこのときに顕
在化します。 そして， もし統合のための準備期間が短け
れば， その差異に継ぎはぎ的な対処策を施して， 急場を
しのぐことになります。 継ぎはぎは， 往々にして， 作成し
た本人にしか理解できない属人化した処理モジュールとし
て， システムを硬直化させる原因になります。 このような
継ぎはぎが重なると， やがて， 業務とシステムの整合性
は崩れていきます。
企業間や組織間でのシステム統合では， 対象とすべき
業務とシステムが多数存在しており， 業務とシステムの整
合性を維持するためには， 業務 ・ システム群を俯瞰 （ふ
かん） する一段高いレベルでのアーキテクチャの分析 ・
設計作業が求められることになります。
このような作業を支援するための体系的な手法として，
最近利用されるようになってきたのが， EA です。 この手法
では， 業務とシステムの現状のアーキテクチャを， 各種図
表類を使って可視化します。 次に， 業務とシステムに対
4
「東芝ソリューション テクニカルニュース」2006年（秋季号）
本稿では， システム統合を成功に導くための取り組みと
する理想のアーキテクチャを作成します。 その際，例えば，
企業間や組織間で業務 ・ システムの重複を排除し標準化
や集中化を図るなど， 全体最適の観点から理想像を考え
ます。 それと併せて， 業務とシステムの整合性にも十分
に留意します。 そして， 現状と理想像が明らかになったな
らば， それらの間のギャップを埋るため， 現状から理想像
への移行の進め方を計画としてまとめます。
今後， 企業間や組織間でのシステム統合では， 継ぎ
して， リスクの管理， EA の策定， SOA の導入　につい
て説明しました。 そのほかに， 第 1 節で挙げた分類④の
非機能要件についても， これまでに各種技術 ( 性能管理，
クラスタリング， など ) が研究 ・ 開発されてきました。 これ
らの中で， セキュリティリスクに備えるための当社のソリュー
ションを， 特集記事 3 で説明します。
今後， 企業統合 ・ 組織再編の本格化に伴い， システ
ム統合に関するこれらの取り組みの重要性は， ますます高
まっていくことと考えます。
はぎ的な対処策を施すのではなく， この EA の手法に則っ
て， 理想のアーキテクチャを明確化し， 移行計画に基づ
いて， 統合後も継続的に改善を行っていくようになると考
えます。　４． SOA 導入で変更に柔軟に対応
( 注 1) SOA について， 「特集記事 4」 で更に詳しく説明しています。 あわ
せてご参照ください。
継続的に改善を行っていくためには， 各種の変更に柔
軟に対応できるようにシステムが設計されている必要があり
【参考文献】
[1] NIKKEI NET 2006年7月3日付けニュース記事, ”日本企業，M&A件数・
額とも最高・1-6月” .(オンライン),入手先
<http://www.nikkei.co.jp/news/sangyo/20060702AT2D3000Z30062006.
html>, (参照2006-08-31)
ます。 そのために，最近注目されているのが，SOA です。
SOA とは， 独立したソフトウェアの機能 ( 「サービス」 と
呼ぶ ) を組み合わせてシステムを構築する設計手法です。
[2]金融庁, “みずほフィナンシャル・グループに対する行政処分について” .
(オンライン),入手先
<http://www.fsa.go.jp/news/newsj/13/ginkou/f-20020619-1.html>,
(参照2006-08-31）
SOA では， サービス間の依存性を排除するように個々の
サービスを設計し， 機能の利用 ・ 提供は， インタフェース
を介して行います。 それにより， サービスの組み合わせ
や組み替えを容易に行えるようにします。
[3] 金融庁 , “「システム統合リスク管理態勢の確認検査用チェックリストに
ついて」 通達の発出について” .( オンライン ), 入手先
<http://www.fsa.go.jp/news/newsj/14/f-20021226-6.html>,
( 参照２006-08-31）
SOA という言葉自体は， 10 年程前から存在していまし
た [5]。 しかし， 最近になって注目されるようになったのは，
ビジネス環境の急激な変化のほかに， Web サービスなど
のシステム間相互接続の標準技術が確立されたことにより
[4] 島田裕次 , “IT ガバナンスとシステム統合” , 経営情報学会システム統
合特設研究部会 [ 編 ]: “成功に導くシステム統合の論点” 第 5 章 ,
日科技連 ,2005.
ます。 Web サービスとは， “標準インターネットプロトコル
上で XML 形式のメッセージを送受信してシステムを連携
させる技術体系”のことです [6]。 Web サービスの登場以来，
様々な種類のプラットフォームが Web サービスに対応しま
した。 そして， プラットフォーム
に依存することなく， システムどう
しを連携させることができるように
業務・
システムの現状
なりました。 このような Web サー
ビスの普及が， SOA の考え方を
有意義なものとして現実化したの
です。
EA で策定した理想像への移
行においては， ビジネス上の優
先度や技術的な難易度， 予算
的な制約などから， 移行を段階
的に実施するのが一般的です。
また， 移行作業の中では， シス
テム間の連携部分に対する変更
が大きな割合を占めます。 した
がって， 移行の際に， SOA を
導 入 し て シ ス テ ム を 再 設 計 し，
Web サービスで実装することは，
移行の各段階で生じる変更要求
への柔軟な対応を可能にし， 移
行をスムーズに進めるためのソ
リューションになるのです。
（注 1）
[5] Yefim V. Natis， “Service-Oriented Architecture Scenario”，
オンライン， 2003 年 4 月 16 日， 入手先
<http://www.gartner.com/DisplayDocument?id=391595>，
( 参照 2006-08-31)
[6] 西澤秀和， 早瀬健夫， 矢野令， 山田正隆， 山本純一， “Web サービ
ス分析 ・ 設計ガイド”， ソフトバンクパブリッシング， 2002 年 12 月 28 日
理想のアーキテクチャ
現状のアーキテクチャ
ビジネス アーキテクチャ
（例：業務プロセスフロー図）
予算機種
変更要？
設
計
No
製番仮登録
照会
Yes
製番更新
ＰＪ情報
設定
予算機種
設定
企
画
完
成
計
上
ECHO
-PMS
本社
No
Yes
製
造
シ
ス
テ
ム
ＰＪ管理
対象？
発番情報
（事）
ECHO
PMS接続
平日9:00~22:00
で
１時間毎のバッチ
製番
プロジェクト
データ アーキテクチャ
（例：データモデル図）
各業務・システムで利用される
情報とそれらの関連を
体系的に整理
可視化
データ
アプリケーション
システム
アプリケーション
アーキテクチャ
（例：システム間連携図）
テクノロジ アーキテクチャ
工場
対象とする業務の内容，組織，
業務の流れ，などについて，
対象とする業務の内容，組織，
体系的に整理
物流拠点
（例：ネットワーク構成図）
移行計画
の
現状の業務処理とシステムの
現状の業務処理とシステム
機能を対応付けて 体系的に 整
体系的に整理
システム構築の際に利用する
システム構築の際に利用する
技術的な構成要素（ハードウェ
技術的な構成要素（ハードウェ
ア，ソフトウェアなど）を
体系的に整理
移行
図1．SOAに基づいたシステムの構成要素
業務とシステムの現状を，ビジネスアーキテクチャ，データアーキテクチャ，アプリケーションアーキテクチャ，
テクノロジアーキテクチャの四つの側面から可視化して，全体最適の観点から将来的な理想像を作成します。
「東芝ソリューション テクニカルニュース」2006年（秋季号）
5