スプレッドシートが部署ごとに乱立する

スプレッドシート乱立の本当の原因

乱立は怠慢ではなく、業務上の必然から生まれます。部署ごとに見たい切り口が違い、自分用に加工したいニーズがあるからこそ、シートが増えていきます。

「一元化すれば解決する」と考えがちですが、一元化しても「自分用に加工したシート」は残ります。正のデータを決めず、運用だけで統合しようとすると、また乱立します。

sento.groupの解き方

乱立を消すのではなく、正のデータと参照の流れを設計します。加工シートは許容しつつ、元データがどこにあるかを明確にします。

• 乱立シートの棚卸し（どこに、何が、誰が管理しているか）
• 正のデータの特定と定義（更新責任・訂正手順を含む）
• 参照の流れの設計（正→加工シートへの連携）
• 統合すべき部分と、乱立を許容する部分の切り分け

乱立をゼロにするのではなく、「どれが正か分からない」という状態を解消することがゴールです。

乱立のパターンを分ける

乱立にはいくつかのパターンがあり、パターンによって対策が変わります。

• 加工目的の乱立：報告用・分析用に形を変えている → 正のデータからの自動連携で解消
• 信頼の問題：他部署のシートを信用できない → 定義と更新責任の明確化で解消
• システムの穴：SaaSに出力機能がない → API連携・データ基盤の検討
• 履歴の蓄積：過去バージョンが残り続けている → 命名規則・バージョン管理の導入

複数のパターンが重なっている場合は、影響の大きいものから順に整理します。

データのサイロ化との関係

スプレッドシート乱立は、データのサイロ化の一形態です。サイロ化の解消方法は「データのサイロ化とは」のページも参照ください。

乱立がSaaS間のデータ断絶と組み合わさっている場合は、SaaSデータ連携・データ基盤の検討が必要になることもあります。

相談の入口

「同じデータのはずなのに数字が合わない」という場面があれば、そこから整理できます。どのシートが正で、どこが加工なのかを確認し、参照の流れを設計します。