「属人化したシステム」が退職をきっかけにブラックボックス化から立ち直るまで — よくある課題と解決パターン
詳しい社員一人に依存してきた業務システムが、退職を機にブラックボックス化のリスクに気づき、保守体制を立て直す一般的な流れを解説する。
「属人化したシステム」がブラックボックス化から立ち直るまで
中小企業でよく見られる課題パターンとして、社内に一人だけいる「詳しい人」が独力で構築した業務システム(販売管理、在庫管理など)に、会社全体が長年依存し続けているケースがある。その人物が退職や異動をする段階になって初めて、誰もソースコードやサーバーの管理方法を把握していないという事実が発覚する。
本記事は特定の企業の事例ではなく、中小企業に共通してよく見られる課題と解決の流れを一般化した解説である。登場する会社・数値・エピソードはいずれも典型例として構成したものであり、実在の特定企業を描写するものではない。
典型的な状況設定
従業員40名規模、卸売・小売業を想定する。10年以上前、当時在籍していたITに詳しい社員が、業務の効率化のために独自に販売管理システムを構築し、以後もその人物が一人で改修・保守を続けてきた。システムは業務に深く組み込まれており、日々の受発注・在庫管理はこのシステムなしには回らない状態になっている。
課題の構造
このパターンの本質は「属人化」にある。構築した本人以外、ソースコードの所在、サーバーやドメインの契約情報、管理画面のログイン情報、そして「なぜこの処理はこう動くのか」という仕様の背景を誰も把握していない。本人が退職の意向を伝えた瞬間、会社は初めてこのリスクの大きさに気づくことが多い。
あわせて、システムの利用アカウントやサーバーの契約が本人の個人名義・個人メールアドレスになっていたり、サーバー代を本人が個人的に立て替えていたりするケースもよくある。業務システムでありながら、会社として契約主体になっていない状態は、このパターンで頻出する構造的な問題である。
さらに厄介なのは、システムが完成してから長い年月が経つ間に、業務ルール自体がシステムの挙動に合わせて変化してきている点である。「このシステムはこういう動きをするから、現場ではこう運用している」という暗黙の運用ルールが積み重なっており、システムだけを見ても業務全体は理解できない。本人の頭の中にしかない情報が、コードと現場運用の両方に分散している状態が、引き継ぎを一層難しくしている。
検討した選択肢の比較
| 選択肢 | 費用感 | リスク | 向いているケース |
|---|---|---|---|
| 現行維持+ドキュメント整備 | 数十万円程度 | 属人化リスクは残る | 退職までの時間が短い場合の応急対応 |
| 保守を外部委託 | 月額数万〜十数万円 | 引き継ぎの質に依存 | システム自体は使い続けたい場合 |
| リプレース(作り直し) | 数百万円〜 | 移行期間中の業務影響 | 老朽化・機能不足が深刻な場合 |
| SaaS(既製サービス)へ移行 | 月額数万円〜 | 自社独自の業務フローに合わない可能性 | 業務が標準的なパターンに近い場合 |
典型例では、退職までの残り期間が数ヶ月しかないため、まず現行維持+ドキュメント整備で最低限のリスクを下げつつ、並行して保守の外部委託先を探す、という二段構えの進め方がよく取られる。将来的なリプレースを検討する場合は、発注完全ガイドや人月とは何かを読み、規模感を把握しておくと外部との会話がスムーズになる。
実際の進め方(退職前引き継ぎ期間の使い方)
- 退職意向確認直後: ソースコード、サーバー・ドメインの契約情報、管理画面ログイン情報の洗い出しと会社名義への切り替え
- 1ヶ月目: 本人へのヒアリングをもとに、システム構成図・処理フローの簡易ドキュメント化
- 2ヶ月目: 外部の保守委託先候補への相談、保守の完全ガイドを参考に委託範囲を整理
- 3ヶ月目: 委託契約締結、本人同席での引き継ぎミーティング
- 退職後: 外部委託先による保守運用開始、必要に応じてリプレース検討を並行開始
費用感
ドキュメント整備や引き継ぎ支援の一般的な費用感は数十万円〜100万円程度、外部委託による月次保守は月額数万〜十数万円程度が目安になることが多い。リプレースまで踏み込む場合は数百万円規模になることもあり、システムの規模や移行範囲によって幅が大きい。いずれも会社によって差が大きいため、複数社から見積もりを取り、比較検討することが望ましい。
特にドキュメント整備や引き継ぎ支援は、作業範囲があいまいなまま依頼すると「どこまでやってもらえるのか」で後からトラブルになりやすい。ソースコードの解析範囲、ヒアリング回数、成果物の形式(構成図・仕様書・運用手順書など)を事前に取り決め、契約書に明記しておくことが望ましい。
つまずきやすいポイント
- 本人しか知らない「暗黙の仕様」(なぜこの条件分岐があるのか等)が、引き継ぎ資料に反映されないまま退職してしまう
- サーバーやドメイン、管理画面が個人アカウント・私物端末に紐づいており、退職後にアクセスできなくなる
- 契約書や開発契約の基本を確認しないまま長年運用しており、著作権や再委託の可否が不明確
- 引き継ぎ期間を十分に確保できず、退職直前に駆け込みで対応することになる。失敗あるあるにも共通するパターンとして挙げられる
- 退職後に軽微な不具合が発生した際、対応できる相手がおらず、業務が一時的に完全停止するリスクを見落としていた
よくある質問
退職の意向を聞いた直後に最初にすべきことは?
ソースコード一式、サーバー・ドメインの契約者情報、各種管理画面のログイン情報を洗い出し、可能な限り会社名義のアカウントに切り替えることが優先度が高い。
ドキュメントが全くない場合でも引き継ぎは可能か?
完全なドキュメントがなくても、本人へのヒアリングを重ねて主要な処理フローだけでも簡易的に記録しておくことで、その後の保守委託や改修の難易度を大きく下げられる。
リプレースと保守委託、どちらを優先すべきか?
退職までの時間が短い場合は、まず保守委託でリスクを下げてから、時間をかけてリプレースを検討する二段階のアプローチが取られることが多い。
まとめ
「属人化したシステム」問題は、担当者が在籍している間は表面化しにくいが、退職や異動のタイミングで一気に会社全体のリスクとして露呈する。退職の意向を把握した時点で、ソースコードやアカウント情報の棚卸しを最優先で行い、限られた引き継ぎ期間をどう使うかが、その後の立て直しの速度を左右する。
この課題は一人の退職がきっかけで表面化することが多いが、本質的には特定の担当者に依存せずシステムを回せる体制をどう作るかという、より長期的な経営課題でもある。引き継ぎを乗り切った後も、ドキュメントを更新し続ける仕組みや、複数人が触れる体制を維持できるかどうかが、同じ問題を繰り返さないための分かれ目になる。
この記事に関連する無料ツール(登録不要・その場で結果)
お気軽にご相談ください
お問い合わせ