ソフトウェアの出来栄えを最後のユーザテスト工程まで確認できず、もうプロジェクト終了直前になって「こんなはずではなかった」とクレームが発せられることの多い従来型のウォータフォール開発に比べれば、アジャイルは確かにスピーディに役立つソフトウェアを作るのに有効な手段と言えます。
ただし、どんな方式にも弱点はあります。また、いくら良い方式でも中途半端な知識のまま行うと却って物事が悪い方向に転がってしまうことも良くある話です。今回は、アジャイル方式で開発は行ったものの、その方式への理解がやや中途半端だったことによる紛争をご紹介したいと思います。まずは、事件の概要からです。
アジャイル開発の同床異夢
(東京地方裁判所 平成26年9月10日判決より)
商品先物取引受託業務を行うユーザ企業が、業務システムの開発をITベンダに依頼し、ベンダはこれを行ったが、ユーザ企業は請負代金などをベンダに支払わなかった。理由は、ベンダが期限までにシステムを完成させなかったとのことで、必要な機能のいくつかが未実装あるいは未完成であるとのことだったが、ベンダは、システムは完成させたはずであるとして、未払の代金と開発中に使用したデータセンターの利用料の支払いを求めて裁判所に訴え出た。
一方ユーザ企業は、システムは完成しておらず、既払い代金の相当額を損賠として、その賠償を求めて、反訴を提起した。なお、この開発はアジャイル方式で行われ、要件定義書、設計書等のドキュメントは残されていなかった。
そもそも、こうした紛争が起きること自体を問題視しなければなりません。ベンダはシステムが完成したと言い、ユーザは完成していないと言うのですが、なぜ、そんな食違いが起きるのでしょうか。答えは簡単で、システムにどのような機能を持たせるのかを両者が共有していなかったからです。ウォータフォール方式なら文書化していた要件や基本設計について正式な合意もないまま進めたため、何を作ればよいのかという認識がズレていた、正に同床異夢の状態だったわけです。何を作るのかが判然としない以上、「頼んだものが出来ているのか」が分からないのはある意味当然のことです。加えて言うなら、この紛争に至った開発では、納品にあたって実施したテストの記録もないので、なおさらベンダー側が債務を全うしたかが分からない状態になっています。
システム開発における「同床異夢」は、最後の最後まで実際のソフトウェアを目にすることができないウォータフォール型の方が発生しがちですが、アジャイルでも、やはりこうしたことが発生するようです。
