全社台帳をシステム化した後、部署ごとのローカルExcelが復活する問題

苦労して部署をまたいだ台帳統合を終え、全社共通のシステムに一本化できたと安堵した半年後、気づくと営業部の一部メンバーが再び独自のExcelファイルを作り始めていた。100〜300人規模の会社で、この「シャドー台帳の再発」は決して珍しい現象ではありません。統合プロジェクトそのものは技術的に成功していても、システム化した後の運用設計が不十分だと、現場の使い勝手の悪さから、静かに、しかし確実に元のExcel運用へ回帰していきます。厄介なのは、この復活が大々的な反対運動として表面化するのではなく、一部の担当者が個人の判断で「ちょっとだけ楽をするために」始めることが多く、情シス側が気づいたときには、すでに複数部署で定着してしまっているという点です。このガイドでは、統合後にシャドー台帳が再発する原因と、それを防ぐための運用ルールの設計を解説します。

この記事で分かること

全社的な台帳システム化が完了した後、部署ごとのローカルExcelが復活する「シャドー台帳の再発」がなぜ起きるのか、その兆候をどう早期発見するか、再発を防ぐためにどのような運用ルールを設計すべきかを扱います。統合作業そのものの進め方は部署をまたいだExcel台帳の重複、統合前にやるべき突き合わせ作業に譲ります。

シャドー台帳が復活する典型的な原因

システム化した台帳が、なぜ時間の経過とともにExcelへ回帰してしまうのか。原因は一つではなく、複数の要因が積み重なって起きることがほとんどです。代表的な原因を整理します。

• システムでは対応できない集計・加工作業が現場に残っている: 統合システムは全社共通の項目・形式を前提に設計されるため、特定の部署だけが必要とする独自の集計軸や表示形式に対応しきれないことがある。現場はその不足分をExcelで補おうとする
• 入力の手間がExcelより増えている: 新システムの入力項目が多い、あるいは操作手順が複雑で、Excelに直接入力するほうが速いと感じられている
• 一時的な「仮の記録」のつもりが定着してしまう: 出張中や外出先でシステムにアクセスできない際、一時的にExcelにメモしたものが、そのまま正式な記録として使われ続けてしまう
• 新しく異動・入社したメンバーが、旧来のExcel運用しか知らない: 統合プロジェクトの当事者ではなかったメンバーが、周囲を見て「前任者がExcelで管理していたから」という理由でローカルファイルを作ってしまう

これらの原因に共通するのは、統合システムそのものの欠陥というより、「現場の実際の業務フローと、システムが想定する業務フローの間にギャップがある」ことです。このギャップが埋まらないまま放置されると、現場は自然とギャップを埋めるための独自の工夫（＝シャドー台帳）を編み出していきます。

なぜ100-300人規模で特に起きやすいのか

シャドー台帳の再発は、どの規模の会社でも起こりうる現象ですが、100〜300人規模では特に発見が遅れやすいという特徴があります。理由は、情シスチームの目が届く範囲と、実際に業務が行われている現場の距離が、30〜100人規模の頃より広がっているためです。

ひとり情シスの時代であれば、社内の様子を日常的に見て回るだけで「あ、また誰かがExcelを作っている」と気づける規模感でした。100〜300人規模、複数拠点にまたがる組織になると、情シス担当者が全部署・全拠点の日常業務を直接観察することは現実的に不可能になります。結果として、シャドー台帳は情シス側が気づかないまま、数ヶ月、時には1年以上にわたって静かに拡大し続けることがあります。

兆候を早期に発見するためのモニタリング

シャドー台帳の再発を完全にゼロにすることは難しいものの、早期に発見できれば、被害が拡大する前に手を打てます。次のようなモニタリングの仕組みを組み込んでおくことをお勧めします。

1. システムの利用率を定期的に確認する: 統合システムへのログイン頻度、レコードの新規登録・更新頻度を部署別に確認する。特定の部署だけ更新が止まっている場合、別の場所でデータ管理が行われている可能性がある
2. 部署への定期ヒアリングにシャドー台帳の有無を含める: 100人を超えたら属人化台帳をどう運用に乗せるかで扱う棚卸しのタイミングに合わせて、「システム化した業務について、部署内で個別にExcelを使っていないか」を確認項目に加える
3. 問い合わせ内容から兆候を読み取る: 「この集計、システムでできますか」「このデータをExcelに書き出したい」といった問い合わせが増えている場合、現場がシステムの機能不足を感じている兆候かもしれない

