IT・ベンチャーの企業法務

システム開発での旧システムからの移行に伴う法律問題

2019.07.19

2023.01.19

企業で用いる新たなITシステムを作ることはITエンジニアの代表的な職域ですが、「新たなシステムを作る」という場合、そこでは「これまで使われていたシステムを撤廃する」というプロセスもまた、同時に含まれている場合が多いものです。本記事では、新システムの開発というプロジェクトをあえて「旧システムの撤廃」という側面から捉え直したうえで、それに付随する諸々の法律問題について解説していきます。

この記事の目次

新システムへ移行するとはどういうことか

ITシステムの寿命は永遠ではない

企業で用いるITシステムは、一度作れば永続的に使い続けられるものかというと、決してそうではありません。またそもそも、古いものをいつまでも大事に使い続けることが必ずしも良いわけでもありません。企業ごとに、またシステムの用途ごとにも当然バラツキはあるものの、大まかな目安として、ひとつのシステムは長くてもだいたい１０年程度使い続けたら、新しいものに一新するほうがよいという経営判断が下される傾向があります。

１０年もあれば、市場に流通するコンピューターの性能も様変わりしてしまうものです。そうなればたとえば、１０年前には（人間からみればシンプルで優れた設計であるものの）コンピューターの処理速度などの制約によって実装が現実的でなかったプログラムも、現在では実装可能になっているということもあるかもしれません。また、一度作ってから１０年間も使い続けてきていたのであれば、その間に会社の業務のワークフローや、社内のルールも随分変わってきているかもしれません。そうした会社の内外の経営環境の変化に対応すべく事後で実装されてきたコードは、画面側からは認識できないほどに複雑で入り組んだ構造になってしまっているかもしれません。こうなると徐々にユーザーにとって追加してほしい機能があっても、開発者側からみて最早追加の実装が不可能になってしまっているというような事態にもなりえます。

古くなったシステムは、徐々にITエンジニアに多くの「手作業」（たとえば個別にデータを抽出するためのクエリを発行するなどの運用業務）を多く発生させてしまうことがあります。システムそれ自体も、古くなれば皮肉にも業務を「属人化」させていくのです。古くなりすぎて、属人的な業務が多くなってきたシステム関連の業務に対して、さらなる「システム化」の施策を講じようとするとき、そこには「旧システムから移行するための新システムの開発」というプロジェクトが立ち上がることになるのです。

新システムの開発は、旧システムの撤廃とともに進む

先述の通り、（すべてのシステム開発のプロジェクトがそうではないにしろ）ひとつのシステム開発プロジェクトには、旧システムからの移行という側面も同時に併せ持っていることが多いものです。システムそれ自体は、ある日を界に非連続に切り替わることも多いものでしょう。

しかし日々の業務の進行そのものは、過去から現在、現在から未来に向かって連綿と連なっていくべきものです。過去のデータは必要な分保管しつつ、現在の業務の進行は遮ることなく、さらに未来に向かって優れた「システム化」の構想を打ち出すことなど、新システムへの移行には様々な課題が伴うことが多いものです。これらの事情が複合的に合わさることにより、新規システムの開発と、既存システムの運用・保守などの業務は複雑に関連しあい、切っても切り離せない関係にたつような場合も出てくるのです。

新システムへの移行ステップとは

旧来のシステムから、新規のシステムに移行する際に、特に重要になるのは、データを適切に移行させることです。データを移行させる際のステップは一般的に次のような手順に沿って進むことが多いものです。

旧システムが保管しているデータのうち、新システムに移行させるべきものがどれであるのかを明確にする→新システムの画面側からも容易に検索可能にすべきデータがどれであるのか、また、画面側からの検索は可能でなくてもよいが（監査対応などの際に）必要に応じて取り出せるようにしておくべきデータがどれであるのかなどの区別もあわせて必要となります。
１で特定したデータのうち、新システムに取り込むべきデータを、CSVファイルなどの形式で出力する。
２で抽出したデータを、新システムに取り込む。
３によって取り込まれたデータが、新システムにおいて反映されているのかどうかを検証し、正しく移行がなされているかどうかを確認する。　　 →正しく移行できているかの検証結果は、画面側の表示画面や帳票の印刷によって、エビデンス資料を残すことが通常です（いわゆるテスト工程）。

新システムへの移行はユーザーとベンダーの役割整理が難しい

