「このシステム、実は〇〇さんしか分かってないんですよ」
システム保守を担当する情報システム部門から、こんな話を聞くことは珍しくありません。
むしろ、多くの企業でこれが常態化しています。
入社15年の担当者が1人で管理しているシステム。彼が休むと問い合わせに対応できない。彼が異動、ましてや退職したら…考えたくもない。
こうした「属人化した保守運用」は、企業のリスク管理の盲点になりやすい。数年は何とか回る。しかし、いつかは限界が来ます。
その限界が、外部への移管や継続開発の検討を迫られたとき、初めて顕在化する。
「知っている人」が不在になると何が起きるか
保守運用が1人に依存する状態は、表面的には「効率的」に見えます。
- 意思決定が早い
- 余計な説明や報告がない
- 別のドキュメント化のコストもない
しかし、実際には深刻なリスクを抱えています。
1. 業務継続性の喪失
担当者の退職、長期休暇、配置転換などが起きた時点で、保守業務そのものが止まります。応急対応すらできないケースも多い。
2. 改修・改善が進まない
本来なら既存システムの不具合を直したり、老朽化した部分を更新したりすべきところが、「とりあえず動いている」という理由で放置される。技術債が膨らみ続ける。
3. 企業判断ができない
このシステムは本当に必要なのか。他のシステムと統合すべきなのか。外部に保守委託できるのか。そもそも廃止を検討すべきなのか。
こうした経営判断が全くできません。現場の「継続してほしい」という声だけが根拠になる。
4. 移管や外注の話が出たときに初めて気づく
多くの場合、「人員削減」「コスト最適化」「部門統廃合」といった経営判断が下されたときに、初めて「このシステム、実は全貌が分かっていない」ことに気づきます。
その時点で、外部への移管は非常に困難になっている。
なぜ起きるのか：仕様書も手順もない構造
属人化が進む背景には、いくつかの構造的な問題があります。
システムが複雑すぎて、仕様書化できない
当初は仕様書があったかもしれません。しかし、15年の運用の中で、要望、パッチ、改修が積み重なり、仕様書は陳腐化。やがて誰も修正しなくなり、信用を失う。
最後には「仕様書は参考程度。実際の運用ルールは暗黙知」という状態に。
手順が形式知化されていない
「この状況になったら、〇〇に連絡して、〇〇というファイルを編集して…」といった運用の詳細は、すべて担当者の頭の中。
緊急時の対応手順も、トラブルシューティングも、ドキュメントには書かれていない。
「今のやり方が正しい」という確信がない
本当にこのアプローチが最善なのか。別のシステムなら同じ問題にどう対応しているのか。
比較検討の機会がないまま、「今まで通り」が踏襲される。
外部の目が入らない
保守ベンダーとの契約終了後、社内で完全に管理するようになると、外部からのレビューが途絶えます。
いつの間にか、業界標準から外れたやり方に。セキュリティも古いままに。
よくある失敗パターン
属人化が問題だと気づいた企業は、以下のような対応を取りがちです。
1. いきなり大量のドキュメント作成を命令する
「あの人の知識をドキュメント化しよう」と意気込み、担当者に「保守マニュアルを作ってほしい」と依頼。
しかし、15年の知識を短期間でドキュメント化するのは不可能。担当者も本業が忙しい。結果、不完全で誰も読まないドキュメントが出来上がる。
2. 外部コンサルを入れて一気に整理する
「外部の専門家なら、素早く仕様を整理できるはず」と期待。
しかし実際には、そのシステムの全貌を外部の人間が理解するには、かなりの時間が必要。ドキュメント作成だけに終わり、実運用の理解は深まらない。
3. 「仕様書があれば外注できる」と考える
仕様書さえあれば、オフショアにでも移管できると考える経営層。
しかし、15年の運用知識は、仕様書では書ききれない。暗黙的な優先順位、例外処理、顧客対応の工夫など、文字化できない部分が大量に存在する。
4. 急いで丸投げしてしまう
「時間がない。とにかく外部に任せよう」と、不十分な説明のまま移管を進める。
結果、新しいベンダーは理解不足のまま保守開始。トラブルが増えて、コストが膨らむ。
現実的な解決策：「可視化」が移管の第一歩
属人化したシステムを外部に引き継ぐために、必要なアプローチは以下の通りです。
STEP 1: まず「可視化」する。ドキュメント化ではなく。
仕様書を完璧に作る必要はありません。まず大切なのは：
- ソースコードから仕様を逆推定する
- システムの全体像をアーキテクチャ図として示す
- データフローを可視化する
- 依存関係を明確にする
AI支援ツールを使えば、ソースコードから自動的に仕様の骨組みを抽出できるようになりました。完璧ではなくても、外部の人間が「何をしているか」を理解する出発点になる。
STEP 2: 日本側SEが、可視化した内容を検証・補足する
抽出された仕様が本当に正しいか。現場での運用ルールで漏れているものはないか。日本側の経験者が確認する。
ここで初めて「どの知識が属人化していたか」が浮き彫りになる。
STEP 3: 「並走型」で徐々に移管する
いきなり丸投げしない。日本側SEとオフショア開発チームが、一緒に保守運用を進める。
数ヶ月間、小さな改修から始めて、オフショアチームが徐々にシステムの文化や判断基準を学ぶ。
日本側SEは徐々に「指示する人」から「相談される人」へ。最終的には、オフショアチームが継続開発チームとして自走できる体制に。
STEP 4: 並走の中で、本当に必要な情報だけをドキュメント化する
「何でもドキュメント化する」のではなく、「実運用で実際に必要な情報」だけ。
トラブルシューティング、優先度の判断基準、顧客対応の注意点。こうした実践的な知識を、担当者とオフショアチームの対話の中から引き出す。
スマラボが推奨する保守運用の考え方も、同じです。
オフショアを「安い外注先」とするのではなく、「継続開発チーム」として扱う。
そのためには、段階的なアプローチが必要です。
- 第1段階：可視化（AIを活用したコード解析）
- 第2段階：並走型移管（日本側PM/SEとベトナム開発チームの協働）
- 第3段階：継続開発体制（チームの自走と継続的な改善）
属人化したシステムほど、いきなり移管するべきではありません。逆に、そうしたシステムだからこそ、丁寧な可視化と並走が必要です。
AI-DD時代だからこそ、ソースコード解析や影響範囲調査で保守移管の準備を加速できる。しかし、最後の判断と責任は、人間が担う必要があります。
担当者しか分からないシステムの外部移管は、実は珍しい課題ではありません。
むしろ、多くの企業がこの課題を先送りにしているだけです。
移管を成功させるために必要なのは：
- 可視化から始める（いきなりドキュメント化しない）
- 並走型で進める（丸投げしない）
- 段階的に進める（小さく始めて範囲を広げる）
- AIを活用する（ソースコード解析で可視化を加速する）
- 人間の判断を残す（最終判断はSEが行う）
この考え方を組織内で共有できれば、属人化の解消と継続開発体制の構築は十分現実的です。
自社の保守体制をどこからどう改善すべきか。属人化解消と継続開発体制構築の進め方をまとめた資料をご用意しています。
まずは「現状整理」から始めたいご担当者は、こちらからダウンロードしてください。
