2026.08.26開発

大会の速報ページを作るなら、紙のプログラムを先に見たほうがいい

はじめに

スポレックという競技の大会「ODD Fes 2026」で、試合結果の速報ページを作りました。

それまで本部では、審判が紙のスコアカードに書いた結果を、担当者がExcelに打ち直していました。その工程を減らしつつ、選手と観客が自分のスマホで順位を追えるようにするのが目的でした。

結果としては動きました。ただ、開催4日前になってから作り直しが続き、当日も表示が壊れる場面がありました。振り返ると、原因のほとんどは同じところに帰着します。

APIの形が決まる前に、入力側と表示側を同時に作り始めたことです。

今回はその記録です。

構成はこうです。

審判が紙のスコアカードに記入
        ↓
本部の入力担当がGASの画面で登録   ← status = 承認待ち
        ↓
本部の承認担当が紙と照合
        ↓
承認済みだけがリーグ表に自動集計
        ↓
速報ページが60秒ごとに取得して表示

入力・承認・集計はGoogle Apps Scriptとスプレッドシート。表示側は静的HTMLで、GASのJSON APIを叩くだけの読み取り専用です。

承認を挟んだのは、紙が正であることを崩したくなかったからです。入力ミスがそのまま順位表に出ると、本部が紙を見て直す羽目になり、かえって手間が増えます。承認済みのデータだけを集計対象にすることで、紙との照合が終わったものだけが表に出るようにしました。

表示側に書き込みを一切持たせなかったのも同じ理由です。本部の外から順位が変わる経路を作らないことを優先しました。

問題は開催4日前から始まりました。

トーナメントのデータ構造が「試合の平坦な配列」から「ラウンドの配列」に変わり、表示側の判定が全部空振りして、ブラケットが空になりました。

翌日には試合番号や審判担当などのフィールドが増え、星取表と試合順を作り直しました。同じ日に、コートリーダーを表す値が文字列からオブジェクトに変わり、そのままだと画面に[object Object]と出る状態になりました。

どれも「動いていたものが壊れる」変更です。

原因ははっきりしていて、レスポンスの形を先に決めないまま両側を書き始めたからです。入力側を触るたびに表示側が壊れ、当日が近づくほど直す時間が無くなっていきました。

大会が終わったあと、実際のレスポンスからAPI仕様を起こしてリポジトリに置きました。本来これは最初に書くものです。

いちばん効いた失敗はこれでした。

設計書を書いた時点で、自分は紙のプログラムの現物を見ていませんでした。その結果、審判担当が設計から完全に抜けていました。

参加者にとって「自分がいつ審判か」は「自分がいつ試合か」と同じくらい重要な情報です。見落とすと試合が始まりません。それが入っていなかった。

試合番号による星取表と試合順の相互参照、コートリーダー、開始時刻も同じで、すべて後から足しています。

紙に載っている情報は、そのまま参加者が必要としている情報でした。現場で長く使われている紙は、それ自体がよくできた仕様書だったということです。

さらに、仕様と実データが食い違っている箇所もありました。予選の通過数がデータ上はどのグループも2組なのに、実際は3位から4組が本戦に上がっていた。表示側はデータを信じていたので、本戦に出ている4組が予選表で落選扱いになっていました。

いまは通過判定を、宣言された数ではなくトーナメント表に在籍しているかどうかで見るようにしています。

全部門148試合を毎回まとめて返す作りだったので、スプレッドシートの読み取りに時間がかかり、取得に失敗することがありました。同時アクセスが増える当日はなおさらです。

まずかったのは失敗したときの挙動でした。更新に失敗すると、表示中の順位表が消えてエラー画面に差し替わっていた。

読んでいる最中に画面が壊れたように見えます。本来なら、取れなかったのは新しいデータであって、いま出ている順位表が間違いになったわけではありません。

いまは、リトライを入れたうえで、失敗しても表示はそのまま維持し、最終更新の時刻に注記を添えるだけにしました。

速報ページは毎回GASから取得するだけで、結果を自前で持っていませんでした。

つまり、次の大会のためにスプレッドシートを初期化した瞬間、 2026年の結果はサイトから消える構造でした。大会の記録としては致命的です。

いまは結果をJSONとして保存し、参照先を切り替えられるようにしています。大会期間中はAPIから、終わったら保存済みのファイルから読む。

動くものはできましたが、直前と当日に慌てた部分は、ほとんど事前に潰せたものでした。

次にやるなら、順番を変えます。

特に1つ目です。

デジタル側だけで設計を進めると、現場で当たり前に共有されている情報が丸ごと抜けます。今回でいえば審判担当がそうでした。紙を見ていれば1分で気づけたはずです。

長く使われている紙の様式は、それ自体が要件定義なのだと思いました。