うまけいた、社内SEやってます

20代でSier⇒社内SEに転職し、数年の業務経験を経て感じたこと、経験等をこれからIT企業への就職や転職を考えている人むけに、その仕事内容や業務ノウハウ等をご紹介。

社内基幹系システム移行計画策定時のポイントについて

今回は社内システムのサーバ移行やリプレース対応において事前に計画すべきポイントについて何点かご紹介していこうと思います。

社内SEとしていくつかのシステムのサーバ移行・リプレース等を経験してきましたが、特に人事・経理向け等の社内基幹システムにおいて旧システムから新システムへの移行失敗は、大トラブルに直結してしまいます。

理由としては、移行失敗によって例えば給与計算業務や会計の決算業務等が滞り、会社の事業活動そのものに影響が出てしまう事が想定されるためですが、システム移行を問題なく終えるための移行計画を入念に作成しておく事が大事です。

システム移行の成功・失敗については単純にシステムが動かない以外にも、品質・コスト・納期の遅延等といった様々な観点が絡み合うため、様々なフェーズで様々な計画にそって対応を行っていく必要がありますが、具体的には、以下のような様々な角度から移行計画を行う必要があると考えます。

 

  • 移行対象データの策定

移行データについては、そのデータ量が多くなればなるほど移行にかかる作業量や、当初想定の移行データに過不足がないかどうかのチェック作業等が膨らみ、工数や納期にも影響が出てきます。そのため、単純に移行前のデータを全て移行先システムへ移行する前提で移行作業を進めるのではなく、きちんと各々のデータに対して要不要の精査を行う必要があります。

が、これまでの経験上ユーザ側の立場からすると移行前のシステムで保有しているデータは全て移行先システムへ持っていってほしいと言われるケースが多いです。。

特に基幹系システムにおいてはトランザクションデータ等も膨大な量になってしまうため、マストな感じでないなら移行をしない選択も作業工数削減のためとしては有りかと思います。

ただし、移行しないデータはどうするのか？等の代替案を何かしら示す必要があると思うので、例えば利用頻度の少ないデータについては移行元システムから出力したデータを共有フォルダ等に格納しておく事で有事の際にはいつでもデータ閲覧出来る状態にある事を予めユーザ側に調整しておく等の対応を行う。

システム移行の際にはこのような移行対象とするデータの策定及びそのために必要な調整作業も含めて、計画しておく事が重要と考えます。

まぁシステム移行の時だけでなく、社内SEとしては常日頃からあらゆるトピックに対してユーザとの調整を行っていって、上手いことシステム作業側に有利に(?)働きかける事が出来るかどうか行う事が求められるのですけどね。。それが中々難しいのですがその辺りの内容はまた別記事で掲載していこうと思います。

 

  • 全体スケジュールの策定

システム移行の際には全体スケジュールを策定する必要があります。全体スケジュールの策定では、プロジェクトの開始日と終了予定日の中でシステム移行作業を含めた全ての「作業内容」や「作業期間」、「担当者」等の情報を記載し、システム移行までの予定が計画通り進んでいるのか遅れが発生しているのか、その作業担当者は誰なのかを明確化・資料化して関係者間で共有する事が重要です。

理由としては、基幹系システムのようなシステムを移行する場合、そのシステムが他のシステム群に何かしらのデータ連携しているようなケースが多く、DB連携やバッチプログラムによって他システムへデータ連携している場合は連携先システム側の方でデータ取得のための向き先を移行元システムから、移行先システムへと変更を行う必要があり、連携システム群が多ければ多い程、多くの関係者を巻き込む事になります。

そのような変更作業を行う場合に、具体的にいつ頃にそのような作業を行う必要があるのか、移行までに向けた全体スケジュールをユーザ含めた関係者間で常に把握しておく必要がありますが、

全体スケジュールの明確化・資料化によって当初全体スケジュールで策定した各作業の早まりや遅延が本番移行日に影響を受けるか否かにおいてアンテナを張る事ができ、影響を受ける場合にはシステム移行によって影響を受ける関係者に対して素早く情報共有を行う事が可能となるため、上述した「全体スケジュール」の策定・計画しておく事が重要です。

 

  • 移行作業に係るタイムチャートの策定

移行当日においては実施する作業内容の抜け漏れが発生した場合、システム移行の失敗に直結する事態となってしまい、ユーザ側への事情説明・再調整・報告書の提出や各種周辺システムに対する再調整等といった対応を余儀なくされてしまいます。

また、システム移行の際には事前にユーザ側と移行時間を調整した上での対応となるケースが多く、実際の作業が計画した時間の範囲内に沿って行われているかチェックするために、事前に移行の作業内容及び各作業時間の詳細を計画する事が重要となります。

具体的には、以下のような項目を作業内容単位で事前に計画する必要があると考えています。

  1. 作業日（前日作業なのか当日なのか等）

  2. 作業開始時間

  3. 作業終了時間

  4. 作業時間

  5. 作業内容

  6. 作業結果（OK or NG等）

  7. 作業担当者（ベンダ側なのかユーザ企業側なのか等）

  8. 備考

 

  • 移行時の体制について

移行時においてベンダ側及びユーザ側の担当者を明確にし、システム移行当日にあたって以下の必要最低限以上の要員を確保する事が必要であると考えます。

 

  1. 作業ベンダ側⇒2名以上

  2. 社内システム部門⇒1名以上

  3. ユーザ側⇒1名以上

 

上記の理由としては、主な作業者として想定されるベンダ側の担当においては作業者とは別に確認者を用意する事で、作業者の作業漏れやミスに気づいて対応を行えるようになり、トラブルを未然に防げる可能性があるため、ベンダ側は2名以上は必須であると思います。

ユーザ側においては、ベンダとユーザの橋渡し役になるシステム部門担当者1名と、システム部門側からの移行作業に係る報告を受けるユーザ側担当者1名以上の要員を確保する必要がある。ただし、システム部門担当とユーザ側担当においてはベンダからの報告を受けて何かしらの判断・各所への調整対応を行う事が出来る人材が担当する事がポイントであると考えます。

 

  • コンティンジェンシー計画について

システム移行時において事前に想定される障害を洗出し、万が一その障害が発生した場合に被害を最小限に抑えるために事前計画しておく必要があります。

具体的には、旧環境で取得しておいたバックアップを新環境への適用が完了しないような場合や、移行したシステムから周辺システムに対して意図せぬデータが連携されてしまっているような事象が発生した場合には一時的にシステム移行の切替を取りやめ、旧環境を継続利用する等といった対応を事前に策定する事で、不測の事態がもたらす被害を最小限に抑えられるため、システム移行においてコンティンジェンシー計画の策定が重要です。

 

今回いくつか社内基幹系システム移行計画策定時のポイントについて記載させていただきましたが、もっと経験重ねるともっと色々な事に気付けるようになるんだろうな。。

本テーマについては今後も継続して記事にしていきたいと思います！

 

それでは、また！