【読書メモ】システム開発 受託契約の教科書
なぜ請負が多いか
- ユーザーとしては、請負であれば、当初の予算どおりに開発を終えられると思っている
- システム開発会社としては、上手くやれれば請負の方が準委任よりも儲けることができる点に請負契約で受注する
- リスクは避けたいというユーザー心理と、利益率を上げたいというシステム開発会社の思惑が合致し、請負で契約する場合が多い
- しかし、これは当然ながら、システム開発会社としては大きなリスクを孕んでいる
- システム開発会社の見積ミスで赤字案件となった開発をよく耳にする
請負と判断する要素
- 完成する仕事（システム）が具体的となっている
- 完成したら代金を支払うこととなっている
- 報酬が工数に関係なく決められている
- 瑕疵担保責任の条項がある
- 検収の条項がある
- 契約書の標題が請負契約となっている
準委任と判断する要素
- 完成する仕事（システム）が明確になっていない
- システム開発会社が投入した人月に応じて代金が決まることとなっている
- システムが完成しなくても作業をやれば、代金を支払うこととなっている
- 契約書の標題が業務委託契約書となっている（当事者に準委任契約であるとの意思がある場合、業務委託契約という標題を使うことが多い。なお、単なる「委託」という言葉は、請負でも使われるので注意)
一括契約と多段階契約
多段階契約
- メリットは見積の正確性にある。
- システム開発プロジェクトは、その開始時点では構築するシステムの具体像が詳細化はされていないので、この段階で正確に見積することには無理がある
- 必要とされるシステムスキルも流動的
- したがって、システム開発プロジェクト開始時に全工程を一括して契約することは、リスクを抱えることになるので多段階契約をする
一括契約
- システム開発会社としては、ある程度バッファをみた見積で価格をユーザーに提示することが多い。
- バッファを食い潰しても工数が足りず、システム開発会社としては赤字となる案件が多くみられる。
- その一方で、ユーザーとしては、実際に開発をしてみたら思いのほか簡単であった、したがって一括契約の代金が結果的には割高になるという事態も想定される
- 要件定義フェーズの過程で、ユーザーの現場から様々な意見が出て、当初の想定よりも遥かに工数が膨らんでしまうことはよくある。
- 一括契約の場合、システム開発会社としては対応できる工数に限りがあるので、色々噴出した要件について、どんどんカットしていかざるを得なくなる
- ある程度以上大きい開発（案件の内容にもよるが、数十人月～百人月以上）は、多段階契約とすべき
契約の形態
- 1つは、全フェーズで共通の基本契約書を締結し、それに基づいてフェーズ毎に個別契約書を締結するという方法
- もう1つは、要件定義フェーズの契約と、設計～リリースまでの契約の2段階契約
- 要件定義前に契約することは、ユーザー、システム開発会社双方にリスクがある
- 一般論として外部設計までは準委任契約が望ましい
- 外部設計、導入・受入支援、運用テストといったフェーズは、ユーザーが深く関わるべきだから
- システム開発会社としては、自社の力だけで仕事を完成できないこれらのフェーズを請負契約とすることはリスクがある
基本契約書について
基本契約とは
企業間で反復・継続して行われる商取引に、共通的に適用される事項をまとめてあらかじめ定めたもの
システム開発契約における基本契約書
取引横断型
このタイプの契約書は、ユーザーとシステム開発会社との間で使われるよりも、元請のシステム開発会社と下請のシステム開発会社との間で使われることが多いもの
フェーズ横断型
開発工程の内のフェーズを一括して契約する場合も多いが、規模が大きい開発の場合は要件定義前に金額を確定することはリスクが大きいので、フェーズ毎に契約するというような場合
個別契約書
- 契約書に「準委任契約」と書いてあっても、裁判になった場合、契約の内容から裁判官が「請負契約」であると判断する可能性がある。
- 請負契約とは、仕事の完成を目的とする契約
-> したがって、例えば要件定義フェーズを準委任契約とするのであれば、作業項目は「要件定義」または「要件定義書作成支援とする」
要件定義か要件定義書作成支援か
事例
1. 要件定義フェーズのユーザーとシステム開発会社の役割分担として、要件定義書はユーザーが作成しシステム開発会社は要件定義書のチェックおよび進捗確認を行う場合
2. ユーザーは業務要件をメモや既存の業務マニュアル等で提示しそれを受けて要件定義書の作成自体をシステム開発会社が行う場合
->1. の場合が「要件定義書作成支援」であり、2.の場合が「要件定義」。前者であれば、準委任契約になる。
感想
システム開発自体が約2回に1回が上手くいかない状況を考えると、クライアントを含めた相互理解の基、適切な意思決定をしていく行いが大切だな〜
この記事が気に入ったらサポートをしてみませんか？