アドバイザリー

システム障害発生防止の決め手 「移行判定基準」

2012.03.13
岡村 和彦
岡村 和彦
新日本有限責任監査法人
ITリスクアドバイザリー部 エグゼクティブディレクター
システム監査技術者、中小企業診断士
監査法人入所後、官公庁、地方自治体、独立行政法人を中心に開発保守、運用の情報システム監査、金融機関、一般企業の個人情報保護に関わるセキュリティ、ITコスト削減などのアドバイザリー業務などに従事。


1. 移行判定基準とは

システム開発における「移行判定基準」とは、開発作業完了後、システムが確実に本番切替できるレベルに達しているかを確認・判定する規準のことです。この規準には、システムが本番稼動後に安定して稼動できるかどうかを確認する多数の基準項目が体系的・網羅的に構成されています。例えば、システムの品質、バグの収束状況、システムの利用者に対する操作教育や環境整備、本番稼動後の運用体制、保守体制などの確認基準項目があります。
金融機関や一般企業などの合併やシステム共有に伴うシステム統合の増加により、この移行判定基準の重要性が注目されるようになりました。金融庁の「システム統合リスク管理態勢の確認検査用チェックリスト」にも、システムの移行判定に関しては「取締役会は、システムの移行判定基準を承認しているか」とチェック項目が明記され、金融機関のシステム統合には、移行判定基準が整備されていることが前提となっています。

2. システム移行の重要性

システム開発の最終ゴールはシステム移行であり、これにより旧システムから新システムに交代することになります。ところが、この移行で失敗すると、大きなトラブルとなり、重要度の極めて高いシステムでは、社会に大きな影響を及ぼすことにもなりかねません。システム移行とは、旧システムからデータなどを引き継いで、新システムに移行して、稼動させるだけですが、その作業はシステムが膨大になればなる程、複雑・困難を極めることになります。データの移行だけでも、新システムに移行するデータを抽出して、新システムの仕様に適合するように、データ変換のアプリケーションシステムを事前に作成することが必要になる場合もあります。しかも、日々稼動している情報システムであれば、これらの移行作業を短時間で遂行しなければなりません。作業漏れや手順の間違いは、即、移行後の大きなトラブルにつながります。ところが、このような移行作業の重要性は、あまり認識されていないようです。一時的で1回限りの移行作業に対して、多くの企業はコストも工数も十分に割り当てない傾向があります。

3. 続発したシステム統合のトラブル

2005年頃に頻繁に行われた市町村合併では、システム統合のトラブルが続発しました。合併した市町村の約3割がシステム移行後に何らかの障害が発生したと報告しています。トラブル原因は、データ移行の失敗、運用上のトラブル、ハードウェア障害、プログラムミスなどで、多種多様でした。データに関しては、多くは市町村名変更などの検証不足によるものでした。市町村合併は、規模の大きな市町村の既存システムに統合されるケースが多数でしたが、それでも作業は単純ではなかったようです。トラブル発生の影響としては、住民票や証明書の発行が一時的にできなくなる現象が起きました。

4. 公表されない移行判定基準

「業務・システム最適化指針(ガイドライン)」(各府省情報化統括責任者(CIO)連絡会議決定)においても、移行に関しては、移行判定を行うことが明記されています。次期システムの安定稼動を確実に行うために、判定項目、移行判定基準等を作成の上、移行の可否を行うこととされています。各省庁とも移行判定基準の普及に関する取り組みは真摯なものですが、この移行判定基準なるものが、まだ、どこからも公表されていません。SIベンダーやシステム開発に強みのあるコンサルティング企業が、独自に開発して所有しているに過ぎないようです。そのため、この規準の普及には弾みがつかないようです。

5. 判定基準のポイント

移行判定基準を、各企業が独自に策定する場合、少なくとも次のようなことを十分考慮して、反映させておく必要があります。

(1) 本番システムの準備はすべて完了しているか。
(2) 本番リハーサルを実施し、問題点は発生していないか。
(3) 本番時と同一システムでテストが完了しているか。
(4) 本番環境とテスト環境との違いはないか。
(5) 予定された各フェーズおよび各種のテストは実施され、問題点はないか。
(6) トラブル発生時の体制、方針、手続は明確にされているか。
(7) バグの収束状況の判定結果は品質基準をクリアしたか。

本来、このようなことは、システム開発過程のプロジェクト管理において十分確認されているべきです。ところが、開発管理が行き届いていなければ、当然実施される事項が進捗遅延やトラブル発生により未了のまま本番予定日を迎えたり、修正変更作業を安易に考えて確認が不十分なまま本番当日にトラブルを発生させたりすることもありえます。そのためにも本番移行直前に開発したソフトウェアの品質と本番環境への適応性を十分に検証できる規準が必要になります。
さらに、新システムのカットオーバー(本稼動)の可否判断は、曖昧な規準でなされるべきものではなく、対象システムと環境に適合した規準を、システムテスト開始前までに準備しておく必要があります。なぜなら、システムテスト時には、本番稼動に十分耐え得るかどうかの見極めを、開発者側の立場から、設定した規準に基づいて行うことが速やかな規準達成につながるからです。

6. 移行判定基準の位置づけ

「新システムのカットオーバーは何年何月何日」と経営層が決定を下すと、これを撤回するのは至難の技となります。また、多少困難と思われてもプロジェクト組織が大きければ集団心理が働き「なんとかなるだろう」という希望的観測に支配されることもあります。プロジェクトマネージャにしろ、システム開発責任者にしろ、カットオーバー直前に「延期しましょう」と言えば、その責任が個人に問われ、不適格者の烙印も押されかねません。このような事態を想定すれば、予め開発プロジェクトの方針や規程などに、移行判定基準の位置づけを明確にしておく必要があります。移行後のトラブル発生というリスクを最大限に回避するには、移行判定基準に基づいて、客観的、科学的、総合的に判定して、移行の最終決定を下すのが最良の策といえます。





情報量は適当ですか?

文章はわかりやすいですか?

参考になりましたか?