システム開発契約のポイント
1.システム開発契約の全体像
システム開発契約は、開発期間、開発規模、金額等が千差万別です。
数十万円単位のものから数百億円単位のものまであり、非常に個別性が高い契約類型です。
多くのリソースが割かれることがある一方で、その契約交渉は十分になされていることは多くないのが実情です。
契約書が存在しないケース、開発概要や金額等のについてだけ記載されたが締結されているようなケース、他の契約類型を雛形を流用したために実態と乖離した契約書が締結されているケースがあります。
システム開発契約の雛形としては、以下のものが公表されています。
※「情報システム・モデル取引・契約書」
独立行政法人情報処理推進機構・経済産業省
※「２０２０年版ソフトウェア開発モデル契約」
一般社団法人 電子情報技術産業協会 ソリューションサービス事業委員会
https://home.jeita.or.jp/cgi-bin/page/detail.cgi?n=1124&ca=1
これらの雛形を非常に参考になりますが、最終的には個別のシステム開発毎に適切な契約条項を設定する必要があります。
2.開発手法
(1)概要
システム開発は、大きく分けてウォーターフォール型とアジャイル型の2種類に分類されます。
※参照 「D X レポート
～ITシステム「2025年の崖」の克服とDXの本格的な展開～」 平成３０年９月７日デジタルトランスフォーメーションに向けた研究会
https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_02.pdf
(2)ウォーターフォール型
ウォーターフォール型とは、開発工程を「要件定義→基本設計→プログラミング→テスト」といった工程ごとに区切って、工程ごとに開発を進めていく開発手法です。
滝の流れの様に、工程の上流から下流にかけて開発が進むことからウォーターフォール型とよがれています。
ウォーターホール型では、前工程で確定したことを前提として次工程の開発を進めます。そのため、基本的には前工程に戻る（「手戻り」といいます）ことなく順々に開発を進めていくことが想定されています。
ウォーターフォール型が向いている開発
開発対象が要件定義の段階で明確になり、開発期間中に要件定義の内容が必要となる状態にならないことが想定されている場合には、ウォーターホール型の開発が向いています。
要件定義→基本設計→詳細設計→プログラミング→テスト
(3)アジャイル型
アジャイル型とは、「新しい機能を短期間で継続的にリリースしていくソフトウェア開発のアプローチ」※をいいます。
※引用元「なぜ、いまアジャイルが必要か？」 IPA
アジャイル型は、開発中に変動する周辺環境の変化を柔軟に開発内容に組み込むことができることが大きなメリットです。
ウォーターフォール型の様に開発前に全体の要件定義を行ってから開発するのではなく、機能ごとに開発を行っていくため、途中の手戻りが比較的行いやすいことがメリットです。
開発段階では不確定な要素が多いシステム開発に向いている開発手法です。
(4)その他
SES（System Engineering Service）契約とは、主にITベンダがユーザーに対し、エンジニアの稼働を人月ベースで提供するものです。
ユーザーにとっては、自社でエンジニアを採用する手間が省けること、必要なときに必要なリソースだけ確保することが出来る点で利便性が高いものになります。
ITベンダにとっても、適切な人材をアサインし効率よくマネジメントすることが出来れば大きな利ざやを得ることができるものになります。
SES契約は、実態としては、ユーザーからITベンダがアサインしたエンジニアに直接指揮命令がなされていることもあります。
このような実態がある場合には、労働者供給（職業安定法第4条第7項）や労働者派遣法に定める労働者派遣に該当する可能性があります。
これがいわゆる「偽装請負」と呼ばれるケースになります。
「偽装請負」に該当することを避けるためには、実態として、ユーザーが直接指揮命令を行わせないことが重要です。もちろん、契約書上でも指揮命令関係等について明記することも大切です。
具体的な基準は、以下を参考にしましょう。
基準の詳細な解説はこちらの記事を参考にしてください。
・旧労働省告示（労働者派遣業と請負による行われる事業との区分に関する基準（昭和61年労働省告示37号））
https://www.mhlw.go.jp/content/000780136.pdf
・厚生労働省ガイドライン（労働者派遣・請負を適正に行うためのガイド）
https://www.mhlw.go.jp/file/06-Seisakujouhou-11600000-Shokugyouanteikyoku/0000078287.pdf
Poc(Proof of Concept)契約とは、試作品を作成する契約のことです。
あくまでも試作品レベルのものを作成し検証することが目的であるため、厳格な要件定義は行われないことが一般的です。
とはいえ、試作品作成によって著作物が創作されるケースもあるため、試作品に関する権利関係の帰属については事前に明確に契約書に記載しておく必要があります。
ラボ契約とは、ベンダーにおいて、ユーザーが求める一定水準以上のエンジニアの稼働を一定期間確保する代わりに、ユーザーには最低発注量に関する義務が課されるものです。
ラボ契約を締結することで、ユーザーは新規プロダクトの開発や既存プロダクトの追加開発や改修にあたり、その都度エンジニアを集める必要がなくなります。そのため、迅速にその開発に着手できることが利点です。
一方で、一定のエンジニアの稼働を確保するために必要なコストがかかりますので、ある程度資金余力のある企業向けのものになるでしょう。
3.契約類型
システム開発契約は、請負契約と準委任契約のいずれかに該当するものとして整理されることが一般的です。
請負契約・準委任契約のいずれにも該当しない契約類型（無名契約）として整理することもありますが、どちらかをベースにしつつアレンジを加えていることが多いのが実態です。そのため、両契約の基本的な性質を理解することが重要になります。
契約の性質は、契約書の名称や契約書に記載されている文言のみによって判断されるわけではなく、実質的な業務実態も考慮されます。
ベンダー：納品した後に契約不適合責任とか負いたくないなぁ・・・あ、業務の完成に対して責任を負わないように準委任契約にしよう！契約書にも「本契約は準委任契約とみなす」って書いておこう。これで安心安心。
契約書に契約の性質を記載することは問題ありませんが、仮に紛争になった場合に、常に契約書の記載通りの契約性質と判断されるわけではない点に注意しましょう。実態として、請負なのか準委任なのか、それともそれら以外なのかが重要です。
両者には複数の異なる性質がありますが、コアな部分では、仕事の完成が義務となるのが請負契約、善良なる管理者による業務遂行が義務となるのが準委任契約という違いがあります。
どちらか一方のみの契約性質になることもありますが、作業フェーズ毎に契約の性質が異なることも多くあります。
アジャイル型の場合には、フレキシブルにやるべきことを変更することが出来るというメリットを生かすためにも、基本的には準委任契約が選択されることが一般的です。
請負契約と準委任契約の違いはこちらの記事を参考にされてください。
4.システム開発に関する紛争
システム開発に関する紛争としては以下のようなものがあります。
・完成品が出来た時点で必要な機能関してユーザーとベンダ間で認識のズレが発覚した
・UIのデザインイメージがズレていた
・そもそもUXとUIの概念に関する認識がズレており業務範囲に関する認識も同様にズレていた
・追加開発費用が発生することをユーザー側が認識していなかった
・納品日までに成果物が納品できなかった
・納品物に重大なバグが発見されリリース後草々に一旦クローズとなった
上記の様な紛争に巻き込まれた会社様は、こちらからお気軽にご相談ください。
