今年もアジアリーグアイスホッケーが開始しました。今期はスターズ神戸という関西のチームが参加し、さらに盛り上がると思います。
以前EY-Officeの開発(1) アジアリーグアイスホッケーブログに書いたようにアジアリーグアイスホッケーの集計システムはEY-Officeで作成し、現在もメンテナンスしています。
Gemini 2.5 Flash Imageが生成した画像をもとにしています
今年もトラブルが・・・
アジアリーグアイスホッケーのシステムはクラウドで動いているのでハードウェアのトラブルは今のところ起きていません。ソフトウェアも20年近い実績があり、バグもほぼありません。
今回もそうですが、新たに参加した担当者が勘違いしてスコアーを記述している事がほとんどです。
スコアーの入力は会場でExcelを使い入力しています。そのスコアー入力用のExcelシートはお見せできませんが、OFFICIAL GAME SHEETとほぼ同じように作られています。スコアーは以下の画像の、オレンジ色の部分が試合会場で入力する部分で、青色の部分はシステムが集計した結果です。
ただし、
トラブル(1)
トラブルの報告は下の画像のように、「GoalKeeper RecordsのBチームのゴールキーパーNo.55の選手の時に1点入ったので1を入力したのですが、OFFICIAL GAME SHEETには0が表示されます」でした。
入力用のExcelシートは基本的に集計部分（スコアー画像の青色の部分）も会場で入力しています。そうしないと会場で試合の状況は把握できないからです。ただし、システムは集計部分（スコアー画像の青色の部分）の入力データは無視して集計結果でGoalKeeper Recordsを埋めます。
さて、ゲームシートにはたくさんの情報があるので、報告があっても直ぐには判らない事が多いです。しかもシステムを作ったのは20年前です。😅 という事で仕様書やソースコードを見ながら原因を考えます。開発環境はDockerで直ぐに起動できるので、デバッグ・プリントを入れて試したりする事でを原因を追求しました。
その結果、下の画像のようにゴールに記録でキーパーのNo.が間違っている事が判りました。
トラブル(2)
次にあったトラブルは「ゴールキーパーの成績：GK SPで、No.55の選手の被Goal数が、本来3のはずが5になっています」でした。
集計処理の問題です、また開発環境のDockerにデバッグ・プリントを入れて調査しながら、再度ゲームシートを見てみたところ問題点を発見しました。
ゴールの記録には、ゴール時にスケートリンクにいた選手の背番号が記録されています。P1〜P6は攻撃チーム、N1〜N6は防御チームの選手です。アイスホッケーは通常は1チーム6人（ベンチには最大23人まで入ります）がスケートリンクにいるのですが、反則等で5人になっている場合があります。このゴールではNは5人しかいなかったので、苦し紛れにNo.55を2ヶ所に記入したと思われます。本来はN6は-です。
このような記入があると集計ソフトはキーパーのNo.55が2ヶ所あったので2回集計してしまったようです、現在のコードはこのようなケースに対応していませんでした。N6を-にして再登録・再集計したところ直りました。
まとめ
トラブル(1)は担当者が小さな入力ミスに気がつかず、さらにシステムの原理を知らなかった事が原因です。
トラブル(2)は担当者がスケートリンクに5人だった場合の正しい入力方法を知らずにキーパーを2回入力するという工夫をした事が、集計ソフトウェアの考慮不足点を突き不思議な結果を生み出してしまいました。
長い間使われているシステムでも、間違ったデータに対して全て上手く対応できるわけではありません。 現場ではドキュメントや継承されたノウハウで上手く運用されているという事を痛感しました。
