
今回はソフトウェア開発を行う際に、よく用いられる「多段階契約」のおける紛争事例について紹介します。本事例から契約の在り方自体について考えてみたいと思います。
増えてきた多段階契約
以前にもこの連載で触れたことがあると思いますが、ソフトウェアの開発を行う際、多段階契約を行う例が良く見られます。ソフトウェアの開発というのは、ある意味、やってみなければ分からないことが多く、当初の契約時点で定められた機能と費用が開発を行ううちに、どんどん変わってしまうのが常と言っても良いほどです。
金額と期間を定めて、作り始めたが、いざやってみると、まだ機能が足りないことに気づいた、技術的な難易度が思ったより高くて費用が足りなくなった。そんな話はまさに日常茶飯事です。
こうしたソフトウェア開発のリスクを低減しようと言うのが多段階契約です。ベンダは提案時に概算の見積は出すものの、それはある意味、変更することを前提としたもので、まず要件定義だけを契約します。そして、実際にやってみて機能や実現方式を明らかにした後設計の契約を結び、またそれができたら今度は開発の契約を結ぶという方式です。
こうした契約の仕方なら、契約毎に費用と実装する機能、スケジュールを調整するので、開発の見通しは効きにくいものの、ユーザ企業とベンダの間での諍いのようなものは起きにくくなります。
実際のプロジェクトを見ても、問題があれば双方が話し合いをして、費用の追加や機能の縮退といった落としどころを見つけることが多いようです。そんなこともあって、こうした契約形態をとるソフトウェア開発が徐々に増えてきました。
この記事は参考になりましたか?
- この記事の著者
-
細川義洋(ホソカワヨシヒロ)
ITプロセスコンサルタント東京地方裁判所 民事調停委員 IT専門委員1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年より20...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア