システム統合とは何か
システム統合の対象には，アプリケーションとシステム基盤の二つがある。 適切に統合することで，「機能重複」「運用品質の低下」などの課題が解決できる。 システムの統合と移行について，まずは基本的な考え方を押さえる。 第1部では，システムを統合/移行するためのノウハウを解説す る。統合/移行の対象には，アプリケーションとシステム基盤があ るが，本書では後者に注目する。システム基盤の品質低下が，シス テムの安定稼働を妨げていると考えるからだ。システム基盤のカバ ー範囲は，サーバー機やOS，DBMSとったミドルウエアである。 第1部では，「1章 システム統合とは何か」で統合の概要を説明した 後に，「2章 システム統合の6レベル」「3章 システム統合の技術」で そのノウハウに踏み込む。システム移行のポイントは，「第4章 シ ステムの移行」にまとめた。 本章では，システム統合をアプリケーションとシステム基盤の両 面からとらえ，その概要を説明する。システム統合には様々なメリ ットがあるが，アプリケーションとシステム基盤のどちらを対象と するかにより，得られるメリットは異なる。ここで，システム統合 の全体像をつかんでおこう。 システム統合で七つの課題を解決 これまで多くの企業が，会計管理や受発注管理など特定の業務を システム化し，業務の効率化を図ってきた。こうした特定業務のシ ステム化が一巡した現在，さらなる業務効率の改善を目指したとき に，現場では様々な課題が浮かび上がってくる。 例えば，業務間連携の改善や，リアルタイムに業務の実施状況を 把握することが難しい。また，内部統制対応などの要望に応えるた めに，複数のシステムを見渡した全体最適の視点が必要になってき た。加えて，昨今の規制緩和やグローバリゼーションの流れに押さ れ，経営統合や，事業の再編と改革，分社化や企業間のアライアンス， M&Aなどが進み，一つの企業内に様々なシステムが混在する状況 が増えてきた。そうした状況を踏まえてシステムの全体最適化を考 えると，従来のシステム開発では問題になりづらかった，七つの課 題への対処が求められてきた（図1-1-1）。 （1）機能重複 機能や業務が複数システム間で重複しており，投資・維持効率が 悪いので，システム全体で整理することが必要である。 （2）業務改善の仕組みの不足 リアルタイムに業務の進捗状況などを把握し，問題点を把握する ことが難しい。 サーバー ネットワーク ハードウエア OS ミドルウエア アプリケーション サーバー ネットワーク ハードウエア OS ミドルウエア アプリケーション クライアント ❸ 業務の断絶 ❷ 業 務 改 善 の 仕組みの不足 ❶ 機能重複 ❻ 運用品質の低下 ❺ 危機管理対策 ❹ 異種プラットフォーム 乱立の弊害 ❼ 柔軟なリソースの 割り当て 図1-1-1●全体最適に向けた七つの課題（3）業務の断絶 異種プラットフォームの連携が難しいことに起因するシステム間 の断絶により，業務の効率や正確性が低下している。 （4）異種プラットフォーム乱立の弊害 乱立に伴い，開発効率や管理レベルの低下，TCO増加や調達コ ストの分割損＊1などが生じている。 （5）危機管理対策（ビジネス継続プランニング） 天災や人災の発生時にも業務を継続して実施するための仕組みが 求められている。 （6）運用品質の低下 手動復旧・自動復旧，クラスタ構成での切り替え方法など，統一 した障害復旧ポリシーがないシステムでは小さな障害から，事前に 把握できていなかった関連システムへの障害へと連鎖し，大規模な システム・トラブルが引き起こされる。 （7）柔軟なリソースの割り当て インターネット経由でコンシューマにサービスを提供する場合な ど，トラフィック量の状況に応じてリソースを柔軟に割り当てる必 要がある。 こうした課題への解決策として，「システム統合」の考え方が挙げ られる。システム統合とは，複数のシステムをスコープとして，ア プリケーションおよびシステム基盤の最適化を目指すものである。 また，戦略的に企業内のシステムを標準化し，組織の最適化を進め， 効率よくシステムを構築・運用するための考え方である。 アプリケーションの統合は，業務や組織単位で構築していたアプ リケーションの開発・保守を，フレームワークの導入やアプリケー A事業部 ミドル ウエア 共通部品 アプリケ ーション B事業部 ミドル ウエア 共通部品 アプリケ ーション C事業部 ミドル ウエア 共通部品 アプリケ ーション A事業部 ミドル ウエア ミドルウエア フレームワーク 共通部品 ミドル ウエア 共通部品 アプリケ ーション B事業部 共通部品 アプリケ ーション C事業部 共通部品 アプリケ ーション フレームワークの導入 事業部間で同一のフレームワークを用いることにより， アーキテクチャを統一し，部品の共通化を進める A事業部 ミドル ウエア ミドルウエア ミドルウエア アプリケ ーション B事業部 アプリケ ーション C事業部 アプリケ ーション アプリケーションの共有 アプリケーションの部品を共通化し，事業部間で共有する フレームワーク 事業部間でアプリケーション環境が異なる それぞれアプリケーション環境がそれぞれ異なるので， 保守コストや運用コスト，調達コストが増大してしまう 課題 図1-1-2●アプリケーション統合の概要 ＊1 分割損 システム・リソースを分割することによ って，利用効率が下がったり，調達 コストが上がったりすることを指す。
ション・アーキテクチャを統一することなどで効率化し，さらには 業務間・組織間でアプリケーションを共有することを目指す（前々 ページの図1-1-2）。 一方，システム基盤の統合は，アプリケーションが利用するサー バーやストレージ，ネットワーク，OSやミドルウエアなどを物理的・ 論理的に集約し，保守・運用・調達・アプリケーション開発に必要な リソース配分などを効率化することを目指す（図1-1-3）。 これら二つのタイプの統合を組み合わせて実施することにより， 統合されたシステム基盤上で，統合されたアプリケーションが実行 されることになり，システムを最適化できる。 先に挙げた七つの課題のうち，（1）〜（5）はアプリケーションを 統合する過程で整理し，（3）〜（7）はシステム基盤を統合する過程 で整理する（図1-1-4）。 こうした課題への対応は独立して行うのではなく，既存のIT資 産の活用や，進行中のプロジェクト計画などを勘案しつつ，実行す る必要がある。以下，それぞれの課題への解決策を説明する。 アプリケーション統合の考え方 アプリケーションの統合・移行についての課題と，その解決策の 一例を示す。 A事業部 ミドル ウエア アプリケ ーション B事業部 ミドル ウエア アプリケ ーション C事業部 ミドル ウエア ハード ウエア ウエアハード ハードウエア ネット ワーク ワークネット ワークネット OS OS OS アプリケ ーション A事業部 ミドル ウエア OS ミドル ウエア OS ミドル ウエア OS ハード ウエア ハードウエア ハードウエア ネット ワーク ワークネット ワークネット アプリケ ーション B事業部 アプリケ ーション C事業部 アプリケ ーション 論理的なシステム基盤統合 事業部間で同一のシステム基盤を用いることにより， 保守・運用・調達を集約する A事業部 ミドルウエア OS ハードウエア ネットワーク アプリケ ーション B事業部 アプリケ ーション C事業部 アプリケ ーション 物理的なシステム基盤統合 事業部間でシステム基盤を共通化し，アプリケーション をシステム基盤上で動作させることにより，保守・運用・ 調達を集約する 事業部間でシステム基盤が異なる システム基盤がそれぞれ異なるので，保守コスト や運用コスト，調達コストが増大してしまう 課題 図1-1-3●システム基盤統合の概要 主にシステム基盤 統合で解決する課題 両面で解決する課題 主にアプリケーション 統合で解決する課題 ❶ 機能重複 ❸ 業務の断絶 ❹ 異種プラットフォーム 乱立の弊害 ❺ 危機管理対策 ❷ 業務改善の 仕組みの不足 ❻ 運用品質の低下 ❼ 柔軟なリソースの 割り当て 図1-1-4●アプリケーションおよびシステム基盤の統合で解決する課題
【機能重複】 機能重複を整理する第一歩は，現在行っている業務を整理するこ とである。業務を整理する際には，様々なIDEF0規格＊2に準拠し たプロセス・モデリング，データフロー・ダイアグラム＊3などの業務 モデリング手法が適用されることが多い。その上で，それぞれのシ ステム上に実装されている業務機能を整理し，整理された業務との 対応関係を明確にする（図1-1-5）。 これらの作業により，重複している業務や機能が明らかになるの で，重複個所を集約すべきか否かを検討する。その際，業務的な観 点だけで集約を検討するのではなく，運用面や非機能要件への影響 も考慮して決定する必要がある。 【業務改善の仕組みの不足】 業務改善のための仕組みづくりには，「機能重複」で整理した業務 モデリングの結果を活用する。 まずは改善する目標を立てる。例えば，業務実施の期間を短縮す る，業務遂行量を増大させる，業務実施コストを下げる，などが挙 げられる。そしてその目標を達成するための指標を定める。例えば 注文から請求までのサイクルを短縮したい場合，それぞれのプロセ スにおける所要時間や業務の滞留量を算出する，などである。 次に，その指標をシステム的に取得するための方法を検討する。 リアルタイムであればイベントを発生させ，キャッチする仕組みを 検討し，リアルタイムでなければログを出力して集約する仕組みを 検討する。その仕組みを，システム基盤の統合の検討や，新規開発 /機能改修をする際に実装していく（図1-1-6）。 【業務の断絶】 業務の断絶を解消するために，「機能重複」で整理した，業務モデ リングとシステム上の実装との対応結果を活用する。ここではシス テムで実装できていない，つまり人手で実施しているアクティビテ ィに注目し，なぜ人手で行っているのか，その理由を把握する（次 ページの図1-1-7）。もしシステム的な制約の場合は，システム基 業務処理1 業務処理2 業務処理3 業務処理4 業務処理A 業務処理B 業務処理C 業務処理D 業務処理W 業務処理X 業務処理Y 業務処理Z 業務処理の共通化検討 業務処理の共通化 業務処理1 業務処理2 業務共通 処理❶ 業務共通 処理❷ 業務処理4 業務処理A 業務処理C 業務処理W 業務処理X 業務処理Y 図1-1-5●機能重複を整理するための考え方 ＊2 IDEF 0 IDEFはIntegrated DEFinition methodsの略。統合化のためのモ デリング手法の総称。米国商務省の 標準化機関であるNIST（National I n s t i t u t e o f S t a n d a r d s a n d Technology）によって1990 年代 初頭に標準化され，現在でも多くの 企 業 において 採 用されている。 IDEF 0は機能モデリングが対象で ある。 ＊3 データフロー・ダイアグラム
Data Flow Diagram（ DFD ）。 1970 年代，Tom Demarcoによっ て提案された構造化分析手法の一 部で，データの流れを中心に，プロ セスを分解し定義する手法。 業務処理1 業務処理2 業務処理3 業務処理4 現状の把握 改善策の立案/実行 ステータスなど モニタリング・ 分析システム 業務プロセスの改善 人的リソースの配置変更 システム・リソースの配置変更
…
図1-1-6●業務改善のための仕組みづくり盤の統合を検討したり，新規開発や機能改修をする際にその制約を 解消したりすることが必要になる。 システム基盤を統合する システム基盤の統合を進めることで，「業務の断絶」「異種プラッ トフォーム乱立の弊害」「危機管理対策」「運用品質の低下」「柔軟な リソースの割り当て」といった課題が解決できる。サーバー統合の パターンは以下の六つがあり，解決できる課題や効果が異なる。 （1）サーバーの設置場所を集約 データセンターなどにサーバーを集約配置することにより，運用 管理作業を集約して効率化を図る。 （2）きょう体の集約 ブレードサーバーなどきょう体レベルで集約化し，スペース効率 の向上や，ハードウエアの保守性の向上を図る。 （3）仮想化により物理きょう体を統合 複数のアプリケーションを同一のきょう体で動作させることによ り，物理的なサーバーの数を減らす。パーティショニング＊4や仮想 化技術＊5が用いられる。 （4）OSやミドルウエアを統一 OSやデータベースなどのミドルウエアを統一し，運用担当者に 求められるスキルを専門化させる。 （5）アプリケーションやデータの統合/連携 従来，データの手入力や，手動で連携させていたアプリケーショ ン間のやり取りをシステム化したり，散在するデータを統合したり して，一元管理する。 （6）管理レベルの集約や統合 それぞれのシステムで個別に決めていたサービスレベルを共通化 し，システム全体として品質を確保する。 システム移行の三つの理由 最後に，システム統合と併せて論じられることが多いシステム移 行について触れる。 システム移行では，旧システムからデータやアプリケーションの 一部を新しいシステムに移行する。移行の理由は大きく，「システ ムの再構築」「システムのバージョンアップ」「ハードウエア/OSの 入れ替え」の三つがある。当然，システム統合と併せて検討するこ とで，両者を個別に実施するよりコストや期間的なメリットが生ま れる。ただし，作業の複雑度が増すので，リスクは高くなる。統合 と移行を同時に行う場合は，綿密な計画を立案し，綿密にシミュレ ーションやリハーサルなどを行うことが望まれる。 ＊4 パーティショニング Partitioning 。1 台のハードディス クを複数の領域に区切り，あたかも 複数台のハードディスクがあるかのよ うに利用する技術。 ＊5 仮想化技術 CPUやメモリー，ストレージやネット ワークといったコンピュータの物理リ ソースを論理的に分割し，効率的に 利用するための技術。物理リソース に対応した論理リソースを作成し，ア プリケーションは論理リソースを通じ て物理リソースにアクセスする。 業務処理1 業務処理2 業務処理3 業務処理4 現状の整理 情報を連携させて業務の断絶を解消 システムA システムB システムC オペレータ オペレータ 人間の判断 情報の 再入力 判断結果 の入力 業務処理1 業務処理2 業務処理3 業務処理4 システムA システムB システムC オペレータ 人間の判断 判断結果の 入力 情報の連携 図1-1-7●業務の断絶を解消するための考え方
