 |
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
| 事例分析 〜 みずほFGにおける障害発生の分析 | ||||||||||||||||||||||||||||||
|
次に図3のモデルを用いて、2002年4月に発生した、みずほFGの障害発生について分析してみよう。 みずほFGは、第一勧業銀行、富士銀行、日本興業銀行の3行が経営統合した結果発足したメガバンクである。1999年8月に行われた統合発表以降統合作業が進められ、すでに設立済みの上場持ち株会社みずほホールディングスの下に、2002年4月にリテールのみずほ銀行と企業向けのみずほコーポレート銀行の2行に統合・再編した。 しかしシステム統合の初日（2002年4月1日）にATM（現金自動預け払い機）が正常に利用できなくなった上に、実際には引き落としていない口座の現金残高が減るといった異常な事態が発生した。口座振替処理の遅延も250万件に達するなど被害が拡大し、完全復旧までに2週間以上を費やすことになったのである。 このように、みずほFGは統合・再編、分割合併に伴う情報システム統合の際に、ATM障害や口座の二重引落し、口座振替の遅れなどの障害が発生した、というのが,この事例の概要である。 「図4は図3で示したモデルを用いて、みずほFG統合事例研究分科会がまとめたものに従って、対応するポイントを列挙したものである。」
図4：みずほFGの障害発生分析 ビジネスとの整合性の観点からみずほFGの障害発生について考えると、図4に示すような「プロジェクトの各プロセスにおいて、ステークホルダー間の意思疎通」を欠いたために、「各ステークホルダーの本来の業務との情報システムの関係がうまくいかなかった」ことが失敗の根本的な原因であると考えることができる。 |
||||||||||||||||||||||||||||||
| 障害発生を防ぐための形式的アプローチとその限界 | ||||||||||||||||||||||||||||||
|
システム統合を含めた情報システムにおける障害発生に対して、形式的手法を用いることによって、回避する可能性を考えることができる。形式的手法とは、VDM（注1）やZ（注2）などが代表的だが，集合論に基づいて仕様を厳密に記述することにより、望ましくないことが起こらないことを保証しようというアプローチである。
※注1：
VDM：Vienna Development Method
IBMのウィーン研究所で開発された形式仕様記述言語。詳しくはhttp://www.vdmtools.jp/を参照されたい。 ※注2： オックスフォード大学で開発された形式仕様記述言語。 このアプローチは、実際には、「証明」という形で仕様の妥当性を示すという使い方よりも、厳密な型や変数名の管理を容易にすることが、その利点であるといわれている。 このような形式的手法が有効なのは、例えば「誤発注に対する取消し入力があった場合には…」といった要求が与えられている時に、「システムがその要求を満足するかどうか」といった「想定の範囲内」での話である。一方、「想定の範囲外」のことが起こった場合、すなわち「元々要求として考えられていない」場合には、障害が発生しないことを保証できないということに留意すべきである。障害として何を想定するかは、仕様を作る側の問題なのである。 |
||||||||||||||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
-
人気記事ランキング
-
-
連載
