LASSIC Media らしくメディア
アプリ開発契約形態選び方｜準委任と請負を徹底比較
LASSIC IT事業部｜プライムベンダーとしてシステム保守・運用を受託
この記事のポイント
- 準委任契約と請負契約の違いを、経済産業省・IPAの公開資料に沿って整理し、比較表で確認できる。
- アプリ開発の工程ごとに、どの契約形態が適しているかを判断する基準を理解できる。
- 契約形態の選定で失敗しないための注意点と、選び方の手順を把握できる。
アプリ開発契約形態の選び方とは、工程ごとに準委任と請負を使い分ける判断である
アプリ開発契約形態の選び方とは、要件定義・設計・実装・テスト・保守の各工程で、準委任契約と請負契約のどちらが業務の性質に適合するかを判断し、契約書として明文化する取り組みを指す。経済産業省およびIPAは「情報システム・モデル取引・契約書」を公開しており、企画段階は準委任契約、開発工程は請負契約とする多段階契約の考え方を提示している*1。要件が固まりきらない上流では準委任、スコープが明確な下流では請負を選ぶことが、契約形態選定の基本軸となる。
目次
選定基準は要件確定度・成果物の明確さ・継続性の3軸
契約形態の選定は、3つの軸で判断する。第一に「要件確定度」。要件が固まっていない段階で請負を選ぶと、スコープ変更のたびに契約変更が必要になりやすく、双方の負荷が大きい*1。第二に「成果物の明確さ」。完成物の定義が明確であれば請負、業務の遂行プロセスに重きが置かれる場合は準委任が適合する。第三に「継続性」。長期にわたる保守運用は、業務範囲が変動するため準委任で柔軟に組み立てるパターンが基本となる。
3軸を踏まえると、アプリ開発の契約形態は工程によって異なるのが自然な姿となる。経済産業省・IPAのモデル契約も多段階契約を前提に構成されている*1。
準委任と請負の比較：法的位置づけ・費用構造・リスク分担
準委任契約と請負契約の主要な違いを比較表で整理する。アプリ開発に直接関係する観点に絞り、判断材料として用いる。
| 比較軸 | 準委任契約 | 請負契約 |
|---|---|---|
| 契約の目的 | 業務の遂行を約束する | 仕事の完成を約束する |
| 成果物の扱い | 必須ではない。成果完成型準委任の場合は成果物に対応した報酬 | 完成物の引渡しが前提 |
| 費用算定 | 人月・時間単価による精算が一般的 | スコープに対する一括または分割の報酬 |
| 指揮命令 | 受託者が業務を主導。発注者からの直接指揮は行わない | 受託者が成果物の完成方法を主導 |
| 契約不適合責任 | 原則として善管注意義務の範囲 | 完成物の契約不適合責任を負う |
| 向く工程 | 要件定義・上流設計・保守運用*1 | 外部設計以降の開発工程*1 |
| スコープ変更時 | 期間延長や工数追加で柔軟に対応 | 契約変更・追加発注が必要 |
比較表が示す通り、両者は性質が異なる契約である。どちらが優れているかではなく、対象業務との適合で選ぶ。
これらの位置づけは、2020年4月に施行された改正民法を前提としている。改正民法では、準委任に、事務処理の遂行に対して報酬を支払う履行割合型と、成果に対して報酬を支払う成果完成型（民法648条の2）の2類型が整理され、従来の瑕疵担保責任は契約不適合責任（民法562条ほか）へと改められた。経済産業省・IPAのモデル取引・契約書も、この改正民法に対応した第二版へ改訂されている*1。比較表の「成果物の扱い」「契約不適合責任」の各行は、この枠組みに沿っている。
準委任契約：要件定義・保守運用に適する柔軟な業務遂行型
準委任契約は、受託者が業務の遂行に責任を負う形態である。アプリ開発では、要件定義・上流設計・保守運用の各工程で活用されることが多い。経済産業省・IPAのモデル契約でも、要件が具体化していない企画段階・要件定義段階で準委任を採用する考え方が示されている*1。
メリット：要件未確定でも着手でき、変動に柔軟に対応できる
要件が固まりきらない段階で着手できるため、ディスカバリーフェーズや、ユーザーリサーチを伴う要件整理に向く。期間延長や工数追加もしやすく、外部環境の変化に対応しやすい構造を取れる。
デメリット：成果物の明確化が弱く、発注者の主体的関与が必要
業務遂行に対する報酬であり、完成物の引渡しが必須ではない。発注者が要件整理・意思決定を主体的に行わない場合、業務の方向性が定まらず費用が膨らみやすい。中間成果物の定義・レビュー頻度を契約書で明確にする必要がある。
向いているケース：要件定義・PoC・継続保守
要件定義段階、PoC（Proof of Concept、実証検証）段階、リリース後の継続保守段階に向いている。長期保守ではアプリのOS追従や機能改善が継続的に発生するため、業務遂行型の準委任で柔軟に運用する組み立てが選ばれる*2。
請負契約：設計・実装・テストに適する成果物確定型
請負契約は、受託者が仕事の完成に責任を負う形態である。アプリ開発では、外部設計が確定したあとの実装・テスト工程で採用されることが多い。経済産業省・IPAのモデル契約でも、開発工程は請負契約を推奨する立て付けとなっている*1。
メリット：成果物が明確で、発注側の予算確定にも向く
完成物が明確であるため、社内予算の確定がしやすく、見積もりと実費の乖離も抑えやすい。発注者にとっては、合意したスコープに対して受託者が完成責任を負うため、品質面の安心感も得られる。
デメリット：スコープ変更には契約変更が必要で、変動への耐性が低い
合意したスコープを超える変更が発生した場合、追加発注・契約変更の手続きが必要となる。アプリ開発では、ユーザーフィードバックを反映した小回りの利く改修が求められる場面もあり、請負だけで全工程を回そうとすると変更管理の負荷が大きい。
向いているケース：外部設計後の実装・結合テスト・初回リリース
外部設計のアウトプットが確定した実装工程・結合テスト工程・初回リリース工程に向いている。複数のサブシステム連携を伴うアプリでは、機能単位で請負契約を分割する組み立ても有効となる。
工程別の推奨パターン：上流は準委任・下流は請負・運用は準委任
工程別の推奨パターンを整理する。経済産業省・IPAのモデル契約の考え方をベースに、現場運用を踏まえた使い分けを示す*1。
| 工程 | 推奨契約形態 | 理由 |
|---|---|---|
| 企画・要件定義 | 準委任 | 要件が変動しやすく、業務遂行型が適合*1 |
| 外部設計（基本設計） | 準委任または請負 | 要件が固まる度合いによって選択。要件側に未確定要素があれば準委任 |
| 内部設計・実装・単体テスト | 請負 | スコープが確定しており、完成物が明確*1 |
| 結合テスト・公開審査 | 請負 | 成果物の品質責任が明確になる |
| 保守運用・OS追従 | 準委任 | 業務範囲が変動するため柔軟性が必要*2 |
工程ごとに契約形態を分けることで、双方のメリットを取り入れた多段階契約となる。発注側にとっては予算とスコープの整合が取りやすく、受託側にとっては業務の性質に合った報酬体系を取れる。
失敗しない選定ポイント：契約形態の混同と書面化漏れを避ける
ポイント1：契約形態の名称ではなく実態で判断する — 形式と実態の乖離を避ける
契約書のタイトルが「業務委託契約」であっても、内容が請負か準委任かは契約条項の実態で判断される。指揮命令関係・成果物責任・報酬算定の3点を明文化しないと、形式と実態の乖離が後日のトラブル原因になる。
ポイント2：成果物の定義と検収基準を必ず書面化する — 認識のずれを防ぐ
準委任でも成果完成型を採用する場合、成果物の定義と検収基準を明確にする。請負では完成物の仕様・検収基準・契約不適合責任の範囲を契約書で確定させる。
ポイント3：スコープ変更時の手続きを契約書で定める — 変更管理の負荷を抑える
スコープ変更が発生した場合の手続き（書面合意の方法・追加見積もりの方法・期間延長の取扱い）を契約書で定めておくことが、運用フェーズでのトラブルを抑える。
ポイント4：機密保持・知的財産権・再委託の条項を漏らさない — 後日紛争の予防
機密保持・知的財産権の帰属・再委託の可否は、契約形態を問わず明文化が必要となる。アプリ開発では、第三者のSDK・ライブラリ利用も多いため、ライセンス取扱いの条項を確認することも求められる。
まとめ：アプリ開発契約形態選定の3つの判断軸
アプリ開発の契約形態は、「要件確定度」「成果物の明確さ」「継続性」の3軸で工程ごとに判断する。経済産業省・IPAのモデル契約に沿うと、上流工程は準委任、下流の開発工程は請負、保守運用は準委任という多段階契約になる*1。選定時の論点は、契約形態を名称ではなく実態で判断すること、および成果物の定義・検収基準・スコープ変更手続き・知的財産権・再委託の各条項を書面化することにある。これらは比較表と工程別表で整理した内容に対応する。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（2020年公開・2025年4月更新）
- *2 出典：経済産業省「情報システム・モデル取引・契約書（受託開発・保守運用）概要」（経済産業省、2007年公表）
