担当者しか分からないシステムから脱却するには？属人化を解消する4つのステップ

「このシステムの中身は、あの担当者しか把握していない」そうした状態に心当たりのある企業は少なくありません。

日々の業務が回っているうちは大きな問題として表面化しませんが、担当者が休んだり退職したりしたタイミングで、業務が止まってしまうこともあります。

システムの属人化は、担当者個人の問題ではなく、組織として仕組みが整っていないことによって起こります。

そのため、「引き継ぎ資料を作ってください」と依頼するだけでは、解消につながりにくい面があります。

この記事では、システムが属人化する原因と放置した場合のリスクを整理したうえで、脱却に向けた具体的な進め方を解説します。

マニュアル整備で対応できるケースと、システム側の見直しを検討したほうがよいケースの判断軸についても触れますので、自社の状況に当てはめながら読み進めてみてください。

システムの属人化とは？

システムの属人化とは、システムの仕様や運用手順を特定の担当者しか把握しておらず、その人以外では対応が難しくなっている状態を指します。

「動かし方が分からない」というレベルにとどまらず、なぜその処理が必要なのか、どこを変更すると何に影響するのかといった判断まで、一人の頭の中に蓄積されている状態です。

現場では「詳しい人がいるから安心」と受け止められがちですが、組織としては依存度が高い状態といえます。

なお、属人化の多くは担当者の抱え込みではなく、業務に習熟した結果として自然に生じます。

問題となるのは、その状態が長期化して代わりが利かなくなったときです。

業務の属人化との違い

企業で問題になる属人化は、業務とシステムの観点に大別できます。

業務の属人化は、進め方をそろえて共有すれば改善が進むことがあります。

一方でシステムの属人化は、そもそも仕様が記録として残っていない場合、担当者の記憶をたどる以外に把握する手段がないケースもあります。

そのため、マニュアルを書こうとしても書ける人が一人しかいない、という状況に陥りやすい点が特徴です。

対策を検討する際は、どちらの属人化が起きているのかを切り分けておくと、打ち手を選びやすくなります。

属人化しやすいシステムの傾向

以下のようなシステムは、比較的属人化が進みやすい傾向があります。

• 現場担当者が個別に作成したExcelマクロやAccessのツール
• 開発当時の担当者が社内に残っていない基幹システム
• 度重なる改修によって、当初の設計から大きく変わってしまったシステム
• 少人数の情報システム部門、あるいは兼任担当者が運用しているシステム
• 外部ベンダーに任せきりで、社内に仕様を把握している人がいないシステム

共通しているのは、仕様を知る人が限られたまま長く使われている点です。

特に現場で作られたツールは正式なシステムとして管理されていないため、棚卸しの対象から外れやすくなります。

小さなツールでも請求処理や在庫管理に組み込まれていれば、止まったときの影響は小さくありません。

導入から年数が経ったシステムは、技術面の老朽化と属人化が同時に進むこともあり、詳しくは「レガシーシステムとは？放置リスクと今からできる脱却の進め方」で解説しています。

システムの属人化から脱却する4つのステップ

現状を把握したら、実際の解消に取り組みます。一度にすべてを解決しようとせず、段階的に進めることが現実的です。

1. ドキュメントを最低限の範囲から整備する

現状の整理と並行して、資料の整備を進めます。

このとき、完璧な設計書を目指すと途中で止まってしまうことが多いため、優先度の高い情報から着手します。

• 日常的に発生する定型作業の手順
• 障害やトラブルが起きた際の一次対応の流れ
• アカウント情報や権限設定の管理場所
• 外部ベンダーや関連システムとの連絡先および連携内容

これらは、担当者が不在になった際に真っ先に必要となる情報です。

システム内部の詳細な設計情報よりも、まずは「担当者がいなくても業務を止めずに済む」ための情報を優先すると、短期間で効果が出やすくなります。

作成した資料は、担当者以外の人が実際に読んで作業できるかどうかを確認しておくと、抜けに気づきやすくなります。

