過去の分析資産が再利用されず同じ分析を繰り返す問題をなくし分析工数を半減させる方法

分析依頼が来るたびに、過去に誰かが作ったクエリやダッシュボードの存在を知らずゼロから分析を始めてしまう。この問題は多くの企業で起きています。SQLクエリ、Pythonスクリプト、Excelの加工手順、ダッシュボードといった分析資産が個人のPC内やローカルフォルダに散在し、検索も参照もできない状態が原因です。放置すると、同じデータ抽出と加工を何度も繰り返すことで分析工数が膨らみ続け、担当者の異動や退職のたびに分析ノウハウが消失します。

この記事は、従業員50〜500名規模の企業で、データ分析業務を担当しているマーケティング部門や経営企画部門の担当者、あるいは情報システム部門で分析基盤の整備を兼務している方を想定しています。読み終えると、分析資産を組織の共有財産として蓄積・検索・再利用できる仕組みの全体像と、具体的な運用サイクルが分かります。大規模エンタープライズ向けのデータガバナンス設計や、個別ツールの網羅的なレビューは扱いません。

なお、本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、分析クエリとダッシュボードの登録・検索・再利用の運用フローを自社に導入するための具体的な手順書が手に入ります。

Workflow at a glance: 過去の分析資産が再利用されず同じ分析を繰り返す問題をなくし分析工数を半減させる方法

• Step 1: 分析クエリとスクリプトをバージョン管理に登録する (GitHub) (IDE（統合開発環境）)
• Step 2: ダッシュボードを共有ワークスペースに公開する (Looker Studio) (BIツール)
• Step 3: 分析資産カタログを作成し検索可能にする (Notion) (ナレッジマネジメントツール)

なぜ同じ分析を何度も繰り返してしまうのか

分析資産が個人に閉じている

分析担当者がSQLクエリやスクリプトを自分のPCのデスクトップやローカルフォルダに保存している状態では、他の担当者からはその存在が見えません。たとえば営業部門から月次の売上推移分析を依頼されたとき、3か月前にマーケティング部門向けにほぼ同じ分析を別の担当者が実施していたとしても、その事実を知る手段がありません。結果として、データ抽出のSQLを書き直し、加工ロジックを再構築し、グラフを一から作り直すという作業が発生します。

分析の文脈が記録されていない

仮にクエリやダッシュボードのファイル自体を共有フォルダに置いたとしても、そのファイルがどんな目的で、どんな前提条件のもとで作られたのかが記録されていなければ再利用できません。ファイル名が analysis_v3_final2.sql のような状態では、中身を開いて読み解く手間がかかり、結局ゼロから作り直した方が早いという判断になります。

担当者の異動・退職で資産が消失する

個人のPCに閉じた分析資産は、担当者が異動や退職をした瞬間に事実上消失します。引き継ぎ資料にすべてのクエリやスクリプトを網羅することは現実的に不可能で、後任者は前任者が何をどう分析していたかを把握できないまま、同じ分析をゼロから構築することになります。これは単なる工数の問題ではなく、組織としての分析ノウハウが蓄積されないという構造的な問題です。

重要な考え方：分析資産に名前と文脈をつけて一か所に集約する

この問題を解決するために必要なのは、高度なツールの導入ではありません。分析資産に対して、何の分析か、どんなデータを使ったか、どんな前提条件があるかという文脈情報を付与し、誰でも検索・参照できる場所に集約するという運用ルールを作ることです。

分析資産の3層構造を意識する

分析資産は大きく3つの層に分かれます。第1層はデータ抽出のクエリやスクリプトです。第2層はデータの加工・集計ロジックです。第3層は可視化されたダッシュボードやレポートです。この3層をバラバラに管理すると、ダッシュボードは見つかったがその元になるクエリが分からない、という事態が起きます。3層をセットで管理することが再利用の前提条件です。

検索できなければ存在しないのと同じ

