受託開発から内製化へ移行する手順｜契約整理・引き継ぎ成果物・並走期間の実務チェックリスト

執筆：Swooo編集部／監修：諸藤 哲耀（株式会社アイビス Swooo）

受託開発から内製化への移行は、「内製化するかどうか」を決めた後が本番です。現行の開発会社との契約をどう整理するか、引き継ぎで何を受け取るか、旧体制と新体制をどれだけの期間並走させるか。この実務設計を誤ると、システムは動いているのに誰も直せない、という状態に陥ります。

この記事は、内製化の方針がすでに固まっている（あるいは固まりつつある）企業のIT部門・情報システム・DX推進担当の方に向けて、移行の実務手順を5つのフェーズに分け、契約整理の論点、引き継ぎで受け取るべき成果物のチェックリスト、並走期間の設計方法まで具体的に整理したものです。
「そもそも内製化すべきか」「どの領域を内製に寄せるか」という判断そのものについては、システム開発の内製化ガイドで扱っています。本記事は「決めた後」の実行編です。

先に全体像を示します。移行は次の5フェーズで進みます。

合計すると、棚卸しの開始から自走まで6ヶ月〜1年程度を見込むのが現実的です。順に見ていきます。

移行計画の大原則：契約終了日から逆算しない

各フェーズに入る前に、移行計画全体を貫く原則をひとつ確認しておきます。「契約終了日」を先に固定して、そこから逆算で引き継ぎを詰め込まないことです。

失敗する移行の多くは、「来期からは内製に切り替えるので、保守契約は年度末で終了」というように、期日が先に決まっています。期日が固定されると、引き継ぎの完了度に関係なく契約が切れます。ドキュメントの受領が半分でも、内製チームが一度も本番リリースを経験していなくても、その日でベンダーのサポートは終わります。

安全な組み立ては逆です。「引き継ぎの完了条件」と「並走期間の卒業基準」を先に定義し、それを満たしたら契約を終了するという条件ベースの計画にします。予算の都合で最終期限を置く場合でも、期限と完了条件の両方を管理し、期限が近づいた時点で完了条件が満たせていなければ、契約の部分延長を協議できる余地を残しておきます。

もうひとつ、全フェーズに共通する姿勢として、現行の開発会社を「切る相手」ではなく「引き継ぎの協力者」として扱うことを勧めます。引き継ぎの質は、ベンダー側の協力度に大きく左右されます。移行後も繁忙期のスポット依頼や技術相談で関係が続くケースは珍しくありません。内製化の意向は隠さず、ただし敬意を持って伝えるのが、実務上もっとも得の多い進め方です。

フェーズ1：棚卸し——移行前に可視化すべき3つの領域

最初のフェーズは、自社が「何を、どんな条件で、誰に」預けているのかの可視化です。棚卸しの対象は3つの領域に分かれます。

1. システム資産の棚卸し

移行対象のシステムそのものと、その依存関係を一覧にします。

• システム一覧：対象システムの名称、役割、利用部署、利用者数、事業への影響度
• 外部依存：連携している外部API・SaaS、決済や認証などの外部サービス、それぞれの契約名義（自社名義か、ベンダー名義か）
• インフラ：サーバー・クラウドの契約主体、ドメインとDNSの管理者、SSL証明書の更新者
• ライセンス：有償のライブラリ・ツール・プラグインと、その契約者

ここでとくに重要なのが契約名義の確認です。クラウドやドメイン、外部APIの契約がベンダー名義になっているケースは多く、名義がベンダー側にあるものは、契約終了と同時にアクセスできなくなるリスクを抱えています。名義の移管には外部サービス側の手続きが必要で、時間がかかるものもあるため、棚卸しの段階で洗い出しておきます。

2. 契約の棚卸し

現行ベンダーと交わしているすべての契約書を集めて、次の項目を確認します。

• 契約の種類と範囲：開発契約（請負か準委任か）、保守運用契約、SLAの有無
• 契約期間と更新条件：自動更新の有無、解約を申し入れる場合の予告期間
• 成果物と権利の定め：納品物の範囲、ソースコード・ドキュメントの著作権の帰属、利用許諾の範囲
• 終了時の義務：データの返却・消去、引き継ぎ協力に関する条項の有無

