Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

中途半端なアジャイルが招く危険

2018/07/05 06:00

 ソフトウェア開発を行う際、要件の確定→設計の確定→開発→テストというプロセスを踏まず、おおまかな要望を元に、まずは開発してみて、ユーザと共にその機能や性能などについて議論をしながら修正や追加を行いながら徐々に作り上げていくというアジャイル開発は、中小規模の開発プロジェクトを中心にすっかり市民権を得た形となっており、昨今、ソフトウェア開発の成功率が上がってきた要因の一つにこのアジャイル方式の定着を挙げる人がいます。

 ソフトウェアの出来栄えを最後のユーザテスト工程まで確認できず、もうプロジェクト終了直前になって「こんなはずではなかった」とクレームが発せられることの多い従来型のウォータフォール開発に比べれば、アジャイルは確かにスピーディに役立つソフトウェアを作るのに有効な手段と言えます。

 ただし、どんな方式にも弱点はあります。また、いくら良い方式でも中途半端な知識のまま行うと却って物事が悪い方向に転がってしまうことも良くある話です。今回は、アジャイル方式で開発は行ったものの、その方式への理解がやや中途半端だったことによる紛争をご紹介したいと思います。まずは、事件の概要からです。

アジャイル開発の同床異夢

  (東京地方裁判所 平成26年9月10日判決より)

 商品先物取引受託業務を行うユーザ企業が、業務システムの開発をITベンダに依頼し、ベンダはこれを行ったが、ユーザ企業は請負代金などをベンダに支払わなかった。理由は、ベンダが期限までにシステムを完成させなかったとのことで、必要な機能のいくつかが未実装あるいは未完成であるとのことだったが、ベンダは、システムは完成させたはずであるとして、未払の代金と開発中に使用したデータセンターの利用料の支払いを求めて裁判所に訴え出た。

 一方ユーザ企業は、システムは完成しておらず、既払い代金の相当額を損賠として、その賠償を求めて、反訴を提起した。なお、この開発はアジャイル方式で行われ、要件定義書、設計書等のドキュメントは残されていなかった。

 そもそも、こうした紛争が起きること自体を問題視しなければなりません。ベンダはシステムが完成したと言い、ユーザは完成していないと言うのですが、なぜ、そんな食違いが起きるのでしょうか。答えは簡単で、システムにどのような機能を持たせるのかを両者が共有していなかったからです。ウォータフォール方式なら文書化していた要件や基本設計について正式な合意もないまま進めたため、何を作ればよいのかという認識がズレていた、正に同床異夢の状態だったわけです。何を作るのかが判然としない以上、「頼んだものが出来ているのか」が分からないのはある意味当然のことです。加えて言うなら、この紛争に至った開発では、納品にあたって実施したテストの記録もないので、なおさらベンダー側が債務を全うしたかが分からない状態になっています。

 システム開発における「同床異夢」は、最後の最後まで実際のソフトウェアを目にすることができないウォータフォール型の方が発生しがちですが、アジャイルでも、やはりこうしたことが発生するようです。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 細川義洋(ホソカワヨシヒロ)

    ITプロセスコンサルタント 東京地方裁判所 民事調停委員 IT専門委員 1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年...

バックナンバー

連載:紛争事例に学ぶ、ITユーザの心得

もっと読む

All contents copyright © 2007-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5