「進行中の業務委託契約を途中で切りたいが、訴えられないだろうか」——開発の外注でつまずいた企業から、こうした相談をよく受けます。契約期間はまだ残っている。相手の担当者からは「途中解約なら残りの期間分を請求します」と言われた。しかし社内では年度内の結論を求められている。契約書を読み返しても、解除条項の意味がうまく読み取れない。そんな状態で検索にたどり着く方がほとんどです。
結論から言うと、業務委託契約の解除は、合意解約、債務不履行による解除、契約に基づく中途解約(任意解除)の3類型に分けると整理できます。そして「解除できるかどうか」の答えは、多くの場合「できる」です。民法上、請負は注文者が仕事の完成前ならいつでも損害を賠償して解除でき、委任・準委任は各当事者がいつでも解除できると定められているためです。争点になるのは可否ではなく、既にやった分の報酬をどう精算するか、作りかけの成果物をどう引き取るかという点に移ります。
システム開発では、ここに固有の難しさが加わります。私が見てきた相談で最も多いのは「切ったあとに開発が止まる」ケースです。リポジトリの管理権限が相手側にあり、本番環境の認証情報も一部しか引き継げず、次のベンダーが着手できない。法的には解除できていても、事業としては前に進んでいない。解除を決める前に、精算と引き渡しの範囲を書面で決めておくことが、実務では何より効きます。
本記事では、解除の3類型と見分け方、民法とフリーランス法(2024年11月施行)の原則、契約書で確認する6か所、システム開発での出来高の精算とソースコード・環境の引き渡し、解除の前に検討できる選択肢、よくある質問の順に解説します。なお本記事は一般的な情報提供であり、法的助言ではありません。個別の案件については、契約書を持参のうえ弁護士にご相談ください。
私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。そのなかで、契約を解除せずに体制だけを入れ替えて解決した案件も数多くあります。この記事を読み終えるころには、自社がどの類型に当たるのか、次に何を確認すべきかが判断できるはずです。
目次
- 業務委託契約の解除は3類型
- 「解除」と「解約」は同じではない
- 3類型の比較表(根拠・要件・予告・金銭・使いどころ)
- リスクが低い順に選ぶ
- 解約通知の出し方
- 民法の原則とフリーランス法
- 請負(民法641条): 注文者は仕事の完成前ならいつでも解除できる。ただし損害を賠償して
- 委任・準委任(民法651条): 各当事者がいつでも解除できるが、不利な時期の解除は損害賠償
- 既にやった分の報酬はどうなるか
- フリーランス法16条: 継続的業務委託の解除・不更新は少なくとも30日前までに予告
- 契約書で見る6か所
- 契約書チェック表(6項目・どこに何が書いてあるか)
- 中途解約の予告期間
- 既履行部分の報酬と違約金
- 契約が終わっても残る条項
- システム開発での解除
- 途中解除で最ももめるのは「どこまでが出来高か」
- 引き渡しを受けるもの9項目(チェック表)
- 次のベンダーへの移行
- 解除の前に確認する
- 当社の場合——契約を解除せずに体制を変える選択肢と、引き継ぎやすさの設計
- 1か月単位のリプレイスメントと約1週間の増員
- Git標準とドキュメント納品
- 業務委託契約の解除でよくある質問
- Q1. 契約書に解除条項がなくても、途中で解除できますか?
- Q2. 解除の通知は何日前に出すべきですか?
- Q3. 解約通知はメールで出しても有効ですか?
- Q4. 残りの契約期間分の報酬は、全額支払う必要がありますか?
- Q5. 作りかけのソースコードは引き渡してもらえますか?
- まとめ: 3類型を見分け、契約書の6か所を確認し、精算と引き渡しを書面で決める
業務委託契約の解除は3類型——合意解約、債務不履行による解除、契約に基づく中途解約

