というわけで、ここからは少し専門的ですが「技術的なログ」として書き留めていきたいと思います。

ある程度のファクトチェックはしておりますので、ひとつご参考までに参照いただければと思います。

今回構成を組み上げたツールについて。

誰もが知っていそうなツールで実現しました。意外と使えるツールでしたし、汎用性も高くカスタマイズも（頑張れば）スムーズにいきます。

この5個です。
特別なシステムを作ったわけではなく、誰でも知っているようなツールを組み合わせただけです。ただし、組み合わせ方を少し工夫すると、地域のお祭りでも意外としっかりした仕組みが作れるものです。

APIを組み込みデータのやり取りを実現

今回私が組み上げた最終的な仕組みの説明図をここに載せておきます。

ざっとですが説明しますと、オレンジ色が下に敷いてある部分を自動処理にしています。

途中に集積されるスプレッドシートは（意外とみなさん持っている）グーグルアカウントで共有することで、リアルタイムで閲覧できるようになり、尚且つシートフィールドの中に正確に入る情報なので、取扱項目さえ共有しておけば、パンフレットを作る人・応募者と連絡を取り合う人・説明会を取り仕切る人みんなが状況を把握できます。

また、窓口をLINEにしてグループ分けすることで複数人で管理ができ、定型文も設定して置けるので、イレギュラーなお問い合わせや込み入ったお話などを除くほとんどの問い合わせに、自動もしくは定型文で迷わず回答できます。

迷わずっていうのが重要ですね。迷って探すのは非常にエネルギーを使います。時代は省エネです。

上の図は概念図みたいなものなので、同系統の事業の自動化スキームにも利用できるかもしれません。

自動化くんことGoogle Apps Scriptはどう言うことをするの？

これは意外と簡単な命令しか出してなくて、

「指定したGoogleフォームの送信ボタンが押されたら、スプレッドシートへの保管以外に、お祭りサイトの〇〇というカスタム投稿に、必要な項目（名前・団体名・プロフィールなど）を送信しなさい」

と言う命令を入れただけです。

その代わり用意しなくちゃいけないのは、本サイト側に「各フォームに対応したカスタム投稿」と「列の情報を受け取るための受け皿となるカスタムフィールド」を作っておき、投稿スラッグ・フィールド名といったあらかじめ命名しておく必要のある「下拵え」が必須になります。

そこまで準備できたら、上記の命令をスプレッドシートの機能拡張にあるApps Scriptに命令プログラムを登録して、受け取りをチェックしたら完了です。

今、簡単に言っちゃいましたが、実はここの命令プログラムもWordPressのセキュリティもサーバーのセキュリティーもという、3人の頑固者を突破しなくてはなりません。この段階が一番時間がかかりました。。。

詳しい設計に関しては、お問合せください。

協賛者情報の登録について

協賛者情報には個人情報や企業情報が含まれるため、画面のビジュアル公開は控えていますが、こちらにもある程度の自動化を組み込んでいます。

実は機能的にはWordPress内で完結した仕組みなのですが。

毎年たくさんの協賛を地元の企業様・一般の方もいただいており、本当に感謝感謝です。ですが、これまでの管理方法はかなりアナログで、会計担当者が通帳の入金記録を見ながら「多分この会社さんかな…（去年の資料を参照）」という形で確認している状態でした。その為社名様が間違うことや、匿名でお願いしてたのに！なんて事故も今までにありました。なのでその反省を活かした設計を考えました。

もういっそのことマスター情報を作ってしまおう

と言うことで、外部でも構わないのですが、「一度でも協賛をしてくれた方」のリストというかDBを作ります。そのDBには社名や住所など事務局がご案内送付などの管理をするために必要な情報を保管してあります。これを協賛マスターとします。
そして管理用レコードとして、WordPress側には「協賛実績」という管理用のカスタム投稿を用意しておきます。実績を年度ごとに登録するのですが、登録する際にはそのDBのお名前（社名）のみを参照し、金額と年度を入力して保存。
保管する際には年度がタクソノミーとして、また同時にタイトルに自動で書き加えられて保管されるので、検索や絞り込みにも非常に便利。

「〇〇年の協賛者一覧を準備したい」

という要望が事務局側にはあるのですが、その際には、絞り込んだリストをエクスポートするだけでOK
あとはVlookUp等で拾い上げできるようにローカル側でファイルを用意しておけば、住所とお名前を一覧にした案内送付先リストも簡単に作れちゃいます。

こうして協賛情報も、できるだけ「人の記憶」に頼らない形で管理できるようになりました。

