100人を超えたら属人化台帳をどう運用に乗せるか。作って終わりにしない仕組み化

ひとり情シスの時代に作ったシステム管理台帳は、作成した瞬間が最も正確で、そこから時間が経つほど実態とずれていきます。社員が100人を超え、システムを担当する人数が2〜3人に増えてくると、この「ずれ」は加速度的に大きくなります。理由は単純です。台帳を作った本人以外のメンバーが新しいSaaSを契約したり、既存システムの管理者を交代したりするたびに、台帳への反映が漏れる機会が増えるからです。ひとりで運用していた頃は「気づいたら自分が直す」で済んでいたことが、複数人体制になると「誰かが直すだろう」という空白地帯を生みます。このガイドでは、100〜300人規模の会社が台帳を「作って終わり」にせず、継続的に更新される運用に乗せるための具体的な設計を解説します。

なぜ複数人体制になると台帳が腐りやすくなるのか

台帳の劣化は、担当者が増えることそのものが原因ではありません。原因は「更新の責任範囲が曖昧なまま人数だけが増える」ことにあります。ひとり体制のときは、良くも悪くも責任の所在が明確でした。台帳が古ければ、それは担当者本人の見落としであり、本人が気づけば直すという単純な構造です。

ところが2〜3人の体制になると、「このシステムの担当は自分ではないから、台帳の更新も自分の仕事ではない」という心理が働きやすくなります。特に、システムごとの担当分担がまだ明文化されていない移行期には、この空白地帯が生まれやすくなります。担当分担の決め方そのものについては、兼任が2〜3人に増えたときの担当分担、誰が何を持つかの決め方で扱っていますので、台帳の運用設計と合わせて整備することをお勧めします。

さらに、100人を超える規模になると、契約しているSaaSやシステムの数自体も増加します。部署ごとに個別契約したツール、拠点ごとに異なる運用のシステムなど、ひとりが全体を把握しきれない量に達している会社も少なくありません。台帳がカバーすべき対象が増えるほど、更新漏れが起きる確率も上がるという、規模拡大に伴う構造的な課題です。

台帳運用でよくある3つの失敗パターン

100〜300人規模の会社で実際によく見られる、台帳運用の失敗パターンを整理します。

• 「誰かが更新するだろう」問題: 更新責任者が明示されておらず、結局誰も更新しない。数ヶ月後に確認すると、退職済みの担当者名がそのまま残っている、契約が終了したSaaSが載ったままになっているといった状態に陥る
• 棚卸しの号令だけで終わる問題: 「今度全社で台帳を見直しましょう」という号令はかかるが、具体的な頻度・担当・手順が決まっていないため、1回きりのイベントで終わり、翌年には誰も覚えていない
• 台帳が複数存在してしまう問題: 部署ごと、拠点ごとに独自の台帳が作られ、どれが正なのか分からなくなる。特に複数拠点を持つ会社ではこの問題が起きやすく、詳しくは100-300人規模で複数拠点にシステムが散らばる問題の整理手順で扱っています

これらの失敗パターンに共通するのは、「台帳の存在」と「台帳の運用ルール」を切り離して考えてしまっていることです。台帳というドキュメントを作ることと、それを継続的に正確な状態に保つ仕組みを作ることは、まったく別の設計課題として扱う必要があります。

更新責任者を「システムオーナー」として明示する

台帳を運用に乗せる第一歩は、台帳全体の管理者とは別に、システムごとの「更新責任者（システムオーナー）」を明示することです。100〜300人規模になると、情シス担当者がすべてのシステムの詳細を把握し続けることは現実的ではなくなります。そこで、各システムについて「実際にそのシステムを日常的に使い、変更があれば真っ先に気づく立場の人」を更新責任者として台帳に記載します。

ここで重要なのは、「システムオーナー」と「台帳更新担当」を分けて考えることです。経理部で使っている会計システムの実態を最もよく知っているのは経理部のメンバーであり、情シス担当者ではありません。システムオーナーには「変更があったら情シス担当者に知らせる」責任を持たせ、台帳への実際の反映作業は情シス担当者側が担う、という分業にすると、現場の負担を最小限にしながら情報の鮮度を保てます。

