受託開発・運用保守の契約はどう結ぶべきか ── IPA「モデル取引・契約書」に学ぶ準委任と請負の使い分け

「一括請負で契約したのに、要件が固まらないまま開発が始まり、完成の基準をめぐって揉めた」

「月額の保守契約を結んでいるが、どこまでが保守の範囲なのかお互いの認識が違っていた」

「見積もりを取ったら『要件定義は準委任で』と言われたが、なぜ工程ごとに契約を分けるのか分からない」

システム開発の外部委託では、技術ではなく契約のかたちが原因でトラブルになることが少なくありません。

実は、この問題には公的な「お手本」があります。IPA(独立行政法人情報処理推進機構)が公開している情報システム・モデル取引・契約書です。

この記事では、このモデル契約をもとに、受託開発や運用保守を委託するとき・受けるときの契約がどう組み立てられるべきかを、発注側の方にも分かる言葉で整理します。

なお、この記事はIPAの公開資料に基づく一般的な解説であり、法的助言ではありません。個別の契約については、弁護士等の専門家にご相談ください。

1. まず結論

システム開発と運用保守の契約について、IPAのモデル取引・契約書が示している考え方を先にまとめます。

• 開発の全工程を1本の契約にまとめず、工程ごとに契約を分ける(多段階契約)
• 「何を作るか」がまだ決まっていない企画・要件定義の工程は、準委任契約にする
• 「何を作るか」が決まった後の内部設計〜開発・テストの工程は、請負契約を基本にする(外部設計は案件によりどちらも取り得る)
• 運用・保守のような継続的な業務は、準委任契約を基本にする
• 発注側にも、要件を決める・情報を提供するなどの協力義務がある
• 仕様変更は口頭でやり取りせず、文書による変更管理の手続きで扱う

一言でいうと、「決まっていないものに完成責任を約束しない、決まったものには完成責任を約束する」という原則で、工程ごとに契約のかたちを使い分ける考え方です。

この記事の知識マップ

IPAの情報システム・モデル取引・契約書は、開発工程を1本の契約にまとめず工程ごとに分ける多段階契約を軸とし、基本契約書と個別契約書の二層構造で運用される。何を作るか未確定な要件定義には準委任契約が推奨され、決まったものを作る内部設計〜開発・テストには完成責任と契約不適合責任を伴う請負契約が向く。準委任は善管注意義務を前提とし、履行割合型と成果完成型の報酬類型を持つ。運用・保守は継続的業務として準委任が基本だが、保守範囲の線引きを契約時に文書化しないと仕様変更をめぐる水掛け論を招くため、変更管理手続で費用・納期をセットに合意することが重視される。発注側の協力義務とベンダのプロジェクトマネジメント義務がプロジェクト失敗を防ぐ両輪であり、アジャイル開発には準委任を前提とした専用のモデル契約が別に用意されている。

