システム開発の頓挫は誰の責任？PM義務と協力義務を弁護士が解説

「開発を依頼したシステムがいつまでも完成しない」「途中で開発が中止になり、支払った費用が宙に浮いてしまった」——。自社の基幹システムや業務アプリの開発を外部のベンダーに委託したものの、プロジェクトが頓挫してしまうケースは、中小企業でも決して珍しくありません。金額が大きくなりやすいうえ、責任の所在が分かりにくく、当事者間の主張が真っ向から対立しやすいのがシステム開発紛争の特徴です。

この記事では、システム開発プロジェクトが頓挫した場合に、発注者（ユーザー）とベンダーのどちらが責任を負うのかについて、裁判例が示してきた「プロジェクトマネジメント義務」と「協力義務」という2つの考え方を軸に整理します。あわせて、契約類型による違い、頓挫時の費用精算、そして中小企業が紛争を未然に防ぐための実務のポイントを、横浜の弁護士が解説します。IT・システム開発を発注する立場の事業者にも、受託する立場のIT企業にも役立つ内容です。

システム開発が頓挫する典型的なパターン

システム開発の失敗は、単純に「ベンダーの技術力不足」だけで起こるわけではありません。裁判で争われる事案を見ると、次のような要因が複合的に絡み合っていることが多いといえます。

• 要件・仕様が固まらない：発注段階で必要な機能や業務フローの整理が不十分なまま開発に着手し、後から要望が膨らんでいくパターンです。
• 仕様凍結後の追加要望：いったん仕様を確定した後も、現場から次々と変更・追加の要望が出て、開発が収束しないパターンです。
• スケジュール・費用の見通しの甘さ：当初の見積りが現実的でなく、途中で破綻するパターンです。
• 意思疎通の不全：ベンダーとユーザーの間で認識のズレが放置され、問題が表面化したときには手遅れになっているパターンです。

こうした事情が重なってプロジェクトが中止に至ると、ユーザーは「支払った費用を返してほしい」「損害を賠償してほしい」と考え、ベンダーは「未払いの報酬を支払ってほしい」「頓挫の原因はユーザー側にある」と主張することになり、紛争へと発展します。責任を判断するうえで鍵になるのが、次に説明する2つの義務です。

ベンダーが負う「プロジェクトマネジメント義務」とは

システム開発の専門家であるベンダーは、単にユーザーの指示どおりに作業をすればよいというわけではありません。裁判例では、ベンダーは開発の進行を管理し、問題があれば適切に対応・提言すべき義務、いわゆる「プロジェクトマネジメント義務（PM義務）」を負うと解されています。この義務は、契約に明記されていなくても、専門家としての付随的な義務として認められると考えられています。

この考え方を示した代表的な裁判例が、いわゆるスルガ銀行対日本IBM事件です。銀行の勘定系システムの開発が頓挫し、多額の損害賠償が争われた事案で、控訴審である東京高裁は、平成25年9月26日の判決において、ベンダーである日本IBMのプロジェクトマネジメント義務違反を認め、約42億円の損害賠償を命じました（この判決は、最高裁が平成27年7月8日に双方の上告を退けたことにより確定しています）。

この裁判例では、ベンダーは開発の各局面において、ユーザーにとってのメリットやリスクを踏まえ、開発状況の分析や、開発計画の変更・中止の要否とその影響について、適時適切に説明・提言すべき義務を負うという趣旨が示されました。つまり、ベンダーが「このまま進めても完成は難しい」と分かる状況であれば、その事実を説明し、ユーザーが適切な判断（計画の見直しや中止）を下せるよう促すことが求められる、という考え方です。ベンダー側の事業者にとっては、開発を漫然と続けること自体がリスクになり得る点に注意が必要です。

ユーザー（発注者）が負う「協力義務」とは

もっとも、システム開発はベンダーだけで完成できるものではありません。どのような業務にどう使うのか、既存の運用はどうなっているのか——こうした情報はユーザーしか持っておらず、ユーザーが必要な説明・意思決定・資料提供を行わなければプロジェクトは前に進みません。そこで裁判例では、ユーザーもまた開発に協力する義務（協力義務）を負うと解されています。

ユーザーの協力義務違反が正面から問われた裁判例として、旭川医科大学対NTT東日本事件があります。電子カルテを中核とする病院情報管理システムの開発をめぐる事案で、札幌高裁は平成29年8月31日の判決において、仕様の凍結後も現場から大量の追加要望が繰り返し出されたことなどを踏まえ、ユーザーである大学側の協力義務違反を認め、大学に対しベンダーへの約14億9744万円の支払いを命じました。

この裁判例は、「発注者だから守られる」「代金を払う側だから強い」とは限らないことを示しています。開発範囲を確定して以降は追加要望を出さないという合意があるにもかかわらず、大量の追加要望を出してベンダーの対応を強い、開発を妨げるような行為は、協力義務に反すると評価される可能性があります。発注者側の中小企業も、要望の出し方や意思決定のスピードによっては責任を問われ得る、という視点を持っておくことが大切です。

請負契約か準委任契約かで責任はどう変わるか

システム開発の責任を考えるうえでは、契約の類型も重要です。実務では、主に「請負契約」と「準委任契約」が用いられます。それぞれの性質の違いを整理すると、次のとおりです。

大まかにいえば、要件定義や設計といった上流工程は準委任契約、仕様が固まった後の開発工程は請負契約、というように工程ごとに契約を分ける「多段階契約」の考え方が実務で広く用いられています。請負契約であれば、ベンダーは「完成」を約束していますので、完成できなかった場合の責任は重くなりやすい一方、準委任契約では、成果の完成自体が義務ではないため、責任の枠組みが変わってきます。どちらの契約類型かによって、頓挫時に「報酬を請求できるか」「費用の返還を求められるか」の結論が左右されるため、契約書上の位置づけの確認が欠かせません。