業務委託契約を終わらせたいとき、最初にやることは通知書の作成ではありません。自社のケースがどの類型に当たるかを見分けることです。類型が決まれば、相手の同意が要るのか、催告が要るのか、何日前に予告するのか、金銭はどう動くのかが自動的に決まります。ここを飛ばして手順を進めると、後から根拠を組み直すことになります。
「解除」と「解約」は同じではない——さかのぼるか、将来に向かってのみか
日常会話では「解除」と「解約」を区別せずに使いますが、法律上は意味が異なります。解除は、原則として契約を締結した時点にさかのぼって効力を消滅させる行為で、受け取ったものを返す原状回復義務が生じます。解約は、将来に向かってのみ効力を消滅させる行為です。
ただし、業務委託契約で実際に問題になる場面では、この差はやや緩やかになります。民法は委任の解除について「第六百二十条の規定は、委任について準用する」と定めており(民法652条)、準用される620条は「解除をした場合には、その解除は、将来に向かってのみその効力を生ずる」と規定しています。継続的な準委任契約を途中で終わらせる場合、過去に提供された役務まで巻き戻すことはしない、という整理です。
契約書に「解約」と書かれているか「解除」と書かれているかで、実務上の扱いが大きく変わることは多くありません。とはいえ、条項を読むときは「どちらの言葉が使われているか」ではなく「終了の効果と精算がどう書かれているか」を見てください。
3類型の比較表(根拠・要件・予告・金銭・使いどころ)
業務委託契約の終わらせ方は、根拠の違いで次の3つに分かれます。契約期間の満了による終了(不更新)を加えると4つですが、こちらは厳密には解除ではなく、更新しないという選択です。
類型 | 根拠 | 主な要件 | 予告・手続き | 金銭の扱い | 使いどころ |
|---|---|---|---|---|---|
合意解約(合意解除) | 当事者の合意 | 相手方の同意 | 協議のうえ解約合意書を締結 | 精算条件を合意書で決める | 相手に落ち度がない、または争点を残したくない場合 |
債務不履行による解除 | 民法541条(催告解除)・542条(催告によらない解除) | 相手の債務不履行があること。541条は相当の期間を定めた催告が必要 | 書面で催告し、期間内に履行がなければ解除の意思表示 | 既履行部分の精算に加え、損害賠償を請求できる場合がある | 納期遅延・品質不良・連絡不通などが続く場合 |
契約に基づく中途解約(任意解除) | 契約書の中途解約条項。定めがなければ民法641条(請負)・651条(委任・準委任) | 相手の落ち度は不要 | 契約書所定の予告期間(30日前・60日前・3か月前など)を守る | 既履行部分の報酬を支払う。相手の損害の賠償や違約金が問題になる場合がある | 予算削減・方針変更など自社都合の場合 |

