システムカットオーバー後に押さえておきたいポイントとは

社内・社外システム問わず、システムカットオーバーしたときは達成感がありますよね。しかし、カットオーバー後にシステムが安定稼働していることがもっとも重要です。

私は経験上、多くのシステム開発・導入を担当してきました。
ときには想定外のシステム障害が発生し、夜通し作業をしたことがあります。

とはいえ、振り返ってみるときちんと事前準備やテストをする、または障害に備えて体制を整えておけば、そういった事態を防ぐことができたかもしれない、と思うことがあります。起きたとしてもスピーディな対応ができた場合にも心当たりがあります。

今回は、自身の経験を踏まえてシステムカットオーバー後に気をつけるべき5つのポイントを紹介したいと思います。

1.最悪を想定したチーム作りをする

システム開発、またはパッケージと呼ばれるシステム導入であっても、油断は大敵です。さまざまなシステムトラブルが発生すると仮定したチーム作りをすべきです。

例えば、私が経験したカットオーバー後のトラブルを具体的にあげると、

  • 日次で動くはずのバッチ処理が動かなくなった。
  • データベースがデッドロックを起こして画面を動かすことができなくなった。
  • ネットワークアクセスが集中して画面がフリーズしてしまった。
  • データ不整合が発生してしまった。

などがあります。事前に全く想定ができない場合もありますが、可能な限り多くのトラブル発生について仮定し、対策すべきです。

私が所属している会社では、システムカットオーバー後数週間は体制を組んで即対応する状態を「臨戦」と呼び、アプリケーションやインフラのあらゆるトラブルに備えています。

臨戦には、とにもかくにもまずはトラブルに対応できるチームメンバーを集めましょう。

2.業務イベントを整理する


臨戦に臨める体制を組む場合、いつまで、そして誰を配置すべきかは業務イベントを元に判断すべきです。

ここでいう業務イベントとは、システムを使う頻度と回数が増える業務を意味しています。例えば、会計システムでは経理の決算業務時期は経理からの問い合わせが多くなります。仕訳の金額が合っていない、帳表がこの場合は正しく出力されていない、など多くの問い合わせが集中します。

さらに、対応期日もすぐにといったケースが多くなります。

臨戦を組むときには、業務イベントを整理しておきましょう。

経験上、システムで行う初回業務は要注意です。できれば検証をした上で本番に臨むことをオススメします。

3.問い合わせ、および障害時の連絡網・連絡方式を明確にしておく

システムカットオーバー前に何かしらクリティカルなシステム障害が発生した際に、上長や関係者の連絡は明確になっていますでしょうか?

本来、こういった事態が起きないことが望ましいですが、いざ起きたときには迅速に動けるよう事前に連絡網や連絡方式を明確にしておきましょう。

経験上、連絡を受ける上長にも実際のトラブルを想定した動きを理解してもらうためにも、シミュレーションをしておくことをオススメします。

4.コンティンジェンシープランを作成する


障害が起きたときに備えることは大切なことです。迅速に修正や対応ができることが望ましいですが、場合によっては完了するまでに時間がかかってしまうケースがあります。

この場合、どういった手段が取れるのかあらかじめ想定しておくことをオススメします。

例えば、会計システムにてある部門の仕訳データが正しく出力されない不具合が見つかった場合、経理の業務スケジュールとしては今日中が求められているものの、機能の修正に3人日ほど工数がかかるとします。このような場合、仕訳後の経理作業がストップしてしまいます。

経理作業を止めないことが求められているので、この場合は仕訳の元データをデータベースから取り出して、仕訳はそれを元に作成するするといった方法ができれば期日までには間に合うでしょう。

このように、システム機能が正しく動かないような場合、何ができたらゴールなのかを明確にして、機能以外で解決できる方法がないかあらかじめ検討することをオススメします。

5.問い合わせ内容のログを残しておく

システム利用ユーザーからはシステムカットオーバー後、要望や問い合わせがたくさん来ます。

それら問い合わせをきちんとログとして残しておきましょう。

システムの不具合ではなく、操作に関する問い合わせが複数人から来る場合は、マニュアルを作成してシステム利用ユーザーに配布するといった作業が必要となる場合があります。効果的な改善をするためには、日々どんな問い合わせが来ているのかチェックしておく必要があります。

そして、問い合わせのログを分析し、時間軸で見たときに減少傾向にあるのかなど、定量的な評価ができるようにしましょう。

6.ヒヤリハットの法則を頭に入れておく

別名、ハインリッヒの法則とも言いますが内容は1つの重大事故の背景には29の軽微な事故があり、さらにその背景には300のインシデントが存在するというものです。

この法則を理解していると、日々のトラブルに対して、氷山の一角ではないかと疑問を持つ
ことができます。

氷山の一角と考えることができると、トラブルの原因の本質を追求することができます。

小さなトラブルであったとしても、氷山の一角と捉えて原因の本質を追求することが重要です。

7.まとめ

いかがでしたか?

システム開発・導入を経験している方は、システムがカットオーバーする前よりも、カットオーバー後の方が大変という方も多いかとは思います。

本質的にはカットオーバー前にあらゆることを想定したテストができておけば理論上は問題ないのですが、残念ながら実際はトラブルは何かしら発生すると思います。

ポイントはそれらが極力発生しないよう、業務イベント把握など、なるべく事前に予測しておくことです。そして、仮にトラブルが発生した場合は即座に対応ができる体制を整えておくことが必要となります。

さらに、即対応できない場合は上長含めた関係者にコンティンジェンシープラン含めて報告することも重要です。

日々のポイントとしては、ヒヤリハットの法則を理解し、小さなトラブルが後々に大きなトラブルにならないよう原因の本質を日々追求することを忘れないようにしてください。

そして、定量的な分析をして改善ができるよう問い合わせ内容のログをきちんと残しておくこと。

これらをしっかりすれば、カットオーバー後のトラブルは最小限に留めることができるのではないでしょうか。

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

同じタグのついた記事

同じカテゴリの記事