ひとり情シスが全社員のアカウント・端末を1人で把握する台帳の作り方

社員数が10人台の頃は、「誰がどのパソコンを使っていて、どのアカウントを持っているか」は担当者の頭の中に入っていました。しかし30人を超えたあたりから、この記憶依存は静かに破綻し始めます。100人に近づく頃には、「あの人、退職したはずだけどアカウントどうなってたっけ」と台帳を見返しても答えが出てこない、という状態に陥っている会社は珍しくありません。

このガイドは、専任のIT資産管理担当がいない30〜100人規模の会社で、兼任のひとり情シスが1人で作り、1人で回し続けられる資産台帳の作り方を扱います。一般的なIT資産管理の教科書は、専任チームや資産管理ツールの導入を前提にしていることが多く、兼任担当者の実情に合わないことがあります。ここでは「ツールを買う前に、まずExcelやスプレッドシートで何を管理すればこの規模を乗り切れるか」に絞って解説します。

台帳という言葉を聞くと、多くの担当者は「大がかりな棚卸しプロジェクト」を想像してしまいます。しかし、30〜100人規模のひとり情シスにそのような大規模プロジェクトを進める時間的余裕はありません。このガイドで提示するのは、最小限の労力で最大限の実用性を確保する「継続できる台帳」の設計です。

なぜ30〜100人規模で台帳が崩壊しやすいのか

台帳が崩壊する典型的なパターンは3つあります。

• 入退社・異動の頻度が記憶の限界を超える: 10人規模なら年に数件だった入退社が、30〜100人規模では月に複数件発生することも珍しくなくなります
• 部署をまたぐ端末の異動が記録されない: 退職者のPCを別の新入社員が使い回す、といった「モノの移動」が口頭やチャットのやり取りだけで完結し、記録に残らない
• 管理者が一人しかいないため、記録する余裕がない日が続くと更新が止まる: 兼任担当者は本業が忙しい週に台帳更新を後回しにしがちで、一度止まると「今の状態と台帳がずれている」不信感から更新自体が形骸化する

これらは根性論では解決しません。台帳の設計自体を、更新が止まっても最低限の実態と乖離しにくい構造にすることが必要です。

台帳が崩壊した状態を放置すると、どのような実害が出るのかも具体的に確認しておきましょう。台帳が実態と乖離していると、退職者のアカウントが削除されずに残る、必要な人に必要な権限が付与されていない、端末の所在が分からず紛失に気づくのが遅れる、といった問題が連鎖的に発生します。これらは30-100人規模の会社が最初に整備すべきセキュリティ対策の順番で扱っている優先順位の対策すべての土台であり、台帳が崩れていると、その上に積み上げるどの対策も実効性を失います。

台帳に持たせるべき3つの軸

台帳は「社員」「端末」「アカウント」の3つを軸に設計します。これらを1枚のシートに詰め込むと、入退社のたびに行の追加・削除が発生して壊れやすくなるため、最低限3つのシート（またはテーブル）に分けることを推奨します。

社員台帳と端末台帳、アカウント台帳をIDで紐づけておくことで、「この人が辞めたら、どの端末とどのアカウントに影響が出るか」を一目で追跡できるようになります。これができていないと、退職者アカウントの削除漏れを防ぐチェックリストで示されている削除フローそのものが、そもそも「何を削除すべきか分からない」状態で機能しません。

3シート構成の利点は、それぞれのシートの更新頻度が異なることにも対応できる点です。社員台帳は入退社・異動のたびに更新が必要ですが、端末台帳は購入・廃棄・貸与変更のタイミングでのみ更新すればよく、アカウント台帳は新規発行・権限変更・退職時の削除で更新します。1枚のシートにまとめてしまうと、これらの異なる更新タイミングが混在し、どこを最新化すればよいか分かりにくくなります。

「棚卸し」ではなく「発生時更新」を基本にする

30〜100人規模のひとり情シスが台帳を維持できなくなる最大の原因は、「年1回まとめて棚卸しする」運用を前提にしてしまうことです。この規模になると、半年も経てば実態と台帳の乖離が大きくなりすぎて、棚卸し自体が数日仕事になり、結局後回しにされます。