システムオーナーの指名は、口頭の依頼だけでなく、部署の月次会議や全社会議の場で正式にアナウンスすることをお勧めします。「なんとなく詳しい人にお願いする」という曖昧な形では、依頼された本人も自分の責任範囲を認識しづらく、結局更新が滞る原因になります。

棚卸し頻度をシステムの重要度で分ける

台帳全体を同じ頻度で棚卸しする必要はありません。すべてのシステムを毎月確認しようとすると、確認作業自体が大きな負担になり、結局続かなくなります。システムの重要度に応じて、棚卸しの頻度を段階的に設定することをお勧めします。

1. 基幹系（人事・給与・会計など）: 四半期に1回。契約内容の変更や利用者数の増減が業務に直結するため、比較的高頻度で確認する
2. 業務系（部署ごとのSaaS）: 半期に1回。部署の担当者交代のタイミングで漏れが起きやすいため、人事異動の時期に合わせた確認も有効
3. 周辺系（個別ツール・トライアル導入のSaaS）: 年1回。利用が定着しているか、そもそも使われなくなっていないかを中心に確認する

この頻度設定は、あくまで目安です。会社の実情に応じて調整してください。重要なのは、頻度を決めたら、それをカレンダーに組み込み、確認作業自体をルーティン化することです。「思い出したら確認する」という運用では、結局後回しにされ続けます。

棚卸しを「イベント」ではなく「習慣」にする工夫

棚卸しを一度きりの大がかりなイベントとして扱うと、継続しにくくなります。むしろ、日常の業務フローの中に棚卸しの契機を組み込む方が、無理なく継続できます。

• 新規契約・解約のタイミングで即時反映: 新しいSaaSを契約したら、その場で台帳に1行追加する。解約時も同様に、その場で削除または「解約済み」に更新する運用を徹底する
• 人事異動・入退社のタイミングで確認: 担当者が異動・退職する際、引き継ぎのチェックリストに「担当システムの台帳記載を確認・更新する」項目を入れる
• 予算申請・契約更新のタイミングで棚卸し: SaaSの契約更新月には、その契約に関する台帳の記載内容を見直す。ちょうど契約内容を確認する必要があるタイミングなので、二度手間になりにくい

このように、棚卸しを独立したイベントにするのではなく、既存の業務フロー（契約・異動・更新）に「ついでに確認する」形で埋め込むことで、継続のハードルを大きく下げられます。

「半期に1回、全社で棚卸しの日を設けています。ただし、それとは別に、契約や異動のタイミングでも都度更新するルールにしているので、半期の棚卸しは『漏れがないかの最終チェック』程度の負担で済んでいます」

このような二段構えの運用が、100〜300人規模での現実的な落としどころです。

台帳の保管場所とアクセス権限の設計

複数人が更新する台帳になると、保管場所とアクセス権限の設計も重要になります。ひとり情シスの時代は、自分だけがアクセスできる場所に保管していても問題ありませんでしたが、複数人が更新する台帳では、関係者全員がアクセスできる状態にしておく必要があります。

一方で、台帳にはパスワードそのものではないにせよ、管理者アカウントのメールアドレスや契約内容といった機微な情報が含まれます。アクセス権限を広げすぎると、情報漏えいのリスクも高まります。実務上は、次のような権限設計が現実的です。

• 編集権限: 情シス担当者と、各部署のシステムオーナーのうち台帳更新を任された人に限定する
• 閲覧権限: 部門長クラスまで広げ、緊急時に誰でも参照できる状態にしておく
• 一般社員への公開: 原則として行わない。緊急連絡先など、一部の情報のみを別途まとめた簡易版を用意する方が安全

権限設計に迷った場合は、「更新できる人は最小限に、参照できる人は必要な範囲に」という原則に立ち返ってください。編集権限を広げすぎると、誰が何を変更したか追いづらくなり、かえって台帳の信頼性を損ないます。

台帳更新のログを残す

複数人で更新する台帳では、「いつ、誰が、何を変更したか」の履歴を残すことも重要です。クラウド上のスプレッドシートであれば、変更履歴機能を活用できます。もし専用の資産管理ツールを導入している場合は、多くのツールに変更ログ機能が標準で備わっています。

