アジャイル開発における受注者の裁判リスクと実務上の備え１

2025.09.15UP!

ブログ

1.初めに：日本におけるアジャイル開発の法的状況

アジャイルソフトウェア開発は、その柔軟性と変化への適応力から、日本においても広く採用されるようになってきました。
従来のウォーターフォールモデル（９０％程度は請負）とは異なり、アジャイル開発（１０％程度であり準委任が一般的）は反復的かつ段階的なアプローチを取り、開発の初期段階で詳細な仕様を固定しない点が特徴です。この特性は、ベンダー（受注者）にとって、迅速な開発と顧客ニーズへの柔軟な対応を可能にする一方で、法的観点からは新たな課題とリスクをもたらします。
本調査ノートでは、2025年4月6日時点における日本国内のアジャイル開発プロジェクトにおいて、受注者が直面する可能性のある裁判リスクを詳細に分析し、これらのリスクを軽減するための実務上の備えについて考察します。

（１）ソフトウェア開発特有の難しさ

ソフトウェアは裁判官そしてユーザーにとってなじみがなく、基本的に情報非対称性が発生します。その結果、折角ベンダー優位の契約をしても、裁判官は情報の非対称性などをベースにユーザ側に立ち、ベンダーに厳しい判断を行うことがあります。
一般的な工事とソフトウェア開発とを同視し、ベンダーはなんらのユーザーからのコミュニケーションなしに組み立てられると勘違いする裁判官もいます。しかし、工事についてはアジャイルは基本的になく、ソフトウェア開発特有と言っても良いものです。最近はアジャイルということが一般に広がりアジャイルガバナンスなどと言われますが、実際にわかって使っているケースは稀です。
ソフトウェア開発は基本的に工事と異なり、基準が標準化しているわけではなく、カスタマイズされています。その結果、要件定義を決めた場合、不可逆性を持ち、変更をする場合は大きな手戻りを起こします。よって、ユーザーは最初から神経をとがらせて決めるべきところ、ユーザーサイドは具体的なイメージが無いと判断できないとして後で決めようとすることが多くあります。これはウォーターフォールでは手戻りが発生するために基本的にご法度です。なお、アジャイルの場合、それはないと安易に考えるケースもありますが、実際には手戻りをすることもあり、それを避けるために、最小限の開発で手戻りを避けてしまう仕組みでもあります。
基本的にウォーターフォールでは要件定義が決まって、徐々に詳細設計・開発・テストなどの流れがありますが、アジャイルにおいては何度も小さく開発を繰り返すのが通常です。しかし、ウォーターフォールではしにくいことをするという非ウォーターフォールとしてアジャイルを考えるケースもあり、本件ではウォーターフォールにあてはまらないものをアジャイルとして言及することとします。
アジャイルについては、見積もり段階では見積もりが難しいケースが多いです。ストーリーポイントを雑に見積もって決めることが多いですが、それは徐々に開発の対象が分かってくることもあり、そもそも精密に見積もることができないという特性があるからです。
そして、ユーザーもあまり判断資料を渡さないことも多くあり、キックスタートになってから資料が多く出てくるケースは頻繁にあります。
よって、そもそもアジャイル開発は、紛争の宝庫であり、結果的にベンダーと優しくかつ几帳面なユーザー以外は、紛争が発生する仕組みです（これを基本的に相性の良いチームといいます）。
基本的に短期で仕上げるケースもあり、それを何度も契約を締結して延長するケースが多くあります。これは双方に相性を確かめ合い、排除すべきベンダーかをユーザーが確認しテイク必要があるからです。このため、ベンダーも、何をやったか、何をやるのかを記録化し、引継ぎとともに、報酬を定期的に貰っておく必要があります。同様に、顧客は製品を完成したいという希望があり、アジャイルにおいてもなんらかのものは期待しており、ベンダー自身もそれを理解し、説明とプロジェクトマネジメントをし、期待値を捜査していく必要があります。それは情報の非対称性から発生するところでもあります。
以上の特性があり、ウォーターフォール開発は請負、アジャイル開発は準委任とされるものの、アジャイル開発においても重たい善管注意義務が課されており、アジャイル＝免責という関係ではないことを理解しておく必要があります。

（２）法的責任

ソフトウェア開発プロジェクトにおける契約類型は、プロジェクトの進め方や成果物の性質によって異なり、法的責任の所在に大きな影響を与えます。アジャイル開発とウォーターフォール開発は、その進め方の違いから、適用される可能性の高い契約類型も異なります。

①請負

