弓道の交流射会のデジタル化

出発点は、記録係の負担と結果を確認するまでの待ち時間でした。Excelでは12人分の入力が1人に集中し、「立ち」が終わるたびに印刷して掲示していました。立ちは、一緒に行射する組のことです。参加者も結果の掲示を待つ必要があり、自分の出番を把握しづらい状態でした。

その後も、交流のきっかけづくり、予定の確認、受付情報の共有に課題が残っていました。紙の受付リストで把握した欠席情報は記録係・招集係へ伝わらず、事前に想定した時刻の通知も実際の進行とずれていました。

運営を少しでもラクにし、参加者が出番や進行を確認しやすくすることを目指しました。記録係として見つけた問題を起点に、交流支援と受付・招集まで改善の対象を広げました。私は仕組みの設計と実装に加え、関係者への導入と当日の運用も担当しました。

有志による運営のため、システムの利用料を0円にする必要がありました。開発は本業外の限られた時間で行い、開催日までに使える状態にすることが前提でした。第5回では受付・招集の改善までは手が回らず、次の第6回へ持ち越しています。

もう一つ守ったのは、第3回で確定した記録係の入力方法です。アプリを追加しても入力フローは変えず、既存の運営を支える補助として使えるようにしました。

最初に選んだのは、複数人で同時編集でき、オンラインで閲覧できるGoogleスプレッドシートです。前射場・後射場で入力を分担することで、1人に集中していた作業を分けました。

アプリ化の決め手は、プロフィール交換を通して、参加者同士の交流のきっかけをつくることでした。記録入力はスプレッドシートに残し、そのデータをRealtime Databaseへ同期し、アプリが変更を受け取る（購読する）構成にしました。Realtime Databaseは、データの変更をアプリへ届けるためのデータベースです。この組み合わせで、本件のシステム利用料0円という条件と既存入力の維持を両立しました。

受付担当の役員アプリから、Google Apps Script（GAS）を経由するAPI（データ更新の窓口）で、記録用スプレッドシートへ受付完了を反映します。記録と受付状態を同じデータの流れに載せる設計にしました。

受付担当は完了を確認して参加賞を渡し、記録係・招集係は記録閲覧画面の「受付完了」を見て呼び出します。呼び出し済みを示す消し込みと背景色は、役員画面内のメモリ上で扱う補助情報です。

QRコードを表示・読取できない場合に備え、管理リストから直接受付を完了できる代替手段も用意しました。通知は進行との自動連動ではなく、現場を見て手動で送る運用に変えています。

第3回は、以前の記録担当者へスプレッドシートへの移行を提案し、移行の実現性について合意を得ました。その後、実際に運用する記録係へ展開し、使い方をマニュアル化しました。

第5回のプロフィール交換と交流賞は、代表幹事と景品担当に相談しました。代表幹事は交流促進に積極的で採用が円滑に決まり、景品担当も新たな景品を増やせるため合意しました。私は交換数を確認できる管理画面を実装し、上位者を運営へ伝えました。アプリはホームページ、参加フォーム、代表幹事のXで参加者へ案内しました。

第6回は担当者へ事前に説明し、マニュアルと来場者向けの1枚の説明資料を準備しました。当日は私も受付に同席してサポートし、進行に合わせたプッシュ通知で招集や場内の案内を補いました。

実装時のAI活用　第5回はCopilotを利用したと記憶しています。第6回はCursorを使って実装しました。

記録は射場ごとの分担入力に変わり、結果を即時にオンラインで確認できるようになりました。第5回は入力方法を変えずにアプリでの閲覧を追加し、プロフィール交換数を交流賞の決定に活用しました。2024年の記事では、結果の更新によって出番に備えるタイミングが分かりやすかったという参加者の声も紹介しています。

第6回は受付状態を記録・招集へ共有できるようになり、当日は受付を完了できないケースは発生しませんでした。

一連の改善で重視したのは、現場で確定した入力方法を残し、共有が必要な情報をつなぐことです。アプリと既存運用の依存関係を薄くし、補助として使える形にしました。第6回もQRだけに頼らず、リストから受付を完了できる手段を残しています。

一方、開発・運用の属人性、他の射会へそのまま転用しにくいこと、細かな不具合は課題として残っています。