システム・アプリ関連紛争

改元に伴うシステム改修のトラブルに対する法的責任

弁護士 石田 優一

 

平成31年4月1日,新元号が「令和」に決まったことが発表されました。そのような中,IT企業においては,改元前のシステム改修作業に追われています。このコラムでは,新元号対応のシステム改修において法的トラブルが発生した場合のIT企業の対応と,このような法的トラブルの予防策について取り上げます。


第1章 はじめに

平成31年4月1日,新元号が「令和」に決まったことが発表されました。新元号は,5月1日に施行される予定です。

 

そのような中,IT企業は,新元号に対応するためのシステム改修の対応に追われています。今後,新元号対応のためのシステム改修をめぐって,IT企業(ベンダー)とユーザーとの間で法的トラブルが発生することも考えられます。新元号対応のためのシステム改修にかかわるベンダーには,このような法的トラブルを想定した対応が求められます。

 

もっとも,昭和から平成に改元された際には,コンピュータが現在のように普及しておらず,改元に伴って必要とされるシステム改修も限定的なものでした。そのため,今回の改元では,これまでの経験をもとに想定することができなかったトラブルが発生することも予想されます。

 

このコラムでは,新元号対応のためのシステム改修に不備があった場合に,ベンダーがユーザーに対してどのような法的責任を負う可能性があるかについて検討しながら,限られた期間の中でベンダーに求められる対応について考えます。

 

第2章 システム改修の必要性

新元号に対応するためのシステム改修の必要性については,情報処理推進機構(IPA),日本マイクロソフト株式会社等から説明資料が公表されています。これらの資料をもとに,システム改修の遅れによって想定されるトラブルの例をご紹介します。

 

1 データベースの不具合

これまでデータベースに和暦を使用していた場合,新元号で入力した日付データがシステム上は「日付」として認識されず,システムエラーが発生してしまうおそれがあります。

 

また,無効な和暦がデータ入力されるのを防ぐために,そのようなデータが入力された場合に例外処理を行う仕様になっている場合,新元号を使用した和暦の入力によって,エラーが発生するおそれがあります。

 

日本の企業では,発注書や請求書といった契約関係書類等に,西暦ではなく和暦を使用している例が多く,それに併せて,システムのデータベースでも和暦表記の日付データを用いていることが多くあります。これらの問題についてきちんと検証しておくことは,日本の多くの企業に求められます。

 

2 システム連携に伴う不具合

他社との間でシステム連携を行っている場合,たとえ自社のシステムが改元に対応していても,他社のシステムが改元に対応していなければ,データを連係する際にシステムエラーが発生するおそれがあります。また,このようなトラブルは,自社内の複数のシステム間でも発生するおそれがあります。

 

日本マイクロソフトが公表している資料では,データ交換における原則として,「送信は厳格に。受信は寛容に。」という考え方が示されています。システム連携を行っている場合には,他のシステムにデータを送信する際には,他のシステムでエラーが発生しないように,できる限り和暦を含むデータを送信しないことや,送信する場合には連携先のシステムでエラーが発生しないかを確認する対応が求められます。一方で,他のシステムからデータを受信する際には,たとえ和暦を含むデータが他のシステムから届いたとしても対応できるように,システムを実装しておく必要があります。

 

3 元号で1文字表記(合字)を使用しているシステムの不具合

合字とは,2つ以上の字を1つの文字として表現したものです。「平成」の文字を縦長にして1文字にした表記を,時々見かけることがあるかと思います。合字は,Unicodeにおいて割り当てられた文字の1つであるため,新元号「令和」の合字も,今後,Unicodeに新たに割り当てられることが予想されます。また,「令和」の合字がUnicodeに新たに割り当てられても,使用しているフォントがきちんと対応していなければ,適切な表示ができません。

 

4 OSやアプリケーションの更新に伴う不具合

今後,新元号「令和」への対応のため,OSやアプリケーションの更新プログラムを適用してアップデートしていく必要性があります。ただ,OSやアプリケーションのアップデートに伴って,システムに不具合が発生することも考えられます。

 

特に,これまでシステムの動作への影響を考慮してOS等のアップデートを差し控えてきたケースにおいては,深刻な問題です。

 