代わりに推奨するのは、入社・退職・異動・機器の貸与や返却が発生した「その日」に台帳を更新する運用です。年1回の棚卸しは、この発生時更新の漏れをチェックする補助的な位置づけに格下げします。

• 入社時: 社員台帳に行を追加し、貸与端末とアカウントを同時に記録する
• 退職・異動決定時: 台帳上に「退職予定日」を先に入力しておき、発行済みアカウント一覧を事前に洗い出す
• 機器の貸し出し・返却: 台帳の使用者欄をその場で書き換える。口頭やチャットだけで済ませない

このルールを機能させる鍵は、入退社のプロセスに台帳更新を組み込むことです。人事や経営層が入退社を決定した時点で、情シス担当者に通知が届く仕組みがなければ、発生時更新は結局漏れます。中途入社が増える段階でのアカウント発行フローの整備は中途入社が増える段階でのアカウント発行・権限付与フローの整備で詳しく扱っているので、台帳更新のタイミングをそこで扱う入社フローと連動させてください。

発生時更新を定着させるコツは、台帳更新を「別のタスク」として扱わないことです。入社対応のチェックリストの最後の項目に「台帳への記録」を組み込む、退職者の最終出社日の対応手順に「アカウント台帳の削除予定欄への記入」を含める、といった形で、既存の業務フローの中に台帳更新のステップを埋め込んでしまうと、忘れにくくなります。

権限は「誰が持っているか」より「誰が承認したか」を残す

台帳整備でありがちな失敗は、アカウントの存在だけを記録し、なぜその権限を持っているかを記録しないことです。30〜100人規模になると、部署間の異動や兼務が増え、「なぜこの人が経理システムの編集権限を持っているのか、もう誰も分からない」状態が生まれやすくなります。

アカウント台帳には、権限レベルの列に加えて「承認者」「付与理由」の列を最低限持たせてください。これにより、半年後・1年後に見返したときに、権限の棚卸しが「記憶に頼らず判断できる」状態を維持できます。

具体的には、アカウント台帳の列構成を次のように拡張すると実用的です。

この中でも「最終利用確認日」は見落とされやすい項目ですが、実は重要です。付与された権限が実際に使われているかどうかを定期的に確認することで、「発行したまま誰も使っていない休眠アカウント」を発見できます。休眠アカウントは、本人が気づかないうちに不正利用されるリスクがあり、可視化されていないと発見自体が困難になります。

台帳をどこに置くか: ツール導入は必須ではない

30〜100人規模であれば、専用のIT資産管理ツールを導入せずとも、クラウドの表計算ソフト（共有スプレッドシート）で十分運用できます。ツール導入を急ぐより、まず上記の3シート構成と発生時更新の運用が定着するかを確認してから、必要性を判断してください。IT資産管理の始め方の全体像は中小企業のIT資産管理の始め方にまとめてあるので、台帳の粒度に迷ったときはあわせて参照してください。

一方で、100人に近づき、かつ入退社の頻度がさらに増えていく見通しがあるなら、スプレッドシートの限界（同時編集の競合、検索性の低さ、権限管理自体の脆弱さ）が顕在化してくる時期でもあります。その場合の判断基準は以下の通りです。

• 月あたりの入退社・異動件数が2桁に達している
• 台帳の参照者が情シス担当者以外にも複数人いる
• アカウント数が数百を超え、Excel関数での突合が現実的でなくなっている

これらに複数当てはまる場合は、専用ツールの検討時期です。ただし30〜100人規模の多くの会社では、まだこの段階に至っていません。

スプレッドシートで台帳を運用する際の実務上の工夫

スプレッドシートで台帳を運用する場合、いくつかの工夫を加えることで、1人での運用がぐっと楽になります。