2. 運用ルールを標準化する

資料を整備しても、進め方が担当者ごとに異なっていては共有が定着しにくくなります。

作業依頼の受け方や記録の残し方といったルールを決め、全員が同じ手順で進められる状態にします。

標準化を支える手段としては、以下のようなツールが活用されています。

ツールの種類	主な役割
ナレッジ共有ツール	手順や対応履歴を蓄積し、検索できる状態にする
マニュアル作成ツール	操作画面を含む手順書を短時間で用意する
ワークフローシステム	申請や承認の流れを固定し、処理を記録に残す
IT資産管理ツール	社内のシステムや権限の状況を一覧化する

いずれも共有を進めやすくしますが、導入すれば属人化が解消するわけではありません。

ツールはあくまで共有を支える器であり、中に入れる情報を整理するのは自社側の作業になります。

記録すべき内容が定まらないまま導入すると、器だけが残り、運用されないまま終わってしまう場合もあります。

3. 担当者以外が触れる状態をつくる

資料とルールが整ったら、実際に他のメンバーが作業する機会を設けます。

読むだけでは分からない部分が出てくるため、手を動かすことで資料の不足に気づきやすくなります。副担当を置く、定期的に担当を入れ替える、対応内容を共有する場を設けるといった方法が考えられます。

最初は時間がかかりますが、ここを通過しないと資料が実務で使える状態かどうかを確認しにくくなります。

なお、担当者本人が共有に消極的に見える場合もありますが、その多くは抱え込みの意識ではなく、説明する時間を確保できないことが背景にあります。

共有のための時間を業務として見込んでおくと、取り組みが進みやすくなります。

対応件数を記録しておけば、負荷の偏りを客観的に示す材料にもなります。

4. システム側の見直しを検討する

ここまで進めても、システムそのものの構造に起因する属人化は残ることがあります。たとえば、改修が積み重なって処理の流れを追えなくなっている場合や、同じデータを複数の場所で管理している場合です。

こうしたケースでは、運用の工夫だけで解消することは難しく、システムの改修や再構築を検討する段階に入ります。

部分的な改修で対応できることもあれば、作り直したほうが結果的に早い場合もあり、現行システムの調査結果によって判断が変わります。

判断の材料としては、改修にかかる工数と、その業務を今後どれくらいの期間続けるのかを並べて考える方法があります。

移行の進め方や費用の考え方については、「システムリプレイスはいつ必要？必要性の判断基準と4つの移行方式」で整理しています。

システムが属人化する4つの原因

属人化の背景には、組織の構造や進め方に関わる要因があることが多く見られます。ここでは代表的な4つの原因を整理します。

1. 開発や改修の経緯が記録として残っていない

システムを改修する際、「なぜその仕様にしたのか」という判断の背景は、記録として残らないことが多くなります。

設計書に「この処理を行う」と書かれていても、「どの部署の要望で、どの業務ルールに対応するために追加したのか」までは残っていないケースも少なくありません。

打ち合わせのやり取りがメールやチャットに残っていても、後から探し出せる形で整理されていなければ、実質的には失われた情報に近い状態といえます。

この背景情報が失われると、後任者は変更してよいのかどうかを判断しにくくなります。

一見すると不要に見える処理でも、特定の取引先だけに必要な対応であることも珍しくありません。

結果として、触ると何が起きるか分からないため、当時を知る担当者に確認するしかない状態が固定化していきます。

2. 現場で個別に作られたツールが業務に組み込まれている

業務効率化の意識が高い現場ほど、担当者が自分で改善ツールを作ることがあります。

短期的には効果が出ますが、社内の開発ルールに沿っていないため、命名規則やコメントの書き方が独自のものになりがちです。

作成者にとっては分かりやすい構造でも、他の人が引き継ぐ際には解読作業から始まることになりがちです。

業務改善の成果として評価されてきた経緯があるため、見直しを提案しにくい空気が生まれる場合もあります。

