資格道場 › レッスン一覧 › システム開発技術

システム開発技術・12/12・9分

システム移行と保守

ゴール

システム移行の方式（一斉・段階・並行・パイロット）の特徴と、移行テスト・移行計画（切戻し基準）・保守の手順・利用者マニュアルの構成を区別して、該当する過去問の正しい選択肢を選べるようになる。

システムは作って終わりではなく、旧システムから乗り換えて何年も使い続けます。この乗り換えと保守の段階の事故は業務停止に直結するため、試験では「安全に切り替える」「確実に直す」という考え方がよく問われます。

このレッスンで稽古する（用語チェック・過去問）

結論：移行は「切り替え方」と「失敗したときの戻り方」で考える

システム移行とは、旧システムで動いている業務とデータを新システムへ乗り換えることです。試験で問われるのは主に3点です。

どう切り替えるか（移行方式：一斉・段階・並行・パイロット）
切り替え手順を事前に試したか（移行テスト）
失敗したら旧システムに戻せるか（移行計画の切戻し基準）

リリース後は保守（不具合の修正や機能変更）の段階に入ります。ここでは「本番環境を直接いじらない」「完了を記録する」が基本ルールです。

移行方式の4分類（最頻出）

引っ越しにたとえると分かりやすくなります。一斉移行は「全部の荷物を一晩で新居に運ぶ」、並行運用は「しばらく旧居も借りたまま両方で暮らす」方式です。

方式	やり方	長所	短所（試験で問われる特徴）
一斉移行（一括移行）	ある時点で全てを新システムへ切り替える	期間が短く、費用が安い	移行トラブルの影響が大きい（全業務が一度に止まる）
段階移行	機能・拠点ごとに少しずつ切り替える	トラブルの影響範囲が小さい	移行途中は新旧が混在するため、新旧をつなぐアプリケーション（中継の仕組み）が必要
並行運用（並行移行）	新旧を同時に動かし、結果を比べてから新へ移る	新が失敗しても旧で業務を続けられ、安全性が最も高い	二重に動かす運用コストと手間がかかる
パイロット移行	一部の部門・拠点で先に試し、問題がなければ全体へ広げる	小さく試して問題を早く見つけられる	全体の完了まで時間がかかる

見分け方のコツ：選択肢の文が「影響が大きい」なら一斉、「接続するアプリケーション」なら段階、「並行させて運用」「運用コスト」なら並行運用です。

4つの移行方式で、旧システムと新システムがいつ動いているかを時間軸に並べた図。

移行テストの目的：切替え手順を確認する

移行テストとは、本番の切り替えの前に、旧システムから新システムへの切替え手順そのものと、切替えに伴う問題点を確認するテストです。確実に切り替えられるか、決められた時間内に終わるか（効率性）を見ます。

ほかのテストと取り違えさせる問題が出ます。

テスト	確認すること
移行テスト	旧→新への切替え手順と、切替えで起きる問題
性能テスト	実データ相当の量で、十分な処理性能が出るか
結合テスト（インタフェースの確認）	既存の他システムや他プログラムとのインタフェースの整合性
受入れテスト	新システムが要求された機能を全て満たしているか（利用者側が確認）

「移行」という言葉が付いていたら、キーワードは切替えです。

移行計画の留意点：切戻し基準を決めておく

切戻し（フォールバック）とは、移行作業が失敗したときに旧システムへ戻すことです。移行計画書には、どんな状態になったら旧システムに戻すかの判断基準を事前に書いておく必要があります。当日その場で判断すると、決断が遅れて業務停止が長引くからです。

試験で誤りとして出る記述も押さえておきましょう。

「データ量が多いほど切替え直前に一括で移す」→ 誤り。量が多いほど時間がかかり失敗リスクが高まるので、事前に一部を移しておくなどして分散する
「新旧で環境の一部を共有すると確認が容易」→ 誤り。共有すると互いに影響し、問題の切り分けが難しくなる
「並行運用で費用が下がる」→ 誤り。二重運用なので費用は増える

切戻しの判断基準を事前に決めておくと移行当日にすぐ判断でき、決めていないと決断が遅れて業務停止が長引く。

アプリケーション保守の手順：本番は直接触らず、完了を記録する

保守では、変更を申請→承認→修正→テスト→承認→本番へ反映→完了記録の流れで管理します。本番環境のプログラムを置く場所を本稼働用ライブラリと呼びます。

完了を記録する：保守作業が途中で放置されるのを防ぐため（正解の考え方）
本稼働用ライブラリを直接更新しない：変更が簡単に見えても、テストと承認を経てから反映する
担当者のテスト終了＝完了ではない：承認を受けて本番に反映し、記録して初めて完了
テスト後すぐに本番登録→事後報告は誤り：登録の前に承認を受ける

アプリケーション保守の正しい流れと、試験で誤りとして出る近道を並べた図。

組込みシステムの開発環境の維持管理

製品を出荷した後も、不具合修正などの保守で開発環境（専用の開発ツールや評価用の機材）が再び必要になります。そのため、使用頻度に関係なく、定期的に動作確認をして維持管理するのが正解です。「製品化したら不要」「最新に更新し続ける」（更新すると当時の製品を再現できなくなる恐れがある）、「レンタル品はレンタル会社がずっと保持してくれる」は誤りです。

利用者マニュアルの構成：チュートリアルは「例題で一通り」

利用者向けマニュアルの各章の役割を区別させる問題が出ます。