なお、民法541条の催告解除には「その期間を経過した時における債務の不履行がその契約及び取引上の社会通念に照らして軽微であるときは、この限りでない」という但し書きがあります。軽微な遅れを理由にした解除は認められない可能性があるということです。一方、542条は履行不能や明確な履行拒絶など5つの場合を挙げ、催告なしに直ちに解除できると定めています。無催告で切れる場面は限られている、と理解しておいてください。
リスクが低い順に選ぶ——不更新、合意解約、そして一方的な解除
3類型のどれを選ぶかは、法的な可否だけでなく、紛争になる確率で判断すると失敗が減ります。リスクが低い順に並べると、契約期間の満了による不更新、双方合意による合意解約、一方的な解除、という順序になります。当社が発注者側から相談を受けるときも、まず不更新で目的を達せられないかを確認し、達せられない場合に合意解約、それも難しい場合に一方的な解除、という順で検討します。
自社都合で終わらせたい場合ほど、この順序が効いてきます。相手に落ち度がないのに債務不履行を理由にすると、事実の立証ができず、逆に相手から損害賠償を求められる展開になりかねません。契約期間の残りが3か月なら、無理に切らずに満了を待って更新しないほうが、総コストが低く済むこともあります。
相手の債務不履行が明らかな場合でも、まず催告を出し、そのうえで協議を申し入れるという二段構えが現実的です。催告書は「是正されなければ解除する」という予告であると同時に、後から見れば「こちらは是正の機会を与えた」という記録にもなります。
解約通知の出し方——記載する7項目と、内容証明郵便で残す理由
類型が決まり、協議の段取りがついたら、書面で通知します。解約通知書(解除通知書)に記載する項目は次の7つです。
- 通知日: 作成日・送付日。予告期間の起算点になる
- 受信者の情報: 相手方の会社名・代表者名または氏名、住所
- 差出人の情報: 自社の会社名・代表者名・住所・連絡先
- 対象の契約: 契約書の正式名称と締結日。基本契約と個別契約がある場合は両方
- 解除または不更新の意思表示: 「本契約を◯年◯月◯日をもって解除します」など
- 効力発生日(契約終了日): 具体的な日付
- 解除の理由: 債務不履行を理由にする場合は必須に近い。自社都合でも記載したほうが誠意が伝わる
債務不履行を理由にする場合は、催告の内容を先に送ります。「本通知書の到達から◯日以内に◯◯を履行しない場合は、本契約を解除します」という形で、是正の対象と期限を特定して書いてください。
送り方は内容証明郵便が基本です。内容証明郵便は、いつ・どのような内容の文書を送ったかを郵便局が証明する制度で、後日「そんな通知は受け取っていない」という反論を封じられます。メールでの通知が無効というわけではありませんが、送達の記録が弱くなります。協議が円滑に進んでいる案件でも、最終的な意思表示だけは記録の残る形で出しておくと、後の精算交渉が安定します。ここまでが手続きの話です。次章では、その手続きを支える民法とフリーランス法の原則を確認します。
民法の原則とフリーランス法——請負は641条、委任・準委任は651条、継続的業務委託は30日前予告

