「いつもの担当さんが辞めて、引き継いだ人と話が通じない」「修正依頼を出したら見当違いの対応が返ってきた」——発注したシステム会社のエンジニアが退職した直後によく起きる現象です。中小ベンダーや個人開発色の強い体制では、1人のエンジニアが要件・設計・実装・運用を全て握っていることが珍しくなく、その人が辞めた瞬間に「会社単位の知見」が消失します。本記事では、属人化が招くトラブルの構造、発注前に見抜く5つのチェック、退職リスクを織り込んだ契約と運用の組み方を、経営者目線で整理します。
この記事の結論（3行）
- 担当者退職トラブルは「ベンダー選び」ではなく「属人化を許す契約」が根本原因
- 発注前に体制チェック5点（チーム人数・ドキュメント・引き継ぎ手順・主担当複数化・退職時のSLA）を確認
- 既に属人化している案件は、設計書再構築・第三者レビュー・段階的引き継ぎの3手で復旧可能
なぜ担当者の退職でシステム会社と話が通じなくなるのか
属人化したシステム発注では、担当エンジニアが「会社全体の窓口」を兼ねていることが多くあります。要件のヒアリングから設計・実装・テスト・運用までを1人が担当し、社内に共有するドキュメントも最低限。この体制で担当者が退職すると、後任に引き継がれるのは「ソースコードと簡単なメモ」だけになり、要件の背景や設計の意図が失われます。
- 担当者の頭の中にしか「要件の背景」が存在しない
- ソースコードは引き継げてもビジネスロジックの意図は引き継げない
- 引き継ぎ期間を設けないまま退職してしまう
経営者から見ると「ベンダー選びを間違えた」と映りますが、実態は「属人化を許す契約と発注の仕方」が根本原因です。同じベンダーでもチーム体制と引き継ぎ手順が整っていれば、退職トラブルは大幅に減らせます。
担当者の頭の中にしか「要件の背景」が存在しない
システム開発では、要件の背景にある「なぜそうしたか」が後の保守で重要になります。「この計算ロジックは税理士の指摘で5年前に変更した」「この権限制御は監査対応で必須」といった背景情報は、ドキュメント化されていないと担当者の頭の中にしか残りません。退職すると一緒に消えるため、後任が誤った修正をしてしまうリスクが高まります。
ソースコードは引き継げてもビジネスロジックの意図は引き継げない
ソースコードは形式的に引き継がれても、なぜそのロジックを書いたかという意図は引き継がれません。後任エンジニアが「無駄なコードだ」と判断して削除した結果、業務に重大な影響が出るケースが散見されます。コメントが充実していても、業務的な意図までは網羅されないことが大半です。
引き継ぎ期間を設けないまま退職してしまう
中小ベンダーでは退職決定から実際の退職日まで2週間〜1カ月程度しかなく、引き継ぎ期間がほぼ確保できないケースが目立ちます。後任が決まっていない、引き継ぎ書類を作る時間がない、退職者本人が「次の仕事に意識が向いている」など、構造的に引き継ぎが薄くなる要因が重なります。
加えて、退職者が「自分が抜けた後の混乱に責任を負わなくて済む」立場にあることも見過ごせません。引き継ぎが不完全でも退職金や給与に影響しない構造であれば、人として悪意はなくても結果として手薄になります。発注側がベンダー側に「引き継ぎ完了の確認」をどう義務付けるかが、トラブル発生確率を左右します。
属人化を見抜く体制チェック5点
発注前に確認すべき体制チェックを5点にまとめます。発注先候補のベンダーに、これらを質問してみてください。
| チェック項目 | 質問例 | 危険度 | |---|---|---| | チーム人数 | 当案件を担当するチームの人数とロールは？ | 高 | | ドキュメント標準 | 設計書・運用手順書のテンプレートはありますか？ | 高 | | 引き継ぎ手順 | エンジニア離任時の引き継ぎフローは？ | 高 | | 主担当の複数化 | 副担当を配置できますか？ | 中 | | 退職時のSLA | 退職時の対応期日は契約に明記されますか？ | 中 |
5項目全てに明確な回答ができるベンダーは、属人化リスクを構造的に抑えていると判断できます。質問への回答内容を項目別に整理してから業者を選定する流れがお勧めです。
チーム人数とロール構成
「当案件を担当するチームは何人で、誰がどのロールを担うか」を最初に確認してください。営業1人・開発1人の2人体制で完結している場合は、属人化リスクが極めて高い状態です。理想は営業・PM・開発・QA・運用の5ロールが分かれていることですが、中小ベンダーでは「開発リーダー＋メンバー＋運用窓口」の3ロール構成があれば十分です。
ドキュメント標準とテンプレート
「設計書・運用手順書・テスト仕様書のテンプレートはありますか」と聞いてください。テンプレートが存在するベンダーは、ドキュメント文化が組織に根付いている証拠です。「案件ごとに違う」「特に決まっていない」と回答するベンダーは、納品物のドキュメント品質が担当者依存になります。
エンジニア離任時の引き継ぎフロー
「エンジニアが離任するときの引き継ぎフローはどうなっていますか」と質問してください。即答できるベンダーは、過去に離任を経験し、再発防止策を組織的に組み込んでいる証拠です。「特にフローはない」「都度対応している」と回答する場合は、属人化リスクが残ったままです。
主担当の複数化と副担当配置
主担当に副担当を1人配置してもらえるかを確認してください。費用が増えるケースもありますが、副担当が「設計レビュー」「テスト確認」「定例参加」を兼務すれば、主担当退職時の引き継ぎがスムーズです。中小ベンダーで副担当配置が難しい場合は、最低でも「主担当の作業を週次でレビューする上位者」を立てる契約にしてください。
退職時のSLA契約
「担当者の退職や離任が発生した場合の対応期日を契約に明記してほしい」と要望してください。具体的には「30日以内に後任を配置」「引き継ぎ期間として20日以上を確保」などです。SLAに明記されていれば、退職トラブル時の対応根拠になります。
SLAを契約に組み込むと、ベンダー側もそのリスクを織り込んで体制設計を行います。結果として、副担当の配置やドキュメント整備が自然と進む副次効果が期待できます。SLAは「ベンダーを縛るもの」ではなく「ベンダーのリスク管理を促すもの」と捉えてください。
経営者目線で考える「属人化を許さない発注の作り方」
属人化リスクは、ベンダー側だけでなく発注側の発注の作り方にも原因があります。経営者が意識すべきは3点です。
第一に、「コミュニケーション窓口の冗長化」です。打ち合わせや定例に発注者側から2名以上が参加するルールを作ってください。1人で対応していると、その人の退職や異動で発注者側の知見も失われます。第二に、「ドキュメント納品の契約明記」です。設計書・運用手順書・テーブル定義書を納品物に明記してください。費用が30〜50万円増えるケースもありますが、3年後の保守継続性を考えれば十分に元が取れます。第三に、「窓口移転権の確保」です。ベンダー側の担当が変わった場合に、別ベンダーへ移転判断できる契約条項を入れてください。
特に2つ目が肝心です。ドキュメント納品費用を惜しんで発注すると、3年後に「保守できる人がいない」状態に陥ります。発注時点で30万円のドキュメント費用を払うか、3年後に300万円の再構築費を払うか、長期的な経済合理性で判断してください。発注前に契約条件を整えたい場合は、業務改善・システム見積もりAI適正診断で具体的な条項案まで整理できます。
ぷらすわんの実例：副担当配置と週次レビューで属人化を防ぐ
ある飲食業A社の場合、別ベンダーで在庫管理システムを発注後、主担当エンジニアが半年で退職し、後任との会話が成立しない状態に陥っていました。「税抜き計算のロジック」「閉店時の在庫補正処理」「複数店舗の集計ルール」など、業務固有の要件がドキュメント化されておらず、後任は「コードを読んだ印象」だけで対応していたため、リリース後に在庫数値の不整合が連発しました。
A社の事例で原因だったのは、発注時の体制設計でした。主担当1名のみ、副担当なし、ドキュメント納品なし、退職時のSLAなし——全てが「属人化を許す契約」になっていたのです。最終的にぷらすわんが第三者レビューに入り、業務ロジックを聞き取りで再構築。設計書を新たに作成し、別ベンダーへ段階的に引き継ぐ流れで業務復旧しました。聞き取り再構築だけで2カ月・150万円の追加費用が発生した事例です。
この案件で得た教訓は、発注時点で「副担当配置」と「週次レビュー」を契約に組み込むだけで、属人化リスクは半分以下に抑えられる、というものでした。ぷらすわんでは新規発注の支援時、こうした2点を契約条件として推奨しています。
副担当配置の追加費用は月額3〜5万円程度、週次レビューの追加費用は月額2〜3万円程度が相場です。合計で月額5〜8万円の保険料を払うかたちですが、属人化トラブルが起きた場合の復旧費用（A社の例では150万円）と比較すれば、20カ月程度で元が取れる計算になります。経営判断としては安価な保険と捉えられます。
既に属人化している案件を立て直す3手
すでに担当者退職トラブルに直面している経営者の方へ、立て直しの3手を整理します。
- 設計書の再構築を別ベンダーに依頼する
- 第三者レビューで現状の品質を可視化する
- 段階的引き継ぎで業務継続性を担保する
順番が重要です。いきなり別ベンダーに引き継いでも、現状のシステムが理解できなければ移行できません。
設計書の再構築を別ベンダーに依頼する
現状のソースコードと業務担当者へのヒアリングをもとに、設計書を「逆引き」で再構築する作業を別ベンダーに依頼してください。費用は30〜100万円程度、期間は1〜2カ月。これがあれば後の引き継ぎや改修判断が現実的になります。設計書再構築なしで引き継ぎを進めると、後任ベンダーの工数が大幅に膨らみます。
第三者レビューで現状の品質を可視化する
ソースコードの品質、テストカバレッジ、セキュリティ脆弱性、運用環境の健全性を第三者ベンダーにレビューしてもらってください。費用は20〜50万円程度。レビュー結果をもとに「改修すべき優先順位」「引き継ぎ可否」「再構築判断」が具体化します。第三者レビューを比較を依頼する場合は、3社程度から見積もりを取って判断基準を揃えてください。
段階的引き継ぎで業務継続性を担保する
設計書再構築と第三者レビューが揃ったら、別ベンダーへの段階的引き継ぎを進めます。「障害対応のみ別ベンダー」「軽微な修正は別ベンダー」「機能追加は別ベンダー」と段階を分けることで、業務継続性を保ちながら移行できます。一気に切り替えると、移行期間中の障害対応が止まるリスクがあります。
段階的引き継ぎの目安は、フェーズ1が1〜2カ月、フェーズ2が2〜3カ月、フェーズ3が3〜6カ月程度です。トータル6〜11カ月かかりますが、業務影響を最小限に抑えながら移行できる現実的な進め方です。性急な移行ほど、再障害や再属人化を招きやすい点に注意してください。
まとめ
担当者の退職でシステム会社と話が通じなくなる悲劇は、ベンダー選びの問題というより、属人化を許す契約と発注の作り方が根本原因です。発注前に体制チェック5点（チーム人数・ドキュメント・引き継ぎ手順・主担当複数化・退職時のSLA）を確認しておくだけで、リスクは大幅に下げられます。
経営者の視点で重要なのは、属人化を防ぐ契約条件を「コスト」ではなく「保険」として捉えることです。副担当配置・ドキュメント納品・窓口移転権の3点を発注時に組み込めば、3年後の継続性が安定します。既に属人化している案件は、設計書再構築・第三者レビュー・段階的引き継ぎの3手で復旧可能です。発注先の体制を整理したい場合は、診断する流れから始めてください。