この段階でよくあるのが「契約書が見つからない」「担当者の交代で経緯がわからない」という事態です。移行の協議はすべて契約書の記載が起点になるため、原本の確保だけは最優先で進めてください。

3. 暗黙知の棚卸し

見落とされがちなのが、ドキュメントに書かれていない知識の所在です。「障害のときはベンダーの◯◯さんに電話すれば直る」という状態は、裏を返せば、障害対応の手順とノウハウが◯◯さんの頭の中にしかないということです。

棚卸しでは、過去1年の問い合わせ・障害対応の記録を集め、「どんな事象で、誰が、何をして解決したか」を一覧にします。この一覧は、フェーズ3の引き継ぎで「何をヒアリングすべきか」のリストにそのまま転用できます。

フェーズ2：契約整理——現行ベンダーとの間で確認すべき論点

棚卸しで現状が見えたら、契約面の整理に入ります。先にお断りしておくと、ここで挙げる論点の結論はすべて「契約内容によります」。一般論として何を確認すべきかの整理であり、個別の判断は契約書の記載と、必要に応じて法務部門や弁護士への相談を前提にしてください。

検収と契約不適合責任：不具合対応の「期限」を把握する

まず確認したいのは、過去の開発案件の検収状況と、不具合が見つかった場合の責任範囲です。
請負契約では、納品物に契約内容と合わない不具合があった場合、開発会社に修補などを求められる「契約不適合責任」（2020年の民法改正前は「瑕疵担保責任」と呼ばれていたもの）の定めが置かれるのが一般的です。

移行の文脈で重要なのは、この責任には期間の定めがあることです。期間や範囲は契約書ごとに異なりますが、契約や法律の定めにより期間が区切られているのが通常です。移行後に発見された不具合を旧ベンダーに対応してもらえるかどうかは、この期間内かどうかに左右されます。
実務上は、「移行前に集中的な動作検証を行い、不具合は責任期間内に洗い出しておく」のが定石です。引き継ぎ検証（フェーズ3）を責任期間と突き合わせてスケジュールしてください。

ソースコードとドキュメントの権利：もらえるか、直せるか

内製化の移行でもっとも見落とされやすいのが、この論点です。開発費を払っていても、ソースコードの著作権が自動的に発注側へ移るとは限りません。著作権の帰属は契約の定めによって決まり、契約書に「著作権は開発会社に留保し、発注者には利用を許諾する」という形の条項が置かれているケースも一般的にあります。

内製化にあたって確認すべきは、権利の名義そのものよりも、実務上の可否です。

• ソースコード一式の引き渡しを受けられるか（納品物の定義にソースコードが含まれているか）
• 自社（または自社が依頼する第三者）がコードを改変してよいか：利用許諾の範囲に「改変」が含まれるか。著作者人格権の不行使条項があるか
• 開発会社の共通部品・フレームワークが含まれていないか：ベンダーが他案件でも使う独自部品は、引き渡しや改変の対象外とされている場合があります
• OSS・サードパーティライブラリのライセンス：コードに含まれる外部ライブラリの利用条件は、ベンダーとの契約とは別に存在します

契約書にこれらの定めがない、あるいは内製化に不利な定めになっている場合でも、協議で引き渡しや改変許諾に合意できるケースは多くあります。その場合は口頭ではなく、覚書などの書面で合意内容を残すのが原則です。判断に迷う条項があれば、この段階で専門家に確認してください。契約形態の基礎は開発契約ガイド（請負と準委任の使い分け）でも整理しています。

保守契約の終了条件と、引き継ぎ協力の位置づけ

保守契約については、解約の予告期間と自動更新の条件を確認します。予告期間を過ぎてから申し入れると契約が次の期間へ自動更新され、移行スケジュール全体が後ろ倒しになるため、棚卸しの段階でカレンダーに落とし込んでおきます。

あわせて押さえておきたいのは、「引き継ぎへの協力」は、契約に定めがなければベンダーの義務とは限らないという点です。ドキュメントの追加作成、後任チームへの説明会、質疑応答の窓口。これらは既存の保守契約の範囲外であることが多く、その場合は引き継ぎ支援を有償の業務として別途合意するのが現実的です。

引き継ぎ費用を「余計な出費」と捉えるか、「移行の保険料」と捉えるかで、移行の成功率は変わります。協力への正当な対価を払う姿勢を見せることは、ベンダー側の引き継ぎ品質にも率直に影響します。