OSやアプリケーションの更新プログラムを適用する前に,これまで公開されている更新プログラムをOSやアプリケーションに適用することで,システムの動作にどのような影響が出るおそれがあるかについて,事前に情報収集を行っておく必要があります。

 

そのうえで,OSやアプリケーションの更新プログラムを適用するスケジュールを綿密に決めて,システムを使用する業務に支障が生じないように配慮する必要があります。

 

第3章 システム改修の対応をどのように進めるべきか

1 ベンダーには無償対応が求められるか

システム開発を担当したベンダーは,システム納入後もシステムの保守を行う契約を締結していることが多くあります。このような契約を締結している場合,ユーザー側から新元号対応のためのシステム改修を求められた場合,無償対応をしなければならないでしょうか。

 

これについては,システム保守契約においてどこまでの保守対応が予定されていたかによって変わります。少なくとも,天皇生前退位が発表される前に締結されたシステム保守契約であれば,保守対応の範囲として,新元号対応のためのシステム改修まで含まれていたということは難しいと考えられます。また,天皇生前退位が発表された後にシステム保守契約が締結されていたとしても,少なくとも,新元号対応のためのシステム改修に一般的な保守と比べて多額のコストを要する場合には,このようなシステム改修を無償対応することまでは契約上予定されていなかったと考えられます。

 

もっとも,ユーザーは,システムの仕様について十分に理解していないことが一般的であるために,第2章で取り上げたような改元に伴う不具合がシステム上で発生した場合に,ベンダーに対して無償でのシステム改修を求めてくる可能性があります。このような場合には,システム保守契約の内容を見直したうえで,システム改修に必要なコストも踏まえて,本当に無償対応をすることが法的に求められるのかどうかを検討する必要があります。

 

ユーザーとの間でシステム改修費用について折り合いがつかない場合には,弁護士に相談することが望ましい対応です。なぜなら,ベンダーがどこまで無償対応すべきかは契約解釈の問題であり,システム関連紛争に関する法的知識が問われるからです。

 

2 ユーザーとの打合せにおいて留意すべき点 

(1) 和暦表記のリスト化

ベンダーがユーザーからシステム改修作業の依頼を受けた場合,あらかじめ,ユーザーと綿密な打合せをしておく必要があります。なぜなら,ユーザーがシステムを業務でどのように利用していて,新元号に対応しなければどのような支障が出る可能性があるかは,ユーザーから聴き取りを行わなければ,把握することができないからです。

 

打合せにおいては,まずはユーザー側で,システムを利用するどのような場面で和暦表記を使用しているかをリスト化してもらうことが望ましいです。なぜなら,和暦表記を使用している場面は,実際にシステムを利用しているユーザー側のほうが把握しやすいからです。

 

もっとも,ユーザー側で作成したリストを鵜呑みにしてシステム改修作業に着手するのは,ベンダー側の対応として不適切です。なぜなら,ユーザー側は,システム内部において和暦表記がどのように使用されているか,把握することができないからです。ベンダー側は,ユーザー側が挙げたリストをもとに,システム内部で使用される和暦表記を改めてリスト化すべきです。

 

このように,双方で作成したリストを改めて打合せにおいてすり合わせることで,システム改修作業が必要な点を漏れなく整理することができます。

 

(2) 対応スケジュールの調整

システム改修作業が必要な点を洗い出した後には,対応スケジュールの調整が必要です。第2章で取り上げたように,新元号対応のためのシステム改修作業には早急な対応が求められる一方で,OS等のアップデートを伴う場合には,システムの動作に影響が生じるおそれがあります。

 

ベンダー側は,システム改修作業によってシステムの動作に影響が生じる可能性についてきちんとユーザー側に説明したうえで,対応スケジュールについて綿密なすり合わせを行っておくべきです。

 

(3) システム改修完了後のフォロー

ベンダー側は,システム改修が完了し,運用がスタートした後に,改めてユーザー側と打合せを行い,トラブルが発生していないかどうかをフォローすべきです。ベンダー側にとってこのようなフォローはコストに感じられるかもしれませんが,事後のトラブルを防止するうえでは,必要な対応です。

 

3 ベンダーのプロジェクトマネジメント義務

一般に,ベンダーは,ユーザーに対して,プロジェクトマネジメント義務を負っています。プロジェクトマネジメント義務には,(1) プロジェクトの進捗状況を管理して改修作業を阻害する要因の発見に努め,適切に対処する義務や,(2) ユーザーによって開発作業を阻害する行為がされないように働きかける義務等があります。

 

ユーザーにはシステムに関する専門的知識がないために,どのようにベンダー側と打合せを進めれば円滑にシステム改修作業を完了することができるか,的確な判断をすることができません。だからこそ,ベンダーは,プロジェクトマネジメント義務を負い,ユーザーに対して適切な働きかけを行うことが求められるわけです。

 

特に,新元号への対応は,スケジュールが限られており,かつ,スケジュールの遅延によるユーザーへの影響が大きいことから,ベンダーとしては,プロジェクトマネジメント義務を十分に意識することが求められます。

 

ユーザーとの間でシステム改修に関する契約を締結する前であっても,ベンダーには,信義則上の義務として,プロジェクトマネジメント義務が課せられます。そのため,ベンダーは,契約締結前であっても,ユーザーに対して主導的に打合せ等を提案し,期限内でのシステム改修作業の完了に向けて適切なスケジュール調整を行う必要があります。

 

4 必ず新元号施行前にシステム改修を完了させるべきか

ユーザーから新元号対応のシステム改修作業を求められた場合に,ベンダーは,「必ず新元号施行前にすべての対応を終わらせなければならない」と考えるかもしれません。しかし,「安請け合い」をすることは,法的トラブルを招くおそれがあります。

 

先ほどご説明したとおり,たとえベンダーとユーザーとの間でシステム保守契約を締結していたとしても,システム改修作業を行うことまでが契約上予定されているとは限りません。むしろ,システム改修作業がシステム保守契約の内容に含まれるケースは,かなり限定的であると思います。

 

システム保守契約で義務づけられていない限り,ベンダーには,ユーザーから求められた対応を「断る自由」があります。多くのベンダーは,「ユーザーから言われたことは絶対に守らないといけない」という感覚をお持ちかもしれません。しかし,ユーザーは,ベンダーにどれほどの負担がかかるかを意識せずに,安易に対応を求めていることが多いのです。

 

ベンダーは,新元号対応のシステム改修作業を求められた場合には,早期に打合せの期日を設定し,必要な対応の洗い出し作業見積もり必要な工数の検討を実施すべきです。そのうえで,ユーザーが求める期限までに対応ができないのであれば,ユーザーにきちんと事情を説明して,対応の優先順位を決めてスケジュール調整をしたり,通常よりも報酬を上げて対応人員を増やしたりすることが求められます。

 

もし,ユーザーとどうしても折り合いがつかないのであれば,「受託しない」という対応も,ベンダーには残されています。ベンダーは,「断ったら信頼に傷がつく」と考えるかもしれませんが,もっとも信頼に傷をつけるのは,「一度契約したことを守れないこと」です。

 

第4章 システム改修で法的トラブルが発生した場合

1 法的トラブルが発生したらどうすればよいか

システム改修作業が完了した後に,万が一,ユーザーからベンダーに苦情が来た場合には,ベンダーとしては,どのように対応すべきでしょうか。

 

もちろん,ベンダーは,ユーザーとの信頼関係を維持するために,ユーザーからの苦情には適切に対応することが求められます。ただ,ベンダーは,たとえユーザーからシステム改修の内容について苦情を受けたとしても,必ずしも損害賠償等に応じなければならないわけではありません。

 

2 ベンダーの法的責任についての考え方

システム改修作業に問題があったとしても,ベンダーは直ちに法的責任を負うわけではありません。

 

一般に,システム開発においては,一定割合でバグが生じることは避けられないために,ベンダーが法的責任を負う場合は,(1) ユーザーから不具合発生の指摘を受けて遅滞なく補修を終える等の対応を行わなかったようなケースや,(2) バグがシステムの機能に軽微とはいえない支障を生じさせ,遅滞なく補修することができないか,その数が著しく多く,しかも順次現れてシステムの稼働に支障が生じるようなケースに限定されると考えられています(ダイセーロジスティクス事件,東京地判平成9年2月18日)。

 

新元号対応のシステム改修作業においても,求められる対応が多岐にわたることからやむなくバグが発生してしまい,ユーザーの指摘でベンダーが遅滞なくバグの修正対応を行ったような場合であれば,ベンダーが法的責任を負わないことは十分に考えられます。

 

