「移行計画書のドラフトができたので、内容をご確認ください」——ベンダーからこう言われて、急に不安になっていませんか。分厚い資料を渡されても、どこを見れば危ないのか、自分は何をOKすればいいのか、専門知識がないと判断のしようがありません。
システム移行は、現行システムを止めずに新環境へ切り替える、失敗が許されない作業です。データが一部消えただけでも業務が回らなくなり、移行当日にトラブルが起きれば翌朝の窓口業務が止まってしまう——そんな事態を想像すると、安易にハンコを押すのは怖いものです。とはいえ「全部ベンダーにお任せ」では、いざ問題が起きたときに「それは御社の判断する部分でした」と言われかねません。
実は、移行計画書には発注者が必ず読むべき急所があり、そこさえ押さえれば専門家でなくても危険のサインを察知できます。さらに、移行の成否を分けるタスクの中には「発注者にしか担えないもの」が確実に存在します。これを知らずに丸投げすると、最も失敗しやすいポイントを誰も見ていない状態になってしまうのです。
本記事では、システム移行計画とは何かをまず整理したうえで、移行計画書に含まれる項目を「発注者がどう読むか」という視点で解説します。さらに、移行方式の選び方、発注者だけが担う責任の範囲、そして承認前に必ず確認すべきチェックリストまでを、専門知識がなくても判断できる形でお伝えします。読み終える頃には、次の打ち合わせでベンダーに具体的な質問ができる状態になっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
システム移行計画とは？発注者が押さえる全体像
システム移行計画とは、ひとことで言えば「現行システムを新しい環境へ安全に移すための実行計画を文書にまとめたもの」です。この文書を一般に「移行計画書」と呼び、いつ・何を・どの方式で・誰が移すのかを取り決めます。
そもそも「移行（マイグレーション）」とは何か、データ移行とどう違うのかといった概念から押さえたい場合は、マイグレーションとはやデータ移行とはもあわせてご覧ください。本記事は概念の解説は最小限にとどめ、「計画」のフェーズ——とくに発注者が移行計画書をどう読み、どこを承認前に確認すべきか——に絞ってお伝えします。
ここで強調しておきたいのは、移行計画書は「ベンダーが書いて発注者がサインするだけの文書」ではない、という点です。移行を成功させるには、発注者（とくに現場の業務部門）が果たすべき役割が必ずあります。移行計画書は、その役割分担を含めた「関係者全員のための地図」だと捉えてください。
移行計画書が果たす役割 — 関係者の認識を合わせる地図
移行計画書の最大の役割は、ベンダーと発注者、そして社内の各部門が「同じ絵を見て動く」状態を作ることです。
移行プロジェクトには、開発会社のエンジニアだけでなく、実際にシステムを使う業務部門、データの正誤を知る担当者、当日に問い合わせ対応する窓口など、多くの人が関わります。誰が・いつ・何をするかが文書で共有されていないと、「それはベンダーがやると思っていた」「そのデータは使わないはずだった」といった認識のズレが生まれ、これが移行失敗の典型的な原因になります。
実際、移行対象データの選定に見落としがあり、本番移行時まで誰も気づかないと、業務に必要なデータが揃わずに移行そのものが失敗してしまうという指摘もあります（NTTドコモビジネス）。移行計画書は、こうした「認識のズレ」を事前につぶすための合意書なのです。
移行プロジェクトの流れと「計画フェーズ」の位置づけ
移行計画書がプロジェクト全体のどこに位置するかを押さえておくと、何を確認すべきかが見えてきます。システム移行は、おおむね次の流れで進みます。
- 要件定義: 新システムに何を求めるか、何を移すかの大枠を決める
- 移行計画の策定: 移行方式・スケジュール・対象・体制を文書化する（＝移行計画書）
- 移行リハーサル: 本番に近い環境で移行作業を予行演習し、所要時間や問題点を洗い出す
- 本番移行: 計画に沿って実際にデータと業務を新システムへ切り替える
- 定着・運用: 新システムでの業務を安定させ、現行システムを停止する
発注者がこの記事で扱う「計画フェーズ」は、ステップ2にあたります。ここで承認した内容が、その後のリハーサルや本番移行のすべてを規定します。つまり、計画段階での確認を怠ると、後工程でいくら頑張っても取り戻せません。承認前のチェックがいかに重要かが分かる流れです。
移行計画書に含まれる主な項目と発注者の読み方
ここからは、移行計画書に通常含まれる主な項目を、「発注者はここを読む・こう質問する」という視点で見ていきます。ベンダーが何を書くかではなく、受け取った側がどこに注意すべきかに着目してください。
代表的な項目と、発注者としての確認ポイントを一覧にまとめます。
項目 | 何が書かれるか | 発注者の確認ポイント |
|---|---|---|
移行方針・目的 | なぜ移行するか、どこまでを範囲とするか | 自社が刷新で実現したかった目的とズレていないか |
移行対象・範囲 | 移すデータ・機能、移さないものの線引き | 「移さない」とされたデータが本当に不要か、現場に確認したか |
移行方式 | ビッグバン／段階移行／並行運用のどれか | 自社の業務都合（停止できる時間など）に合っているか |
スケジュール | 各作業の日程とマイルストーン | 繁忙期や決算と重なっていないか、予備日があるか |
移行体制・役割分担 | ベンダー・発注者それぞれの担当 | 自社が担うタスクが明記され、実行可能か |
移行テスト・リハーサル | 予行演習の回数・環境 | 本番相当の環境で複数回計画されているか |
切り戻し（ロールバック） | 失敗時に元に戻す手順と判断基準 | 中止判断の基準と判断者が明記されているか |
このうち「移行方式」「役割分担」「切り戻し」は、とくに発注者が見落としやすく、かつ失敗に直結しやすい急所です。それぞれ後の章で詳しく扱います。ここでは、まず基本となる3項目を掘り下げます。
移行方針・移行対象・移行範囲 — 「何を移し、何を捨てるか」の合意
移行計画書の冒頭には、移行の方針と対象範囲が書かれます。発注者がここで確認すべきは、「移さない」と線引きされたものが本当に不要か、という点です。
長年使ってきたシステムには、現場が日常的に参照している古いデータや、特定の担当者しか把握していない運用が紛れています。ベンダーは技術的に移行作業を担えますが、「このデータは業務上まだ必要かどうか」は、実際に使っている発注者側にしか判断できません。ここを安易に「不要」としてしまうと、移行後に「あのデータが見られない」というトラブルが起きます。
移行範囲のページを読むときは、必ず利用部門の担当者にも目を通してもらい、「これがなくなって困らないか」を現場目線で確認してください。
スケジュールとマイルストーン — 予備日と業務カレンダーの整合
次に確認すべきはスケジュールです。ここでの着眼点は2つあります。
ひとつは、移行作業の日程が自社の業務カレンダーとぶつかっていないかです。月末の締め処理、決算期、繁忙期などに本番移行を重ねると、万一トラブルが起きたときの被害が跳ね上がります。提示された日程が自社にとって無理のないタイミングか、業務部門の視点で確認しましょう。
もうひとつは、スケジュールに「予備日（バッファ）」があるかです。移行作業は予定どおり終わらないことが珍しくありません。リハーサルで問題が見つかれば修正に時間がかかりますし、本番当日に想定外が起きることもあります。予備日がまったく組まれていないスケジュールは、一度でもつまずくと後ろの予定がすべて崩れる危険な計画です。「もし当日うまくいかなかったら、いつまでにやり直せますか」とベンダーに尋ねてみてください。
移行体制と役割分担 — 連絡体制と緊急時の指揮系統
移行計画書には、ベンダーと発注者それぞれの担当範囲を示した体制図や役割分担表が含まれます。発注者がここで確認すべきは、自社が担うタスクが明記されているか、そしてそれを実際に実行できる体制が社内にあるか、です。
加えて見ておきたいのが、緊急時の連絡体制です。移行当日にトラブルが起きたとき、誰が誰に連絡し、最終的に誰が「続行か中止か」を判断するのか。この指揮系統が曖昧なまま当日を迎えると、いざというときに判断が止まり、被害が拡大します。連絡先一覧と判断者が計画書に書かれているかを確認しましょう。
移行方式の種類と発注者の業務都合での選び方
移行計画書で最も技術的に見える項目が「移行方式」です。しかし、方式の選択は本来、技術論ではなく「自社の業務をどこまで止められるか」という発注者側の都合で決まるものです。ここでは3つの方式を、業務影響の観点から比較します。
主な移行方式は次の3つです（発注ラウンジ、アールワークス）。
方式 | やり方 | 向いているケース | 発注者側の負担 |
|---|---|---|---|
ビッグバン（一括） | すべてを一度に切り替える | まとまった停止時間を確保できる | 当日の業務停止を許容する必要がある |
段階移行 | 業務・機能ごとに順次切り替える | 長期の停止が難しい | 移行期間が長期化し、複数回の対応が必要 |
並行運用 | 新旧を一定期間同時に動かし検証する | 失敗が絶対に許されない基幹業務 | 二重入力など現場の作業負荷が大きい |
ビッグバン方式（一括移行）が向くケース・注意点
ビッグバン方式は、現行システムから新システムへ一度に切り替える方法です。工程がシンプルで全体が把握しやすく、移行にかかる作業負荷やコストを抑えやすいのが利点です。
一方で、切り替えのために業務を完全に停止させる必要があるため、業務への影響が大きくなります。発注者として確認すべきは、「業務を止められるまとまった時間（たとえば連休や夜間）を確保できるか」です。この窓が取れる業務であればビッグバン方式は有力ですが、止められない時間帯にトラブルが起きると一気に被害が広がる点には注意が必要です。
段階移行・並行運用が向くケース・現場の負荷
長時間の業務停止が難しい場合は、段階移行や並行運用が候補になります。
段階移行は、業務や機能ごとに順番に切り替えていく方式で、まとまった停止期間を取らずに進められます。ただし移行作業が複数回に分かれるため、期間が長期化し、その都度の確認やテストの手間が増えます。
並行運用は、新旧のシステムを一定期間あわせて動かし、両者の結果を突き合わせて検証する方式です。最も確実に移行できる一方で、新旧両方にデータを入力する「二重入力」が発生し、現場の担当者に大きな負担がかかります。発注者として確認すべきは、「現場がこの二重作業の期間に耐えられるか」です。机上では安全な方式でも、現場が疲弊して入力ミスが増えれば本末転倒になります。
方式選択を左右する発注者側の前提
どの方式が適切かは、最終的に次のような発注者側の前提条件で決まります。
- 業務を止められる時間がどれだけあるか: 長い停止窓が取れるならビッグバン、取れないなら段階移行・並行運用
- データ量の大きさ: 移行データが膨大なほど作業時間が読みにくく、予備日や段階移行の検討が必要
- 繁忙期・決算期との距離: 業務影響が小さい時期に本番を設定できるか
- 現場の人的余力: 並行運用の二重入力に耐えられる人員がいるか
これらは技術ではなく業務の話なので、発注者がベンダーに伝えるべき情報です。「うちは月末3日間は絶対に止められない」「繁忙期は7月」といった前提を最初に共有すれば、ベンダーは現実的な方式を提案しやすくなります。方式の議論は、こうした自社の事情を起点にすると、専門知識がなくても対等に進められます。
発注者だけが担えるタスクと責任分界点
ここが本記事の核心です。移行を成功させるタスクの中には、ベンダーには代われない「発注者しか担えないもの」が確実にあります。これを知らずに丸投げすると、最も失敗しやすいポイントを誰も見ていない状態になってしまいます。
責任分界の考え方をシンプルに整理すると、次のようになります。
- ベンダーの責任: 技術的な移行作業（データの変換・移送、新環境の構築、移行ツールの実行など）
- 発注者の責任: 業務的な判断（どのデータが正しいか、何が必要か、いつ業務を止められるか、現場をどう動かすか）
ベンダーはデータを「正確に移す」ことはできますが、「そのデータが業務的に正しいか」までは判断できません。この線引きを押さえておくと、自社が何をすべきかが見えてきます。
データの正誤・クレンジングは発注者にしか判断できない
移行で最もトラブルになりやすいのがデータです。長年運用してきたシステムには、重複した顧客情報、使われなくなった古いコード、入力ミスがそのまま残っているレコードなどが蓄積しています。これらを整理せずに移行すると、新システムにゴミデータごと持ち込むことになります。
この「どのデータが正しく、どれが不要か」を判断する作業（データクレンジング）は、データの中身と業務を知っている発注者にしかできません。ベンダーは「この項目が空欄のレコードが1万件あります」とは報告できても、「その1万件は移すべきか捨てるべきか」は判断できないのです。
データ移行が失敗する大きな原因のひとつが、まさにこの移行対象データの選定ミスです（グランパズ）。移行計画書を承認する前に、「データのクレンジングは誰が、いつまでにやるのか」が明記されているかを必ず確認してください。ここが空欄なら、それは発注者の宿題になります。
利用部門を巻き込むリハーサルと受け入れテスト
移行のリハーサルや、新システムが業務で使えるかを確認する受け入れテストは、ベンダーだけで完結しません。実際に業務を回す利用部門が参加して、初めて「現場で本当に使えるか」が分かります。
情報システム担当者がひとりで確認しても、現場特有の操作や例外的な業務までは見きれません。リハーサルや受け入れテストの計画に、利用部門の参加が組み込まれているかを確認しましょう。組み込まれていなければ、「本番で初めて現場が触る」という危険な状態になります。発注者として、現場のキーパーソンを巻き込むのは自社の役割です。
移行当日の業務調整・社内周知・問い合わせ窓口
本番移行の当日とその前後は、業務側の調整が欠かせません。これも発注者の担当領域です。
- 業務調整: 移行作業中に業務を止める場合、いつからいつまで止めるかを各部門と調整し、合意を取る
- 社内周知: 「この日は旧システムが使えません」「新システムのログイン方法が変わります」といった案内を全社に行き渡らせる
- 問い合わせ窓口: 切り替え直後は現場から質問が殺到する。誰が答えるのかを事前に決めておく
これらはベンダーには手の出せない、社内の調整ごとです。移行計画書に技術的な手順がいくら緻密に書かれていても、この業務調整が抜けていると、当日になって「現場が新システムを使えず混乱する」事態になります。計画書を読みながら、「自社側でこの周知と窓口は誰がやるか」を並行して考えておきましょう。
失敗を防ぐ承認前チェック — 切り戻し・リハーサル・予備日
最後に、移行計画書を承認する前に発注者が必ず確認すべき急所を、チェックリストの形でまとめます。ここに挙げる項目が計画書に書かれていなければ、サインを保留してベンダーに差し戻すべきサインです。
切り戻し（ロールバック）基準と中止判断のルール
移行で最も重要な安全装置が、切り戻し（ロールバック）です。これは、移行作業中に重大な問題が起きたとき、システムを移行前の状態に戻して業務を守る仕組みです。
確認すべきは、次の3点が計画書に明記されているかです。
- 切り戻しの手順: どうやって元の状態に戻すか
- 中止の判断基準: どんな状況になったら「移行を中止して元に戻す」と決めるのか
- 判断者: その中止を誰が決定するのか
移行中に緊急事態が発生した場合に、移行前の状態へ切り戻すかどうか、その手順をあらかじめ計画しておくことが重要だとされています（シースリーインデックス）。とくに「いつ・誰が中止を決めるか」が曖昧だと、当日トラブルが起きても誰も止める判断ができず、被害が広がります。切り戻しの記載が薄い計画書は危険信号です。
リハーサルの回数・環境・予備日の確保
移行の成否は、リハーサル（予行演習）の質で大きく変わります。確認ポイントは次の3つです。
- 本番に近い環境か: サーバーのスペックやデータ量を本番と同じ条件で行うと、所要時間や問題点が正確に分かります
- 複数回計画されているか: 1回のリハーサルで問題が出れば、修正して再度確認する必要があります。少なくとも2回は実施するようスケジュールを組むことが推奨されています
- 予備日があるか: リハーサルや本番でつまずいたときにやり直せる余地が日程に確保されているか
リハーサルは本番に近い環境で行う必要があり、複数回の実施が望ましいとされています（エンジニアtype）。リハーサルが1回しか組まれていない、または本番とかけ離れた環境で行う計画は、「ぶっつけ本番に近い」と捉えて、回数と環境をベンダーに確認してください。
承認前チェックリスト（まとめ表）
これまでの内容を、承認前に確認すべきチェックリストとして一覧にまとめます。次の打ち合わせで、この表を手元に置いてベンダーに確認してみてください。
# | 確認項目 | 書かれていなければ |
|---|---|---|
1 | 切り戻し（ロールバック）の手順・中止基準・判断者が明記されているか | 当日トラブル時に誰も止められない。差し戻し |
2 | リハーサルが本番相当の環境で複数回計画されているか | ぶっつけ本番のリスク。回数・環境を確認 |
3 | スケジュールに予備日（バッファ）があるか | 一度のつまずきで全日程が崩壊。追加を依頼 |
4 | 緊急時の連絡体制・判断フローが明示されているか | 当日に判断が止まる。体制図を要求 |
5 | バックアップ取得が移行前提に組み込まれているか | 切り戻しの土台が欠ける。必須で確認 |
6 | データクレンジングの担当・期限が明記されているか | 自社の宿題になる。役割を明確化 |
7 | 利用部門が参加するリハーサル・受け入れテストの計画があるか | 本番で現場が初めて触る危険。参加を要求 |
このうち1〜5は移行作業の安全性に直結し、6〜7は発注者の責任範囲に関わる項目です。すべてが完璧に揃っている必要はありませんが、空欄や曖昧な項目があれば、サインの前にベンダーへ質問するきっかけになります。
まとめ
システム移行計画とは、現行システムを新環境へ安全に移すための実行計画を文書化した「移行計画書」のことであり、ベンダーに任せきる文書ではなく、発注者が読み、確認し、自社のタスクを果たすための共同作業の地図です。
最後に、承認前に確認すべき急所を改めて整理します。
- 切り戻し（ロールバック）: 手順・中止基準・判断者が明記されているか
- リハーサル: 本番相当の環境で複数回計画されているか
- 予備日: スケジュールにバッファが確保されているか
- 連絡体制: 緊急時の判断フローが明示されているか
- 発注者の責任範囲: データクレンジングと利用部門のリハーサル参加が計画に組み込まれているか
これらが計画書に書かれているかを確認するだけで、専門知識がなくても危険のサインを察知できます。そして、移行方式は技術論ではなく「自社の業務をどこまで止められるか」という都合から選べることも押さえておきましょう。
次のアクションとして、まずは手元の移行計画書（またはこれから届くドラフト）を、本記事の承認前チェックリストと照らし合わせてみてください。空欄や曖昧な項目が見つかれば、それがそのままベンダーへの質問リストになります。あわせて、自社（業務部門）が担うべきデータの判断やリハーサル参加のタスクを洗い出しておけば、安心して次の打ち合わせに臨めるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 移行計画書を承認するとき、専門知識がなくても最低限どこを見れば危険を判断できますか
「切り戻し手順・中止基準・判断者」「本番相当の環境での複数回リハーサル」「予備日」「緊急時の連絡体制」の4点が明記されているかをまず確認してください。これらが空欄や曖昧なら、技術内容が分からなくても差し戻すべき危険信号と判断できます。
- ベンダーから渡された移行計画書に承認前チェックの項目が抜けていたら、どう伝えればよいですか
「もし当日うまくいかなかったら、いつまでにやり直せますか」「中止は誰がどんな基準で決めますか」のように、足りない項目を質問の形でベンダーに投げてください。専門用語で指摘する必要はなく、抜けを質問として返すだけで計画の補強を促せます。
- 移行を全部ベンダーに任せたいのですが、発注者がやらないと本当に失敗するのはどの作業ですか
データの正誤判断（クレンジング）、利用部門が参加するリハーサル・受け入れテスト、移行当日の業務調整・社内周知・問い合わせ窓口の4つです。これらは業務を知る発注者にしか担えず、丸投げすると最も失敗しやすいポイントを誰も見ない状態になります。
- 移行方式（ビッグバン・段階・並行運用）はベンダーに選んでもらえばよいですか
方式選択は技術論ではなく「自社が業務をどこまで止められるか」で決まるため、発注者が前提を伝える必要があります。止められる時間・繁忙期・現場の人的余力を最初に共有すれば、ベンダーは現実的な方式を提案でき、専門知識がなくても対等に議論できます。
- 移行後に「あのデータが見られない」と発覚した場合、どう対処すればよいですか
まず慌てて手作業で入れ直さず、旧システムやそのバックアップにデータが残っているかを確認してください。切り戻し（ロールバック）が可能な期間内であれば、追加移行で取り込める場合があります。鍵になるのが「旧システムをいつまで残すか」です。本番移行後すぐに旧システムを停止・破棄すると、後から不足が発覚しても取り戻せなくなります。移行計画書を承認する段階で、旧システムを一定期間（最低でも1〜2回の月次業務が回るまで）並行で残し、データの過不足を検証する期間を設けるよう依頼しておくと、こうした取りこぼしに対処できます。