伝えるタイミング：早すぎる沈黙より、早めの対話

内製化の意向をいつベンダーに伝えるかは、多くの担当者が悩む点です。「伝えたら対応が悪くなるのでは」という懸念から直前まで伏せるケースがありますが、実務上は逆効果になりがちです。引き継ぎには相手の工数確保が必要で、直前の通告は物理的に丁寧な引き継ぎを不可能にします。

目安として、解約予告期間に引き継ぎ期間と並走期間を足した分、つまり半年前後は手前で対話を始めるのが妥当です。伝え方は「契約を切る通告」ではなく、「内製体制への移行を計画しており、引き継ぎに協力してほしい。必要な支援は有償で依頼したい」という協力依頼の形を取ります。

フェーズ3：引き継ぎ——必ず受け取るべき成果物チェックリスト

契約面の整理がついたら、いよいよ引き継ぎ本体です。受け取るべき成果物を分類別に一覧にします。自社のシステムに合わせて取捨選択し、引き継ぎ計画のベースにしてください。

ノーコード・ローコードで構築されたシステムの場合は、ソースコードの代わりにアプリケーションのオーナー権限（管理権限）の移管が中心になります。プラットフォームの契約プラン、導入済みプラグインの一覧、外部サービス連携の設定と名義を、上の表に読み替えて確認してください。

受け取り方の鉄則：「もらう」ではなく「自分たちで動かす」

チェックリスト以上に重要なのが、受け取り方です。引き継ぎの完了条件を「ファイル一式の受領」にしてはいけません。完了条件は「受け取った資料だけを頼りに、自社メンバーが開発環境をゼロから構築し、変更を加えて、検証環境にデプロイできること」に置きます。

この「一巡テスト」をやると、手順書の抜け、ベンダー担当者の頭の中にしかなかった設定、名義移管の漏れが一気に表面化します。表面化した穴を、ベンダーがまだ契約期間内にいるうちに埋める。これが引き継ぎフェーズの実質的な仕事です。
逆に、一巡テストなしで契約を終了すると、穴は最初の障害や改修のときに見つかります。そのときベンダーはもういません。

中身の品質は、書類が揃っていても別問題

もうひとつ、実務からの注意点があります。ドキュメントとコードが形式的に揃っていても、中身の品質はまた別の問題だということです。

Swoooに寄せられる開発の立て直し相談には、引き継いだ後に問題が発覚するパターンが実際にあります。たとえば、データベース設計に無理がありデータ量の増加とともに動作が極端に遅くなっているケースや、外部APIとの連携が実装できておらず本来の要件を満たしていなかったケースです。いずれも、資料を受け取った時点では気づきにくく、運用を引き取ってから表面化しています。

移行はシステムの健康診断の機会でもあります。引き継ぎ検証の際に、設計品質・セキュリティ・性能の観点で第三者のレビューを入れることを検討してください。問題が見つかれば、契約不適合責任の期間内であれば旧ベンダーとの協議材料になりますし、期間外でも内製チームが最初に手を入れるべき箇所の優先順位が明確になります。引き継ぎ後に深刻な問題が見つかった場合の立て直しは、開発の引き継ぎ・立て直しガイドで詳しく扱っています。

フェーズ4：並走期間の設計——二重コストは「保険料」と考える

引き継ぎが完了しても、すぐに旧ベンダーとの契約を切ってはいけません。旧ベンダーの保守契約を縮小しつつ残したまま、内製チームが実運用に入る「並走期間」を設けます。

並走期間には旧契約の費用と内製体制の人件費が二重にかかるため、省略したくなる誘惑が強い工程です。しかし、引き継ぎ資料がどれだけ充実していても、実際の障害対応や本番リリースを一度も経験していないチームには、必ず想定外が起きます。並走期間は、その想定外を「ベンダーに聞ける状態」で経験するための期間です。目安は3〜6ヶ月、システムの複雑さと障害の許容度に応じて調整します。

並走期間の設計3点セット

並走期間を「なんとなく契約を残している状態」にしないために、開始前に次の3つを文書化します。

