移行フェーズにおける作業の概要

伊東 輝

システム開発における「移行作業」とは、システムテストやクライアントの受け入れが完了し、リリースが了承されたシステムについて、実際にサービスを提供するための本番環境で稼働できるように設定変更を行う作業のことを指す。
「本番リリース」や「カットオーバー」等と呼ばれることもある。

移行作業前は、開発者やテスト担当者、受け入れ担当者のような一部の関係者しか新システムを操作することはできないが、移行作業後は一般ユーザーが新システムを操作して実運用を行うことができるようになる。
移行作業は、これまで現行システムで実運用を行っていた一般ユーザーが、如何にスムーズに新システムによる実運用に移れるか、如何に不便な思いをさせないかが鍵となる。
仮に「現行システム」と呼べるようなシステムが存在しなかったとしても、代替手段として手作業による実運用はされていたはずであり、作業の手順や蓄積されたデータといったものも存在するはずである。
移行作業では、そのような所も意識する必要がある。

この記事では、移行作業を実際に行うために必要な知識、具体的には、移行作業の計画の立て方、移行作業の方式、及びリハーサルについて簡単に取り上げる。


(1)移行作業の計画

移行作業は思いつきで行うような作業ではない。
事前に計画を立て、その計画通りに作業を実施することが重要となる。

移行作業の計画を立てるにあたり、意識するべき視点には以下のようなものがある。

  • 移行の目的と対象の明確化
    移行作業は一般ユーザーに影響を与える重要な作業であるため、移行作業を行うにあたっては、新システムの詳細を知らない社内外の意思決定者に移行計画を説明する必要がある。
    そのため、移行の目的や移行対象といった、前提となる情報を改めて整理する必要がある。

  • スケジュール作成
    一般ユーザーにとって、新システムがいつから使えるのかは重要な情報である。
    また、現行システムが稼働している場合は、現行システムを停止させて新システムに入れ替えるという作業が必要になるため、いつシステム停止をするのかも重要な情報になる。
    （原則として深夜ないし土日祝のような定期的なシステム停止が行われるタイミングと被せるが、24時間365日の稼働が必要なシステムの場合は意図的にサービス停止のタイミングを作り周知する必要がある）
    また、内部的には、移行作業の準備作業や、後述する移行後の確認作業・監視作業のような作業も必要になり、通常の勤務とは異なる勤務体制も必要になることが多い。
    上記のことを鑑みて、スケジュールを作成する必要がある。

  • 移行手順作成
    作業担当者向けにはスケジュールの作成のみでは不十分である。
    一般ユーザーに直接影響が出る重要な作業であるため、作業に抜け漏れや誤りがないようにするため、詳細な作業手順を作成し、その手順に従って作業を行う必要がある。
    流れを大まかに書くと、「インフラ設定変更によるサービス停止→プログラムの配置作業→データの移行（旧システム向けフォーマットから新システム向けフォーマットへの変換）→移行後の確認作業→インフラ設定変更によるサービス解放」という流れになる。
    それぞれの作業について、コマンドレベルにまで落とし込んで、手順化する必要がある。
    作業手順を作成する際には、サービスを停止することができる時間を鑑みた上で、その時間内に作業が完了するように手順を作る必要があり、作業の完了の見込みが立たない場合は移行方式の見直しも考える必要がある。

  • 移行後の確認作業と監視体制の策定
    新システムへの移行後、サービス解放前のタイミングで、サービスが解放されたとしても正常にシステムが稼働するか確認する必要がある。
    一般ユーザーの操作を想定した操作を行ったり、新システム移行後に実行されるバッチ処理を実行させたりすることで、これを確認する。
    また、サービス解放後は問題が発生する可能性が高いため、問題発生時に迅速に対応できるようにするために、通常よりも手厚く監視体制を整える必要もある。

  • 問題発生時の対処法（コンティンジェンシープラン）の策定
    サービス解放後は、プログラムの業務ロジックの誤りによる機能面の問題や、処理性能が追い付かないことによる非機能面の問題といった、様々な問題が起こり得る。
    それらの問題に対して、可能な限り、どのような問題が発生したらどのような対応を行うのかを考えておくべきである。
    比較的軽微な問題であれば、手動での運用作業によるカバーや、一部機能の制限、プログラムの修正と再リリースといった方法で乗り切ることができるが、重大な問題の場合はシステム移行前の状態に戻す必要がある。
    この戻しを行うことができるかどうかは、システム移行後のリスクを抑える上で重要な観点となる。
    戻しを行う上では、バックアップの取得とその戻しという事前の準備が必要となり、この準備を怠ると、重大な問題が起きたとしても元に戻すことができない、何が正しいのかも不明確な状態で目の前の問題に手探りで対応するしかない、というリスクが高い状態となる。

(2)移行作業の方式

移行作業の方式としては、大きく分けて「一括移行」「段階移行」「平行運用」という３つの方式がある。
（より具体的な話としては、どのようなCI/CDツールを使うのか、どのようなデータフォーマットからどのようなデータフォーマットにするのか、といった話もあるが、この記事では割愛する）

この３つの方式は以下のような方式である。

  • 一括移行
    現行システムの全機能を停止してから、一括で新システムへの切り替えを行う方式である。
    現行システムと新システムの連携が必要ないシンプルな方式であり、小規模でリスクも少ないシステムに向いている。

  • 段階移行
    現行システムから段階的に新システムへ切り替える方式であり、システムを機能ごとに停止して何回かに分けて順番に切り替えを行う。
    一括移行では、必要なシステム停止期間が長くなる、移行後の問題発生時の影響が大きい、といったリスクがあるが、システムを段階的に移行することで一回一回の移行作業についてリスクを減らすことができる。
    一方、全ての機能を移行するまでは現行システムと新システムが同時に稼働する期間が生まれるため、その期間でどのようにデータや運用手順の整合性を取るのか考える必要がある。
    一括移行が難しい大規模なシステムに向いている。

  • 平行運用
    現行システムを稼働させながら新システムを稼働させ、現行システムと照らし合わせて新システムが業務上問題無く処理を行うことができていることが確認され次第、現行システムを停止する方式である。
    新システムの妥当性の確認をより確実に行うことができる点、新システムで問題が発生した場合も実運用に支障が出ないという点で、低リスクな方式であると言える。
    しかし、現行システムと新システムの両方を同時に運用する必要があるため、コストがかさむ方式でもある。
    コストを払ってでもリスクを低減する必要があるシステムに向いている。

(3)移行作業のリハーサル

移行作業の準備の一つとして、「リハーサル」というものがある。
これは、実際の移行作業と同じように作業を実施する、というものである。
実際の移行作業と異なる点は、サービス解放前に現行システムへの戻しを行う、という一点のみである。

リハーサルを実施することで、移行手順のミスを事前に発見でき、場合によっては移行後に想定される問題も見つけられることがある。
また、コンティンジェンシープラン発動時に実施する戻しの手順についても確認することができる。

システム移行に伴うリスクを減らしたいのであれば、本番の移行作業の前にリハーサルを実施するべきである。

この記事が気に入ったらサポートをしてみませんか？