システム担当者の退職・引き継ぎで「誰も分からない」を防ぐ方法とチェックリスト

「システムを作った担当者が辞めてしまい、いざ直そうとしたら誰も中身が分からない」——これは受託開発・社内開発を問わず、非常に多く起きるトラブルです。原因は担当者個人ではなく、引き継ぎに必要なものが揃っていないことにあります。この記事では、なぜ引き継げなくなるのか、退職やベンダー撤退で起きるトラブル、そして「誰も分からない」を防ぐために発注段階から揃えておくべきものを解説します。

「担当者が辞めたら誰も分からない」システムの引き継ぎ問題

システムの引き継ぎ問題とは、そのシステムを作った・運用していた人がいなくなった途端に、社内の誰も中身を把握できなくなる状態のことです。日々動いているうちは表面化しませんが、担当者の退職や開発会社の交代をきっかけに、一気に噴き出します。

よくあるのは次のような場面です。

• 社内で作った担当者が転職し、修正しようにも手を付けられる人がいない
• 発注先の開発会社が廃業・撤退し、改修も障害対応も引き受け先がない
• 担当者が長期休職し、その間にシステムが止まったが誰も直せない
• 外部サービスのログイン情報が本人しか知らず、更新もできない

これらに共通するのは、システムそのものは正常でも、「動かすための知識と権限」が特定の人と一緒に消えてしまうという点です。建物にたとえるなら、建物は無事なのに鍵と設計図を持った管理人が突然いなくなり、中に入ることも修繕することもできなくなるようなものです。

引き継ぎ問題は、担当者が誠実かどうかとは関係なく起こります。むしろ真面目に一人で回してきた人ほど、知識がその人に集中し、抜けたときの影響が大きくなりがちです。だからこそ、個人の努力ではなく仕組みで備えることが必要になります。

なぜシステムは引き継げなくなるのか（4つの原因）

引き継げなくなる原因は、大きく4つに整理できます。どれか一つでも厄介ですが、複数が重なると引き継ぎは事実上不可能になります。

原因	どういう状態か	起きやすいケース
属人化	手順やノウハウが特定の人の頭の中だけにある	一人の担当者に運用を任せきりにしていた
ドキュメント不足	仕様書・設計書・手順書が残っていない	忙しさの中で「動けばよい」で進めた
ソースコード非開示	プログラムの実物・権利が手元にない	権利の帰属を契約に書かず発注した
作った人しか分からない構造	独自の作りで、他の人が読み解けない	その人の慣れたやり方だけで組まれている

それぞれ、もう少し具体的に見ていきます。

• 属人化：一番の根っこがこれです。「あの設定はどうなっているか」「なぜこの処理をしているか」が本人の記憶にしかないと、辞めた瞬間に問い合わせ先が消えます。
• ドキュメント不足：仕様書や設計書、運用手順書がないと、後任者は動いているものを見て中身を推測するしかありません。推測には時間がかかり、誤った修正で新たな障害を生むこともあります。
• ソースコード非開示：プログラムの実物と、それを自由に使う権利が手元になければ、後任の誰であっても改修に着手すらできません。これは社内・社外を問わず起こります。
• 作った人しか分からない構造：世の中で広く使われていない独自のやり方で組まれていると、他の技術者が読んでも意図をつかめず、引き継ぎコストが跳ね上がります。

これらは特別な失敗ではなく、忙しい現場で「とりあえず動かす」を優先した結果として、自然に積み上がっていきます。だからこそ、意識して潰しにいく必要があります。開発の発注の流れの早い段階で、引き継ぎの前提を決めておくのが有効です。

退職・ベンダー撤退で実際に起きるトラブル

引き継ぎができていないと、担当者の退職やベンダーの撤退をきっかけに、次のようなトラブルが連鎖的に起きます。

トラブル	具体的に起きること	事業への影響
改修できない	項目一つ足すのにも中身が読めず着手できない	業務変更や制度改正に対応できない
障害対応できない	止まった原因を調べられる人がいない	復旧が遅れ、業務や売上が止まる
パスワード不明	管理画面や外部サービスに入れない	更新・支払い・設定変更ができない
費用が不透明になる	現状が分からず、後任の見積りが高額化	想定外の出費が発生する
データを取り出せない	保存先や構造が分からない	移行も再構築も進められない

とくに深刻なのが「パスワード不明」です。システム本体だけでなく、外部サービスやサーバーのログイン情報が本人しか知らないと、支払いの更新やドメインの管理すらできなくなります。契約が切れてサービスが止まる、というかたちで突然表面化することもあります。

具体的には、こんなケースが典型です。

