フリーランスが作ったプロダクトを引き継ぐ方法
「MVPは信頼できるフリーランスの方に作ってもらった。動いてはいるが、その方が本業で忙しくなり返信が週1回になった」「連絡は取れるが、次の開発フェーズをお願いできる稼働がもう無い」——低コストでスピーディにMVPを立ち上げるためにフリーランスへ発注するのは合理的な選択ですが、事業が成長して継続開発が必要になった段階で、体制のボトルネックとして表面化するケースをよく見ます。
フリーランス1人が作ったプロダクトは、法人の開発会社が作ったものと比べて引き継ぎの難易度が一段高いことが多いです。理由は技術力の差ではなく、「体制」というレイヤーがそもそも存在しなかったことにあります。この記事では、フリーランス発のプロダクトを別の開発チームに引き継ぐときに固有の論点と、円満に進める手順を整理します。
フリーランス発プロダクト特有の3つの問題
法人の開発会社が作ったプロダクトの引き継ぎと比べて、フリーランス1人が作ったプロダクトには次の特徴が出やすくなります。
1. インフラ・外部サービスが個人名義のまま
法人契約では会社のクレジットカード・会社ドメインのメールで登録するのが原則ですが、フリーランスへの発注では「早く始めたいので、とりあえず私のアカウントで」という進め方になりがちです。AWSやVultrのアカウント、ドメインレジストラ、GitHubリポジトリ、Stripeなどの決済アカウント、SendGridのようなメール送信サービスが、フリーランス本人の個人メールアドレス・個人カードで登録されているケースは珍しくありません。この状態のまま連絡が減ると、契約が終わった瞬間にプロダクトの土台ごと消える(あるいはアクセスできなくなる)リスクを抱えたままになります。
2. コードのお作法が「その人だけの流儀」
法人の開発チームは複数人でレビューし合うため、命名規則やディレクトリ構成がある程度標準的な型に寄ります。一方フリーランス1人の開発は、レビューする相手がいないためその人固有の書き方の癖がそのままコードベース全体に定着します。悪いという意味ではなく、「なぜここでこの設計を選んだか」を説明できるのが本人しかいない、という状態を指します。標準的なRailsの規約から外れた独自のディレクトリ構成、フレームワークの機能を使わず自作したヘルパー群、変数名の省略ルールなど、外部から見て初見では読み解きにくい箇所が多くなりがちです。
3. ドキュメント・引き継ぎ書がそもそも存在しない前提で作られている
法人の開発会社であれば納品時に一定の設計書や運用手順書を用意する慣習がありますが、フリーランスとの継続的な関係の中では、「聞けばすぐ本人に確認できる」ため、ドキュメントを残す動機自体が働きません。これは手抜きではなく合理的な選択の結果ですが、本人と連絡が取りにくくなった瞬間にその合理性が裏目に出ます。
引き継ぎ前に確保すべきもの
連絡がまだ取れる段階、あるいは契約がまだ生きている段階で、次を先に確保しておくと引き継ぎの難易度が大きく下がります。
- 全アカウントの棚卸しと会社名義への移管: インフラ(AWS/Vultr/GCP等)、ドメイン・DNS、GitHub、決済(Stripe等)、メール送信、監視・分析ツールを洗い出し、可能な限り会社のメールアドレス・組織アカウントに移す。個人名義から切り離せないものは、少なくともログイン情報と復旧手段(2要素認証のバックアップコード等)を会社側で保管する
- ソースコードが全てpushされているか: フリーランスのローカル環境にしかない未pushの変更、ローカルにしか置かれていない環境変数ファイルがないかを確認する
- 設計判断の背景をヒアリングする: なぜこの技術構成を選んだか、検討して見送った代替案は何か、外部APIとの連携で「決まった順序で呼ばないと失敗する」といった暗黙のお作法があるか。これは契約終了後には基本的に復元不可能な情報です
- 請求・契約の精算条件を明確にする: 引き継ぎ作業自体に稼働を割いてもらう場合、それが契約範囲内か追加費用かを先に合意しておく。ここが曖昧なまま進めると、引き継ぎ協力への熱意が下がりやすくなります
これらは前任者退職後のシステム引き継ぎで最初にやることで解説した手順とほぼ共通ですが、フリーランス特有の論点として「個人名義のアカウントが多い」「稼働を割いてもらう対価をどう扱うか」の2点が上乗せされます。
コードの現状診断で見るポイント
引き継ぎ後、別の開発チーム(社内採用でも外部委託でも)が最初に行うのは、コードベースの健全性診断です。フリーランス発プロダクト特有の観点は次の通りです。
- フレームワークの標準からどれだけ外れているか: Railsであれば規約通りのMVC構成か、独自の抽象化レイヤーが挟まっているか。標準から外れているほど、新しいメンバーのキャッチアップに時間がかかる
- テストの有無: 個人開発ではテストを書かずスピード優先で進めることが多い。テストがない場合、いきなり全体に書き足すのではなく、これから触る範囲に絞って最小限の回帰テストを積み増す進め方が現実的
- 依存ライブラリのバージョン: MVP立ち上げ時に選んだgem/npmパッケージのバージョンが、事業成長のスピードに対して更新されずに止まっていないか
- 「動くが説明できない」箇所の洗い出し: コードは動いているが、コメントもテストもなく、挙動を変えると何が起きるか予測できない箇所を先にリストアップしておく。これを事前に把握しておくだけで、次のチームが不用意に壊すリスクを減らせる
この診断の一般的な進め方は既存プロダクトの改善、外部チームが最初に見る観点で詳しく解説しています。フリーランス発プロダクトの場合、特に「フレームワーク標準からの逸脱度」と「暗黙知の量」を通常より重めに見積もっておくのが実務上のコツです。
フリーランスから開発チームへの移行の進め方
移行を一気に進めようとすると、稼働の切れ目でプロダクトが放置される期間が生まれがちです。実務では次の順番で進めるとリスクを抑えられます。
- 並走期間を短くてもいいので設ける: フリーランスの方の稼働がゼロになる前に、新しいチームが並走してコードを読める期間を1〜2週間でも確保する。ここで質問できる相手がいるかどうかで、その後の立ち上がりスピードが大きく変わる
- 引き継ぎミーティングは「読む」より「動かしながら聞く」形式にする: ドキュメントを口頭で説明してもらうより、画面共有しながら実際にコードを一緒に動かし、判断の背景を録画しながら聞き出す方が情報の密度が高い
- 最初の改善タスクは小さく、リスクの低いものを選ぶ: 新しいチームがコードベースに不慣れな段階でいきなり大きな機能改修に着手すると、既存の挙動を壊しやすい。小さなバグ修正や軽微な改善から着手し、コードベースへの理解を検証しながら進める
- 属人化した箇所から順にドキュメント化・テスト化する: 診断で洗い出した「動くが説明できない」箇所から優先的に、テストを足しながら仕様を明文化していく
この進め方は、CTOなど社内の技術責任者が抜けた場合の引き継ぎとも共通する部分が多く、CTO退職後も開発を止めない引き継ぎ方も合わせて参考になります。
円満な引き継ぎのために
フリーランスとの関係が悪化した状態で引き継ぐケースは稀で、多くは「本業が忙しくなった」「他の案件が優先になった」といった、双方に悪意のない理由です。円満に進めるために意識したいのは次の点です。
- 契約終了・稼働縮小の意思決定を、引き継ぎ作業が必要になる前に早めに共有してもらう: 直前になって判明すると、上記の「確保すべきもの」を集める時間が取れなくなる
- 引き継ぎ協力への対価を明確にする: 無償の善意に頼った引き継ぎは、優先順位が下がった瞬間に止まる。稼働に対して正当な対価を払う前提で依頼する方が、結果的に必要な情報を確実に得られる
- 技術的な評価と人間関係を切り分ける: コードの構造やテストの有無について改善点が見つかっても、それは「フリーランスが悪かった」という話ではなく、1人開発という体制の構造的な限界であることが多い。この前提を共有しておくと、引き継ぎのヒアリングが協力的に進みやすくなります
まとめ
- フリーランス発のプロダクトは、インフラが個人名義のまま・コードがその人固有の流儀・ドキュメント不在という3点で、法人開発の引き継ぎより難易度が上がりやすい
- 契約終了前にアカウントの会社名義移管、ソースコードの完全push確認、設計判断の背景ヒアリングを済ませておくことが、その後の立ち上がりスピードを大きく左右する
- 移行は並走期間を設け、小さいタスクから着手してコードベースへの理解を検証しながら進めるのが安全。属人化した箇所は診断で洗い出してから優先的にドキュメント化・テスト化する
torcheees では、フリーランスからの引き継ぎのような体制の切れ目にある案件にも対応しています。まずは1〜4週間の「要件整理・開発診断」で、現状のコード・インフラ・アカウントの状態を確認し、保全すべき箇所と改善の優先順位をご提示します。継続的な改善は継続的な改善支援としてもご相談いただけます。モダナイゼーションのサービス詳細をご覧のうえ、まずはお問い合わせフォームからご連絡ください。