「業務委託契約」という名前の契約類型は、民法にはありません。中身が請負なのか、委任・準委任なのかで、適用される条文と解除のルールが変わります。まずは自社の契約がどちらに当たるかを確かめてください。なお、以下は条文と公開情報に基づく一般的な整理であり、法的助言ではありません。個別の判断は契約書を持参のうえ弁護士にご確認ください。
請負(民法641条): 注文者は仕事の完成前ならいつでも解除できる。ただし損害を賠償して
請負は、仕事の完成を目的とする契約です。システム開発でいえば、要件を確定して「このシステムを納品する」と約束する形が典型です。この場合、民法641条が「請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解除をすることができる」と定めています。
読みどころは「いつでも」と「損害を賠償して」の2つです。注文者側からの解除には、相手の落ち度も、理由の説明も要りません。その代わり、解除によって請負人に生じた損害を賠償する義務がセットになっています。賠償の範囲は一律ではなく、既にかかった費用や、得られたはずの利益の一部が問題になります。「いつでも切れる」という前半だけを読んで動くのは、失敗のもとです。
なお、注文者が破産手続開始の決定を受けた場合は、請負人または破産管財人から解除できます(民法642条)。これは発注側の事情が極端に悪化した場面の規定です。
委任・準委任(民法651条): 各当事者がいつでも解除できるが、不利な時期の解除は損害賠償
準委任は、仕事の完成ではなく事務の処理そのものを目的とする契約です。ラボ型開発やSES、月額での保守・運用などが該当します。法律行為以外の事務の委託は準委任と呼ばれ、委任の規定が準用されます(民法656条)。
民法651条1項は「委任は、各当事者がいつでもその解除をすることができる」と定めています。発注側からも受注側からも解除できる、という点が請負との違いです。ただし2項で、次の場合には相手方の損害を賠償しなければならないとされています。ひとつは相手方に不利な時期に解除したとき、もうひとつは委任者が受任者の利益(専ら報酬を得ることによるものを除く)をも目的とする委任を解除したときです。いずれも、やむを得ない事由があったときは賠償義務を負いません。
実務では、この2項2号の解釈が争点になります。最高裁昭和56年1月19日判決(昭和54年(オ)第353号・民集35巻1号1頁)は、委任が受任者の利益をも目的とする場合であっても、委任者が解除権自体を放棄したものとは解されない事情があるときは、やむを得ない事由がなくても民法651条により解除できると判示しました。受任者が被る不利益は、損害の賠償によって填補されれば足りるという整理です。現行の651条2項2号は、この判例法理を踏まえて明文化された規定にあたります。したがって長期の専属体制を前提にした契約でも、問題になるのは解除できるかどうかではなく、賠償すべき損害の範囲です。単発の開発委託でこの論点が正面から問題になる場面は多くありませんが、長期契約では意識しておく価値があります。
既にやった分の報酬はどうなるか——請負は民法634条、委任は648条3項
解除の相談で最も多い質問が、既にやった分の扱いです。条文は次のように整理されています。
契約類型 | 条文 | 内容 |
|---|---|---|
請負 | 民法634条 | 請負が仕事の完成前に解除されたとき、既にした仕事の結果のうち可分な部分の給付によって注文者が利益を受けるときは、その部分を仕事の完成とみなし、請負人は利益の割合に応じて報酬を請求できる |
委任・準委任(履行割合型) | 民法648条3項 | 委任が履行の中途で終了したときは、受任者は既にした履行の割合に応じて報酬を請求できる |
委任・準委任(成果完成型) | 民法648条の2第2項 | 成果に対して報酬を支払う約定の場合、民法634条が準用される |
解除の効力 | 民法652条→620条準用 | 委任の解除は将来に向かってのみ効力を生ずる。損害賠償の請求は妨げられない |
原則として、残りの契約期間分の報酬を全額支払う義務があるわけではありません。既にやった分・着手済みの分は支払い、未着手分は支払わないというのが出発点です。ただし、解除によって相手に生じた損害の賠償は別の問題として残ります。ここを混同すると、交渉が噛み合わなくなります。
フリーランス法16条: 継続的業務委託の解除・不更新は少なくとも30日前までに予告
2024年11月1日に施行された「特定受託事業者に係る取引の適正化等に関する法律」(フリーランス法、フリーランス新法とも呼ばれます)は、従業員を使用しない個人などへの業務委託に、発注側の義務を課しています。解除に直結するのが16条です。
同条1項は「特定業務委託事業者は、継続的業務委託に係る契約の解除(契約期間の満了後に更新しない場合を含む)をしようとする場合には、当該契約の相手方である特定受託事業者に対し、厚生労働省令で定めるところにより、少なくとも三十日前までに、その予告をしなければならない」と定めています。災害その他やむを得ない事由により予告することが困難な場合などは例外とされています。2項では、予告日から契約満了日までの間に相手から解除理由の開示を請求された場合、遅滞なく開示する義務が定められています。
ここでの「継続的業務委託」は、政令で定める期間以上の期間行う業務委託(契約の更新により継続してその期間以上行うこととなるものを含む)を指します。単発の契約が短くても、更新を重ねて累計で期間を満たせば対象になり得る、という整理です。政令で定める期間は改正で変わり得るため、契約前に最新の条文を確認してください。
注意点は2つあります。第1に、対象は従業員を使用しない個人などであり、従業員を抱える開発会社との契約は通常この義務の対象外です。第2に、対象外であっても、契約書に定めた予告期間は当然に守る必要があります。自社が発注しているフリーランスのエンジニアがいるなら、更新しないだけの場合でも予告が必要になり得る点は要注意です。
契約書で見る6か所——予告期間、既履行部分の報酬、返還、機密保持、競業避止、損害賠償