例：担当者退職で改修が止まったケース（一般化した例） 社内で一人がシステムを作り運用していたが、その人が転職。半年後に法改正で項目を追加する必要が出たものの、仕様書もソースコードの整理もなく、外部サービスのログイン情報も分からない。外部の会社に相談しても「中身が分からないので調査から」と言われ、想定の何倍もの費用と期間がかかった——。

金額の大小以前に、「すぐに直せない・止まっても対処できない」という状態そのものが、事業にとって大きなリスクになります。使われないシステムと同じく、引き継ぎ不全も後からじわじわ効いてくる落とし穴です。

引き継ぎに必要なもの5点セット（引き継ぎ資料チェックリスト）

引き継ぎ問題は、担当者がいるうちに次の5点を揃えておくだけで、大きく防げます。これは社内・社外どちらの引き継ぎでも共通する「最低限そろえるもの」です。

そろえるもの	中身	なぜ必要か
仕様書	画面・機能が何をするかの説明	後任が全体像を把握できる
設計書	データの構造・外部連携のつなぎ方	影響範囲を読めて安全に直せる
アカウント一覧	管理画面・サーバー・外部サービスのログイン情報	誰でも入って操作・更新できる
ソースコード	プログラムの実物と自由に使える権利	別の会社・人でも改修できる
保守先の情報	現在の運用・保守の連絡先と契約内容	困ったときの相談先が分かる

チェックリストとして、次を確認してください。

• 仕様書：主要な画面と機能の役割が文書で残っているか
• 設計書：どんなデータをどう持ち、外部と何をつないでいるかが分かるか
• アカウント一覧：ログイン情報が一覧化され、本人以外もたどれるか
• ソースコード：実物を受け取り、権利が自社にあるか
• 保守先の情報：保守・運用の連絡先と契約内容が控えてあるか
• 外部サービスの契約情報：ドメイン・サーバー・有料サービスの契約者と支払い方法が分かるか
• データの持ち出し方法：必要な情報を書き出す手順があるか

大切なのは、これらが口頭ではなく文字で、本人以外もアクセスできる場所に残っていることです。担当者本人のパソコンやメールの中だけにあるのでは、いなくなった時点で失われてしまいます。共有フォルダや管理台帳など、組織として保管する場所を決めておきましょう。

内製担当が抜ける場合と外注先が変わる場合

引き継ぎには、大きく「社内で作った担当者が抜ける場合」と「外注していた開発会社が変わる場合」の2パターンがあります。そろえるべきものは共通ですが、回収の進め方が異なります。

観点	内製担当が抜ける場合	外注先が変わる場合
主なリスク	知識が本人の頭の中に集中	成果物・権利が発注側にない
回収先	本人（在職中に文書化）	契約と開発会社からの引き渡し
動くタイミング	退職が決まったらすぐ	契約時、遅くとも解約前
要点	手順とアカウントの棚卸し	ソースコードと仕様書の受領

• 内製担当が抜ける場合：最大の武器は「本人がまだ在職している時間」です。退職が決まったら、本人に手順書を書いてもらい、アカウント情報を棚卸しし、可能なら後任と並走期間を設けます。辞めてから連絡を取るのは難しくなるので、在職中にどれだけ文書化できるかが勝負です。
• 外注先が変わる場合：ここで効くのは契約です。成果物（ソースコード）の権利が発注側に移るか、仕様書・設計書が納品物に含まれるかを、あらかじめ決めておきます。すでに発注済みで曖昧な場合は、開発会社の選び方や危ない開発会社の見分け方を参考に、解約や引き渡しの条件を早めに確認しておきましょう。

どちらのパターンでも共通する鉄則は、「本人・その会社がいなくなる前に動く」ことです。いなくなってからでは、情報を集めるコストも交渉の難しさも一気に上がります。内製と外注の比較も、体制を考えるうえで参考になります。

発注段階で「引き継げる形」で作ってもらう

引き継ぎ問題への最も効く対策は、実は発注する段階で「引き継げる形」で作ってもらうことです。作り終わってから資料を揃えるより、最初から引き継ぎを前提にしておくほうが、はるかに確実で安く済みます。

発注時に確認・依頼しておきたいのは、次の点です。

• ソースコードを納品物に含める：完成したプログラムの実物を受け取り、権利が自社に移る（または自由に使える）ことを契約に明記します。
• 仕様書・設計書を残してもらう：画面・機能の説明と、データ構造・外部連携の情報を、納品物として文書で残してもらいます。
• 一般的な技術で作ってもらう：広く使われている技術なら、後から別の会社やフリーランスでも対応できます。独自の作りは引き継ぎの壁になります。
• アカウントは発注側で管理：外部サービスやサーバーの契約・ログイン情報を、最初から発注側の名義・管理にしておきます。
• 引き継ぎ条件を契約に入れる：保守の解約時に、データとソースコードを引き渡してもらう条件を決めておきます。