flowchart LR
    accTitle: IPAモデル取引・契約書の知識マップ
    accDescr: 情報システム・モデル取引・契約書が示す多段階契約と基本契約書・個別契約書の二層構造、要件定義に準委任・内部設計以降に請負を使い分ける考え方、運用保守の契約範囲の線引きと変更管理手続がトラブルを防ぐ関係、アジャイル開発版モデル契約の位置づけを示す図
    model_transaction_contract["情報システム・モデル取引・契約書"]
    quasi_mandate_contract["準委任契約"]
    ukeoi_contract["請負契約"]
    ipa["IPA(独立行政法人情報処理推進機構)"]
    multi_stage_contract["多段階契約"]
    system_development_contract["ソフトウェア開発委託基本モデル契約書"]
    maintenance_master_agreement["情報システム保守運用委託基本モデル契約書"]
    agile_development_model_contract["情報システム・モデル取引・契約書(アジャイル開発版)"]
    requirements_definition["要件定義"]
    detailed_design_development["内部設計〜プログラミング〜テスト"]
    individual_contract["個別契約書"]
    operation_maintenance["運用・保守"]
    performance_based_quasi_mandate["履行割合型"]
    outcome_based_quasi_mandate["成果完成型"]
    duty_of_care["善管注意義務"]
    contract_nonconformity_liability["契約不適合責任"]
    verbal_change_request["口頭・メールでの変更依頼"]
    scope_dispute["仕様変更をめぐる水掛け論"]
    change_management_procedure["変更管理手続"]
    cooperation_obligation["発注側の協力義務"]
    project_failure["プロジェクトの失敗"]
    project_management_obligation["プロジェクトマネジメント義務"]
    maintenance_scope_definition["保守範囲の線引き"]
    ipa -->|"実装を担う"| model_transaction_contract
    model_transaction_contract -->|"利用する"| multi_stage_contract
    model_transaction_contract -.->|"利用する"| system_development_contract
    model_transaction_contract -.->|"利用する"| maintenance_master_agreement
    model_transaction_contract -->|"利用する"| agile_development_model_contract
    quasi_mandate_contract -->|"推奨される対応"| requirements_definition
    ukeoi_contract -->|"用いるのは非推奨"| requirements_definition
    ukeoi_contract -->|"推奨される対応"| detailed_design_development
    requirements_definition -->|"より先に行うべき"| detailed_design_development
    ukeoi_contract -.->|"で構成できる"| individual_contract
    quasi_mandate_contract -.->|"で構成できる"| individual_contract
    maintenance_master_agreement -->|"利用する"| individual_contract
    quasi_mandate_contract -->|"推奨される対応"| operation_maintenance
    quasi_mandate_contract -->|"利用する"| performance_based_quasi_mandate
    quasi_mandate_contract -->|"利用する"| outcome_based_quasi_mandate
    quasi_mandate_contract -->|"前提とする"| duty_of_care
    ukeoi_contract -->|"前提とする"| contract_nonconformity_liability
    verbal_change_request -.->|"原因になり得る"| scope_dispute
    change_management_procedure -->|"軽減する"| scope_dispute
    agile_development_model_contract -->|"前提とする"| quasi_mandate_contract
    agile_development_model_contract -->|"用いるのは非推奨"| ukeoi_contract
    cooperation_obligation -->|"軽減する"| project_failure
    project_management_obligation -->|"軽減する"| project_failure
    model_transaction_contract -->|"利用する"| project_management_obligation
    model_transaction_contract -->|"利用する"| cooperation_obligation
    maintenance_scope_definition -->|"推奨される対応"| maintenance_master_agreement
    maintenance_scope_definition -->|"軽減する"| scope_dispute

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全27件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. IPA「情報システム・モデル取引・契約書」とは

情報システム・モデル取引・契約書は、システム開発の委託契約のひな形と、その解説をまとめた公的文書です。

もともとは経済産業省が2007年に、受託開発(一部企画を含む)、保守運用を対象とした第一版として公開しました。ユーザ企業(発注側)とITベンダ(受託側)の間で契約内容の認識がずれ、トラブルが多発していたことが背景にあります。

その後、見直しをIPAが引き継ぎ、2020年4月に施行された改正民法に対応した第二版が2020年12月22日に公開されました。第二版では、後述する契約不適合責任や、成果完成型の準委任契約の位置づけなどが整理されています。

なお、適用範囲には注意が必要です。この第一版・第二版は、もともと企業の基幹システムなどの比較的大規模なカスタム開発(ウォーターフォール型)を、システム部門や法務の体制を持つ企業同士の取引を想定して作られたものです。中小規模の取引やパッケージ・SaaSを活用するケースに向けては、別に「パッケージ、SaaS/ASP活用、保守運用」を対象とした追補版系のモデル契約が用意されています。自社の取引にどちらが近いかを確認したうえで、条文をそのまま流用するのではなく、考え方のベースとして使うのが正しい距離感です。この記事で紹介するのも、規模を問わず役に立つ「考え方」の部分です。