これらのモニタリングは、単発で行うのではなく、既存の運用サイクル（台帳の棚卸し、定例ミーティングなど）に組み込むことで、追加の負担を抑えながら継続できます。

「システム化して半年後の棚卸しで、ある拠点だけ更新頻度が極端に低いことに気づきました。確認したところ、拠点独自のExcelで先に記録して、月末にまとめてシステムに転記していたことが判明しました。本人たちに悪気はなく、システムの入力画面が拠点のPC環境で動作が重かったことが原因でした」

再発を防ぐための運用ルール設計

シャドー台帳の再発を防ぐには、モニタリングによる早期発見だけでなく、そもそも再発の動機を減らす運用ルールの設計が重要です。次のような観点でルールを整備することをお勧めします。

• 正式な記録の置き場所を明確にし、周知を徹底する: 「この業務の正式な記録は統合システムのみ」という原則を、新規入社者向けのオンボーディング資料にも含める
• システムでカバーしきれない部署独自のニーズを定期的に吸い上げる: 統合システムの機能改善要望として正式に受け付ける窓口を作り、現場が「文句を言ってもどうせ変わらない」と諦めてExcelに逃げる状況を作らない
• 一時的な代替手段を使う場合のルールを明文化する: 出張中など、システムに一時的にアクセスできない状況で仮の記録を取る場合の手順（後で必ずシステムに反映する期限を決めるなど）をあらかじめ定めておく

特に2番目の「機能改善要望の窓口」は見落とされがちですが、非常に効果的な予防策です。現場が「システムのここが使いにくい」と感じたとき、その不満をぶつける先がないと、黙ってExcelに戻ってしまいます。不満を正式なルートで受け止め、対応の可否とその理由を返すだけでも、シャドー台帳へ流れる動機を大きく減らせます。

アクセス権限の設計が再発防止に果たす役割

シャドー台帳が生まれる背景には、統合システムへのアクセス権限の設計が実態に合っていないケースもあります。例えば、必要な情報を閲覧する権限しかなく、自分の業務に必要な形での出力・加工ができない担当者が、結局手元でExcelに書き出して独自に加工し、それがそのまま定着してしまう、という経路です。

権限設計が過度に厳格すぎると、現場は正規のルートで業務を回せず、非公式な手段に頼らざるを得なくなります。逆に権限を緩めすぎると、今度は情報の一貫性やセキュリティが損なわれます。この匙加減の設計については、100人超え組織のExcel権限管理、閲覧・編集範囲をどう分けるかで詳しく扱っていますので、シャドー台帳の再発防止策とあわせて検討することをお勧めします。

再発してしまった場合の対処手順

モニタリングをすり抜けてシャドー台帳が定着してしまった場合、発見した時点でどう対処するかも重要です。頭ごなしに「ルール違反だからやめてください」と指摘するだけでは、表面上はExcelの利用をやめても、別の見えない形で同じ問題が再発するリスクが残ります。

1. なぜそのシャドー台帳が必要とされたのかをヒアリングする: 現場を責めるのではなく、システムのどこに不足があったのかを理解する機会と捉える
2. 不足している機能・運用の改善で対応できないか検討する: ヒアリングの結果、システム側の改善で解消できる不足であれば、優先的に対応を検討する
3. 統合システムへのデータの取り込みを支援する: シャドー台帳に蓄積されたデータを、正規のシステムに反映させる作業を情シス側でサポートする
4. 再発防止の確認を後日実施する: 対応後、一定期間を置いて同様の問題が再発していないか確認する

この対処プロセスを、単なる「注意して終わり」にせず、システムや運用ルールの改善につなげる機会として扱うことが、長期的な再発防止において最も効果的です。

統合直後の「フォロー期間」を意識的に設ける

シャドー台帳の再発を防ぐ上で効果的な工夫の一つが、統合作業が完了した直後に、意図的な「フォロー期間」を設けることです。多くのプロジェクトでは、システムへの切り替えが完了した時点でプロジェクトが終了したとみなされ、その後の定着状況を追いかける工程が省略されがちです。しかし、実際に現場がシステムに慣れ、Excelへ戻る誘惑を感じなくなるまでには、数ヶ月単位の時間がかかることが一般的です。

