企業の基幹システム・リニューアルについて書いてみました。
- 企業の必需品「システム」
- 定期的なリニューアルが必要なシステム
- リニューアルに潜む、システム障害のリスク
- 大手金融機関のシステムリニューアルの思い出
- JALが「旅客システム」を50年ぶりにリニューアル
- 「こうすればよかったのでは？」JALのシステム理想的なシステム移行手順
企業の必需品「システム」
「システム」というのは、企業において、今や必要不可欠になっています。
小さな会社でもパソコンぐらいは導入され、簡単な社内LANのようなものが普通にあるようになりました。中小企業でもネットバンキングや受発注システムなどを行っていたり、大企業などでは、自社開発の社内システムなんかが動いていたりします。
ITなしで、業務を行うというのは、なかなか難しくなってきています。
定期的なリニューアルが必要なシステム
システムは、一度導入して終わりではなく、定期的なメンテナンスやリニューアル、機器交換などが必要となります。
パソコンやサーバーなどの機器寿命や、機器の性能やOSなども年々バージョンアップするという理由もあるし、「運送費が変わる」「消費税率が変更」などといった商環境が変わり、その対応をしなければいけないということもあります。
リニューアルに潜む、システム障害のリスク
大企業の場合、組織規模が大きくなるので、このシステムのリニューアルというのは、なかなかやっかいなものになります。
業務に影響がないように、リニューアル作業を行なう必要があり、システムが稼働しない休日などに入れ替え作業などを行います。
さらに一般のお客さんが使うシステムでは、事前のアナウンスを行うなど、特に注意が必要です。
しかし、いくら注意してリニューアル対応しても、システム障害やトラブルが起きてしまいます。たとえば、こんな事例があります。
みずほフィナンシャルグループでの大規模システム障害
第一勧業、富士、日本興業の３銀行のシステムを「みずほ銀行」として一本化するシステム統合で、統合の方針決定が紆余曲折し、システム統合のスケジュール・統合作業が遅れて、予定していたシステム稼働テストの開始がずれ込み、十分な見極めができないまま開業したため、2002年4月の開業直後に大規模システム障害が発生。
ヨドバシカメラでのシステム障害
「ヨドバシ・ドット・コム」が2008年10月21日（火）にリニューアルされ、個人的な感覚では「使いにくく、見にくく、お目当ての商品が探しにくく」なって改悪されたように感じられていたわけですが、それどころかあまりにも表示が遅すぎて激重になり、なんとお詫びページまで作られるほどに。
英ブリティッシュ・エアウェイズ（ＢＡ）、大規模システム障害でロンドン発便すべて欠航
英航空大手ブリティッシュ・エアウェイズ（ＢＡ）は27日、大規模なシステム障害の発生を受けて、同日のロンドンの二大空港発の航空便をすべて欠航した。国内だけでなく海外を含む幅広い業務が影響を受け、オンラインでのチェックインができなくなるなど旅客に混乱が広がった。ＢＡは復旧を急ぐとともに、旅客に空港に来るのを控えるよう呼びかけた。
こういう事案を見ると、以前の業務を思い出します。
大手金融機関のシステムリニューアルの思い出
昔、某大手ITコンサルに在籍していた時、大手金融機関のシステムを担当していて、大小さまざまなリニューアル案件が、日常的に行われていました。
金融機関のシステムというのは、かなり慎重に扱う必要があります。リニューアル前後で「残高の金額が違う」「口座データが消えた」というのはもってのほかで、あるいは、リニューアル後に「オンライン取引ができなくった」という自体でもなれば、その経済的損失を補償しないといけないことに発展する可能性もあります。
そうはならないように、入念なテストはもちろんのこと、入れ替え作業において、不具合が発覚したら、そのバックアップ策というのを、あらかじめ講じておきます。
JALが「旅客システム」を50年ぶりにリニューアル
日本航空・JALが、2017年11月16日に「旅客システム」を50年ぶりにリニューアルし、従来のホスト系システムから、クラウド系システムへの移行となりました。
IBM系のメインフレームで作られた自社製システムから、「アマデウス」という外部の航空会社向けクラウドシステムに移行です。
この日本航空・JALの「旅客システム」のリニューアルは、Web系媒体で報道もされていたりします。
この日本航空・JALの「旅客システム」を、個人的に使ってみた感想としては、よくあるWebサービスのβ版的な感じで、「今はここまでできるけど、ここから先はまだできていない」という感じです。IT系会社の新サービスでは、よくあるパターンなのでいいですけど、日本航空・JALとしては「どうなのか？」という感じもします。
この日本航空・JALの「旅客システム」は、一見すると大丈夫そうなんですが、使ってみるとバグというか誤表示てきなものが気になります。大きな失敗はないけど、細かいエラーがいろいろとある、という感じです。
ただ、「予約データ」「データ表示」系のバグがほとんどなので、日常の飛行機の運航には影響がないですが。
「ほんとにテストしたのか？」というTwitterでのコメントをよくみます。以下のコメントは、見かけて、その通りだと思いました。
#JAL テスト要員じゃないが、バク報告をしたほうがいいのか。バグを避けて予約したけど。こういう特異日には飛行機に乗るもんじゃないな。不安だよね。
— 富田恭敏 (@aoKaeru) 2017年11月15日
「こうすればよかったのでは？」JALのシステム理想的なシステム移行手順
今回の日本航空・JALの「旅客システム」のリニューアルをみて、理想的なシステム移行手順を妄想してみます。(内情や制約条件を考慮せずに書いています。)
多くの会社の、基幹業務系システムというのは、基本的には、データベースの更新作業です。
「オンライン注文」「検索」「バンキング」など、いろいろな用途がありますが、その基本は、データベースの更新です。そして、そのデータベースの内容をいじったり、表示したりするインターフェイスが、基本的な構図です。
基本的なシステム構図
システムの用途として、「オンライン注文」「検索」「バンキング」など、いろいろな用途がありますが、基幹業務系システムというのは、基本的には、データベースの更新作業です。そして、そのデータベースの内容を操作したり、表示したりするインターフェイスというが、基本的なシステム構図です。
Phase-1: インターフェイスだけ変更
利用者、とくに一般者が使うシステムの場合、慣れるまで時間がかかるため、先に慣れてもらうとよいでしょう。
まず、Phase-1では、新しいインターフェスを用意し、旧DB(データベース)につながるようにします。
旧インターフェイスも共存しておき、新旧のインターフェスで使えるようにします。
Phase-2: データを旧DBと新DBへ
次のPhase-2では、旧DBと新DBに同じデータを流れるようにします。理論上は、旧DBと新DBは同じデータ入るようになります。
その際、旧DBを正として、新DBの内容をチェックして、漏れがないのかを確認します。
Phase-3：旧DBへの接続を廃して新DBに一本化
新DBへのデータ接続が問題ないようならば、次のPhase-3では、旧DBの接続を廃止して、新DBだけを使うようにします。
Phase-4: 旧インターフェスを廃止
新インターフェイスの利用浸透が進んだならば、Phase-4として、旧インターフェイスを廃して、旧システム自体も廃止します。
＊上の内容は、内情や制約条件を考慮せずに書いています。
こういう手順を踏めば、不具合時の影響が少なく、またバックアップ対応もしやすいのではなかったかとおもいます。
ただ、メインフレーム系のデータベースと、サーバー系のデータベースを並存させて使うには、ミドルウェアをいろいろと用意しなくてはならず、その対応だけでも開発負担が相当なものとなるでしょう。
これはかなり手間と時間とお金がかかる方法なので、よほど慎重な場合にしか、こんな方法はとらないと思います。
しかし、多くの一般利用者がいるシステムで、航空券はそれなりに高額な商材なので、このような慎重対応でもよかったのではないかと思ったりします。
時代によって顧客のニーズは変化するので、頻繁に少しずつシステムを変えていけることが重要。
by宮崎 富夫
