社内開発の既存プロダクトを外部へ引き継ぐ手順

「エンジニアが1人しかいなくて、その人の手が完全に埋まっている」「採用を半年続けているが決まらない」「社内エンジニアが退職を決めていて、後任のあてがない」——社内で作り育ててきたプロダクトの開発を、外部チームへ引き継ぎたいという相談は年々増えています。開発会社を乗り換える移管とは違い、引き継ぐ相手が「他社」ではなく「自社で作った人の頭の中」である分、つまずき方も独特です。

社内開発から外部への引き継ぎがうまくいかないのは、技術力の問題ではなく、渡すべきものが「ドキュメント」ではなく「習慣」になっていることが原因です。この記事では、社内プロダクトを外部チームへ引き継ぐときに実際につまずくポイントと、失敗しない進め方を整理します。

社内開発ならではのつまずき方

開発会社からの移管(開発会社を変更するときの引き継ぎチェックリスト)と比べて、社内開発からの引き継ぎには固有の難しさが3つあります。

1. ドキュメントを書く動機がそもそもなかった

社内の1〜2人チームでは、「聞けばすぐ分かる」ためにドキュメント化のインセンティブが働きません。仕様書がないのではなく、「仕様書という概念が発生しなかった」状態です。これは前任者が退職して情報が失われたケースとは根本的に違い、担当者がまだ社内にいる今のうちにしか、頭の中の情報を引き出す機会がありません。

2. 「聞けば分かる」がボトルネックそのものになっている

社内エンジニアが手一杯になっている場合、その人に質問すること自体が新しいタスクを積むことになります。外部チームが立ち上がるための質問ラッシュが、まさに手一杯にしたい相手の時間を食う——この矛盾が引き継ぎの初速を殺します。

3. 社内に「自分の仕事を取られる」抵抗が生まれやすい

開発会社の交代と違い、社内エンジニアからすれば「自分が作ったものを他人に渡す」体験です。本人が望んで引き継ぎを申し出た場合でも、無意識に情報を出し渋る、あるいは「言わなくても分かるだろう」という前提で説明が粗くなることがあります。退職が絡む場合はなおさらで、悪意がなくても引き継ぎの優先度が本人の中で下がりがちです。

何を渡すべきか: ドキュメントより先に「動く状態」と「権限」

引き継ぎというと真っ先にドキュメント整備を思い浮かべがちですが、優先順位を間違えると時間切れになります。実務上、次の順で確保してください。

最優先: アクセス権とアカウントの所在

社内開発では、サーバー・ドメイン・SaaS契約が個人アカウントに紐づいていることが珍しくありません。担当者が退職・異動した瞬間にアクセス不能になるリスクを、引き継ぎ前に必ず潰します。

• [ ] 本番サーバー(AWS/GCP/Vultr等)の契約が会社名義のアカウントになっているか、個人アカウント配下でないか
• [ ] リポジトリのOwnerが会社のOrganizationになっているか(個人の GitHub アカウント配下は要移管)
• [ ] ドメイン登録者・DNS管理権限
• [ ] 決済・メール配信・分析ツールなど外部SaaSの管理者権限一式
• [ ] 環境変数・APIキー・credentials の復号キー(Railsなら master.key)の所在と管理方法

このリストは開発会社を変更するときのチェックリストと重なりますが、社内開発の場合は「個人アカウント依存」の比率が体感で2〜3倍高くなります。担当者が善意で全部やってくれていたがゆえに、会社としての所有権が整理されていないケースが大半だからです。

次点: 「動かせる」状態の確認

ローカル開発環境の再現手順、デプロイ手順が、担当者以外の人間の手でも再現できるかを確認します。これは既存プロダクトの改善、外部チームが最初に見る観点で詳しく解説した内容とほぼ同じですが、社内開発では「READMEを書く習慣自体がなかった」ことが多いため、外部チームが入る前に一度、担当者以外(別の社員でも構いません)が手順書だけを見て再現できるかテストすることを強く勧めます。ここで詰まった箇所こそが、最初に文書化すべき箇所です。

その次: 暗黙知の抽出

コードそのものより厄介なのが、コードに書かれていない判断です。

• なぜこの仕様になっているか(顧客からの個別要望、過去の障害対応の名残など)
• 触ると危険な箇所(バッチ処理、決済連携、外部APIの制限に近い箇所)
• 「本当は直したいがずっと後回しにしている」箇所のリスト

これらは会議で1回聞いても引き出しきれません。詳しくは次の並走期間の設計で扱います。

並走期間の設計: 「同席」と「独立」を分けて考える

社内開発から外部への引き継ぎで最も失敗しやすいのが、並走期間の設計です。「とりあえず1ヶ月一緒にやってもらう」という曖昧な計画は、往々にして社内担当者の負荷を増やすだけで終わります。並走期間は目的ごとにフェーズを分けるほうがうまくいきます。

フェーズ1: 観察期間(1〜2週間、社内担当者の負荷は最小)

外部チームがコードとログを読み、動かして観察する期間です。ドキュメントがない既存システムを引き継ぐ方法で述べた「動かして観察する」プロセスと同じで、この段階では社内担当者への質問は最小限(1日15分程度の確認で足りることが多い)に抑えます。ここで質問を絞り込むために事前に疑問点をリスト化させておくと、社内担当者の負荷を大きく下げられます。

フェーズ2: 集中ヒアリング期間(3〜5営業日、社内担当者の負荷は高いが短期集中)