請負契約は、当事者の一方（請負人）がある仕事を完成することを約し、相手方（注文者）がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生じる契約です。この契約類型の核心は、「ある仕事の完成」という明確な成果物の納品義務が請負人に課せられる点にあります。請負人は、契約で定められた期日までに、契約内容に適合した成果物を注文者に引き渡す義務を負い、引き渡された成果物に瑕疵があった場合には、契約不適合責任（旧法における瑕疵担保責任）を負うことになります。
この請負契約は、ウォーターフォール開発モデルとの親和性が高いと考えられます。ウォーターフォール開発は、要件定義、設計、開発、テストといった工程を順次進めていく手法であり、プロジェクト開始前に詳細な仕様が確定され、最終的にその仕様に基づいた完成品を納品することが目標となります 7。したがって、ウォーターフォール開発におけるベンダーの義務は、まさに請負契約が定める「仕事の完成」と合致しやすく、法的紛争が生じた場合も、契約書に記載された仕様と納品物の適合性が主な争点となることが多いと考えられます。

②準委任

準委任契約は、委任契約と同様に、当事者の一方（委任者）が法律行為でない事務の処理を相手方（受任者）に委託し、相手方がこれを承諾することによって、その効力を生じる契約です。準委任契約において受任者が負う主な義務は、委任された事務を善良な管理者の注意をもって処理すること（善管注意義務）であり、特定の成果物の完成を保証するものではありません。
アジャイル開発は、その開発プロセスが反復的であり、開発中に要件や仕様が柔軟に変更されることを前提としているため、一般的に準委任契約に近い法的性質を持つと考えられています。情報処理推進機構（IPA）も、アジャイル開発の外部委託においては、請負契約ではなく準委任契約を用いるのがより適切であるとの見解を示しています。これは、アジャイル開発の特性である、開発途中の機能追加・変更や優先順位の変更への柔軟な対応が可能であるためです。

（３）契約類型の法的影響

契約類型が請負契約か準委任契約かによって、ベンダーが負う義務と潜在的な法的責任は大きく異なります。準委任契約においては、ベンダーの責任は主に、委託された開発業務を専門家としての知識と能力をもって、適切かつ誠実に遂行したかどうかに焦点が当てられます。したがって、法的紛争は、開発プロセスにおけるベンダーの過失や善管注意義務違反の有無が争点となる可能性が高くなります。一方、請負契約では、ベンダーは契約で定められた完成品を期日までに納品する義務を負い、納品物に契約内容との不適合があった場合には、契約不適合責任を追及される可能性があります。アジャイル開発においては、最終的な成果物の仕様が開発の進行とともに変化していくため、請負契約を締結した場合、納品物の適合性を巡って紛争が生じるリスクが高まります。準委任契約であれば、ベンダーは各スプリントにおける開発業務の遂行責任を負うことになりますが、最終的な成果物の完成責任を負わないと解釈されることが多いです。

先述の通り、善管注意義務は過程の妥当性を確認するものであり、そしてその注意義務は、画一的に決まるものではありません。ユーザーがベンダーと同じ立場であれば、ユーザーはSES（System Engineering Service（システムエンジニアリングサービス）としてクライアント企業にITエンジニアの技術力や労働力を提供するサービスと類似するものとなります。その場合は、ベンダーはユーザーの指示に従って作業をすることが多くなります。これに対して、ユーザーが何らの技術的な知識を知らないケースにおいては、裁判官も情報の非対称性などを考慮して判断することがあります。

３．受注者が直面する裁判リスク

受注者がまず気付くべきことは、コーディングをすぐにわかる弁護士は多くいないことです。基本的に大手の弁護士事務所においては理解するものもいますが、それほど多くいるわけではありません。訴訟を提起する側もそれほど理解して訴訟提起しているわけでもないケースも見受けられます。
タイムチャージでなければ受けられないケースもあり、費用はそれなりにかかります。よって、まずやるべきは訴訟を回避し、話し合いで終わらせることです。上場会社においては多額の和解金などを払う場合は説明責任の観点から訴訟を提起しなければならないケースもありますが、そうでない企業はまずは炎上対策をする必要があります。

（１）リスク①：仕様変更の曖昧さに起因する履行範囲の争い

アジャイル開発では、プロジェクト開始時にすべての仕様を明確に定義することは難しく、その上での見積もりを提供することになります。開発の進行とともに仕様が変更されることが前提となりますが、見積もりの曖昧さが、契約に含まれる履行範囲を不明確にし、結果として以下のような争いを引き起こす可能性があります。

当初の見積もり金額で実装すべき内容か否かを巡る争い： ユーザーが、後から追加された仕様や変更が当初の見積もり範囲に含まれると主張し、期間を徒過したとして追加費用の支払いを拒むケースが考えられます。
納品物が不十分と評価され、追加開発を求められるリスク： ユーザーが、アジャイル開発における各スプリントの成果物や最終的な納品物が、自らの期待するレベルに達していないとして、不十分であると主張し、追加の開発を無償で要求する可能性があります。
「成果責任を負っていない」旨の主張が退けられる可能性： ベンダーが準委任契約であることを根拠に最終的な成果物の完成責任を負わないと主張しても、契約の内容や開発の経緯によっては、裁判所がベンダーに一定の成果責任があると判断する可能性があります。すなわち、アジャイル＝免責という安易な考え方はダメで、善管注意義務を重視していく必要があります。

