ITごはん

ITを活用したい人、ITで何か作りたい人、そんなITでごはんを食べる人のためのブログ

システム開発の契約形態

はじめに

初めてシステム開発を発注する際に、 最初の難関は契約書ではないでしょうか。

システム開発は、一般に業務委託契約という名前の契約書が 交わされます。

そして、この業務委託契約には大きく2種類あります。 それは、請負契約と委任契約です。

請負契約と委任契約

この2つの契約のもっとも大きな違いは、以下になります。

請負契約
・システムの完成に責任を負う


委任契約

・システムの完成に責任を負わない

どちらもシステム完成に向けて、作業するというところでは違いがありません。 ただし、法律的には、 請負契約が完成について責任を負うことになるのに対し、 委任契約では作業はするものの、システムの完成に責任は負いません。 万が一、完成しなかったとしても、責任を追求することはできません。

どちらがお得か

では、 乱暴に言ってしまえば、発注者にとっては、請負契約が、 受注者にとっては委任契約がお得だと言えます。

請負契約であれば、システム開発会社は何が何でも、完成させなければ 1円も受け取れません。(もちろん、契約内容によります)

ただし、「何が何でも完成させる」という命題がありますから、 例えば、ユーザーのちょっとした機能追加などの要望についても、 受け入れることが難しくなったりします。

これでは、より良いシステムを求めるユーザーにとって、 本末転倒な状況といえるでしょう。

さて、委任契約はどうでしょう。 委任契約ではシステム開発会社は、精一杯作業することが、 第一の目的ですから、機能追加などにも柔軟に対応できます。

ただし、その場合は作業量が増える=支払額が増える、となります。 また、本当に一生懸命やっているか、といった管理も必要になるかもしれません。

実際には、要件定義や基本設計といった、 スケジュールが見えにくい工程(プロセス)では、委任契約。

詳細設計やプログラミング、テストといった、 あるていどスケジュールを立てて進められるような工程では、 請負契約というのが、多いように思います。

最近の状況

最近ではアジャイル開発という、開発手法が各地で行われております。 これは、これまでのウォーターフォールという、 事前にしっかりと計画をたてて、企画→要件定義→設計→プログラミング→テストという、 手順を踏むのではなく、

企画→要件定義→設計→プログラミング→テストを、1〜3か月という短いスパンで、 繰り返すような開発の手法です。 この方法により、発注者とシステム開発会社の認識相違を少なくし、 柔軟に企画や、機能追加を行うことが可能となります。

このようなアジャイル開発では、多くの場合、委任契約のほうがマッチします。

システム開発の法律論

基本的には、契約・法律はトラブルが起こったときに、問題になります。

もちろん、「契約違反だー」と怒号が飛ぶような状況は、 発注者も、システム開発会社も避けなければなりません。

発注者も、システム開発会社もシステム開発という共通のゴールがあるわけですから、 それに向けて協力関係を築くのが第一です。

ただし、認識の相違や止むに止まれぬ事情によって、 契約の話になることもしばしばです。 もし、その際に、双方が建設的に問題を処理できるようにという観点で、 契約書を作成することが大切です。

ユーザを成功に導くシステム開発契約―クラウドを見据えて

ユーザを成功に導くシステム開発契約―クラウドを見据えて