また,システム改修作業に当たってユーザーと綿密な打合せを実施していたかどうかは,ベンダーの法的責任を考えるうえで重要な要素になると考えられます。

 

ユーザーは,「新元号対応くらいのことでどうしてバグが発生するのか」と不信感を抱くかもしれません。しかし,新元号に対応するだけの改修作業であったとしても,システムの一部分を改修すれば他の部分に新たな支障が発生するといった事情で,実際にはベンダーに求められる対応が多岐にわたることは十分にあり得ます。特に,システム間での連携を伴っている場合には,他のシステムの仕様も検討しなければならず,求められる対応も自ずと増えてしまいます。このような認識の差は,ユーザーとベンダーとの間に専門的知識の差があるために,避けられないことです。

 

ベンダーは,ユーザーから法的責任を追及された場合には,本当に法的責任を負うケースであるかどうかを検討したうえで,ユーザーに対して合理的な主張をすべきです。

 

もっとも,このような対応には,システム関連紛争に関する法的知識が求められますから,対応に苦慮する場合には,迷わず弁護士に相談すべきです。

 

3 損害についての考え方

たとえ,ベンダーが法的責任を負うケースであっても,ユーザーの言い値を損害賠償金として支払わなければならないわけではありません。

 

新元号対応のシステム改修に問題があってシステムの運用に支障が生じた場合,ユーザーは,「システムを全く利用することができなかった」前提で,損害算定を行ってくることが予想されます。しかし,このような算定方法の妥当性は,ベンダーにおいて,きちんと検討すべきです。

 

例えば,システム改修に不備があって,発行する文書に「平成31年5月」といった表記しかできなくても,そのシステムを業務に全く利用することができないかといえば,必ずしもそうではありません。例えば,発行した文書の「平成31年」という文字に二重線を引いて,「令和元年」と書き換えて使用する等の対応も考えられます。実際,昭和から平成に改元した際には,急遽の改元に対応するために,このような暫定措置を講じた例がありました。このような対応による代替措置でも特段の支障が生じないケースであれば,「書き換え対応に伴って生じる人件費等のコストのみを損害と考えるべき」といった反論も考えられます。

 

現行制度において元号の法的根拠となる唯一の法律は,元号法(昭和54年法律第43号)です。ただ,元号法には,元号の法的意義については特に定められていません。仮に,契約書等の法的文書に「平成31年5月1日」といった記載があったとしても,その意味する日を特定することはできますので,その法的効力に影響はないものと考えられます。

 

ベンダーとしては,ユーザーからの「新元号の対応ができていなかったからシステムを全く利用することができなかった」という主張をされたとしても,そのような主張に本当に法的観点を踏まえた合理性があるかを検討すべきです。そして,ユーザーの主張について合理性に疑いがある場合には,率直に疑問を提示して,納得のいく説明を求めるべきです。

 

損害額をめぐってユーザーと折り合いがつかない場合には,弁護士への依頼を検討すべきです。なぜなら,損害算定の方法を検討するうえでは,不法行為・契約責任に関する制度や,システム関連紛争に関する法的知識が求められるからです。

 

第5章 おわりに

新元号対応のためのシステム改修に関して法的トラブルが発生した場合には,当事務所にご相談ください。当事務所は,神戸市・兵庫県内の企業様に限らず,幅広い地域の企業様からのご相談に対応しております。当事務所の弁護士が,システム関連紛争に関する法的知識と経験をもとに,迅速かつ的確に対応いたします。

 

ー当事務所の「システム・アプリ関連紛争」法務サービスはこちらですー

 

ー当事務所でご提供する法人向けサービスのご案内はこちらですー

 

―コラムの一覧はこちらです―

このコラムを書いた人

弁護士 石田優一
兵庫県弁護士会所属 68期 登録番号53402
情報処理安全確保支援士、応用情報技術者の資格を持つ若手弁護士。IT、IoT、営業秘密など、いつでもすぐに、最新の問題に対応するリーガルサービスを提供できるよう、5年先、10年先を読みながら、日々研鑽を積んでいる。
プロフィールはこちら

同じカテゴリのコラム記事

システム・アプリ関連紛争
Androidアプリの脆弱性に対する開発者の法的責任
システム・アプリ関連紛争
アプリを企画する前に知っておきたい法律知識

みおの関連サービス