「社内ITの整理、何から手を付ければいいか分からない」 ひとり情シス、あるいは総務兼任で情シスを見ることになった方から、最初にいただく質問です。
セキュリティ対策、SaaSの整理、問い合わせ対応、経営からのDX要請。 やることは無限にあるように見えますが、ご支援の経験から言うと、多くのケースで最初に整えるべきは台帳です。 現状が見えていなければ、対策の優先順位を判断する基準そのものがありません。 そして必要な台帳は、突き詰めると3つに絞られます。
なぜ台帳が最優先なのか
台帳は地味な仕事に見えますが、情シス業務のほぼすべての土台になります。
退職者のアカウントが残ったままだった、という話は、セキュリティの文脈のご相談でたびたび耳にします。 台帳がなければ、そもそも「消すべきものの一覧」自体が作れません。 同じ構造の問題は、コストの面にも表れます。 使われていないライセンスや、誰が使っているか分からない端末は、台帳を作る過程でそのまま見つかることが多く、整備にかけた手間はここで回収できるケースが少なくありません。
ISMSやPマーク、取引先のセキュリティチェックシートも、突き詰めれば「台帳がありますか、管理していますか」を確認しています。 そして「あのシステムの契約は前任者しか知らない」という属人化から抜け出す第一歩も、結局は台帳です。
アカウント台帳
退職者のアカウントを消し忘れる会社の多くは、注意が足りないわけではありません。 そもそも「誰が、何を使っているか」を把握している人が、社内のどこにもいないのです。 この空白を埋めるのが、誰が、どのシステムを、どんな権限で使っているかを一覧にしたアカウント台帳です。
台帳に持たせたい列は、氏名、所属、システム名、アカウントID、権限（管理者か一般か）、発行日、削除予定日（退職日）です。 なかでも管理者権限を持つアカウントは、正確に記録する必要があります。 権限が強い分、事故が起きたときの被害も桁違いに大きくなります。 貴社で共有アカウントを使っている場合は、存在自体を台帳に明記したうえで、削減の対象として扱うことをおすすめします。 ゼロから作るのは大変に思えるかもしれませんが、Entra IDやGoogle Workspaceのユーザー一覧をエクスポートすれば、初版は半日ほどで作れますし、最近は生成AIを活用することで以前より作成が楽になりました。
端末台帳
アカウント台帳が人を軸にする台帳なら、端末台帳はモノを軸にする台帳です。 会社の情報に触れる機器が、どこに何台あるかを一覧にします。
台帳に持たせたい列は、機種、シリアル番号、利用者、購入日、OSバージョン、暗号化の有無、MDM（モバイルデバイス管理）の有無です。 特に注意したいのは「誰にも貸与されていない端末」です。 行き先を追えなければ、紛失や持ち出しのリスクがそこに潜みます。 貴社でMDM（IntuneやJamfなど）を導入しているなら、MDM側の登録一覧を正として台帳と突き合わせてください。 私物端末の業務利用（BYOD）を認めている場合は、その端末も台帳の対象に含めます。
SaaS台帳
アカウント台帳が人、端末台帳がモノなら、SaaS台帳が扱うのは契約とお金です。 会社としてどのクラウドサービスを契約し、誰が管理しているかを一覧にします。
台帳に持たせたい列は、サービス名、用途、契約プランと料金、ライセンス数と利用数、管理者、支払い方法、契約更新日です。 「ライセンス数と利用数」の差は、そのまま削減の余地です。 部門が勝手に契約したSaaS（シャドーIT）は、経費精算やカード明細から見つかることが多いですが、無料プランや、経費精算にも上がらない個人カード契約はここには現れません。 カード明細だけで洗い出しが完了したと考えないでください。 契約更新日を台帳に記録しておけば、「気づいたら自動更新されていた」という事態は避けやすくなります。
初版はどこまで作れば十分か
ここまで、3つの台帳とそれぞれに持たせたい列を挙げてきました。 ただ、最初からすべての列を埋める必要はありません。 台帳には「初版」と「育てた後の形」の2段階があり、初版の段階で完成形を目指すと、埋まらない列を調べているうちに手が止まりがちです。
初版の役割は、判断に使う情報を揃えることより先に、まず存在を漏れなく並べることです。 埋めるのは2種類の情報、つまり一件を特定できる情報と、それが誰のものか（利用者。決まっていなければ管理責任者や保管場所）で足ります。 具体的には、アカウント台帳ならシステム名、アカウントID、利用者の3列です。 端末台帳とSaaS台帳も同じ考え方で、端末はシリアル番号、機種、利用者、SaaSはサービス名、用途、管理者から始めます。
このとき「営業部のPC 10台」のようにまとめず、1台を1行に分けて書いてください。 まとめた行は後から分割しようとしても元の内訳が分からず、退職や紛失の対応で「どの1台か」を特定できないため、結局初版から作り直すことになります。
購入日、権限の詳細、暗号化の有無、料金、契約更新日といった残りの列は、初版では作らなくて構いません。 その情報がないと判断できない場面が来たときに、列ごと足していきます。 権限の列はアカウントの棚卸しを始めるとき、契約更新日はコストの見直しに着手するとき、という順で自然に増えていきます。
台帳を「作って終わり」にしない仕組み
台帳整備の失敗は、作ることではなく維持で起きます。 台帳の更新を業務フローに埋め込む形にしてしまえば、この問題は起きにくくなります。
具体的には、アカウント発行と同時に台帳へ記入する、退職手続きのチェックリストに台帳更新の項目を入れる、というように人事のイベントと連動させる形が機能しやすいです。 棚卸しの頻度は、毎月では続かないことがほとんどなので、四半期に一度、台帳と実態を突き合わせる30分ほどの時間を確保することをおすすめします。 ツールも、最初から資産管理の専用ツールを探す必要はありません。 スプレッドシートで十分で、運用が回り始めてから移行を検討しても遅くはありません。
まず目指すべきゴール
「何から手を付ければいいか分からない」と最初に相談をくださった方に、あらためて答えるなら、アカウント、端末、SaaSの3つの台帳を作ることです。 最初のゴールは、3つの台帳の初版がそろい、入退社や端末の購入・廃棄、契約の開始・解約のたびに誰が更新するかが決まっている状態です。 そこまで整えば、あとは台帳を実態に合わせて育てていけます。
退職対応は、台帳がとりわけ威力を発揮する場面です。 詳しくはオフボーディング設計の記事で書いています。 台帳整備から手伝ってほしいという方は、情シス伴走支援のページをご覧ください。 IT資産の台帳整備は、ご支援の定番メニューです。