「要件定義が大事」「曖昧なまま進めると失敗する」という話は、システム開発を発注する立場であれば一度は耳にしているはずです。それでも、いざ自分が社内責任者として契約や要件定義の場に立つと、本当に不安なのは別のところにあるのではないでしょうか。「もし開発が頓挫したり、揉めたりしたら、会社として誰がどう責任を取るのか」「自分は訴えられる側になるのか、それとも泣き寝入りする側になるのか」――この問いに、明確に答えられる方は多くありません。
落とし穴のパターンや予防策を解説する記事は数多くあります。しかし、それらを読んでも「揉めた後に実際どうなるか」までは想像がつかず、議事録や契約書を何のために残すのかが腹落ちしないまま進めてしまう、というのが実情ではないでしょうか。法務専任のいない組織であればなおさら、契約書のどの条項を見ればいいのか、何を記録に残せば自社を守れるのか、判断の拠りどころがありません。
その判断基準を与えてくれるのが、実際に訴訟まで発展した「判例」です。要件定義をめぐる紛争は、これまで何件も裁判所で争われ、ベンダーが数十億円の賠償を命じられた事例もあれば、逆に発注者側が全責任を負わされた事例もあります。判決は、責任が発注者とベンダーのどちらに振れるのか、その境界線がどこにあるのかを、具体的な事実関係とともに示しています。
本記事では、要件定義の失敗が訴訟・損害賠償に発展した3つの判例を発注者の目線で平易に解説し、責任が分かれる境界線と、揉めない・泣き寝入りしないために自社を守る要件定義の進め方を紹介します。なお、要件定義で起きがちな失敗パターンと予防のチェックそのものについては要件定義の落とし穴で詳しく扱っているため、本記事は「実例と責任分担」に絞って深掘りします。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
要件定義の失敗は、なぜ「訴訟」にまで発展するのか
要件定義は、開発工程の最初に「何を作るか」を発注者とベンダーが合意するフェーズです。一見すると地味な打ち合わせの積み重ねに見えますが、ここで合意した内容が、その後のすべての工程の前提になります。失敗が深刻な紛争につながるのは、要件定義の曖昧さが「お金の話」と「責任の話」に直結するからです。
要件定義の合意が「検収・支払い・責任」の起点になる仕組み
システム開発の契約では、ベンダーが納品したものが「合意した内容を満たしているか」を発注者が確認し（検収）、問題なければ支払いをする、という流れが基本です。このとき「合意した内容」の中身が、要件定義書に書かれていることそのものになります。
つまり、要件定義書が曖昧であれば、検収の基準も曖昧になります。「思っていた機能が入っていない」「これは追加費用が必要だ」といった食い違いは、ほぼすべてこの段階の合意の不明確さから生まれます。納品物が要件を満たしていない場合に発注者が主張できる「契約不適合責任」（旧来の瑕疵担保責任にあたるもの）も、「何が契約内容だったのか」が確定していなければ問えません。要件定義の合意は、支払いを止めたり追加費用を拒んだり、逆に修正を求めたりする際の、すべての起点になるのです。
訴訟は「能力不足」ではなく「合意と記録の不在」から起きる
システム開発の紛争というと「ベンダーの技術力が足りなかった」「無理な案件だった」という能力の問題を想像しがちです。しかし実際に裁判で争点になるのは、技術の優劣ではなく「何を、いつ、誰が合意したのか」「その合意はどう変わったのか」という、合意と記録の有無です。
Webシステムや業務システムには「言われなくても当然必要だろう」と双方が暗黙に思い込む領域が必ず存在します。発注者は「業務上当たり前だから書かなくても作ってくれる」と考え、ベンダーは「書いていないなら範囲外だ」と考える。この認識のズレが文書で埋められないまま進むと、後から「言った・言わない」の水掛け論になり、最終的に裁判所が議事録やメールなどの記録をもとに事実を認定することになります。後ほど紹介する判例でも、勝敗を分けたのは技術ではなく、合意と記録のあり方でした。
要件定義の失敗事例｜訴訟になった3つの判例から学ぶ
ここからは、要件定義をめぐって実際に訴訟に発展した3つの判例を見ていきます。法律論ではなく「何が起きて、裁判所はどう判断し、発注者として何を学べるか」という観点で整理します。注目してほしいのは、3つの事例で責任の振れ方がまったく異なる点です。
ベンダー側が責任を問われた事例（スルガ銀行 vs 日本IBM）
スルガ銀行が日本IBMに勘定系システムの構築を委託したものの、プロジェクトが頓挫し、訴額が合計200億円を超える大型紛争に発展した事件です。第一審（東京地裁・2012年）は、スルガ銀行が支払った金額のほぼ全額にあたる約74億円の支払いをIBMに命じました。その後、控訴審（東京高裁・2013年）で賠償額は約42億円に減額され、最高裁がこれを確定させています（IBMに74億円の賠償命令、スルガ銀裁判の深層・日本経済新聞）。
この裁判で発注者にとって重要なのは、ベンダーが負う「プロジェクトマネジメント義務」という考え方が認められた点です。スルガ銀行側は「ベンダーであるIBMがプロジェクトを適切に管理する義務を怠った」と主張し、IBM側は「システム開発はベンダーとユーザーの共同作業であり、ユーザーの協力義務違反が原因だ」と反論しました。裁判所は、専門家であるベンダーには、プロジェクトの状況を正確に説明し、必要なら中止を含めた方針転換を発注者に進言する義務があると判断しました（スルガ銀行・日本IBMシステム開発紛争から学ぶプロジェクト・マネジメント義務・SUPER CEO）。
発注者の立場から見れば、「専門家であるベンダーに丸投げしておけば安心」ではないものの、「ベンダーには専門家として果たすべき責任がある」という後ろ盾になる事例です。技術的な判断や進捗管理はベンダーに求めてよく、それを怠ったまま進められた結果の失敗は、ベンダーの責任を問える余地がある、ということを示しています。
発注者側が全責任を負った事例（旭川医科大学 vs NTT東日本）
一方で、発注者が失敗の責任をほぼ全面的に負わされた事例もあります。旭川医科大学が病院情報管理システムの構築をNTT東日本に委託したものの、開発が遅延し納期に間に合わなかった事件です。札幌高裁（2017年）は、責任割合をユーザー10対ベンダー0と判断し、旭川医科大学に約14億円の支払いを命じました。第一審ではベンダー側に8割の責任があるとされていたものが、控訴審で完全に逆転した点でも注目されました（旭川医大にのみ約14億円の賠償責任・デイライト法律事務所）。
逆転の決め手になったのは、発注者側の「追加要望」と「協力義務」でした。発注者である大学側は、仕様確定後も1,000件近い追加要望を出し、ベンダーが625件を受け入れていったん仕様を凍結したにもかかわらず、その後さらに171件の追加要望を出していました。裁判所は、こうした仕様凍結後の大量の追加要望が発注者の協力義務違反にあたると判断したのです（システム開発において仕様確定後の大量の追加要望等がユーザの協力義務違反に当たるとした札幌高裁判決・イノベンティア）。
この事例は、「発注者だから守られる」という思い込みが通用しないことを示しています。要望を出し続けること自体が悪いのではなく、いったん合意して凍結した仕様を、節度なく次々と覆していく姿勢が「協力義務違反」と評価されました。発注者が積極的に関与することは必要ですが、その関与の仕方を誤ると、むしろ自分が全責任を負う側に回ってしまうのです。
要件定義書に書かれていない機能の責任（航空券販売システムの事例）
3つ目は、「要件定義書に書かれていない機能」をめぐる紛争です。旅行商品の販売システム開発で、遠隔操作機能が契約内容（要件）に明記されていなかったにもかかわらず、裁判所はその機能が旅行商品販売業務を行ううえで不可欠であると判断しました。結果として、ベンダーの代金請求は棄却され、逆にユーザー側の損害賠償請求（約2,570万円）が認められています（情報システム開発トラブル事例と対応法・財務省財務総合政策研究所資料）。
ここで示されたのが「黙示の合意」という考え方です。要件定義書に書いていないからといって、必ずしも契約の範囲外になるとは限りません。一般の常識に照らして誰もが必要と考える機能、業界の慣例として当然備わっているべき機能、旧システムに存在していた機能などは、明記されていなくても「作るべき機能」と判断される場合があります。「ユーザーの期待」とそれに対する「ベンダーの認容」がそろえば、文書化されていなくても合意が成立していたとみなされうるのです。
ただし、これを発注者に都合よく捉えるのは危険です。「書いていなくても当然作ってくれるはず」という期待が、いつも黙示の合意として認められるわけではありません。何が「当然」かの線引きは争いになりやすく、裁判で立証する負担も発注者側に生じます。要件定義書の精度がそのまま責任ラインになる、という教訓として受け止めるべきです。
判例が示す「発注者とベンダーの責任分担」の境界線
3つの事例を並べると、責任の振れ方を決めている共通の因子が見えてきます。ベンダー側が大敗した事例も、発注者側が全責任を負った事例もあり、責任は決して一方に固定されません。境界線を決めているのは、発注者の「協力義務」とベンダーの「プロジェクトマネジメント義務・説明義務」という2つの軸です。
発注者の「協力義務」とは何か
システム開発は、ベンダーだけで完結できる作業ではありません。業務の中身を最もよく知っているのは発注者であり、ベンダーはその情報をもとに設計します。そのため発注者には、開発が円滑に進むよう協力する義務があると考えられています。具体的には、次のような行動が協力義務の中身です。
- 自社の業務内容・業務フローを正確にベンダーに伝える
- 仕様や機能について、求められた意思決定を遅滞なく行う
- いったん合意して凍結した仕様を、安易に覆さない
- 要望の優先順位を整理し、際限なく追加を続けない
旭川医科大学の事例が示すように、この協力義務を怠ったり、節度のない追加要望でプロジェクトを混乱させたりすると、発注者であっても失敗の責任を問われます。
ベンダーの「プロジェクトマネジメント義務・説明義務」とは何か
一方、ベンダーは開発の専門家として、プロジェクトを適切に管理し、リスクや状況を発注者に正確に説明する義務を負います。発注者が無理な要望を出している場合には、専門家の立場からそれを諫めたり、計画の見直しを進言したりすることも、この義務に含まれます。
スルガ銀行の事例で示されたのは、ベンダーが状況を正確に説明せず、必要な方針転換を発注者に促さなかった点が責任につながる、ということでした。発注者の立場からは、「技術的な判断や進捗の管理、リスクの説明はベンダーに求めてよい」という根拠になります。
責任ライン自己診断｜自社は今どちら側か
ここまでの2つの軸をもとに、自社が今どちら側にいるのかを点検してみてください。以下のチェック項目に当てはまるものが多いほど、責任を問われるリスクが高まります。
- 業務の中身をベンダーに「察してもらう」前提で、自社からの説明を省いていないか
- 仕様を合意した後も、思いつくたびに追加要望を出していないか
- 要望に優先順位をつけず、すべてを「必須」として扱っていないか
- 逆に、ベンダーに任せきりで、進捗やリスクの説明を求めていないか
- 打ち合わせの合意内容を、後から確認できる形で記録に残しているか
「丸投げ」も「過剰要求」も、どちらも責任を問われる側に振れる要因です。発注者が見落としがちなこの両面を意識することが、自社を守る第一歩になります。
訴訟リスクを回避する｜要件定義で「記録」と「契約」をどう残すか
判例から学んだ教訓を、専門知識がなくても実行できる具体行動に落とし込みます。揉めないため、そして万一揉めたときに泣き寝入りしないために、要件定義の段階で残すべきものは「記録」と「契約」の2つです。
「議事録が決め手になる」合意の見える化
スルガ銀行の裁判では、議事録が事実認定の決め手になったと指摘されています。裁判所は、当事者の記憶ではなく、その場で残された記録をもとに「何が合意されたのか」を判断するからです。逆に言えば、記録さえ残っていれば、後から「言った・言わない」で不利になることを防げます。具体的には、次のような記録を習慣にしてください。
- 打ち合わせごとに議事録を作成し、決定事項・保留事項・宿題を明記する
- 議事録はベンダーと相互に確認し、双方が内容に同意したことを残す（メール返信でも可）
- 仕様の変更・追加要望が出たら、いつ・誰が・何を依頼したかを記録する
- 仕様を凍結したタイミングと、その後の追加要望は別管理にする
特に「変更管理」は重要です。旭川医科大学の事例が示すとおり、仕様凍結後の追加要望は発注者の責任になりやすいため、追加要望を出す際は「これは凍結後の追加であり、納期・費用に影響しうる」とお互いに認識した記録を残しておくことが、双方の防衛になります。
契約で確認すべき要件定義まわりの条項
要件定義のトラブルは、契約書の作り方でかなり予防できます。法務専任がいなくても、最低限ここだけは確認しておきたい、という条項を挙げます。
- 契約形態（請負か準委任か）: 完成責任をベンダーが負う「請負」か、業務遂行を約束する「準委任」かで、責任の重さが大きく変わります。どちらの契約なのかを必ず確認します
- 契約不適合責任の範囲と期間: 納品物が合意内容を満たさない場合に、いつまで・どこまで修正や賠償を求められるかを定めた条項です。期間や対象範囲を確認します
- 追加要望・仕様変更時の費用負担: 仕様変更が発生したときに、誰がどう費用を負担し、どんな手続きで合意するかを定めておくと、後の紛争を防げます
契約不適合責任の中身については契約不適合責任で詳しく解説しているため、条項を確認する前に目を通しておくと理解が深まります。
発注者が要件定義の前にやっておく業務・要望の棚卸し
最後に、要件定義の打ち合わせに臨む前の準備です。要件定義の失敗の多くは、発注者が「自社が何を求めているか」を整理しきれていないことに起因します。打ち合わせの場でその場しのぎの要望を重ねると、後の追加要望の連鎖につながります。
- 現行業務のフローを書き出し、システム化したい範囲を明確にする
- 「必須」「あれば望ましい」「将来的に検討」と要望に優先順位をつける
- 業務上当然必要だと考える機能ほど、明文化して要件定義書に載せる
- 社内の関係部署から要望を事前に集約し、後出しを減らす
「業務上当たり前だから書かなくても伝わる」という思い込みこそが、航空券販売システムの事例で見たような紛争の火種になります。当然と思う機能ほど、あえて言葉にして残しておくことが、自社を守ることにつながります。
よくある質問（要件定義の失敗事例・責任に関するQ&A）
システム開発における要件定義の失敗事例にはどんなものがありますか？
代表的なものとして、本記事で取り上げた3つの判例があります。ベンダーのプロジェクトマネジメント義務違反が問われたスルガ銀行と日本IBMの事例、仕様凍結後の大量の追加要望が発注者の協力義務違反とされた旭川医科大学とNTT東日本の事例、要件定義書に書かれていない機能の責任が争われた航空券販売システムの事例です。いずれも、技術力ではなく「合意と記録のあり方」が勝敗を分けています。
要件定義の失敗の責任は発注者とベンダーのどちらにありますか？
ケースによって、どちらにも振れます。判断軸は、発注者の「協力義務」とベンダーの「プロジェクトマネジメント義務・説明義務」です。発注者が業務情報の提供や意思決定を怠ったり、節度なく追加要望を出したりすれば発注者の責任が重くなり、ベンダーが状況説明や方針転換の進言を怠ればベンダーの責任が重くなります。「発注者だから守られる」「ベンダーに任せたから安心」のどちらも成り立ちません。
要件定義書に書いていない機能は、ベンダーが対応すべきですか？
必ずしも対応義務があるとは限りませんが、一般常識や業界慣例に照らして当然必要な機能、旧システムにあった機能などは、「黙示の合意」として作るべき機能と判断される場合があります。ただし、何が「当然」かの線引きは争いになりやすく、立証の負担も生じます。当然必要だと考える機能ほど、要件定義書に明記しておくことが安全です。
仕様凍結後に追加要望を出すと、発注者が不利になりますか？
不利になる可能性があります。旭川医科大学の事例では、仕様凍結後の大量の追加要望が発注者の協力義務違反と判断されました。追加要望を出すこと自体が禁じられるわけではありませんが、いったん合意した仕様を節度なく覆すのは避けるべきです。追加が必要な場合は、納期・費用への影響を双方で確認し、合意した記録を残したうえで進めてください。
トラブルを防ぐために、要件定義の段階で何を記録しておけばよいですか？
打ち合わせごとの議事録（決定事項・保留事項・宿題を明記）、仕様変更や追加要望の依頼内容と日付、仕様凍結のタイミングとその後の追加の区別を記録しておきます。議事録はベンダーと相互に確認し、双方が内容に同意したことをメール等で残すと、後の「言った・言わない」を防げます。記録は、揉めたときに自社を守る最大の武器になります。
まとめ｜要件定義の失敗事例が教える「自社を守る」進め方
要件定義の失敗が訴訟に発展した判例を振り返ると、漠然とした不安を具体的な点検に変えるための要点が見えてきます。
- 訴訟は能力不足ではなく、合意と記録の不在から起きる: 裁判所は技術の優劣ではなく「何を、いつ、誰が合意したか」を見ます
- 責任は発注者・ベンダー双方に振れる: 丸投げでも過剰要求でも責任を問われます。発注者の協力義務とベンダーのプロジェクトマネジメント義務という2つの軸で自社の立ち位置を点検しましょう
- 記録と契約で先回りできる: 議事録による合意の見える化、変更管理、契約形態と契約不適合責任・費用負担の条項確認が、揉めない・泣き寝入りしないための備えになります
「もし揉めたら」と祈るだけの状態から、「何を記録し、どの条項を確認すべきか」を点検できる状態へ。それが、実際の判例が発注者に教えてくれる最大の学びです。要件定義で起きがちな失敗パターンと予防のチェックは要件定義の落とし穴で、プロジェクトが頓挫する構造的な要因はシステム開発が失敗する原因で、それぞれ補完的に解説しています。あわせて確認することで、要件定義のフェーズを安心して進める準備が整います。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
