【ITニュース解説】The total was right, but a branch went missing: what happens when you merge twelve spreadsheets

システムエンジニアを目指す初心者にとって、ITシステムにおけるデータ処理の自動化は非常に重要なテーマである。日々の業務を効率化し、人為的ミスを減らすために自動化は不可欠だが、その過程には予期せぬ落とし穴が存在する。今回は、複数のデータファイルを結合して一つのレポートを作成する自動化プロセスで発生した具体的な問題とその解決策について解説する。

ある企業では毎月末、12の支店から送られてくる売上データを一つにまとめ、本社への報告書を作成する業務があった。この作業は毎月繰り返され、特定のルールに従って行われるため、手作業では単調でミスも起こりやすいことから、自動化に非常に適していると判断された。自動化の初期段階では、各支店から送られてくるCSVファイルなどを順に開き、それぞれのファイルのヘッダー行（列のタイトル行）をスキップして、残りの売上データを単純に連結していく方法が採用された。これは、手作業でコピー＆ペーストするのと同じように、データの「位置」だけを見て結合するシンプルな方法である。

このシンプルな自動化スクリプトが完成した後、作業者は結合されたレポートの売上合計が、各支店の合計売上と一致するかどうかを確認した。合計値が一致すれば、データが正しく取り込まれたものと判断し、作業完了とする運用であった。しかし、ここに大きな落とし穴が潜んでいた。

問題の原因は、12ある支店のうち「Branch 07」だけが、他の11支店とは異なるデータの列順序でファイルを作成していたことにあった。具体的には、他の支店が「日付、支店、担当者、売上」という順序でデータを並べていたのに対し、Branch 07だけが「日付、担当者、支店、売上」という順序で並べていたのだ。これは、支店の担当者がスプレッドシート上で誤って列をドラッグして並び替えてしまったような、ごくありふれた状況で起こりうるミスである。

列の位置に基づいてデータを結合する自動化プロセスでは、このような列順序の違いが深刻な問題を引き起こす。Branch 07のデータは、日付に続き、本来「担当者」であるはずの名前が「支店」の列に取り込まれ、本来「支店」であるはずの「Branch 07」という文字列が「担当者」の列に取り込まれてしまった。しかし、重要な点として、「売上」の列はどのファイルでも4番目の位置にあり、結果として正しく売上データが4番目の列に格納された。そのため、結合されたレポートの売上合計は、元の各支店の売上合計と完全に一致してしまったのだ。

この状況では、売上合計が一致しているため、作業者はデータ結合が成功したと信じてしまう。また、全体の行数も元のファイルにある行数の合計と一致しており、一見すると何の異常もないように見える。しかし、内部ではデータが大きく間違って紐付けられていた。この結合されたデータをもとに支店ごとのレポートを作成すると、「Branch 07」の売上がゼロとして報告され、代わりに「Gray」という名前の支店（これはBranch 07の担当者名が誤って支店名として認識されたものである）の売上が計上されるという、実在しない支店からの売上が発生するという異常な事態が判明したのである。

この経験から得られる教訓は、単に合計値や行数が一致するだけでは、データが正しく結合されたことを証明できないということである。二つの異なる間違いが互いに打ち消し合って、合計値が偶然一致してしまう可能性もあれば、各行が意図しない場所に格納されている可能性もある。

より信頼性の高いデータ結合プロセスを構築するためには、いくつかの改善策が必要となる。まず、データ結合の段階で「列の位置」ではなく「列の名前（ヘッダー）」に基づいてデータを処理することが重要である。これにより、たとえ列の順序が異なっていても、正しい列に正しいデータが格納される。また、予期しない列名が見つかった場合には、そのまま結合を続けるのではなく、処理を停止してエラーを通知する仕組みを導入することが望ましい。これにより、データの不整合が下流の工程に影響を与える前に問題を早期に発見できる。

さらに重要なのは、結合後のデータの検証方法である。データ結合に使用した方法とは「異なる検証方法」を用いることが不可欠である。同じ方法で検証しても、同じ種類のミスは見過ごされる可能性があるためだ。例えば、各支店ファイルから「日付、支店、売上」といった複数のキー項目を組み合わせた一意の識別子を作成し、結合後のファイルに含まれる行とこの識別子を用いて厳密に照合する方法が考えられる。この「行単位の比較」を行うことで、たとえ合計値が一致していたとしても、どの行が欠落しているか、あるいはどの行が意図せず追加されているかを正確に特定し、データ結合の成功・失敗を明確に判断できる。この方法であれば、今回のケースのように売上合計が一致していても、不正確な行データがある場合にエラーとして検出され、問題を修正する機会が与えられるだろう。

一般的なオフィスツールであるExcelのPower Query機能においても、この考え方は適用できる。Power Queryの「クエリの追加（Append queries）」コマンドは、基本的に列名に基づいてテーブルを結合する。これは「列名で結合する」というアプローチに近い。しかし、もし異なる列名が存在した場合、Power Queryはエラーで停止するのではなく、新しい列を追加し、該当するデータがないセルには空白（null）を入れる動作をする。そのため、Power Queryを使用する場合でも、結合を行う前にすべてのソースファイルの列名を事前に確認し、必要であれば統一しておくことが重要である。結合後も、支店ごとの合計を元のソースの合計と並べて比較するなどの追加チェックを行うことで、より安全なデータ処理が可能になる。

これらの経験から導き出される最終的な教訓は、自動化システムを設計するシステムエンジニアは、単に機能が動作することを確認するだけでなく、データが意図した通りに、そして期待される通りに処理されているかを多角的に検証する仕組みを組み込む必要があるということだ。特に、異なるソースから来るデータを扱う際には、データの形式や構造が常に一定であるとは限らないという前提に立ち、予期せぬ不整合にも耐えうる堅牢なシステムを構築する視点が求められる。合計値や行数の単純な確認だけでは、データの正確性を保証するには不十分であり、行単位での厳密な検証と、異なるアプローチでのチェックが、信頼できる自動化を実現するための鍵となるのである。