• 役割分担の明文化：一次対応は内製チーム、解決できない場合のエスカレーション先が旧ベンダー、という順序を固定します。最初からベンダーに投げられる体制だと、内製チームに経験が蓄積されず、並走期間が延びるだけになります
• 卒業基準の事前定義：「障害の一次対応を◯件、自力で完結」「本番リリースを◯回、自力で完遂」「ベンダーへの問い合わせが月◯件以下」など、契約終了の条件を数値で先に決めます。基準がないと、安心のために契約だけが更新され続けます
• 問い合わせの記録と逓減の計測：ベンダーへ問い合わせた内容と回答をすべて記録します。この記録はそのまま社内ナレッジになり、問い合わせ件数の推移は卒業判定の客観データになります

引き取る順序：運用から始めて、大きな改修は最後

並走期間中に内製チームが引き取っていく業務には、リスクの小さい順序があります。

1. 運用・監視：日常の稼働確認、定期作業、ユーザーからの問い合わせ対応。システムの「平常時の顔」を覚える工程です
2. 軽微な改修：文言修正、表示調整、設定変更。変更からリリースまでの一連の流れを、低リスクな題材で回数をこなします
3. 機能追加：新しい画面や機能の追加。設計判断を伴う開発を、ベンダーにレビューを頼める状態で経験します
4. 大規模改修・基盤変更：DB構造の変更やアーキテクチャに関わる改修は、上の3段階を消化した後、原則として並走期間の後半以降に着手します

逆の順序、つまり「引き継ぎ直後に大規模改修から着手する」のは典型的な事故パターンです。システムの癖を知らないチームによる大きな変更は、障害の確率がもっとも高い組み合わせだからです。内製化の初期に意欲的なテーマを選びたくなる気持ちは自然ですが、最初の数ヶ月は「地味な業務を確実に引き取る」ことに徹する方が、結果的に早く自走に到達します。

体制構築の順序：移行と同時に「引き取る力」を育てる

ここまで契約と引き継ぎの手順を見てきましたが、受け皿となる社内体制がなければ、受け取った資産は棚に積まれるだけです。体制構築は移行のフェーズと並行して、次の順序で進めます。

1. 運用責任者を決める（フェーズ1と同時）
最初に決めるのはエンジニアの人数ではなく、「このシステムの面倒を見る責任者は誰か」です。責任者は必ずしも技術者である必要はありませんが、棚卸しから並走期間まで一貫して関わる専任性が必要です。移行の途中で担当が交代すると、引き継ぎの引き継ぎという二重の伝言ゲームが発生します。

2. 「読める人」を作る（フェーズ2〜3と同時）
引き継ぎ資料を受け取るとき、コードと設計をある程度読める人が社内側に1人いるかどうかで、引き継ぎの質が大きく変わります。質問ができるからです。経験者の中途採用が理想ですが、採用を待つと移行全体が止まるため、既存人材にコードリーディングとAIツールの研修を受けさせて立ち上げる方法が現実的な選択肢になっています（次章で詳述します）。

3. レビューとリリースの規律を整える（フェーズ3〜4と同時）
誰かが書いた変更を、別の誰かが確認してからリリースする。この当たり前の規律を、並走期間の最初のリリースから運用します。旧ベンダーが担っていた品質管理の機能は、契約終了とともに消えます。チェックリストとレビューの運用は、小さくてよいので初日から始めてください。

4. 改修の実績で広げる(フェーズ4以降)
並走期間の改修実績を教材にして、2人目・3人目の担い手を育てます。1人目への集中は内製化の定番の失敗要因で、立ち上げた本人の異動や退職で体制ごと崩れます。よくある失敗パターンとその回避策は内製化の失敗パターン集にまとめています。

AI駆動開発は引き継ぎの実務をどう変えたか

2026年時点の移行実務を語るうえで、コーディング支援AIの影響は無視できません。Claude Codeのようなエージェント型のAIは、コードベース全体を読み、構造を説明し、変更を提案できます。これは「動いているシステムを引き取る」という移行の中心課題に、直接効きます。

変わったこと：コードを「読み解く」コストが下がった

従来、引き継いだコードベースの全体像を把握するには、経験のあるエンジニアが数週間かけて読み込む必要がありました。現在は、AIにコードベースを読ませて「このシステムの構成と主要な処理の流れを説明して」と対話しながら把握を進められます。具体的には、次のような使い方が移行の現場で機能します。