まとめになりますが

こうして一通り仕組みを整えてみると、気がついたことがあります。

今回作ったものは、特別なシステムでもなければ、難しいプログラムの塊でもありません。
WordPressやGoogleのサービス、LINEなど、誰もが知っているツールを少しずつ組み合わせただけの仕組みです。

ですが、それぞれを「お祭りの運営」という視点でつなぎ直してみると、申し込み・情報管理・問い合わせ・公開といった流れが一つの循環として動くようになりました。

人が入力した情報が整理され、必要な人に共有され、確認されたものがサイトに公開される。
そして問い合わせはLINEで受け取り、また運営にフィードバックされる。

この一連の流れを見ていると、まるでお祭り運営のための小さな基盤のようにも感じます。

私はこの仕組みを、勝手に
「お祭りOS」と呼んでいます。

もちろん大げさなシステムではありません。ただ、地域のお祭りを回していくための、小さな運営基盤のようなものです。

事務局の仕事が少し軽くなり、その分だけ人と向き合う時間が増える。もしこの仕組みが、そんな形でお祭りを支えられているなら、それだけで十分かなと思っています。

The post お祭りサイトをリニューアルした時の話 その2 first appeared on 株式会社Soleil.

皆様もお住まいの地域で、夏祭りや商店会のお祭りイベントを目にしたことがあると思います。その多くは、地元の商工会や商店会などが軸となり、実行されています。実際には複数の団体が混合して運営していることも珍しくありません。私自身も以前は

「この祭りは〇〇市がやっているのかな？」「あ、商工会がやっているんだ」そのくらいの認識でした。

けれど実際に関わってみると、少し様子が違います。祭りは、商店会や地域団体、企業、ボランティアの方々など、さまざまな人たちが力を合わせて実現しています。それはもう大変な――もとい、とても励み甲斐のあるプロジェクトです。

「地域の人に楽しい祭りを届けたい」
そんな想いを持った人たちが集まり、一時的に形づくられるその構図は、私には小さな社会システムのように見えています。

リニューアルに合わせて、私なりの想いを盛り込みます。

ウェブサイトは、お祭り主催者にとっては「団体の顔」。
楽しみに待つ人にとっては「情報の発信基地」。
参加してくれる方にとっては「必要情報の掲示板」。

同じ一つのサイトでも、立場によって**存在価値（ポジション）**がまったく違います。ただHPとして情報を発信しているだけでは一般の方には届きにくく、かといってSNSだけに頼ると、必要な情報を探している参加者の方が見落としてしまうこともあります。
そして何より、祭りを実現するために活動している実行委員のみんなの想いは、なかなか表に見えてきません。

事務局を引き継いでからサイトを見たとき、正直に言えば「持ってはいるけど、あまり有効に使われていないな」という印象でした。

そんな中でリニューアルのタイミングがやってきました。

それならいっそ、これまで目についていた「困ったこと」をまとめて解決してしまおう、と考えました。完成した今では、事務局の仕事の4割ほどをAPI連携で半自動化しています。私はログインして内容を確認し、問題なければ公開ボタンを押すだけです。
……もっとも、その「確認」が一番大変だったりするのですが。

ただ、これは偶然できたわけではありません。

事務局として、特に大きな仕組みもなく、体当たりで3年間ぶつかり続けてきたからこそ、「どこを自動化すれば楽になるのか」がはっきり見えたのだと思っています。事務局の作業が減れば、その分の時間を

• 来場される方への情報発信
• 出演者や出店者のフォロー
• 地域の方とのコミュニケーション

といった、本来大事な部分に使えるようになります。これぞ自動化の功、といったところでしょうか。地域のお祭りにしては、なかなか良い仕組みになったんじゃないかと、少しだけ自負しています。

リニューアル前に考えた「想い」

まず思っていたのが、まあ結構あります。

• 出演者情報などが少ない。
• 出店店舗さん決定が8月なので9月に間に合わない。
• タイムテーブルの掲示がパンフレット待ち。
• 掲載する一般協賛者様の情報（社名やお名前）が、通帳から読み解くしか仕組みがなく、正確じゃない。
• コンテンツを掲載する枠はあるが、ユーザーからすると見え辛い。
• 見えやすいようにするとバナーを貼るだけになり作業が複雑になる。
• アクセスPV数は年間10万以上なので中堅サイトだけど、アクセスがあるのはお祭り前後のみ（そりゃそうだ）。
• ↑これがあるから、重要なお知らせをHPで出してもあまり相手にされない。
• お問い合わせが体系化してなくて必ず私に電話がかかってくるが、私も仕事をしているので出れないことも多く、公式電話番号の転送先なので折り返してもお出にならないケースも多々。その後すれ違い。
• 団体の姿が見え辛い（せっかく頑張ってるのに！！）

