属人化を防ぐ社内システム管理台帳の作り方

「もし自分が今日、急に会社に来られなくなったら、経理の入金確認は誰にもできない」。そんな不安を、口には出さないまま抱えている担当者は少なくありません。幸いにも、まだ何も事故は起きていない。前任者が突然辞めたわけでもなければ、システムが止まって取引先に迷惑をかけたわけでもない。むしろ日々の業務は問題なく回っている。だからこそ、この不安はいつまでも「そのうち整理しよう」の棚に置かれたままになりがちです。

しかし、その「そのうち」は、たいてい自分の都合では選べないタイミングでやってきます。体調を崩して長期入院することになった、家族の介護で急に休みが必要になった、あるいは単純に、より良い条件のオファーが来て転職を決めた。理由が何であれ、属人化した状態のまま担当者が抜けると、その瞬間から会社は「誰も動かし方を知らないシステム」を抱えることになります。

この記事は、まだ危機が起きていない今のうちに、それを防ぐための最も基本的な仕組みである「システム管理台帳」の作り方を解説するものです。すでに引き継ぎの危機に直面している方は、応急対応を扱った別記事『前任者が突然辞めた。社内システムを引き継ぐ最初の1週間でやること』を先に読んでください。この記事が想定するのは、平時のうちに手を打ちたいと考えている方です。

この記事で分かること

システム管理台帳とは何か、なぜ属人化対策として最も効果的なのか、そして実際にどう作り始めればよいかを、具体的な項目例とともに解説します。台帳という言葉から「大変な作業」を想像するかもしれませんが、結論を先に言うと、最初の一歩はExcelシート1枚で構いません。

この記事で扱う内容は次の3つです。

• なぜ属人化が起きるのか: 個人の怠慢ではなく、構造的に起きやすい理由を理解する
• 管理台帳に何を書くか: 最低限埋めるべき項目と、後回しにしてよい項目の線引き
• どう運用を続けるか: 作って満足で終わらせないための更新の仕組み

台帳を完璧に作り込むことが目的ではありません。「自分が今日いなくなっても、誰かが最低限の対応をできる状態」を作ることがゴールです。

属人化はなぜ「悪意なく」起きるのか

まず前提として押さえておきたいのは、属人化は多くの場合、誰かが意図的に情報を隠しているから起きるのではない、という点です。

中小企業でシステム管理を任される人の多くは、専任の情シスとしてではなく、総務・経理・営業事務などの本来業務を持ちながら、片手間で「詳しそうだから」という理由でシステム関連を引き受けています。日々の業務に追われる中で、パスワードは手元のメモに書き、契約書はキャビネットの奥にしまい、「このシステムはこう動く」という理解は自分の頭の中だけに蓄積されていきます。

これは怠慢ではなく、むしろ自然な結果です。ドキュメントを整備する時間的余裕がない状態で、目の前の業務を回すことを優先すれば、当然そうなります。問題は、この状態が何年も積み重なったところに、担当者の異動や退職という「引き金」が引かれることです。

属人化とは、業務のやり方やシステムの仕組みが、特定の担当者の頭の中にしかなく、マニュアルや引き継ぎ資料として残っていない状態を指します。担当者の退職・異動をきっかけに、業務が回らなくなる原因になります。

この定義で重要なのは「担当者の退職・異動をきっかけに」という部分です。属人化そのものは、担当者が在籍している間は表面化しません。業務は普通に回りますし、むしろ「あの人に聞けば何でも分かる」という状態は、短期的には効率的にすら見えます。危険が顕在化するのは、その人がいなくなった瞬間だけです。だからこそ、危機が起きていない平時にこそ対策を打つ価値があります。火事が起きてから消火器を探すのではなく、火事が起きていないうちに設置しておく、というのがこの記事の立場です。

システム管理台帳とは何か

結論から言うと、システム管理台帳とは「社内で動いているシステムに関する情報を、担当者の頭の中ではなく、誰でも参照できる一覧に書き出したもの」です。特別なソフトウェアは必要なく、Excelやスプレッドシート、あるいは社内で使っているクラウドツールの表機能でも十分に機能します。

