IT導入プロジェクトの「失敗の責任」は誰にあるのか｜ベンダーと発注者の責任範囲を整理する
アカンパニー・パートナーズ
「IT導入が失敗した。高いお金を払ったのに動かないんだから、ベンダー（開発会社）が悪いに決まっている」——そう感じるのは無理もありません。しかし、法律的・実務的な現実は非情です。実は「発注者側（ユーザー企業）にも重大な責任がある」と判断され、裁判で全面敗訴する経営者が後を絶ちません。本記事では、IT導入プロジェクトが泥沼化してしまったときの責任の所在を、ベンダー側・発注者側それぞれの実務観点からわかりやすく整理します。
この記事で分かること
IT導入プロジェクトの失敗の責任は、ベンダーと発注者の「双方」にあるケースがほとんどです。
- ベンダーの責任：プロジェクトを適切に導く「プロジェクトマネジメント義務」の違反など
- 発注者の責任：要件定義（何を作りたいか）の丸投げ
合意後の「ついでにこれも」という追加要求など法的なトラブルになった際、経営者を守る最大の武器は「すべての合意を書面（議事録やメール）で残していること」です。
「IT導入の失敗はベンダーのせい」が、法的に通じない理由
【このセクションの結論】
IT導入の失敗をベンダーだけの責任にすることは、法律的には非常に困難です。システム開発には「発注者責任」という概念があり、IT導入は「お金を払えば完成品が届く」お買い物ではなく、発注者とベンダーが力を合わせて進める共同プロジェクトだからです。
「思った通りのシステムができなかったから、ベンダーを訴えればお金を取り戻せるはずだ」という考え方は、実際の法廷では通じないことが多いです。なぜなら、IT導入は「お金を払えば完成品が届く」お買い物ではなく、発注者とベンダーが力を合わせて進める共同プロジェクトだからです。法律でも、発注者側が果たすべき義務が明確に定められています。
そもそもIT導入における「失敗の責任」はどう定義される？
【このセクションの結論】
IT導入の責任は、ベンダーの「プロジェクトを適切に管理・進行する義務」と、発注者の「要件を決め、体制を整える義務」のどちらが、どの程度守られなかったか（過失の割合）によって判断されます。
発注者責任とプロジェクトマネジメント義務とは
【発注者責任とプロジェクトマネジメント義務とは】
発注者責任（ユーザー側の義務）：「何のためにシステムを入れるのか（要件）」を明確にし、ベンダーの質問に答え、成果物をチェックして、決定事項を書類に残す義務です。プロジェクトマネジメント義務（ベンダー側の義務）：専門家としてプロジェクト全体を適切にリードし、スケジュールを管理し、リスクがあれば事前に発注者へ報告・提案する義務です。
両者がそれぞれの義務を果たさなかった場合、失敗の責任は「どちらがより原因を作ったか」によって分け合うことになります。
IPA（情報処理推進機構）「DX動向2025」によると、DXプロジェクトの失敗要因として「推進体制・管理の不備」が上位に挙げられており、その多くが発注初期段階の設計ミスと発注者側の関与不足に起因しています（出典：IPA「DX動向2025」https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html）。
【重要判例】中小企業も他人事ではない「旭川医大 vs NTT東日本事件」
IT導入の歴史における最重要判例が、旭川医科大学とNTT東日本のシステム開発訴訟です。「これ以上の変更はしない」と一度合意（仕様凍結）したにもかかわらず、現場の医師たちから171項目もの追加要求がダラダラと続いた結果、システムが完成せずプロジェクトが頓挫しました。裁判の結果、仕様凍結の約束を破って要求を出し続けた大学（発注者）側が全面敗訴となったのです。
これは大学病院という遠い世界の話ではありません。中小企業の現場でも、「せっかく高いお金を払うんだから、ついでにあの業務の機能も足してよ」「やっぱりこっちの画面に変えて」という「おまけ要求の罠」が日常茶飯事のように起きています。この口頭での後出し要求こそが、のちに会社を不利に追い込む最大の原因になります。
📄 関連記事：追加費用が発生する原因と防ぎ方はこちら
ベンダー（開発会社）の責任が厳しく問われる3つのケース
【このセクションの結論】
ベンダー側の責任が法的に認められるのは、「進捗管理の怠慢」「要件定義の主導放棄」「契約書通りのシステムを作らない」という3パターンです。ただし、これらを追及するためには「証拠（書面）」の存在が前提となります。
①プロジェクトの舵取りを放棄した場合（プロジェクトマネジメント義務違反）
ベンダーには、ITのプロとしてプロジェクトを適切に指導・管理する義務があります。遅れが出ているのに放置したり、問題が起きていることを発注者に隠していたりした場合は、ベンダーの責任が厳しく問われます。
②発注者の要望をうまく引き出さなかった場合（要件定義主導義務の怠慢）
発注者はITの素人です。そのためベンダーには、ユーザーの「やりたいこと」を専門知識でうまく引き出し、設計図（要件定義書）に落とし込む義務があります。「発注者が何も言ってくれなかったから作れませんでした」という言い訳は、プロとして通用しません。
③契約書にある「絶対に必要な機能」を作らなかった場合（契約違反）
契約書や仕様書に「この機能を実装する」と明記されているにもかかわらず、それが動かない、あるいは納期通りに納品されない場合は、明確なベンダー側の契約違反（債務不履行）になります。
注意！「請負契約」と「準委任契約」でベンダーの責任は変わる
IT導入の契約形態によって、ベンダーの責任範囲が大きく変わります。
| 比較項目 | 請負契約（システムを作ってもらう） | 準委任契約（実務をサポートしてもらう） |
|---|---|---|
| ベンダーの義務 | 成果物を完成させて引き渡す義務あり | プロとして誠実に業務を行う義務のみ（完成の保証なし） |
| 完成しなかった場合 | ベンダーの責任が重く、返金請求しやすい | 原則として、働いた時間や業務に対して費用を支払う必要がある |
| 主な適用フェーズ | 設計・プログラミング・実装 | 要件定義の相談・プロジェクト管理の補助 |
| トラブル時のリスク | 発注者側が不備を追及しやすい | ベンダー側の不備（サボりなど）を証明しにくい |
発注者（あなた）の責任が問われてしまう4つのNG行動
【このセクションの結論】
「ITのことはわからないから、ベンダーに全部お任せ」という姿勢そのものが最大のリスクです。発注者には「要望の決定」「体制の提供」「書面管理」の義務があり、これらを放棄するとトラブル時に一切守られなくなります。
【発注者責任とは】
発注者責任とは、IT導入プロジェクトにおいて発注者（ユーザー企業）が果たすべき義務のことです。「何を作るか」を明確にする義務・体制を提供する義務・合意を書面で残す義務が含まれます。これらを怠った場合、失敗の責任を問われます。
NG①「だいたい良い感じで」と、要件の確定を丸投げした
「画面のイメージは、今風の使いやすい感じでよろしく」といった曖昧な発注はNGです。ベンダーが「言われた通りのイメージで作った」と主張した場合、裁判になっても発注者側は「そんなつもりじゃなかった」と言い返せなくなります。
📄 関連記事：要件定義書なしで発注すると何が起きるかはこちら
NG②一度決めた内容なのに、後から「やっぱりこれも」と要求し続けた
前述の判例の通りです。プロジェクトの途中で要望が変わること自体は珍しくありませんが、それを「口頭」で、かつ「追加費用や納期の相談もなし」になし崩し的に要求し続けると、発注者側の義務違反になります。
NG③社内の担当者が忙しくて、打ち合わせや確認をサボった
「ベンダーから確認を求められているのに、現場が忙しくて2週間放置した」「テストをやってくれと言われたが、面倒だからやらなかった」。これらはすべて発注者側の「協力義務違反」とみなされ、納期遅延の責任をベンダーに押し付けられなくなります。
NG④「言った・言わない」の口頭合意だけで進めてしまった
「あのとき、営業のAさんができるって言った！」は、書面（議事録やメール）がない限り、法の場では一切認められません。議事録を作らないということは、自ら防御の盾を捨てているのと同じです。
「開発会社から見て、追加費用を請求しやすいプロジェクトには、明確な共通点があります」
私はシステム開発会社のSEとして11年間、まさに「受注側」の現場で数多くのプロジェクトを見てきました。その立場だったからこそ、経営者のあなたに正直にお伝えします。
開発会社から見て「このお客様なら、トラブルが起きても発注者責任を主張しやすいな（＝追加費用がしっかり取れるな）」と感じるプロジェクトには、以下の3つの特徴が必ずあります。
- 「要件定義書」という明確な書類が存在しない。
- 仕様の変更がいつも口頭ベースで、チャットやメールの履歴がない。
- 発注者の社長や担当者が「よくわからないから任せるよ」と丸投げしている。
この状態だと、開発会社としては「それは当初の範囲に入っていませんので、追加費用になります」というカードが非常に切りやすくなります。これはベンダーが悪質なのではなく、ビジネスの構造上、そうなってしまうのです。中小企業の経営者がベンダーと対等に渡り合い、自社を守る唯一の方法は「どんな小さな約束も、すべて文字（書面）で残すこと」。これに尽きます。
泥沼化を防ぐ！発注者責任を果たすための「7つの実務対策」
【このセクションの結論】
発注者責任をしっかり果たすことは、ベンダーに圧力をかけるためではなく、トラブルが起きたときに「自社を守る最強の防壁」を作る作業そのものです。以下の7つのチェックリストを実践してください。
🛡️ 発注者が自分を守るためのチェックリスト
[ ] 要件定義書（何を、どこまで作るか）を文字にしてベンダーと握り合っているか [ ] スコープ（今回の予算と期間では「やらないこと」）を書類に明記しているか [ ] プロジェクト開始時に、お互いの役割分担を全員で確認（キックオフ）したか [ ] 打ち合わせの議事録は、遅くとも48時間以内に作成・共有しているか [ ] 仕様の変更や追加の依頼は、必ずメールやチャット、変更管理表に記録しているか [ ] 社内の担当者が辞めたり変わったりしたときの、引き継ぎルールがあるか [ ] 検収基準（どういう状態になったら「完成」と認めてお金を払うか）を事前に決めているか
- 要件定義書（何を、どこまで作るか）を文字にしてベンダーと握り合っているか
- スコープ（今回の予算と期間では「やらないこと」）を書類に明記しているか
- プロジェクト開始時に、お互いの役割分担を全員で確認（キックオフ）したか
- 打ち合わせの議事録は、遅くとも48時間以内に作成・共有しているか
- 仕様の変更や追加の依頼は、必ずメールやチャット、変更管理表に記録しているか
- 社内の担当者が辞めたり変わったりしたときの、引き継ぎルールがあるか
- 検収基準（どういう状態になったら「完成」と認めてお金を払うか）を事前に決めているか
1つでも「できていない」項目があれば、今すぐ対策を始めてください。
📄 関連記事：キックオフで合意事項を書面化する方法はこちら
口頭合意のみで進めた場合に失う「4つの権利」
- ⚠️ 「言った・言わない」の水掛け論になった瞬間、書面がない側（発注者）が圧倒的に不利になります
- ⚠️ 仕様変更を口頭で頼んでしまうと、後から提示された追加費用を全額支払う義務が生じるリスクがあります
- ⚠️ 完了の定義を書いていないと、不具合だらけでも「これで完成です」と言い張るベンダーを論破できません
- ⚠️ 議事録がない場合、裁判では「ITのプロであるベンダー側の証言」が信用されやすくなります
📄 関連記事：ベンダーコントロールの外注方法はこちら
もしトラブルが起きてしまったら？返金・損害賠償請求の現実的な進め方
【このセクションの結論】
トラブル発生時は、いきなり弁護士を立てて喧嘩をするのではなく、「契約書と証拠（議事録）の照合」から始めます。まずは書面をもとに、泥臭くとも冷静な「交渉」で解決の糸口を探るのが鉄則です。
1. まずは手元の「証拠」をかき集める
契約書の確認：「完成義務（請負）」なのか、損害賠償の上限額はいくらになっているかを確認します。 メール・議事録の時系列整理：「いつ、誰が、どの不具合について合意したか」をエクセル等にまとめます。 **証拠の保全：**チャットツールの履歴や、ベンダーから提出された提案書を一か所に保存します。
2. ベンダーとの交渉で突きつける「3つの論点」
「契約書にあるこの機能が動いていない」「スケジュール遅延の報告を事前に受けていない」「合意のない追加費用が請求されている」。これらを書面証拠とともに突きつけることで、ベンダー側も真摯に対応せざるを得なくなります。
3. 裁判（損害賠償請求）は本当に現実的か？
裁判で勝てるのは、「契約書にやるべきことが明確に書いてあり」「ベンダーのサボりが書面で証明でき」「回収できる金額が、弁護士費用や裁判にかかる時間コストを上回る」場合だけです。要件定義書も議事録もない状態での裁判は、時間とお金をドブに捨てることになりかねません。
📄 関連記事：システム導入の検収（完了確認）方法はこちら
「裁判で白黒つける前に、書類一枚で取り戻せるお金が、実はたくさんあります」
元・開発側のSEだったからこそ、正直にお伝えします。
IT導入が失敗したとき、悔しさのあまり「もう裁判だ！」と考えたくなる気持ちは理解できます。しかし、裁判は早くても1〜2年、費用も数百万円単位でかかり、経営者の精神的エネルギーを凄まじく消耗させます。
開発側の裏事情を知る人間としてアドバイスするなら、「裁判の前に、書面交渉だけで取り戻せる実利」に目を向けてください。たとえば
- 「まだ着手していない先の工程の費用」
- 「口頭だけで、金額の事前合意がなかった追加作業の費用」
- 「明らかにベンダー側のバグ（瑕疵）である部分の修正費用」
などは、こちらが「〇月〇日の議事録の通り、この作業は未着手ですので、その分の費用は差し引いて精算をお願いします」とメールで理路整然と伝えるだけでも損害を抑えることは可能です。感情的になって喧嘩をする前に、まずは手元の「文字の証拠」を使って、実利を取りに行く交渉をしましょう。
IT導入失敗を防ぐ、「発注者側の右腕」という選択肢
【このセクションの結論】
失敗した後の対処よりも、プロジェクトが始まる前に「発注者責任を果たせる体制」を作ることが最善の防御策です。社内にIT人材がいない中小企業は、中立的な外部の専門家を「自社の味方」としてチームに招き入れることが有効です。
IT導入の失敗を防ぐために最も重要なのは、プロジェクトが始まる前の「要件定義の文書化」と「やらないこと（スコープ）の確定」です。しかし「通常業務で忙しいし、ベンダーのIT用語が理解できないのに、文書化なんて無理だ」と思われるのも当然です。
そこで検討していただきたいのが、ITコーディネーターです。ITコーディネーターとは、経済産業省が推進する民間資格（ITコーディネーター協会が認定）の保有者で、特定のツールやベンダーに依存しない中立的な立場で、経営視点からIT活用を支援する専門家のことです。要件定義書の作成・ベンダーとの打ち合わせへの同席・議事録のチェック・不利な契約条項の確認まで、「発注者側のプロの伴走者」として機能します。
📄 関連記事：ITコーディネーターに頼める仕事10選はこちら
初回ご相談は無料です。
「IT予算の適正額は分かったけれど、うちの今の支出がどれに該当するのか分からない」「ベンダーから来ている見積もりや保守費用が妥当なのか、客観的に見てほしい」「経営者に説明するための、数字の根拠に基づいた資料作りを手伝ってほしい」
アカンパニー・パートナーズは、現状のIT支出の棚卸し・適正額の診断・費目別配分の設計・経営者への説明資料作成まで、貴社の経営と現場にトコトン伴走します。初回ご相談は無料です。
よくある質問（FAQ）
-
IT導入が失敗した場合、ベンダーに費用の返還を請求できますか？
-
請負契約でベンダーの不履行を書面で証明できる場合は可能です。口頭合意のみの場合は困難です。
-
口頭で「やります」と合意した内容は、法的に有効ですか？
-
理論上は有効ですが、「言っていない」と否定された場合に証明できず、実質無効と同じ状態になります。
-
要件定義が曖昧なまま始まったプロジェクトが失敗したら、誰の責任ですか？
-
発注者の要件確定義務違反とベンダーの主導義務違反の双方が問われます。過去の連絡履歴が判断の鍵です。
-
準委任契約と請負契約では、失敗時のリスクはどう違いますか？
-
請負は完成義務ありで発注者が追及しやすく、準委任は完成保証なしでベンダーが費用請求できる場合があります。
-
トラブル時、自分たちを守るために最低限やっておくべきことは？
-
要件定義書・スコープ合意書・議事録・変更履歴の4点を日付順に整理・保管することが最大の自己防衛です。
-
ベンダーに損害賠償を請求する際、何が必要になりますか？
-
契約書・ベンダーの義務違反を示す書面証拠・損害額の立証データが必要です。IT案件に強い弁護士に相談してください。
参考出典：IPA（情報処理推進機構）「DX動向2025」https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html / ITコーディネーター協会（ITCA）公式サイト https://www.itc.or.jp/about/ / 東京スタートアップ法律事務所「システム開発案件で損害賠償責任が発生する主な要因と裁判例」https://tokyo-startup-law.or.jp/magazine/category02/liability-for-damages-in-system-development/
投稿者プロフィール
- 代表
-
プログラマーとしてキャリアをスタートし、製造業の社内SEとして「工場」の論理を、士業事務所の社内SEとして「先生」の論理を肌で学んできました。異なる文化を持つ組織の中でITを推進するには、技術力以上に「聴く力」と「翻訳力」が必要です。
現在はその経験を活かし、新潟の中小企業のDXを支援しています。
ITコーディネーター／上級ウェブ解析士／上級SNSマネージャー
