最終更新日：2025/08/25
※当記事は自身のためにナレッジ化した記事となりますので参考までにお願いいたします。
Gemini 2.5 Proに聞いた内容、自身の経験をもとに記載しております。
なお、絶賛対応中ではありますので経験したことは追記していきます。
今回、初めて移行関係のリーダー的立場を経験しております。
抽象的な内容が多く、業務側へ聞きまわる必要もありなかなかに大変です。
移行関係については色々と調べてみたのですが、多少参考にはなるもののこれだ！って記事は見つかりませんでした。探し方が下手なのもあるとは思います。
なので、自身のためにこのような記事を作成しました。
前提として既存システムからSaaSへの移行となります。また、移行チームと業務チームで分かれております。
移行方針の策定
・移行の目的・目標
移行を行う理由です。
例えばSaaSにすると業務効率が向上する、手作業部分を減らしヒューマンエラーを減らす等でしょうか。
・移行範囲
どの業務、機能、データをSaaSシステムに移すかを定義します。
既存システムは残すのか、その残すシステムは何か、どのデータを移行するか、不要か等々
・移行方式
SaaSへのリビルドのため、データ移行方式に注意しなければならないと思います。
現行のデータをSaaS標準機能の形に合わせるのか、カスタマイズ(追加開発)するのかで話が変わってきます。
カスタマイズがいいといわれた場合はコストもその分詰むことになるかと思います。
・移行時期・期間（スケジュール）
移行を完了させるスケジュール、全体のマイルストーンを設定します。
業務繁忙期等も意識すべきポイントかと思います。
・移行体制と役割分担
各チームがどの範囲の責任を持つのか、移行を行う体制図等を決めます。
業務、移行といったチームに分かれている場合はチーム間での話し合いや情報共有、ルール決めが必要になります。
・品質基準、完了基準
移行が成功したと判断する基準です。
業務シナリオが問題なく実行できる や 移行件数、データの値が正しく設定されている等
移行計画策定
・WBSの作成
言わずもがな必要です。タスクは分かりやすいよう分解しておくと漏れないかと思います。
・マスタスケジュール
各作業の担当者、開始日、終了日、成果物をまとめたスケジュール。
・各フェーズの詳細計画
〇要件定義/Fit&Gap分析: 現行業務とSaaSの機能を比較し、ギャップをどう埋めるかを具体的に決定します。
〇設計・開発: SaaSの設定、追加開発、周辺システムとの連携部分の設計・開発計画です。
移行するツール作成も含みます。
〇テスト: 移行ツール自体はUTレベルで実施し、IT・STにて移行した内容で業務が滞りなく進められるかを見ます。
・移行リハーサル・本番移行
・移行手順書: 本番移行の作業手順を秒単位で記述した詳細なドキュメントです。
特に移行リハーサルを数回行う間に充実化させるのが重要です。
・実施体制: 誰が何時に何をするのかを明確にした体制表。
・切り戻し計画: 万が一、移行に失敗した場合に、元のシステムに戻すための手順と判断基準。
・本番稼働後のサポート
稼働開始直後の問い合わせ対応やトラブル対応の体制を計画します。
と、まあ。。。ここまでは通常の進め方ですね…
イレギュラーな場合を記載しておきます。
そもそも業務要件が確定していない場合
移行方針策定の段階で一部ペンディングが発生します。
例えば
・移行範囲の確定
要件が決まっていないのでもちろん決められません。
・移行方式
Fit&Gapの途中であると考えられ、
Gapがあるものをカスタマイズとするのか、運用カバーするのかで話が変わります。
・品質基準、完了基準
シナリオ自体が要件定義で決まるので、基準が決められないと考えています。
ただ、Fitする業務については現行通りの動作であること程度なら…って感じはします。
ですがSaaSだと運用が変わる場合が多々ありますので、ほぼ決められないと思っています。
・スケジュール
本稼働日からの逆算でしか記載できないと思います。
あくまで仮決めしたスケジュール、現状のタスク洗い出すためのスケジュールとしてしか
機能しないことを客先には伝えたほうがいいかもです。
加えて方針が決まっていないのであればそもそも移行計画書の作成も厳しいですね…
せめてわかっている作業をスケジュール化をしておきたいです。
じゃあ、わかっている作業とは…？
Gemini2.5 proに聞いたものをそのままコピペします。
質問内容
「業務要件確定前ですが、確実にやらなければならないこと、タスクとして見えていることををスケジュール化（マイルストーンふくむ）しようと思っています。
例えば、業務のヒアリングです。どのテーブルを移行するのか、どのシステムかを担当者に聞くタイミングをスケジュール化したり、
リリース計画書を作成するタイミングのスケジュールを仮決めでひこうとしています。
こういった進め方はありでしょうか。」
（…元々文章が下手ですがAIに聞くとき私は更に雑になります。。）
現時点でスケジュール化すべきタスクの具体例
ユーザー様が挙げられた「業務ヒアリング」や「リリース計画書を作成するタイミング」は、まさにこの段階で計画すべきタスクです。その他にも、以下のような項目をスケジュールに盛り込むことができます。
1. プロジェクト管理系のタスク
- プロジェクト体制の確定とキックオフ: 誰がプロジェクトメンバーで、誰がステークホルダー（利害関係者）なのかを確定し、プロジェクトの開始を宣言します。
- 役割分担（RACI）の明確化: 業務チームと移行チーム、それぞれの責任範囲を明確にします。
- コミュニケーション計画の策定: 定例会議の頻度、報告ルート、議事録の共有方法などを決めます。
- 課題・リスク管理ルールの策定: 発生した課題やリスクをどのように管理していくかを決めます。
2. 調査・分析系のタスク（As-Is分析）
- 現行システムドキュメントのレビュー: 既存の設計書や操作マニュアルなどを読み込み、システムの概要を把握します。
- 現行システム環境の調査: どのサーバーで動いているか、OSやミドルウェアのバージョンは何かなどを調査します。
- 移行対象データ候補の調査: ユーザー様が挙げた「どのテーブルを移行するのか」の調査です。テーブル一覧、データ件数、データ型などを洗い出します。
- 外部連携インターフェースの調査: 現行システムが他のシステムと連携している場合、その仕様を調査します。
3. 業務ヒアリング計画
- ヒアリング対象部署・担当者のリストアップと日程調整: 誰に、いつ、何を聞くかを計画します。
- ヒアリング項目の準備: 事前に質問事項をまとめておくことで、効率的にヒアリングを進められます。
4. SaaS製品の調査・理解
- SaaS標準機能の学習・デモ環境での操作: 移行チームがSaaSの仕様を深く理解するための期間を設けます。これは後の業務要件定義支援に不可欠です。
- データ移行APIの仕様調査: SaaSが提供するデータ投入機能の制約などを事前に把握します。
5. 計画策定の計画
- 移行方針（ドラフト版）の作成期間: 調査結果を基に、仮の移行方針を作成する期間を設定します。
- 移行計画（骨子）の作成期間: 方針ドラフトを基に、大まかな計画の骨子を作成する期間を設定します。
- リリース計画書（初版）の作成期間: ユーザー様が挙げたタスクです。
マイルストーンの設定例
この段階で設定すべきマイルストーンは、最終的な「本番リリース」ではなく、より手前の成果物に対するものになります。
- マイルストーン1：プロジェクトキックオフ完了
- マイルストーン2：現行システム調査完了
- マイルストーン3：主要業務担当者へのヒアリング完了
- マイルストーン4：業務要件定義完了 ← これが最も重要な中間目標
- マイルストーン5：移行方針（ドラフト版）合意
この進め方における最大の注意点
この進め方で最も重要なのは、「作成したスケジュールはあくまで現時点での見込み（＝仮決め）である」ということを、プロジェクト関係者全員で合意しておくことです。
特に、経営層や上位のステークホルダーには、「業務要件の規模や難易度によって、特に『業務要件定義完了』以降のスケジュールは変更される可能性がある」ということを明確に伝え、期待値を適切にコントロールしておく必要があります。
この前提さえ共有できていれば、ご検討中の進め方はプロジェクトを健全に推進するための非常に有効な手段となります。
私の場合は役割分担（どの会社が対応するか程度）、業務ヒアリングやヒアリング項目の準備だったり、移行計画書の作成だったりですね。
それらは確実にスケジュールに乗るので仮決めできる内容になります。
以上となります。
現在も移行対応を行っている身ですので、自身の失敗等は今後も積極的にまとめていきます。
最終的に移行が完了した時に振り返りとして文章も再考しようと思いますので、ご容赦ください。
当記事で多少なりとも救われる人がいれば幸いです。
【2025/08/31追記】
データクレンジングについて
クレンジング＝業務データを移行する際に、次期システムに合わせデータを綺麗にする様なものです。次期システム様に変換をかけないといけない部分も出てきます。
業務データを次期システムに合わせて“ベンダ”側が行うという取り決めになった場合、
安易に受けるととんでもないことになりそうです。
データの正しい姿が見えているのなら良いのですが、
ベンダの移行担当にそこは判別つきません。
どういったルールで変換するか、重複データは消して良いか等、あらかじめ握っておく必要が出そうです。
【2025/09/01追記】
ベンダと発注会社の役割について
Gemini2.5proによる生成
1. システム移行（基盤移行）
目的： オンプレミスのインフラからSaaSのプラットフォームへ、システム基盤を安全かつ確実に切り替える。
| タスク | ベンダー（移行チーム） | 発注者（業務・移行チーム） | 主な成果物 （作成者 → 承認者） |
| SaaS環境の払い出しと初期設定 | ✔️ SaaS利用環境の準備、テナント設定 | <ul><li>設定内容の確認・承認</li></ul> | <ul><li>環境定義書 （ベンダー → 発注者）</li></ul> |
| ネットワーク接続設定 | ✔️ 接続仕様に関する情報提供と設定支援 | <ul><li>自社ネットワーク要件の提示</li><li>社内FW等の設定変更</li></ul> | <ul><li>ネットワーク構成図 （ベンダー → 発注者）</li><li>接続テスト報告書 （共同作成 → 共同承認）</li></ul> |
| 認証基盤連携（SSO） | ✔️ SSO連携の技術支援 | <ul><li>IDプロバイダー（IdP）情報の提供</li><li>ユーザー情報の整備</li></ul> | <ul><li>SSO設定仕様書 （ベンダー → 発注者）</li><li>SSO連携テスト報告書 （共同作成 → 共同承認）</li></ul> |
| 本番環境への切り替え | ✔️ DNS切り替え等の技術的支援、手順提供 | <ul><li>DNS切り替え作業の実施承認と実行</li></ul> | <ul><li>移行手順書（システム切替） （ベンダー → 発注者）</li><li>移行完了報告書 （ベンダー → 発注者）</li></ul> |
2. アプリケーション設定移行
目的： オンプレミス環境で利用していたアプリケーションの設定値を、SaaS環境の標準機能の範囲で再現・移行する。
| タスク | ベンダー（移行チーム） | 発注者（業務・移行チーム） | 主な成果物 （作成者 → 承認者） |
| 現行設定のヒアリング | ✔️ 現行システムのパラメータ、権限設定等のヒアリング | <ul><li>現行設定情報の提供</li></ul> | <ul><li>現行設定調査票 （ベンダー作成協力 → 発注者）</li></ul> |
| SaaS標準機能へのマッピング | ✔️ 現行設定とSaaSの標準機能とのFit&Gap分析支援 | <ul><li>代替機能や運用変更の要否を判断</li></ul> | <ul><li>Fit&Gap分析表 （ベンダー → 発注者）</li></ul> |
| SaaSへの設定投入 | ✔️ 承認された設定内容をSaaS環境へ投入 | <ul><li>設定投入後の内容確認</li></ul> | <ul><li>SaaSパラメータシート（ベンダー → 発注者）</li></ul> |
| 権限（ロール）設定 | ✔️ 発注者が定義した役割に基づき、SaaSの権限ロールを設定 | <ul><li>ユーザーリストの提供</li><li>業務役割（ロール）と権限の定義</li></ul> | <ul><li>ユーザー・ロール一覧 （発注者 → ベンダー）</li><li>権限マトリクス （発注者 → ベンダー）</li></ul> |
| 設定移行後の動作確認 | ✔️ 設定が正しく反映されているかの技術的確認 | <ul><li>UAT（ユーザー受け入れテスト）の計画・実施</li></ul> | <ul><li>UAT計画書 （発注者 → ベンダー）</li><li>UATシナリオ （発注者 → ベンダー）</li><li>UAT報告書 （発注者 → ベンダー）</li></ul> |
3. 業務移行
目的： 新しいSaaSシステムに合わせて業務プロセスを再構築し、利用者がスムーズに新業務を開始できるようにする。
| タスク | ベンダー（移行チーム） | 発注者（業務・移行チーム） | 主な成果物 （作成者 → 承認者） |
| 新業務プロセス設計支援 | ✔️ SaaSの標準機能に合わせた業務フローの提案 | <ul><li>現行業務プロセスの棚卸し</li><li>新業務フローの策定・承認</li></ul> | <ul><li>新旧業務フロー対比表（発注者作成、ベンダー支援）</li></ul> |
| 利用者トレーニング | ✔️ 発注者の移行チーム／情報システム部門向けトレーニングの実施 | <ul><li>エンドユーザー向けトレーニングの計画・実施</li></ul> | <ul><li>トレーニング計画書（発注者 → ベンダー）</li><li>トレーニングテキスト （ベンダー → 発注者）</li></ul> |
| 移行リハーサル | ✔️ 移行手順の確認、技術的支援 | <ul><li>業務シナリオに基づいたリハーサルの実施</li><li>リハーサル結果の評価・承認</li></ul> | <ul><li>移行リハーサル計画書（共同作成 → 共同承認）</li><li>移行リハーサル報告書 （共同作成 → 共同承認）</li></ul> |
| 問い合わせ対応体制の構築 | ✔️ 移行後の技術的な問い合わせ対応（二次受け） | <ul><li>社内ヘルプデスクの設置</li><li>業務に関する一次問い合わせ対応</li></ul> | <ul><li>運用保守フロー図（共同作成 → 共同承認）</li><li>エスカレーションルール（共同作成 → 共同承認）</li></ul> |
4. データ移行
目的： オンプレミスシステムに蓄積されたデータを、SaaSへ正確かつ安全に移行する。
| タスク | ベンダー（移行チーム） | 発注者（業務・移行チーム） | 主な成果物 （作成者 → 承認者） |
| 移行計画策定 | ✔️ データ移行方式・スケジュールの提案 | <ul><li>移行対象データの定義・棚卸し</li><li>移行計画の承認</li></ul> | <ul><li>データ移行計画書（ベンダー → 発注者）</li><li>移行対象データ一覧 （発注者 → ベンダー）</li></ul> |
| データクレンジング支援 | ✔️ クレンジング方針に関する助言、ツール等の情報提供 | <ul><li>データの精査・名寄せ・不要データ削除の実施</li></ul> | <ul><li>データクレンジング仕様書 （発注者 → ベンダー）</li></ul> |
| データ抽出・変換・投入 | ✔️ データ移行ツールの提供、変換プログラムの準備、SaaSへのデータ投入作業 | <ul><li>移行元データからのデータ抽出</li><li>データ変換・加工ルールの定義</li></ul> | <ul><li>データマッピング定義書 （ベンダー → 発注者）</li><li>データ移行手順書（ベンダー → 発注者）</li></ul> |
| データ検証 | ✔️ 移行後の件数確認等の技術的検証 | <ul><li>移行後のデータ整合性・正当性の業務的検証</li><li>検証結果の承認</li></ul> | <ul><li>データ検証仕様書（共同作成 → 共同承認）</li><li>データ検証結果報告書（共同作成 → 共同承認）</li></ul> |
以下は発注者側への確認
移行計画書策定に向けた発注者への確認事項チェックリスト
1. プロジェクトの全体像とゴールに関する確認
- 目的の再確認:
- 「私たちが作成した計画書の『プロジェクトの目的』は、皆様の期待と一致していますか？コスト削減、業務効率化、セキュリティ向上など、最も優先すべきは何ですか？」
- 移行完了の定義:
- 「どのような状態になれば、このプロジェクトは『成功』と言えますか？（例：主要な業務が〇日間、問題なく遂行できる、など）」
- 「UAT（ユーザー受け入れテスト）で、どのような基準をクリアすれば本番移行を承認いただけますか？」
- スコープの最終確認:
- 「移行対象の機能、業務、部門について、この範囲で間違いありませんか？逆に、今回『やらないこと』としてリストアップした内容に、含めるべきものはありませんか？」
2. 体制と役割分担に関する確認
- キーパーソンの特定:
- 「各業務領域において、仕様やデータに関する最終的な『判断』をされる方はどなたですか？」
- 「UATに参加し、業務の観点からテストを実施していただく担当者は、どなたを想定されていますか？」
- 工数の確保:
- 「計画上、UATやデータ検証などで貴社（発注者）の作業が必要となりますが、担当者の方の工数は確保いただけそうでしょうか？」
- 意思決定プロセス:
- 「私たちが提出する成果物（設計書、テスト報告書など）の承認プロセスと、通常要する期間を教えてください。（例：担当者確認→部長承認で約5営業日など）」
3. データ移行に関する詳細確認（最重要）
- 移行データの範囲（何を）:
- 対象データ: 「移行対象とするデータ（顧客マスタ、商品マスタ、受注伝票など）の一覧は、これで全てでしょうか？漏れはありませんか？」
- 対象期間: 「トランザクションデータ（受注伝票など）は、何年前のものまで移行が必要ですか？（例：過去3年分、全期間など）」
- 対象外データ: 「逆に、移行が不要なデータ（退職者の情報、古いログなど）はありますか？」
- データ品質とクレンジング（どうする）:
- 正データの定義: 「重複データがあった場合、どちらを『正』としますか？（例：最終更新日が新しい方、特定の部署が登録した方など）」
- 表記揺れの統一ルール: 「『㈱』と『株式会社』、『1-2-3』と『一丁目二番地三号』など、どちらの表記に統一しますか？」
- 欠損データの扱い: 「必須項目が空欄のデータは、どう扱いますか？（例：移行対象外とする、特定のデフォルト値を入れるなど）」
- 仕様の承認: 「私たちが作成する『データクレンジング仕様書』を承認いただくことで、そのルールに基づいたデータ変換作業の責任を私たちが負う、という進め方でよろしいでしょうか？」
- データ検証（どう確認する）:
- 検証方法: 「移行後のデータが正しいことを、どのように確認されますか？（例：現行システムから特定の条件で抽出し、件数と内容を突合する、など）」
- 検証責任者: 「移行後のデータの正当性を最終的に確認し、承認される担当者はどなたですか？」
4. 業務移行と受入に関する確認
- UAT（ユーザー受け入れテスト）:
- 「UATで必ず確認したい、クリティカルな業務シナリオは何ですか？（例：月末の請求処理、新規顧客の登録から初回受注まで、など）」
- トレーニング:
- 「利用者向けトレーニングの対象者はどの範囲ですか？（例：全社員、特定の部署の担当者など）」
- 「トレーニングの実施形式にご希望はありますか？（例：集合研修、マニュアル配布、動画コンテンツなど）」
- 移行後のサポート体制:
- 「移行後、操作方法などに関する社内の一次問い合わせ窓口（ヘルプデスク）は、どこになりますか？」
- 「どのような場合に、私たちベンダーへ問い合わせをエスカレーションするルールにしますか？」
5. 非機能要件と制約事項に関する確認
- システム停止時間:
- 「本番移行作業に伴い、現行システムを停止できる時間は最大で何時間ですか？（例：土曜の夜22時～日曜の朝6時まで、など）」
- セキュリティ要件:
- 「SaaSを利用するにあたり、貴社のセキュリティポリシー上、遵守すべき事項はありますか？（例：パスワードの最低文字数、IPアドレス制限など）」
- 業務上の制約:
- 「本番移行日として、絶対に避けなければならない時期はありますか？（例：繁忙期、決算期、株主総会の時期など）」
システム移行の一部としてアプリケーション移行がある
一般的な定義とスコープの違い
両者の関係は、「システム移行」という大きな枠組みの中に、「アプリケーション移行」が含まれると考えると分かりやすいです。
システム移行 (System Migration)
- スコープ: 広義。 アプリケーションが動作する**環境（土台）**を含めた、システム基盤全体の移行を指すことが多いです。
- 主な関心事:
- インフラストラクチャ: サーバー、OS、ミドルウェア、ネットワーク、データベースなど。
- 非機能要件: パフォーマンス、セキュリティ、可用性、運用監視など。
- イメージ: 「家（アプリケーション）を、土地（インフラ）ごと新しい場所に移転する」または「古い家を壊して、新しい土地に新しい家を建てる」イメージです。
- 今回のプロジェクトでの該当タスク例:
- オンプレミスのサーバーやOSの管理から、SaaSベンダーのクラウド基盤へ切り替えること。
- 社内ネットワークとSaaS環境を安全に接続するための設定（IPアドレス制限など）。
- ID認証基盤をSaaSと連携させること（シングルサインオンなど）。
アプリケーション移行 (Application Migration)
- スコープ: 狭義。 特定の業務機能を実現している**ソフトウェア（アプリケーション）**そのものを、新しい環境へ移したり、新しいものに入れ替えたりすることを指します。
- 主な関心事:
- 業務機能: これまで使っていた機能が、新しいアプリケーションでどう実現されるか。
- データ: アプリケーションが利用するデータの構造や内容。
- 操作性（UI/UX）: ユーザーが直接触れる画面や操作方法。
- イメージ: 「家の中の家具や家電（機能やデータ）を、新しい家に運び込み、使えるように設置する」イメージです。
- 今回のプロジェクトでの該当タスク例:
- オンプレミスの販売管理機能が、SaaSの販売管理機能に置き換わること。
- 現行システムのマスタ設定値を、SaaSのパラメータ設定に投入すること。
- 現行システムのユーザー権限設定を、SaaSのロール設定にマッピングすること。
なぜプロジェクトでこの2つを分けて考えるのか？
では、なぜ貴社のプロジェクトで、あえてこの2つの用語を使い分ける必要があるのでしょうか。それには明確なメリットがあります。
- 役割分担の明確化:
- 「システム移行」は、主にインフラやネットワークの知識を持つエンジニアが担当します。
- 「アプリケーション移行」は、業務知識やSaaS製品の仕様に詳しいコンサルタントやエンジニアが担当します。
- このように担当領域を分けることで、責任の所在が明確になります。
- タスクの洗い出し漏れ防止:
- 「アプリケーションの機能」だけに注目していると、ネットワーク接続やID連携といった土台部分のタスクを見落としがちです。
- 「システム移行」という観点を持つことで、「そもそもどうやってSaaSにアクセスするのか？」「誰がログインできるのか？」といった、プロジェクトの成否を左右する重要なタスクを確実に洗い出すことができます。
- 発注者との合意形成:
- 発注者にとっては、「動く環境」と「動くモノ」の両方が揃って初めて業務ができます。
- この2つの観点でタスクと役割を提示することで、「ベンダーがどこまで技術的に面倒を見てくれるのか」「自分たち（発注者）が何を決め、何を設定する必要があるのか」が明確になり、安心してプロジェクトを任せることができます。
コメント