システム開発終了後にベンダーが負うサポート義務とは

システム開発において、システム開発の専門業者であるベンダーが「プロジェクトマネジメント義務」を負うことはよく知られていますが、これと似て非なる概念として法律上は、「サポート義務」なるものも提起されています。本記事では、この「サポート義務」について、過去の裁判例等も踏まえて解説していきます。

サポート義務とは

サポート義務の概要

ベンダーがユーザーに対して負う義務という話では、代表的なものにはプロジェクトマネジメント義務があります。これは過去の裁判例等で繰り返し言及されながら確立されてきたものであり、システム開発の専門家としてベンダー側が一連のプロジェクトに対して負っている義務を総括した概念です。

プロジェクトマネジメント義務は、システム開発に関する法律用語としては非常に有名なものであり、ベンダーが引き受けている義務として主たるものであることは間違いありません。しかし一部の裁判例には、このようなプロジェクトマネジメント義務とは異なる義務の存在として、「サポート義務」というものの存在を認めているものがあります。

サポート義務はユーザーに対する運用支援で問題となる

ではサポート義務とはなんでしょうか。そしてそれはなぜ、あえてプロジェクトマネジメント義務とは異なる呼称で呼ばれるものなのでしょうか。サポート義務が問題になるのは通常、システムの開発が終了した後の場面です。システム開発プロジェクトは、そのプロジェクトが「開発」であるからには、たしかに基本的な考え方としては、作るべきシステムが完成したら終了となります。すなわち、作るべきシステムがなんであるかを明確化すること（＝要件定義）にはじまり、それが実際に出来上がったかどうかの確認（＝テストもしくは検収）をもって終わるのがシステム開発プロジェクトだということです。なお、検収という工程について、それが「システム開発プロジェクトの終了」として重要な意味を持つ点を踏まえつつ、この段階で生起しがちな法律問題については、以下の記事にて詳細に扱っています。

しかし、たとえシステム開発プロジェクトが、新しくシステムを作っていく開発工程そのものであると解したとしても、開発されたシステムはその後業務で活用されることになるのが当然の前提です。つまり、システムが開発された後でどのようにそのシステムを活用していくのかという点を一切不問にし、「開発業務のみを担う立場である以上、ただ作りさえすればよい」とまで言ってしまうと大きな非合理を生みかねないとも考えられるのです。こうした点を踏まえて、過去の裁判例においても、システム開発を担うベンダーに対しても、一定の運用支援の義務を課すことができないかが問題となってきたのです。すなわち、システム開発契約においてベンダーが負う義務のなかに、開発後の運用支援にかかわる義務も内包していると考えるべきなのではないかという問題です。運用支援は開発工程そのものではないことから、プロジェクトマネジメント義務と区別する意味で、サポート義務という言い回しがなされてきた経緯であると考えられます。
　

サポート義務が問題となった裁判例とは

システムテストの段階で、ユーザーの業務の実施に支障をきたした事例

以下に引用する判決文の事案では、システム稼動前に行われたシステムテストにおいて、ユーザー側が当初想定していたようにシステムを活用することができず、結果システムの稼動そのものをユーザーが断念するに至ったというものです。本件はユーザー側の運用開始時におけるトラブルであるところ、事前に交わされたシステム開発のための請負契約から、ベンダー側の責任をどのようにして根拠づけるかが問題となりました。結論としては、ユーザー側の損害賠償請求が認められ、その根拠としては「サポート義務の違反」が指摘されることとなりました。

イ　サポート義務違反
（ア）原告代表者は、平成九年七月一四日、被告に対し、「システムを作るだけでなく、きちんと回るように最後まで面倒見て欲しい。」、「うちは素人だから、高い金を出すのだから最後まで使えるようにして欲しい。」と申し入れた。これに対し、被告は、原告の導入目的を達成し得るシステムの構築が可能であると説明し、きちんと使えるようになるまでサポートすると約束した。これにより、原告と被告との間には、原告が本件システムをきちんと使えるようになるまで被告がサポートするとの合意が成立した。
被告が原告に対してサポート義務を負っていることは、本件請負契約の代金として、「パッケージ導入支援」という項目で一七二六万もの費用を計上していること、見積書には、月額保守料について、「導入後六か月間無償保守」と記載され、「今後のＳＥサポートについて（社内打合せ資料）」と題する書面には、生鮮発注について、「導入手順（計画）の作成」及び「データ／運用検証作業」についてＳＥサポートを受けられることが確認されていることからも明らかである。