民法の規定の多くは任意規定で、契約書に別の定めがあればそちらが優先される場面が少なくありません。つまり、解除を検討するときに最初に開くべきは六法ではなく、自社が締結した契約書です。どこを、どの順で読むかを6か所に絞って示します。
契約書チェック表(6項目・どこに何が書いてあるか)
次の6項目を、契約書の条番号と合わせて書き出してください。社内で共有するときも、この形にしておくと議論が早く進みます。
No | 確認する項目 | 典型的な条項名 | 見るポイント | 定めがない場合 |
|---|---|---|---|---|
1 | 中途解約の予告期間 | 契約期間、中途解約、解約 | 何日前・何か月前か。書面か電磁的方法か。自社からも解約できるか(片務になっていないか) | 請負は民法641条、委任・準委任は651条による |
2 | 既履行部分の報酬 | 報酬、委託料、清算 | 月額か成果物単位か。日割り・時間割の定めがあるか。検収前の作業をどう評価するか | 請負は民法634条、委任は648条3項の考え方による |
3 | 成果物と資料の返還 | 成果物の帰属、資料の取扱い、返還義務 | ソースコード・設計書・貸与資料の返還または引き渡しの期限と方法。著作権の移転時期(報酬完済時になっていることが多い) | 個別交渉になり、もめやすい |
4 | 機密保持の存続 | 秘密保持、存続条項 | 契約終了後に何年残るか。データの消去・返却の義務があるか | 存続の定めがないと終了とともに切れる可能性がある |
5 | 競業避止 | 競業避止、専属性 | 期間・範囲・対象者。終了後も相手のメンバーを直接雇用・直接契約できるか(引き抜き禁止条項) | 定めがなければ制限はないが、事実上の摩擦は残る |
6 | 損害賠償の範囲 | 損害賠償、責任の制限、違約金 | 上限額(直近◯か月分の報酬額など)、間接損害・逸失利益を除外しているか、違約金の定額条項があるか | 民法の一般原則による。上限がないため予測が立てにくい |
この6項目のうち、1・2・6は金銭に直結し、3・4・5は解除後の事業運営に直結します。どれか1つでも空欄になるなら、通知を出す前に埋めておくほうが安全です。
中途解約の予告期間——30日前・60日前・3か月前と、日数の数え方
中途解約条項の予告期間は、契約によって30日前、60日前、3か月前などさまざまです。月額の継続契約では「1か月前までに書面で通知することにより、翌月末日をもって解約できる」という書き方もよく見ます。
見落としやすいのが日数の数え方です。フリーランス法の条文は「少なくとも三十日前まで」と定めています。当社では、予告日から契約終了日の前日までに30日以上が確保されるよう、終了日から逆算して予告日を決める運用にしています。たとえば8月31日で終了させるなら、8月1日までに予告する計算です。契約書の予告期間も、同じように「終了日から逆算していつまでに出すか」を日付で押さえてください。
契約書の予告期間と法令上の予告期間の両方がかかる場合は、長いほうに合わせます。契約書が60日前で法令が30日前なら、60日前です。逆に、契約書に何も書かれていなくても、フリーランス法の対象なら30日前の予告が要ります。
既履行部分の報酬と違約金——「未着手分は払わない」を書面にする
精算でもめる原因の大半は、条文の解釈ではなく、合意の不在です。「既履行部分の報酬」といっても、開発では「着手したが動くものがない作業」が必ず出てきます。設計だけ終わったもの、実装したがテスト前のもの、レビュー指摘の修正待ちのもの。これらをどう評価するかを、解除の意思表示より前に決めておくのが実務の要点です。
違約金条項にも注意が要ります。中途解約の場合に「残存期間の委託料相当額」を違約金とする条項が入っていると、実質的に中途解約できない契約になります。逆に、違約金の定めがなくても、相手が被った損害の賠償を求められる可能性は残ります。ここが不透明な会社との契約は要注意です。
合意解約を目指す場合は、解約合意書に「本合意書に定めるほか、当事者間に何らの債権債務がないことを相互に確認する」といった清算条項を入れるのが一般的です。これがあると、後から追加請求が出てくる余地を狭められます。
契約が終わっても残る条項——機密保持、知的財産、競業避止、返還義務
契約書の末尾には、たいてい存続条項(残存条項)が置かれています。「本契約終了後も、第◯条、第◯条の規定は有効に存続する」という形です。ここに何が列挙されているかで、解除後の自由度が決まります。
発注側から見て確認したいのは、成果物の著作権が自社に移転する条項が存続するか、相手が保持する自社のデータの消去・返還義務が残るか、相手のメンバーへの直接接触が制限されていないか、の3点です。特に3点目は、体制ごと別の会社に移す場合や、優秀なメンバーだけ直接契約したい場合に効いてきます。解除を決めた後になって存続条項を読み、打ち手が狭まっていたと気づく——これは避けられる失敗です。
システム開発での解除——出来高の精算、ソースコードと環境の引き渡し、次のベンダーへの移行

