アジャイル開発にありがちな、途中でコロコロ変わる発注側の要望……仕様が未確定のまま納期を過ぎてしまった

仕様が「未確定」のまま納期を過ぎたプロジェクト

　契約締結後、開発は進んでいきましたが、双方が思い描いていた「完成の姿」は次第にずれていきました。発注側の担当者は、アプリケーションとして必要となる機能や動作の方向性について検討を重ねながら、開発の途中で追加の要望や改善案を伝えていました。一方、開発会社は、発注側から示される要望を受け止めつつ、中間的な動作確認版を提示しながら実装を進めていきました。

　しかし、年月が経つにつれ、両者の間で「どこまでが契約時点での範囲で、どこからが追加なのか」という線引きが曖昧になっていきます。発注側としては、「依頼したつもりだった」内容が実装されていなかったり、「当然含まれていると思っていた」機能が進まなかったりする場面が増えていきました。それに対し、開発会社は、「その仕様はまだ確定していない」「追加の要望として扱うべきだ」と認識していたため、スケジュールや作業量にも影響が出ていきます。

　納期が迫っても完成しない状態が続くなか、発注側は「いつまで経っても出来上がらないのは、開発会社の不完全履行によるものだ」と考えるようになりました。一方で開発会社は、「仕様が契約当初から確定しておらず、発注側の判断や要望の変更によって作業が左右されていた」と反論しました。

　つまり、発注側は「約束したものができていない」と訴え、開発会社は「そもそも約束が固まっていない」と主張したのです。

　さらに、間に差し込まれていく追加検討や仕様の再調整は、プロジェクト全体の進行を複雑にしました。発注側は「修正は必要だが、本質的には当初の計画の範囲内だ」と捉えるのに対し、開発会社は「内容が変わっており、本来は追加費用や期間の相談が必要だ」と認識していました。両者の理解は、大きな隔たりを生んでいきます。

　このように、争点の中心にあったのは「完成しなかった責任はどちらにあるのか」という一点です。しかしその内側には、仕様の確定時期、追加要望の扱い、進行上の役割分担といった、アジャイル開発特有の問題が幾重にも絡み合っていました。発注側から見れば“当然の期待”であっても、開発会社から見れば“決まっていない要求”だった可能性があり、それが後になって双方の主張を正面からぶつける形になっていきました。

　こうした対立構造は、どちらの主張にも一理あるように見えます。果たして裁判所は、発注側の「未完成」という訴えをどう捉えたのか、あるいは開発会社の「仕様が確定していない」という主張にどれだけ耳を傾けたのか。読み進めるほどに、どちらが最終的に責任を負うことになるのかが気になるところです。さて、判決はどうだったでしょうか。