「今お願いしているエンジニアに、そろそろ別の人へ交代してもらいたい」。レスポンスが遅い、品質が落ちてきた、連絡がつきにくい。不満は積み重なっているのに、いざ交代を考えると手が止まってしまう。多くの発注者がこの状態で立ち往生しています。
その理由ははっきりしています。「このエンジニアしかソースコードの全体像も、サーバーの設定も、仕様も把握していない。辞めてもらったら開発が完全に止まるのではないか」という恐怖です。加えて「いきなり契約を切ったら、トラブルや損害賠償になるのでは」という法的な不安も重なります。結果として、不満を抱えたまま、動けないまま、時間だけが過ぎていきます。
これは、発注者の怠慢ではありません。1人のエンジニアに開発を任せきりにする体制は、構造的に「その人を切れない」状態を生み出します。つまり、あなたが動けないのは、ごく自然なことなのです。
ただし、正しい順番で準備すれば、開発を止めず・揉めず・合法的に、エンジニアを交代させることは十分に可能です。鍵になるのは「いきなり切らない」「先に自社の資産を握る」「フリーランス新法の予告期間から逆算する」という3つの原則です。
本記事では、外注している個人エンジニア（フリーランス・業務委託人材）を別のエンジニアに切り替える手順を、判断の見極めから属人化の解除、フリーランス新法を踏まえた契約解除、開発を止めない引き継ぎ、そして次の人材の確保まで、時系列に沿って解説します。読み終えるころには、明日から着手すべき最初の一歩が明確になっているはずです。
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド
この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
外注エンジニアの切り替えで発注者が直面する3つの壁
開発会社（ベンダー）の乗り換えと、個人エンジニアの交代は、似ているようで難易度がまったく違います。会社相手であれば、担当者が1人抜けても社内に引き継ぎ要員がいたり、ドキュメントが整備されていたりします。しかし個人エンジニア1名に任せていた場合、その人が抱えている情報のすべてが、そのまま「失われるリスク」になります。
本記事が扱うのは、この個人エンジニア（フリーランス・業務委託人材）を別の個人エンジニアに切り替えるケースです。多くの発注者が交代に踏み切れないのは、次の3つの壁が同時に立ちはだかるからです。
属人化の壁｜なぜ「その人を切れない」状態が生まれるのか
最も大きな壁が属人化です。1人のエンジニアに開発・保守を長く任せていると、ソースコードの構造、なぜその実装にしたのかという背景、サーバーやデータベースの設定、外部サービスの連携方法といった情報が、すべてそのエンジニアの頭の中に蓄積されていきます。
ドキュメントが残っていればまだ救いがありますが、小規模な開発ではドキュメント作成が後回しになりがちです。結果として「コードを読んでも何が起きているか分からない」「サーバーにどうログインするのかも分からない」という状態になり、その人を切った瞬間に開発がブラックボックス化します。これが「不満はあるのに切れない」人質状態の正体です。
法的トラブルの壁｜個人との契約解除は会社相手と勝手が違う
2つ目は法的な壁です。2024年11月に施行されたフリーランス新法（正式名称「特定受託事業者に係る取引の適正化等に関する法律」）により、個人事業主・フリーランスへの業務委託には発注者側の義務が定められました。特に6か月以上継続している業務委託を中途解除する場合、原則として30日前までの予告が必要です（政府広報オンライン）。
「明日から来なくていい」という会社員的な感覚で契約を打ち切ると、法令違反になる可能性があります。この点は記事の後半で詳しく整理します。
代替人材の壁｜次のエンジニアを引き継ぎ前提で確保できるか
3つ目は、次を誰に頼むかという壁です。新しいエンジニアを探すだけでも手間ですが、外注先の交代では「既存のコードを読み解いて引き継げる人」を選ぶ必要があります。ゼロから作るのとは別のスキルが求められるため、選定基準も変わってきます。
この3つの壁は、それぞれ独立しているように見えて、実は「どの順番で手をつけるか」で難易度が大きく変わります。次の章から、その順番を1つずつ解説していきます。
切り替えを判断すべきサインと、続けるべきケース
交代を決める前に、一度立ち止まってほしいことがあります。それは「本当に人を変えるべきなのか、それとも依頼の仕方を変えるべきなのか」という問いです。感情的に「もう無理」と切ってしまうと、新しいエンジニアでも同じ問題が再発し、引き継ぎコストだけが二重にかかることになりかねません。
切り替えを検討すべき4つのサイン
次のような状態が常態化している場合は、交代を具体的に検討する段階に来ています。
- レスポンス遅延の常態化: 連絡してから返信まで数日かかる、締め切りの遅延が繰り返される
- 品質の低下: バグが増えた、同じ不具合が再発する、リリース後の手戻りが多い
- 連絡の不通・不透明化: 進捗が見えない、質問への回答が曖昧、稼働状況が把握できない
- コストと成果の乖離: 支払っている金額に対して、開発のスピードや成果が見合っていない
これらが一時的ではなく、改善を求めても変わらない状態が続いているなら、交代の検討は妥当です。
人を変えても解決しないケース（発注側に原因がある場合）
一方で、次のようなケースは人を変えても解決しません。むしろ発注側の進め方に原因があるため、新しいエンジニアでも同じ不満が生じます。
- 要件や仕様が曖昧なまま依頼している: 「いい感じに作って」という依頼では、誰が担当しても期待とのズレが生じます
- コミュニケーション設計がない: 定例ミーティングや進捗共有の仕組みがなく、放置した結果として連絡が滞っている
- 一時的な多忙が原因: 他案件との兼ね合いで一時的に手が回っていないだけで、本来の実力は高い
特に「要件が曖昧」「管理の仕組みがない」場合は、人を変える前にまず依頼の仕方を見直すほうが効果的です。それでも改善しない、あるいは信頼関係そのものが壊れている場合に、はじめて交代という選択肢が現実味を帯びます。安易な切り替えは、二重コストを払うリスクがあることを念頭に置いてください。
契約を切る前にやるべき属人化の解除｜最優先の準備
ここからが本記事の核心です。交代を決めたとしても、いきなり契約解除を伝えるのは最悪手です。なぜなら、その瞬間に相手の協力を得にくくなり、属人化したままの状態で開発が止まるからです。
正しい順番は「先に自社が握っておくべきものを確保する」こと。これを済ませておけば、人質状態が解け、安心して次のステップに進めます。
自社が確保すべき資産チェックリスト（コード・権限・ドキュメント・契約名義）
まず、以下の4カテゴリが「自社の管理下にあるか」を確認してください。現エンジニア個人のアカウントや名義に紐づいたままだと、交代時に詰みます。
1. ソースコード
- GitHub / GitLab などのリポジトリが、自社（または自社管理のアカウント）のオーナー権限になっているか
- リポジトリの所有者がエンジニア個人のアカウントになっている場合、組織アカウントへの移管を依頼する
2. サーバー・ドメイン・各種SaaSのアカウント権限
- AWS・さくらインターネット等のサーバー、ドメイン管理、利用中の外部サービス（決済・メール配信・監視ツール等）の管理者権限が自社にあるか
- 管理者アカウントがエンジニア個人のものになっていないか
3. 仕様書・設計書・環境構築手順・認証情報リスト
- システムの仕様、画面・データベース設計、開発環境を再現する手順
- サーバーへのログイン情報、APIキー、各種パスワードの一覧
4. 外部サービスの契約名義
- ドメインやSaaSの契約が、自社名義になっているか。エンジニア個人のクレジットカードで契約されていると、交代後に支払いやサービス継続でトラブルになります
これらのうち、ひとつでも「現エンジニアしか持っていない」ものがあれば、それが交代を阻む人質です。優先的に自社へ移すことが、最初にやるべき作業です。
「自然な形で」資産を確保する依頼の仕方（角を立てずに権限移管を進める）
ここで注意したいのは、依頼の仕方です。「交代を考えているので権限をください」と切り出すと、相手が身構えて協力を得にくくなります。交代の意思はまだ伏せたまま、通常の運用改善という名目で資産を確保するのが得策です。
たとえば次のような切り口が自然です。
- 「事業継続性（BCP）の観点から、社内でもリポジトリやサーバーを把握しておきたい」
- 「担当者が休んだ場合に備えて、アカウント権限を会社側でも管理できるようにしたい」
- 「監査・セキュリティ対応のため、認証情報を一覧化しておきたい」
これらはどれも、交代の有無にかかわらず本来あるべき体制です。むしろ、こうした体制を整えていなかったこと自体が、属人化を招いた一因でもあります。資産の所在を自社で把握できた段階で、はじめて次の契約解除のステップに進みます。
フリーランス新法を踏まえた契約解除の進め方
属人化の解除に目処が立ったら、いよいよ契約解除の準備に入ります。ここで必ず押さえておきたいのが、2024年11月施行のフリーランス新法です。「いきなり切ってトラブルになる」という不安は、ルールを知れば計画的に回避できます。
フリーランス新法で発注者に課される中途解除のルール（30日前予告・理由開示）
フリーランス新法では、6か月以上継続している業務委託を中途解除する場合、または契約を更新しない場合、発注者は原則として30日前までに予告しなければなりません。予告は書面・FAX・電子メール等の方法で行う必要があります（政府広報オンライン）。
さらに、予告の日から契約満了までの間に、フリーランス側が解除・不更新の理由の開示を請求した場合、発注者はその理由を開示する義務があります（公正取引委員会 フリーランス法特設サイト）。
このルールが、実は切り替えスケジュールを設計する上での起点になります。30日前予告が義務である以上、新しいエンジニアへの引き継ぎ期間を確保するためには、現エンジニアへの予告タイミングを引き継ぎ完了時期から逆算して決める必要があります。たとえば「2週間の並走引き継ぎを行いたい」なら、その並走期間と予告期間を見込んで、余裕を持ったスケジュールを組むことになります。法律上の義務が、結果的に「拙速な交代を防ぐ安全装置」として機能するわけです。
予告不要で即時解除できるケース
ただし、30日前予告にはいくつかの例外があります。次のような場合は即時解除が認められうるとされています（植野法律事務所）。
- 業務委託の期間が30日以下など、短期間である場合
- フリーランスの責めに帰すべき事由がある場合（重大な契約違反など）
- 災害その他やむを得ない事由により業務委託の継続が困難な場合
注意したいのは、「品質が少し低い」「レスポンスが遅い」といった不満が、ただちに「責めに帰すべき事由」として即時解除を正当化するとは限らない点です。即時解除が可能かどうかの判断は個別性が高く、安易に「相手に非があるから即解除できる」と考えるのは危険です。原則は30日前予告と捉え、即時解除を検討する場合は弁護士など専門家への確認をおすすめします。
契約書で確認すべき解除条項・成果物の権利帰属
契約解除の前に、現在の契約書も必ず読み返してください。確認すべきポイントは次の通りです。
- 解除条項: 解除の手続き、予告期間、違約金の有無
- 成果物の権利帰属（著作権）: 開発したソースコードの著作権が自社に譲渡される取り決めになっているか。ここが曖昧だと、交代後にコードの利用を巡ってトラブルになりかねません
- 秘密保持義務: 退任後の情報の取り扱い
もし契約書を交わしておらず、口頭やチャットだけで進めてきた場合は、この機会に取り決めを文書化しておくことが、今後のトラブル防止につながります。
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド
この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
開発を止めない引き継ぎの段取り｜並走期間の設計
検索者の最大の不安「交代したら開発が止まる」を実務的に解消するのが、この引き継ぎフェーズです。鉄則は、旧エンジニアと新エンジニアの並走期間を設けること。一斉に切り替えるのではなく、重なり合う期間を作って段階的に移行します。
並走期間の設計と期間の目安
並走期間とは、旧エンジニアがまだ稼働している間に新エンジニアが参加し、知識を引き継ぐ期間です。この期間があれば、新エンジニアは「分からないことをその場で旧エンジニアに質問できる」状態になり、引き継ぎの抜け漏れを大きく減らせます。
期間の目安は、システムの規模や複雑さによりますが、おおむね2週間〜1か月程度を見込むとよいでしょう。小規模なツールなら数日で済むこともありますし、複数システムが絡む複雑な開発では1か月以上かかることもあります。重要なのは「ゼロ並走」を避けることです。
引き継ぎ資料に最低限含めるべき項目
並走期間中に、新エンジニアへ渡すべき情報を整理します。最低限、次の項目をまとめておきましょう。
- リポジトリ情報: ソースコードの場所、ブランチ運用ルール
- 環境構築手順: 開発環境・本番環境を再現する手順
- インフラ構成: サーバー・データベース・外部サービスの構成と接続情報
- タスク・課題の状況: 進行中の作業、既知の不具合、未対応の要望
- 運用ルール: デプロイ手順、定期メンテナンス、監視体制
- 関係者の連絡先: 外部サービスのサポート窓口、関連する取引先
これらは、前章で確保した自社資産と重なる部分が多くあります。属人化の解除を先に済ませておけば、この引き継ぎ資料の作成もスムーズに進みます。
旧エンジニアに引き継ぎ協力を依頼するときの注意（報酬・態度）
引き継ぎは、旧エンジニアの協力なしには成り立ちません。ここで重要なのが、引き継ぎ工数も正式な委託業務として扱い、相応の報酬を支払うことです。
「最後だから無償で」という姿勢は、相手のモチベーションを下げ、形だけの引き継ぎに終わるリスクがあります。引き継ぎ作業を契約上の業務として明示し、対価を払うことで、旧エンジニアも責任を持って情報を渡してくれます。
また、たとえ不満があって交代する場合でも、最後まで誠実な態度で接することが大切です。エンジニアの世界は意外と狭く、悪い評判は巡るものです。円満に引き継ぎを終えることが、結果的に自社のリスクを最小化します。
次のエンジニアを引き継ぎ前提で確保する方法
最後の壁が、代替人材の確保です。ここでのポイントは、「新規開発ができる人」ではなく「既存のコードを引き継げる人」を選ぶこと。求めるスキルが少し異なります。
代替人材の探し方3パターン
代替人材を探す主な経路は、次の3つです。それぞれに特徴があります。
- フリーランス・複業マッチングプラットフォーム: スキルや実績を確認した上で、比較的短期間で人材にアクセスできます。引き継ぎ可能なスキルを持つ人材を、条件を絞って探せるのが利点です
- 知人・既存取引先からの紹介: 信頼性は高いものの、タイミングよく適任者が見つかるとは限りません。選択肢が限られる点に注意が必要です
- エージェント（人材紹介会社）: 要件を伝えれば候補者を提案してもらえます。仲介手数料がかかりますが、選定の手間を軽減できます
外注先の交代という緊急性のある場面では、必要なスキルを持つ人材に短期間でアクセスできるかどうかが重要になります。フリーランス・複業人材のマッチングプラットフォームは、こうした「引き継ぎ可能なスキルを持つ人を、すぐに探したい」というニーズに合った選択肢の一つです。
引き継ぎを任せられるエンジニアの選定基準
既存システムの引き継ぎでは、ゼロから作る力よりも、他人が書いたコードを読み解く力が問われます。選定時には次の点を確認するとよいでしょう。
- 既存コードの読解・改修経験: 他人のコードを引き継いで開発した実績があるか
- ドキュメントが薄い前提での立ち上がり力: 仕様書がほとんどない状態でも、コードを追って全体像を把握できるか
- コミュニケーション能力: 引き継ぎ期間中、不明点を整理して質問できるか。発注者にも分かる言葉で説明できるか
面談時には「過去にドキュメントの少ないシステムを引き継いだ経験」を具体的に聞いてみると、対応力が見えてきます。
再発防止｜一人依存をやめる体制設計
そして最も大切なのが、再び同じ属人化に陥らない体制を作ることです。せっかく交代しても、新しいエンジニア1人に再び任せきりにすれば、数年後にまったく同じ問題が起きます。
再発防止のために、次のような工夫を検討してください。
- アカウント権限を常に自社で保持する: リポジトリ・サーバー・SaaSの管理者権限は、最初から自社の組織アカウントで持つ
- ドキュメントを成果物に含める: 開発業務の中に「仕様・手順のドキュメント化」を組み込み、知識が個人に閉じないようにする
- 複数人体制やバックアップ要員を検討する: 1人依存をやめ、最低限のレビュー体制や代替要員を確保する
今回の交代を、属人化体質そのものを見直す好機と捉えることで、長期的な開発リスクを大きく下げられます。
よくある質問（FAQ）
Q. 契約書を交わしていない（口頭・チャットのみ）場合でも切り替えられますか？
切り替えは可能ですが、リスクは高くなります。成果物の著作権や解除条件が明文化されていないため、コードの利用や引き継ぎを巡ってトラブルになりやすいからです。まずは前章で挙げた自社資産（コード・権限・ドキュメント）を確保し、可能であれば現時点からでも簡易な合意書を交わしておくことをおすすめします。なお、契約書がなくてもフリーランス新法の予告ルールは適用されうるため、6か月以上の継続取引では30日前予告を前提に進めてください。
Q. ソースコードを渡してもらえない、アカウント権限を移してもらえない場合はどうすればいいですか？
まず、契約書に成果物の権利帰属や引き継ぎ義務が定められていれば、それを根拠に交渉します。条項がない場合は、引き継ぎ作業を有償の業務として依頼し、対価を提示することで協力を引き出せることが多いです。それでも応じない場合は、トラブルに発展する可能性があるため、弁護士など専門家への相談を検討してください。こうした事態を防ぐためにも、交代を切り出す前に資産を確保しておくことが重要です。
Q. フリーランス新法の30日前予告を守らないとどうなりますか？
フリーランス新法は発注者に各種義務を課しており、違反した場合は公正取引委員会等による指導・助言、勧告、命令の対象となりえます（公正取引委員会 フリーランス法特設サイト）。罰則を避けるためにも、6か月以上の継続取引では原則30日前予告を守り、スケジュールを逆算して計画的に進めてください。
Q. 引き継ぎ期間中に旧エンジニアが非協力的になったらどうすればいいですか？
引き継ぎ工数を正式な有償業務として位置づけ、対価を支払うことが前提です。それでも協力が得られにくい場合に備え、並走期間の早い段階で重要な情報（リポジトリ・インフラ構成・認証情報）から優先的に引き継ぐようにします。最初に「詰まると困るもの」を押さえておけば、万一非協力的になっても被害を最小化できます。
Q. 個人エンジニアより、開発会社に切り替えるべきですか？
これは状況によります。継続的な開発・保守が必要で、属人化を避けたいなら、複数人体制を持つ開発会社への切り替えも有力な選択肢です。一方、小規模で予算を抑えたい場合や、特定のスキルにピンポイントで頼みたい場合は、個人エンジニアのほうが機動的です。「再発防止」の観点では、誰に頼むにせよ、自社で資産とドキュメントを握る体制を整えることが共通して重要になります。
まとめ｜切り替えは「順番」で決まる
外注エンジニアの切り替えがうまくいくかどうかは、能力や運ではなく「順番」で決まります。本記事で解説した流れを、改めて時系列で整理します。
- 判断: 感情ではなく客観的なサインで交代の要否を見極める。発注側に原因がある場合は依頼の仕方を先に見直す
- 属人化の解除: いきなり切らず、先にコード・権限・ドキュメント・契約名義を自社へ確保する
- 法的準備・予告: フリーランス新法の30日前予告を起点に、スケジュールを逆算する。契約書の解除条項・権利帰属を確認する
- 並走引き継ぎ: 旧・新エンジニアの並走期間を設け、有償で誠実に引き継ぐ
- 代替確保: 既存コードを引き継げる人材を選び、再発防止の体制を設計する
押さえるべき原則は3つだけです。「いきなり切らない」「先に自社資産を握る」「30日前予告から逆算する」。この3つを守れば、開発を止めず・揉めず・合法的に、エンジニアを交代できます。
まずやるべき最初の一歩は、難しいことではありません。今のシステムのソースコード・サーバー・各種アカウントの権限が、誰の名義で、どこにあるのかを確認すること。ここから始めれば、長く続いた人質状態は確実にほどけていきます。
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド
この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