ここまでが法律と契約書の話です。システム開発では、これに固有の難しさが加わります。私が2018年からホーチミンで約100社の開発体制の相談に乗ってきたなかで、解除の相談で最も多いのは「切ったあとに開発が止まる」ケースです。法的には解除できている。しかしリポジトリの権限が相手側にあり、次のベンダーが着手できない。事業としては何も前に進んでいません。
途中解除で最ももめるのは「どこまでが出来高か」——着手前に決めておく3点
民法634条は、請負が仕事の完成前に解除されたとき、可分な部分の給付によって注文者が利益を受けるならその部分を完成とみなし、利益の割合に応じて報酬を請求できると定めています。条文は明快ですが、開発では「可分な部分」と「注文者が受ける利益」の線引きが難しいのが実情です。
たとえば、10画面のうち6画面を実装したが結合テストが終わっていない、という状態を考えてみてください。発注側は「動かないのだから利益は受けていない」と言い、受注側は「6割は完成している」と言う。どちらの主張にも理屈があり、条文だけでは決まりません。
この争いを避ける方法は1つです。着手前に、次の3点を契約書または個別の合意書に書いておくことです。
- 出来高の単位: 画面単位・機能単位・スプリント単位のどれで数えるか。マイルストーンごとの完了条件(DoD)を定義する
- 検収の方法とタイミング: 誰が、何をもって検収とみなすか。月次で部分検収を行うか、最終納品時に一括で行うか
- 中途終了時の評価方法: 検収済みの部分は満額、着手済みで未検収の部分は工数実績ベース、未着手は支払わない、といった扱いを明記する
すでに契約が始まっていて、この定めがない場合は、解除の意思表示より前に協議を申し入れ、出来高の評価だけ先に合意する進め方が現実的です。合意ができてから通知を出すほうが、通知を出してから合意を目指すより、圧倒的に早く終わります。
引き渡しを受けるもの9項目(チェック表)——ソースコード、権限、環境、認証情報、設計書
引き渡しは「ソースコードをもらう」だけでは足りません。次の9項目を一覧にして、期限と受け渡し方法を合意書に書いてください。
No | 引き渡しを受けるもの | 具体例 | 見落としやすい点 |
|---|---|---|---|
1 | ソースコード一式 | アプリケーション、バッチ、IaCの定義 | 開発途中のブランチ、未マージの作業も対象に含めるか |
2 | リポジトリの管理権限 | GitHub・GitLabのOwner権限、組織の移管 | 相手の組織配下にある場合は、リポジトリごと移管が必要 |
3 | 実行環境の情報 | クラウドのアカウント、構成、ネットワーク設定 | 相手名義のクラウドアカウントだと移管に時間がかかる |
4 | 認証情報 | APIキー、サービスアカウント、SSHキー、証明書 | 引き渡しと同時に失効・再発行の計画を立てる |
5 | 設計・仕様のドキュメント | 要件定義書、基本設計書、テーブル定義、API仕様 | 「コードが仕様」の状態になっていないかを早めに確認 |
6 | ビルドとデプロイの手順 | CI/CDの設定、リリース手順書、環境変数の一覧 | 属人化している手順は口頭で聞き取って文書化する |
7 | テスト資産 | テストケース、自動テスト、テストデータ | 個人情報を含むテストデータの扱いを決める |
8 | 第三者ライセンス | 利用しているOSS、有償ライブラリ、外部サービスの契約 | 契約名義が相手側だと、そのまま引き継げない場合がある |
9 | 運用中のデータ | 本番データ、ログ、バックアップ | 消去の義務と引き渡しの義務は別。両方を書き分ける |

