内製化前提の外注｜引き継ぎを契約に書くべき項目

「納品後は自社で保守する予定です。」——キックオフでは全員がうなずく。だが契約書に書いてあるのは検収と瑕疵担保だけで、誰が・いつ・何を教えて自走するかが空欄のまま始まる案件が多い。

結果、リポジトリは渡っても「触ると壊れる」状態が残る。内製化は意志ではなく、契約とスケジュールに落とさないと起きない。

外注の成果物をコードではなく「自走状態」と定義し、引き継ぎを条項とマイルストーンにする。

結論：契約に書く項目

項目	書いておく内容の例
成果物の定義	コード＋運用手順＋意思決定ログ＋環境再現手順
ペア／同席	週次で社内担当と作業する時間（例: 週4時間×N週）
ドキュメント	何を・どの粒度で・いつ更新するか（Wikiの山は成果にしない）
引き継ぎ期間	検収後○週間は質問対応と同行を含む
採用・育成	社内採用の面接同席やオンボーディング支援の範囲
完了条件	「社内担当が単独で定例リリースと一次障害対応ができる」等

「ナレッジ移転します」の一文では足りない。観測できる完了条件が必要だ。

事例1：ドキュメント山積みで失敗

匿名化した一例。受託側が200ページの設計書を納品。社内エンジニア2名が読み切れず、最初の改修でベンダーへ回帰。追加の問い合わせ費用が月額化し、内製化は名目だけになった。

分岐点は契約時だ。「ページ数」ではなく「社内が週1リリースを独力で回せる」を完了条件にしていたら、成果物の形が変わっていた。

事例2：週1ペアで自走に近づいたケース

別の一例。開発期間の後半8週間、毎週半日をペア作業と障害訓練に充てる条項を入れた。ドキュメントは短いRunbookと意思決定ログに限定。検収後4週間で、社内が一次対応を取れるようになった。ベンダー依存はゼロにはならないが、止まらない状態には届いた。

ベンダー依存が残る構造

内製化を急ぐ発注者と、稼働を維持したい受託側ではインセンティブがずれることがある。悪意ではなく、契約が「作ること」に偏ると起きる。引き継ぎ工数を見積もりとスケジュールに明示し、終わらない支援をダラダラ続けない方が双方健全だ。

判断軸：内製化条項を厚くする／外注継続を前提にする

厚くする	外注継続を認める
12ヶ月以内に社内で改修・障害一次を回したい	コア以外を継続外部に置く方針が明確
採用が進み、受け皿の担当が決まっている	担当不在のまま「いつか内製」だけが口号
ドメイン知識を社内資産にしたい	コモディティ領域で、切り替えコストが低い

次に確認すること

1. 自走の完了条件は一文で書けるか
2. ペア／同席の時間は見積もりに入っているか
3. ドキュメントの「量」ではなく「使う場面」を定義したか
4. 検収後の引き継ぎ期間と費用は分かれているか
5. 社内の受け皿担当（名前）は決まっているか

まとめ

内製化前提の外注は、納品物の美しさでは測れない。契約に引き継ぎの時間・成果物・完了条件を書き、スケジュールの後半で実行する必要がある。意志だけでは、リポジトリの権限移譲で終わってしまう。

---

引き継ぎ設計を含む受託の相談は、お問い合わせフォーム からどうぞ。