基本情報 令和元年度 秋期 問56：マネジメント系に関する問題

答えは a「旧システムに戻す判断基準が必要」 です。

新システムへの引っ越し（移行）は、もし失敗したら戻る道も用意しておかないと危険。

引越しで「家具搬入したけど住めなかった」となったら、元の家に戻れるようにしておきますよね。それと同じ。

👉 覚え方：前進プランと撤退プラン、両方用意。

ほかの選択肢：b 一括移行＝リスク高／c 環境共有＝事故の元／d 並行運用は費用が増える（減らない）。

なぜこれが正解か

正解は a。システム移行計画では移行失敗時の切り戻し（フォールバック／ロールバック）判断基準を事前定義することが必須。「いつ、何が起きたら、どう戻すか」が明文化されていないと、障害発生時に意思決定が遅れ被害が拡大する。

各選択肢の解説

• b 一括移行：データ量が多いほど作業時間長くなりリスク増大。段階移行（分割／パイロット／並行）が推奨される。
• c 新旧環境一部共有：データ不整合・依存関係でかえって複雑化。完全分離が安全。
• d 並行運用で費用低減：並行運用は両システム稼働でコストが増加（人件費・ハードウェア）。

覚え方・ひっかけ注意

システム移行の主要方式：

• 一括移行（Big Bang）：一気に切替。短期・高リスク
• 段階移行（Phased）：機能・地域・組織別に段階切替。中期・中リスク
• 並行運用（Parallel）：旧新両方稼働で比較。長期・低リスク・高コスト
• パイロット移行：一部組織で先行検証

移行計画には必ず切り戻し基準・手順・責任者・連絡先を含める。

理論的背景

システム移行はITサービスマネジメント（ITIL／ISO/IEC 20000）の変更管理／リリース管理／展開管理の文脈で語られる。PMBOKではプロジェクト統合管理、リスク管理、ステークホルダ管理にまたがる。移行計画は次の要素を含む：

• 移行方式：一括／段階／並行／パイロット
• 移行手順書：作業順序、責任者、所要時間
• データ移行計画：ETL設計、データクレンジング、検証クエリ
• 切り戻し基準（Rollback Criteria）：定量・定性基準で発動条件を明示
• コンティンジェンシープラン：想定外事象への対応
• コミュニケーション計画：ステークホルダ通知
• テスト計画：移行リハーサル、本番前総合確認

移行リスクと対策

• データ損失：完全バックアップ、データ検証スクリプト、件数／ハッシュ照合
• 性能劣化：性能テスト、負荷テストで事前検証
• 互換性問題：API契約テスト、契約による設計
• 業務停止時間（ダウンタイム）：Blue/Green Deployment、ローリングアップデート、Canary Release
• ユーザ混乱：トレーニング、マニュアル、ヘルプデスク強化

現代的な移行戦略

• Blue/Green Deployment：新旧2環境を並行運用、瞬時切替＋瞬時切戻し
• Canary Release：少数ユーザに先行リリースして検証
• Feature Flag／Toggle：機能単位でON/OFFを制御。LaunchDarkly、Unleash
• Strangler Fig Pattern（Martin Fowler）：レガシーを少しずつ新システムに置換
• データベース変更：Expand-Contract Pattern（追加→移行→削除の段階）
• ゼロダウンタイムデプロイ：CI/CDパイプライン、Kubernetes Rolling Update

クラウド移行の6R

• Rehost（Lift & Shift）：そのまま移行
• Replatform：軽微な最適化
• Repurchase：SaaS置換
• Refactor：再設計
• Retire：廃止
• Retain：現状維持

試験での位置づけ

基本情報・応用情報・ITサービスマネージャ・プロジェクトマネージャ・システムアーキテクトで頻出。直近はクラウド移行、レガシーマイグレーション、DXの文脈で出題増加。

選択肢の発展補足

並行運用は安全だが、データ二重入力／同期コスト・人的負荷が高い。Active-Active同期でクラウド移行する場合、データベースレプリケーション（Oracle GoldenGate、AWS DMS、Striim等）でリアルタイム同期し、フェーズドカットオーバーで切替リスクを下げる。経済産業省『DXレポート』が指摘する「2025年の崖」では基幹システム刷新が課題で、本問のような基本的移行計画策定が再注目されている。