• プルダウンリストで入力の揺れを防ぐ: 部署名や権限レベルを自由入力にすると、「営業部」「営業」「Sales」のように表記が揺れ、後から集計・検索する際に支障が出ます。あらかじめ選択肢を固定したプルダウンにしておくと、この揺れを防げます
• 条件付き書式で異常を可視化する: 退職予定日が過ぎているのにアカウントが削除済みになっていない行を自動的に色付けするなど、条件付き書式を使うことで、目視での見落としを減らせます
• 更新履歴を残す設定を有効にする: クラウド型のスプレッドシートには変更履歴を自動保存する機能があります。「いつ誰がどこを更新したか」を追跡できる状態にしておくと、後から不整合が見つかった際の原因調査がしやすくなります
• 編集権限を必要最小限に絞る: 台帳自体も機密性の高い情報です。編集権限を持つ人を情シス担当者と、必要であれば経営層に限定し、閲覧のみの権限で共有する範囲を分けてください

よくある失敗パターンとその回避策

台帳整備を始めた担当者が陥りやすい失敗パターンをいくつか紹介します。

失敗パターン1: 最初から完璧な粒度を目指してしまう

台帳の設計段階で、あらゆる項目を網羅しようとすると、シートの作成自体に何週間もかかってしまい、結局着手が遅れます。まずは社員ID・氏名・所属・貸与端末・主要アカウントという最小限の項目でシートを作り、運用しながら必要な項目を追加していく方が現実的です。

失敗パターン2: 過去の情報まで遡って完璧に埋めようとする

新しく台帳を作る際、「これまでの入退社履歴もすべて遡って記録すべきか」と悩む担当者がいますが、これは優先度が低い作業です。まずは「現在有効なアカウント・端末・社員」の現状把握を優先し、過去の履歴の整備は余裕があるときに後回しにして構いません。

失敗パターン3: 台帳の存在を自分だけが知っている状態にする

ひとり情シスが台帳を作っても、その存在や場所を経営層や後任候補に共有していないと、担当者が急な休暇や退職をした際に台帳自体が引き継がれず、また一から作り直すことになります。台帳の保存場所と更新ルールは、少なくとも経営層の誰か1人には共有しておいてください。この点は、ひとり情シスが安心して休むために作っておく仕組みで扱われている不在時の備えとも共通する考え方です。

台帳と他の管理業務との連携

台帳は単独で存在するものではなく、他の情シス業務と連携させることで真価を発揮します。

セキュリティ対策との連携: 30-100人規模の会社が最初に整備すべきセキュリティ対策の順番で扱っているMFA全社適用や退職者アカウント削除は、台帳がなければ「誰に何を適用すべきか」が分からず実行できません。台帳整備とセキュリティ対策は、どちらか一方を先に完璧にしてから次に進むのではなく、並行して進めることを想定してください。台帳の骨格ができた時点で、分かっている範囲からセキュリティ対策にも着手し、台帳が充実するにつれて対策の網羅性も高まっていく、という relationship で捉えるのが現実的です。

予算計画との連携: 端末台帳にEOL（サポート終了）予定時期を記録しておくと、数年先のリプレース予算をあらかじめ見積もることができます。台帳が整っていない状態では、「気づいたら壊れたので急遽購入」という後手の対応になりがちですが、台帳から先読みできれば、年次の予算計画に組み込むことができます。

入社・退職フローとの連携: 前述の通り、台帳更新は入社・退職のフローに組み込むことで初めて継続的に機能します。中途入社が増える段階でのアカウント発行・権限付与フローの整備で扱っているオンボーディングフローの最後のステップに、必ず台帳更新を含めてください。

台帳整備がもたらす副次的なメリット

台帳整備の目的はセキュリティリスクの低減や業務効率化ですが、実際に運用を続けていくと、想定していなかった副次的なメリットも見えてきます。

• ライセンス費用の無駄が見える化される: アカウント台帳を眺めていると、「もう使われていないのに契約が継続しているSaaSライセンス」が見つかることがあります。台帳が整っていなければ気づけなかったコストの無駄です
• 業務プロセスの属人化に気づくきっかけになる: 特定の社員だけが特殊な権限を持っている状態が見つかった場合、それは業務そのものが属人化しているサインかもしれません。台帳整備をきっかけに、業務プロセスの見直しにつながることもあります
• 新入社員へのオンボーディングがスムーズになる: 標準的な権限セットが台帳に整理されていると、新しく入社する社員に何を渡すべきかが明確になり、準備の抜け漏れが減ります