さらに、ファイルが個人のパソコンや共有フォルダに置かれたままになりやすく、どれが最新版なのか分からなくなることもあります。

こうしたツールは資産管理台帳に載っていないことも多く、退職時の引き継ぎ対象から漏れてしまう場合があります。

3. 担当者に業務が集中し、共有する時間が確保できない

属人化した状態では、問い合わせや障害対応が特定の担当者に集まりやすくなります。

対応に追われることで、ドキュメントを整備する時間はさらに取れなくなり、属人化がいっそう進むという循環に陥りやすくなります。

とりわけ中小企業では、情報システム部門が独立しておらず、総務や経理の担当者が兼任しているケースも見られます。

兼任の場合は本来の業務が優先されるため、システムに関する情報を整理する時間はさらに確保しにくくなります。

近年はIT人材の不足も続いており、採用や増員だけで解決することは難しくなっています。

そのため、人を増やす前提ではなく、限られた人員の中で情報を共有できる仕組みを整える方向で検討する企業が増えています。

4. 仕様変更が繰り返され、資料と実態が一致しなくなる

改修のたびに設計書を更新する運用は、理想としては望ましいものの、現実には後回しになりやすい作業です。

急ぎの対応が続くと、システムだけが更新され、資料は古いまま取り残されがちです。

そして一度ずれが生じると、「資料は当てにならないので、担当者に聞いたほうが早い」という判断が定着しやすくなります。

こうなると資料は参照されにくくなり、更新する動機も失われていきます。

資料が実態と合っていない状態は、資料がない状態よりも危険な場合があります。誤った情報をもとに改修を進めると、想定していなかった業務に影響が及ぶこともあるためです。

以上の4つを見ると、いずれも個人の姿勢というより、記録や体制の仕組みに関わる問題であることが分かります。

属人化したシステムを放置することで起こりうるリスク

属人化は、日常業務が回っている間は問題として認識されにくいテーマです。しかし、以下のような形でリスクが表面化することがあります。

1. 担当者の退職や異動によって、業務が停止する
2. 障害発生時に原因の切り分けができず、復旧が長期化する
3. 改修や機能追加の見積もりが取れず、改善が進まない
4. アクセス権限や処理内容が不透明になり、内部統制上の課題となる
5. 業務改善やシステム連携の検討が進められなくなる

2つ目の障害対応、4つ目の内部統制、5つ目の連携の問題は、いずれも担当者の不在や仕様の不透明さが引き金になりがちです。

なかでも影響が大きく、相談として持ち込まれることが多いのが1つ目と3つ目のため、ここから詳しく見ていきます。

担当者の退職や異動で業務が止まる

もっとも分かりやすい形で表面化するのが、担当者がいなくなったタイミングです。

引き継ぎ期間が数週間しかない状態で退職が決まった場合、仕様の全体像を伝えきることは現実的に難しく、後任者は手探りで運用を始めることになりかねません。

日常の操作は引き継げても、年に数回しか発生しない処理や例外対応までは伝わりにくい傾向があります。

その状態で決算処理や繁忙期を迎えると、対応できる人がいないまま業務が滞ることもあります。

異動や休職でも同じことが起こるため、退職に限った話ではありません。

実際には、退職の申し出があってから慌てて引き継ぎに着手し、期間が足りずに一部を積み残したまま運用を続けるケースが多く見られます。

改修の見積もりが取れず、改善が進まなくなる

現行システムの仕様が説明できないと、開発会社は影響範囲を見積もれず、リスクを織り込んだ高めの金額を提示せざるを得ない場合があります。

その結果、改修費用が想定より膨らみ、必要な改善が先送りされることもあります。

見積もりを依頼しても「調査からの着手が必要」と返答され、話が進まないケースもあります。

新しいツールとの連携や自動化の検討も同様で、RPAによる業務自動化を進める場合も、処理内容が整理されていなければ対象を選びにくくなります。