このうち2・3・4は、解除日を過ぎてからでは交渉の材料がなくなります。最終の支払いと引き渡しを同時履行にする——つまり「引き渡しの確認をもって最終の支払いを行う」と合意書に書いておくのが、実務上いちばん効く手当てです。
次のベンダーへの移行——並走期間を置き、小さな改修で足場を確かめる
引き渡しを受けたら、次は移行です。稼働中のシステムを止めずに移すには、いきなり全面的な開発を任せるのではなく、段階を踏みます。
第1段階は事前診断です。新しいベンダーにソースコードとドキュメントを読んでもらい、構成・依存関係・技術的負債の所在を報告してもらいます。第2段階は並走期間です。可能なら旧ベンダーとの契約を1か月程度重ね、質問できる状態を残します。第3段階は小さな改修です。影響範囲の限られた不具合修正や文言変更から着手し、ビルドからリリースまでの一連の流れが通ることを確かめます。ここまで通れば、本格的な開発に移せます。
移行の手順をさらに詳しく知りたい場合は、「開発会社 乗り換え 引き継ぎ」の記事で、引き継ぐ資産の分類と契約で確認する項目を整理しています。成果物の権利関係が気になる場合は「知的財産 帰属」の記事もあわせてご覧ください。
解除の前に確認する——本当に会社を替える必要があるのか
最後に、順序を1つ戻します。解除は手段であって目的ではありません。相談を受けたとき、私がまず確認するのは「問題は会社にあるのか、要員にあるのか、進め方にあるのか」です。
特定のエンジニアのスキルが合っていないだけなら、交代で解決します。要件が固まらないまま請負で発注したことが原因なら、契約形態を準委任に変えるほうが早い場合があります。逆に、報告が上がってこない、見積もりの根拠を出さない、といった会社としての姿勢に原因があるなら、替えるべきです。自社の問題はどれに当たるでしょうか。次章では、契約を解除せずに体制を変えるという選択肢を、当社の運用を例に説明します。
当社の場合——契約を解除せずに体制を変える選択肢と、引き継ぎやすさの設計

当社はベトナム・ホーチミンを拠点に、日本国内法人・日本法準拠の契約でオフショア開発の体制を提供しています。ここでは、解除を検討している方の判断材料として、当社が体制の変更と引き継ぎをどう設計しているかを説明します。押し売りではなく、契約形態を考えるときの比較対象としてお読みください。
1か月単位のリプレイスメントと約1週間の増員——体制の調整で足りる場合
当社の体制は、日本人PM・ブリッジSEとエンジニアで組むパターンAと、エンジニアのみのパターンBの2つです。1名から契約でき、開始までは最短2週間、増員は約1週間、縮小と交代(リプレイスメント)は1か月単位で対応しています。最小構成は日本人PMをフロントに置いて2〜3人月、月額約80万円〜が目安です。
この設計にしているのは、問題の多くが「会社」ではなく「要員」や「体制」にあるためです。スキルが要件に合っていない、コミュニケーションが噛み合わない、といった理由なら、契約を解除して一から探し直すより、1か月で人を入れ替えるほうが早く、安く済みます。単価は公開しており、実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです(1USD=150円換算目安。円表記は換算の目安で、為替により変動します)。2,000名以上のIT人財データベースから直接アサインしているため、協力会社を挟む仲介マージンが発生しません。
Git標準とドキュメント納品——次に渡すことを前提にした開発体制
もう1つ、解除の相談を受けるたびに痛感するのが、引き継げる状態で開発されているかどうかの差です。当社では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックを品質管理の3点として運用しています。リポジトリは発注企業側の組織で管理していただく形も選べますし、設計書やテーブル定義などのドキュメントも納品物に含めます。
介護記録SaaS「CareViewer」では、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、要件が動くプロダクトを週次の優先順位判断で継続開発しています。このように、日々の意思決定が記録として残る進め方をしておくと、仮に将来どこかで体制を変えることになっても、引き渡しは前章の9項目を順に確認するだけの作業になります。「次に渡せる形で作る」ことは、発注側にとって最も安い保険です。
業務委託契約の解除でよくある質問