履歴を残す目的は、単に「誰の責任か」を追及するためではありません。むしろ、「このシステムはいつ契約が変わったのか」「担当者はいつ交代したのか」という会社のIT環境の変遷そのものが、履歴として蓄積されていくことに価値があります。特に、後から入社したメンバーが会社のシステム変遷を理解する際、この履歴は貴重な資料になります。

台帳と引き継ぎ書の関係を整理する

台帳と、個々のシステムに関する引き継ぎ書は、しばしば混同されがちですが、役割が異なります。台帳は「会社全体のシステムの一覧性」を担保するための資料であり、個々のシステムの操作手順や設定の詳細までは記載しません。一方、引き継ぎ書は特定のシステムについて、実際の操作方法やトラブル対応の勘所まで含めた、より詳細な資料です。

100〜300人規模になり、システムごとの引き継ぎ書を整備する段階になったら、台帳の該当行から引き継ぎ書へのリンクを貼っておくと、両者が有機的につながります。台帳を見れば「どんなシステムがあるか」が分かり、そこから引き継ぎ書に飛べば「具体的にどう扱うか」まで分かる、という二層構造です。引き継ぎ書のフォーマット統一については、チーム化する情シスの引き継ぎ書、個人の作業メモから組織のドキュメントへで詳しく解説しています。

台帳運用の形骸化を防ぐチェックポイント

台帳を作ってから半年〜1年ほど経過した段階で、次のようなチェックポイントを確認することをお勧めします。形骸化の兆候を早期に発見し、手遅れになる前に軌道修正するためです。

これらのチェックを、前述の棚卸し頻度に合わせて定期的に実施することで、台帳が実態から乖離していく前に気づける体制になります。

台帳のデータ構造を「1シート」から「関係構造」へ広げる

100人未満の段階では、1枚のシートにシステム名と担当者を並べるだけの台帳でも十分に機能します。しかし100〜300人規模になると、システム同士の依存関係、契約と利用部署の対応関係、利用者数の増減といった、単純な一覧では表現しきれない情報が増えてきます。ここで有効なのが、台帳を「システム台帳」「契約台帳」「利用者台帳」のように、目的別に分割しつつ、共通のキー（システム名やシステムIDなど）で紐づける設計です。

• システム台帳: システムの機能・オーナー・技術的な構成を記録する
• 契約台帳: 契約金額・支払いサイクル・契約更新日・契約者名義を記録する
• 利用者台帳: どの部署の何人がそのシステムを利用しているかを記録する

1枚のシートにすべてを詰め込むと、列数が膨大になり、かえって更新の手間が増えて形骸化しやすくなります。目的別に分けることで、それぞれの台帳の更新頻度や担当者を個別に最適化できるようになります。例えば契約台帳は経理と連携して更新し、利用者台帳は各部署のシステムオーナーが更新する、というように、台帳ごとに適した運用フローを設計できます。

ただし、分割しすぎると今度は「どの台帳を見ればよいか分からない」という新たな問題が生まれます。分割は、実際に更新担当者が異なる場合や、更新頻度が大きく異なる場合に限定し、むやみに細分化しないことが肝心です。目安として、担当者と更新頻度が同じ情報同士はまとめておき、異なる場合にのみ分割するという基準で判断してください。

台帳のデジタル化・自動化をどこまで進めるべきか

100〜300人規模になると、台帳の更新作業そのものを自動化したいという発想も出てきます。実際、IT資産管理専用のSaaSを導入すれば、社内の端末やアカウントの情報を自動的に収集し、台帳の一部を自動更新できる場合があります。こうしたツールの活用は有効な選択肢ですが、導入にあたっては次の点を確認することをお勧めします。

1. 自動収集できる範囲とできない範囲を切り分ける: 端末情報やアカウント一覧は自動収集に向いていますが、契約者名義や解約予定といった情報は、依然として人手での確認が必要です
2. 既存の台帳運用との二重管理を避ける: 自動化ツールを導入したことで、既存の手動台帳と情報が二重管理になり、かえって混乱するケースがあります。導入する際は、既存の台帳をどう統合または廃止するかを事前に決めておく
3. 費用対効果を見極める: 100〜300人規模では、専用ツールの費用が見合わないケースもあります。まずは無償のスプレッドシートで運用の型を作り、規模がさらに拡大してから専用ツールへの移行を検討するという段階的なアプローチも現実的です

