システム開発プロジェクトは総合テストに入り，本番稼働が見えてきました。しかし，データ移行がうまくいかず，ユーザと揉めています。ユーザからは，新システムに旧システムのデータが正しく入らない限りシステムの検収はできないと言われています。我々は，データ移行をサポートするとは言っていますが，結果について責任は持てません。

データ移行に関する契約形態と，うまくいかない原因が問題となります。データ移行業務が「請負契約」となっていた場合でも，その範囲が，データ移行プログラムを作ることを請け負っていたのか，新システムへの旧システムからのデータ移行そのものを請け負っていたのかによっても責任範囲が変わります。

（ａ）データ移行でトラブルになることが多い

システムの障害などの機能的な問題によってトラブルが生じることも多いですが，データ移行関係でトラブルが生じることも意外に多いと感じています。データ移行単体で特定のベンダに依頼するケースというのはほとんどありませんので，多くは，システム開発の付随的契約として（あるいは，一つの契約の付随的義務として）データ移行が含まれています。

通常のシステム開発もユーザとベンダの共同作業といえますが，データ移行の場合は，それ以上に，旧システムの内容をよく知っているユーザ（あるいはユーザが委託した旧システムの保守ベンダ）の主体的な作業，協力なくしてできない作業だといえます。

ところが，どうしてもタスクとしてはメインのシステム開発の脇に追いやられ，契約関係や役割分担が不明確なまま進むことが多くなるため，後にトラブルになりやすい傾向にあります。そもそも，現場でタスクとして認識されていながらも，契約に反映されておらず，「え，移行は御社が責任持ってやってくれるんですよね？」というような事態も起きています。

（ｂ）データ移行をどのような契約形態で進めるか

データ移行作業も，「移行計画の立案」「移行プログラムの設計」「移行プログラムの開発」「移行テストの実施」「本番移行」などのプロセスに分けられますが，それぞれのフェーズに応じて適切な役割分担と，それに適した契約形態（請負あるいは準委任）の選択が必要になります。

旧システムの開発・保守を同一ベンダが担当していたという場合でない限り，ベンダが完成責任を負えるのは，移行計画の中で切り出された移行プログラムの設計・開発の部分に限られるでしょう。旧システムのデータのクレンジングを行ったり整合性を担保できるのは，やはりユーザ（あるいはユーザから委託を受けた旧システムの担当ベンダ）ということになります。

これらの線引きを事前に行い，さらには契約条項に反映しておかないと，いざ稼働直前のテストを行う際に，トラブルが発生し，システム稼働全体の遅れを招きかねません。こうしたトラブルが少なくなく，また，一度トラブルになった場合に契約関係が不明確である場合には容易に解決しづらいため，契約実務において留意すべきです。

（弁護士　伊藤雅浩　H29.2.28）