本連載では、ITプロジェクトにおける様々な勘所を、実際の判例を題材として解説しています。今回は、「アジャイル開発にプロジェクトマネジメント義務はあるのか?」という問題を扱います。アジャイル方式のプロジェクトでは、開発が進むにつれ発注者のイメージや要望が変わっていくことが珍しくありません。当初の契約には、そんな機能や要件は含まれていなかったのに……。その場合、どこまでを完成とみなせばよいのでしょうか。また、未完成に終わった場合の責任は、発注側と受注側のどちらにあるのでしょうか。
アジャイル開発につきまとう“Moving Goal”の危険性
アジャイル方式でプロジェクトを進めていると、当初の発注者側が明確に描いていた「完成の姿」が、自身の中でも少しずつ曖昧になっていくことがあります。ベンダーが開発した部分をレビューなどで見ている際にはそれなりにプロジェクトが前に進んでいるように思えても、その直後に別の課題や要望が生まれ、気付けば「今回の開発ではどこまでを完成とみなすのか」が自分でも整理しづらくなるといったことがよく発生するものです。
無論、発注者側のシステム担当としても、むやみに開発規模を大きくしたり、要求を変更したりするつもりはないのですが……。たとえば、社内のエンドユーザーから寄せられる改善要求を丁寧に拾い上げ、「できるだけ事業のスピードに合わせて開発に反映させたい」など、組織の要望に応えるシステムを作ろうとすればするほど、スコープが膨らみ、ベンダーあるいは開発チームとの認識の隔たりがどんどん広がってしまうなんてことは、アジャイルに限らず日常茶飯事です。
そうなってくると、ベンダー側としても「仕様がいつまでも固まらない」という不満が溜まりますし、発注側としても結局、「思い描いたものがいつまで経っても出来上がらない」という不満が膨らんでいくわけです。
今回取り上げる判例は、こうした発注側の意思決定の遅れや、仕様確定の曖昧さが積み重なり、最終的に「未完成の責任はどちらにあるのか」が法的判断の争点となったケースです。アジャイル開発の特性と、発注者・受注者それぞれの役割がどう作用したのかを確認することで、現在進めているプロジェクトにおいて、どのような点に注意を払うべきかが見えてきます。
この記事は参考になりましたか?
- 紛争事例に学ぶ、ITユーザの心得連載記事一覧
-
- アジャイル開発にありがちな、途中でコロコロ変わる発注側の要望……仕様が未確定のまま納期を過...
- 裁判所が重視するプログラムの「新規性・独自性」とは? 自社のプロダクトを守るために知ってお...
- 「ユーザー側の態度」が破綻したITプロジェクトの予後を左右する──“野村HD vs 日本I...
- この記事の著者
-
細川義洋(ホソカワヨシヒロ)
ITプロセスコンサルタント
経済産業省デジタル統括アドバイザー兼最高情報セキュリティアドバイザ
元東京地方裁判所 民事調停委員 IT専門委員
筑波大学大学院修了(法学修士)日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステム...※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