台帳という言葉が持つ「重厚で完璧な文書」というイメージは、いったん脇に置いてください。最初の一歩として必要なのは、次の3種類の情報を1つの場所にまとめることです。

• 何が動いているか: 社内で使っているシステム・ソフトウェア・クラウドサービスの一覧
• 誰が管理しているか: 開発・保守を担う会社（または部署）の連絡先、契約内容
• どう入れるか: 管理者アカウントの保管場所、ログインの手順

この3種類さえ書き出されていれば、担当者が突然いなくなっても、後任者は「何が動いているか分からない」という最悪の事態を避けられます。逆に言えば、この3種類が頭の中にしかない状態こそが、属人化の実体です。

なお、社内のIT資産（パソコン・ライセンス等）を管理する取り組みはIT資産管理と呼ばれ、システム管理台帳と重なる部分もありますが、対象範囲が少し異なります。IT資産管理は主に「モノとライセンス」を対象にするのに対し、システム管理台帳は「システムという仕組み全体」（契約・アカウント・依存関係を含む）を対象にする、という違いを押さえておくと混同しにくくなります。

何を最初に書けばよいか。優先順位のつけ方

台帳作りでつまずきやすいのは、「完璧な一覧を作ろう」として最初の一歩が重くなってしまうことです。実務的には、次の優先順位で埋めていくのが現実的です。

優先度1: お金が動いているシステムから書き出す

最初に手をつけるべきは、毎月または毎年、費用が発生しているシステムです。理由は単純で、費用が発生しているものは経理の支払い明細やクレジットカードの明細から機械的に洗い出せるため、記憶に頼らず作業できるからです。

会計システム、給与計算システム、勤怠管理、顧客管理（CRM）、グループウェアなど、契約書や請求書が残っているものから順に一覧化していきます。この段階では、細かい仕様や操作方法までは書きません。「このシステムに毎月いくら払っていて、どこの会社と契約しているか」が分かれば十分です。

優先度2: 止まると業務が止まるシステムを特定する

次に、費用の有無にかかわらず、そのシステムが止まると業務全体が止まってしまうものを洗い出します。こうした箇所は単一障害点（SPOF）と呼ばれ、古い社内サーバー1台に複数の業務が同居しているケースなどが典型例です。

止まると困るシステムほど、実は台帳への記載が後回しにされがちです。「動いているから大丈夫」という安心感が、記録を残す動機を弱めてしまうためです。しかし、こうしたシステムこそ、いざ止まったときの被害が最も大きくなります。優先度1で洗い出したリストを見ながら、「これが止まったら、明日の業務にどれくらい影響するか」を自問し、影響が大きいものから順に詳細を埋めていきます。

優先度3: 個人のPCやアカウントに紐づいた仕組みを洗い出す

最後に、特定の担当者個人のパソコンやアカウントに依存している仕組みを確認します。VBAマクロで自動化された定型作業、個人のGoogleドライブやOneDriveに保存された共有ファイル、退職者が作った未整理のフォルダなどが該当します。

これらは金額としては小さいことが多いですが、担当者の異動・退職と同時に「誰にも分からないブラックボックス」に変わりやすい部分です。優先度1・2に比べると発見しづらいため、後回しにしてよい項目ですが、台帳作りが軌道に乗ってきたら必ず対応してください。

台帳に書くべき項目の具体例

ここまでの優先順位を踏まえて、実際に台帳のシートに列として並べる項目を整理します。以下は、システムの管理台帳として実務上よく使われている項目の例であり、すべてを一度に埋める必要はありません。自社の状況に合わせて取捨選択してください。

特にアカウント情報の扱いには注意が必要です。パスワードそのものをExcelファイルに平文で書き込むのはセキュリティ上望ましくありません。台帳には「どのパスワード管理ツールの、どのフォルダに保管されているか」という保管場所の情報を書き、実際の認証情報は専用のツールで管理する、という二段構えにするのが実務的な落としどころです。