このモデル契約には、次のような特徴があります。

• ユーザ企業、ITベンダ、業界団体、法律専門家が議論して作られており、どちらか一方に有利な内容にならないよう中立的に設計されている
• 契約書のひな形がWord形式で公開されており、自社の取引に合わせて修正して使える
• 条文だけでなく、「なぜそう定めるのか」の解説が付いている
• 開発契約のセキュリティ仕様を決めるためのガイドラインなど、付属文書も公開されている

つまり、これから契約書を作る場合のたたき台としても、相手から提示された契約書を確認するときの比較基準としても使える資料です。

どの版を見ればよいか

IPAのページにはいくつもの版が並んでいるので、自社の取引がどれに近いかを先に決めてから開くと迷いません。

この記事の以降の説明は、いちばん基本になる第二版 本編を前提にしています。

3. 核心は「多段階契約」── なぜ工程ごとに契約を分けるのか

モデル取引・契約書の考え方の核心は、多段階契約です。

システム開発は、おおまかに次のような工程で進みます。

企画・要件定義(何を作るかを決める)
        ↓
設計・開発・テスト(決めたものを作る)
        ↓
受入・導入支援(作ったものを業務に載せる)
        ↓
運用・保守(動かし続ける)

多段階契約とは、これらの工程を1本の契約にまとめず、工程ごと(または工程のまとまりごと)に契約を分けて結ぶ方式です。

実際の文書構造 ── 基本契約書と個別契約書の二層

「工程ごとに契約を分ける」と聞くと、工程の数だけ独立した契約書を作るように思えますが、モデル契約書が採っているのは基本契約書と個別契約書の二層構造です。ひな形を開いたときに戸惑わないよう、構造を先に押さえておきます。

• ソフトウェア開発委託基本モデル契約書(基本契約書) ── プロジェクト全体に共通する事項を定めるもので、原則としてプロジェクトごとに1本結びます。用語の定義、再委託、協働と役割分担、責任者、連絡協議会、変更管理手続、秘密保持、知的財産権、損害賠償といった条文はこちらに入ります。
• 個別契約書 ── 個別業務に着手する前に、その業務ごとに結びます。要件定義作成支援業務、外部設計書作成(支援)業務、ソフトウェア開発業務、ソフトウェア運用準備・移行支援業務といった単位です。ここで決めるのは、具体的な作業内容と範囲、契約類型(請負か準委任か)、作業期間または納期、役割分担の詳細、委託料と支払方法、納入物、検査・確認に関する事項などです。

つまり、「工程ごとに変わるもの」はすべて個別契約書側に寄せてあり、請負にするか準委任にするかも個別契約書で決める建て付けです。基本契約書には、個別契約書の条項が基本契約書に優先する旨も定められています。

運用・保守は開発とは別の契約書(情報システム保守運用委託基本モデル契約書)が用意されていて、こちらも基本契約書と個別契約書という同じ二層です。保守運用は業務の種類が多様で一律のひな形を作れないため、共通条項だけを基本契約書に置き、個々の委託業務は個別契約書で定める、という考え方が明示されています。個別契約書には、定型化したサービス内容を書く業務仕様書と、対象システムや実施場所・役割分担のように顧客ごとに変わる事項を書く受託条件明細を添付する想定になっています。

第二版の本編に収録されている契約書類は次のとおりです。

なぜ分けるのでしょうか。理由は単純で、工程によって「約束できること」が違うからです。

要件定義が終わる前の段階では、作るものの内容も分量も確定していません。この時点で開発全体の金額と納期を確定させると、次のどちらかが起こります。

• 受託側が、不確定なリスクを見込んだ大きめの金額を提示する
• 安く受けた受託側が、後から「それは範囲外です」と主張し、発注側と揉める