これらは特別な要求ではなく、誠実な開発会社であれば「もちろんお渡しします」と即答する内容です。逆に、成果物の引き渡しや権利の帰属を濁す会社は要注意です。発注前の確認ポイントは見積書の見方や要件定義の段階で押さえておくと、納品物の範囲が曖昧なまま契約する事故を防げます。

**「引き継げる形」で作るコスト自体は、ほとんどかかりません。**必要なのは、着手前に納品物の範囲と権利を明確にしておくことだけです。この一手間が、数年後に担当者や会社が変わったときの安心につながります。

ベンダーロックインとの関係

引き継ぎ問題は、ベンダーロックイン（特定の会社に依存して抜け出せない状態）と根が同じです。どちらも「成果物や情報が発注側にない」ことから生まれます。ただし、着目点が少し異なります。

観点	引き継ぎ問題	ベンダーロックイン
きっかけ	担当者の退職・撤退	乗り換えたいのにできない
困りごと	誰も中身が分からない	言い値で払い続けるしかない
共通の根っこ	ソースコード・ドキュメント・権限が手元にない
共通の対策	成果物・仕様書・権利・アカウントを発注側が持つ

つまり、引き継ぎ資料を揃えておくことは、そのままロックインの予防にもなります。ソースコードと仕様書、そして権利が手元にあれば、担当者が変わっても引き継げますし、別の会社に相見積もりを取ることもできます。逆にこれらがないと、引き継ぎもできず、今の会社に頼み続けるしかなくなる——という二重の不利益が生じます。

引き継ぎとロックインは、いわば同じ問題の裏表です。「本人・その会社がいなくても回せる状態」を保っておくことが、両方への最良の備えになります。将来システムを入れ替えたくなったときの進め方はリプレースの解説、機能を足したくなったときは追加開発の解説もあわせてご覧ください。

D-oneAppの考え方

D-oneAppは、成果物（ソースコード）とドキュメントをお渡しし、担当者や会社が変わっても引き継げる形を基本としています。料金も一律100万円（大規模なプロプランは一律200万円）で総額が固定。「囲い込んで高く売る」構造ではなく、必要なものを明朗な金額でお渡しする立場です。

• ソースコードの権利は発注側へ：作ったものは実物ごとお渡しします。将来どの会社に頼んでも改修できる状態が前提です。
• 仕様書・ドキュメントを残す：後任者が全体像をつかめるよう、機能とデータ構造の情報を文書で残します。
• 一律料金で追加費用なし：着手前に総額が確定するため、引き継ぎ後に「調査費」や「言い値の改修費」で膨らむ構造がありません。

なぜこの立場かというと、引き継げる形で渡しておくほうが、結果的に発注側にとって安心して頼める関係になるからです。囲い込みで縛るのではなく、また頼みたいと思ってもらえるかどうかで選ばれる、という考え方です。

例：引き継ぎを前提に発注したケース（一般化した例） ある小規模事業者が業務システムを作る際、「担当が代わっても困らないように」とソースコードの権利・仕様書の納品・アカウントの自社管理を条件にした。数年後に社内の担当者が異動しても、後任が仕様書を見て運用を継続でき、機能追加も相見積もりを取って依頼できた——。

大がかりな仕組みでなくても考え方は同じです。100万円でできることの範囲でも、成果物とドキュメントを押さえておけば、担当者や会社が変わっても「誰も分からない」を防げます。

まとめ

システムの担当者退職・引き継ぎで「誰も分からない」に陥る原因は、属人化・ドキュメント不足・ソースコード非開示・作った人しか分からない構造の4つです。これらが重なると、退職やベンダー撤退をきっかけに、改修できない・障害対応できない・パスワード不明といったトラブルが連鎖します。防ぐには、仕様書・設計書・アカウント・ソースコード・保守先の5点を、担当者がいるうちに文書で揃えておくこと。そして最も効くのは、発注段階から「引き継げる形」で作ってもらうことです。

引き継ぎとベンダーロックインは同じ問題の裏表で、共通の答えは「本人・その会社がいなくても回せる状態を保つ」こと。成果物と権利、ドキュメントが手元にあれば、担当者が変わっても慌てずに済みます。引き継げる発注のしかたに不安があれば、無料相談でお気軽にご相談ください。