今回はみんなが大好きな「移行」について、
ここ3年間で大小4つのプロジェクトで本番移行の計画・推進のご支援を行った経験から、
その計画を立てる上でのポイントをいくつか共有したいと思います。
##前提知識
###システム開発における移行とは
簡単に言うと「旧システムのデータ・ハードウェア・ネットワーク・利用者・運用などを新システムに移し替え、新システムの利用に切り替える作業」のことです。
そして移行には、さまざまなトラブルが付きまといます。
例えば、以下の様なトラブルは移行トラブルあるあるです。
①旧システムからデータが引き継がれていなかった。
②稼働初日の朝になって、端末にログインできない、帳票が出力されない。
③いざ切り替えたらスムーズに業務が開始できなかった。
④予定していない処理が走ってしまいデータがおかしくなってしまった。
###移行の４つの分類
一言に移行と言っても、大きくは4つの観点に分類できます。
#####システム移行
- サーバ機器、端末、ネットワーク、アプリケーションなどを、旧システムから新システムで利用可能となる様にする作業
#####データ移行
- 旧システムのデータベースやファイルなどに格納されたデータを新システムに移し替える作業
#####業務移行
- システムの利用者が新システム稼働後、速やかにシステムを使って業務をスムーズに行える様にするための作業
#####システム運用移行
- システムの維持管理に必要となる運用作業を新システムでもスムーズに実施できる様に引き継ぐ作業
ちなみに先述で例に挙げたトラブルは全てがこの４つの分類のいずれかの不備に起因しています。
①→主にデータ移行
②→主にシステム移行 or データ移行
③→主に業務移行
④→主にシステム運用移行
##本題
前提知識としての移行を説明したところで本題に移っていきます。
4つの分類の移行を網羅した移行全体の計画を立てることは簡単ではありませんが、
移行全体を計画・推進する上で特に注意しているポイント5点について共有したいと思います。
####1. 要件定義までには移行計画の検討を開始すべし
移行は一般的には開発が一段落つこうかといったところから検討することが多いと感じています。
しかしその頃に検討を始めると、業務移行やシステム運用移行の観点が忘れられがちです。
（忘れられていなくても、検討が放置されがちです）
なぜなら、利用者がプロジェクトで一番関わってくるのは要件定義とユーザーテスト（受け入れテスト等）のため、利用者がプロジェクトから比較離れている期間に移行を検討することになるからです。
要件定義では、現在の業務分析や運用の流れを可視化した上で検討を進めていくので、遅くてもこの時期には移行の検討を開始できると、業務移行やシステム運用移行の観点を盛り込みやすくなります。
この段階では移行の要件（並行稼働の有無などの移行方針）、移行する範囲（移行対象業務、システム、データ）、リハーサル（後述「4. リハーサルは複数回計画すべし」参照）は何回実施するのか、スケジュールを検討する上での制約条件を整理すると良いでしょう。
スケジュール検討については、次のポイントで続けて説明します。
####2. ビジネスファーストで移行スケジュールを考えるべし
ポイントの1つ目で要件定義までには検討を開始すべき項目として、
スケジュールを検討する上での制約を整理すると書きました。
利用者目線で制約条件を徹底的に考え抜いて、移行スケジュールを検討しましょう。
一般的によくある制約条件は以下の通りです。
・機器、ソフトウェアの保守サポート期限
・法改正
・利用者業務繁忙期、重要業務イベント、業務年度切替、会計年度切替
・並行する他プロジェクト
ビジネスファーストでスケジュールを立てることは、
ビジネス面から考慮すべき点を取りこぼすことなくスケジュールを立てるのにとても有効です。
また、副次的な効果として利用者に向けてビジネスファーストのスタンスを示すことで、
利用者から信頼を得る等の関係構築を促進することができます。
業務移行の検討時に移行前後の業務制約や、システム運用移行への申し送り事項など、後ほどに検討事項が発生することがあるため、プロジェクトの早い時期から移行に対する当事者意識を利用者に持ってもらうことが大切です。
そのためにも前段として、利用者とは良好な関係を築いておきたいですね。
####3. 移行計画は３者間の連携プレイで進めるべし
移行の計画は関係者が大きく３者います。
１．移行作業実施ベンダー（旧システム、新システム）
２．利用者（情シス、エンドユーザー）
３．移行計画立案者
それぞれの誰が欠けても、作られた移行計画は絵に描いた餅になってしまいますし、網羅性に欠けた移行計画となってしまいます。
そのため、３者間の連携が移行の成功の鍵です。
一例として、私が移行全体計画を立てる上での大きな流れは以下の様な進め方になります。
①移行作業実施ベンダーと利用者は、旧システム、新システムの制約を移行計画立案者に集める。
②移行計画立案者は、移行作業実施ベンダーから出された制約と、利用者側の制約を踏まえた移行基本方針を作成し、移行作業実施ベンダー、利用者側に提示し、フィードバックを得る。
③移行計画立案者は、移行基本方針にフィードバックの内容を反映して、それを基に移行全体計画を完成させる。
④移行作業実施ベンダーと利用者は、移行全体計画書の内容を基に、移行作業実施ベンダー、利用者は本番移行時の作業手順書や詳細スケジュールを作成していく。
####4. リハーサルは複数回計画すべし
移行は様々な関係者が一堂に会して行う大イベントです。
したがって、まず1回目で全てが上手くいくことはありません。
そのため、本番の移行時に向けてリハーサルという素振りが必要となります。
全体を通して作業することによって初めて見えてくる課題の抽出が主な目的となります。
リハーサルは最低でも2回設定する様にしましょう。
なぜなら、1回目で抽出した課題の解決を確認するために2回目が必要だからです。
リハーサルはそれぞれの回で、誰が何を確認することが目的なのか検討した上で利用者と合意します。
代表的な考え方として、以下の様な目的を設定する。
（移行リハ2回の例）
１回目：移行手順全体を通して移行手順書の正しさを確認する。
移行タイムスケジュール（所要時間）の正しさを確認する。
参加者：ベンダー、利用者側の情シス
２回目：１回目で発生した課題が解消されていることを確認する。
参加者：ベンダー、利用者側の情シス、利用者側のエンドユーザー
予備期間も確保しておきましょう。（リハーサルが2回予定であっても、3回目がゼロと考えていないことを示す）
####5. 事前にできることは全部事前にすべし
これはどちらかと言えば、システム移行やデータ移行の各論の検討時に注意する点になりますが、
本番の移行当日に行う作業を少しでも減らせないか考えます。
事前にやれることが多いほど、課題が早く抽出でき、結果として対策を講じることができます。
例）
データ移行の中でシステムでは参照しかしない古いデータのみ、先行して移行して
当日は変動するデータのみ移行する。そうすれば、本番の移行当日の作業量を低減できる。等
ちなみに本番切替でしか扱えない機器や、接続できない機器があることは少なくありません。
その場合どうするかと言えば、
何がどこまで出来て、どこから先が確認出来ないかを整理し、本番切替の事前に確認できることは確認する。
確認できない点は、不備が発生した場合の運用回避手段などを検討して、リスクを低減すると良いですね。
##おわりに
移行全体の計画を立てる上で一番注意している点は、以上の５点となります。
本当は、データ移行、システム移行、業務移行、システム運用移行の各論ごとにも気を付ける点などあるのですが、プロジェクトの特性ごとの内容であったり、細かくなる話が多くて書ききれないため、全体計画を立てる際のポイントに絞っての共有とさせていただきました。
###移行計画と推進はとても大切
移行のゴールはプロジェクトのゴールに繋がる最後の１ピース
移行のゴールは、
「切替が終わった後、利用者が新システムで快適に業務を開始することができること」に尽きます。
これは即ち、プロジェクトで開発した情報システムが期待通りに利用者に使われ始めること。
そしてそれは、その情報システムが作られた目的を果たすこと（プロジェクトの目的）に繋がっていきます。
ですが、先述の様なトラブルがあれば、快適に業務を開始するはおろか、
利用者のシステムに対する満足度・信頼度が下がり、プロジェクトの目的を台無しにすることに繋がりかねません。
移行は、石橋を叩いて、さらに叩いて進めていくことになりますが、
完璧な移行を実現した時に見れる風景は格別ですよ！
だって、プロジェクトの殿を務めるのですから。そこでしか見えない風景がきっとあります。
是非、皆さんもそんな格別な風景を見てみてください！