なお、社内の担当者ではなく特定の外部ベンダーに依存が偏っている場合は、属人化とは別の観点での対処が必要です。

その場合は「ベンダーロックインとは？自社が陥っているか判断する5つの兆候」で整理していますので、参考にしてみてください。

システムの属人化はどこから手をつける？現状の整理方法

対策に着手する前に、まずどこから手をつけるかを決める必要があります。社内のシステムをすべて同時に見直すことは難しいため、依存度が高く影響の大きい部分から順に取り組む形が現実的です。

漠然と「属人化している」と捉えるのではなく、どの部分がどの程度依存しているのかを整理すると、優先順位をつけやすくなります。

人・情報・仕組みの3つの切り口で整理する

属人化の度合いは、次の3つの切り口で確認すると把握しやすくなります。

切り口	確認する内容
人	対応できる担当者が何名いるか、代替できる人材がいるか
情報	仕様書・運用手順書・アカウント情報が最新の状態で残っているか
仕組み	作業の記録が残る仕組みがあるか、権限が個人に集中していないか

「人」の観点では、形式上は複数名が担当になっていても、実際の作業がすべて一人に寄っていれば依存度が高い状態と判断できます。

「情報」の観点では、資料の有無だけでなく、内容が現在のシステムと一致しているかどうかまで確認したいところです。

最終更新日が数年前のまま止まっている資料は、実態と乖離している可能性を考慮する必要があります。

「仕組み」の観点では、作業履歴や変更履歴が残る運用になっているかを確認します。

業務とシステムの対応関係を可視化する

まず取り組みたいのが、どの業務がどのシステムで処理されているかの整理です。

システム単体を見るのではなく、業務の流れに沿って「入力する人」「処理する内容」「出力される情報」を並べていきます。

きれいな図にする必要はなく、表計算ソフトで業務名とシステム名、担当者を並べる程度でも十分に役立ちます。専用のツールを用意するより、手元の環境で早く形にすることを優先したいところです。

この作業を通じて、業務の流れの中でブラックボックスになっている箇所が見えてきます。

担当者へのヒアリングが中心になりますが、いきなり詳細を聞くのではなく、大きな流れから確認していくと負担を抑えられます。一覧の形にしておくと、担当者以外の人とも認識をそろえやすくなります。

対象システムを洗い出し、優先順位をつける

対応関係を整理できたら、そのうえで着手する順番を決めていきます。

• 止まったときに業務への影響が大きいシステムから着手する
• 担当者の退職や定年が近い領域を優先する
• 現場で個別に作られたツールも対象に含める
• 更新頻度が高く、変更が続いているシステムを見落とさない

基準としたいのは、影響範囲と緊急度の掛け合わせです。売上や請求に直結するシステムは、たとえ短時間の停止であっても影響が広範囲に及ぶことがあります。

一方で、担当者の異動時期が迫っている領域は、影響範囲が限定的であっても先に着手したほうがよい場合があります。

例えば、次のようにシステム名、担当者、業務への影響度、緊急度、更新状況を一覧にします。

業務への影響度と緊急度がともに高いものから優先して着手します。現場で個別に作られたExcelマクロなども、重要な業務に組み込まれている場合があるため、一覧から漏らさないようにします。

この段階では詳細な仕様まで調査せず、優先順位を判断するために必要な情報を把握できれば十分です。

 

洗い出しの段階では、システム名・担当者・業務への影響度を一覧にまとめる程度で構いません。

システムの属人化はマニュアルで解消できる？改修が必要なケースとの判断基準

属人化の対策では、どこまで運用で対応し、どこからシステムに手を入れるかの判断が難しいところです。

判断を誤ると、資料整備に時間をかけたにもかかわらず状況が変わらない、という結果になりかねません。

運用の改善で対応しやすいケース

次のような状態であれば、資料の整備とルールづくりで改善が進む可能性があります。

• システムの構造自体は標準的で、市販パッケージや一般的な構成である
• 操作手順が共有されていないことが主な原因になっている
• 設計情報が残っており、内容を確認できる状態にある
• 担当者が在籍しており、ヒアリングできる時間を確保できる

