#はじめに
自分の業務の中で、月次データの集計作業（突合・照合）を行なっております。
その中で、工夫している点や改善点について振り返ってみました。
個人的な振り返りになりますが、参考にしていただいたり、同じ悩みを持っている人に共感していただけると嬉しいです。
#突合・照合について
こちらのサイトによると、比較方法によって意味の違いがあるみたいです。
「突合」というのは、「正しいデータ(大元のデータ・原本)などと手元のデータを突き合わせて、数字や内容に間違いがないかを確認すること」を意味しています。
それに対して、「照合」という言葉は「二つ以上の数字・データを照らし合わせて有無を調べること」の意味合いを持っています。
ざっくり言うと、
-
（正しいとされる,運用等で正しいと決めた）大元のデータと比較する作業を突合
-
大元のデータが存在しない、お互いの持ってるデータ同士を比較する作業を照合
という位置付けです。
自分の場合では、以下のデータ集計（突合・照合）作業を行なっています。
- 入金データの突合：大元の入金データと、DBで管理している入金データが一致しているか
- データ更新結果の照合：システム同士でデータ連携を行なっているケースで、データ更新結果のレコード数を比較して差分の有無を確認する
集計作業について
集計作業の流れについて一例を紹介します。
1. 突合用の入金（大元となる正の）データを、担当者から受け取る
↓
2. 集計対象のデータを抽出する（SQLで抽出、バッチ処理によるデータインポート）
↓
3. 突合用のデータと、抽出結果を比較する
↓
4. 比較して問題ないかデータに問題ないか確認する。差分があった場合は別途調査
上記の集計作業について、前任の担当者から引き継いでから4回ほど実施しています。やってみると結構手間であると感じており、集計作業について工夫や改善することも一つの業務成果に繋がるので振り返りを実施しています。
#集計作業の工夫点
集計作業で、工夫している点について以下に紹介します。
1. 焦らない
2. リハーサルの実施
3. 分析する
4. 数値設定をする
1. 焦らない
焦りは１番の大敵です。平常心で集計作業に臨みましょう。
例えば、「集計用のクエリを実行してみたら応答結果が帰ってこない」という状態になり、
焦ってムダな調査や正確性の欠いた集計作業（ 人員作業によるミスの原因に繋がります）
を行ってしまうと、大きな手戻りにつながります。
そのため、焦りを生まないため以下の工夫をしてます。
- 応答を常に確認できるように集計時の進捗状況を表示する。
- 複雑なクエリは実行しない（ざっくりとしたクエリから徐々に絞り込みを行うイメージ）。
イメージとしては以下になります。
STEP1:
「購入確定」されたアイテムの集計開始。
1000/1000 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
「購入確定」されたアイテムの集計終了。
STEP2:
「購入確定」されたアイテムの「キャンセル」分のチェック開始。
1000/1000 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
「購入確定」されたアイテムの「キャンセル」分のチェック終了。
集計ツールがPHPのLaravelフレームワークを使用していて、「プログレスバー」で画面上に常に応答を返しています。これを実装しておくと進捗状況が確認できます。（また、プログレスバーの進む速度で「いつ頃終わりそう」などの目処もつきます）
また、複雑なクエリ（ex. 1つのクエリで購入確定されたアイテムから、キャンセル分を除いて集計する）は極力避けてます。
クエリ自体が複雑化するほど、「保守性が落ちる」、「データ件数の違いで、開発環境では動作できてたけど本番環境で動かない」というリスクがあるからです。
自分の場合では、上記の「STEP1」->「STEP2」の感じで、必要な情報をざっくり取ってきてから、徐々に絞り混みを行っています。
2. リハーサルの実施
集計作業は、実施時期が決まっているパターンが多いです。
ex.「月次データの集計作業は営業日3日以内で実施完了する（7/1〜7/31の月次データを、8/3までに集計する）
もし集計データに不備が見つかれば、
「3日以内で実施完了する」という要件が満たせなくなるので、
事前にリハーサル作業を実施しています。
ex. 毎月の25日ごろに「7/1〜7/25分のデータを集計する」
あらかじめリハーサルをしておくことで、差分がでた箇所について把握できるので、本番集計時の作業効率化に繋がります。
主観になりますが集計作業におけるリハーサルで心がけたことをまとめます。
- 集計内容について、事前にすり合わせを実施
- 集計内容に対して、+αの情報も出す
それぞれ解説します。
説明では、「ex.特定期間内（2020/7/1から2020/7/31）に売れた商品のデータを集計したい」と
依頼された場合を想定します。
集計内容について、事前にすり合わせを実施
集計単位「商品ID単位（主キー）」、「購入したユーザ単位でまとめるか（Group化）」は確認しておきます。
集計単位を揃えないと、数値のズレを生んでしまったり、後になって集計不可という自体を避けるためです。
上記図は打ち合わせ時の抜粋になります。打ち合わせ相手（相手がエンジニアだったらER図でもいいかもです。）と認識揃えるため、用意してます。
「商品ID単位でしたら8件、ユーザIDでまとめたら2人が集計対象です」みたいな感じで話してみると認識が揃いやすくなります。
集計内容に対して、+αの情報も出す
前述の打ち合わせで、「商品ID単位で集計しましょう」と合意できても、実際にやってみると「差分で想定と違う商品IDが出てくる」ということも考えられます。
そこで、+αの情報（このときは、状態変化が起きたタイミングや、次の状態遷移）なども比較用に用意しておきます。
| 商品ID | 状態変化 |
|---|---|
| 001 | 商品購入：2020-07-01 購入キャンセル：2020-07-02 ←キャンセルされたのに集計されている |
| 002 | 商品購入：2020-07-04 購入キャンセル：2020-07-05 商品購入：2020-07-06 ←再購入された商品がのっていない |
| 003 | 商品購入：2020-08-01 ←集計期間外の商品IDが出現 |
3. 分析する
実際に、集計作業をして差分が出たときに、「何故、差分になったのか？」と分析するようにします。
自分の場合は、以下の傾向でした。このあたりを分析することで、集計作業の改善点にも繋がります。
-
データの連携ミス
- **原因：**データの取得や連携が失敗していた場合。
- **対応：**あとで再連携（リカバリ）作業で対応します。
-
イレギュラー処理
- **原因：**通常と異なる処理（ユーザーからの問い合わせで個別で対応した場合など）があった場合、差分が出てしまうケースに発展します。
- **対応：**イレギュラー処理の記録（運用部門が記録してるファイル）を参照して、差分を埋めるようにしています。
-
人員作業によるミス
- **原因：**手動作業による入力ミス（
ex. SQLの範囲指定で7/1〜7/31ではなく、6/1〜6/30を指定した） - **対応：**ミスしたところを再入力します。また、手動入力を極力減らせるように自動化を目指す（改善点に記載）のも重要と考えてます。
- **原因：**手動作業による入力ミス（
4. 数値設定する
データ更新結果の照合（照合なので、大元の正となるデータがない）を実施する際に、
向こうのシステム担当者の方と、差分件数に対してあらかじめ誤差について取り決めてました。
許容誤差：差分件数が全体の1%未満
許容誤差に関しては、「データ更新の時刻を同期してないので、数秒のラグによる更新タイミングのズレが生じる」
というのが分かってので数値的に1%と取り決めました。
前述のリハ作業時に、許容誤差を超えた時は、「何かおかしいのではないか？」と考え、
お互いに原因調査を実施して、集計方法の改善を実施しました。
最終的には、許容範囲内の誤差（1%未満で、マージ可の差分）内に収まる範囲で照合できました。
#改善点
集計作業をやってみて、「こういうところは、改善したい」と思っている箇所について列挙してます。
1. 手動入力を減らす、自動入力を増やす
現行の集計処理では、手動入力している箇所が存在するので、なるべく自動入力できる処理を増やしたいと考えてます。手動入力が多いとミスも発生しやすいので、集計作業の正確性を向上させるためにも必要な改善点だと感じています。
2. 業務フローを見直す
「集計作業について」でも述べてますが、データ集計から確認までの4工程を行なっています。
この4工程ですが、手動入力の件も含めて誰でも（ex.バッチ処理やSQLに馴染みがない担当者など）実行できる用意するのも一案だと思います。環境が構築できれば、作業者の分担も可能になり効率化に繋がると考えています。
仕組みづくりはこれからになりますが、以下の取り組みをしたいと思います。
ex. バッチ処理の簡略化や、API連携でデータ連携を簡易化する
#おわりに
ざっくりですが、集計作業について振り返ってみました。振り返ってみると自分の中で改善点が見えてきました。改善できた成果については、別の機会で紹介できればと思います。
長文になりましたが、最後までお読みいただきありがとうございました。