分析資産を共有フォルダに置くだけでは不十分です。売上推移、月次、チャネル別といったキーワードで検索して目的の分析資産にたどり着ける状態を作る必要があります。そのためには、分析資産ごとにタイトル、概要、使用テーブル、対象期間、依頼元部門といったメタ情報を記録する仕組みが必要です。この仕組みをナレッジマネジメントツール上に構築します。

完璧を目指さず、まず登録する習慣をつける

分析資産の登録ルールを細かく決めすぎると、登録の手間が増えて誰も登録しなくなります。最初はタイトル、概要の1〜2行、関連するクエリやダッシュボードへのリンクの3項目だけで十分です。運用が定着してから項目を増やしていく方が現実的です。

分析資産を蓄積・検索・再利用する3ステップの運用フロー

ステップ 1：分析クエリとスクリプトをバージョン管理に登録する（GitHub）

分析で使用したSQLクエリ、Pythonスクリプト、データ加工用のコードをGitHubのリポジトリに登録します。リポジトリの構成は、分析テーマごとにフォルダを切るのが最もシンプルです。たとえば sales/monthly-channel-trend/ というフォルダの中に、データ抽出用のSQLファイル、加工用のスクリプト、READMEファイルを格納します。

READMEファイルには、分析の目的、使用したデータソースのテーブル名、対象期間、前提条件や注意事項を記載します。この作業は分析完了後に5〜10分で終わる程度の分量にとどめてください。完璧なドキュメントを書こうとすると登録が止まります。

担当者は分析を完了したタイミングでコミット（変更の記録）を行います。コミットメッセージには、2024年4月度チャネル別売上推移分析のように、後から検索しやすい日本語の説明を入れます。頻度は分析が完了するたびに都度実施します。

ステップ 2：ダッシュボードを共有ワークスペースに公開する（Looker Studio）

分析結果の可視化はLooker Studioで行い、チーム全体がアクセスできる共有ワークスペースに公開します。Looker Studioを使う理由は、Googleアカウントがあれば無料で利用でき、ブラウザ上で閲覧できるため、閲覧者にツールのインストールを求めない点です。

ダッシュボードの命名規則を統一することが重要です。FitGapでは、部門名_分析テーマ_対象期間という形式を推奨します。たとえば、営業_チャネル別売上推移_2024Q1 のようにします。命名規則が統一されていれば、Looker Studioの検索機能でダッシュボードを探せるようになります。

ダッシュボードの説明欄には、対応するGitHubリポジトリのフォルダURLを記載します。これにより、ダッシュボードを見つけた人がその元になるクエリやスクリプトにたどり着けるようになり、第1層から第3層までの分析資産がつながります。

ステップ 3：分析資産カタログを作成し検索可能にする（Notion）

GitHubに登録したクエリとLooker Studioに公開したダッシュボードを、Notionのデータベース機能を使って一覧化します。これが分析資産カタログになります。

Notionのデータベースには、次のプロパティを設定します。分析タイトル（テキスト）、概要（テキスト、1〜2行）、分析カテゴリ（セレクト、売上分析・顧客分析・コスト分析など）、依頼元部門（セレクト）、対象期間（日付）、GitHubリンク（URL）、Looker Studioリンク（URL）、担当者（ピープル）、最終更新日（日付）です。

新しい分析依頼が来たとき、担当者はまずこのNotionのカタログを検索します。分析カテゴリや依頼元部門でフィルタリングし、キーワードで検索して、過去に類似の分析が存在するかを確認します。類似の分析が見つかれば、GitHubからクエリを取得し、Looker Studioのダッシュボードを複製して、差分だけを修正すれば済みます。

この検索と確認のプロセスを、分析着手前の必須ステップとして運用ルールに組み込むことが定着のポイントです。週次のチームミーティングで、新規登録された分析資産を共有する時間を5分設けると、カタログの存在がチーム内に浸透しやすくなります。

この組み合わせが機能する理由

GitHub：クエリとスクリプトの変更履歴が自動的に残る