一方、要件定義が終わっていれば、作るものが決まっているので、受託側は現実的な精度で見積もりと完成の約束ができます。

多段階契約は、「要件定義が終わった時点で、開発部分をあらためて見積もり直す」ことを前提にした方式です。発注側から見ると総額が最初に確定しない不安はありますが、根拠のない金額で全体を確定させるより、結果的にトラブルも無駄なコストも少なくなる、というのがモデル契約の立場です。

4. 準委任と請負 ── 2つの契約類型の違い

多段階契約では、工程ごとに準委任契約と請負契約を使い分けます。この2つの違いが、この記事でいちばん重要なポイントです。

この章で出てくる用語を先に短くまとめておきます。

そのうえで、請負と準委任の違いを一覧にします。

請負契約 ── 完成を約束する契約

請負は、「この成果物を完成させます」と約束する契約です。受託側は完成責任を負い、完成しなければ原則として報酬を請求できません(ただし、プロジェクトが途中で終了した場合でも、完成している部分を切り分けて発注側の利益になるときは、その割合に応じた報酬が認められることがあります)。

納品物が契約の内容に適合していなかった場合、受託側は契約不適合責任を負います。2020年施行の改正民法で従来の「瑕疵担保責任」から再構成されたもので、発注側は修補(直してもらうこと)を請求できるほか、期間を定めて修補を求めても行われない場合など一定の条件のもとでは、報酬の減額を請求することもできるようになりました。ただし、発注側が提示した仕様や指示そのものが原因で不適合が生じた場合は、受託側がその問題に気づきながら告げなかったようなときを除き、原則としてこれらの請求はできません。モデル契約第二版は、この改正を反映しています。

完成と引き換えに強い責任を負う契約なので、「何をもって完成とするか」を明確に決められる工程で使うのが適切です。

準委任契約 ── 専門家としての仕事を約束する契約

準委任は、「専門家として業務を行います」と約束する契約です。受託側は完成責任を負わない代わりに、善管注意義務、つまり専門家として通常期待される注意を払って業務を遂行する義務を負います。

「完成責任がない」と聞くと、発注側には不安に聞こえるかもしれません。しかし、これは「手を抜いてよい」という意味ではありません。専門家として不適切な仕事をすれば、善管注意義務違反として責任を問われます。

また、改正民法では成果完成型の準委任という報酬の払い方も明文化されました。行った業務の割合に応じて報酬を支払う履行割合型(時間単価で精算する方式はその代表例で、定型業務を月額固定で行う形もあり得ます)に対し、成果完成型では合意した成果に対して報酬を支払います。要件定義書のような成果物がある準委任業務では、この型を使うことで「準委任だが、成果物の納品と報酬が結びついている」形にできます。

工程ごとの使い分け

モデル取引・契約書では、おおむね次のような使い分けが想定されています。

ここで大切なのは、「請負の方が発注側に有利」「準委任は受託側に有利」という単純な話ではないことです。

決まっていない段階の仕事を無理に請負にすると、完成の基準が曖昧なまま完成責任だけが約束され、「完成した/していない」の水掛け論になります。工程の性質に合った契約類型を選ぶことが、結局は両者を守ります。

5. 運用保守の契約で決めておくべきこと

開発が終わった後の運用保守は、開発とは別のトラブルの種を抱えています。いちばん多いのは、「月額の保守料金にどこまで含まれるのか」の認識ずれです。

運用保守と一口に言っても、中身は性質の違う業務の集まりです。

• 稼働監視、バックアップ、定期メンテナンス
• 操作方法などの問い合わせ対応
• 障害発生時の一次調査・復旧対応
• 不具合の修正
• OSやミドルウェアの更新への追従
• 機能追加・画面変更などの改修

このうち、監視・問い合わせ対応・一次調査のような継続的な業務は準委任型が基本です。一方、内容を明確に定義できる機能追加や改修は、保守契約の中に曖昧に含めず、個別に見積もって請負で切り出す方が安全です。

