システム運用段階での紛争・トラブルにまつわる法律とは

ITシステムを開発するプロジェクトにおいて、様々な紛争・トラブルが起こりうることはよく知られる通りです。しかし一連の開発プロジェクトは、無事全工程完了しさえすれば万事一安心かというと、決してそうではありません。企業で用いられるITシステムはその性質上、大量の機密情報・個人情報を扱うものとなるのが通常であり、運用段階でも様々な問題が起きることがあるためです。したがって運用段階においても、そうした事態に対する対応策の検討や予防に法律の知見を活かしていくことが大切になります。

開発と運用で、システムにまつわる法律論はどう変わるか

企業で用いるITシステムに関連する法律問題の典型にあたるのは、やはり「開発」段階におけるプロジェクトの「炎上」問題です。システム開発のプロジェクトは、多数の人手・資金・期間を投じて行われる大規模な事業となる場合が多く、大なり小なり様々な紛争・トラブルのリスクを抱えながら進んでいくのが通常です。

上の記事では、一連のシステム開発プロジェクトのなかで起こりがちな紛争の類型を、法的な枠組みに沿って整理しています。また、ITシステムにまつわる法律問題を特徴付けるものは、システム開発の専門家であるベンダーが包括的に負うものとされる「プロジェクトマネジメント義務」があります。

もっとも、ITシステムは「開発」した後は「運用」というフェーズに移っていきます。ITシステムにおける運用とは一言でいうなら、開発されたシステムを活用・操作して、実際の業務を執り行うことをいいます。ITシステムを活用するためにはその仕様を熟知していることが必要な場合も多いため、ここでもIT系技術者の力が必要となる場合が多くあるのです。ITシステムが開発・運用いずれにおいても技術的な知見を要するということは、両者の区分は実務的には曖昧になる場合もあるということです。そうしたことを端的に示す例としては、「サポート義務」というものの存在を挙げることができます。

上の記事では、システム開発のプロジェクト中にベンダーが負う「プロジェクトマネジメント義務」と区別して、開発後の運用・導入にむけた支援を行う義務として、「サポート義務」というものを認めた裁判例を紹介しています。つまり、以後の運用フェーズの事情も踏まえながら開発業務を受けるベンダーの法的義務が決まってくる場合もあるということです。また、新システムの開発が、旧システムの撤廃と同時に進んでいくような場合には、旧システムの「データ移行」などが課題となる場合があります。こうした場合にも、旧システムの運用と新システムの開発は密接に関連しあうことになります。

システムの運用にまつわる法律問題はどう整理すべきか

以上、ITシステムにまつわる実務が「開発」と「運用」で密接につながり合うものであることがわかりました。とはいえ、運用フェーズでは、開発プロジェクトが終了しているため、「プロジェクトマネジメント義務」の問題と切り離して考えることも必要となります。「開発」と「運用」の法律問題を統一的に論じるためには、実務からやや法律寄りに、抽象度の高い枠組みで整理することが必要となります。たとえば以下の記事で解説する、ITシステムに関連する法的「 責任」という観点からの整理はその一例です。

上の記事では、民事上の債務不履行責任・瑕疵担保責任・不法行為責任などについて、ITシステムの文脈を踏まえながら解説しています。しかし、運用において瑕疵担保責任が問題となる事案は、検収後に不具合が事後発覚するような場合を除くと、そう多く想定されるものではありません。したがってまずは、契約内容を根拠とする債務不履行責任と、契約関係を前提としない不法行為責任の二つを念頭に置いて整理をしていけばよいでしょう。

まずベンダー側の義務違反の有無を検討

債務不履行責任であれば契約上の義務の違反、不法行為責任であれば「他人の権利の侵害」といった実態があるのか否かが争点となります。債務不履行責任であれば、サービスレベルアグリーメント（SLA）の記載事項が問題となります。なお、債務不履行責任・不法行為責任はいずれも故意または過失を要件とする点にも注意しましょう。

次にユーザー側の損害の発生状況を確認

損害賠償義務は、ユーザー側に生じた被害事実に対して負うものです。そのため、債務不履行・不法行為いずれの場合であれ、ユーザー側に損害が発生していないのであれば賠償義務を負うことにはなりません。

さらに過失相殺・制限責任条項の適用可否なども検討

なお、ベンダー側が損害賠償義務を負うことになるとしても、ユーザー側にも何らかの過失があるような場合には、過失相殺といった処理がなされることも考えられます。また、事前に締結した契約で賠償金額に制限を設けている場合にも、それによって賠償金額が変化する場合があります。たとえば経産省モデル契約と呼ばれる契約書の代表的な雛形では、制限責任についていかのような規定が置かれています（下線部は筆者が追記したものである）。

（損害賠償）
第 53 条 甲及び乙は、本契約及び個別契約の履行に関し、相手方の責めに帰すべき事由により損害を被った場合、相手方に対して、（○○○の損害に限り）損害賠償を請求することができる。但し、この請求は、当該損害賠償の請求原因となる当該個別契約に定める納品物の検収完了日又は業務の終了確認日から○ヶ月間が経過した後は行うことができない。

2.前項の損害賠償の累計総額は、債務不履行、法律上の瑕疵担保責任、不当利得、不法行為その他請求原因の如何にかかわらず、帰責事由の原因となった個別契約に定める○○○の金額を限度とする。

3.前項は、損害賠償義務者の故意又は重大な過失に基づく場合には適用しないものとする。

システムの運用で起こりがちなトラブル・紛争の事例とは

また実務上、システムの運用において想定されるトラブル・紛争の代表例には以下のものがあります。

運用担当者のミスによって発生するデータ紛失などの事故

システムの運用にかかわる仕事は、重要な企業秘密・個人情報の処理にかかわるものが多く、不注意から事故が起きる場合があります。その一例には、「データの紛失」があります。こうした事案については、以下の記事で詳細に解説しています。

データの紛失などの事故には、あらかじめバックアップをとっておくなどの備えを講じておくことが重要です。こうした対策を怠っていた場合、運用業務を任されていたベンダー側への責任追及はきわめて困難になることが考えられるので、注意が必要です。

ウィルスをはじめとするセキュリティ攻撃

他にも、ECサイトのように不特定多数の人がWeb上で大量に利用するようなITシステムの場合には、ウィルスをはじめとするセキュリティ攻撃によって大きな事件や事故になることがありえます。こうしたセキュリティ攻撃を検知することや、対策を講じることなども、運用業務の一部とされる場合があります。

検収合格後に発覚するバグや不具合

また、検収合格後にバグや不具合が新たに発覚する場合もあります。事前のテスト工程であらゆるバグや不具合の可能性を網羅的に検討し尽くせるとは限らず、事後で発覚することがあるためです。こうした場合は、すでに納品は完了していることから、債務の履行自体は完了していると評価され、債務不履行責任からは免責されるのが通常です。しかし、瑕疵担保責任に基づく損害賠償請求などが認められる場合もある。こうした場合については、以下の記事で詳細に解説しています。

まとめ

システムの「運用」といった段階では、開発プロジェクトとは性質の異なるトラブル・紛争が数多く存在します。しかし、債務不履行責任・不法行為責任・瑕疵担保責任といった法律論を基礎に据えることによって、その違いに囚われない統一的な分野の整理が可能となります。