システム移行を上手く計画したい
システム移行ではどんなポイントに気を付ければいいか知りたい
と言った疑問に答えます。
この記事を読むことで、システム移行の業務移行・システム移行・データ移行の違いや、システム移行で注意する勘所が理解でき、システム移行を上手く推進できるようになります。
✔記事の信ぴょう性
SIer SE→現、一部上場企業社内SE（IT歴15年以上）。基幹システム開発、及び、グローバル１６拠点への導入やSCM・MDM等システム開発。社内SEの情報サイトIT Comp@ss運営者。「社内SE 1年目から貢献！情シス 企画・開発・運用 107のルール」著者。
✓あなたにあわせておすすめ
ITスキルを伸ばしたい方は、【システム開発が学べる本22冊】
社内SEの待遇や年収を知りたい方は【社内SE転職ナビ】
システム移行とは？言葉の定義
システム移行とは、システム開発プロセスの本番稼働前の最終工程です。(以下、紫で囲った部分）
システム開発のプロセス全体は、【2-2 システム開発の一連の工程（プロセス）の流れ|全体像を理解】の記事参照。
システム移行を他の表現で、
「サービスイン」
「本番リリース」
「カットオーバー」
と、呼ぶ場合もあります。
いずれの呼び方でも意味は同じです。
要件定義→開発→テストと実施後、システムを業務・お客様が理由するに提供する本番環境への移行を指しています。
システム開発従事者にとっては、最後の難関です。
リリースを無事終え安定稼働が確認できれば保守メンバーにシステム運用を引き継ぐなどして一段落となります。
システム移行の用語（英語含む）まとめ
システム移行 system migration
サービスイン service in
システムリリース system release
システムカットオーバー system cut-over
失敗しないシステム移行｜おさえるべきリスクと４つのポイント
失敗しないシステム移行のために、リスクを理解しポイントをおさえることで、システム移行を成功に導くことが出来ます。
システム移行 4つのリスク
①あいまいなシステム移行の定義
②広がりがちなシステム移行の範囲
③話しがややこしくなるデータ移行
④バッファーのないシステム移行設計
１つずつ解説していきます。
①あいまいなシステム移行の定義
1言でシステム移行と言っても、プロジェクト内で認識齟齬が発生する場合をかなり見かけます。
ある人は、
「システム移行＝アプリケーションのリリース」
と捉えていたり、
他の人は、
「システム移行＝データ移行、業務移行」
と捉えていたりします。
以下図は、業務・サービスが本番利用・移行するために必要な要素です。
広義のシステム移行も細分化すると、
【システム（アプリ）移行】
【データ移行】
【業務移行】
に分かれます。
システムリリースの分類
プロジェクトにとって「システム移行とは何か？」を定義をすることが非常に重要です。社内SE/情シスとして、プロジェクト全体でまずは言葉の定義・実施中のプロジェクトでのシステム移行とは何か？を定義する必要があります。
システム開発、プロジェクト運営のコツ
— グル@社内SE講師 (@it_compass_guru) September 19, 2020
・当たり前と思っている事、
・前提としている事
を疑い
共通認識をとる
つまり
チームを共通情報認識でつなげる作業#社内SE #システム開発
ポイント①
プロジェクトにとって、システム移行とは何か？をきちんと定義する
②広がりがちなシステム移行の範囲
システム開発のプロジェクトだからと言って、何でも感でも社内SEで巻き取ってしまうのは大変危険です。業務移行は、基本業務が推進すべきです。
大規模案件であればあるほど、必ず分業すべきです。回らなくなります。
楽天ブックスがシステム移行でやらかして炎上気味だが、被害者に対する対応が酷すぎる。システム移行にトラブルが出るのは、珍しいものではない気もするが、問題は接客。トラブルからの回復は当たり前だが、利用者に対する適切な説明をしてくれないと。因みに自分も注文から11日経過、未着。
— Dc (@dc4047) March 31, 2011
例えば上記の例では、システム対応＋業務対応両方が必要でチームの弱さ役割の不明確さが読み取れます。
一番避けるべき点は、顧客迷惑です。
社内SE・情シスで、業務移行やデータ移行まで巻き取れないなと思ったら、迷わずPM・プロジェクトオーナーーに体制強化を依頼すべきです。＊相談して追加しない判断をPM・プロジェクトオーナーが行った場合は、責任はPM・プロジェクトオーナーに明確に移ります。相談しないと、、、、
ポイント②
業務移行は基本業務がリード。データ移行はプロジェクト内で要相談。
システム移行のリソース不足は必ずPM・プロジェクトオーナーにエスカレーション
③話しがややこしくなるデータ移行
鬼門のデータ移行に関してもう少し掘り下げて解説します。
システムテストを実施する際に、仕様書もテストも全て「移行後のデータで前提」で行うとシステムリリースを失敗します。（恥ずかしながら体験談）
特に繊細に考慮が必要なのが、「過渡期のデータを想定していない」場合、おそらく本番での障害は避けられません。
データ移行に関しては、【何のデータを】、【どれくらい】、【どのように】を綿密に計画する必要があります。
データ移行を検討→実行するプロセス
データ移行では、
・データ要件の整理
・実データの整備
・データの投入
の3つの観点で誰がどこまでを実施するのか？を明確にする事が非常に重要があります。
データ要件の整理
データ移行の要件は、システム要件定義で整備した内容がベースになり、最終的にシステムに必要なデータ形式をシステム側からまず明示します。
実データの整備
その後、その仕様に合わせて既存データの整備・クレンジングを実施します。新しいシステムではＮＧとされるケースがあれば既存システムできれいにしてもらったり、場合によっては他のデータとして別途管理を依頼したりもします。
データの投入
業務的なインパクトが少ないのであればそもそもの既存データを合う形に加工してもらったりもします。実データなのでクレンジングの作業をＩＴが実施する場合もありますがリードと判断は事業・業務ユーザーになります。
データ投入は、新しいアプロケーションに対して業務ユーザーがエントリーし直し移行する場合や、システマチックにツール等で移行する等様々な手段が考えられます。
どのように業務ユーザーとデータ移行に関してディスカッションすべきか？
業務ユーザーでよく要件定義フェーズで、過渡期のデータの事を根ほり葉ほり聞いてくる（心配してくる・揚げ足をとる）人がいます。
話をややこしくしたいだけなのか？と思うくらいの人います。。。あなたも経験あるのでは。
その際のおすすめの対応方法があります。一度、要件定義はデータ移行を話さないと決めて強います。ストレートに言うと波風がたつので、データ移行は、データ移行の別セッションで議論しますとし、その会議を早めに後工程に段取れればＯＫです。
こうすることで、まずはシステムとして通常系をしっかりと定義し、その後にイレギュラーとして過渡期のデータを検討することが出来ます。
ビル改装の例でいえば、一旦ビルの完成図を描き、その後で、どのフロアの改装と家具の移動から着手するか設計します。システム移行・データ移行もこういった手順で検討します。
何のデータを持っていくべきか？の考え方
データ移行は必ずしも社内SE/情シス側が責任を持ち推進する必要はなく、システム切替後に必要なデータを業務が再入力しても場合によっては問題ありません。
おすすめのデータ移行をどのようにするかの判断ロジックは以下です。
データ量が多く、業務影響が多いものはシステマチックに移行するべきです。
しかし、データ量が少ない場合は、データ量が多くても業務影響が無い場合等は、そもそも新しい仕組みにデータを持っていくべきか？持っていく場合誰がどのように？は要相談ポイントです。
新しい仕組みに持っていかない場合は、クラウド環境に安価なデータベースを構築して退避しておくのも手です。
ポイント③
データ移行検討は、一度仕様をある程度固めてから実施
データ移行するしない、誰が、いつ、どのように本番システムに持っていくか明確化する
④バッファーのないシステム移行設計
システム移行の座右の銘は、”expect unexpected!です。たくさん有益な情報を共有しましたが、どうしても忘れてほしくない言葉がこれです。
日本語に訳すと、「不測の事態が起こることを予定しておく」です。
システム移行では、どんなに綿密にスケジュールしたとしても、それでも予想外の事態は残念ながら発生します。
例えば、
・当日大雪で電車が動かず担当が出社できない
・作業員の凡ミスであるはずの無いデータが紛れ込む
・コロナ
等々
何かしらの課題・問題が発生するのがシステム移行、というか人生です。
そんなトラブル発生時にあなたを守ってくれるのがバッファー＝時間です。
ただし！余分な時間を確保だけでは不十分です。どれくらいの時間的余裕があるのか？いつまでに次の行動を決めなければいけないのか？を正確に認識しておくことが重要です。
時間のバッファーは心のゆとりにもつながり、あなたの冷静な判断を助けてくれます。システム移行も仕事も何でも以下の法則が大事です。
どんなに難しい事でも速く出来てしまう方法
— グル@社内SE講師 (@it_compass_guru) September 19, 2020
・難しい事は、ゆっくりやると出来るようになる
・出来る事は、繰り返す事で速く出来るようになる
ポイント④
システム移行にはバッファーを入れ、且つ正確に認識しておく
システム移行の計画（計画書）の作り方
システム移行計画書の作り方のご説明をします。システム移行計画書の主要な目次は以下です。
システム移行の主要な目次
目的
移行要件
移行スコープ・対象
移行スケジュール
体制図
コミニケーションルール
システム移行の目的
システム移行の目的をまずは記載します。
そんなのあたりまでしょ！って思ったかもしれませんが、かなり重要です。
あなたの担当したシステム移行が、アプリ移行なのか？業務移行も含むのか？データ移行もなのか？明確化する必要があります。
移行要件
システム移行の目的に沿って、移行の要件を決定していきます。
要件の中で制約事項等も明確にすることで、数回実施するシステム移行リハーサルのどの段階で何の品質や観点を確認するのか明確になります。
移行スコープと対象
ここまでの内容をふまえ、システム移行のスコープと対象を明文化していきます。システム構成図を用いて図解でシステム移行の対象をクリアにすべきです。
更にデータの観点では、どの移行リハーサルでどこまでのデータを確認するのか？をクリアにしておきます。
移行スケジュール
システム移行を実施するだけでは、システム移行の手順の確認はできますが、アプリケーションの品質はできません。システム移行のリハーサルと併せて、システムテストやユーザー受入テストの設計が必要です。併せてスケジューリングすることで効率的にシステム移行品質・データ移行品質を確認することが出来ます。
移行スケジュールには、移行リハ―サルの日程だけではなく、各システムとのかみ合わせもわかるようにしておくべきです。
体制図・コミニケーションルール
ある程度の大きさのシステム開発では、システム移行プロジェクト・チームとして全体開発プロジェクトから切り出して管理したりもします。その場合は、関係者・報告ラインを明確にするために体制図とコミニケーションルールの明記すべきです。
システム移行計画書サンプル
本サンプルでは、システム・業務・データ3つの観点のシステム移行を計画した要件定義書です。少額のシステム開発ではこの項目全てを定義する必要はありませんが、体系立てて全体を理解することが出来ます。
年金業務システムのサブシステムである経過管理・電子決裁サブシステム、個人番号管理（1 次）サブシステム及び基盤サブシステムの稼働に向けた、業務、システム及びデータ
移行、教育研修に関する要件を記述
他にもシステム開発に役立つ各種サンプルは【システム開発の成果物・ドキュメント一覧まとめ【DLリンク有】】の記事でご紹介しています。
鬼門のデータ移行が学べるおすすめ本
データ移行を、更に体系化し学びたい人おすすめの書籍を、「【厳選】SEにおすすめ本20冊と勉強方法｜社内SE/情シス必見」で紹介しています。データ移行の書籍だけではなく、あなたのシステム開発スキルをぐんと伸ばせるおすすめ書籍を開発の工程別に紹介しています。
SE必見|システム移行計画のリスクと抑えておくべき４つのポイントまとめ
本記事で紹介したシステム移行の４つのリスクとポイントのまとめになります。
①あいまいなシステム移行の定義
プロジェクトにとって、システム移行とは何か？をきちんと定義する
②広がりがちなシステム移行の範囲
業務移行は基本業務がリード。データ移行はプロジェクト内で要相談。
システム移行のリソース不足は必ずPM・プロジェクトオーナーにエスカレーション
③話しがややこしくなるデータ移行
データ移行検討は、一度仕様をある程度固めてから実施
データ移行するしない、誰が、いつ、どのように本番システムに持っていくか明確化する
④バッファーのないシステム移行設計
システム移行にはバッファーを入れ、且つ正確に認識しておく