• 切り替え直後の1〜3ヶ月は、利用状況を通常より高い頻度で確認する: 週次または隔週で、部署別の利用率や問い合わせ内容をチェックする
• この期間中に出た不満・要望は、優先的に対応を検討する: 定着期にシステムへの不満が積み重なると、それがそのままシャドー台帳への逃避につながりやすい
• フォロー期間の終了時点で、正式な定着確認を行う: 「この業務は完全にシステムに移行できているか」を関係部署とともに確認し、問題が残っていれば追加対応を検討する

このフォロー期間をプロジェクト計画の中に最初から組み込んでおくことで、「統合したら終わり」という認識のずれを防ぎ、再発リスクが最も高い時期を手厚くカバーできます。

現場担当者を巻き込んだ改善サイクル

シャドー台帳の再発を長期的に防ぐには、情シス側が一方的にルールを定めて監視するだけでなく、現場担当者自身がシステムの改善に関与できる仕組みを作ることも有効です。現場の担当者が「自分たちの意見が反映される」という実感を持てると、不満をシャドー台帳という形で表出させるのではなく、正式な改善要望として伝えるようになりやすくなります。

1. 各部署から「システム活用の窓口役」を任命してもらう: 情シス担当者との橋渡し役を部署側に置くことで、細かい不満が情シス側に届きやすくなる
2. 定期的に改善要望を集める場を設ける: 四半期に1回程度、システムの使い勝手について現場からフィードバックをもらう機会を作る
3. 反映できた改善・できなかった改善の両方を共有する: 要望がすべて通るわけではないことを理解してもらいつつ、検討した事実自体を可視化する

この改善サイクルは、複数部署から寄せられる要望を適切に捌く優先順位付けの仕組みとも密接に関連しています。システム定着後の改善要望も、脱Excelの新規要望と同様に、限られたリソースの中で優先順位をつけて対応していく必要があるためです。

拠点ごとの再発リスクの違いに注意する

複数拠点を持つ会社の場合、シャドー台帳の再発リスクは拠点ごとに一様ではありません。本社から物理的に離れた拠点ほど、情シス担当者の目が届きにくく、また現地特有の業務事情から、統合システムでは対応しきれない独自の運用が生まれやすい傾向があります。

• 拠点ごとの通信環境・端末環境の違いを確認する: 統合システムの動作が遅い、あるいは対応していない端末を使っている拠点では、Excelへの回帰が起きやすい
• 拠点責任者を通じた定期的な状況確認を組み込む: 本社からの一方的な監視ではなく、拠点責任者が現地の状況を能動的に報告してくれる関係性を築く
• 拠点特有の業務事情をヒアリングし、システム側で吸収できないか検討する: 本社基準では見えない拠点固有のニーズが、シャドー台帳の温床になっていることは珍しくない

拠点をまたぐ組織では、本社主導で決めたルールが、そのまま拠点の実情に合うとは限りません。拠点ごとの事情を丁寧にすくい上げる姿勢が、離れた場所での再発を防ぐ鍵になります。

シャドー台帳の再発防止を評価指標に組み込む

シャドー台帳の再発防止を、情シスチームの継続的な取り組みとして根付かせるためには、単発の対策で終わらせず、チームの定常的な評価指標の一つに組み込むことも有効です。

これらの指標を定点観測することで、「統合プロジェクトが終わった後も、その効果が維持されているか」を客観的に把握できます。単に「統合した」という事実だけで満足せず、統合後の定着状況を継続的にモニタリングする文化を、チーム全体で共有しておくことが望ましい姿勢です。

経営層への報告に再発防止の取り組みを含める

シャドー台帳の再発防止は、情シスチーム内だけで完結させる取り組みではなく、経営層への定期報告の項目としても位置づけておくことをお勧めします。台帳統合プロジェクトへの投資対効果を経営層に示す際、「統合しただけ」ではなく「統合後も定着し続けている」ことを示せると、情シスチームの取り組みへの評価にもつながります。

