自治体向け予約管理・抽選システムの開発事例｜多様な住民サービスに対応する業務効率化と利用者体験向上の両立

導入：自治体サービスの「予約と抽選」は、なぜこんなに煩雑なのか？

公共施設の利用や住民サービスを巡る“予約・抽選”業務は、自治体職員にとって大きな負担となっています。
たとえば、

・公民館や体育施設の貸出予約
・予防接種や健康診断の時間枠予約
・講座やイベントの定員制申込（先着順 or 抽選）
・高倍率な申し込み枠の抽選結果通知

こうした業務の多くは、いまだに電話や窓口受付、Excelでの転記管理といったアナログ運用に依存しており、

「同じ電話番号から何度も申し込まれて困る」
「予約時間の重複やダブルブッキングが発生してしまう」
「抽選の公平性をどう担保するか分からない」

といった問題が日常的に起きています。

本記事では、ある地方自治体で実際に導入された「予約・抽選管理システム」の開発事例をもとに、
発注側が意識すべき視点やシステム設計の工夫、費用対効果の考え方を具体的に解説していきます。

ユースケース概要：複数種別の予約・抽選を一元管理

対象の自治体では、住民サービスごとにバラバラだった受付・管理業務を「1つのシステム」で統合しました。

具体的には以下のような業務が対象です：

• 公民館・体育館・調理室などの施設利用予約（抽選 or 先着順）

• 健康診断・予防接種などの時間枠予約（年齢条件付き）

• 市民向け講座の応募・キャンセル・補欠管理

• 抽選結果の自動通知・当選者確認ページの提供

• 窓口職員による代理申込・予約変更対応

このように、利用対象・予約方式・入力項目が異なる多様な業務に対して、“設定型の管理画面”を設けることで運用の柔軟性を確保しつつ、住民側のUXも統一する設計が求められました。

システム開発の要件と工夫ポイント

今回のシステム開発では、以下のような要件が提示されました。

住民側の要件

• スマホで完結する申込・キャンセルフロー

• 抽選結果やリマインド通知をLINE・メールで受信

• 家族分の申し込み／代理申し込みにも対応

• アカウント登録なしでも申込可能（認証は予約番号と生年月日）

管理側の要件

• 業務ごとに受付期間・定員・応募条件を設定できる

• 予約や抽選の受付・キャンセル・当選連絡を一元管理

• ログ・履歴の記録、CSV出力、電話申込の代理入力機能

• 高齢者向け操作支援（紙ベースの予約受付→後入力も可）

特に評価されたのは、**抽選ロジックをシステム化することで「公平性の担保」「問い合わせ削減」**が実現された点でした。

技術スタックとセキュリティ配慮

システムは以下のような構成で開発されました。

• フロントエンド：Vue.js（スマホ対応・アクセシビリティ対応）

• バックエンド：Laravel（PHP）

• DB：MySQL（予約・応募データを正規化設計）

• 通知：SendGrid（メール）／LINE Notify

• インフラ：AWS（RDS・S3・WAF）

• セキュリティ：SSL／WAF／ログインIP制限／認証コードによる本人確認

また、以下の点が行政案件ならではの要件として求められました：

• データは国内リージョンでのみ保存

• 操作ログは6年間保存（住民訴訟等を見据えて）

• 同一IPからの不正申込を制限

• アクセシビリティ配慮（音声読み上げ対応）

開発プロセス：住民と職員双方の声を反映したアジャイル設計

行政案件はウォーターフォール型になりがちですが、今回は以下の理由で段階的なアジャイル開発が採用されました。

• 多様な部局が使うため、要件が途中で具体化される

• 住民からの声をデモ版で確認し、UXを調整する必要があった

• 本稼働前にテスト予約期間を設け、負荷や運用負荷を事前検証した

その結果、「職員も納得し、住民も使える」形に仕上げることができました。

成果と費用対効果：どのような効果が得られたか？

実際に導入された年のデータでは、以下のような効果が見られました。

• 窓口・電話予約対応の業務時間が月100時間以上削減

• 抽選業務に関する問い合わせ件数が80％減少

• 市民アンケートで「予約のしやすさ」が前年比30％向上

• 職員の属人業務が解消、誰でも代理対応が可能に

また、再利用性のある設計としたことで、翌年には新たな講座予約にも転用され、追加開発コストも抑制されました。

今後の展開と“中長期で見た価値”

このような自治体向けシステムは、「一度作ったら終わり」ではなく、住民ニーズや制度変更に応じて継続的な見直しが必要です。

そのため、以下のような設計思想が盛り込まれました：

• 管理画面から「予約種別」「応募条件」「定員方式」を自由に変更できる

• 抽選方式も「先着順／完全抽選／部分抽選」などを選択可能

• 職員ごとの操作ログ管理、変更履歴のトレース機能

• 今後の拡張として「APIによる住民ID連携」や「窓口タブレット受付」も想定

このように、“仕様書で固定されない柔軟性”を持った構造こそが、費用対効果の高い公共システムであると評価されています。

発注担当者が押さえるべき開発視点

• 機能ではなく「運用フロー」を主軸に設計を考える

• アナログ運用の「不満点」「転記のムダ」をすべて棚卸しする

• 利用者（住民）視点だけでなく「職員が運用しやすいか」を優先

• 抽選結果や応募履歴など「問い合わせに耐えうる設計」になっているか

• 操作ログ、監査ログ、出力仕様なども初期から仕様に入れる

自治体案件は“トラブルにならないこと”が重視されるため、実装よりも「安心できる仕組み」が何よりも価値になります。

まとめ：小さな自治体でもDXはできる。鍵は“柔軟性と安心設計”

今回の予約・抽選管理システムの開発事例は、大都市圏ではない地方自治体での実装でした。
予算も潤沢とは言えない中で、それでも「住民サービスをよりよくしたい」という現場の思いが形になった成功例です。

発注を検討している自治体や関連団体の担当者にとっては、「大がかりなパッケージ導入」ではなく、目的に絞った“設計型の受託開発”という選択肢が現実的であることを、ぜひ知っていただきたいと考えています。