はじめに
システム開発や基盤更改プロジェクトでは、新しいシステムを構築することに意識が向きがちです。
しかし、どれだけ優れたシステムを構築できたとしても、既存システムから新システムへ安全に移行できなければ、本番稼働を迎えることはできません。
実際のプロジェクトでは、
- データ移行に想定以上の時間がかかった
- 外部システムとの連携がうまく動作しなかった
- 移行リハーサル不足で本番切替に失敗した
といった問題が発生することがあります。
特に近年はクラウド移行や大規模システム更改が増えており、移行作業そのものがプロジェクトの成否を左右するケースも少なくありません。
IPAの非機能要求グレードでは、このようなシステム移行に関する要件を「移行性」として整理しています。
非機能要求グレードがそもそも何か？については以下の記事にまとめています。
インフラ要件定義で役立つ「非機能要求グレード」とは？実務で感じたメリットと注意点
今回は、移行性の考え方や要件定義で確認しておくべきポイントについて解説します。
移行性とは何か
移行性とは、現行システムの資産を新システムへ移行するための要求です。
システム更改では、
- サーバ
- ネットワーク
- ミドルウェア
- データ
- 外部連携
など、多くの資産を新環境へ引き継ぐ必要があります。
特に重要なのがデータです。
システムは完成していても、業務データが移行されていなければ利用することはできません。
そのため、移行性では単なるシステム構築だけではなく、
「どのように新システムへ切り替えるか」
までを含めて検討する必要があります。
IPAの非機能要求グレードでは、移行性を以下の5つの観点で整理しています。
- 移行時期
- 移行方式
- 移行対象（機器）
- 移行対象（データ）
- 移行計画
実務でも、この5つを整理することで移行に関するリスクを大きく減らすことができます。
移行時期はシステム停止時間と密接に関係する
移行性を検討する際に最初に確認するのが移行時期です。
要件定義では、
- いつ切り替えるのか
- システム停止は可能か
- 並行稼働が必要か
を整理します。
例えば、
土日に停止できる業務システムであれば、
金曜日夜に停止し、月曜日朝から新システムを利用開始するという方法が考えられます。
一方で、
- 金融システム
- ECサイト
- 物流システム
などは長時間停止できない場合があります。
その場合は、
- 段階的移行
- 並行稼働
- リアルタイムデータ同期
などの仕組みが必要になります。
実務でよくあるのは、
「停止できると思っていたが実際は停止できなかった」
というケースです。
特定業務や外部連携システムの都合で想定以上に停止制約が厳しいこともあります。
そのため、移行時期や停止可能時間は早い段階で関係者と合意しておくことが重要です。
移行方式は一斉切替か段階切替かを決める
移行方式では、新システムへの切り替え方法を検討します。
代表的な方法として、
- 一斉切替
- 段階切替
があります。
一斉切替は、ある時点で旧システムを停止し、新システムへ切り替える方法です。
構成がシンプルで運用管理もしやすい反面、切替時の失敗リスクが高くなります。
一方、段階切替は、
- 拠点ごと
- 部門ごと
- 機能ごと
に順番に移行していく方法です。
例えば全国展開システムであれば、
東京拠点
↓
大阪拠点
↓
名古屋拠点
のように移行するケースがあります。
リスクを分散できるメリットがありますが、新旧システムが共存する期間が長くなります。
そのため、
- データ同期
- 運用管理
- 障害対応
などの難易度は高くなります。
実務では「段階移行の方が安全」と考えられがちですが、新旧システムの共存期間が長くなることで別のリスクが発生することもあるため注意が必要です。
移行対象の洗い出しが移行計画の第一歩
移行計画で最も重要なのが移行対象の整理です。
移行対象は大きく、
- 機器
- データ
の2つに分類できます。
機器移行では、
- サーバ
- ストレージ
- ネットワーク機器
- ソフトウェア
などを対象とします。
特に既存資産を継続利用する場合は注意が必要です。
例えば、
- 保守期限切れ
- OSサポート終了
- 新環境との互換性不足
などの問題が発生することがあります。
実務ではコスト削減のために既存機器を利用したいという要望もありますが、結果的に将来の更改コストが増加するケースもあります。
そのため、継続利用の可否は慎重に判断する必要があります。
データ移行は想像以上に難しい
移行プロジェクトで最もトラブルになりやすいのがデータ移行です。
実際のプロジェクトでも、
「移行はデータをコピーするだけ」
と考えていた結果、大幅なスケジュール遅延につながることがあります。
確認すべき項目としては、
- データ量
- データ形式
- 保管媒体
- 変換ルール
などがあります。
例えば、
CSVからCSVへの移行であれば比較的容易です。
しかし、
- 文字コード変更
- 項目追加
- データ型変更
- 業務ルール変更
などが発生すると、変換ツールの開発が必要になる場合があります。
また、長年運用されているシステムでは、
- 不正データ
- 重複データ
- 未使用データ
が大量に存在することもあります。
そのため実務では、
「移行するデータ」と「移行しないデータ」
を整理する作業も重要になります。
移行データ量が数TBを超えるようなシステムでは、移行時間そのものが大きな課題になることもあります。
移行リハーサルは必ず実施する
移行作業で最も重要なのがリハーサルです。
実務では、
「手順書があるから大丈夫」
と考えることがありますが、本番で初めて実施する移行作業は非常に危険です。
そのため、
- データ移行
- システム切替
- 外部連携
- 動作確認
を含めたリハーサルを実施します。
特に外部システムとの連携がある場合は注意が必要です。
新旧システムで接続方式が変更されるケースもあり、想定外のトラブルが発生することがあります。
また、リハーサルでは作業時間も重要です。
本番切替で利用できる時間が12時間しかないのに、リハーサルで15時間かかっているようでは成功できません。
実際のプロジェクトでもリハーサルによって問題点が発見されることは非常に多いため、十分な回数を確保することが重要です。
切り戻し計画まで準備しておく
移行作業では成功だけでなく失敗も想定しなければなりません。
そのため、切り戻し計画が重要になります。
例えば、
- 何時までに判断するか
- 誰が判断するか
- どの手順で戻すか
を事前に決めておきます。
実務では、
「ここまで進んだから戻れない」
という状況が最も危険です。
移行失敗時に無理やり続行すると、業務停止やデータ不整合につながる可能性があります。
そのため、
- 判断基準
- 判断者
- 切り戻し手順
を移行計画書に明記しておくことが重要です。
また、本番移行時には関係者を待機させ、トラブル発生時に迅速に対応できる体制も必要になります。
まとめ
移行性は、新システムを安全に本番稼働させるために欠かせない非機能要件です。
特に重要なのは、
- 移行時期を明確にすること
- 適切な移行方式を選択すること
- 移行対象を整理すること
- データ移行を十分に検討すること
- リハーサルを実施すること
- 切り戻し計画を準備すること
です。
実務ではシステム構築に注力するあまり、移行計画の検討が後回しになることがあります。
しかし、移行に失敗すればシステムが完成していても利用することはできません。
IPAの非機能要求グレードの移行性は、そうしたリスクを未然に防ぐための有効なフレームワークです。
システム更改やクラウド移行を担当する際は、構築だけでなく移行性の観点もしっかり検討し、安全なシステム切替を実現していきましょう。
コメント