お祭りサイトをリニューアルした時の話 その2
その2です。前回は公式LINEの設定まででした。公式LINEはルール内で最大限に生かすという前提でしたので、先に設定しました。この案件に関しては、「一般の方・参加者」と「事務局（私）」をある程度「自動化で繋ぐ」というのが主題でもあるので、特殊なツールや大規模なグループウェアのようなものは極力避けたかったのです。
というわけで、ここからは少し専門的ですが「技術的なログ」として書き留めていきたいと思います。
ある程度のファクトチェックはしておりますので、ひとつご参考までに参照いただければと思います。
今回構成を組み上げたツールについて。
誰もが知っていそうなツールで実現しました。意外と使えるツールでしたし、汎用性も高くカスタマイズも（頑張れば）スムーズにいきます。
| サイトの本体 | WordPress | 世界中で使われているCMS。小〜中規模サイトでは特に利用例が多く、拡張性と外部サービスとの連携が強いのが特徴です。APIも豊富で、今回のような自動化との相性も良好。私の得意分野。 |
| 参加者・出展者からの申込情報 | Google Forms | アンケートや申し込みなどで一度は見たことがある方も多いと思います。Googleが提供しているフォーム作成サービスで、回答内容をそのままデータ化できるのが便利。今回もシンプルな入力フォームとして活用しました。 |
| 申し込み情報のDB | Google スプレッドシート | Excelのように表形式でデータを管理できるGoogleのサービス。クラウド上で共有できるので、実行委員会の担当者と情報をリアルタイムで確認できるのが便利です。今回のデータベースの役割。 |
| 連絡ツール | 公式LINE | 説明不要なくらい有名なLINEのビジネス版サービス。参加者や出店者の方と「友だち」になってもらうことで、電話よりもログが残りやすく、問い合わせ対応もしやすい窓口になります。 |
| API | Google App Script | ここが今回の「自動化くん」。Googleサービスを連携させるためのスクリプト環境で、フォームの送信をきっかけにプログラムを実行したり、データを加工して別のサービスへ送ったりできます。上のツール同士をつなぐ裏方の役割です。 |
この5個です。
特別なシステムを作ったわけではなく、誰でも知っているようなツールを組み合わせただけです。ただし、組み合わせ方を少し工夫すると、地域のお祭りでも意外としっかりした仕組みが作れるものです。
APIを組み込みデータのやり取りを実現
今回私が組み上げた最終的な仕組みの説明図をここに載せておきます。
ざっとですが説明しますと、オレンジ色が下に敷いてある部分を自動処理にしています。
途中に集積されるスプレッドシートは（意外とみなさん持っている）グーグルアカウントで共有することで、リアルタイムで閲覧できるようになり、尚且つシートフィールドの中に正確に入る情報なので、取扱項目さえ共有しておけば、パンフレットを作る人・応募者と連絡を取り合う人・説明会を取り仕切る人みんなが状況を把握できます。
また、窓口をLINEにしてグループ分けすることで複数人で管理ができ、定型文も設定して置けるので、イレギュラーなお問い合わせや込み入ったお話などを除くほとんどの問い合わせに、自動もしくは定型文で迷わず回答できます。
迷わずっていうのが重要ですね。迷って探すのは非常にエネルギーを使います。時代は省エネです。
上の図は概念図みたいなものなので、同系統の事業の自動化スキームにも利用できるかもしれません。
自動化くんことGoogle Apps Scriptはどう言うことをするの？
これは意外と簡単な命令しか出してなくて、
「指定したGoogleフォームの送信ボタンが押されたら、スプレッドシートへの保管以外に、お祭りサイトの〇〇というカスタム投稿に、必要な項目（名前・団体名・プロフィールなど）を送信しなさい」
と言う命令を入れただけです。
その代わり用意しなくちゃいけないのは、本サイト側に「各フォームに対応したカスタム投稿」と「列の情報を受け取るための受け皿となるカスタムフィールド」を作っておき、投稿スラッグ・フィールド名といったあらかじめ命名しておく必要のある「下拵え」が必須になります。
そこまで準備できたら、上記の命令をスプレッドシートの機能拡張にあるApps Scriptに命令プログラムを登録して、受け取りをチェックしたら完了です。
今、簡単に言っちゃいましたが、実はここの命令プログラムもWordPressのセキュリティもサーバーのセキュリティーもという、3人の頑固者を突破しなくてはなりません。この段階が一番時間がかかりました。。。
詳しい設計に関しては、お問合せください。
協賛者情報の登録について
協賛者情報には個人情報や企業情報が含まれるため、画面のビジュアル公開は控えていますが🙇、こちらにもある程度の自動化を組み込んでいます。
実は機能的にはWordPress内で完結した仕組みなのですが。
毎年たくさんの協賛を地元の企業様・一般の方もいただいており、本当に感謝感謝です。ですが、これまでの管理方法はかなりアナログで、会計担当者が通帳の入金記録を見ながら「多分この会社さんかな…（去年の資料を参照）」という形で確認している状態でした。その為社名様が間違うことや、匿名でお願いしてたのに！なんて事故も今までにありました。なのでその反省を活かした設計を考えました。
もういっそのことマスター情報を作ってしまおう
と言うことで、外部でも構わないのですが、「一度でも協賛をしてくれた方」のリストというかDBを作ります。そのDBには社名や住所など事務局がご案内送付などの管理をするために必要な情報を保管してあります。これを協賛マスターとします。
そして管理用レコードとして、WordPress側には「協賛実績」という管理用のカスタム投稿を用意しておきます。実績を年度ごとに登録するのですが、登録する際にはそのDBのお名前（社名）のみを参照し、金額と年度を入力して保存。
保管する際には年度がタクソノミーとして、また同時にタイトルに自動で書き加えられて保管されるので、検索や絞り込みにも非常に便利。
「〇〇年の協賛者一覧を準備したい」
という要望が事務局側にはあるのですが、その際には、絞り込んだリストをエクスポートするだけでOK
あとはVlookUp等で拾い上げできるようにローカル側でファイルを用意しておけば、住所とお名前を一覧にした案内送付先リストも簡単に作れちゃいます。
こうして協賛情報も、できるだけ「人の記憶」に頼らない形で管理できるようになりました。
まとめになりますが
こうして一通り仕組みを整えてみると、気がついたことがあります。
今回作ったものは、特別なシステムでもなければ、難しいプログラムの塊でもありません。
WordPressやGoogleのサービス、LINEなど、誰もが知っているツールを少しずつ組み合わせただけの仕組みです。
ですが、それぞれを「お祭りの運営」という視点でつなぎ直してみると、申し込み・情報管理・問い合わせ・公開といった流れが一つの循環として動くようになりました。
人が入力した情報が整理され、必要な人に共有され、確認されたものがサイトに公開される。
そして問い合わせはLINEで受け取り、また運営にフィードバックされる。
この一連の流れを見ていると、まるでお祭り運営のための小さな基盤のようにも感じます。
私はこの仕組みを、勝手に
「お祭りOS」と呼んでいます。
もちろん大げさなシステムではありません。ただ、地域のお祭りを回していくための、小さな運営基盤のようなものです。
事務局の仕事が少し軽くなり、その分だけ人と向き合う時間が増える。もしこの仕組みが、そんな形でお祭りを支えられているなら、それだけで十分かなと思っています。
この記事へのコメントはありません。