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