請負契約と準委任契約の使い分けや、それぞれのリスクについては、別の記事「準委任契約と請負契約の使い分け方｜IT・コンサル系事業者が知るべきリスクと注意点」でも詳しく解説していますので、あわせてご覧ください。

頓挫した場合の費用・損害はどう精算されるか

プロジェクトが途中で中止になった場合、既に支払った費用や、逆に未払いの報酬をどう扱うかが問題となります。結論は事案によって大きく異なりますが、判断の視点としては次のような要素が挙げられます。

• 頓挫の原因が主にどちらにあるか：ベンダーのPM義務違反が主因なら損害賠償や既払金返還が、ユーザーの協力義務違反が主因ならユーザー側の支払責任が問題になり得ます。
• 完成した部分（出来高）の有無：一部でも仕事が完成し、その部分がユーザーにとって利益になる場合には、その割合に応じた報酬が認められることがあります。
• 双方に落ち度がある場合の調整：一方だけが悪いとは言い切れない事案では、過失相殺の考え方により、損害額が調整されることがあります。

先に紹介した2つの裁判例が示すように、多額の金銭が動く結果になることも少なくありません。頓挫が現実味を帯びてきた段階では、感情的な応酬に入る前に、契約書・議事録・メール等の記録を整理し、早めに弁護士へ相談して見通しを立てることが、損失を抑えるうえで有効と考えられます。

中小企業が紛争を未然に防ぐための実務ポイント

システム開発紛争は、いったん表面化すると解決に長い時間と費用がかかります。発注する側・受託する側のいずれの立場でも、次のような備えが有効と考えられます。

• 開発対象・仕様の範囲を書面で明確にする：「どこまでを作るのか」を要件定義書等で具体化し、契約書に紐づけておきます。
• 変更管理（仕様変更）のルールを定める：追加・変更の要望が出た場合の手続、費用・スケジュールへの反映方法をあらかじめ決めておきます。
• 検収の基準・方法を明確にする：何をもって「完成」とするのかを客観的な基準で定め、検収プロセスに双方が協力する旨を確認しておきます。
• 中止時の費用精算を定めておく：やむを得ず中止する場合の出来高の扱いや清算方法を契約段階で合意しておきます。
• やり取りを記録に残す：議事録やメールで合意内容・課題・判断の経緯を残しておくことは、後の紛争で重要な証拠になります。

特に、法務担当者を置いていない中小企業では、ベンダー側が用意した契約書をそのまま締結してしまい、自社に不利な条件に気づかないまま開発が進んでしまうことがあります。契約書の内容を締結前に弁護士がチェックすることで、こうしたリスクを事前に減らすことが期待できます。外注時の著作権の帰属や仕様変更条項の書き方については、「アプリ・システム開発を外注するときの契約書の落とし穴」もご参照ください。契約書レビューの効果については「契約書のレビューを弁護士に頼むと何が変わる？費用対効果と実務上のポイント」で解説しています。

よくある質問（FAQ）

Q1. システム開発が失敗したら、支払った費用は返してもらえますか？

頓挫の原因や契約類型によって結論は変わります。ベンダー側にプロジェクトマネジメント義務違反などの債務不履行が認められれば、既払金の返還や損害賠償が認められる可能性があります。一方で、完成した部分（出来高）がある場合や、ユーザー側の協力義務違反が原因とされる場合には、返還が認められなかったり、逆にユーザーが支払義務を負ったりすることもあります。

Q2. プロジェクトマネジメント義務とは何ですか？

システム開発の専門家であるベンダーが、開発の各局面で進捗や課題を管理・分析し、必要に応じて開発計画の変更や中止をユーザーに説明・提言すべき義務をいいます。スルガ銀行対日本IBM事件の裁判例で示された考え方で、ベンダーが負う付随的な義務と解されています。

Q3. ユーザー（発注者）にも義務があるのですか？

はい。システム開発はユーザーの業務内容の説明や意思決定、資料提供がなければ進められないため、ユーザーは開発に協力する義務（協力義務）を負うと解されています。仕様凍結後に大量の追加要望を出し続けるなど、協力義務に反した場合には、ユーザー側が損害賠償責任を負う可能性があります。

Q4. トラブルを防ぐために契約書で工夫できることはありますか？

開発対象・仕様の範囲、契約類型（請負か準委任か）、検収の基準と方法、仕様変更（変更管理）の手続、中止時の費用精算方法などを明確に定めておくことが有効と考えられます。工程ごとに個別契約を結ぶ多段階契約にする方法もあります。個別の案件に応じた設計が重要ですので、弁護士への相談を検討されることをおすすめします。

まとめ

システム開発の頓挫は「どちらか一方が全面的に悪い」と単純に決められるものではなく、ベンダーのプロジェクトマネジメント義務と、ユーザーの協力義務という双方の役割を踏まえて責任が判断されます。スルガ銀行対日本IBM事件のようにベンダーの責任が認められた例もあれば、旭川医科大学対NTT東日本事件のようにユーザーの責任が認められた例もあり、事案ごとに結論は大きく変わります。

だからこそ、発注する側・受託する側のいずれにとっても、契約段階で仕様・契約類型・検収・変更管理・中止時の精算を明確にし、やり取りを記録に残しておくことが、紛争予防の要になります。すでにトラブルが起きてしまった場合でも、証拠を整理して早めに専門家に相談することで、有利な解決につながる可能性があります。IT・システム開発の契約や紛争でお悩みの際は、横浜のタングラム法律事務所にご相談ください。

※本記事は一般的な法律情報の提供を目的としており、個別の法律相談ではありません。具体的な案件については弁護士にご相談ください。