• 統合プロジェクトの成果報告に、統合直後だけでなく数ヶ月後の定着状況も含める: 一時点の成果だけでなく、時間経過後の状態も報告することで、取り組みの持続性が伝わる
• シャドー台帳の発見・対応事例があれば、教訓として共有する: 失敗を隠すのではなく、どう対応し、どう改善したかを含めて報告することで、チームの対応力の証明にもなる
• 再発防止の取り組みにかかる工数も、正当な業務として認識してもらう: モニタリングや現場ヒアリングには相応の時間がかかるため、これを正式な業務として経営層に理解してもらうことが、継続的な取り組みを支える土台になる

台帳統合は、システムを切り替えた瞬間に完了する作業ではなく、定着するまでを含めた継続的なプロジェクトであるという認識を、情シスチーム内だけでなく組織全体で共有できると、再発防止の取り組みも持続しやすくなります。

AIツールの普及がシャドー台帳の形を変えつつある点にも注意

近年は、表計算ソフトだけでなく、生成AIチャットツールに業務データを貼り付けて個人的に整理・分析するという、新しい形のシャドー運用も見られるようになってきました。これは従来のExcelファイルとは異なる形をとりますが、本質的には同じ「非公式なデータ管理の発生」という問題です。

• 業務データを外部の生成AIツールに入力する行為が、社内ルールで許可されているかを確認する: 顧客情報や機密性の高いデータを、許可なく外部サービスに入力してしまうリスクにも注意が必要
• 統合システム自体にAIを活用した分析・要約機能がないか確認する: 現場がAIツールを使いたくなる背景には「システムでは面倒な集計・分析が、AIなら簡単にできる」という動機があることが多く、統合システム側で同等の機能を提供できれば、外部ツールへの依存を減らせる
• AIツールの利用実態についても、定期的なヒアリングの対象に含める: 従来のExcelファイルの有無だけでなく、業務データの取り扱い全般について確認する視点を持つ

シャドー台帳という現象は、ツールの形を変えながら、今後も同じ構造で発生し続ける可能性があります。「Excelを見張る」という発想だけでなく、「なぜ現場が非公式な手段に頼りたくなるのか」という根本の動機に目を向け続けることが、長期的な再発防止の本質的なアプローチです。

複数の統合プロジェクトを経験したチームが持つべき視点

100〜300人規模の会社では、一つの台帳統合プロジェクトだけでなく、複数の業務領域で並行して、あるいは時期をずらして統合プロジェクトが進むことがあります。複数のプロジェクトを経験する中で、チームとして蓄積しておくべき視点があります。

• 過去のシャドー台帳再発の事例をチーム内のナレッジとして共有する: どの業務領域で、どのような理由から再発したかのパターンを蓄積しておくと、新しい統合プロジェクトの計画段階でリスクを予測しやすくなる
• 業務領域ごとに再発リスクの傾向が異なることを踏まえて対策の重みづけを変える: 例えば、現場での判断や個別対応が多い業務ほど、システムの画一的な運用に馴染みにくく、再発リスクが高くなる傾向がある
• チームメンバーが異動・退職しても、この知見が失われないよう文書化しておく: 個人の経験則として蓄積されるだけでは、いずれ組織の記憶から失われてしまう

このような知見の蓄積は、単発のプロジェクトを成功させることを超えて、情シスチーム全体の「統合プロジェクトを成功させる力」そのものを底上げしていきます。

統合システムの機能改善サイクルとの連動

シャドー台帳の再発を根本的に防ぐには、モニタリングと運用ルールだけでなく、統合システム自体を継続的に改善していくサイクルとも連動させる必要があります。システムが現場のニーズに追いつかないまま固定化されていると、どれだけ運用ルールを厳格にしても、いずれ限界が訪れます。

• 現場からの改善要望を、システムのアップデート計画に反映する仕組みを持つ: 要望を集めるだけでなく、実際に機能改善へつなげるサイクルを回す
• システムベンダーとの契約内容に、機能追加・カスタマイズの余地があるか確認しておく: パッケージ型のシステムでは、カスタマイズの自由度が限られる場合があり、現場の細かいニーズに対応しきれないことがある
• 改善サイクルの頻度を、現場の不満が蓄積する前のペースに合わせる: 年に1回程度の改善では、現場の不満が先に限界を迎え、シャドー台帳への逃避が起きてしまう可能性がある

システムを「一度導入したら終わり」ではなく「継続的に育てていくもの」として捉える姿勢が、シャドー台帳の再発を長期的に防ぐ最も本質的なアプローチです。

