外注で作ったMVPを社内チームに引き継ぐときに最も大切なのは、ソースコードを受け取ることではなく、「社内のメンバーが一人で変更を加え、安全に公開できる状態」をゴールに置くことです。そのためには、権限とアカウントの移管、最低限のドキュメント、そして外注先と社内チームが一緒に作業する並走期間の3つをセットで計画する必要があります。コードと資料を一度に渡して終わりにすると、引き継ぎの後に小さな変更ひとつで何日も止まる、ということが起こります。
この記事は、外部の開発会社やフリーランスに作ってもらったMVPを、社内のエンジニアチームで育てていこうとしている事業責任者、エンジニアリングマネージャー、引き継ぎを受ける側のエンジニアに向けて書いています。引き継ぎの全体像、移すべきものの一覧、並走期間の進め方、権限移管の手順、外注先との契約上の確認点、よくある失敗とチェックリストまでを整理しました。
読み終えるころには、外注から内製への引き継ぎの計画を立てられ、外注先と社内チームの双方が無理なく進められる段取りが分かるはずです。
外注から内製へ移るタイミングと目的
MVPの段階では、スピードを優先して外部の力を借りることがよくあります。検証の結果、事業として続けることが決まると、次のような理由で内製への切り替えが検討されます。
- 改善の頻度が上がり、外部とのやり取りに時間がかかるようになった
- 事業の中核となる技術や知識を、社内に蓄積したい
- 長期的に見て、社内にエンジニアを抱えるほうが効率的になった
- 事業の方針を開発に素早く反映できる体制を作りたい
ただし、内製に切り替えること自体が目的ではありません。社内のエンジニアが確保できていない、確保できても事業の速度に見合わない、という状況なら、外注を続ける、または外注と内製を組み合わせるほうが合理的なこともあります。段階に応じた体制の考え方は内製化か外注かの判断で解説しています。内製化は一度に切り替えるものではなく、段階的に移していくものと考えるのが現実的です。
引き継ぎのゴールを決める
引き継ぎの計画を立てる前に、ゴールを具体的に決めます。おすすめは、次の状態を引き継ぎの完了条件とすることです。
- 社内のエンジニアが、外注先の手を借りずに、小さな機能の追加や不具合の修正を行い、本番環境に公開できる
- 本番環境で障害が起きたときに、社内のメンバーだけで状況を把握し、一次対応ができる
- すべての外部サービスとインフラの管理者が社内のアカウントになっている
- 次に何をどう変えればよいかを判断するための資料が揃っている
この完了条件を外注先と共有しておくと、引き継ぎの範囲と期間の認識がそろいます。
引き継ぐべきものの一覧
引き継ぎで移すべきものは、大きく「資産」「権限」「知識」の3つに分けられます。
| 分類 | 引き継ぐもの | 確認のポイント |
|---|---|---|
| 資産 | ソースコード一式と変更履歴 | すべてのリポジトリが揃っているか。履歴ごと移せるか |
| 資産 | 設計資料・仕様の記録 | 画面一覧、データ構造、外部サービスの一覧、判断の記録 |
| 資産 | インフラの構成と設定 | 構成図、環境ごとの設定、設定をコードで管理しているか |
| 資産 | テストと公開の手順 | 自動テスト、公開の手順、環境の作り方 |
| 権限 | クラウドのアカウント | 契約名義、管理者、請求先 |
| 権限 | 外部サービスのアカウント | 決済、認証、メール配信、分析ツールなど |
| 権限 | ドメインと証明書 | 登録者、更新の期限、DNSの管理 |
| 権限 | アプリストアなどの開発者アカウント | アプリがある場合の名義と管理者 |
| 権限 | 秘密情報 | APIキー、パスワード、証明書の保管場所と更新方法 |
| 知識 | 設計の意図と経緯 | なぜその構成・その技術を選んだか |
| 知識 | 既知の問題と技術的な負債 | 後回しにしていること、壊れやすい箇所 |
| 知識 | 運用の手順 | 定期作業、障害時の対応、問い合わせ対応 |
ソースコードと変更履歴
ソースコードは、最終版のファイル一式ではなく、変更の履歴ごと受け取ります。Gitなどのバージョン管理の履歴には、いつ、なぜ、その変更をしたのかという情報が残っています。リポジトリを外注先のアカウントで管理している場合は、自社のアカウントへ履歴ごと移します。
ソースコードの権利がどちらにあるかは、契約の内容によって決まります。引き継ぎの前に契約を確認し、必要であれば権利の扱いを明確にしておきます。詳しくはソースコードの著作権と権利帰属を参照してください。
設計資料と仕様の記録
MVPでは、詳細な設計書がないことも珍しくありません。その場合でも、画面の一覧、主なデータの構造、使っている外部サービスの一覧、設計の判断の記録は、引き継ぎの前に外注先に作成を依頼します。どこまで残すべきかはMVP開発の仕様書はどこまで書くかの考え方が参考になります。
既知の問題と技術的な負債
MVPは、スピードを優先して作られているため、後回しにした部分や、本来は作り直すべき箇所が必ずあります。外注先にとっては言いにくい情報ですが、引き継ぐ側にとっては最も価値のある情報の一つです。「責める意図はない」ことを伝えたうえで、正直に一覧にしてもらいます。
並走期間の進め方
引き継ぎを成功させる鍵は、外注先と社内チームが一緒に作業する並走期間です。資料の受け渡しだけでは伝わらない知識を、実際の作業を通じて移します。
並走期間の段階
並走期間は、次の3つの段階に分けて進めます。
| 段階 | 主に作業する人 | 内容 |
|---|---|---|
| 見て学ぶ | 外注先が作業、社内が観察 | 外注先が普段の改修や公開の作業を行い、社内のエンジニアが横で見て質問する |
| やって確かめる | 社内が作業、外注先が支援 | 社内のエンジニアが小さな改修を担当し、外注先がレビューと助言を行う |
| 任せて見守る | 社内が作業、外注先は待機 | 社内だけで改修と公開を行い、困ったときだけ外注先に相談する |
それぞれの段階の期間は、システムの大きさと社内のエンジニアの経験によって変わります。大切なのは、段階を飛ばさないことです。いきなり「任せて見守る」から始めると、社内のエンジニアが分からないことを抱え込み、時間だけが過ぎていきます。
並走期間に行う作業の選び方
並走期間に扱う作業は、引き継ぎの練習として適したものを選びます。
- 画面の文言の変更など、影響が小さく、公開までの流れを一通り体験できる作業
- 小さな機能の追加など、データの構造やコードの全体像を理解する必要がある作業
- 外部サービスとの連携部分の修正など、壊れやすい箇所に触れる作業
- 障害の訓練など、本番環境での対応を体験する作業
最初の作業として、公開までの一連の流れを社内のエンジニアだけで実行してみることを強くおすすめします。手元で開発環境を作り、変更を加え、確認用の環境で動作を確かめ、本番に公開する。この流れが一人でできれば、引き継ぎの半分は終わったと言えます。
進み具合を確かめる方法
並走期間が順調に進んでいるかは、感覚ではなく具体的な事実で確かめます。社内のエンジニアが外注先に質問した回数と内容を記録しておくと、質問の内容が「どこに何があるか」から「この設計で問題ないか」へと変わっていく様子が分かります。前者の質問が減らない場合は、資料が足りていないか、並走の段階を早く進めすぎている合図です。また、社内のエンジニアが担当した改修について、レビューでの指摘の数や公開までにかかった時間を見ておくと、次の段階に進んでよいかを判断しやすくなります。週に一度、外注先と社内チームで振り返りの時間を取り、分からないことが残っている領域を一覧にして、次の週の作業に反映します。
外注から内製への引き継ぎの手順
全体の手順は次のとおりです。
- 引き継ぎのゴールと完了条件を決め、社内の関係者と外注先に共有する
- 外注先との契約を確認し、引き継ぎ作業の範囲、期間、費用、成果物の権利を合意する
- 引き継ぐもの（資産・権限・知識）の一覧を作り、外注先に確認してもらう
- 社内のエンジニアの受け入れ準備をする（開発に使う端末、ツールのアカウント、参加する人の時間の確保）
- ソースコードのリポジトリを、自社のアカウントへ履歴ごと移す
- 外注先に、設計資料、外部サービスの一覧、既知の問題の一覧の作成を依頼する
- 社内のエンジニアが手元に開発環境を作り、手順書どおりに動くかを確認する。詰まった箇所は手順書に追記する
- 並走期間の「見て学ぶ」段階を始め、外注先の作業を社内が観察し、質問する
- 「やって確かめる」段階に移り、社内が小さな改修を担当し、外注先がレビューする
- クラウド、外部サービス、ドメインなどの権限を、社内のアカウントに移す
- 秘密情報（APIキーやパスワード）を新しいものに更新し、外注先のアクセスを整理する
- 「任せて見守る」段階に移り、社内だけで改修と公開を行う
- 完了条件を満たしていることを確認し、外注先との問い合わせ対応の期間と方法を決めて、引き継ぎを終える
手順10と11の順番が重要です。権限の移管は、並走期間の途中で行います。最初に権限を移してしまうと、外注先が作業できなくなり、並走が成り立ちません。逆に最後まで移さないと、引き継ぎが終わった後も外注先のアカウントに依存したままになります。
権限の移管で注意すること
権限の移管では、次の点に注意します。
- クラウドや外部サービスの契約名義が外注先になっている場合は、名義の変更や、新しい契約への移行が必要になることがある。サービスによって手続きが異なるため、早めに確認する
- 移管の作業は、利用者への影響が少ない時間帯に行い、作業の前にバックアップを取る
- 移管が終わったら、外注先のアカウントの権限を、並走に必要な範囲まで縮小する
- 引き継ぎが完了したら、外注先のアクセス権を削除し、共有していた秘密情報をすべて新しいものに更新する
- ドメインや証明書の更新の期限を確認し、社内の担当者に通知が届くようにする
秘密情報の更新を忘れると、引き継ぎが終わった後も、外部の人が本番環境にアクセスできる状態が残ります。これは外注先を疑っているからではなく、管理の基本として必要な作業です。
外注先との契約と関係で確認すること
引き継ぎを円滑に進めるには、外注先の協力が欠かせません。外注先にとって、引き継ぎは自社の仕事が減る作業でもあります。協力を得るために、次の点を最初に確認します。
- 引き継ぎ作業の費用：資料の作成や並走期間の作業は、通常の開発とは別の作業です。範囲と費用を明確にして合意します
- 成果物の権利：ソースコードや資料の権利が、契約上どちらにあるかを確認します
- 外注先が使っている独自の部品：外注先が他の案件でも使っている独自のライブラリや仕組みが含まれている場合、その扱いを確認します
- 引き継ぎ後の問い合わせ：引き継ぎの後、一定期間は質問に答えてもらえるか、その費用はどうするかを決めます
- 今後の関係：完全に関係を終えるのか、一部の作業を引き続き依頼するのかを決めます
外注先を途中で変更する場合の引き継ぎについては開発会社を途中で変更するときの引き継ぎでも整理しています。内製への引き継ぎと、別の会社への引き継ぎは、確認すべき項目の多くが共通しています。
架空の例：飲食店の予約サービスの内製化
ある架空の会社が、飲食店向けの予約サービスのMVPを外部の開発会社に作ってもらい、検証の結果、事業として続けることを決めました。社内に2名のエンジニアを採用し、内製に切り替えることにしました。
最初の計画では、ソースコードと資料を受け取り、1週間で引き継ぎを終える予定でした。しかし、社内のエンジニアが手元に開発環境を作ろうとしたところ、手順書が古く、外注先の担当者の端末でしか動かない設定が含まれていることが分かりました。また、決済サービスとメール配信のアカウントが外注先の名義で契約されていました。
会社は計画を見直し、外注先と合意して、並走期間を設けました。最初の段階では外注先の担当者が普段の改修を画面共有で見せ、社内のエンジニアが質問しながら手順書を書き直しました。次の段階では社内のエンジニアが予約画面の小さな改修を担当し、外注先がレビューしました。その間に、決済とメール配信のアカウントを自社名義の契約に移しました。最後の段階では、社内だけで改修と公開を行い、困ったときだけ外注先に相談する形をとりました。
結果として、当初の計画より時間はかかりましたが、引き継ぎの後に社内だけで改修を続けられる状態を作ることができました。
よくある失敗と避け方
- 資料とコードを受け取って終わりにする：資料では伝わらない知識が多く、引き継ぎの後に改修が止まります。並走期間を必ず設けます。
- 手元で開発環境を作れるか確認しない：外注先の環境でしか動かない設定が含まれていることがあります。引き継ぎの早い段階で、社内のエンジニアが手順書どおりに環境を作れるかを確かめます。
- 権限の移管を後回しにする：外部サービスの名義が外注先のままだと、関係が終わった後に手続きが難しくなります。並走期間中に移管します。
- 秘密情報を更新しない：引き継ぎの後も外部の人がアクセスできる状態が残ります。完了時にすべて更新します。
- 既知の問題を聞かない：後から壊れやすい箇所に気づき、思わぬ障害につながります。最初に正直に一覧にしてもらいます。
- 外注先との関係を悪くする：引き継ぎの途中で関係がこじれると、必要な情報が得られなくなります。引き継ぎ作業の費用と範囲を明確にし、敬意を持って協力をお願いします。
- 社内のエンジニアの時間を確保しない：社内のエンジニアが他の仕事と兼務で引き継ぎを受けると、並走期間が形だけになります。引き継ぎに使う時間を計画的に確保します。
外注から内製への引き継ぎチェックリスト
- 引き継ぎのゴールと完了条件を決め、外注先と共有した
- 引き継ぎ作業の範囲、期間、費用、成果物の権利を外注先と合意した
- ソースコードを変更履歴ごと自社のアカウントに移した
- 画面一覧、データ構造、外部サービスの一覧、判断の記録を受け取った
- 既知の問題と技術的な負債の一覧を受け取った
- 社内のエンジニアが、手順書どおりに手元の開発環境を作れた
- 社内のエンジニアが、一人で変更を加えて本番に公開できた
- クラウド、外部サービス、ドメイン、証明書の名義と管理者を社内に移した
- 秘密情報を新しいものに更新し、外注先のアクセスを整理した
- 障害時の一次対応を、社内のメンバーだけで行えることを確認した
- 引き継ぎ後の問い合わせの期間と方法を決めた
チェックが付かない項目が残っている場合は、外注先との関係を終える前に対応します。特に、名義の移管と秘密情報の更新は、関係が終わった後では手続きが難しくなることがあるため、優先して片付けます。
よくある質問
Q. 並走期間はどれくらい必要ですか？
システムの大きさ、社内のエンジニアの経験、資料の整備状況によって変わります。期間を先に決めるより、完了条件を満たすまで段階を進める、という考え方のほうが確実です。目安として、各段階で少なくとも一度は公開までの流れを体験できる期間を確保します。
Q. 外注先が引き継ぎに協力してくれない場合はどうすればよいですか？
まず契約の内容を確認し、引き継ぎ作業の範囲と費用について改めて話し合います。それでも協力が得られない場合は、受け取れる資産をもとに、社内のエンジニアや別の開発会社がコードを読み解いて状況を把握する必要があります。契約の解釈が問題になる場合は、専門家に相談してください。
Q. 内製化の後も、外注先に一部を任せてもよいですか？
構いません。たとえば、インフラの運用や、特定の専門的な機能の開発だけを引き続き外部に依頼する形はよくあります。その場合は、どの作業を誰が担当するのかを明確にし、資産と権限は社内が持つ形にしておきます。
Q. 引き継ぎを機にコードを作り直すべきですか？
引き継ぎの直後に大きな作り直しを始めるのは、おすすめしません。まずは引き継いだコードを理解し、社内で改修できる状態を作ることを優先します。そのうえで、改修を続ける中で作り直すべき箇所が明確になったら、計画的に進めます。
Otsumuに相談できること
社内に経験のあるエンジニアがいて、外注先との関係も良好な場合は、この記事の手順とチェックリストを使って、自社で引き継ぎを進めることができます。まずは引き継ぎの完了条件を決め、外注先と共有するところから始めてみてください。
一方で、社内のエンジニアがまだ少なく、引き継ぎを受ける体制が整っていない、引き継ぐべき資料が揃っておらず現状の把握から始める必要がある、内製と外注をどう組み合わせるべきか判断できない、といった場合は、外部の力を借りたほうが早く進むことがあります。
Otsumuは、構想から開発・運用・改善まで一気通貫で手がけてきた実践者として、引き継ぎを前提にしたMVPの開発と、社内チームへの移行の支援を行っています。新規事業の爆速MVPシステム開発では、AIを活用した少人数・短期間の開発に加え、内製化を見据えた資料の整備や並走期間の設計を支援します。既存システムの現状把握や保守の引き継ぎについてはシステム保守・運用のページでも紹介しています。
引き継ぎの計画づくりから相談したい、という段階でも構いません。30分の無料相談でお気軽にご相談ください。
この記事のテーマに最も近い支援は、開発会社選定・発注者支援です。
- RFPと比較表で、見積もりをそろえる
- 準委任・請負など契約形態の違いを整理
- 外注から内製への引き継ぎまで見据える
まずは30分の無料相談で、状況をお聞かせください。
この記事のテーマに近い開発メニューは、他社開発システムの引き継ぎ・コード診断です。
- 診断で、現状とリスクを見える化
- ドキュメントがなくても読み解く
- 保守・改修を安全に引き継ぐ
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01