システム再構築のプロジェクトに一度でもたずさわった経験のあるITエンジニアであれば,移行の難しさを誰もが知っているであろう。純粋な新規のシステム開発であれば,移行は考慮する必要はないし,あったとしてもCSVやテキストデータの取り込み程度の場合が多い。しかし,現実のシステム開発の現場では,新規案件よりも既存システムの陳腐化対応としての再構築案件の方がはるかに多い。この再構築には必ず「システム構築の最大の難関」といわれる移行が立ちはだかる。この移行を成功させない限り,新システムの運用を開始することはできないので,避けて通るわけにはいかない。

 ただし,RFPを作成する段階で移行に関する要求事項の詳細が分かるわけではない。移行に関する計画は現行システムと新システムの両方の仕様や構造を理解していないと立案することはできない。従って,要件定義,基本設計そして詳細設計と作業を進めていきながら,移行計画を具体化していくことになる。

 そのため,RFP作成の段階では移行に関しては限られた要求しか記述できない。だが,それでも移行に関する要求は必ず記載すべきである。それは,ベンダーを選定する上で非常に重要なポイントとなるからだ。たとえ提案書の段階であっても,移行を甘く見て,おざなりの移行計画やスケジュールを提示してくるようなベンダーは,移行作業で失敗する可能性が高くリスクが大きい。

 逆に移行に関しての見識が深く,慎重かつ適切な移行に関する提案をしてくるベンダーは信頼性が高い。移行はベンダーの力量や姿勢の違いが如実に表れる分野であるので,RFPでは移行計画(この段階では具体的な移行作業案ではなく,ベンダーの移行に対する基本的な考え方とか,移行期間や並行稼働のスケジュール感などを)を必ず提案してもらうように要求を行うべきである。そのためには下記に例示するような移行に関わる基本的な情報をRFPに記載してベンダーに情報提供を行う(図4)。

図4●移行に関する検討ポイント
図4●移行に関する検討ポイント

[データの移行]
 移行作業の中心となるのが,現行システムのデータを新システムに移す作業である。データの移行は右から左へと単純に移せるものではなく,さまざまな工夫を要する。データ変換ツールなどを用いる場合も多い。詳細の検討はシステム設計フェーズで行うことになるが,提案時にベンダーにある程度のあたりをつけてもらうために,データに関する情報を提供する必要がある。提供する情報は,以下のようなものがある。

・現行システム上のどのようなデータ(マスターやコード,履歴情報なども含む)を移行する必要があるのかを明示する。
・上記のデータのレコード数やテーブル数がどれくらいの件数があるのかを記述する。
・データはどれだけの容量があるのかを記述する。

[システムの移行]
 システムを移行し,運用を開始するにはデータ移行だけではなく,ほかにもいくつか考慮すべき点がある。このシステムの移行に関してはRFPの段階では発注側に具体的な要求イメージがない場合も多い。無理してユーザー側の要求として取りまとめるよりは,「このような点を忘れずに考慮して提案してほしい」という要求の出し方でも十分である。考慮点として漏れがないことが大事だからである。具体的には,以下のような考慮点を伝えて提案を要求する。

・他のシステムやネットワークとの接続に関して,どのようなタイミングと方法で現行システムと新システムの切り替えを行うのか。
・他社との接続がある場合,切り替えをどのように行うのか。
・ユーザーが仕様するPCも同時に新機種に移行するのかどうか。

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

[並行稼働]
 移行作業を確実に行い本番稼働を成功させるためには,現行システムと新システムを同時に運用する並行稼働期間として,数カ月の期間を取るのが理想的である。しかし口で言うのは容易だが,実際の並行稼働は,データの入力やアウトプットの確認をすべて二重にやらなくてはならないので,特にエンドユーザーに多大な負荷が掛かり,大変な作業となる。

 システムの規模やミッションクリティカルの度合い,あるいはエンドユーザーの負荷などを考慮して,並行稼働期間を取るのか,取るとしたら現実問題としてどれくらいの期間が妥当なのかを検討する。逆に諸事情により並行稼働を行うことが困難であり,一気にシステムの切り替えを行う場合は,ユーザー側の受け入れテストが重要になってくるのでその検討が必要となる。

 並行稼働に関する要求はユーザー側の都合に依存するので,RFPを書く段階でしっかりと議論し,方針を決めておく必要がある。もし,方針が定まらずベンダーの提案内容により検討したいということであれば,「並行稼働期間は最低1カ月」という要求を出して,様子をみるのも一つの方法である。

永井 昭弘(ながい あきひろ)
1963年東京都出身。イントリーグ代表取締役社長兼CEO,NPO法人全国異業種グループネットワークフォーラム(INF)副理事長。日本IBMの金融担当SEを経て,ベンチャー系ITコンサルのイントリーグに参画,96年社長に就任。多数のIT案件のコーディネーションおよびコンサルティング,RFP作成支援などを手掛ける。著書に「RFP&提案書完全マニュアル」(日経BP社)。