「データ」「システム」「業務」それぞれの移行

　また一言で「移行」といっても、移行対象は複数あり、大きく分けると「データ」「システム」「業務」の3つになる。

データの移行

　移行作業の中心となるのが、データの移行である。言葉通り、現行システムのデータを新システムに移植する作業である。このデータの移行はケースによりさまざまであり、ツールなどを利用してほとんどすべてのデータを自動的に移行できる場合もあれば、それとは正反対にデータの互換性がなく、人海戦術による手入力でやらざるを得ない場合もある。基本的にデータは右から左へと単純に移せるものではなく、さまざまな工夫を要する作業であると認識しておいた方がよいだろう。なぜなら、ここを甘く見ていると、コスト、スケジュール、品質、全てが破綻する可能性があるので、キツめに見るべきところだ。

　また、ベンダーによって移行スキルに大きな差があり、さらに一般論でいえば、高い移行スキルを持つベンダーは優良ベンダーであることが多い。従って、適切なベンダー選定を行うためには、移行対象となるデータに関する情報をRFPで提示して、ベンダーにある程度の当たりを付けてもらい、提案書には移行に関する提案も盛り込んでもらう必要がある。ベンダーに提示すべきデータ情報とは次のようなものだ。

システムの移行

　ここでいう「システム」とは、ハードウェアやOSといった、いわゆるプラットフォームを指す。現行システムがスタンドアロンであれば簡単にシステムの移行はできるかもしれないが、そのようなケースはむしろまれで、ほとんどの場合、現行システムはネットワーク接続され、他のシステムとデータ連携を行っていたりする。この現行システムとネットワークや他システムとの「関係」を新システムは基本的には受け継ぐ必要がある（もちろんケースによっては新システム移行によって、その「関係」が大幅に変更になり、受け継ぎが不要になる、あるいは逆に全く新しい「関係」を作る場合もあるだろう）。

　このシステム移行に関しては、システム開発の経験が少ないと、RFPの段階では発注側に具体的な要求イメージがない場合もあるだろう。そのような場合は無理してユーザー側の要求として取りまとめるよりは、「このような点を忘れずに考慮して提案してほしい」という要求の出し方で代替してもよい。RFPの段階で重要なことは、詳細に記述することではなく「漏れ」がないことだからである。曖昧でも未熟でも記載してあれば、後の要件定義や基本設計の段階で拾い上げて具体化することができるが、「漏れ」ていると後のフェーズでも表に出ることがなく忘れ去られ、開発プロジェクトの最終盤である受け入れテストや並行稼働の段階になって、大事な要件が「漏れ」ていることに気付き、大騒動になってしまう。システム移行に関するRFPの記述ポイントとしては、以下のような考慮点を伝えることである。

　サーバ機器の物理的な入れ替えに関しては、場合によっては既存の機器を使い、ソフトウェアだけ入れ替えるケースもある。どちらのケースであっても、どのような方法とタイミングでソフトウェアを入れ替えるかイメージできていればそのやり方でやることを要求し、イメージがなければベンダーに提案を要求する。

業務の移行

　業務の移行はベンダーではなく、発注者であるユーザー側のテーマである。特にシステムが新しくなり業務フローが大幅に変更になるようなケースでは、業務の移行に関してきちんとユーザー企業内で検討しておく必要がある。業務の移行に関しては、RFPで特にベンダーに要求する項目はあまりないかもしれない。しかし、この業務の移行という検討事項があることはRFPの段階でも発注者は忘れずに念頭に置いておかなければならない。

既存グループウェアからSaaS型グループウェアの場合

　1つ事例を挙げて、既存システムから新システムへ移行する際のRFPの留意点を見ていこう。最近のクラウドブームに乗って増えてきているのが、自社でサーバを設置して運用していたオンプレミス型のグループウェアをいわゆるSaaS型に切り替えるという事例である。この事例の場合、RFPを記述する上でどのような点がポイントとなるかといえば、最重要ポイントはやはり「データの移行」である。

　例えばRFPに以下のような要求を書いたとする。

1. 既存グループウェアのデータ（スケジュール、掲示板、ワークフローなどすべて）を新システムに移行すること
2. 上記のデータ移行はツールなどの利用により、自動的に移行すること
3. 既存システムではワークフローは当社業務に合わせて、○○機能をカスタマイズしているが、その仕様を踏襲すること

　上記のような要求が満たされる提案がSaaSベンダーから提示されるならば、ユーザーにとって非常に幸福なことであるが、現実はそう簡単ではない。例えば1のような要求は既存グループウェアとSaaS型グループウェアの「相性」によってその実現性が大きく異なる。同製品のオンプレミス型からSaaS型への移行であれば、比較的容易に実現できる製品もある。しかし、他の製品に乗り換える場合は、要注意である。

　特に制約となるのは既存グループウェアのデータの持ち方である。CSVでデータを吐き出せるならデータ移行できる可能性は高いが、そうでないとすると難しい場合が多い。難しいというのは「コストを掛ければできなくはない」ということであり、コストを費やしても移行するか、それとも古いデータを思い切って捨ててしまうか、という判断をする必要がある。このコスト判断、言い換えれば要求の優先順位というのは、RFP作成時において非常に重要な要素である。2にも関連するが、SaaS型グループウェアを提供するベンダーはさまざまなデータ移行ツールを用意しているが、その多くは相手（既存グループウェア）が「有名で実績多数」の場合がほとんどであり、もしマイナーなグループウェアを使っているとしたら、ツールは存在しないと思った方がよいだろう。そのような場合、データの移行にこだわるか、それともSaaS型の新機能や運用容易性を取るか、という要求の優先順位が問題となってくる。また3のような要求の優先順位が高いのであれば、そもそもSaaS型を利用すべきか否かという根本的な議論となってくる。

　繰り返しになるがデータ移行というのは、手間とコストが掛かる作業であるということを、RFP作成段階でも強く認識する必要がある。それ故、移行対象となるデータに関しては以下のように優先順位を明確にしておくとよいだろう。

• 移行が必須のデータ（たとえ手入力となっても移行すべきデータ）
• 移行できるとありがたいデータ
• 捨てても差し支えないデータ

　上記の優先順位が明確になっているとRFPの実効性が高まるだけでなく、ベンダーおよび製品選定作業もやりやすくなるはずだ。