自動化はあくまで手段であり、目的ではありません。手動運用でも、更新責任者と棚卸し頻度が明確であれば十分に機能します。自動化を急ぐあまり、運用の設計そのものを疎かにしないよう注意してください。

台帳の粒度をどこまで細かくするか

台帳を整備していく過程で、しばしば悩ましいのが「どこまで細かく記録すべきか」という粒度の問題です。細かすぎる台帳は更新の負担が大きくなり、粗すぎる台帳は緊急時に役に立ちません。次のような基準で粒度を判断することをお勧めします。

基幹系のシステムほど細かく、周辺的なツールほど粗く、というメリハリをつけることで、台帳全体の更新負担を現実的な範囲に収めることができます。すべてのシステムに同じ粒度を求めると、結局どこかで運用が破綻します。

台帳運用を新任メンバーに引き継ぐときの注意点

情シスチームのメンバーが交代する際、台帳の更新責任も一緒に引き継がれることになります。この引き継ぎがうまくいかないと、せっかく整備してきた台帳の運用が、担当者交代のタイミングで途切れてしまうことがあります。新任メンバーへの引き継ぎでは、次の点を明確に伝えることが重要です。

• 台帳の存在そのものと、保管場所へのアクセス方法
• 各システムオーナーとの連絡体制、これまでの運用で見えてきた協力の得やすさ・得にくさの傾向
• 直近の棚卸しでどんな問題が見つかり、どこまで解消できているか
• 台帳運用にまつわる「暗黙のルール」があれば、それも言語化して伝える

特に最後の「暗黙のルール」は見落とされがちです。例えば「このシステムオーナーは多忙なので、四半期ごとの棚卸し依頼はメールではなく対面で伝えたほうが反応がよい」といった、台帳そのものには書かれていない運用上のコツが、実際には数多く存在します。こうした暗黙知の引き継ぎ不足は、台帳という「仕組み」自体が新たな属人化を生む皮肉な結果につながりかねません。運用のコツまで含めて言語化し、チーム内で共有できる形にしておくことをお勧めします。

経営層への台帳の見せ方: 何を報告し、何を求めるか

台帳の運用は、情シスチーム内だけで完結する話ではありません。100〜300人規模になると、経営層や部門長が「会社のIT資産の状況を把握したい」と考える機会が増えてきます。このとき、台帳そのものを丸ごと見せるのではなく、経営層が判断に使える形に要約した報告資料を用意しておくと、コミュニケーションが円滑になります。

経営層への報告では、次のような観点でサマリーを作成することをお勧めします。

1. 契約総額の推移: システム全体でどの程度の費用がかかっているか、前年・前四半期との比較
2. 重複・未使用システムの有無: コスト削減の余地がある領域
3. セキュリティリスクの高い項目: 名義不明・保守切れなど、経営判断が必要な事項
4. 棚卸しの実施状況: 台帳がどの程度最新の状態に保たれているか

台帳の運用体制そのものを経営層に理解してもらうことも重要です。台帳の維持には一定の工数がかかるという実態を共有しておくことで、棚卸しのための時間確保や、必要であれば専用ツールの導入予算についても、理解を得やすくなります。逆に、台帳の存在や運用の手間が経営層に見えないままだと、「なぜこんなに時間がかかっているのか」という誤解を招くこともあります。定期的な報告は、台帳運用の正当性を組織内で確立するためにも有効な手段です。

報告の頻度は、四半期ごとの経営会議のタイミングに合わせるのが現実的です。毎月細かく報告する必要はなく、むしろ頻度が高すぎると「またこの報告か」と受け止められ、内容が形骸化しがちです。四半期に1回、要点を絞った1〜2ページ程度の資料にまとめることで、経営層にとっても消化しやすく、情シス側にとっても準備の負担が少ない、持続可能な報告サイクルを作ることができます。報告を重ねるうちに、経営層側からも「このシステムは本当に必要か」といった踏み込んだ質問が出てくるようになれば、台帳が単なる管理資料を超え、経営判断を支える情報基盤として機能し始めている証拠だといえます。

台帳運用のよくある質問

台帳の運用設計を進める過程で、実際によく聞かれる疑問についてまとめます。