前掲のデータ移行のステップにおいて、往々にして問題となるのは、ユーザーの側がそれをどこまで自社の内部の問題として、管理下におくべきなのかという問題です。なお、データ移行の話に限らない、システム開発プロジェクト全般における「ユーザーの協力義務」についての概説は、下記の記事をご参照ください。

システム開発の発注者であるユーザー側が負う協力義務とは

一般論としてシステム開発というプロジェクトにおいては、たしかにベンダーの方がシステム開発のための専門的ノウハウという面でユーザーに優越すること多い（もしくはむしろ、その点にこそ業務を任されている理由があることが多い）ものです。しかし一方で、自社のシステムの「あるべき姿」について論じることはユーザー側にしか行いえないということが多いものです。

そうした点に踏まえるならば、先述の手順１、４をユーザーが行うという役割整理が一つ考えられます。あえて別の言い方をするならば、一連のデータの移行に際して、移行すべきデータの”要件定義”、要件どおりにデータを移行できたかどうかの”検収”がそれぞれユーザーの協力義務というように整理するやり方だとも言えるかもしれません。もしくは別の整理の仕方として、ユーザー側にも当該旧システムについて豊富な知識を有する人がいる場合であれば、手順２についてもユーザー側の担当としてしまうことも考えられるでしょう。

あえて外注に回さずとも、旧システムの話は社内で対応可能ということであれば、新システムの話のみをベンダーに外注したいという考えで発注されることも考えられます。こういったかたちで、データの移行作業においては、ユーザーとベンダー、それぞれの役割整理はときに曖昧になってくる場合があるのです。なお、ユーザーがベンダーにシステム開発関連の業務を外注する場合に、通常ベンダーにどういった役割が期待され、どのような法的義務が帰属することになるのかといった点についての一般的な解説については、下記の記事も合わせて参照してください。

システム開発におけるプロジェクトマネジメント義務とは

新システムへの移行にかかわる過去の裁判例

新システムへの移行を目指すシステム開発プロジェクトにおいて、実際にトラブルが発生し、裁判となった事案は現に存在します。下記に引用する判決文の事案は、データ移行時に移行作業に失敗し、新システムにおいて複数のデータの不整合・バグが発生するなどのトラブルが発生し、納期にも遅れが生じたというものです。そうした種々のトラブルに対し、ベンダー側・ユーザー側がそれぞれプロジェクトに対していかなる義務を負っていたかが争点となりました。結論としては、ベンダー側が本来負うべき注意義務として以下の内容を判示し、ベンダー側の注意義務違反を認定しました。

被告は，本件請負契約に基づくデータの移行業務として，本件旧システム上のデータを本件新システムに単に移行させることにとどまらず，移行したデータにより本件新システムを稼働させる債務，具体的には，データの移行業務を開始する前に，本件旧システム上の移行の対象となるデータを調査・分析して，データの性質や状態を把握し，そのデータが本件新システムに移行された後，その稼働の障害となるかを検討し，障害となる場合には，いつ，いかなる方法で当該データを修正するかなどについて決定した上で，データの移行業務（移行設計，移行ツールの開発，データの移行）に臨み，最終的には，本件旧システムから移行したデータにより本件新システムを稼働させる債務を負担していた
ものと認めるのが相当であり，本件においては，データ移行に当たり，データ不整合を是正・解消すべき義務を負うものというべきである。
東京地判平成２８年１１月３０日

この事案は、手順１と手順４をユーザー側が引きうけ、手順２と手順３をベンダー側が引き受けるという役割整理が本来なされていたものです。つまり、旧システムからのデータの抽出（手順２）をベンダー側で一度引き受けていたという話となります。したがって裁判所も、データの抽出まで含めて、（システム開発の専門業者として）ベンダーが引き受けたのであれば、そのデータの抽出作業が本当にスムーズに行いうるか否かなども含めて事前に検討できてしかるべきであったと判断されたのです。

もっとも、もし手順２（つまりはデータの抽出）をユーザー側の業務として事前に役割整理をしていて、そのうえで抽出作業に失敗していたような場合はどうなっていたでしょうか。この場合に考えられることとしては、ユーザーがデータ抽出がスムーズに行いうるかどうかの事前調査を怠ったせいで納期に遅れが生じたものとして、今度は逆にユーザー側が協力義務違反を追及されてしまうといった展開になる可能性もあるでしょう。

また、こうした判断は、必ずしも契約書のみならず、システム開発の進捗に合わせた議事録なども証拠として行われます。議事録の重要性に関しては下記記事にて詳細に解説しています。