サッカーならロス・タイムの2分間，プロ野球でいえば9回裏ツー・アウト，競馬であれば第四コーナーを回って最後の直線――。勝利への最大の難関は，ゴール目前に訪れるものだ。
システム構築プロジェクトでも同じことが言える。ゴールである「システムの稼働」にたどり着く直前には，「旧システムから新システムへの移行作業」という大きな落とし穴が待ち構えている。システム移行の失敗は，大トラブルに直結する。システム移行は，システム構築における最後の難関である。
システム移行の目的自体は，非常にシンプルだ。「旧システムから必要なものを取り出し，新システムに持っていく」と要約できる。
だが，そのためには，膨大かつ複雑な作業が必要になる。データの移行だけを取っても，「新システムに移すデータを選び出す」，「データ変換アプリケーションを作る」といった事前準備はもちろん，切り替え当日には「限られた時間内にすべてのデータを旧システムから新システムに移し替える作業」が発生する。こうした作業の一つひとつで失敗は許されない。作業漏れや手順の間違いは命取りだ。
最後の難関だけに，移行で痛い目に遭う企業は少なくない。例えばある製造業は，基幹系システムの刷新に伴う移行アプリケーションの開発規模を見誤り，稼働の延期を余儀なくされた。稼働延期には至らないまでも，移行手順の不備で新システムのデータが不整合を引き起こすといったことは列挙にいとまがない。
最大の問題は，落とし穴の存在すら気づかないこと
システム移行を重要な作業と認識していれば，ベテラン中心の移行専門チームを発足させたり，新システムの設計作業と並行して移行計画の検討に着手するといった取り組みを行うはずだ。ところが現実には，移行のためにこうした手を打つプロジェクトはそう多くない。
実は，システム移行の最大の落とし穴は，作業の難しさよりも移行そのものの重要性に対する認識が足りないということである。落とし穴の存在に気づいていないから，穴に落ちてしまうのだ。
「移行を軽視することはない。常に重要課題としてとらえている」。こう反論する読者も多いだろう。事実，記者はあるユーザー企業のシステム部長から，「移行を軽視したことは一度もない」ときっぱり言われたことがある。半年ほど前，日経コンピュータのシステム移行に関する特集の取材で，記者が「システム移行の重要性を改めて強調したい」と訴えたことに対する回答である。
それでも筆者は，「システム移行は，重要性の割に軽視される傾向がある」とみている。確かに言葉では「移行は重要」と言う人がほとんどであろう。にもかかわらず，極論を言えば「設計よりは優先度が低いので，移行はすべてメーカーに任せている」という事例が少なくない。これでは，移行の怖さを十分認識しているとは言いがたい。要するに，「移行を重視する」という言葉に含まれた，重視の度合いが問題なのである。
システム移行は，稼働直前の切り替え作業だけがすべてではない。システムの分析・設計段階から，「オンラインは何時間止められるか」「データ移行は時間内にできそうか」「リハーサルはいつ何回やればいいか」といった類の検討を進めるべきである。移行は本番の切り替え作業こそ短時間で終わるが，準備は何カ月も前からやるべきもの。こうした入念な計画の立案を実施していて，初めて移行を重視していると言える。
ユーザー企業のなかには，プロジェクトの計画段階から移行関連の案件を検討する専門チームを立ち上げ，さまざまな課題を検討しながら計画を入念に策定しているところもある。記者が怒鳴られたある企業がその代表例だ。会計システムを刷新する際，事前に移行計画を入念に検討。旧システムのデータは新システムですべて参照できなくてもいいと割り切る代わりに，移行に伴う作業工数を9割以上も削減した。
移行費用を減らすにも綿密な作戦が不可欠
「移行の成功には事前の計画が重要なのはよく分かる。しかし新システムの設計と並行して移行の検討を進める人員をアサインするほど，ヒトとカネの余裕はない」。こうした本音を漏らすユーザー企業の担当者は少なくない。限りあるシステム予算を有効に使いたいのは当然のこと。一度限りの使い捨てである移行アプリケーションの開発にお金をかけるぐらいなら，新システム向けにミドルウエアを一つでも多く購入した方がいいと思うのも無理はない。
もちろん移行費用は安く上げるに越したことはない。手順次第で，移行にかかる費用は大きく変わる。例えば，長崎県の地方銀行である親和銀行は今年5月，九州銀行（長崎県）との合併に伴うシステム統合を完了させた。統合に伴う移行作業を工夫することで，作業工数を通常の半分以下に抑えることができた。
親和銀行がコストを削減しながら移行を成功できたのは，「過去に移行で苦労した経験から，リスクと工数を減らす手順を考え抜いた」（石橋政宏専務）結果である。同時に移行のリハーサルを半年以上かけて行うなど，親和銀行は工数こそ減らしているが，移行重視の気持ちは決しておろそかにしていない。
費用を減らすにしても，移行の全体像や影響範囲を把握した上で，検討を進めることが欠かせない。「旧システムに格納してある過去の取引実績データは，新システムで参照できなくてもいい。その代わり新旧システムの並行稼働期間を設ける」「切り替え時間の短縮には費用がかかるので，オンラインを臨時で数時間停止する」など，企業戦略上の影響とコストを天秤にかけて検討すべき内容である。これに対して，重要性を度外視してコスト削減に走っては切り替え失敗を招く。
最適解は自社で見つける
こうした移行方針は，ユーザー企業自身で決めるしかない。企業戦略によって，最善の移行手順は千差万別だからである。ITベンダーには口出しできない部分でもある。
自社の尺度に基づき移行手順を決めることができれば，切り替えの成功がぐっと近づく。成功の典型例が，三井住友銀行のシステム統合だ。統合のリスク削減とスピードを最優先するという方針に基づき移行手順を決める姿勢が，はっきりと表れている。
住友銀行とさくら銀行の合併で新銀行が発足した2001年4月は，旧2行のシステムを接続して並行稼働させる方式を採用。システムの本格的な一本化を終える2002年7月までは，旧2行のシステムを並存させた。2001年3月31日から4月1日の土日は，統合作業のためにすべての店舗でATM（現金自動預け払い機）の稼働を止めた。本来営業している時間にATMを停止させるのは，大手銀行ではほとんど前例がない。それでも移行計画の段階で，確実な移行にはATMを止めるのが不可欠と判断して決断した。さらに2002年4月からの一本化は，合計7回に分けて段階的に行った。
繰り返しになるが，最適な移行計画は企業によって異なる。例えば三井住友銀行の手順をほかの銀行が真似しても，その選択が最善の方法であるとは限らない。ただ，システム移行について，他社の事例を知るのは無駄ではない。計画段階で注意した点や移行手順の考え方など，移行に対する“思想”を学ぶことはできるからだ。
（大和田 尚孝＝日経コンピュータ）
