最終更新日：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：移行方針（ドラフト版）合意
この進め方における最大の注意点
この進め方で最も重要なのは、「作成したスケジュールはあくまで現時点での見込み（＝仮決め）である」ということを、プロジェクト関係者全員で合意しておくことです。
特に、経営層や上位のステークホルダーには、「業務要件の規模や難易度によって、特に『業務要件定義完了』以降のスケジュールは変更される可能性がある」ということを明確に伝え、期待値を適切にコントロールしておく必要があります。
この前提さえ共有できていれば、ご検討中の進め方はプロジェクトを健全に推進するための非常に有効な手段となります。
私の場合は役割分担（どの会社が対応するか程度）、業務ヒアリングやヒアリング項目の準備だったり、移行計画書の作成だったりですね。
それらは確実にスケジュールに乗るので仮決めできる内容になります。
以上となります。
現在も移行対応を行っている身ですので、自身の失敗等は今後も積極的にまとめていきます。
当記事で多少なりとも救われる人がいれば幸いです。
コメント