言葉だけでは実感しにくいので、線引きの例を挙げます。どこに線を引くかは契約で決めることなので、これはあくまで「よくある落としどころ」です。

4行目の「画面に1項目追加」は、依頼する側からは軽微に見えて、実際には設計・実装・テスト・リリースの一式が動きます。「画面や帳票の項目が増減する依頼は別見積もり」のように、判断が分かれない基準を1行決めておくと、都度の交渉が減ります。

契約時には、少なくとも次の点を文書で決めておくことをおすすめします。

• 月額(定額)の範囲に含まれる作業と、含まれない作業の線引き
• 問い合わせや障害対応の受付時間帯と、対応開始までの目安時間
• 障害の重要度の区分と、区分ごとの対応方針
• 定額範囲を超える作業が発生した場合の見積もり・発注の手順
• 開発時の契約不適合責任(無償修正の対象)と、保守契約(有償対応)の関係

特に最後の点は見落とされがちです。納品直後に見つかった不具合が開発契約の契約不適合責任の範囲なのか、保守契約での対応なのかは、期間と条件を契約で明確にしておかないと揉めやすいポイントです。

6. 発注側にも義務がある ── 協力義務とプロジェクトマネジメント義務

契約書の話から少し広がりますが、モデル取引・契約書の解説やこれまでの裁判例で繰り返し示されてきた重要な考え方があります。システム開発は発注側とベンダの共同作業であり、どちらにも果たすべき義務があるという点です。

• ベンダ側は、専門家としてプロジェクトを適切に管理し、リスクがあれば説明する義務(プロジェクトマネジメント義務)を負う
• 発注側は、要件を決める、業務内容の情報を提供する、必要な意思決定を期限内に行うなどの協力義務を負う

つまり、発注側が「専門的なことは分からないから」とすべてをベンダに委ねる、いわゆる丸投げをすると、要件は固まらず、プロジェクトが失敗したときに発注側の協力義務が問われることもあります。

モデル取引・契約書には、両者の役割分担を文書化し、連絡協議会(定例会議)で進捗と課題を共有する仕組みが組み込まれています。契約書のひな形というより、プロジェクトを共同で運営するためのルールブックとして読むと、発注側にとっても得るものが大きい資料です。

7. 仕様変更は「変更管理手続」で扱う

開発の途中で「やはりこの画面はこう変えたい」という要望が出るのは、避けられないことです。問題は変更が出ること自体ではなく、変更を口頭やメールのやり取りだけで進めてしまうことです。

• 発注側は「軽微な変更のつもりだった」
• 受託側は「対応したが、工数が膨らんだので追加費用を請求したい」

口頭やメールのやり取りも交渉の記録にはなりますが、変更の範囲・費用・納期まで含めて双方が正式に合意した文書がないため、この状態になってからでは水掛け論になりがちです。

モデル取引・契約書には、変更管理手続が定められています。おおまかには次の流れです。

変更の提案(どちらからでも)
        ↓
書面(変更提案書)で内容・影響範囲・費用・納期への影響を提示
        ↓
両者で協議
        ↓
合意したら書面に残して変更を実施 / 合意できなければ現行どおり

ポイントは、変更の内容だけでなく、費用と納期への影響をセットで合意してから着手することです。手続きとしては一手間ですが、この一手間が「言った・言わない」を防ぎます。

8. アジャイル開発の場合は専用のモデル契約がある

ここまで説明してきたのは、要件を決めてから作るウォーターフォール型を前提とした契約です。

一方、作りながら要件を見直していくアジャイル開発には、情報システム・モデル取引・契約書(アジャイル開発版)という専用のモデル契約が2020年3月31日に公開されています。

アジャイル開発版の特徴は次のとおりです。