Q. 台帳の棚卸しに、どのくらいの時間を見込んでおくべきですか。

システムの数や複雑さによって大きく異なりますが、100〜300人規模で、システム数が50〜100件程度の会社であれば、四半期ごとの基幹系の棚卸しに半日〜1日、半期ごとの業務系の棚卸しに1〜2日程度を見込んでおくと現実的です。初回の棚卸しは、これまで蓄積してきたずれを解消する作業も含まれるため、通常より時間がかかることを想定しておいてください。

Q. システムオーナーが協力的でない場合、どう対処すればよいですか。

まず、システムオーナーへの依頼が「面倒な追加業務」として受け取られていないか確認してください。依頼の背景（なぜ台帳が必要か、更新しないとどんなリスクがあるか）を丁寧に説明することで、協力を得やすくなることがあります。それでも協力が得られない場合は、上長を通じて正式な業務として位置づけてもらう、あるいは更新作業自体を情シス側で巻き取り、システムオーナーには確認のみを依頼する形に変更するといった調整も検討してください。

Q. 台帳とパスワード管理ツールは統合すべきですか。

原則として分けることをお勧めします。台帳は「何がどこにあり、誰が管理しているか」という一覧性を担う資料であり、パスワードそのものを含めるべきではありません。パスワードは専用の管理ツールで別途管理し、台帳側には「パスワードはこのツールのこのフォルダに保管されている」という参照情報のみを記載する形が、セキュリティ上も運用上も望ましい設計です。

Q. 台帳の項目を増やしたいという要望が現場から出た場合、どう対応すべきですか。

要望をすべて受け入れると、台帳が肥大化し、更新負担が増えて形骸化のリスクが高まります。まずは「その項目は緊急時や棚卸し時に本当に必要か」を確認し、必要性が高いと判断できる場合のみ追加してください。個別のシステムに特有の詳細情報であれば、台帳本体には追加せず、そのシステムの引き継ぎ書側に記載する形で切り分けるという選択肢も検討する価値があります。台帳は「一覧性」を守ることが最優先であり、詳細情報は別の資料に委ねるという役割分担を崩さないことが、長期的に機能し続けるための鍵になります。

まとめ: 台帳は「作る」より「回す」ほうが難しい

台帳を作ること自体は、時間さえかければ誰にでもできる作業です。しかし、100〜300人規模の複数人体制でその台帳を正確な状態に保ち続けることは、作成そのものよりもずっと難しい課題です。この難しさの正体は、「更新責任の所在が曖昧になりやすい」という、人数が増えることに伴う構造的な問題にあります。

システムオーナーの明示、重要度に応じた棚卸し頻度の設計、既存の業務フローへの棚卸しの組み込み、適切なアクセス権限の設計。これらを一つずつ整えていくことで、台帳は「作って満足する資料」から「日々更新され続ける、会社の生きた地図」へと変わっていきます。台帳の運用設計に唯一の正解はありませんが、「誰が」「いつ」「何を」更新するかを曖昧にしないことだけは、どんな会社にも共通する原則です。

台帳の完成度を100点にしてから運用を始めようとすると、いつまでも着手できません。まずは今ある台帳に、システムオーナーの列を1つ追加するところから始めてください。次の四半期の棚卸し予定日をカレンダーに入れる。それだけでも、台帳は「作りっぱなしの資料」から「動き始めた仕組み」へと変わります。100〜300人という規模は、ひとりで抱えきれる情報量を超えつつも、まだ複雑な管理体制を構築するには早い、ちょうど過渡期にあたります。この過渡期にこそ、身の丈に合った運用の型を作っておくことが、その後さらに組織が拡大していく局面で大きな土台になります。

将来的に社員数が300人を超え、専任の情シス部門としてさらに拡大していく局面では、台帳の運用もより高度な仕組みへと発展させていく必要が出てくるでしょう。しかし、その発展形がどのようなものであれ、根底にあるべき考え方は変わりません。台帳は誰か1人の頭の中にある知識ではなく、組織として共有され、更新され続ける「生きた資産」であるべきだという原則です。100〜300人規模の今、この原則に沿った運用の土台を作っておくことが、将来の組織拡大に耐えうる情報基盤への最も確実な投資になります。