これらの副次的なメリットは、台帳整備を始めた当初は意識していなくても、運用を続けるうちに自然と実感できるようになります。地味な作業を続けるモチベーションとして、こうした副次的な成果にも目を向けてみてください。

台帳整備を始めるタイミングに「遅すぎる」はない

すでに30〜100人規模になっていて、これまで台帳らしい台帳を作ってこなかった会社の担当者は、「今さら始めても手遅れではないか」と感じるかもしれません。しかし、台帳整備に「遅すぎる」タイミングはありません。今日から始めれば、今日以降に発生する入退社や機器の異動は正しく記録され、実態との乖離はそこで止まります。

過去の情報をすべて遡って完璧に埋める必要はないことは前述の通りです。まずは「現在」のスナップショットを正確に作ることに集中し、そこから発生時更新を積み重ねていけば、数ヶ月後には十分に実用的な台帳へと育っていきます。

台帳更新を後回しにしても崩れない優先順位

本業が忙しく台帳更新が滞りそうな週があっても構いません。その場合は、社員台帳とアカウント台帳のうち、退職者・異動者に関する更新だけは最優先で死守してください。端末の細かい貸与記録は数週間遅れても実害は限定的ですが、退職者のアカウントが台帳上に残ったままだと、削除漏れに直結するリスクの方が重大です。

優先順位をつけるとすれば、次のような順序になります。

1. 退職者・異動者のアカウント状態の反映（最優先）
2. 新規入社者のアカウント・端末の記録
3. 権限変更の記録
4. 端末の細かい貸与・返却状況の更新
5. 過去情報の整備・粒度の見直し（時間に余裕があるときのみ）

端末台帳で見落とされがちな「私物端末の業務利用」

端末台帳を作る際、会社が貸与した端末だけを対象にしがちですが、30〜100人規模の会社では、私物のスマートフォンで業務メールを確認している社員が一定数存在するケースが少なくありません。いわゆるBYOD（Bring Your Own Device）の実態です。

私物端末を台帳の管理対象に含めるかどうかは会社の方針次第ですが、少なくとも「どの私物端末が業務データにアクセスしているか」だけは把握しておくべきです。これを放置すると、退職時に業務データへのアクセス権限を私物端末から削除し忘れる、というリスクにつながります。端末台帳に「所有区分（会社貸与／私物）」の列を追加し、私物端末であっても業務アクセスがある場合は台帳に記録する運用を検討してください。

台帳整備を「本業の合間」で進めるための時間配分

兼任担当者にとって最大の壁は、台帳整備にまとまった時間を確保できないことです。しかし台帳整備は、まとまった時間がなくても少しずつ進められる性質の作業でもあります。次のような時間配分の考え方を参考にしてください。

• 初期構築（シートの骨格作り）: まとまった時間が必要な唯一の工程です。半日〜1日程度、集中して取り組む時間を確保してください。この工程だけは分割すると設計がぶれやすくなります
• 既存データの流し込み: 人事情報システムや会計システムに社員一覧がすでにある場合は、そこからのエクスポート・取り込みで多くの部分を自動化できます。ゼロから手入力する前に、既存のデータソースを確認してください
• 日々の発生時更新: 1件あたり数分で終わる作業です。入退社や機器貸与のたびにその都度行えば、まとまった時間を確保する必要はありません
• 定期チェック（月1回程度）: 台帳と実態がずれていないかを確認する時間です。30分程度、カレンダーに固定で予定を入れておくと習慣化しやすくなります

このように工程を分解すると、「台帳整備」という一つの大きなタスクではなく、「初期構築の半日」「日々数分の更新」「月1回30分のチェック」という、兼任者でも現実的に確保できる時間配分に落とし込めます。

台帳を使った定期棚卸しの実施方法

発生時更新を基本にしていても、月1回程度の軽い定期チェックに加えて、半年〜1年に一度は少し踏み込んだ棚卸しを行うことをおすすめします。定期棚卸しでは、次のような確認を行います。

