ソフト開発の裁判沙汰は
もちろん、アジャイル開発そのものが悪いわけではなく、正しく契約と開発をしないと紛争になる傾向があるということです。紛争をなくすためにも正しい契約と正しい開発をしていく必要があり、本文で紹介します。
ソフトウェア開発はいいかげん
ソフトウェア開発はいいかげんです。これはハードウェアの開発と比較して、ソフトウェアの開発では、きっちりと仕様を決めずに、部品を決めずに、工法（開発手法）を決めずに、開発者のスキルも決めずに、適当にいいかげんに開発します。
ソフトウェアがハードウェアに対して開発がいい加減になる理由は、ソフトウェアが柔軟に臨機応変に開発できるためです。この柔軟さが却って仇（あだ）になって、いいかげんになる傾向にあります。
特にアジャイル開発ではウォーターフォール開発と比較して、仕様をきっちりと決めずに開発する傾向があります。このため、アジャイルではますますいいかげんになります（断言）。
アジャイル開発の裁判沙汰の例
ここではアジャイル開発における裁判例を見ていくことにします。
(1) ドキュメントの不備
ソフトウェア開発ベンダが、アジャイル開発ではドキュメントは不要と考え、品質保証／追跡のためのドキュメントを作成しませんでした。これをプロジェクトマネージャの責任の放棄と判断されました(下記参照)。
上記のベンダは、アジャイル開発の指針となっている「アジャイルソフトウェア開発宣言」にある「包括的なドキュメントよりも動くソフトウェアを、価値とする」の宣言を品質保証・追跡のドキュメントは不要と誤解しています。
アジャイル宣言にも「左記のことがらに価値があることを認めながらも」とあるように、必要なドキュメントは必要です（この文はトートロジー）。
判例：
東京地裁：平成２６年９月１０日判決 裁判例 (2014WLJPCA0 09108013)
東京地裁：平成２４年５月３０日判決 裁判例 (2012WLJPCA05308009)
東京地裁：令和４年３月１０日判決 裁判例 (2022WLJPCA03108015)
# 大髙浩, 「Agile 紛争から学ぶ教訓の見える化」,
# Forum 207, 失敗学会(2024/10)から参照（以降の判例もここから参照）
(2) 仕様決定の遅れ・未定
ソフトウェアユーザ企業とソフトウェア開発ベンダ間で、仕様の決定が遅れ、また仕様が決定できないことが原因で、どちらに瑕疵があるかで裁判になりました（下記参照）。
仕様があいまいであったために、準委任契約をユーザとベンダ間で結び、開発を実施したが、結果的に納期までに仕様が決まらず、開発が失敗になりました。
このような場合は、ベンダ側の「プロジェクトマネージャの義務違反」とユーザ側の「善管義務」との争いになるが、結果はベンダ側の賠償を認められました。
アジャイル開発は仕様が未定の状態で始まることが多いですが、（ユーザ側の善管義務を条件にして）仕様を決める主たる責任はベンダ側にあります。ベンダはアジャイルだから仕様を未定のまま開発を進めるのは間違っています。
判例：
東京地裁：令和２年９月２４日判決 裁判例 (2020WLJPCA09248012)
アジャイル開発が裁判沙汰にならないために
裁判の判例を見てきましたが、多くの問題は(1)ドキュメントの不備と(2)仕様決定にあります。これらが原因で裁判沙汰にならないための指針を紹介します。
(1) ドキュメントは必要なものだけ必要なときのみに
アジャイル開発でもドキュメントはまったく不要ではありません。これを怠ると裁判沙汰になります。
しかしアジャイルでは包括的なドキュメントより動くソフトウェアに多くの価値を認めています。そしてこれはアジャイルな開発に必要なものです。
このため、ドキュメントは包括的ではなく必要なものだけ作成します。
そして事前に用意するのではなく、必要になったときにのみ、作成します。
「これだけドキュメント」の精神です。
(2) 仕様決定は必要なものだけ必要ときのみに
仕様決定が遅れる、または仕様が決定されないと、ソフトウェア開発はたぶん失敗し裁判沙汰になります。
アジャイル開発でも一般的には最後まで仕様を決めずに開発することはできません。（ただし永遠に工事中というプロジェクトがありますが。）
このため、仕様決定は必要なものだけ、必要になったときに決める必要があります。これは書くまでもない当たり前のことですが。
「必要になったときまでに仕様決定」の精神です。
(参考) アジャイル契約はIPAのモデル契約で
契約そのものは何らかのモデルとなる契約をベースにするのが安全です。以下のIPAで策定したアジャイル開発のモデル契約書がありますので参考にしてください。
情報システム・モデル取引・契約書（アジャイル開発版）
ソフトウェア開発を成功するために
アジャイル開発で裁判沙汰にならないためには前述のように、必要最低限のドキュメント作成や仕様決定をする必要があります。しかしこれはあくまでも、裁判沙汰にならないための施策です。
そこでここではソフトウェア開発を、アジャイル開発を成功するための指針を記載します。
(1) ユーザとベンダの共創
アジャイル開発では判例にもあるように、仕様決定の責任分担があいまいになりがちです。
そこでアジャイル宣言の「契約交渉よりも顧客との協調を」とあるように、契約交渉よりもユーザとベンダの協調に価値があるとしていて、上記の仕様決定にも役立ちます。
これはアジャイル開発だけに限らずに、ウォーターフォール開発でも、ユーザとベンダの協調、共創は成功への鍵となります。
ただしこれをやり過ぎると、ユーザとベンダが癒着し、共依存になってしまう危険性もありますので、適当な距離で共創することが必要です。
(2) 仕様変更の適当な対応
アジャイル開発だけに限らずソフトウェア開発では、仕様変更は多く起こります。この仕様変更を柔軟に対応できる仕組みが必要です。アジャイル開発では、これが肝であり、このための施策が詰まっています。
しかしこれが逆にソフトウェア開発が失敗する原因にもなります。そこで仕様変更に対しては、なんでもかんでも「柔軟に」受け付けるのではなく、取捨選択して「適当に」受け付けることが大事です。
ということで今日の結論。「ソフト開発で裁判沙汰にならないためにドキュメントと仕様決定は適当に」以上です。
以下のグループで今回のメトリクスに関する情報を紹介しています。
ソフトウェア研究会「とある技術のソフトウェアエンジニアリング」 | Facebook
マンガFAQの引用元：ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
いいなと思ったら応援しよう！
