販売管理システムが稼働したものの、不具合が次々に出て現場が回らない。開発会社に直してほしいと伝えても「仕様どおりに作っています」と返され、残りの代金の支払いを止めたところ、今度は先方から支払いを求める書面が届いた。社内では「もう裁判しかないのでは」という声まで出ている。システム開発の訴訟を検索するのは、こうした場面にいる方が多いと思います。
先に書いておくと、システム開発の紛争で裁判に進むのは、ほとんどの場合、発注側にとっても最後の手段です。時間も費用もかかり、しかも裁判で争われる中身は、契約書と仕様書と、それまでのやり取りの記録でほぼ決まっています。この記事では、裁判で何が争点になるのかを4つの型に分けて整理したうえで、訴訟の前に取れる協議と裁判外紛争解決（ADR）の手順を、経済産業省とIPAが公開しているモデル契約書に沿って解説します。判例の解釈や勝てるかどうかの見通しには踏み込みません。
この記事のポイント
- 争点は作る範囲・完成と検収・納品後の不具合・双方の協力の4つに分かれる
- どの争点も契約書と仕様書と記録に何が書いてあるかで結論が変わる
- モデル契約書は訴訟の前に協議とADRを挟む順番を定めている
- 訴訟か仲裁かは契約の紛争解決条項で先に決まっていることがある
目次
システム開発の訴訟で争点になること
システム開発の紛争は、報道される大型案件だけの話ではありません。数百万円から数千万円規模の業務システムでも、代金の支払いと不具合の修正をめぐって話がこじれることはよくあります。
揉めている最中は「相手が悪い」という感情が先に立ちます。ただ、裁判になったときに問われるのは、感情ではなく、契約で何を約束していたかです。争点になりやすいものを4つの型に分けて見ていきます。
作る範囲がどこまでだったか
最も多いのが、そもそも何を作る約束だったのかという争いです。発注側は「この機能も当然入っていると思っていた」と考え、開発会社は「その機能は要件に入っていない」と考える。この食い違いが、追加費用の請求や、未完成だという主張の根っこになります。
ここで判断の材料になるのは、要件定義書やシステム仕様書に何が書かれているかです。打ち合わせで話した記憶があっても、仕様書に書かれていなければ、約束した範囲に入っていたと示すのは難しくなります。逆に、仕様書に書かれているのに作られていないなら、それは追加ではなく、約束した作業が終わっていないという話になります。
私が現場でよく見るのは、要件定義書に「現行システムと同等」とだけ書かれていて、何が同等なのかを双方が別々に理解していたケースです。範囲の争いは、実は発注前の段階で種がまかれています。
完成したか、検収が済んだか
2つ目は、システムが完成したのか、検収が済んだのかという争いです。請負契約では、完成して引き渡されたかどうかで代金の支払い義務が変わるため、ここは金額に直結します。
IPAのモデル契約書（第二版）では、発注側は決められた検査期間内に検査仕様書に基づいて検査し、合格なら検査合格書を交付し、不合格なら「不合格となった具体的な理由を明示した書面」を交付すると定めています。さらに、検査期間内に書面で具体的な理由を示して異議を述べなければ、検査に合格したものとみなされる、という条項も置かれています。
つまり「不具合があると口頭で伝えていた」だけでは、検収が済んだ扱いになっている可能性があるということです。自社の契約書に同じような条項があるか、検査期間はいつまでだったかを先に確かめてください。納品物とテスト結果のどこを点検すれば検収を判断できるかは、検収・受入テスト確認シートで項目ごとに確認できます。検収の進め方やみなし検収の条項の扱いは、システム開発の検収で確認することで詳しく整理しています。
納品後の不具合をどう扱うか
3つ目は、検収が済んだあとに見つかった不具合の扱いです。モデル契約書では、検収後にシステム仕様書との不一致（バグを含む）が見つかった場合を「契約不適合」と呼び、発注側はまず修正などの追完を請求できるとしています。
そのうえで、開発会社の責めに帰すべき事由による不具合で損害を受けた場合は損害賠償を請求でき、追完を求めても相当期間内に直らず、契約の目的を達することができないときは、契約の全部または一部を解除できるという順番になっています。いきなり代金を返せと言える構造ではなく、まず直してもらうことが出発点です。
もう1つ見落とされやすいのが、責任を追及できる期間です。モデル契約書では、検収完了後の一定期間内に不具合を通知した場合に限って責任を負う、という形で期間を区切る条項になっています。期間の長さは空欄で、個別に決める項目です。不具合に気づいたら、まず書面で通知しておくことが、あとの選択肢を残すことにつながります。
発注側の協力も問われる
4つ目は、プロジェクトがうまくいかなかった原因がどちらにあるのかという争いです。システム開発の紛争では、開発会社がプロジェクトをきちんと管理していたかと同時に、発注側が必要な協力をしていたかも問われます。
モデル契約書は、役割分担の条項の冒頭で、円滑な遂行のためには開発会社の技術と知識の提供と、発注側による「システム仕様書の早期かつ明確な確定」が重要であり、双方の共同作業と分担作業が必要だと書いています。決めるべきことを決めない、資料を出さない、現場の担当者をテストに出さない、といった発注側の遅れは、紛争になったときに自社の側の事情として扱われることがあります。
訴訟を考え始めたら、相手の落ち度を並べる前に、自社側の宿題が期限どおりに出せていたかを棚卸ししておくほうが、見通しを誤りません。遅延が起きたときの記録の残し方や、損害賠償を請求できる範囲については、システム開発の遅延と損害賠償の手順で扱っています。
システム開発の訴訟の前に取れる解決手段
争点が見えてきたら、次はどう解決するかです。システム開発の紛争は、いきなり裁判に持ち込むのではなく、いくつかの段階を踏むのが一般的です。モデル契約書も、その順番を条文で定めています。
訴訟の前に協議の段階を踏む
モデル契約書の「和解による紛争解決」の条項は、紛争が生じたら、仲裁や訴訟といった手続きをとる前に、まず定例の連絡協議会を開いて十分に協議するよう求めています。
そこで解決できなければ、手続きをとろうとする側が、相手方に対して、紛争解決の権限を持つ代表者や役員との協議を申し入れ、決められた日数以内に誠実に協議するとしています。担当者どうしの話し合いで行き詰まったら、決裁権を持つ人どうしの話し合いに上げる、という段階です。
それでも解決できない場合の選択肢として、法務省の認証を受けた紛争解決事業者による手続き（認証紛争解決手続）を通じて和解を目指す条項が、オプションとして用意されています。そこでも和解が成立する見込みがないとなって初めて、仲裁や訴訟に進むという流れです。
現場の感覚としても、担当者レベルでこじれた話が、役員どうしの協議で動き出すことは少なくありません。担当者は自分の判断で譲れないことが多いからです。
裁判の外で解決する仕組みがある
裁判以外で紛争を解決する手続きを、ADR（裁判外紛争解決手続）と呼びます。システム開発の分野では、一般財団法人ソフトウェア情報センター（SOFTIC）が、2008年に法務省の認証を受けてソフトウェア紛争解決センターを設けています。扱う紛争の例として、情報システムの開発における成果物の不具合や、納期遅延などによる費用負担をめぐるトラブルが挙げられています。
このセンターが用意している手続きは4つです。
| 手続き | 中身 | 結果の効力 |
|---|---|---|
| 和解あっせん | 中立の第三者が話し合いを支援し、解決案を示す | 双方が同意すれば和解契約になる |
| 中立評価 | 専門家が技術的・法律的な論点を評価し、解決案を示す | 拘束力はない |
| 単独判定 | 片方の申立てだけで、専門家が申立事項を判定する | 拘束力はない。社内の検討材料になる |
| 仲裁 | 当事者の合意に基づき、仲裁人が判断を下す | 裁判の確定判決と同じ効力。再び裁判所に訴えることはできない |
センターは、手続きが非公開で進むこと、ソフトウェアに詳しい弁護士や技術者を当事者が選べること、裁判より柔軟に技術的な争点を整理できることを利点として挙げています。一方で、和解あっせんや中立評価は、相手方が応じなければその段階で終わります。相手が話し合いに乗ってくる余地があるうちに使う手段だと考えておくとよいでしょう。
訴訟か仲裁かは契約で決まっている
見落とされやすいのが、紛争になったときにどこで決着をつけるかが、契約書ですでに決まっていることがある点です。モデル契約書では、この条項を2つの案から選ぶ形になっています。1つは仲裁で最終的に解決する案、もう1つは訴訟になった場合の第一審の裁判所をあらかじめ決めておく案です。
仲裁を選んでいる場合は注意が必要です。モデル契約書の解説は、当事者が仲裁に合意すると、その対象となる紛争については裁判所での通常の訴訟は行えなくなる、と説明しています。自社の契約書に「仲裁により終局的に解決する」といった文言があれば、訴訟という選択肢はそもそも取れない可能性があります。
逆に、裁判所を決めておく条項の場合は、相手方の本社がある地域の裁判所が指定されていることもあります。遠方の裁判所に通うことになれば、それだけで負担が大きくなります。揉め始めたら、まず契約書の最後のほうにある紛争解決の条項を開いてみてください。契約書全体で確認すべき条項は受託開発の契約で発注者が確認すべきことにまとめています。
弁護士に相談する目安と持っていくもの
次のどれかに当てはまったら、社内で結論を出そうとせず、システム開発の紛争に詳しい弁護士に相談するタイミングです。
- 相手方から支払いや損害賠償を求める書面が届いた
- 自社から支払いを止めている、または契約の解除を考えている
- 役員どうしの協議でも話が進まなくなった
- 不具合を通知できる期間や、請求できる期間の終わりが近づいている
相談のときは、話の経緯を口で説明するより、書類をそろえて持っていくほうが早く進みます。持っていきたいのは、契約書と別紙（重要事項説明書など）、要件定義書とシステム仕様書、見積書と注文書、検査や検収に関する書類、議事録、変更の合意に関するメールや書面です。時系列の一覧を1枚作っておくと、相談の時間を争点の整理に使えます。
ここで整理した内容は、契約書のどこを見るかまでの一般的な話です。実際に請求するか、支払いを止め続けるか、どの手続きを選ぶかは、契約書の文言と個別の事情で結論が変わるので、最終的な判断は必ず弁護士に確認してください。
よくある質問
- Q. 不具合があるので、残りの代金の支払いを止めてもいいですか？
- A. 自己判断で止めるのは危険です。検収が済んだ扱いになっている場合は、支払いを止めると自社が契約に違反している側になり、相手方から支払いを求められる立場になりかねません。支払いを止める前に、検収の状況と契約の条項を確かめ、弁護士に相談してください。
- Q. ADRは大きな案件でないと使えませんか？
- A. 大きな案件だけのための仕組みではありません。モデル契約書の解説では、特に小規模な案件については、話し合いによる合意づくりを支援する調停やあっせんを勧めるADRセンターも多いと紹介されています。裁判にするほどではないが当事者だけでは話がまとまらない、という段階で検討する価値があります。
- Q. 次の発注で揉めないために、契約で何をしておけばいいですか？
- A. 作る範囲を仕様書に具体的に書くこと、検収の期間と不合格の伝え方を決めること、不具合の責任を追及できる期間を空欄にしないこと、紛争解決の条項で協議からADRまでの順番を決めておくことの4つが基本です。どれも揉めてからでは決められないことばかりです。