なお、独立行政法人情報処理推進機構（IPA）が公開している「中小企業の情報セキュリティ対策ガイドライン」（2026年3月発行の第4.0版）には、付録として資産管理台帳のサンプル（Excel形式、複数シート構成）が用意されています。ゼロから項目を考えるのが難しい場合は、こうした公的機関が公開しているひな形を出発点にし、自社の実態に合わせて列を増減させる進め方も現実的です。

中小企業の情報セキュリティ対策ガイドライン第4.0版（2026年3月27日発行、IPA）には、付録6として資産管理台帳のサンプルが用意されている。

——IPA「中小企業の情報セキュリティ対策ガイドライン」掲載情報より

システム管理台帳と「引き継ぎ資料」はどう違うのか

ここまで読んで、「それは引き継ぎ資料と同じものではないか」と感じた方もいるかもしれません。両者は重なる部分が多いものの、目的が少し異なります。

引き継ぎ資料は、特定の後任者に向けて「その人が明日から業務を回せるようにするための説明書」です。操作手順や業務フローなど、手続き的な情報が中心になります。一方でシステム管理台帳は、特定の誰かに向けたものではなく、「その時点で会社が使っているシステムの実態を映した台帳」であり、後任者が決まっているかどうかに関わらず、常に最新の状態を保つことを目指します。

言い換えれば、引き継ぎ資料は担当者交代の「そのとき」に作る一度きりの文書であるのに対し、システム管理台帳は担当者が誰であっても常に存在し続ける「土台」です。台帳が日頃から整備されていれば、いざ担当者交代が発生したときの引き継ぎ資料作成は、台帳の内容を整理し直すだけで大部分が完成します。逆に台帳がなければ、引き継ぎ資料はゼロから記憶を掘り起こして作ることになり、時間的な余裕がない交代のタイミングほど、内容が薄くなりがちです。

つまりシステム管理台帳は、将来発生するかもしれない引き継ぎのための「事前投資」でもあります。平時にコツコツ更新しておくことが、有事の引き継ぎ資料作成の負担を大きく減らすことにつながります。

依存関係を見える化する簡易的な方法

台帳の項目の中でも、特に後回しにされやすいのが「依存関係」の欄です。あるシステムが別のどのシステムとデータをやり取りしているかは、日々の運用の中では意識しにくく、記録に残りにくい情報のひとつです。

しかし、この依存関係こそが、担当者交代後のトラブルで最も時間を食う原因になりがちです。「勤怠システムのデータが給与計算システムに自動連携されている」ことを知らないまま、片方だけを解約・変更してしまい、連携が止まってから初めて気づく、というのは典型的な失敗例です。

依存関係を厳密な構成図として描く必要はありません。最初は次のような簡易的な一覧で十分機能します。

• システムAの名前とシステムBの名前を1行に並べる
• どちらからどちらへ、どんな情報が渡っているか（例: 勤怠→給与、勤務時間データ）を一言で書く
• 連携の方法（自動連携か、手動でCSVを移すだけか）を書き添える

CSVで手動連携しているだけの箇所は見落とされやすいので、特に注意して洗い出してください。自動連携されているシステムに比べ、手動連携は「なぜか毎月あの人がやっている謎の作業」として属人化しやすい典型パターンです。

よくある失敗パターンとその避け方

台帳作りに着手した担当者が陥りやすい失敗には、いくつかの共通パターンがあります。ここで先に知っておくことで、同じ轍を踏まずに済みます。

• 完璧主義で止まる: 最初から全項目を埋めようとして、着手する前に力尽きてしまうパターン。優先度1の項目だけをまず1週間で埋め切る、というように範囲を区切るほうが継続しやすくなります
• 属人化した1人が1人で作る: 台帳作成自体を、また特定の1人だけで抱え込んでしまうパターン。台帳の存在と保管場所を、最低でも上長ともう1人には共有しておくことが重要です
• 作って終わりにする: 台帳を一度作った満足感で更新が止まり、半年後には実態と乖離した「使えない台帳」になるパターン。次のセクションで扱う運用の仕組みが対策になります
• 細かすぎる項目設計で挫折する: 大企業向けのIT資産管理の教科書をそのまま真似て、使わない項目まで用意してしまい、埋めるのが苦痛になるパターン。中小企業の実態に合わせて、必要な列だけに絞り込む判断が必要です

