06:00ソフトウェア開発を行う際、要件の確定→設計の確定→開発→テストというプロセスを踏まず、おおまかな要望を元に、まずは開発してみて、ユーザと共にその機能や性能などについて議論をしながら修正や追加を行いながら徐々に作り上げていくというアジャイル開発は、中小規模の開発プロジェクトを中心にすっかり市民権を得た形となっており、昨今、ソフトウェア開発の成功率が上がってきた要因の一つにこのアジャイル方式の定着を挙げる人がいます。ソフトウェアの出来栄えを最後のユーザテスト工程まで確認できず、もうプロジェクト終了直前になって「こんなはずではなかった」とクレームが発せられることの多い従来型のウォータフォール開発に比べれば、アジャイルは確かにスピーディに役立つソフトウェアを作るのに有効な手段と言えます。どんな方式にも弱点はあります。良い方式でも中途半端な知識のまま行うと却って物事が悪い方向に転がってしまうことも良くある話です。今回は、アジャイル方式で開発は行ったものの、その方式への理解がやや中途半端だったことによる紛争をご紹介したいと思います。行うユーザ企業が、業務システムの開発をITベンダに依頼し、ベンダはこれを行ったが、ユーザ企業は請負代金などをベンダに支払わなかった。理由は、ベンダが期限までにシステムを完成させなかったとのことで、必要な機能のいくつかが未実装あるいは未完成であるとのことだったが、ベンダは、システムは完成させたはずであるとして、未払の代金と開発中に使用したデータセンターの利用料の支払いを求めて裁判所に訴え出た。ユーザ企業は、システムは完成しておらず、既払い代金の相当額を損賠として、その賠償を求めて、反訴を提起した。ドキュメントは残されていなかった。そもそも、こうした紛争が起きること自体を問題視しなければなりません。ベンダはシステムが完成したと言い、ユーザは完成していないと言うのですが、なぜ、そんな食違いが起きるのでしょうか。答えは簡単で、システムにどのような機能を持たせるのかを両者が共有していなかったからです。ウォータフォール方式なら文書化していた要件や基本設計について正式な合意もないまま進めたため、何を作ればよいのかという認識がズレていた、正に同床異夢の状態だったわけです。何を作るのかが判然としない以上、「頼んだものが出来ているのか」が分からないのはある意味当然のことです。加えて言うなら、この紛争に至った開発では、納品にあたって実施したテストの記録もないので、なおさらベンダー側が債務を全うしたかが分からない状態になっています。システム開発における「同床異夢」は、最後の最後まで実際のソフトウェアを目にすることができないウォータフォール型の方が発生しがちですが、アジャイルでも、やはりこうしたことが発生するようです。※この続きは、会員の方のみお読みいただけます(登録無料)。会員登録(無料)ログインはこちら※この続きは、会員の方のみお読みいただけます(登録無料)。NECソリューションイノベータ(株))にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年より2012年まで日本アイ・ビー・エム株式会社にてシステム開発・運用の品質向上を中心にITベンダ及びITユーザ企業に対するプロセス改善コンサルティング業務を行なう。現在は、東京地方裁判所でIT開発に係わる法的紛争の解決を支援する傍ら、それらに関する著述も行なっている。モメないプロジェクト管理77の鉄則』。西内啓氏が見据える次の10年。EYACCの森島さんはいかにして生まれたのか319SAPが会津若松で中小企業のものづくりのイノベーションに取り組む理由296AWSでセキュリティを高めるために今すぐやるべき7つのこと262企業のデジタルシフトはIoT、5G、サブスクリプションが牽引。×ログインEメールパスワード※旧SEメンバーシップ会員の方は、同じ登録情報(Eメール&パスワード)でログインいただけます。パソコン「EnterpriseZine」(エンタープライズジン)は、翔泳社が運営する企業のIT活用とビジネス成長を支援するITリーダー向け専門メディアです。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。