観察で分からなかった「なぜこうなっているか」を、まとめて聞く期間です。ダラダラと数週間に分散させるより、社内担当者のカレンダーを数日ブロックしてもらい、集中的に消化する方が、聞く側・答える側双方の負荷が少なく済みます。録画・議事録を残し、後から同じ質問が出ないようにします。

フェーズ3: 並走実装期間(2〜4週間、社内担当者は最終確認のみ)

外部チームが実際に小さな改修を担当し、社内担当者はレビューと最終承認だけを行う期間です。ここで実装を外部チームに完全に渡せるかどうかが、引き継ぎの成否の分岐点になります。

• 完全に渡せるケース: フェーズ2までで「危険地帯」が言語化できており、外部チームが自走できる見通しが立っている
• 並走期間を延長すべきケース: フェーズ3の初回リリースで想定外の不具合が出た、あるいは社内担当者から「まだ不安な箇所がある」という声が出ている

この判断を曖昧にしたまま社内担当者が退職・異動してしまうと、フェーズ3の途中で連絡が取れなくなり、前任者退職後のシステム引き継ぎと同じ状況に陥ります。退職が決まっている場合は、退職日から逆算してフェーズ1〜3を必ず退職前に終える日程を組むことが最優先です。

社内の抵抗を減らす進め方

社内エンジニアの協力度合いが引き継ぎの速度を大きく左右します。抵抗を減らすには、次のような設計が有効です。

• 「取り上げる」ではなく「手が空く」フレームで伝える。特に手一杯で疲弊している担当者には、引き継ぎが負荷軽減であることを明確に伝える
• 引き継ぎ後の役割を先に決めて伝える。何も決めずに引き継ぎを始めると、担当者は「自分の仕事がなくなるのでは」という不安から情報を出し渋る。次の章で扱う「社内に残す役割」を先に握っておく
• 退職者の場合は、退職後の有償スポット相談を打診する。退職後も低頻度(月数時間)で質問に応じてもらう契約を結べると、フェーズ2で拾いきれなかった暗黙知の保険になる

外部チームの立ち上がりを速める工夫

引き継ぎを受ける外部チーム側でも、立ち上がりを速める工夫があります。

• 質問はバッチ化して渡す。都度Slackで聞くのではなく、1日1回まとめて質問リストを送り、まとめて回答をもらう運用にすると、社内担当者が「常に呼び出される」状態を避けられる
• 触る前にコードから仮説を立て、質問は「仮説の検証」の形にする。「これは何をしていますか」より「これは◯◯のための処理だと理解していますが合っていますか」の方が、答える側の負荷が小さく、精度も上がる
• 最初の改修は影響範囲が狭いものを選ぶ。信頼構築のためにも、最初の1〜2件はリスクの低いタスクを選び、外部チームの手つきを社内側に見てもらう

社内に残すべき役割

外部化は「全部丸投げ」ではありません。特に次の役割は、社内に残すことを強く勧めます。

• 仕様決定権: 何を作るか・優先順位をどうするかの意思決定は、事業を理解している社内側に残す。外部チームは実装の専門家であって、事業判断の代行者ではない
• 最終承認者: 本番リリースの最終ゴーサインを出す人。技術的な実装確認は外部チームに任せてよいが、「今リリースしていいか」のビジネス判断は社内に残す
• 窓口1名: 外部チームとのコミュニケーション窓口を1人に絞る。全員が個別に外部チームとやり取りすると情報が分散し、外部チーム側も混乱する

エンジニアがゼロになるからといって、意思決定まで手放す必要はありません。むしろ実装を外部に任せることで、社内側は仕様検討や優先順位づけに集中できるようになります。

引き継ぎチェックリスト

• [ ] サーバー・ドメイン・SaaSアカウントが個人名義でなく会社名義になっているか確認した
• [ ] リポジトリのOwnerが会社のOrganizationになっている
• [ ] 開発環境が担当者以外の手でも再現できることをテストした
• [ ] 並走期間をフェーズ1(観察)・フェーズ2(集中ヒアリング)・フェーズ3(並走実装)に分けて日程化した
• [ ] 退職が絡む場合、退職日から逆算してフェーズ3までを終える日程を組んだ
• [ ] 引き継ぎ後の社内側の役割(仕様決定権・最終承認者・窓口)を先に決めて本人に伝えた
• [ ] 退職者向けの有償スポット相談の可否を打診した

まとめ

• 社内開発からの引き継ぎは、ドキュメント不足ではなく「習慣として文書化されてこなかった」ことが本質的な難しさ。個人アカウント依存のインフラ・SaaS権限の整理を最優先で行う
• 並走期間は「観察」「集中ヒアリング」「並走実装」の3フェーズに分けると、社内担当者の負荷を抑えながら暗黙知を引き出せる。退職が絡む場合は退職日から逆算して日程を組む
• 外部化しても仕様決定権・最終承認者・コミュニケーション窓口は社内に残す。丸投げではなく役割分担として設計することが、引き継ぎ後の関係を長続きさせる

torcheeesでは、社内エンジニアが手一杯・退職・採用難で開発が止まりかけているプロダクトの引き継ぎに数多く対応してきました。まずは1〜4週間の「既存プロダクト改善」診断で、現状のコード・インフラ・アクセス権を確認し、並走期間の設計と概算費用をご提示します。継続的な改善支援も承っています。モダナイゼーション・要件整理からのご相談のサービスページもご覧いただき、まずはお問い合わせフォームからご連絡ください。