業務委託契約の解除について、相談の場で繰り返し聞かれる質問を5つにまとめました。いずれも一般的な情報提供であり、法的助言ではありません。個別の判断は弁護士にご確認ください。
Q1. 契約書に解除条項がなくても、途中で解除できますか?
契約書に定めがなくても、民法の規定によって解除できるとされています。請負は民法641条で注文者が仕事の完成前ならいつでも損害を賠償して解除でき、委任・準委任は民法651条で各当事者がいつでも解除できます。ただし損害賠償の論点が残るため、まずは合意解約の協議から始める進め方が安全です。
Q2. 解除の通知は何日前に出すべきですか?
まず契約書の予告期間を確認してください。30日前・60日前・3か月前など契約によって異なります。相手が従業員を使用しない個人などで、政令で定める期間以上の継続的業務委託に当たる場合は、フリーランス法16条により少なくとも30日前までの予告が必要です。契約書と法令の両方がかかる場合は、長いほうに合わせます。
Q3. 解約通知はメールで出しても有効ですか?
契約書が「書面により」と定めている場合は、その方法に従ってください。フリーランス法の予告については、電磁的方法でも可能とする解説が一般的です。いずれの場合も、送信日時が分かる記録を残し、相手に受信確認を求めてください。争いが予想される場面では、内容証明郵便を使うと送達の証明になります。
Q4. 残りの契約期間分の報酬は、全額支払う必要がありますか?
原則として全額支払う義務はありません。請負は民法634条、委任・準委任は民法648条3項により、既にした仕事や履行の割合に応じた報酬が基本です。ただし契約書に違約金条項がある場合や、解除によって相手に損害が生じた場合は、別途の支払いが問題になることがあります。
Q5. 作りかけのソースコードは引き渡してもらえますか?
契約書の成果物・著作権の条項次第です。著作権の移転時期が「報酬完済時」となっている契約が多く、未払いのままでは引き渡しを求めにくくなります。最終の支払いと引き渡しを同時履行にする合意を先に取り付けるのが実務的な進め方。
まとめ: 3類型を見分け、契約書の6か所を確認し、精算と引き渡しを書面で決める
業務委託契約の解除は、合意解約、債務不履行による解除(民法541条の催告解除・542条の無催告解除)、契約に基づく中途解約(任意解除)の3類型に分かれます。請負は注文者が仕事の完成前ならいつでも損害を賠償して解除でき(民法641条)、委任・準委任は各当事者がいつでも解除できる一方、相手方に不利な時期の解除などは損害賠償の対象になります(民法651条)。つまり争点は可否ではなく金銭です。既にやった分の報酬は請負が民法634条、委任・準委任が648条3項の考え方によります。相手が従業員を使用しない個人などで、政令で定める期間以上の継続的業務委託に当たる場合は、フリーランス法16条により少なくとも30日前までの予告が必要です。
進め方は3ステップです。第1に、自社がどの類型かを見分け、リスクが低い順(不更新→合意解約→一方的な解除)で選ぶ。第2に、契約書の6か所——中途解約の予告期間、既履行部分の報酬、成果物と資料の返還、機密保持の存続、競業避止、損害賠償の範囲——を条番号つきで書き出す。第3に、システム開発なら出来高の評価方法と引き渡し9項目を合意書に落とし、最終の支払いと引き渡しを同時履行にする。この順序を守れば、解除は紛争ではなく手続きになります。なお本記事は一般的な情報提供であり、法的助言ではありません。個別の案件については、契約書を持参のうえ弁護士にご相談ください。
解除を検討する前に、問題が会社にあるのか、要員や体制にあるのかを切り分けてみてください。要員や体制が原因なら、契約を解除せずに交代や増員で解決できる場合があります。当社は1名から契約でき、増員は約1週間、縮小と交代(リプレイスメント)は1か月単位で対応しており、最小構成は日本人PMをフロントに置いて2〜3人月、月額約80万円〜が目安です。移行の手順は開発会社の乗り換えと引き継ぎ、契約そのものの基礎は業務委託契約とはもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、引き継ぎに必要な期間と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。