GitHubの最大の強みは、ファイルの変更履歴が自動的に記録される点です。分析クエリを修正したとき、いつ、誰が、何を変えたかが記録されるため、過去のバージョンに戻すことも、変更の経緯を追うこともできます。これは個人のPCにファイルを保存する運用では絶対に実現できない機能です。

一方で、GitHubはエンジニア向けのツールであり、非エンジニアの分析担当者にとっては操作のハードルがあります。この問題に対しては、GitHub Desktopというデスクトップアプリを使うことで、コマンドライン操作なしにファイルの登録と変更記録ができます。最初の環境構築だけ情報システム部門がサポートすれば、日常の操作は直感的に行えます。また、無料プランでもプライベートリポジトリ（社外に公開されない保管場所）を作成できるため、社内の分析資産を安全に管理できます。

Looker Studio：閲覧のハードルが最も低いダッシュボードツール

Looker StudioはGoogleアカウントさえあれば無料で利用でき、ブラウザ上で動作するため、閲覧者にソフトウェアのインストールを求めません。この閲覧ハードルの低さが、分析資産の再利用率を大きく左右します。高機能なBIツールでダッシュボードを作っても、閲覧にライセンスが必要であれば、結局スクリーンショットをメールで送るという運用に戻ってしまいます。

制約として、Looker Studioはデータの加工機能が限定的です。複雑なデータ変換が必要な場合は、事前にスプレッドシートやデータベース側で加工を済ませてからLooker Studioに接続する設計にしてください。また、ダッシュボードの数が増えてくると、Looker Studio単体の検索機能では目的のダッシュボードを見つけにくくなります。だからこそ、ステップ3のNotionカタログが必要になります。

Notion：非エンジニアでも使えるデータベース機能が分析資産カタログに最適

Notionのデータベース機能は、フィルタリング、ソート、キーワード検索を備えており、分析資産カタログとして必要な機能が揃っています。エンジニアでなくても直感的に操作でき、プロパティの追加や変更も管理画面から簡単に行えます。

Notionの弱点は、GitHubやLooker Studioとの自動連携機能が標準では用意されていない点です。分析資産をGitHubに登録したら、Notionのカタログにも手動で1行追加するという運用が必要になります。この手動登録の手間を許容できるかどうかが、運用定着の分かれ目です。FitGapでは、登録項目を最小限に絞り、1件あたり2〜3分で登録できる設計にすることを推奨します。自動連携が必要な場合はZapierなどの連携ツールを追加で導入する選択肢もありますが、まずは手動運用で定着させてから検討する方が確実です。

Recommended tool list

結論：分析資産に文脈をつけて一か所に集約すれば同じ分析の繰り返しはなくなる

分析資産の再利用が進まない原因は、ツールの不足ではなく、分析資産が個人に閉じていて検索できない状態にあることです。GitHubでクエリとスクリプトを管理し、Looker Studioでダッシュボードを共有し、Notionで分析資産カタログを作る。この3つの仕組みを組み合わせることで、新しい分析依頼が来たときにまず過去の資産を検索し、再利用できるものは再利用するという運用が実現します。

最初の一歩として、直近1か月で実施した分析を3件だけNotionのデータベースに登録し、チームメンバーに共有してください。完璧なカタログを目指す必要はありません。3件の登録から始めて、分析のたびに1件ずつ追加していけば、3か月後には実用的な分析資産カタログが出来上がります。

Mentioned apps: Notion, GitHub, Looker Studio

Related categories: BIツール, IDE（統合開発環境）, ナレッジマネジメントツール

Related stack guides: 監査時にガイドライン対応の証跡をすぐ提出できる体制を4つのツールで構築する方法, 業界標準の改定内容を自社システムへ漏れなく反映し監査不適合を防ぐ方法, パートナーとのトラブル発生時に証跡を即座に集約し原因究明と再発防止を加速する方法, 育児・介護休業の案内から申請・社会保険手続きまでを仕組み化し人事担当者の個別対応と手続きミスをなくす方法, 危機発生時にブランド方針と広報対応のズレをなくし初動遅れと二次炎上を防ぐ方法