1〜5人のIT台帳:端末・管理者・更新日・契約を整理する
この記事の内容
少人数の会社でIT台帳を作る目的は、すべてを細かく監視することではありません。PCが壊れた、担当が辞めた、契約が更新された、といった時に、誰が何を管理しているかを探せるようにすることです。
最初は、端末、業務サービス、接続関係の三つを分けた小さな一覧から始めます。パスワードを台帳へ集めず、秘密の保管場所を参照する形にすると、日常の確認に使いやすくなります。
端末とサービスを同じ一行へ詰め込まない
一台のPCで複数のサービスを使い、一つのサービスを複数人で使うことがあります。端末の行にすべてを書こうとすると、同じ契約情報を何度も更新する必要が生まれます。
端末表には、管理番号、利用者、所有者、OS、購入日、保護状態、返却先を記録します。サービス表には、サービス名、契約名義、管理者、利用者、支払者、更新日、解約条件を記録します。どの端末でどのサービスを使うかは、必要な場合だけ別に結び付けます。
IPAは、小規模事業者も使える情報セキュリティの資料と資産管理台帳のサンプルを公開しています。自社に必要な項目を考える出発点にできます。IPAの情報セキュリティ対策ガイドライン
管理者・利用者・支払者を分けて書く
クレジットカードの明細にサービス名があっても、誰が管理画面へ入れるか分かるとは限りません。逆に、利用者がログインできても契約変更の権限を持っていない場合があります。
| 項目 | 架空の記入例 | 分けておく理由 |
|---|---|---|
| 契約名義 | A事務所 | 会社の契約かを確認 |
| 管理者 | 代表者と予備担当 | 設定変更と復旧 |
| 利用者 | 制作担当2名 | 席数と権限 |
| 支払者 | 会社カード | 請求の追跡 |
| データ責任者 | 案件担当者 | 保管と引継ぎ |
| 問い合わせ先 | 公式サポート | 障害時の連絡 |
架空の3人会社では、代表者が払っている予約サービスを、退職した外注先だけが管理していた、という構成を避けたいところです。契約と業務が会社へ引き継がれているかを、台帳で見つけます。
管理者を増やす場合も、全員へ最高権限を渡すのではなく、製品が提供する役割に合わせます。予備の担当が入れることと、普段からすべてのデータを見ることは分けて設計できます。
OSの更新と契約更新を別の日付で持つ
「更新日」という一列では、ソフトを新しい版にした日なのか、年間契約が自動更新される日なのか分かりません。端末では最終確認日やサポート状況、契約では請求期間と解約期限を分けます。
ソフトの自動更新が有効でも、再起動待ちなどで適用されていない場合があります。台帳には「自動更新オン」だけでなく、いつ誰が状態を見たかを記録すると、放置された端末が分かります。
契約については、更新日の何日前までに手続きが必要かを製品の条件で確認します。年払いを月額相当で比較する場合も、実際の支払月を残してください。毎月の予算と年一回の支出が混ざらず、解約判断の時期を把握できます。
秘密を書かず保管場所と復旧経路を示す
台帳にパスワード、復旧コード、APIキーをそのまま記録すると、棚卸しのために開く人にも秘密を見せることになります。台帳には保管庫の項目名などを記録し、秘密自体へのアクセスは別に管理します。
例えば「メール管理者の認証情報は業務保管庫のメール管理項目」と示します。保管庫へ入れなくなった場合の復旧方法も、台帳に全文を書かず、管理担当と別保管の存在を記録します。
APIキーや自動化の接続は、どの業務が使っているかを記録することが特に重要です。キーを更新した時に何が止まるか分からないと、変更を先延ばしにしがちです。APIキー管理の方法を参考に、接続名、用途、担当、更新日をサービス表へ結び付けます。
入退社と契約変更の時に更新する
台帳を一度作って終えるより、変更が起きる場面で更新する方が続けやすくなります。入社、退職、端末購入、故障交換、外注開始・終了、サービス契約を更新のきっかけにします。
架空の入社手順なら、利用端末を登録し、必要なサービスを招待し、権限を確認し、台帳に担当者を記録します。退職時は逆に、その人の名前で台帳を検索し、端末、アカウント、共有、接続の残りを確認します。
この時、退職者がデータの所有者になっているサービスは、停止前に引継ぎを確認します。端末の返却だけで完了にせず、クラウドの所有権や課金人数まで確認します。退職・契約終了時のアカウント整理と台帳を連動させると、処理対象を思い出す負担が減ります。
更新した人と日付を残せば、情報が古いかを判断できます。人数が少なくても、変更を口頭だけで伝える運用は避け、管理画面を変えた人がその場で記録するルールにします。
続かない台帳は項目と用途を減らす
最初から何十列も作ると、入力が重くなって古い情報が残ります。使っていない列を削り、「端末を失った時」「契約を見直す時」「担当が変わる時」に必要な項目を優先します。
架空の棚卸しで、3人がそれぞれ10サービスを使っていても、契約が同じなら30契約ではありません。利用者との関係は別にし、契約は一件として管理すると、更新の重複を減らせます。台帳の行数を多くすること自体が目的ではありません。
月次の請求確認や端末の点検と合わせ、台帳にない支払や使っていない席がないかを見ます。新しい管理ソフトを買う前に、既存の表計算で運用が続くかを確かめてもよいでしょう。必要な通知や集計が増えた時に、権限・履歴・連携を備えた製品へ移す判断ができます。
完成の目安は、作成者が不在でも、必要なサービスの担当と契約、データの場所を探せることです。台帳を短く保ち、実際の変更と一緒に更新する仕組みを作ってください。