（イ）そして、被告が原告に対して負うサポート義務は、具体的には、少なくとも原告が本件システムの本稼働に至るまで、被告が、原告に対し、①本件システムの運用方法についての適切なアドバイスを提供すること、②運用テストへの立ち会い及び運用テストで生じたシステム上の不具合についての対応をすること、③運用テストの結果に応じたシステムの改善をすること、④オペレーターに対する導入教育を行うことを指す
しかし、被告は、運用テストにおいてトラブルが多発しても、オペレーターの習熟度の問題であるとしてこれに真摯に対応しようとせず、オペレーターの導入教育費用を要求してくるだけで、原告に対し、本稼働へ向けた適切なサポートを何ら行わなかった。

東京地裁八王子支部平成１５年１１月５日判決

本判決文では、目次も含め判決文全体で、約３０回ほど「サポート」という語が登場してきます。適切な支援を求めるユーザーの声がそのまま判決文に記載されるなど、事案の経緯をかなり具体的に斟酌しつつ、公平な解決を目指した末の結論であったことがうかがえます。また本件の理解について特に注目してみるべき点としては、

• サポート義務の違反は、「債務不履行」と一つとして扱われているため、その結果生じた損害賠償までが命じられることになった点
• 「プロジェクトマネジメント義務」という用語は、判決文全体でみても、一度として用いられていない点

です。プロジェクトマネジメントと別の概念でありつつも、それをシステム開発の契約が内包する契約上の義務として扱おうとする姿勢が見て取れます。

サポート義務の性質はいかに解するべきか

サポート義務は未だ明確な概念ではない

先述の裁判例は要するに、システム開発を行なったベンダーはユーザーが運用開始するために必要なサポートも併せて行うべき旨を示したものです。しかしサポート義務は、プロジェクトマネジメント義務ほど判例の蓄積等が豊富ではなく、その実態を知る手がかりもさほど多くないのが現状です。とりわけ、「サポート」という用語自体も、具体的になにをなすべきかが判然としないという問題を含むものです。

サポート義務は無制限に認められるものではない

また、ベンダーのサポート義務違反を認めた上記の判決は、併せて非常に重要な点も判示しました。

被告は、本件請負契約に基づき、原告に構築・納入したシステムについて、原告がこれを運用するために必要な一定のサポートをする義務を負うものと解される。しかしながら、その内容が、原告が主張するような、期間を限らず、実際に原告が本件システムを運用することができるようになるまで、無償であらゆるサポートをするといったものであったとは解されない。

東京地裁八王子支部平成１５年１１月５日判決

引き受けた業務として主たるものがシステム「開発」なのであれば、その後の「運用」にむけたサポートとして行うべきことにも、自ずと制約があることを指摘したものであると考えられます。本判決においても、支援を求めるユーザーの声をあえて判決文で引用している点や、事前の見積りの内容にも言及している点や、サポートを行う旨の特約の有無などについても触れている点など、いくつか特色というべき点が見当たります。つまり、サポート義務の概念が無制限に拡張していくことになればベンダー側に大きな負荷を強いるものになる点を踏まえて、義務違反の認定そのものもある程度慎重に行う意図であったと考えられます。

サポート義務の内実は、ユーザーの協力義務もと併せて検討すべき

ここまでの話はつまるところ、「システム開発における運用の初期段階において、その業務負荷をユーザーとベンダーでどのように負担しあうか」という話であるともいえます。そこには確かに、「開発」に関する契約から、運用開始時にベンダーがどの程度の法的義務を負うのかという、やや難解な問題が含まれています。また同時に、個別事情を踏まえた判断が求められる傾向も強いと言わざるを得ません。

とはいえ、ベンダーが負うサポート義務の内実がいかなるものであるかは、ユーザーが負う協力義務についても理解することで、より確かなものとなると考えられます。

そもそも新たなシステムによって業務を改善していく取り組みは、技術の専門家たるベンダーと、社内の業務知識を有するユーザーの共同作業であるという面があります。そうであるからには、そのサポート義務なるものについても、ユーザーが「協力義務の履行」の一環として自助努力で解決すべき事項を明確にすることで、その範囲が自ずと定まってくる場合も多いと考えられます。

まとめ

本記事では、プロジェクトマネジメントについての基礎を踏まえつつ、その派生系ともいうべき「サポート義務」についての整理を行いました。サポート義務の概念には未だ曖昧な点も多く残りますが、その理解においても重要になるのは、やはり「プロジェクトマネジメント義務」や「協力義務」といった基礎的な事項であると考えられます。