章	書く内容
序文	マニュアルの目的（何のために作ったか）
始めるに当たって	マニュアルの使い方、ソフトウェアの概略と特徴、必要な機器
チュートリアル	基本的な考え方と操作手順を、例題を使って一通り体験させる
リファレンス	機能を詳細に、調べたい箇所が見つけやすいよう整理して説明（辞書的）
付録・用語解説・索引	補足情報、用語の意味、語句からの逆引き

チュートリアルは「教習所の路上練習」、リファレンスは「辞書」と覚えると混同しません。

試験での問われ方

一斉移行の特徴を問う問題は、同じ4択がほぼそのまま繰り返し出ています。正解は「移行時のトラブルの影響が大きい」で、残り3つは段階移行・並行運用の特徴です
移行テストは、性能テスト・結合テスト・受入れテストの説明を並べてきます。「切替え手順」の語が入った選択肢を選びます
移行計画は「切戻しの判断基準が必要」が正解の定番です
保守は「完了を記録」が正解で、「直接更新」「テスト終了で完了」が誤りとして並びます

要点（試験直前に読む）

一斉移行の特徴は「移行時のトラブルの影響が大きい」。新旧を接続するアプリが必要なのは段階移行、運用コストがかかるのは並行運用。
移行テストの目的は「旧から新への切替え手順と、切替えに伴う問題点の確認」。
移行計画書には、失敗したときに旧システムへ戻す判断基準（切戻し基準）を書いておく。
保守では本番ライブラリを直接更新せず、承認を経て反映し、完了を記録して放置を防ぐ。
組込みの開発環境は、製品化後も使用頻度に関係なく定期的に動作確認して維持する。
チュートリアルは例題を使って一通り操作を体験させる章、リファレンスは詳細を調べる辞書的な章。

ひっかけ

一斉移行の問題で、並行運用の特徴（新旧を並行運用する・運用コストがかかる）や段階移行の特徴（新旧を接続するアプリ）を混ぜてくる。「全部を一度に」から考えれば、影響が大きいの1択になる。
移行テストの問題で、性能・インタフェース・要求機能の確認を並べてくる。「移行」なら「切替え」の語がある選択肢を選ぶ。
「データ量が多いほど直前に一括移行」「並行運用で費用が下がる」は、もっともらしいが誤り。量が多いほど分散し、二重運用は費用が増える。
保守で「簡単な変更なら本番を直接更新」「担当者のテスト終了で完了」は誤り。承認と完了記録が抜けている選択肢は外す。
マニュアルの章の問題では、リファレンス（詳細に整理）・序文（目的）・始めるに当たって（概略や必要機器）の説明が並ぶ。チュートリアルは「例題で一通り」。

用語（12）

一斉移行 いっせいいこう
ある時点で旧システムの全てを一度に新システムへ切り替える方式で、短期間・低コストだがトラブルの影響が大きい。
⚠ 並行運用と混同しやすい。新旧を同時に動かすなら並行運用、一度に全部切り替えるなら一斉移行。

段階移行 だんかいいこう
機能や拠点ごとに少しずつ新システムへ切り替える方式で、移行途中は新旧が混在する。
⚠ パイロット移行と似ている。段階移行は全体を順番に移す方式、パイロット移行は一部で試してから全体に広げる方式。「新旧間を接続するアプリケーションが必要」は段階移行の特徴。

並行運用 へいこううんよう
新旧システムを一定期間同時に動かし、結果を比べて問題がないことを確かめてから新システムへ移る方式。
⚠ 安全性は最も高いが、二重運用の運用コストがかかる。「費用が下がる」は誤り。

パイロット移行 ぱいろっといこう
一部の部門や拠点で先に新システムを導入し、問題がないことを確認してから全体に広げる方式。
⚠ 段階移行との違いは、最初の一部が「試行」の役割を持つ点。

移行テスト いこうてすと
旧システムから新システムへの切替え手順と、切替えに伴う問題点を本番前に確認するテスト。
⚠ 性能テスト（処理性能）、結合テスト（インタフェースの整合性）、受入れテスト（要求機能を満たすか）と区別する。キーワードは「切替え」。

移行計画 いこうけいかく
移行の方式・手順・日程・体制や、失敗時の切戻しの判断基準をまとめた計画。

切戻し きりもどし（フォールバック）
移行作業が失敗したときに、新システムの利用をやめて旧システムに戻すこと。
⚠ 判断基準は当日ではなく、事前に移行計画書へ書いておく。

アプリケーション保守 あぷりけーしょんほしゅ
稼働中のアプリケーションの不具合修正や機能変更を、承認・テスト・記録の手順に沿って行う作業。
⚠ 担当者のテストが終わった時点では完了ではない。承認を経て本番に反映し、完了を記録して初めて完了。

本稼働用ライブラリ ほんかどうようらいぶらり
本番環境で実際に使われるプログラムを保管する場所。
⚠ 変更が簡単でも直接更新してはいけない。テストと承認を経てから登録する。

開発環境の維持管理 かいはつかんきょうのいじかんり
製品化した後の保守に備えて、開発に使ったツールや機材を使用頻度に関係なく定期的に動作確認して保持すること。
⚠ 「最新版に更新し続ける」は誤り。当時の製品を再現できる状態を保つことが目的。

チュートリアル ちゅーとりある
利用者マニュアルのうち、基本的な考え方と操作手順を例題を使って一通り説明する章。
⚠ リファレンス（機能を詳細に整理した辞書的な章）と取り違えやすい。「例題で一通り」ならチュートリアル。

リファレンス りふぁれんす
利用者マニュアルのうち、機能を詳細に説明し、知りたい箇所を見つけやすいように整理した章。
⚠ チュートリアルは学ぶための章、リファレンスは調べるための章。

このレッスンの過去問

このレッスンで稽古する

← デバッグ・テスト支援ツールと品質の測り方