• アカウント台帳の「最終利用確認日」が古いままの行を洗い出す: 半年以上利用が確認されていない権限は、実際に必要か本人・上長に確認します
• 端末台帳のEOL予定時期が近づいている端末を一覧化する: リプレース予算の計画に活用します
• 社員台帳と実際の在籍者名簿を突合する: 人事側の情報と台帳の情報がずれていないかを確認します

この定期棚卸しは、発生時更新では拾いきれない「気づかないうちに生じたずれ」を修正するための保険のような位置づけです。年1回のイベントとして負荷の高い作業にするのではなく、半年ごとに軽く確認する頻度に分散させることで、1回あたりの作業量を抑えられます。

経営層への台帳の見せ方: 数字で説明する

台帳を整備したこと自体は、経営層にとって直接的な成果として伝わりにくい場合があります。台帳整備の価値を経営層に理解してもらうには、台帳から得られる数字を使って説明するのが効果的です。

• 「現在、社員数〇〇人に対してアカウント数は〇〇件です。退職者に紐づいたまま残っているアカウントが〇件見つかり、削除しました」
• 「端末のうち〇台がサポート期限（EOL）を迎えており、リプレース計画が必要です」
• 「特定のシステムへの管理者権限を持つ人数が想定より多いことが分かりました。棚卸しを行い、〇人まで絞り込みました」

台帳整備そのものは地味な作業ですが、そこから見えてくる数字は経営層にとって意思決定の材料になります。台帳を「情シス担当者だけが見るバックヤードの資料」にとどめず、定期的に要点を経営層へ報告する習慣をつけることで、台帳整備の価値そのものへの理解も深まります。

報告のタイミングとしては、定期棚卸しを行ったタイミングに合わせるのが自然です。半年に一度、数値をまとめて経営層に共有する場を設けておけば、台帳整備の労力が「見える成果」として認識され、今後の予算確保や体制強化の議論にもつながりやすくなります。

まとめ: 1人で回せる粒度に絞り込む

30〜100人規模の台帳整備で目指すべきは、網羅性の高い高機能な資産管理システムではなく、ひとりの兼任担当者が本業と両立しながら更新し続けられる粒度です。社員・端末・アカウントの3軸をIDで紐づけ、年1回の棚卸しではなく発生時更新を基本にする。この2点さえ守れば、100人規模までは十分に台帳を機能させ続けられます。

台帳は一度作って終わりではなく、会社の成長とともに育てていくものです。最初は最小限の項目から始め、運用しながら必要な項目を足していく。そして、自分がいなくなっても他の誰かが状況を理解できるよう、台帳の存在自体を組織の資産として共有しておく。この姿勢を持ち続けることが、30〜100人規模を乗り越えて、その先の体制に引き継いでいくための土台になります。

社員数が100人を超え、情シスの専任化やチーム化が進む段階になれば、台帳もより高機能なツールへ移行する選択肢が現実的になってきます。しかしそれは、このガイドで示した基本の3軸（社員・端末・アカウント）と発生時更新の考え方があってこそ成立する次のステップです。まずは1人で回せる粒度の台帳を今日から始め、会社の成長とともに育てていってください。専任化のタイミングで役割の範囲をどう経営層と合意すべきかは、情シス専任1人目が就任したときに経営層と決めておくべき役割の範囲で扱っています。

台帳は地味で目立たない仕事です。しかしこの地味な土台があるかないかで、セキュリティ対策の実効性も、入退社対応の速さも、ヘルプデスク対応の的確さも大きく変わってきます。30〜100人規模を乗り越えようとしているひとり情シスにとって、台帳整備は最も優先度の高い「見えない投資」であることを忘れないでください。今日、まだ台帳がないなら、社員台帳の1行目を作るところから始めてみてください。

3シート、3つの軸、それだけで十分です。完璧を目指さず、まず動かし始めることが何よりも大切です。

一次情報

• IPA「中小企業の情報セキュリティ対策ガイドライン」: https://www.ipa.go.jp/security/guide/sme/about.html
• 警察庁・総務省・経済産業省「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況」: https://www.npsc.go.jp/policy/list/260313.pdf