移行とはなにか

もやっとした要求を解きほぐす企画・要件定義から始まり、多くの調整を要する設計を書き上げ、ひとつひとつをプログラムとして実際に動かしていき、困難かつ大量のテストを終え、胸を張って使ってもらえる品質のシステムが仕上がったら、ユーザさんお待たせしました、さぁどうぞ使ってください、……というわけにはいきません。

たとえばみなさんが普段使っているブラウザやメーラを、他のものに乗り換えることを考えてみてください。はじめは新しいブラウザやメーラの操作の仕方も良く分かりません。接続設定もしなくてはいけませんし、メール自体やアドレス帳、ブックマークなども持って行きたいところです。そうまでして乗り換えても、サイトによっては新しいブラウザでは表示が崩れたりするかもしれません。最初は元のソフトも残しておきたいですよね。こうしたことを解決するのが、移行という工程です。

業務の移行、データの移行、システムの移行

企業システムにおいては、システムのリニューアルに合わせて業務も変わることが多々あります。

もちろん、これまでシステム化されていなかった業務をシステム化するとなれば、仕事のやり方をがらっと変えることになります。新しい業務のやり方は、要件定義に参加されたユーザには概ね理解されているかもしれませんが、実際のシステムを目の前にすれば、また気づく点もあります。言うまでもなく、それ以外のユーザにもシステムを使ってもらうことがあれば、「新しい業務はどうなる」というコンセプトから説明の必要があるでしょう。説明会やリハーサル、マニュアルの作成と配布、ヘルプデスクの設置といった手立てで、新しいシステムに基づく新しい業務が、できるだけ早く、トラブルなくスムーズに根付くように働きかけます。

既存システムがあれば、当然データは移し変える必要があります。既存システムから、どうやってデータを取り出すのか、データの形式や項目は、このような仕様が不明なこともあります。吸い出したデータを新システムに投入するための変換プログラムも必要になるでしょうし、大量のデータなら、取り出して変換して投入するのに何日もかかるかもしれません。

サーバを設置してプログラムをインストールして、新しいシステムを立ち上げるのもいろいろ大変です。その環境を予め用意して、システムテストで利用していたりすれば、影響がないようにクリーンアップする必要もあります。当面古いシステムと共存させようとしたりすれば、さらに話はややこしくなります。システム運用の体制としても、障害時の連絡や対応を含めて整えておく必要があります。

こうした段取りを踏んだとしても、システム立ち上げ直後は、なにかとバタバタするものです。綿密な準備の網目をくぐる、思いもよらなかったトラブルに鍛えられて、業務とシステムはようやく回り始めるのです。

執筆者紹介

山本啓二(YAMAMOTO KEIJI)
- ウルシステムズ コンサルティング第2事業部 副事業部長

独立系ソフトベンダーを経て、2001年入社、2009年より現職。アーキテクチャおよび開発プロセスにまつわるコンサルティングに多く携わる。著書に、「そこが知りたい 最新Webアプリ開発のお作法(共著・翔泳社刊)」、「プログラマの本懐(日経BP社刊)」。