2. 移行の漏れに備える4段階の対策
移行作業の漏れは１つの対策では防ぎきることはできません。
そこで、1つめの対策で駄目だった場合は次の対策で防ぐというように、複数段階の対策を用意して備えるようにします。
具体的には、移行の計画をするにあたり「早い時期から検討する」、「網羅性を担保する」という対応と、それでも想定仕切れない場合の「実際にやってみて確認する」という対応、それでも駄目なときに「最後のセーフティーネットを張る」という対応の4段階での対策が有効です。
2.1 早い時期から検討する
移行というと、一般的にはシステム開発も終わりに差し掛かる頃に検討を始める場合が多いのではないかと思います。
しかし、開発工程の終盤から移行の検討を始めると、特に運用移行や業務移行の検討が漏れがちとなります。
これらはシステムを利用した業務や運用と密接に関わっているため、検討には業務を担うユーザーが積極的に関わってもらう必要があります。
そこで、これらのユーザーが特に積極的に関わることになる、要件定義の工程のなかで移行についての検討を始めます。
要件定義では、現在の業務や運用の流れを可視化する作業を行うため、それらの作業と関連して移行の検討が行いやすくなるので、漏れを減らすことができます（表2)。
要件定義段階では、移行のための要件や制約事項を整理して、大まかなスケジュール案を作成します。
札幌市の場合は、要件として検討する内容として、並行稼働させるのかといった移行方針、移行する業務、システム、データといった移行対象の範囲、機器のサポート期限や、法改正の時期による移行時期の制約、繁忙期の回避といった移行スケジュールに影響を与えるような移行の制約となる情報といったものを検討しました。
特に移行対象となるデータについては、データの量（件数、ファイルサイズ）や、保存方法(媒体、紙、データベース）、データ格納状態・品質（レコードの重複有無、文字コード）といった内容について整理し、データ移行の対象を明らかにしました。このように、要件定義の成果物と関連づけて調査・整理することで漏れを減らすことができます。
基本設計工程では、要件定義段階で整理した要件に基づいて、アプリケーションやネットワークの切り替えをどうするかといったシステム移行方式や、データ移行の対象データを新システムのデータベースのどこに格納するのかを整理した上で、データの変換をどのように行うのかといったデータ移行方式について具体的に検討します。
開発工程では基本設計工程で整理した内容に基づいて、データ移行を実施するための変換ツールの開発などを実施し、実際の移行作業をおこないます。
2.1網羅性を確保して検討する
移行の検討が縦割りになりがちな箇所としては、業務アプリケーションの開発、サーバーやデータベースの構築、端末の展開・設定の作業の間や、複数の業務アプリケーションとの間などです。
これは、扱う技術の専門性が異なるため、チーム分担がなされることにより起こるものです。
ですから、規模が大きくなると発生しやすくはなりますが、基本的には単一ベンダー・マルチベンダーといった要素にかかわらず発生します。
縦割りによる漏れを解決するためには、単にプロジェクト全体を統括する立場が全体の移行を計画して提示すれば良いのではと思うかもしれません。
しかし、全体を統括する立場としては、個々の情報システムの移行に関する制約や要件が分からなければ、全体として実効性のある移行計画を作ることができないため、個々のシステムの移行計画の提示を要望します。
一方、それぞれの立場からすると、全体としての制約や要件がなければどのように検討すればよいか分からず、全体の移行方針や計画を提示するよう要望します。このように、互いに計画の提示を待つことで、移行の検討着手が遅れ、手戻りが起きることや作業が間に合わなくなってしまいます。
そこで、要件定義の時期から個々のシステム開発のプロジェクトとプロジェクト全体を統括する立場で移行の検討内容をキャッチボールしながら、徐々に検討内容を詳細化していき、全体を俯瞰した整合性のある移行計画を作り上げていくという進め方を採るようにします。
札幌市の場合は、プロジェクト全体を統括する立場であるPMOと個別プロジェクトの間でこのキャッチボールを行いながら、全体移行計画書と個別プロジェクトの移行計画書を作り上げていきました。
具体的な進め方は以下のとおりです（図3）。
１．個別プロジェクトはPMOから提示されたテンプレートやガイドなどをもとに、それぞれのシステムにおける移行の要件や制約を明らかにしPMOへ提示する。
２．PMOは個別プロジェクトが整理した移行要件をインプットにして、移行方針書を策定し個別プロジェクトに提示する。個別プロジェクトはそれに沿って内容を更新しさらに移行の方式などの検討を進め、内容をPMOへ提示する。
３．PMOは個別プロジェクトから提示された移行方式の検討結果をもとに、全体移行計画書を作成し、個別プロジェクトに提示する。個別プロジェクトはそれをもとに、移行の実施手順や作業計画を作成し、移行作業を実施する。
2.3実際にやってみて確認する
ここまで2段階の対策を紹介しましたが、それでもやはり漏れは発生します。
データ移行で起こるトラブルの原因として、処理だけでなくデータの受け渡しや内容確認といった人手の作業が伴うような作業の考慮漏れがあります。
また、システム移行で起こるトラブルの原因として、設計と実装が違うケース、アクセス権を初めとする各種設定が設計書の通りに設定されていなかった、テストで利用した環境と本番で利用した環境に僅かな差異があり、それに起因した問題が発生したといったケースなどがあります。これらの原因は、事前の想定で防ぎきることは難しく、現実的ではありません。
これらを防ぐためには、本番を想定した総練習のような徹底したリハーサルや、実際に機器を利用する場所でのシステム動作確認の実施などが有効です。
リハーサルや動作確認の実施を行っておくことは、作業手順の抜け漏れを防ぐだけでなく、作業当日のより正確な必要時間を測定することもできます。
2.4最後のセーフティーネットを張る
ここまでやっても漏れが発生するのが移行です。
うまくいかない可能性はゼロにはなりません。万が一、本番移行で不測の事態が発生した場合、業務への影響は最小限にとどめなければなりません。
移行が上手くいかない場合は、どこかのタイミングで切り替えを中断してやり直すこと、また、切り替えでどのような事態になっても、業務を継続する方法をあらかじめ定めておき、業務所管部門を含めて共有します。
この計画がなければ、まともに業務ができないのに無理やり切り替えを行ってしまい、業務が成立しなくなってしまうという本末転倒の事態が起こってしまったり、システムが不完全だからといって本番当日に切り替えができなくなったりします。また、切り替えの判断タイミングが遅れると、旧システムに戻すこともできず、新システムに切り替えることもできないという八方ふさがりの状況に陥ってしまうことになります。
そこで、移行計画のなかで「コンティンジェンシープラン」を定めておきます。
本番の移行でトラブルが起こった場合に発生しうる事態を洗い出し、それぞれの事態が発生した場合の対処方法について整理します。
対処方法は、システムの機能制限・業務の制限や、場合によっては何日後に稼働を延期して再度移行を実施するといったことも対処に含まれます。
システム的にリカバリが可能なものについては、迅速かつ正確なリカバリ作業を行うために、計画とともに作業手順を予め整備します。
また、それぞれの対処を行うことができるタイミングは限られるため、どのタイミングでどのような判断を行うのかということも併せて定めておきます。