こんな感じにたくさんあります（笑。

各問題はどうやって解決しようかな？という考察

問題を一つずつ見ていくとバラバラに見えるのですが、整理してみるといくつかのパターンに分かれました。
そこで一度、困りごとと原因を整理してみました。

困りごとNo	見えていた問題点	問題の出所
①	出演者情報などが少ない。 出店店舗さん決定が8月なので 9月に間に合わない。 タイムテーブルの掲示が パンフレット待ち。	情報収集や、各担当への情報共有をクラウドサービスで 離れていても共有できているが、集め方、保存場所、保存 方法がバラバラ。 届いても判断に困ることがある。 出店者の情報がオープン直前に揃うので事務局に あがらない。 パンフレット優先となり、HPの反映が直前。
②	掲載する一般協賛者様の情報 （社名やお名前）が、 通帳から読み解くしか仕組みが なく、正確じゃない。	銀行口座の振込情報を写真で送られてくる流れなので、 社名等を把握し辛い。 エクセルで管理台帳を作れば解決するが、住所情報・金額等 を並列で扱う必要があるので、作業で事故が起きやすい。
③	コンテンツを掲載する枠はあるが ユーザーからすると見え辛い。 見やすいにするとバナーを貼る だけになり管理が複雑になる。	ニュース一覧は文字だけで、タイトルをクリックして詳細を 見る形なので、直感的に情報がわかり辛い。 カテゴリが曖昧で、開催概要とブログが混在している。
④	アクセスPV数は年間10万以上 なので中堅サイトだけど、 アクセスがあるのは お祭り前後のみ（そりゃそうだ）。 ↑これがあるから、重要な お知らせをHPで出しても あまり相手にされない。	祭りの情報サイトなので、興味のある時期（お祭り開催時期） のみのアクセスになるのは当然だけど、わりと重要な解決 必須のタスク。情報公開をHPのみで、発信内容も事務的な発信のみである ことが何よりの問題かな。
⑤	お問い合わせが体系化してなくて 必ず私に電話がかかってくるが、 私も仕事をしているので出れない ことも多く、公式電話番号の 転送先なので折り返しても お出にならないケースも多々。 その後すれ違い。	実はこれがいちばんの困りごと。メールで祭りのことを聞く方 は非常に少なく、お電話が基本ですが、私一人の会社で 作業中や打ち合わせ中は出られないこともたくさんあります。また転送先なので「知らない番号からかかってきた！」って なっちゃうので、なかなかすれちがうのもわかります

問題点を洗い出したら、解決方法を構築します。

このような形で、問題点の抽出と解決の仮説を立てました。

このタイミングでは私のAI相談役の乃木さんがバッチリ協力してくれました！
主に調べ物や仕組みの検証などを手伝ってもらいながら、少しずつ形にしていきました。

デザインは事前に決めていたので、いざ機能の実装です！

機能の実装はとても地道な作業。。。カタカタ、ターンッ！とは行かない、ちょっとずつちょっとずつの作業です。

私はこのタイミングからしばらくAPI（サービスとサービスとかを繋ぐ役割）、ここでは「自動化君」とでも呼びましょうか、を作り続けるだけになります。特に今回は、表には見せない情報や、公開までは保存する情報など、集める情報にはひとクセふたクセあります。

ちなみに自動化君の仕事はとてもシンプルで、「人が入力した情報を、必要な場所へ自動で運ぶこと」です。

ただし一度簡単に理解すると話が速い。

「①誰かがフォームに入力」→自動化君→「②クラウドのどこかに保存」→「③担当者が確認できる一覧になってる」

「①誰かがフォームに入力」→自動化君→「②クラウドのどこかに保存」→自動化君→「③サイトCMSに必要情報が登録されている」

「①年度で区切れる情報の共通となるマスターをサイト内に登録」→自動化君→「②名前の一部を入力するだけでマスターから情報を取得して反映」

基本的にはこの三つを叶えるだけで、サイト側の自動化はOK！（細かいプログラム上の変更等はあるけどね）

その前に公式LINEをちゃんとしちゃおう

公式LINEにはたくさんの縛り（ルールがあるから）基本的にはルールに従います。