• 構造の把握：ディレクトリ構成、データの流れ、外部連携のポイントをAIに要約させ、引き継ぎヒアリングの質問リストを作る
• ドキュメント欠損の補完：設計書が古い・存在しない箇所について、現行コードから仕様の説明を逆生成させ、たたき台として整備する
• 影響範囲の調査：「この項目を変更したら、どこに影響するか」をAIに洗い出させてから、軽微な改修に着手する

この変化は、体制構築の前提も変えています。「引き継いだコードを読める人」を育てるハードルが下がったため、経験者の採用を待たずに、既存人材とAIの組み合わせで受け皿を作る移行計画が組めるようになりました。移行期間の長期化要因だった「人が採れないので引き継げない」という詰まりに、迂回路ができたことになります。

変わらないこと：コードに書かれていない情報は、人からしか受け取れない

一方で、AIを過信した引き継ぎ計画は危険です。AIが読み取れるのは、コードに書かれていることだけです。次の情報はコードのどこにも書かれておらず、旧ベンダーの担当者から人として受け取るしかありません。

• なぜその設計を選んだのか（検討して捨てた選択肢と、その理由）
• 過去にどんな障害が起き、何が原因だったのか
• 「一見直せそうだが、触ると壊れる」箇所とその背景
• 業務側との暗黙の合意（画面には出ない運用ルール）

つまり、AIの登場で引き継ぎ成果物の優先順位が変わりました。詳細な設計書の網羅性よりも、「動くコード一式」と「意思決定の経緯・障害の履歴」の価値が相対的に上がったのです。旧ベンダーとの限られた引き継ぎ時間は、コードを読めばわかることの説明ではなく、コードに書かれていない経緯のヒアリングに使ってください。
Claude Codeを軸にした内製体制の作り方そのものは、Claude Codeで進める内製化ガイドで詳しく扱っています。

移行がうまくいかないときの選択肢

手順どおりに進めても、移行が計画どおりにいかないことはあります。代表的な2つの状況と、その際の選択肢を挙げます。

引き渡しが不十分なまま、関係が終わってしまった場合

ベンダーとの関係悪化や倒産・事業撤退などで、十分な引き継ぎのないままシステムだけが手元に残るケースがあります。この場合は、無理に内製チームだけで解読を進めるより、第三者の開発会社に「引き継ぎ調査」を依頼するのが早道です。現状のコード・環境・データを調査し、リスク箇所と改修優先度を報告書の形にしてもらってから、内製で引き取るか、部分的に外部へ再委託するかを判断します。この種の立て直しの進め方は開発の引き継ぎ・立て直しガイドを参照してください。

内製チームの立ち上がりが計画より遅い場合

並走期間の卒業基準に届かないまま期限が近づいたら、選択肢は3つです。並走期間を延長する、引き取る範囲を縮小する（運用は内製・大きな改修は外注のまま残す）、育成に追加投資する。避けるべきは、基準未達のまま予定どおり契約を終了することです。

ここで思い出してほしいのは、内製化は全か無かの選択ではないという原点です。「運用と軽微改修は内製、大規模開発は外部」というハイブリッドは、移行の失敗ではなく、多くの企業にとっての着地点です。内製と外注の使い分けの考え方は、システム開発の内製化ガイドに立ち返って再検討してください。

Swoooの移行支援：受け取る側と渡す側、両方の実務経験から

本メディアを運営するSwooo（東証グロース上場・株式会社アイビスの開発サービス）は、累計50件以上の開発支援の中で、この記事で扱った移行の両側を経験してきました。他社が開発したシステムを引き継いで立て直す側と、自社で開発したシステムをお客様の内製チームへ技術移管する側です。

移行の局面でSwoooが提供できる支援は3つあります。

• 引き継ぎ調査・セカンドオピニオン：現行システムのコード・設計・セキュリティを第三者としてレビューし、内製で引き取る前のリスク箇所と優先順位を報告します
• Claude Code研修：実案件でAI駆動開発を行う開発者が講師を務める法人研修です。全3回9時間・1人10万円で、引き継いだコードの読み解き方から、レビュー・セキュリティといった運用の規律までを扱います。詳細はAI研修の案内をご覧ください
• 並走期間の技術支援：内製チームの設計レビュー・コードレビューに外部の実務者として入り、卒業基準の達成までを支援します

「移行計画の妥当性を見てほしい」「引き継ぎチェックリストの過不足を確認したい」といった、判断材料の整理段階からのご相談で構いません。

