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

システム化の目的が曖昧なら、プロジェクトマネジメント義務も成り立たない？

　判決文には「プロジェクトマネジメント義務」という言葉は登場しません。しかし、少なくともベンダー側にこれを含めて義務違反はなかったということを、この判決は述べています。

　つまり、ユーザーが仕様などの希望を次々にベンダーへ伝えたとき、ベンダー側はその実現性を検討し、リスクを説明したり、場合によっては要件の取り下げを申し出たり、追加の費用や期間を要求したりといった、いわゆるプロジェクトマネジメント義務は果たしておらず、プロジェクトが完遂しなかった責任はベンダーにあるとされています。

　そして、その理由は「本件が仕様の確定していないまま進められたアジャイル開発だったから」だと判決文からは読み取れます。誤解のないよう申し上げますが、アジャイル開発だからプロジェクトマネジメント義務がないと言っているわけではありません。ただ、この開発の場合、「契約の目的やシステム開発の目的そのものが判然としていななかったため、それを目指して実施されるはずのプロジェクトマネジメント義務は成り立たない」ということだったのだと私は考えます。

　つまり、プロジェクトマネジメント義務をベンダーに負ってもらうにしても、そこには「システム化の目的の定義」という前提があり、開発前に要件を決めきらないアジャイル開発の場合は、そこが明確にならない危険性が高いということです。

　たとえアジャイル開発であっても、個別の機能はともかく、システム化の目的と、それを外したらシステム化の意味がなくなるという主要な要件は最低限定めた上で、ベンダーに作業をお願いする必要があるということでしょう。

アジャイル開発案件でも大切にしたい、目的と主要要件

　昨今はアジャイル開発の割合が増えてきており、そのほうが真にユーザーの要望を反映したシステムを作りやすいという声もよく耳にします。私自身も、いくつかのアジャイル開発を経験してそのように考える一人です。

　ただ、よく誤解されるのは、「アジャイル開発なのだから、要件は決まっていなくてもとりあえずスタートする」という考え方についてです。この考え方は、半分は正解で半分は正しくないように思えます。つまり、これまで述べたように、その時点では決まっていなくても大丈夫な要件と、決まっているべき要件があるということです。

　そもそもシステム開発というのは、組織のなんらかの目的（企業で言えば経営の目的）のために実施されます。たとえば、「売上向上のために機会損失を減らす」という目的の下、「では24時間365日引き合いを受けられるように、Webでの問い合わせや引合、注文を可能にしよう」という提案があり、「それならシステムは24/365稼働で、スマホ対応云々……」といった主要要件が出てきます。これらは、いくらアジャイルであっても前以て定めておかなければ、プロジェクトのゴール設定ができず、実質的にプロジェクトとしての体を成していないことになります。

　残念ながら、今回取り上げたプロジェクトの要件定義書や仕様書といったものを私は見ることができず、どこまでの記述があったのか、あるいはなかったのかについて具体的な指摘はできません。しかし、仮にそこに目的や主要要件が明示され、合意されていたならば、裁判所がプロジェクトマネジメント義務について考慮せず、ユーザーだけに責任があるとした判断を下すことは考えられなかったのではないでしょうか。