手入力で止まっていた大会ポイント付与を自動化し、遡り32大会分をまとめて復旧した事例｜業務自動化

「止まってしまった制度」を動かし直した話

全国規模で大会を運営されている競技団体のお客様から、大会結果にもとづくポイント付与を仕組み化したいというご依頼をいただきました。

この記事は「毎回の集計作業が属人的で、担当者の手が空かないと業務が止まってしまう」という状況に心当たりのある方に読んでいただきたい内容です。

クライアント概要

• 業種: 全国規模の競技団体（会員制）
• 規模感: 年間約35大会、1大会あたり最大100名
• 依頼: 大会結果からのポイント算出・付与とCSV生成、および未処理分の遡り対応

課題・依頼背景（Before）

ポイントの算出は、大会ごとの結果表を見ながら手入力で行われていました。1大会あたり最大100名、年間約35大会という量に対して、集計作業ができる担当者は限られています。

その結果、着手時点で次の状態になっていました。

• 大会の結果報告はすでに届いているのに、ポイントが1件も付与されていない
• 未処理のまま溜まった過去分が32大会分あり、手作業では現実的に追いつかない
• 集計が止まると、会員側から見える順位や記録の更新も止まる

つまり問題は「作業が遅い」ことではなく、制度そのものが動いていないことでした。人を増やして手入力を続けても、翌年も同じ状態に戻ります。

実データを確認すると、単純な計算の繰り返しでは済まないことも分かりました。

• 大会区分ごとに参照する基礎点表が異なる
• 年齢区分にもとづく加点があり、区分の定義に例外がある
• 棄権・不参加の行をどう数えるかで結果が変わる
• 同順位の表記ゆれ、全角と半角の混在、様式のバージョン違いが同居している
• 1つのファイルに複数大会分が入っている場合がある

提案・解決アプローチ

まず、数量を先方の申告ではなく実データで確定させるところから始めました。お聞きしていた大会数と、実際に共有いただいたフォルダを全件解析した結果には差があり、掲載の単位で数え直すと想定と異なる件数になったためです。見積の根拠が実物とずれたまま進むと、あとから追加費用の話になります。

実装方針としては、日常の運用に載せやすいスプレッドシート上のスクリプトへ移植する案も検討しました。しかし、ポイント計算では小数の丸め方が結果を左右します。移植すると丸めの扱いが変わり、仕様の再確認が発生するため見送りました。

計算ルールをプログラムに直接書き込む案も見送っています。区分や基礎点は今後変わりうるもので、そのたびに開発者を呼ばないと直せない状態は、手離れとしては後退だからです。

実装内容

• 大会結果ファイル（Excel形式）を読み取るパーサの構築（様式バージョンの違い・表記ゆれを吸収）
• ポイント計算ルールの設定ファイル化（大会区分ごとの基礎点表、年齢区分の加点、例外の扱いを外部定義）
• 会員情報との突合処理
• 掲載用CSVの出力（既存の管理画面にそのまま取り込める列構成に合わせる）
• 未処理だった遡り分の一括処理

計算処理には、小数の丸めを正確に扱える方式を採用しています。金額や順位に関わる計算では、わずかな丸めの差が最終結果を変えるためです。

成果

品質の担保には自動テストを使い、最終的に187件のテストがすべて通る状態にしています。

検証では、お客様側が実際に管理画面へ取り込んだデータと、こちらが生成したCSVを1行ずつ突き合わせました。ある大会で39行17列がすべて一致しています。表計算上で「だいたい合っている」ではなく、実際に投入されたものと完全に一致することを確認しました。

掲載の単位となる16件すべてでCSVを生成し、成果物の検査でも問題は出ていません。手作業では追いつかなかった遡り分を含め、止まっていたポイント付与を再開できる状態になりました。

本プロジェクトで大切にしたスタンス

ポイント1：数量を先方の申告ではなく実データで数え直した理由

当初お聞きしていた大会数と、共有いただいた実データを全件解析した結果には差がありました。ファイル1つに複数大会が入っているもの、そもそもポイント対象外の大会などが含まれていたためです。

申告値のまま見積を作れば、着手後に「思っていたより量が多い」という話になります。手間はかかりますが、着手前に実物を全件開いて数え直し、掲載の単位で数量を確定させてから金額を提示しました。

ポイント2：計算ルールを設定ファイルへ切り出した理由

プログラムに直接書き込むほうが実装は早く済みます。それでも外部の設定ファイルに切り出したのは、区分や基礎点が今後変わるものだからです。

ルールが変わるたびに開発者へ依頼が必要な状態は、自動化したように見えて依存先が変わっただけになります。設定ファイルであれば、変更内容を人が読んで確認できます。

ポイント3：小数の丸めのために移植を見送った理由

運用のしやすさだけを見れば、日常業務で使われているスプレッドシート上に載せる選択もありました。しかし、ポイントは順位や記録に直結します。丸めの扱いが変わって過去の付与結果と食い違えば、制度への信頼そのものに関わります。

「使いやすさ」より「計算結果が変わらないこと」を優先し、丸めを正確に扱える方式を維持しました。

本事例の総括とポイント

• 課題は作業の遅さではなく、結果報告が届いているのにポイント付与が止まっていたこと
• 見積の前に実データを全件解析し、掲載の単位で数量を確定させた
• 計算ルールは設定ファイルへ外部化し、ルール変更に開発を要さない形にした
• 小数の丸めを正確に扱うため、スプレッドシートへの移植は見送った
• 自動テスト187件で品質を担保し、実際に投入されたデータと39行17列の完全一致を確認した
• 掲載単位16件すべてでCSVを生成し、遡り分を含めて再開できる状態にした

こんな方はご相談ください

毎回の集計や転記が属人的になっていて、担当者の手が空かないと業務が止まってしまう方は、無料相談からご相談ください。

• 業務自動化サービス: 手作業の集計・転記を、ルール変更に耐える仕組みに置き換えるところからご相談いただけます → /services/automation/