→ 内製化への移行を相談する（無料）

よくある質問

Q. 受託開発から内製化への移行には、どのくらいの期間がかかりますか？

棚卸しの開始から自走までで6ヶ月〜1年が目安です。内訳は、棚卸しと契約整理に2〜4ヶ月、引き継ぎに1〜3ヶ月、並走期間に3〜6ヶ月。システムの規模と内製チームの経験値によって伸縮しますが、これより大幅に短い計画は、引き継ぎか並走のどちらかを削っている可能性が高く、見直しをお勧めします。

Q. 現行の開発会社には、いつ・どう伝えるべきですか？

解約予告期間に引き継ぎと並走の期間を足した分、目安として半年前後は手前で伝えるのが妥当です。伝え方は契約終了の通告ではなく、「内製体制への移行を計画しており、引き継ぎへの協力を有償でお願いしたい」という協力依頼の形を取ってください。引き継ぎの品質は相手の協力度に大きく依存するため、関係を保ったまま移行する価値は費用に見合います。

Q. ソースコードの著作権が開発会社にあると言われました。内製化は無理ですか？

無理とは限りません。内製化に必要なのは著作権の名義そのものではなく、「コード一式の引き渡しを受けられること」と「自社で改変してよいこと」です。契約書の利用許諾の範囲を確認し、足りない部分は覚書などの書面で合意できるケースが多くあります。条項の解釈に迷う場合は、協議の前に法務部門や弁護士に確認してください。

Q. 引き継ぎの費用は、どちらが負担するものですか？

契約に引き継ぎ協力の定めがなければ、ドキュメント整備や説明会などの引き継ぎ支援は既存契約の範囲外であることが多く、その場合は発注側が有償で依頼するのが現実的です。移行予算には、引き継ぎ支援の費用と、並走期間中の旧契約・内製体制の二重コストをあらかじめ含めて計画してください。

Q. ドキュメントがほとんど残っていない場合は、どうすればいいですか？

3つの手を組み合わせます。第一に、動くコード一式と環境へのアクセスを最優先で確保すること。第二に、Claude CodeなどのAIでコードから構造・仕様の説明を逆生成し、たたき台のドキュメントを作ること。第三に、残された引き継ぎ時間を「なぜその設計か」「過去の障害」などコードに書かれていない経緯のヒアリングに集中させることです。自力での解読が難しい場合は、第三者への引き継ぎ調査の依頼を検討してください。

Q. すべてを内製に切り替えず、保守だけ外注に残すのはありですか？

あります。むしろ「運用と軽微な改修は内製、専門性の高い領域や大規模開発は外部」というハイブリッドは、内製化が定着した企業の標準的な着地点です。重要なのは、外注を残す場合でも、コード・ドキュメント・アカウントの管理権を自社側に置き、いつでも引き取れる状態を保つことです。使い分けの考え方はシステム開発の内製化ガイドで解説しています。

まとめ：移行の成否は「引き継ぎの設計」で決まる

受託開発から内製化への移行は、棚卸し・契約整理・引き継ぎ・並走期間・自走の5フェーズで進みます。要点を振り返ります。

• 契約終了日から逆算せず、引き継ぎの完了条件と並走期間の卒業基準を先に定義する
• 契約整理の論点は、検収と契約不適合責任の期間、コード・ドキュメントの引き渡しと改変可否、保守契約の終了条件。結論はすべて契約書の記載が起点で、必要に応じて専門家に確認する
• 引き継ぎの完了条件は「資料の受領」ではなく「自社メンバーだけで環境構築からデプロイまで一巡できること」
• 並走期間の二重コストは保険料。運用→軽微改修→機能追加→大規模改修の順で引き取る
• AIはコードの読み解きを速くしたが、設計の経緯と障害の履歴は人からしか受け取れない。引き継ぎ時間はそこに使う

移行は一度きりの作業ではなく、その後の内製体制の質を決める土台づくりです。まずはフェーズ1の棚卸しから、契約書とアカウント一覧を机に並べるところから始めてください。

関連ガイド：システム開発の内製化ガイド（判断編）／内製化の失敗パターン集／Claude Codeで進める内製化ガイド／開発の引き継ぎ・立て直しガイド／開発契約ガイド（請負と準委任）

→ 内製化への移行計画を相談する（無料）