TOP
＞
業務システム
＞ システム統合における障害発生分析モデル
システム統合の要点となるビジネス−IT−組織のアラインメント
第２回：システム統合における障害発生の分析 〜 みずほFGのシステム統合事例
著者：
東京工業大学 飯島 淳一
2006/8/1
前のページ
1
2
3
次のページ
システム統合における障害発生分析モデル
次に、この連載のテーマであるシステム統合に話を移そう。2002年4月に誕生したみずほフィナンシャルグループ（以下、みずほFG）の障害発生に代表されるように、ビジネスにおける情報システムの重要性を考えた時に、情報システムにおける障害発生は、1つの部門や企業内にとどまらずに顧客など社会に対して影響を与えることが多い。
サウアーモデルではこの点があまり考慮されていない。また、サウアーモデルにおける支援者は経営者だけでなく、当該企業の情報システムのユーザ部門も含まれるが、それぞれの役割は異なっている。
これらを踏まえて、サウアーのモデルを次の3点について拡張する。
新たに、顧客というアクターを考える
支援者からユーザ部門を抜き出す
プロジェクト組織を社内と社外の2つの組織に分離する
表1：拡張されたサウアーのモデル
これにより、図2に示すようにシステム統合における障害発生分析モデルが得られる。
図2：システム統合における障害発生分析モデル
図2はA社とB社の統合を想定して、システム統合に関わる主なステークホルダーを描いたものである。図2の中心に情報システムを取り囲む形で描かれているのは、システム統合の推進委員会（統合プロジェク本部、統合準備委員会など）である。システム統合においては、通常このような統合に関わる委員会が設置され、システム統合に関する様々な問題について協議して統合プロジェクトを進めている。
システム統合プロジェクトにおける障害発生分析モデル
一般的に、システム統合における障害発生の原因を1つに絞ることは難しい。「統合の発端において当事者間に統合後の姿に対する明確な共通認識がなかった」「意思決定部署と作業部隊との間の意思疎通がうまくはかられていなかった」「統合後のIT戦略がはっきりしていなかった」「本番稼動直前での確認作業がうまくいかなかった」など様々なものがある。
そこで、「システム統合におけるステークホルダーとその間の関係」といった空間的な観点だけでなく、「統合プロジェクト全体を通じてその障害発生を分析する」という時間的な観点も必要となる。
プロジェクトマネジメント
プロジェクトマネジメントでは、プロジェクトのプロセスが5つのグループに大別されている。それらは、立ち上げのプロセス／計画のプロセス／遂行のプロセス／コントロールのプロセス／終結のプロセスであり、PMBOKでは次のように説明されている。
立ち上げのプロセス
プロジェクトあるいはフェーズの着手の必要性を認識して、プロジェクトにコミットする。
計画のプロセス
プロジェクトが引き受けたビジネス上の要求を完遂するために、作業可能な計画を立案し、それを維持する。
遂行のプロセス
計画を遂行するために、人およびその他の資源を使いこなす。
コントロールのプロセス
プロジェクトの目的の達成を保障するために、プロジェクトの進捗を観察・測定し、必要に応じて改善策を実行していく。
終結のプロセス
プロジェクトやフェーズの検収を完了し、プロジェクトをきちんと終点にたどり着かせる。
そこで次に、これら5つのプロセスと、先に述べた、障害発生分析のモデルとを組み合わせたモデルを考えてみる。
図3：システム統合プロジェクトにおける障害発生分析モデル
（画像をクリックすると別ウィンドウに拡大図を表示します）
図3は図2に示した障害発生分析モデルを5つのプロセスグループごとに並べ、その関係について時間的な要素も加味して分析しようというものである。
前のページ
1
2
3
次のページ
著者プロフィール
東京工業大学 社会理工学研究科 教授 飯島 淳一
1982年東京工業大学・大学院博士課程修了。1996年より現職。2006年4月より経営情報学会会長。主な研究分野は，情報システム学と数理的システム理論。主な著作は『成功に導くシステム統合の論点（共著，2005）』『入門 情報システム学（2005）』ほか。
INDEX
第2回：システム統合における障害発生の分析 〜 みずほFGのシステム統合事例
システムにとっての失敗とは
システム統合における障害発生分析モデル
事例分析 〜 みずほFGにおける障害発生の分析
