契約形態の選び方シート

使い方

この資料は、契約書の文面を作るためのものではなく、どの形態で進めるかを社内で決め、開発会社と話すための下準備に使います。第2章の判断シートを埋め、第3章以降で確認事項を洗い出したうえで、実際の契約書は専門家に確認してもらってください。契約は事業の前提を決める部分ですので、雛形をそのまま使わず、自社の状況に合っているかを一度は読み込むことをお勧めします。所要時間は、判断シートの記入と社内の議論で1時間程度を見込んでください。

1. 2つの形態の違いを押さえる

請負契約は「完成した成果物」に対して対価を払う契約です。完成しなければ報酬は発生せず、成果物に不具合があれば修補などを求められます。準委任契約は「業務を行うこと」に対して対価を払う契約で、完成の義務はなく、専門家として適切に業務を進める義務を負います。どちらが有利ということではなく、仕様の確からしさによって適する形が変わります。一般に、作るものが確定していれば請負、これから決めながら進めるなら準委任が検討されます。

2. 自社の状況を判断シートで確かめる

次の各項目に「はい」「いいえ」で答えてください。前半の請負寄りの項目に「はい」が多ければ請負が、後半の準委任寄りに「はい」が多ければ準委任が検討しやすくなります。どちらも半々の場合は、工程を分けて形態を変える方法を第5章で検討してください。この判断は一人で行わず、事業側と現場の双方が同席して答えるほうが、後から前提の食い違いが出にくくなります。

• 【請負寄り】画面と機能の一覧が、追加なしで固まっている
• 【請負寄り】完成の判断基準を、第三者が見て判断できる形で書ける
• 【請負寄り】リリースまでに仕様が変わる見込みはほとんどない
• 【請負寄り】発注側が開発期間中に判断に割ける時間が少ない
• 【準委任寄り】これから顧客に当てながら、作るものを決めていく
• 【準委任寄り】検証結果によっては、途中で作るものが変わる
• 【準委任寄り】優先順位を自社で決めながら進めたい
• 【準委任寄り】発注側が定例に出席し、判断を返せる体制がある

3. 請負を選ぶ場合に確認すること

請負を選ぶなら、完成の定義をどこまで書けるかが要になります。「完成」の判断が曖昧なままだと、検収の段階で双方の認識が食い違い、追加の作業をどちらが負担するかで揉めます。また、仕様変更が起きること自体は避けられませんので、変更の手続きを先に決めておいてください。変更を申し入れる方法と、そのときに費用と納期をどう見直すかが書かれていれば、変更そのものは問題になりません。

• 成果物の一覧（ソースコード、設計資料、デザインデータ、手順書など）が明記されているか
• 検収の方法と期間、検収が通らなかった場合の手続きが書かれているか
• 契約不適合（納品物の不具合）への対応の範囲と期間が書かれているか
• 仕様変更を申し入れる手続きと、費用・納期の見直し方法が書かれているか
• 発注側が資料提供や確認を遅らせた場合の納期の扱いが書かれているか

4. 準委任を選ぶ場合に確認すること

準委任は柔軟な反面、「何が終わったら終わりなのか」が曖昧になりやすい形態です。稼働の報告方法と、成果を確認する仕組みを、契約と日々の運用の両方で決めておいてください。また、発注側が優先順位を決める責任を負う点は、契約を結ぶ前に社内で共有しておく必要があります。ここが決まっていないと、開発会社は手が空いたまま待つことになり、稼働が費用に見合わなくなります。

• 体制（何人が、どの程度の稼働で関わるか）が書かれているか
• 稼働の報告方法と頻度、報告に対する確認の手続きが決まっているか
• 担当者を入れ替える場合の事前の連絡と、引き継ぎの扱いが決まっているか
• 期間の区切り（月次、四半期など）と、更新・終了の申し入れ方法が書かれているか
• 発注側が担う判断（優先順位の決定、確認、資料提供）が言葉になっているか

5. 工程で形態を分ける方法を検討する

すべてを一つの形態にする必要はありません。要件整理や設計は準委任で進め、仕様が固まった部分だけを請負にする、といった分け方もあります。逆に、初回リリースを請負で作り、その後の改善を準委任に切り替える進め方もあります。分ける場合は、工程の境目で何を引き渡すかを決めておいてください。境目の成果物が曖昧だと、次の工程の見積りが出せず、結局そこで時間を使うことになります。

6. どちらの形態でも必ず確認する条項

契約形態にかかわらず、事業の将来に影響する条項があります。特にソースコードや設計資料の権利の帰属は、資金調達や事業売却の際に問われることがあり、後から遡って変更するのは簡単ではありません。契約時点で書面にしておいてください。開発会社が持つ既存の部品が組み込まれる場合は、その部分の扱いだけが異なることもありますので、一括して確認するのではなく、項目ごとに確かめます。

• ソースコード・設計資料・デザインデータの権利が、どの時点で自社に移るか
• 開発会社が既に持っている資産（ライブラリ、社内部品）が含まれる場合、その利用条件
• オープンソースのライセンスの扱いと、一覧の提示があるか
• 機密保持の範囲と期間、開発環境に置ける自社データの範囲
• サーバー・ドメイン・外部サービスのアカウントを、自社名義で持てるか
• 契約を中途で終了する場合の手続きと、引き継ぎ資料の提供

7. 社内で決めて、相手に伝える

契約形態は、開発会社から提案されたものをそのまま受け取るのではなく、自社の状況を伝えたうえで一緒に決めるものです。第2章の判断シートの結果と、そう考えた理由を相手に共有してください。相手が別の形態を勧める場合は、その理由を聞くと、相手が自社の状況をどう見ているかが分かります。理由が「当社は原則そうしている」だけの場合と、自社の仕様の固まり具合を踏まえた説明がある場合とでは、その後の進め方も変わります。

• 自社が請負・準委任のどちらを想定しているか、理由とともに伝えたか
• 仕様がどこまで固まっていて、どこが変わり得るかを具体的に伝えたか
• 発注側が使える時間と、判断できる担当者を伝えたか
• 相手が別の形態を勧めた場合、その理由を聞いて記録したか

ご注意

この資料は契約形態を考えるための一般的な情報をまとめたものであり、法的な助言ではありません。契約の文言や個別の条項の妥当性、自社の状況における法的な効果については、弁護士などの専門家にご確認ください。特に、権利の帰属、契約不適合への対応、中途終了の条件は、事業への影響が大きい部分ですので、雛形の流用ではなく、個別にご確認いただくことをお勧めします。