これらに当てはまる場合、問題は情報共有の不足にあると考えられます。

システムに手を入れるより先に、資料と運用ルールを整えることで、費用をかけずに改善できる可能性があります。

特に担当者が在籍している間は、情報を引き出せる貴重な期間といえます。

退職や異動の予定が分かった時点で着手できると、選択肢を残したまま対応を進められます。

システムの改修や再構築を検討したいケース

一方、以下のような状態では、運用の工夫だけでは限界があります。

• 設計情報がまったく残っておらず、処理内容を追跡できない
• 作成者が退職済みで、内容を説明できる人が社内に存在しない
• 個人が作成したツールが複数連結し、全体の流れを把握できない
• 改修のたびに想定外の不具合が発生している
• 使用している技術の保守サポートが終了している

この状態では、資料を作ろうとしても解析作業から始める必要があり、結果的に作り直すのと同程度の工数がかかる場合があります。

属人化の解消を目的に調査を進めた結果、再構築を選択したほうが総額を抑えられると判明するケースも珍しくありません。

判断のためには、現行システムの調査を先に行い、改修と再構築それぞれの概算を比較することが有効です。

判断に迷ったときの考え方

どちらとも言い切れない場合は、「その業務を今後も継続するかどうか」から考えると整理しやすくなります。

業務自体を続ける前提であれば、システムを整える投資には意味があります。数年先も同じ業務が残るのであれば、放置した分だけ対応コストが積み上がりやすくなります。

一方、業務の見直しや廃止が視野に入っているのであれば、最低限の引き継ぎ資料を残すにとどめる判断もあり得ます。

また、社内だけで結論を出さず、調査の部分だけを外部に任せる進め方もあります。

複数のシステムが同時に属人化している場合は、個別ではなく全体を見渡した整理が必要です。

進め方については、「Excel管理から脱却！業務システム開発の費用・期間・進め方を解説」で解説しています。

まとめ

システムの属人化は、担当者の抱え込みによるものではなく、記録や体制の仕組みが整っていないことから生じるケースが多く見られます。

そのため、引き継ぎ資料の作成を依頼するだけでは、根本的な解消につながりにくい面があります。

まずは人・情報・仕組みの3つの切り口で現状を確認し、業務とシステムの対応関係を可視化したうえで、影響の大きい領域から着手することが現実的な進め方です。

そのうえで、優先度の高い情報から資料を整え、運用ルールをそろえ、担当者以外が触れる状態をつくっていきます。

運用の改善で対応できる範囲と、システム側の見直しが必要な範囲を切り分けることが、無駄な工数を避けるうえで重要になります。

設計情報が残っていない、作成者が既に退職している、といった状態であれば、調査を行ったうえで改修や再構築を検討する段階に入っていると考えられます。

属人化は、担当者が在籍している間のほうが対処しやすいテーマです。退職や異動が決まってから動き出すと選択肢が限られるため、早めに現状を確認しておくことをおすすめします。

属人化したシステムの見直しなら株式会社アレグビット

属人化したシステムの見直しは、資料の整備だけで解決する場合もあれば、システムの改修や再構築が必要になる場合もあり、判断には現行システムの調査が欠かせません。

特に「作成者が退職して中身が分からない」「他社が開発したシステムで手を入れられない」といったご相談は多く寄せられます。

株式会社アレグビットでは、既存システムの調査から改善のご提案まで、無料でご相談いただけます。

• 他社が開発したシステムの調査・改善・機能追加も対応可能です
• 個人が作成したExcelマクロやツールの置き換えからでも承ります
• 改修と再構築のどちらが適しているかのご相談のみでも大歓迎です

現状の資料が揃っていない状態でも問題ありません。どこから手をつけるべきか整理するところからお手伝いできますので、まずはお気軽にご相談ください。

詳しくは株式会社アレグビットのサイトをご覧ください。