執筆：弁護士 森田 芳玄（AI・データ（個人情報等）チーム）
『連載:システム開発紛争の基本問題（９）システム開発における「完成」の意義』はこちらから
１．はじめに
システム開発業務を委託/受託するに際してトラブルに巻き込まれてしまうことは意外にあるものです。そのようなときに後悔しないように、本連載では事前に対処するべき事項や、実際にトラブルになってしまった際の対処法などをできる限りやさしく解説してゆくことを目的としています。
第１２回目は、システム開発において訴訟になる前に準備しておくべき留意点について検討してみたいと思います。
２．システム開発においてトラブルになる主な類型
システム開発契約については、それが１回限りの契約ではなく一定期間継続することが前提であることや、開発内容が高度化・複雑化していること、委託者側と受託者側において相互に目的となるシステム開発に必要な情報が偏在していること（＝相互に認識の齟齬が生じやすい）など様々な要素により、トラブルに発展する可能性が比較的高い類型といえます。
また、アジャイル型の開発手法のように、最終的な成果物の内容が確定しないまま開発が進行することが多くあることも、法務的にはリスクがあるということになります。そこで実際に生じるトラブルには以下のようなよく発生する類型があります。
①成果物の内容に関するトラブル
成果物について、委託していた成果物の内容と異なっているとか、委託していた機能が備わっていない、などのように成果物の内容に関するトラブルです。
②報酬の金額に関するトラブル
成果物自体は一応納品されたものの、あるいは委託された作業自体は実施されたものの、それに関する報酬金額に関する双方の認識の相違によるトラブルも、成果物の内容に関するトラブルと同程度によくある類型です。
③開発が計画通りに進行しなかった（頓挫した）責任の所在に関するトラブル
システム開発案件が計画より遅れたとか、そもそも頓挫して完成しなかった場合の責任の所在に関するトラブルも、①や②の類型と併せて問題になることが多いです。
３．訴訟になった場合に留意するべき前提事項
訴訟の当事者になった場合において、留意するべき訴訟上の前提事項としては主に以下のものがあります。
（１）基本的には請求する側が主張・立証を行う
訴訟において何らかの請求をする場合には、基本的にはその請求をする側が、事実関係の主張とそれを根拠づける証拠の提出を行うことになります。したがって、損害が生じたとして損害賠償請求をする場合においては、実際に生じた損害の項目やその額を請求する側が主張・立証する必要があります。たとえば、人件費を損害として請求する場合には、どんぶり勘定で請求するというわけにはいかず、どれくらいの人数がどれくらいの時間作業に従事していたかを具体的な金額として算出する必要があり、それを根拠づける資料の提出も必要となります。すなわち、請求をしようとする側において、根拠となる証拠も含めた準備が必要になるということになります。
（２）損害賠償請求は実際に生じた損害額が基本となる
損害賠償請求できる項目としては、実際に生じた損害であるのが原則となります。この点については、実際に追加で費用負担することになったとか、余計にかかった人件費などのように現に支出した損害については認められやすいということになります。他方で、このシステムが順調に完成していれば得られたであろう利益のような将来得ることができた利益については、検討されることが多いものではありますが、実際には上記（１）で述べたような根拠づける証拠を準備できるかどうかという問題もあり、容易には認められない印象です。
４．訴訟に備えた準備事項
以上の前提事項を踏まえて、訴訟に備えて検討しておくべき主な準備事項としては以下のものが考えられます。
（１）成果物
成果物の内容に問題があるとしてトラブルになる場合には、当然のことながら成果物自体を保存したり、自ら管理できるようにしておく必要があります。また、通常システム開発案件では、問題があると判断される前後を通じて開発・修正作業などが続けられることが多いため、問題があると判断したのはどの時点の成果物であったのかを特定しておく必要もあります。したがって、成果物については最終的なもののみではなく、バージョンごとの管理をしておくことが望ましいといえます。
（２）仕様
システム開発紛争では（とりわけ請負型の契約の場合には）、仕様書どおりに成果物が完成したか否かが問題とされることが多いといえます。このため、関係当事者において、完成すべきとされた仕様が何なのかについて明確にしておく必要があるということになります。ただ、最初に決められた仕様書のとおりに完成まで一度も変更がないということはまれであると思います。仕様の変更などが行われた場合には、どの時点でどのような仕様変更が行われたかも含めて記録・保管しておくことが重要となります。
（３）やり取りの記録
上記のような仕様変更については、書面でやり取りされることはあまりなく、現在では主にメールやコミュニケーションツールなどによってやり取りされることが多いのではないかと思います。その場合には、あとからやり取りのメッセージ自体の削除や内容変更されないように、別途保管や記録をしておく必要があります。この点、メールは一度受信するとあとからの削除や修正はできないのですが、コミュニケーションツールの場合、あとから削除・変更できるだけでなく、そもそも相手方の管理下にあるツールを使用している場合、トラブル発生後に閲覧しようとしても、アカウントを解除されてしまい、確認することができなくなってしまうという難点もあります。それにより訴訟上重要なやり取りが証拠として利用できなくなってしまうという問題も生じますので、十分な注意が必要です。
（４）重要事項の取決め
仕様変更だけではなく、報酬金額などのような重要事項を決める際に、口頭の約束では、言った言わないの水掛け論になってしまうリスクがあることは想像に難くありません。したがって、少なくとも何らかの記録として残しておく必要があります。この場合、会社であれば代表者同士が書面で締結できれば最も確実ですが、緊急性の高い案件において、都度代表者同士の書面による合意ができるとは限りません（むしろほとんど書面による合意ができないのではないかと思います。）。その場合においても、少なくとも口頭での約束は避けて記録に残すべきであり、記録に残すとしても、上記のとおりコミュニケーションツールの場合には別途保管しておくなどの措置が必要となります。会議の場合においては、議事録に残しておくことも有効です。
（５）担当者の稼働記録
システム開発紛争においては報酬金額でトラブルになることが非常に多く、この場合、訴訟になった場合の前提事項として、上述のとおり請求する側が主張・立証しなければなりません。そこで実際に開発を担当した人員の稼働時間などを証拠として提出する必要があるということになります。
このため、受託者側においては、日常的に担当人員の稼働時間と稼働内容について記録しておくことが望ましいといえます。請負型の場合には稼働時間に関係なく報酬が固定で決められているため、一見するとそのような記録は不要なようにも思えます。しかしながら、請負型の場合においても追加報酬を請求したいケースにおいて当該追加部分についての報酬金額の取決めがない場合には、やはりどれくらいの人員がどれくらい稼働したのかという記録が追加報酬を請求するうえで重要な証拠となる場合があるため、請負型であるからといってそのような記録が全く不要というわけではない点には留意が必要です。
（６）ＩＤ・パスワードなどの情報
これは、訴訟になった場合というよりもトラブルになった場合の留意点ですが、トラブルになった場合、開発環境などを提供するサービスのパスワードなどを知らないと、必要な情報にまったくアクセスできなくなるという事態になりかねません。したがって、可能であれば開発環境のアカウントのＩＤやパスワードなどは自ら把握しておくことが重要です（それでも上記のとおり相手方が管理しているサービスの場合には、そもそもアカウントごと解除されてアクセスできなくなってしまうリスクは残るのですが。）。
５．訴訟に発展しないために気を付けるべきこと～まとめに代えて
訴訟にまで発展しないために気を付けるべきこととしては、やはり上記の準備事項について事前にしっかり取り組むことに尽きるものと思われます。すなわち、仕様についてはあらかじめ明確にしておくこと、当事者間のやり取りを踏まえた合意事項については明確に文書化（記録化）しておくこと、担当者の稼働記録はできる限り詳細に残しておくこと、などが考えられます。それらを明確にし、当事者間で共有することによって当事者双方の認識の齟齬を避けることができ、ひいてはトラブルに発展することを未然に防ぐことができるものと考えます。
紛争に発展した事例をみるに、受託者側の稼働時間が想定より大幅に上回っているにもかかわらず委託者側がその事実を知らなかったとか、委託者側で当然開発の対象となっていると思っていたところ受託者側は開発の対象外であったと思っていたなど、認識の齟齬によって生じてしまっている場合が大変多いと感じます。
システム開発においては、どうしても技術的な課題解決や納期とコストの問題に関心が向きがちですが、訴訟を避けるためにも今回挙げた事項を参考に日頃の運用の見直しを検討していただければと思います。
▼過去シリーズはこちら
『連載:システム開発紛争の基本問題（１） 請負契約と準委任契約の区別の判断要素について（前編）』はこちらから
『連載:システム開発紛争の基本問題（２） 請負契約と準委任契約の区別の判断基準について（後編）』はこちらから
『連載:システム開発紛争の基本問題（３） 仕様の重要性について』はこちらから
『連載:システム開発紛争の基本問題（４） プロジェクトマネジメント義務』はこちらから
『連載:システム開発紛争の基本問題（５） 準委任契約について』はこちらから
『連載:システム開発紛争の基本問題（６） 損害賠償請求について』はこちらから
『連載:システム開発紛争の基本問題（７）段階的契約について』はこちらから『連載:システム開発紛争の基本問題（８）システム開発契約と下請法について』はこちらから
『連載:システム開発紛争の基本問題（９）システム開発における「完成」の意義』はこちらから
『連載:システム開発紛争の基本問題（１０）システム開発契約における契約解除の問題』はこちらから
『連載:システム開発紛争の基本問題（１１）システム開発において契約書が存在しない場合の問題』はこちらから