• 契約類型は準委任契約を前提としている。開発の途中で機能の追加・変更や優先順位の見直しを行うことが前提の手法であり、最初に成果物を確定させる請負となじまないため
• 開発手法としてスクラムを採用し、役割分担(プロダクトオーナーなど)を契約に組み込んでいる
• 契約前チェックリストが付属しており、プロジェクトの目的やアジャイル開発への理解度を発注側・受託側で確認してから契約に進む構成になっている

「アジャイルだから契約は曖昧でよい」のではなく、「変化に対応する開発だからこそ、役割と進め方を契約で明確にする」という設計です。

まとめ

IPAの情報システム・モデル取引・契約書から学べる、受託開発・運用保守の契約の考え方を整理します。

• 開発全体を1本の契約にまとめず、工程ごとに契約を分ける(多段階契約)
• 「何を作るか」を決める企画・要件定義は準委任、決まったものを作る内部設計以降の開発は請負が基本(外部設計はどちらも取り得る)
• 請負は完成責任と契約不適合責任、準委任は善管注意義務と、受託側が負う責任の性質が違う
• 運用保守は準委任を基本に、定額範囲と個別見積もりの線引きを契約時に文書化する
• 発注側にも協力義務があり、丸投げはプロジェクトを失敗させる
• 仕様変更は変更管理手続に載せ、費用・納期への影響とセットで合意する
• アジャイル開発には準委任を前提とした専用のモデル契約がある

モデル契約書のひな形と解説は、IPAのWebサイトからWord形式で無償でダウンロードできます。これから開発を委託する方も、契約書を提示された方も、一度目を通しておいて損のない資料です。

システム開発・保守の委託をご検討の方へ

契約のかたちを適切に選ぶには、その前提として「何を作るのか」「どこまでを委託するのか」「発注側と受託側でどう役割を分担するのか」が整理されている必要があります。

合同会社小村ソフトでは、Windows業務アプリやWebシステムの受託開発・保守のご相談をお受けする際、この記事で紹介した多段階契約の考え方に沿って、要件整理の段階と開発の段階を分けてご提案しています。開発範囲や成果物の整理がまだこれからという段階でも、現状の業務内容の確認からご相談いただけます。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

請負契約と準委任契約の違いは何ですか？

請負契約は「決めた成果物を完成させること」に対して報酬を支払う契約で、受託側は完成責任と契約不適合責任を負います。準委任契約は「専門家として業務を行うこと」に対して報酬を支払う契約(成果完成型の準委任では、合意した成果に対して報酬を支払います)で、受託側は善管注意義務(専門家として注意深く業務を遂行する義務)を負いますが、完成責任は負いません。作るものと完成の基準を明確に決められる工程は請負、発注側主体の検討を支援する工程や継続的な業務は準委任が向いています。

なぜ要件定義は準委任契約が推奨されるのですか？

要件定義は「何を作るか」を発注側が主体となって決める工程であり、ベンダはその検討を支援する立場だからです。また、開始時点では成果物を具体的に確定しにくいため、この段階で完成責任(請負)を約束すると完成の基準が曖昧になり、トラブルの原因になります。IPAのモデル取引・契約書でも、企画・要件定義の工程は準委任型が想定されています。

運用保守の契約は請負と準委任のどちらが良いですか？

稼働監視、問い合わせ対応、障害の一次調査のような「継続的な業務」は、完成という概念になじまないため準委任型が基本です。一方、内容と完成基準を明確に定義できる機能追加や画面改修は、個別に切り出して請負で契約する方法があります。月額の保守契約に何が含まれ、何が別見積もりになるのかを、契約時に文書で線引きしておくことが重要です。

IPAのモデル取引・契約書はそのまま使えますか？

モデル契約書はWord形式で公開されており、自社の取引に合わせて修正して使うことが前提です。ユーザ企業とITベンダのどちらか一方に有利にならない中立的な立場で作られているため、契約書のたたき台や、提示された契約書を確認するときの比較基準として役立ちます。ただし個別の契約判断については弁護士等の専門家への相談をおすすめします。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。