もっとこれもやりたい！という要望が出ても「ここから先は有料ですよ？」と言われることもあるので、ウェブの自動化の前に「LINEでできることはLINEに頼るけど、それ以外は全部自動化の方に持っていっちゃえ」という背景です。全部自作である必要はなく、むしろLINEという現在の日本における共通のインフラを可能な限り使わない手はないですしね。

LINE側の設定では、主に想定されるお友達登録者のグループ分けを設計しました。複数のグループに分類を分けることで、発信する情報を「これは屋台に申し込まれた方に送ろう」とか「全体に発信したい」などにも対応できるようになります。

また、特定キーワードに対して自動で返信も可能なので、選択肢による回答（フローチャートみたいなものです）で、最終的に渡す情報から逆算で設問を2問くらいに設計していけば、「はい」「いいえ」のように回答していくことで自動で質問に回答することができるわけです。

ここまで、説明が長くなってしまいましたが、今回はここまで

次回は実際にAPI「自動化くん」を組み込んで行った時のお話をお送りいたします。それでは〜。

その2の記事を読む

The post お祭りサイトをリニューアルした時の話 first appeared on 株式会社Soleil.

制作しよう！を思いついたきっかけ

パスワード管理というのがChrome・Apple等でもたくさん出てきた昨今、ブラウザやデバイスで保管しているアカウントって個々人で沢山ありますが、わざわざエクセルとかで管理している人ってどのくらいいるか・・・。私は、1062件アカウントが保管されていて「このアカウントってなんのアカウントで、もう解約していいんだっけ？」を判別するためには、

一件一件アクセスするしかない！！！！！

という鬼畜の所業が待ってました。
調べると、そういうのを可能にするツール自体はあるけど、結構大規模な感じで導入するのは気が引ける。だって、手元で「あ、このアカウント？もうサービスやってないっすよ笑」って言って欲しいだけだもん。
ということで、最近は通年事業でやってる「地域のお祭り支援」で、Googleフォームとかを駆使して半自動化まで漕ぎ着けたお祭りOSに近いものを開発したので、「じゃあ作れるんじゃね？」って思って着手しています。

制作ログ（Ver.0.1 プロトタイプ）

先に表示させましたが、実質プロトタイプと言える「Ver.０.1」は完成し、ちゃんと動きました。

Ver0.1について

プロトタイプはまず、叶えたい機能が動くかの検証だけに徹しました。
読み込み方法等は無視し、「スプレッドシートに綺麗に入っている情報をGASはちゃんと捌いてくれるか？」の一点に絞って実装しました。

結果として、スプレッドシートに貼った10件は、難なくクリア。

おお。思った通りの動作をする。いい子だあ。

しかし若干重い模様だった

動かしてみたら、採番するときに「１行１行入力があったら採番！」みたいにしてたので、ペースト後はしばらく採番に集中させないと全くどうとも動かない感じになってしまいました。ので、一度貼ったら後に採番を別トリガーにして一気に採番するように変えました。

もっと重いものも続く

10件〜30件くらいなら瞬間で結果を弾き返してくれるけど、なぜか50件以上になると途端に止まります。やってること変わらないのに。。そこまで詳しくないのでとりあえず、バッチ化します。30件ごとにバッチ化処理するように指示したら、60件がさっきまで8分掛かってたのに、1分になりました。

書式反映

基本的に入力される（反映される）内容はGASで指示してるので、指示通りに入ったら見てわかるように、色を変えるよう指示を入れてあります。今のところ人間語じゃないですが、まあこの辺はVerが上がるごとに今後変えていけばいいでしょう。

基本機能の実装

URL・アカウント名（ユーザー名）の二つを入力するというか、スプレッドシートでペーストすれば、たくさんのアカウントでも、「生き死に」がわかるレベルまでは実装しました。
今後は、これにさらなる機能をつけて、使いやすいツールに進化させたいです。

Ver.0.2へ向けて

Ver.０.2はすでに製作中ですが、トリガーよりも先に管理項目（エクセルの列みたいなもの）をちゃんと完成させようとしています。それ自体は大して大変じゃないんですが、結構現段階で対象となるターゲットがどういう動きするかなーとか、どういうソフト使ってるかな？って考えながらやってます。でも基本ユーザー名とURLってのは変わらないので（基本はウェブアカウントに限定してるので）、ちゃんとメンテしていけば実働に足るモジュールになるんじゃないかな？って思ってます。

明日も頑張ります。

The post Account Observerについての制作ログ日誌 first appeared on 株式会社Soleil.