新任メンバーへの再発防止意識の引き継ぎ

シャドー台帳の再発防止は、一度仕組みを作った担当者だけが意識していても、その担当者が異動・退職した後に引き継がれなければ、意味を失っていきます。チームに新しく加わるメンバーに対して、この観点をどう引き継ぐかも重要な検討事項です。

• 過去にシャドー台帳が発生した事例と、その原因・対応をオンボーディング資料に含める: 抽象的な注意喚起だけでなく、具体的な事例を知ることで、新任メンバーも兆候に気づきやすくなる
• モニタリングの手順を、属人的な感覚ではなく手順書として残しておく: 「なんとなく気にかけていた」という暗黙知のままでは、引き継ぎの際に抜け落ちてしまう
• 新任メンバーが担当することになった部署・拠点について、優先的に現状のヒアリングを行ってもらう: 新しい目で現場を見ることで、既存メンバーが見過ごしていた兆候に気づけることもある

このような引き継ぎを丁寧に行うことで、シャドー台帳の再発防止という取り組みが、特定の個人の努力に依存せず、チームの継続的な文化として根付いていきます。

再発防止と現場負担のバランスを取る

シャドー台帳の再発防止を徹底しようとするあまり、モニタリングやヒアリングの頻度を過剰に増やしてしまうと、今度は現場に「監視されている」という圧迫感を与え、かえって情シスチームへの協力姿勢を損なうことがあります。再発防止の取り組みは、現場への負担とのバランスを常に意識しながら設計する必要があります。

• モニタリングの頻度は、リスクの高い業務領域から優先的に厚くし、リスクの低い領域は簡易的な確認にとどめる: すべての業務領域を同じ密度で監視しようとすると、情シス側の工数も膨らみ、現場の負担も増える
• ヒアリングは「取り締まり」ではなく「困りごとの相談」というトーンで行う: 同じ内容の確認でも、伝え方次第で現場の受け止め方は大きく変わる
• 再発を発見した際も、頭ごなしの指摘ではなく、背景を理解しようとする姿勢を保つ: 現場との信頼関係を損なわない対応が、長期的にはより効果的な再発防止につながる

再発防止の仕組みは、厳格であればあるほど良いわけではありません。現場との信頼関係を維持しながら、必要な範囲で目を配り続けるという、バランス感覚が求められる取り組みです。

統合済みシステムの成功事例を社内で共有する

再発防止の取り組みは、問題が起きたときの対処だけでなく、うまくいっている事例を積極的に共有することでも後押しできます。ある部署でシステムがしっかり定着し、業務が効率化された事例があれば、それを他部署にも伝えることで、「システムに移行してよかった」という実感が社内に広がり、シャドー台帳へ戻る動機そのものを弱められます。

• 定着に成功した部署の担当者に、実際の効果を語ってもらう機会を設ける: 情シス側からの説明よりも、現場の担当者自身の声のほうが説得力を持つことが多い
• 数値で示せる効果（作業時間の削減、入力ミスの減少など）があれば、具体的に共有する: 抽象的な「便利になった」ではなく、実感の伴う成果を示す
• 成功事例を社内報や定例会議など、目に触れやすい場で継続的に発信する: 一度きりの発信で終わらせず、繰り返し伝えることで浸透させる

シャドー台帳の再発防止は、ルールで縛るという守りの発想だけでなく、システムを使い続けたくなる動機を育てるという攻めの発想も、あわせて持っておくことが効果的です。

まとめ: シャドー台帳の再発は「現場からのフィードバック」でもある

シャドー台帳の再発は、放置すればデータの分散・二重管理という問題を再び引き起こしますが、見方を変えれば、統合システムや運用ルールの不備を教えてくれる貴重なフィードバックでもあります。単純に「ルール違反だからやめさせる」という対応に終始すると、表面上のExcel利用は止まっても、根本的な原因は解消されず、別の形で同じ問題が再発しかねません。

早期発見のためのモニタリングを仕組み化し、再発の動機そのものを減らす運用ルールを整備し、それでも起きてしまった場合には現場の声を丁寧に拾う。この3段構えの対応が、100〜300人規模の組織で統合システムを長期的に機能させ続けるための現実的なアプローチです。