「長年システムを担当していたエンジニアが退職することになった」「保守をお願いしていた開発会社との契約が終わることになった」——そんな状況が突然訪れたとき、多くの担当者は途方に暮れます。
どこから手をつければよいか分からない。何を準備すれば引き継ぎができるのか。どこに依頼すれば引き継いでもらえるのか。費用はいくらかかるのか。
本記事では、システム引き継ぎの方法・手順・ドキュメントに含めるべき項目・費用の目安を、中小企業の担当者向けに分かりやすく解説します。スムーズな移管を実現するためのポイントも紹介しますので、ぜひ参考にしてください。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
システム引き継ぎとは？
システム引き継ぎとは、自社が利用しているシステムの管理・開発・運用を、別の担当者や会社へ移管するプロセスのことです。「移管」「引き渡し」と呼ばれることもあります。
引き継ぎ対象となるのは、システムそのもの（ソースコード・データベース・サーバー）だけでなく、業務のノウハウや運用手順、関連するドキュメントも含まれます。システムの「頭の中の情報」をすべて次の担当者・会社へ渡す作業と言えます。
システム引き継ぎが必要になる主な場面
システム引き継ぎが発生するのは、以下のような場面です。
担当エンジニア・IT担当者の退職・異動 社内のシステム担当者が退職・異動する場合、その人しか知らない情報（「このシステムはこのデータを手動で更新している」「月次バッチはこのタイミングで手動実行している」等）がすべて失われます。
開発会社との契約終了・会社変更 コスト削減・サービス不満・会社倒産など、様々な理由で開発会社を変更するケース。前の会社から新しい会社へのシステム引き継ぎが必要です。
システムのリプレイス・統廃合 老朽化したシステムを新しいシステムに置き換える際、既存システムの情報を新システムへ引き継ぎます。
内製化・アウトソース化の方針変更 これまで外部に委託していた開発を社内で担当するようになった（または逆のパターン）ケースです。
システム引き継ぎの3つの方法
システム引き継ぎには、大きく3つの方法があります。状況に応じて最適な方法を選びましょう。
①社内での引き継ぎ（担当者変更）
社内の別のエンジニアや担当者へ引き継ぐ方法です。担当者の異動・退職時に最もよく使われるパターンです。
向いているケース: 社内に技術スタックを理解しているエンジニアが別にいる場合
必要な準備: ドキュメントの整備と、前担当者と新担当者の並走期間（1〜2週間の引き継ぎセッション）
メリット: コストが最小限。社内の業務文脈を理解した状態で引き継げる
注意点: ドキュメントが不十分な場合、新担当者が苦労する。引き継ぎ期間が短すぎると後々トラブルが発生しやすい
②外部の開発会社への引き継ぎ（保守移管）
社内にエンジニアがいない、または社内では対応が難しい技術スタックの場合、外部の開発会社に引き継ぎを依頼します。
向いているケース: 担当エンジニアが退職し、社内に後継者がいない場合。現在の開発会社から別の会社へ切り替えたい場合
必要な準備: 引き継ぎを受けてくれる会社の選定・現状システムの情報整理
メリット: 専門知識を持ったエンジニアにシステムを委ねられる
注意点: 他社が開発したシステムを引き継ぐには調査コストがかかる。引き継ぎを断る会社もある（詳しくは後述）
自社（秋霜堂）では、他社が開発したシステムの引き継ぎ実績があります。TechBandとして、システムの現状調査から保守・継続開発までを一貫してサポートしています。
③引き継ぎを機にシステムを刷新する
ドキュメントがほぼ存在しない、技術的に古すぎるシステムの場合、引き継ぎよりもシステムの再構築・リプレイスを選択するケースもあります。
向いているケース: ドキュメントが皆無で引き継ぎコストが膨大になる場合。技術的負債が深刻で引き継ぎ後の保守が困難な場合
判断基準: 引き継ぎ調査コスト + 引き継ぎ後の保守コスト vs 再構築コストを比較する。10年以上稼働している基幹システムはリプレイスが経済的に合理的なケースが多い
引き継ぎドキュメントに含めるべき7つの項目
スムーズな引き継ぎのために、以下の7項目をドキュメントにまとめておきましょう。
① システム概要・業務フロー
「このシステムは何のためにあるのか」「誰がどのように使うのか」を明文化します。
記載すべき内容:
- システムの目的・機能の概要
- 主な利用者・利用シーン
- 業務フロー図（誰が何をどの順番で行うか）
② 技術スタック・構成情報
引き継ぎを受ける開発会社が最初に確認する情報です。
記載すべき内容:
- プログラミング言語とバージョン（例: Python 3.11, Node.js 18）
- フレームワーク（例: Django, Express.js）
- データベースの種類とバージョン
- サーバー・クラウド環境（AWS/GCP/Azureなど）
③ アーキテクチャ図・ネットワーク図
文章だけでシステム構成を説明するのは限界があります。図を使って可視化しましょう。
記載すべき内容:
- システムアーキテクチャ図（どのコンポーネントがどう連携しているか）
- ネットワーク構成図
- DBのER図（テーブル構造）
④ ソースコードとリポジトリ情報
記載すべき内容:
- GitHubやGitLabなどのリポジトリURL
- ブランチ戦略（どのブランチがどの環境に対応しているか）
- デプロイの手順
⑤ アカウント・認証情報
セキュリティに関わる情報ですが、引き継ぎには不可欠です。
記載すべき内容:
- サーバー・データベースのアクセス情報
- 外部サービス（決済・メール配信・SMS等）のAPIキー
- 管理画面のログイン情報
注意: 認証情報は平文での共有を避け、パスワードマネージャーや暗号化された方法で引き継ぐこと
⑥ 既知の問題・バグ・運用上の注意点
「地雷情報」の共有が引き継ぎの要です。
記載すべき内容:
- 既知のバグ・不具合と対処法
- 「この機能は毎月1回手動で実行が必要」等の運用上の注意
- 過去に発生したトラブルと対処法（障害対応ログ）
- 「このデータは絶対に削除しないこと」等の禁止事項
⑦ 関係者一覧・契約一覧
記載すべき内容:
- サーバー会社・ドメイン管理会社の担当者情報
- 外部サービスの契約内容・更新日
- SLA（サービスレベルアグリーメント）の確認
システム引き継ぎの流れ（ステップ別）
引き継ぎを成功させるためのステップを順番に解説します。
Step1: 引き継ぎ対象の棚卸し（目安: 1〜2週間）
まず「自社のシステムは何があるか」を洗い出します。普段から使っているシステムだけでなく、定期実行しているバッチ処理や、外部サービスとの連携も含めて網羅的に確認します。
確認すべき内容:
- どのシステム・サービスが存在するか
- それぞれに関するドキュメントはあるか
- 現担当者しか知らない情報（暗黙知）は何か
Step2: 依頼先の選定（外部委託の場合、目安: 2〜4週間）
「他社開発システムの引き継ぎを行います」と謳っている会社でも、すべての技術スタックに対応できるわけではありません。依頼前に必ず確認しましょう。
確認すべきポイント:
- 自社システムの技術スタック（言語・フレームワーク）に対応しているか
- 他社開発システムの引き継ぎ実績があるか
- 引き継ぎ調査の費用感を明示してくれるか
Step3: 引き継ぎドキュメント作成（目安: 2〜4週間）
現担当者と新担当者（または新しい開発会社のエンジニア）が一緒に、上記7項目を整備します。ドキュメントが全くない場合は、新担当者が動かしながら「リバースエンジニアリング」でドキュメントを作成することになります。
Step4: 並走期間（目安: 1〜2ヶ月）
新旧の担当者・会社が並行して対応する期間です。この間に「実際に運用して出てきた疑問・問題」を解消します。
「最初の2週間で全体を把握し、次の2週間で独立稼働を試みる」という流れが一般的です。複雑なシステムや、ドキュメントが不足しているシステムは、並走期間を長めに設定しましょう。
Step5: 完全移管・引き継ぎ完了確認
独立稼働できるようになったら、引き継ぎ完了を確認します。チェックリスト（弊社の「失敗しないためのシステム保守の引継ぎチェックリスト」が参考になります）を使って確認漏れを防ぎましょう。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
システム引き継ぎの費用・期間の目安
引き継ぎにかかる費用と期間は、システムの規模と複雑さによって大きく異なります。
費用の目安
ケース | 費用の目安 |
|---|---|
社内引き継ぎ（担当者変更） | 主に担当者の工数コスト（数十万円〜） |
外部委託への移管（調査コスト） | 30〜100万円程度 |
年間保守費用（移管後） | 開発費の10〜15%が目安 |
外部委託への移管では、「引き継ぎ調査費（現状確認・ドキュメント整備）」が別途発生することが多くあります。ドキュメントが整備されていれば調査コストは下がり、ほぼゼロの状態なら上がります。
期間の目安
ケース | 期間の目安 |
|---|---|
単純な引き継ぎ（ドキュメント整備済み） | 1〜2ヶ月 |
一般的な業務システムの引き継ぎ | 2〜3ヶ月 |
複雑なシステム・ドキュメント不足 | 3〜6ヶ月 |
引き継ぎ先を選ぶ5つのポイント
外部の開発会社に引き継ぎを依頼する場合、以下のポイントで選定しましょう。
① 他社開発システムの引き継ぎ実績があるか 実績のない会社は、引き継ぎ時に技術スタックが合わずに困ることがあります。事前に確認しましょう。
② 技術スタックに対応できるか Pythonで書かれたシステムをPHPしか書けないエンジニアには引き継げません。初回ヒアリングで技術スタックとバージョンを必ず確認しましょう。
③ コミュニケーションの透明性 「見積もりを出してもらえない」「調査しないと分からない」ばかりで費用感を教えてくれない会社は避けましょう。
④ 引き継ぎ後の保守・継続開発が可能か 引き継ぎだけ対応して「あとは自分で」という会社より、引き継ぎ後も継続して関われる会社の方が安心です。
⑤ 費用感が明確か 引き継ぎ調査の費用、月次保守費用、追加開発の単価が明確かどうかを確認しましょう。
システム引き継ぎでよくある3つの失敗と対策
失敗1: ドキュメントが不完全なまま引き継ぎを開始してしまう
問題: ドキュメントが存在しないまま引き継ぎを開始すると、新担当者が全容を把握するのに数ヶ月かかります。その間、トラブルが発生しても原因を特定できず、対応が大幅に遅れます。
対策: 引き継ぎ前に最低限のドキュメント（技術スタック・構成図・認証情報・既知の問題）を整備してから引き継ぎを開始しましょう。ドキュメントが全くない場合は、依頼先の開発会社に「リバースエンジニアリングによるドキュメント作成」を引き継ぎ作業に含めて依頼します。
失敗2: 技術スタックが合わない会社に依頼してしまう
問題: 「引き継ぎを受けます」と謳っていても、実際には対応できない技術スタックだった、というケースは珍しくありません。途中でお断りされると、時間とコストが無駄になります。
対策: 最初のヒアリングで、現システムのプログラミング言語・フレームワーク・バージョンを具体的に伝え、「対応可能か」を確認してから進めましょう。
失敗3: 引き継ぎ期間を短く見積もりすぎる
問題: 「1ヶ月で引き継ぎできる」と思っていたら実際は3ヶ月かかった、というケースは多くあります。特にドキュメントが不足しているシステムや、複数の外部サービスと連携しているシステムは時間がかかります。
対策: 引き継ぎ期間は余裕を持って設定しましょう。複雑なシステムは3ヶ月以上を見込むのが安全です。また、引き継ぎ完了の判断基準（「独立して○○ができる状態になったら完了」）を事前に決めておきましょう。
まとめ
システム引き継ぎを成功させるためのポイントをまとめます。
- 引き継ぎ前に7項目のドキュメントを整備する（システム概要・技術スタック・アーキテクチャ図・ソースコード・認証情報・既知問題・関係者一覧）
- 外部委託の場合は技術スタックを確認してから会社を選ぶ
- 引き継ぎ期間は余裕を持って設定する（複雑なシステムは3ヶ月以上）
- 費用の目安（外部委託の場合、移管調査に30〜100万円、年間保守に開発費の10〜15%）
システム引き継ぎでお困りの場合は、ぜひ秋霜堂にご相談ください。TechBandでは、他社が開発したシステムの現状調査から保守・継続開発まで、一貫したサポートを提供しています。
また、「保守会社を変更する際の引き継ぎ」について詳しく知りたい方は、「システム保守の引き継ぎで失敗しないための完全ガイド」もあわせてご覧ください。
引き継ぎ時に確認すべき項目をまとめた「失敗しないためのシステム保守の引継ぎチェックリスト」も無料でダウンロードできます。ぜひご活用ください。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