いずれの失敗も、「最初から完成形を目指す」ことが根本原因になっています。台帳は一度作って終わりのものではなく、育てていくものだと捉え直すことが、継続のコツです。

台帳を「作って終わり」にしないための運用ルール

台帳作りで最も難しいのは、実は「作ること」ではなく「更新し続けること」です。多くの会社で、最初は意気込んで作った台帳が、数ヶ月後には実態と食い違った古い情報のまま放置されています。これを防ぐには、更新のきっかけをルール化しておくことが有効です。

更新のタイミングをイベントに紐づける

「毎月更新する」という時間ベースのルールは、忙しさに流されて形骸化しやすい傾向があります。代わりに、次のようなイベントが発生した際に必ず台帳を更新する、というルールにするほうが実務的に続けやすくなります。

• 新しいシステム・クラウドサービスを契約したとき
• 既存のシステムを解約・乗り換えしたとき
• 管理者アカウントのパスワードを変更したとき
• 保守を担当する開発会社が変わったとき
• 担当者自身が異動・退職の内示を受けたとき

特に最後の「担当者自身の異動・退職の内示を受けたとき」は見落とされがちですが、この記事のテーマである属人化対策という観点では最も重要なタイミングです。内示を受けてから慌てて整理するのではなく、「内示を受けたら即座に台帳の総点検をする」というルールを、あらかじめ社内の慣行として定めておくことをおすすめします。

台帳の保管場所を「1人しか開けない場所」にしない

台帳をせっかく作っても、その保管場所が担当者個人のパソコンのローカルフォルダや、個人アカウントのクラウドストレージだけになっていては意味がありません。台帳自体が属人化していては本末転倒です。

会社として契約している共有ドライブやグループウェア上に置き、少なくとも上長を含む複数人がアクセスできる状態にしておく必要があります。アクセス権限を必要以上に広げる必要はありませんが、「担当者が1人しかアクセスできない場所」だけには絶対に置かないことが鉄則です。

定期的な棚卸しの頻度

日々の更新ルールに加えて、年に1〜2回程度、台帳全体を見直す棚卸しの機会を設けることも有効です。棚卸しの際には、次のような観点でチェックします。

1. 記載されているシステムが、実際にまだ使われているか（使われなくなったシステムが残っていないか）
2. 記載漏れの新しいシステム・サービスがないか（シャドーITとして現場が独自導入したものを含む）
3. 契約先・連絡先の情報が古くなっていないか
4. 担当者の異動・退職があった場合、アカウントの引き継ぎが正しく反映されているか

棚卸しは一人で完結させず、可能であれば上長や他部署の担当者にも一部を確認してもらうと、抜け漏れに気づきやすくなります。

台帳があるだけで防げる典型的なトラブル

「台帳を作ることに、実際どれだけの効果があるのか」と疑問に思う方もいるかもしれません。ここでは、台帳が整備されていれば防げた、あるいは被害を小さくできたはずの典型的なトラブルパターンを紹介します。

取引先からの問い合わせに答えられないケース。担当者が変わった直後、取引先から「いつものシステム連携の件で」と問い合わせが来ても、何のシステムを指しているのか分からず、確認に何日もかかってしまう。台帳に依存関係（どのシステムとどのシステムが連携しているか）が記載されていれば、この確認は数分で終わります。

保守契約の存在に気づかず二重に費用を払うケース。過去に契約した保守契約の存在を忘れたまま、別の会社に同じ内容の作業を依頼してしまう。契約情報が一覧化されていれば、こうした無駄な出費は防げます。

