総務や生産管理をしていると、いろいろな部署から「このデータ集計してもらえますか」という依頼が飛んできますよね。Excelが得意というだけで、毎回似たような関数を組み直す仕事が自分に集中していませんか。
私自身、売上や製造実績といった基本的なデータの定点観測ができていない会社で、まさにこのスポット的な集計依頼を数多く引き受けてきました。元々Excelが得意だったことと、社内にIT弱者が多かったことが重なって、気づけば「データ集計の人」になっていたのです。
この記事では、そのExcel関数の手組みから、基幹システムから直接データを取得する仕組みに発想を変えた経緯と、非エンジニアでも踏める選択肢(パワークエリ・Access)から一歩進んだ選択肢(自作API)までを紹介します。読み終える頃には、自分の会社・自分のスキルでどこから手をつければいいかが見えてくるはずです。
各部署からの集計依頼に振り回されていた頃の課題
私がいた会社は、売上や製造実績のような基本的なデータでさえ、定点観測の仕組みがありませんでした。必要になったときにスポットで集計する、というやり方が当たり前になっていたのです。
毎回似たようなExcel関数を組み直す非効率
さまざまな部署からデータ集計の依頼が来るのですが、よく見ると条件が微妙に違うだけで、元データも集計の考え方もほとんど同じということが多々ありました。それでも毎回ゼロから似たようなExcel関数を組んでいたのです。
正直、「これ、前にも似たものを作ったな」と思いながら手を動かすことが増えていました。1件1件は大した作業量ではなくても、積み重なると地味に時間を食う仕事だったんですよね。
共通する集計条件があるのに、毎回ゼロから作っていた
依頼元の部署が違えば見た目の要望は違いますが、元を辿れば基幹システムの同じデータから抽出しているだけ、というケースがほとんどでした。だったら「取得の仕組み」自体を一度作ってしまえば、毎回のExcel関数の組み直しは不要になるはずだと考えるようになりました。
Excel関数からSQLでの直接取得へ発想を変えた理由
さまざまな部署からの依頼で共通している部分や、毎回似たようなExcel関数を組んでいる状況を振り返ったとき、SQLで基幹システムから直接取得したほうが再現性が高いと判断しました。
再現性の高さという判断軸
Excel関数は、その場その場の集計には強い一方で、依頼内容が少し変わるたびに作り直しが発生します。これに対してSQLで元データから直接取得する仕組みにしておけば、条件を変えるだけで同じ土台を繰り返し使えます。「毎回作る」から「一度作って使い回す」への発想転換が、一番大きなポイントだったと思います。
自分のスキルレベルに応じた選択肢(パワークエリ／Access)
ここで大事なのは、SQLでの直接取得=高度なプログラミングが必須、というわけではない点です。データ分析やデータ集計を担当している方、Excelで売上表やコスト表を作っている方であれば、まずはExcelのパワークエリやAccessで同じ考え方を試せます。
パワークエリなら、Excelの延長線上でデータの取得・結合・変換を自動化でき、Accessならテーブル設計とクエリの組み合わせで、複数部署の似たような集計依頼に対応する基盤を作れます。社内SE的なプログラミング環境(PlayframeworkのようなWebアプリ開発)を使う必要は、最初からはありません。
実際の選択肢を比較する（パワークエリ・Access・自作API）
パワークエリ・Accessでできる範囲（非エンジニア向け）
パワークエリ・Accessは、Excel関数の手組みに限界を感じている非エンジニアがまず試すべき選択肢です。データの取得元を一箇所にまとめ、集計ロジックを「毎回作る」ものから「保存して再利用する」ものに変えられます。プログラミング経験がなくても、Excelの操作感の延長で扱える点が最大の利点です。
自作APIまで踏み込んだ場合（Playframework＋Doobie、上級編）
私の場合は、PlayframeworkとDoobieを使って、基幹システムからデータをJSONで取得するAPIサーバーを新設しました。フロント側は、取得したJSON項目をAIに読み込ませると、表示レイアウトをすぐに作成してくれるという組み方です。
ただし、これは企業の情シス・社内SEにとっても技術レベルが高い選択肢です。社内にWebアプリ開発ができる人材がいない場合、いきなりここを目指す必要はありません。まずはパワークエリやAccessで仕組み化の感覚を掴んでから、「もっと柔軟にしたい」と感じたタイミングで検討する発展形として捉えるのが現実的だと思います。
仕組み化した結果どうなったか
データ集計の仕組みを一度作ってしまえば、以降は定点観測が容易になります。依頼が来るたびにゼロから組んでいた状態から、同じ仕組みに条件を当てはめるだけで済む状態に変わったのは、実務上とても大きな違いでした。
DB接続情報の一元化によるセキュリティ面の効果
もう一つの効果は、基幹システムへのDB接続情報を一元化できたことです。各部署・各担当者がそれぞれ接続情報を持って個別にアクセスする状態ではなく、仕組み側で管理をまとめられるので、セキュリティの面でも安全性が高まりました。
社内データ管理の仕組み化は誰に向いているか
ここまでの話を踏まえて、向き不向きを整理すると次のようになります。
- 向いている: 複数部署から似たような集計依頼が繰り返し来ている
- 向いている: 元データは同じ基幹システム・同じExcel台帳なのに、毎回作り直している自覚がある
- 向いていない: 集計依頼がそもそも少なく、仕組み化のコストに見合わない
- 向いていない: 依頼内容が毎回まったく異なり、共通する集計条件がほとんどない
向いているケースに当てはまるなら、いきなり自作APIを目指す必要はありません。まずはパワークエリかAccessで、よく来る依頼パターンを1つだけ仕組み化してみることから始めるのがおすすめです。たとえば「毎月必ず依頼される売上集計」のように頻度の高いものを1つ選び、パワークエリで同じ処理を再現してみると、仕組み化の感覚がつかみやすくなります。
まとめ
データ集計の属人化は、「毎回作る」から「一度作って使い回す」への発想転換で解消できます。技術レベルに応じて、パワークエリ・Access・SQL直接取得(自作API)と段階的に選択肢があるので、自分のスキルに合わないところから無理に始める必要はありません。
まずは今来ている集計依頼を振り返り、「これ、前も似たものを作ったな」と感じるパターンがあるかどうかを確認してみてください。それが仕組み化の第一歩になるはずです。
関連記事・次の一歩
「仕組み化の先にある可視化・ダッシュボードまでやりたくなった」という方は、データ分析のBIツールを自作に置き換えたら年間80万円削減できた話もあわせて読んでみてください。
「自分でもWebアプリを作れるようになりたい」と思った方は、非エンジニアが業務改善ツールを自作できるようになった理由｜技術より先に決めたことも参考になります。Excelのバージョン管理や台帳管理に悩んでいる場合は、台帳管理を効率化する方法｜Excelの限界を超える3つのアプローチ【総務担当向け】も読んでみてください。