裁判においては、開発中のユーザーとベンダー間のやり取り（議事録、メール、仕様書の版管理など）から、適正な判断と作業などの過程があったか否かが重視されます。適正なマネジメント運営が期待されていますので、仕様変更に関する合意形成のプロセスと、その記録を明確に残しておくことが極めて重要となります。

（２）リスク②：情報提供義務違反とされる可能性

裁判所は、情報システムの開発を請け負うベンダーは、その専門性を有していることを前提として、ベンダーに対してより重い説明義務を負うと考える傾向があります。アジャイル開発においては、特に以下の点について、ベンダーが十分に情報提供を行っていたかが争点となる可能性があります。

アジャイルの進め方自体（仕様変更リスク・追加費用の発生可能性）を事前に説明していたか： アジャイル開発の特性、すなわち仕様が流動的であること、それに伴い当初の見積もりから費用や期間が変動する可能性があることを、ユーザに適切に説明していたかが重要となります。
スプリントごとの成果を「受入済み」と認識してもらう工夫をしていたか： 各スプリントの成果物について、ユーザーから明確な受入確認を得るためのプロセスを確立し、その記録を残しておく必要があります。単に成果物を提示するだけでなく、ユーザがその内容を理解し、合意したことを示す証拠が求められます。
ユーザが誤解するような状態で放置していなかったか：ユーザがアジャイル開発の進め方や成果物の認識について誤解している可能性がある場合、ベンダーが積極的にその誤解を解消するための努力を怠っていたと判断されるリスクがあります。

（３）リスク③：進捗管理・課題共有の怠慢による信頼喪失

アジャイル開発は、「透明性」と「迅速な課題発見」を重要な要素としていますが、以下のような状況が生じると、ベンダーの信頼性が損なわれ、法的紛争につながる可能性があります。

スプリント単位での完了報告が形骸化し、認識齟齬が累積： 各スプリントの完了報告が単なる形式的な手続きとなり、ユーザとベンダー間で成果物や進捗状況に関する認識のずれが積み重なるリスクがあります。
不具合や技術的制約が早期に共有されず、後半で重大化： 開発中に発見された不具合や技術的な制約について、早期にユーザに共有せず、プロジェクトの後半になってから重大な問題として表面化した場合、ベンダーの責任が問われる可能性があります。この点を踏まえて見積もりでの簡易なストーリーポイントから離れて適宜適切な工数見積もりと管理をしていく必要性があります。この点、透明化をし、なぜ工数が見積もれないのか、工数の把握が難しいのかも含めて早い段階に説明しておく必要があります。
PO（プロダクトオーナー）の理解不足を放置し、ユーザ側の誤解を助長： ユーザ側のプロダクトオーナーがアジャイル開発のプロセスや成果物について十分な理解を持っていない場合、ベンダーがその理解不足を放置し、ユーザ側の誤解を助長したとみなされる可能性があります。基本的にここのリスクは大きく、話を安易に合わせず、言うべきことを言わなければ後々障害が発生することもあります。基本的議事録に明記し、争いがあったことも分かるようにしておくのが良いです。

４．裁判になった場合に要求される資料

契約書、要件定義、仕様書などだけでは足りません。作業報告書、スプリントバックログ、プロダクトバックログの他、ソースコードの分析をし、ベンダーが実際に何をやったのか作業報告を裁判官にわかりやすくしなければなりません。
基本的に裁判官からすればアジャイル、ソースコード、プロダクトオーナーなどの言葉すら分からないケースも多くあります。
問題は、ベンダーがユーザーのクラウドにおける開発環境で開発をしていたため、情報が何もないケースです。基本的に争いになることが通常であり、備えておかなければ、負けることもあります。その意味で、基本的にバックアップをしておいた方が良いです。そうでなければ裁判をしながら、資料を許攸しなければならない手間が増えます。
その上で、裁判官にわかりやすく説明するために、以上の証拠を分析し報告書にまとめ上げていく必要があります。この点ソフトウェアエンジニアは、この程度ならわかるだろうとして弁護士に丸投げしてしまうケースもあります。しかし、それでは大体足りません。例えば会議は現場にいたもの以外は分かりません。コミュニケーションも基本的に開発者同士のコミュニケーションはコンテキストを欠くため、理解できないのが通常です。これは外部のソフトウェアエンジニアにも当てはまることであり、分かって当然ということはないのです。基本的に時間は限られており、ソフトウェアエンジニアは弁護士に適切に説明をし、その作業の妥当性を裁判官に理解してもらう必要があります。基本的に裁判官は上記の通り、情報の非対称性からエンジニアの味方というわけではないのでより分かりやすく説明しておかなければ後で苦しむことになります。
常に紛争があることを理解して備え置くことがエンジニア又は経営者にとっては重要なことと理解しておいた方が良いです。そして、早めにソースコードやプログラムが分かる弁護士に相談し適切な手法をとっておいた方が、裁判をするよりもはるかに楽になることも理解しておいた方が良いでしょう。

ご相談はこちらから