旧システムを止められない：二重運用を終えるための確認点
新システムは稼働している。ところが旧システムも残っている。過去の記録を見る人がいる、月末だけ使う処理がある、何かあったときに戻したい。理由はそれぞれもっともだが、「念のため」をまとめて扱うと、二重運用の終わりが見えなくなる。
停止を決めるには、旧システムでしかできない業務、残すべき記録、戻すための準備を分けたい。記録を残す必要があることは、同じ画面と処理を動かし続ける必要があることと同じではない。業務の移行、記録の参照、復帰の方法をそれぞれ確かめてから、稼働を終える。 本記事はこの判断を扱う。
この記事の目次
稼働日は、移行の終点とは限らない
米国GAOの2019年の報告は、政府機関の重要なレガシーシステムを調べ、近代化計画の要素として、節目、必要な作業、旧システムの処分・終了に関する計画を挙げている。対象を選んで行った監査であり、企業全体の失敗率や、終了計画の因果効果を推定した研究ではない。GAO「Critical Legacy Systems」
この論点を企業の移行へ使うなら、承認する計画に「新環境を動かす日」だけでなく、「旧環境の役割がなくなったと確認する仕事」を含めるという提案になる。稼働日は重要だが、それだけでは取り残した処理の有無は分からない。
旧環境を残す理由は、担当者に具体的に説明してもらう方がよい。「不安だから」から一歩進めて、どの業務、どの記録、どの障害で必要になるかを分ける。具体化すれば、すべてを動かし続ける以外の解決も検討できる。
まず、旧環境でしか終わらない仕事を探す
画面の利用者が減っていても、夜間処理や他システムへの連携が残ることがある。日常の操作が成功しただけで、月末や年度の処理まで移行できたことにはならない。停止の確認は、利用人数だけでなく、業務がどの経路を通って完了するかで考える。
AWSの退役ガイダンスも、依存関係を把握し、制御された停止を使って影響を確かめる考え方を示している。これは移行実務の指針であり、「一定期間動かなければ必ず不要」という実験結果ではない。AWS「Retiring applications: Best practices」
編集上の提案は、残っている処理ごとに、代替経路と確認する担当を置くことだ。利用頻度が低いものほど、観測期間に現れなかっただけなのか、実際に不要なのかを区別する。必要な業務周期を無視して、皆同じ日数で合格にしない。
たとえば年に一度の処理は、一年間本番を並走させる以外にも、代表データによる検証や実施手順の確認を検討できる。ただし、まだ試していない部分まで済んだことにはしない。何を確認し、何が残るかを停止の判断者へ渡す。
記録を残すことと、処理を残すことを分ける
過去の契約や取引を見るために旧環境を残す場合、必要なのは何かを明らかにしたい。原データか、当時の帳票か、検索か、訂正の履歴かによって、保管の方法も必要な操作も違う。
記録を書き出せば完了とも限らない。必要な人が検索できるか、項目の意味が分かるか、権限を適切に管理できるかを確認する。ファイルがあることと、問い合わせに答えられることの間には、索引や説明が必要な場合がある。
一方で、閲覧だけが必要なのに更新機能まで残しておくと、どちらが正しい記録か迷う場面が生まれ得る。業務の新規入力を止め、必要な参照だけを残す段階を設ける案がある。ただし、これも環境に応じた設計であり、一律の手順ではない。
保管期間については、対象記録の要件を確認して決める。技術資料に書かれた退役手順から、すべての記録を削除してよい日を導くことはできない。本記事でも、特定の年数を共通の答えにはしない。
参照先を別に用意する案では、記録の検索、権限、解釈が成立するかを確認します。そのうえで、月末・例外処理、定期処理・連携・契約の終了は別々に受け入れます。記録を残す必要があることから、新規取引を作る旧機能まで残すとは決めず、保存義務は記録ごとに確かめます。
二つを動かすほど、戻しやすいとは限らない
新旧両方へ入力しているなら、差異が出たときにどちらを正とするかが必要になる。片方へしか反映されない変更が増えるほど、旧環境があるだけでは戻れない。「電源が入る」と「現在の業務状態を引き継げる」は別の条件である。
MicrosoftのStrangler Figパターンは、新旧を段階的に置き換える方法を説明する一方、その間に置く経路の複雑さや障害点も扱っている。段階移行は有用な選択肢だが、併存を長く続けること自体が安全性の保証にはならない。Microsoft「Strangler Fig pattern」
復帰の準備では、どの時点のデータへ戻すか、移行後の取引をどう扱うか、停止して確認する仕事は何かを明確にする。旧環境を復帰先にするなら、その条件を実際に満たす必要がある。満たさない旧環境を、安心のために残しているだけでは復帰計画にならない。
他方、新環境側で復元・修正して継続する方針を選ぶなら、旧環境を動かすことと切り離して評価できる。戻す先は常に旧システムでなければならない、という前提から一度離れたい。
月末処理が残る会社と、閲覧だけ残る会社
以下は架空の移行の例である。新環境の日常処理は動いているが、月末の締め処理が旧環境からしか実行できない。この場合は全面停止を見送る。その処理の移行または代替を確認し、担当者が完了を判断できる状態を先に作る。
同じ会社でも、締め処理の移行が済み、残る理由が過去帳票の閲覧だけなら、選択は変わる。必要な記録を検索・提示できる保管先を確かめたうえで、旧環境の稼働終了を検討する。帳票が必要という理由で、新規入力まで続ける必要があるとは限らない。
さらに、閲覧先はできたが、例外的な取引を新環境で処理できないと分かったら、その未解決部分を停止判断へ戻す。閲覧が解決したことを、業務がすべて移った証拠にしない。このように、止められない理由を一つずつ分けると、残す範囲も絞りやすくなる。
これらは期間の短さを競う例ではない。条件が整えば止め、整わなければ残る仕事を限定して進めるための例である。安心するまでという期限ではなく、何ができれば終えられるかを合意する。
「一度止めてみる」にも、準備が要る
制御された停止は、誰にも知らせず電源を切ることではない。影響を観測する担当、必要なら再開する手順、利用者への連絡を用意し、想定外の依存を見つけた場合の扱いを決めて行う。AWSの資料も、短い停止では月次・四半期の処理の影響を捉えられない場合を示している。
停止中に問題が出たら、全面的に移行が失敗したと扱うより、依存していた処理を特定して計画へ戻す。その処理だけを移すのか、代替するのか、旧環境の限定稼働を続けるのかを選ぶ。確認の結果を、停止予定日を守るために無視しない。
一方、停止を延期する際には、残す間の運用負担も記録する。障害対応や更新作業が必要な環境を、費用のない保険として扱わないためである。止める危険だけでなく、残し続ける仕事も並べることで、準備を進める優先順位を説明しやすくなる。
最後の承認に、残すものを明記する
停止の承認には、移った業務、参照する記録の場所、障害時の対応、未解決の例外を並べたい。未解決があるなら、全面停止を延期するのか、影響部分だけ残すのかを明示する。残す場合も担当と終了条件を付け、次回また同じ説明を繰り返さないようにする。
停止後の確認も計画に含める。想定外の利用が見つかった場合に誰へ連絡するか、どの記録から影響範囲を追うかを決めておく。停止した当日に問い合わせがなかったことだけで、すべての周期の仕事を確認したことにはしない。
二重運用を終える判断は、新システムの成功を祝う判断とは別である。旧環境の業務上の役割をなくし、必要な記録を別に残し、現実に使える復帰策を確かめる。その三つを分けて完了させることで、止める決定にも、限定して残す決定にも根拠を持たせられる。