退職者のアカウントが放置され続けるケース。台帳がなければ、「そのシステムに退職者のアカウントが存在すること自体」に誰も気づかないまま、何年も放置される可能性があります。これはセキュリティ上のリスクにも直結します。台帳に管理者アカウント一覧があれば、退職・異動のたびにそのリストと突き合わせて、削除・無効化すべきアカウントを機械的にチェックできます。

いずれのケースにも共通するのは、「情報が個人の記憶にしかなかったために、確認に時間がかかった、あるいは確認自体ができなかった」という構図です。台帳は、この構図を「一覧を見れば分かる」という状態に変える、最もシンプルで効果の高い対策です。

経営層・上長を巻き込む伝え方

台帳作りは担当者一人の努力だけでは長続きしません。特に「なぜ今、時間を使って台帳を作る必要があるのか」を経営層や上長に理解してもらえないと、日々の業務に追われる中でいつの間にか優先順位が下がってしまいます。

経営層に説明する際は、「属人化」という言葉そのものよりも、具体的なリスクとして伝えるほうが伝わりやすくなります。次のような伝え方が実務的です。

• 抽象論ではなく具体的な問いを投げる: 「もし私が来月から1ヶ月入院したら、経理の支払い処理は誰ができますか」というように、身近な担当者の名前を挙げて具体的に問いかける
• 金額ではなく時間で語る: システム管理台帳の整備自体に大きな費用はかからないため、「予算がいくら必要か」ではなく「週に何時間、いつまでに整備するか」という時間軸で合意を取る
• 最初から全社的な取り組みにしない: いきなり大きなプロジェクトとして提案すると腰が引かれやすいため、「まずは自分の管轄する範囲だけ、1ヶ月で一次版を作る」という小さな範囲から始める許可を取る

台帳作成を稟議のような正式な手続きに乗せる必要はありませんが、上長に「今、台帳整備を進めている」ことを一言共有しておくだけでも、業務時間の中でこの作業を進める正当性が生まれます。属人化対策は、担当者個人の頑張りだけに頼らず、会社としての取り組みに位置づけることで初めて持続可能になります。

まず着手する第一歩の提案

ここまで読んで、「重要性は分かったが、何から手をつければいいか」と感じている方に向けて、具体的な最初の一歩を提案します。

1. Excelまたはスプレッドシートを1枚新規作成し、「システム名」「契約先」「月額費用」「担当者連絡先」の4列だけを用意する
2. 直近3ヶ月分の経理の支払い明細、あるいはクレジットカードの明細を見返し、システム・クラウドサービスへの支払いをすべて書き出す
3. 書き出した一覧を、上長に共有ドライブ経由で共有する
4. 余裕があれば、優先度2（止まると業務が止まるシステム）の欄を追加する

このステップ1〜3だけであれば、多くの場合1日以内に終わります。完璧な台帳ではありませんが、「自分がいなくなっても、少なくとも何にいくら払っているかは分かる」という最低限の安全網が、この時点で完成します。台帳は完成させてから使うものではなく、使いながら育てていくものだと捉え、まずはこの小さな一歩から始めてみてください。

まとめ

属人化は、悪意や怠慢からではなく、日々の業務に追われる中で自然に積み重なっていく状態です。だからこそ、危機が実際に起きてから慌てて対処するのではなく、平時のうちに「自分がいなくなっても最低限は回る」状態を作っておくことに価値があります。

システム管理台帳は、その最も基本的で効果の高い手段です。最初から完璧を目指す必要はなく、費用が発生しているシステムの一覧から始め、更新のきっかけをイベントに紐づけ、複数人がアクセスできる場所に置く。この3つを押さえるだけで、多くのトラブルは未然に防げるようになります。

すでに引き継ぎの危機に直面している方は『前任者が突然辞めた。社内システムを引き継ぐ最初の1週間でやること』を、古いサーバーのサポート終了(EOL)対応を控えている方は『Windows Server のサポート終了（EOL）対応の進め方』をあわせて参考にしてください。