静岡県の自称進と進学校の狭間の高校の文化祭で生徒の利便性を高めるために、食券デジタル購入や公式LINE/WebAppを開発したお話(2023年のお話)
書いた場所によって文体が違ったり、個人的な主観を含むのでそこはご愛嬌としてゆるーく書かせてもらうよ。
追記:ほったらかしにしてたから公開すんのむっちゃ遅くなっちゃったけど、そのまましまっておくのも勿体ないし現役高校生でこんなもん作ったよっての共有です。ちょい引継ぎ的な意味で書いてたけどそれを修正して公開させていただきます。
目次
全体を通して
第76回香陵祭のデジタル関係でここには、①公式LINE、②公式HP、③公式ウェブアプリとウェブアプリ上で行った④食券デジタル購入が書かれてます!
公式LINEやHPについては以前からあってウェブアプリと食券デジタル購入に関しては今年から導入しました。
それぞれの運営内容や理由、反省などなどは後々書かれていますが基本的には、1・2年の間に不便に感じたことを改善してさらにより良くすることを目標に作りました。(あと単なる創作意欲)
沼東生の中でこーゆー人種は少ないですが、第76回香陵祭を参考にさらに進化した香陵祭を作り上げていってほしい時思います。
運営内容を要約すると、
- 公式LINEでは連絡やMATSURIとアンケートリンクの配布に加え、新たに点呼の呼びかけやステージのイベントの紹介を行った
- 公式HPでは例年通り、「四長あいさつ」「バスの時刻表」それぞれの団体の「模擬店展示」「ステージ」を公開した
(アンケートにWAの下位互換って言われたけどその通り) - 公式ウェブアプリでは、公式HPの内容に加えてお知らせのアーカイブ的なニュース(PDF表示可)、気象庁のデータの天気予報、食券デジタル購入、Canvasに描画したスケジュール、電子版MATSURIなどのコンテンツを提供した
※「ウェブアプリ」て書くのめんどくさくて開発上たまにWAって略してる - 食券デジタル購入は、今まで激悪だった食券販売を改善するために購入部分をユーザーに選択してもらう形でデジタル化した
(初期構想時は全てデジタル化する予定だったからデジタル食券とも呼んでた)
▼それぞれの公開範囲
対象 | 公式HP | 公式LINE | 公式WA |
---|---|---|---|
保護者 | ◯ | △一部制限 | × |
一般の方 | ◯ | △一部制限 | × |
生徒 | ◯ | ◯ | ◯ |
先生方 | ◯ | ◯ | ◯ |
▼使用言語
- HTML/CSS/Javascript(フロント)
- PHP(サーバー側)
- Python(Excelとかの処理)
1.公式LINE
諸々の諸事情
公開するまで
本当はもう少し公開を早くする予定でしたが、公式ウェブアプリの開発を待って他係の公開と合わせて4/25に公開しました。
ちなみに、4月はお金払ってなかったのもひとつの理由。
認証化
認証するとアイコン横の盾が灰色から青になって、検索しやすくなるらしい?
沼東を祭典委員会の住所にしてたから、そこに電話がかかって何も知らない先生か事務員が対応して垢バンされるかもって危機があった。
こっちから電話して「担当の某先生にかけてね」って伝えたら認証できた。
ちなみに、優しそうなおじさんの声だった。
▼要はコレ(認証前)
食券販売時
食券デジタル購入の方で詳しく扱うけど、かなりLINEの友だち登録者数が増えた。
人に登録してねってお願いするよりも、登録したいって思わせる方が良いらしい。
準備期間
各係の配信したいこととか連絡をちょこちょこ入れてた。
もう少し、係員募集とかに注力できれば良かったとは思う。
準備日
考えられる送信内容を事前に考えといてねーとは四長係長には伝えてたものの、当日になってあれやれこれやれといったものが多かった。(というかそれしかなかった。ふざけんな)
このペースで配信してると料金の枠超えそうだなって気づいたのはこのとき。
重要な連絡がかなりあったからウェブアプリに登録してなかった人が文句言い始めたのもこのとき。
(1ヶ月の登録期間に登録しないやつが悪い)
文化祭当日
基本的に問題なし。
ただ、疲れも出たのか17時に集合というのを15時に集合って送信ミスをした時があった。(自治会室で超焦ってた笑)
睡眠は大事ですね。ほぼ仮眠レベルでしか寝てなかった
一般の方に折りたたみのパンフレットを配布してたけど、枚数より人数が多くて公式LINEに誘導してたから友だち登録者数が増えたらしい。
ちなみに、登録者数最大時1260人ぐらい。
配信数を抑えるために連絡事項をステージのイベントの宣伝にくっつけて配信してた。
体育祭
本来ならば5月中に香陵祭は終了する予定だったから、予算としては5月分の1万5千円しか計上してなかったけど、体育祭が6月にもつれ込んだことで配信する必要が生まれて5千円つぎ込んだ。(そんで文句言われたっけ)
ちなみに、2023年6月から公式LINEの利用料金が値上げされてる。
▼参考
配信数 | 無料 | 5000円 | 1万5000円 |
---|---|---|---|
5月まで | 1000発 | 15000発 | 45000発 |
6月から | 200発 | 5000発 | 30000発 |
どう見ても改悪
公開範囲とオーディエンス配信
公開範囲は最初の最初に前述した通り、保護者一般の方を一部制限して、生徒先生方を全て対象にといったところ。
生徒に関しては、連絡があるから公式LINEとWA基本的に全員登録してねーってスタンスだった。
一部制限というのは、WAに登録した人とそれ以外で分けてメッセージを配信していたということ。
※正しくいうと、WA登録時に取得したユーザーのUserIDをもとに、そのリストを作ってオーディエンスを作成して、配信対象を絞り込んで配信してた。
(つまり、手動工程があるから実際にはWA登録者≧配信対象)
登録情報にHRNOがあるからそれをもとに学年ごとの配信も可能だった。
名簿とか連絡事項は外部に漏れるとダメだから、これが必要だった。
ちなみに、リッチメニューもUserIDのjsonを使って内部用と外部用で若干変えてた
リッチメッセージ
補足で書いとくとリッチメッセージというのは公式LINEでたまに送られてくる正方形の大きい画像のこと。
基本的にこれを点呼時間のお知らせに使ってた。(結構好評だった)
▼つまりコイツ
そもそも点呼に関して服装だったり場所だったり時間だったりと決められてるけど、今までの香陵祭だとその資料を見ないと把握できなくて不便だったからこれを作った。
もともとこの機能があることを知ってたから、模擬店とかステージのサムネイル作成の副利品でできたやつを送ってた。
ちなみに、画像アップロードするときに謎に1040x1040にこだわられて、毎度リサイズするのがめんどくさかった。
▼作成した画像たち
2.リッチメニュー
補足で書いとくとリッチメニューというのは公式LINEの画面下部に表示されてるやつのこと。
作成に至った理由
リッチメニュー自体は前の香陵祭から使ってたけどここまで進化させたのは今年度から。
そもそも香陵祭期間前に表示してたのがこれ。
▼期間前のリッチメニュー
公式ウェブアプリを新たに導入したこともあってそれを大きく表示してる感じ。
期間中に向けてリッチメニュー変えなきゃなーって思ってたところに来たのが、兵庫県の長田高校の文化祭の公式LINEのスケジュール表示だった(変更されちゃったから見せるものないけど)
公式LINEのリッチメニューにスケジュール入れるのはすごい革新的って思って感動した。(特にアクセスする時に見るし。)
プラスで、スタバの公式LINEからリッチメニューエイリアスってものを初めて知った。(※リッチメニューを切り替えることができる機能)
そんで、リッチメニューにスケジュール載せてタップで日にち変えられたらいんじゃないって思ったのが始まり。(だから、当初はこーゆーことをするつもり無かった。)
リッチメニュー変遷の歴史
そんでやってたもののスケジュールの変更が超絶あって、リッチメニューの変遷を辿ると、
- まず、Day1-3のリッチメニューを公開
- 前夜祭前日準備関連のぴーぽーたちの要望から生徒用のDay0を急遽追加
- 保護者用のバスの時刻表に誤りが見つかって訂正
- 前夜祭で出来なかった仮装行列が2日目に追加され変更
- あまこんの時間が変更
- 体育祭の延期が決定し変更
- 体育祭の予定から29日の予定に変更
- 後夜祭の予定が当日になってごちゃごちゃして、スケジュールが定まらなかった為シークレット表示に
- 体育祭延期日の朝完全に晴れだったので晴れ表示に
-
圧力を食らってグランドが使えず大縄予定に変更 - 午後の種目が決定し日程を変更
- 最終的に「ハリボテが燃えるまで香陵祭は終わらない」に変更。(本当にいつになったら燃やすのか)
(追記:燃やさずぶっ壊したらしいですね)
とかとか、利便性もあって常に最新になるように更新していた感じだった。(更新作業自動化されてるわけじゃ無かったからそんな簡単に変えられるものだと思って欲しくない。地味にだるかったし)
デザイン
リッチメニューに入れるべき情報といえば、スケジュールとMATSURI、強いていえばあと模擬店マップ。(保護者向けにはバスの時刻表)
ついでに一応公式SNS系を乗っけてこーゆー感じになった。
みんなが必要としている情報に素早くアクセスできるような配置と大きさを意識した。
▼一日目のスケジュールのリッチメニュー
上に「Day1」「Day2」ってタブみたいな感じで表示してる領域をタップするとリッチメニューが切り替わる。
このリッチメニューを切り替える諸々のことをリッチメニューエイリアスって言う。
▼リッチメニュー一覧
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
リッチメニュー設定でめんどかったこと
これを設定するのはこの時の時点ではノーコードでは出来なくて、かなーり面倒な作業が必要。
設定の流れは①デザイン、②マスのデータ送ってリッチメニューIDを発行、③画像を送ってリッチメニューIDと紐づける、④リッチメニューIDをエイリアスと結びつける、⑤リッチメニューを対象のユーザーに結びつけると言った感じ。
詳しくは公式LINEのドキュメントを見ればよくわかると思う。
(ちなみに、公式LINEの仕様って1年の間でいつの間にかだいぶ変わってることよくある)
①は、スマホの(特に古くて)小さな画面に表示されることに注意して、ギリギリ読める文字の大きさとフォントにこだわってやってた感じ。
②は、送るjsonが間違ってなければマスの座標が死ぬほどズレてても何も言われないから注意。何回かやらかした。
③は、1MB未満かつ720px以上とかいう絶妙な大きさを求められるからリサイズしてうまく大きさを合わせる必要がある。判定厳しい。
④は、なんとかなる。
⑤は、登録してくれた生徒のユーザーIDを約800人分一気にやろうとしたら上限500人って文句言われたから400人で分割して設定してた。
基本的にドキュメントとエラー文をよく読んでお友達になっておけば大丈夫。なはず、、、
3.ウェブアプリ
作った理由
- スケジュールやMATSURI,模擬店の情報など見たいものが今まで別々の配信元かつ別々なフォーマットでアクセスしずらかった
- スケジュールの急な変更がちょこちょこあり,パンフレット(小さいびらびらーってした紙)が意味をなさない
- 公式LINEで絞り込み配信をするために生徒のユーザーIDを取得する必要がある
- 食券購入のプラットフォーム
- 公式LINEの仕様でPDFを送信できない(
これがゴミ仕様すぎる)
ウェブアプリという形式
ここに至るまでは少しいざこざがあった。
そもそも開発時点でLIFF上で動くことを前提としてたから急にプラットフォームを変更するのは無理だったのと、アプリを作って見てみたいってのがあった。
とりあえず、最終的にネイティブアプリじゃなくてLIFFを選んだ理由を書いとく。
ネイティブアプリにしなかった理由
- 開発コスト(お金も労力も)かかる
- アプリをインストールするのに抵抗を持つ人がいる(容量とかネット環境とかで)
- 一般公開でふらっと来た保護者とかが沼東回線(しかも香陵祭期間中さらに遅くなってる)でアプリインストールしてくれるかって問題
- インストール後の急な更新がしにくい
- 公開するのに上(学校と県教委)の許可が必要(?)
- メリットとしては、公式LINEの配信数制限とか気にせずプッシュ通知できる
LIFFにした理由
- インフラ基盤のLINEとの連携がしやすい
- HRNOとユーザーIDを結び付けることで学年ごとの配信が可能
- 公式LINEを内外兼用にできる(今までは一応校内のみ)
- 学校配布Google垢はログインできてない人がちょこちょこいるけどLINEの普及率はほぼ100%
- webだからiPhoneとAndroidの両方に対応できる
- パスワード漏れを防ぐ
- パスワード忘れを防ぐ(
学校配布のGoogle垢のパスワード死ぬほどいたし) - なりすましを防ぐ
技術的な部分
環境
フロントエンド(クライアント側)
iPhone/Android端末でありLINEがインストールされていることを前提
HTML/CSS/JavaScriptで構築
jQueryで描画とajaxでPOSTでjsonを通信
(2023年とは思えない超古参アーキテクチャ)
ちなみにポーリングしてユーザー行動を取得してる
LIFFを使ってログイン処理
バックエンド
HPとウェブアプリとLINEのWebhook兼用のサーバー
受け取ったjsonのリクエストと含まれるデータをPHPで処理
(2023年とは思えない超古参アーキテクチャ その2)
(ちなみにリメイク版ではReact+ViteをAWSで動かしてます)
画面デザイン
Home
▼開発当初のデザイン(左)とリリースしたもの(右)
上の要素から順に説明していくと、- 上のバナー画像は、WA自体がシンプルなデザインゆえに彩りが無いととてもつまらない画面になってしまうので配置。
開発当初は、ここに模擬店の広告とかCMとか連絡事項とかもフェードかスワイプすれば見れるようにするつもりだった。(ここにガチ広告をはさんでその収入を…って考えもあった) - 誰も見ることないだろうなーとか思いながら、さりげながらにその日の日付と天気予報を配置。(実際にはこれを見て地味に便利だったって声もあった)
天気の部分をタップでWeatherにアクセスできる。
アニメーション付けて、その日の天気と週間予報を入れ替えさせることも考えてた。 - ニュースの部分は、最新のものを4つだけ表示させて、一応祭ごとに切り替えできる機能を配置。(イベント取得してないから実際どれだけ使ったかわかんないけど)
最新の4つにしたのは、ある程度たくさん情報は詰め込みたいけど≪その他のコンテンツ≫がスクロールしなくても見れるようにしたくてちょうどよかったのが4個だったというわけ。
ちょうどいい色の組み合わせが見つからなかったからそのままモノトーンで攻めた。 - その他のコンテンツは、ユーザーがあまり必要としていないと思われるコンテンツへのリンクとして配置。(食券デジタル購入は例外)
正方形でリッチメニューLikeにデザインしようとも思ったけど、たまたま良さげなのを見かけたからそれをインスパイヤ。(ものは言いよう) - お蔵入りしたものとして、次のイベント表示と混雑情報表示があった。(常に一般の方で混雑してたから別にいらなかったかもだけど)
それに乗じて商品の販売情報も入れようと考えてたけど時間が無くてどれも断念。 - さまざまなコンテンツにアクセスしやすい用に、主要なコンテンツ(News/MATSURI/Schedule)を画面下部のフッターに配置した。
基本的にほとんどのスタイルはflex
で作ってたからCSSとflex覚える良い練習になった。
Weather
▼開発当初のデザイン(左)とリリースしたもの(右)
ちなみに天気予報データの提供源は、気象庁のAPIとOpenWeatherMAp。
気象庁のAPIに関しては調べれば出てくる。違法じゃないけど正規利用ではないと思う。
ほとんどの表示されてるデータは気象庁のもの。
OpenWeatherMapは無料で利用できる数少ない天気API。
どちらもJSONで提供される。
気象庁とかウェザーニュースとかサイトで開発者ツール開いてJSONらしきものを漁ってればそれらしきものにたどり着けますよね
デザインは、Nerv防災のアプリにインスパイアされたもの。(エヴァっぽいとこもだけど普通にデザイン良いよね)
天気のアイコンは、某サイトからちょっくらお借りしてる。違法かも。
{
"text": " 梅雨前線が華中から日本海を通り日本の東へのびています。",
"minTempAverage": "22.9",
"maxTempAverage": "29.6",
"todayWeather": "203",
"weekTimeDefines": [
"2023-06-09T00:00:00+09:00",
"2023-06-10T00:00:00+09:00",
"2023-06-11T00:00:00+09:00",
"2023-06-12T00:00:00+09:00",
"2023-06-13T00:00:00+09:00",
"2023-06-14T00:00:00+09:00",
"2023-06-15T00:00:00+09:00"
],
"weekWeatherCodes": [
"203","211","201","201","201","201","201"
],
"weekPops": [
"","40","30","30","30","30","30"
],
"weekTempsMin": [
"","26","26","25","24","24","24"
],
"weekTempsMax": [
"","33","34","33","33","32","32"
]
}
利用したAPIたち
▼気象庁の準公認API(静岡県の天気概要)
▼気象庁の準公認API(静岡県の週間予報)
▼OpenWeatherMap(沼東の現在の天気)
News
▼開発当初のデザイン(左)とリリースしたもの(右)
実機で見たら全体的なサイズが小さかったからそれを反映して少し大きくなってる。
タブの機能をつけてそれぞれの祭ごとに見れるようにしてる。
(この機能地味にめんどくさかった)
記事を投稿した時間から日付を表示してる。(管理制御盤から記事作成更新できる)
ちなみに、SPAの癖して更新ごとにデータ取得してなくて、実際にはウェブアプリに最初にアクセスしたときのデータを使いまわしてるだけ。
{
"N0021": {
"NewsID": "N0021",
"Important": false,
"NewsType": "Culture",
"NewsCategory": "Notice",
"DateTime": "2023-05-27 17:27:00",
"Title": "落とし物について",
"Content": "<p>落とし物が多く届いております。</p><p>落とし物が…</p>"
},
"N0022": {
"NewsID": "N0022",
"Important": false,
"NewsType": "Culture",
"NewsCategory": "Notice",
"DateTime": "2023-05-27 17:28:41",
"Title": "文化祭期間中の飲食について",
"Content": "<p>飲食は指定された飲食スペースのみです。</p><p>体育館内で…</p>"
}
}
Shop
▼お蔵入りしたもの(混雑&販売情報付き)
▼リリースしたもの 模擬店と展示を分けるとExhibition(展示)って書かないといけなくてそれがむっちゃ長いし、係編成もまとまってるから模擬店展示でまとめてた。 基本的にウェブアプリ、デジタル食券、LINEの自分が担当するものの中では、Day1->黄色、Day2->ピンクで統一してる。 Day1とDay2で切り替えられるような機能を途中でつけた。(食券関係での反省) たぶん画像の部分に目が行くから、そっちにほとんどの情報を詰め込んでる。この画像自体はAviutl(使い慣れすぎてた)でちょいちょいーって作った。 背景はOKUMONOさんから。(ものすごく良い背景用素材サイト) 日にちと場所は概要の下にうすーく残しておいた。 本当は日にちと場所の下に混雑情報と販売情報をつける予定だったけど、例の通り時間が無くて断念。(ただ、数の暴力で4000人も一般いたら常に混雑してたし一瞬で売り切れた。) 商品に関しては、デジタル食券で使ったものをそのままコピーしてる。{
"D2-C2A-Q11": {
"PlaceID": "C2A",
"Day": "Day2",
"GroupName": "旧11HR",
"ShopName": "猫カフェ",
"ShopType": "FoodShop",
"Thumbnail": "D2-C2A-Q11.png",
"Comment": "私たち11HRは、人間ネコカフェをオープンします!!…",
"ProductIDList": [
"D2-C2A-Q11-P01",
"D2-C2A-Q11-P02"
],
"Notes": [
"事前に購入された食券を優先させていただきます。",
"状況によって商品の値段を変更する場合があります。",
"特定原材料(アレルゲン)を含む商品を販売しております。"
]
},
"D2-C22-Q17": {
"PlaceID": "C22",
"Day": "Day2",
"GroupName": "旧17HR",
"ShopName": "射的",
"ShopType": "GameShop",
"Thumbnail": "D2-C22-Q17.png",
"Comment": "射的ともぐらたたきをやれます!…",
"ProductIDList": null,
"Notes": [
"景品が必ずしもあたるとは限りません。"
]
}
}
{
"D2-C2A-Q11-P01": {
"ProductID": "D2-C2A-Q11-P01",
"ShopID": "D2-C2A-Q11",
"ProductName": "どら焼きの皮",
"Price": 200,
"MaxSelect": 3,
"Image": "D2-C2A-Q11-P01.png"
},
"D2-C2A-Q11-P02": {
"ProductID": "D2-C2A-Q11-P02",
"ShopID": "D2-C2A-Q11",
"ProductName": "メロンパンの皮",
"Price": 200,
"MaxSelect": 3,
"Image": "D2-C2A-Q11-P02.png"
}
}
Stage
▼リリースしたもの
これは模擬店展示のものをコピーしてきた。それ以外に書くことはない。 なんか謎に表示順変えてとかいう依頼があったけど、そのまま無視してたっけ。 It's SHOW TIME!の有志ステージの順番があると良かったってアンケートに書いてあって確かにとは思った。ただ、直前になるまで出演順情報を知らなかったからなんもできなかったのも現状。{
"D1-1020-A01-JZ": {
"StageID": "D1-1020-A01-JZ",
"PlaceID": null,
"Day": "Day1",
"Time": "10:20",
"GroupName": "YAMINOKAO",
"Thumbnail": "D1-1020-A01-JZ.png",
"Comment": "YAMINOKAOは吹奏楽部の一部の人によって構成させるジャズバンド!…",
"SetList": [
{
"Title": "Take Five",
"Composer": "PAUL DESMOND"
},{
"Title": "That warm feeling",
"Composer": "SAMMY NESTICO"
},{
"Title": "bildland",
"Composer": "Josef Zawinul"
},{
"Title": "Johnson Rag",
"Composer": "Glenn Miller"
},{
"Title": "Paradise Has No Border",
"Composer": "NARGO"
}
]
}
}
Schedule
▼リリースしたもの
他のページと同様に日にちを切り替えられる機能がある。
当初は、Day1-3までだったけど、準備日の必要性があってDay0を追加した。
内ステと外ステと模擬店に分けてタイムスケジュールにしてる。
現在時間を組み込む機能がついてたんだけど、日にちの設定がバグってたのか機能してなかった。
HTMLの要素で描画するには、位置を計算して値をぶっこむのが必要があって、SVGで描画するにしても角丸にするのが複雑で、結局JSとの相性も考えてCanvasに描画してた。
ただその結果、要素の大きさとか考慮させる処理をつけなかったから「CSS完全に理解した」状態になってる。
Dayごとにその日の表示になるようにデフォルト状態をずらしてた。(つまり手動)
アクセス解析
ウェブアプリの各ページの表示回数の合計は6万3248回だった。
食券販売と香陵祭前後のときに多くアクセスされた。
逆にテスト期間中は、運営側の更新もほぼなかったから少なくなっている。
食券販売の影響で、DTへのアクセスが多く、 次いでSchedule、NewsIndividual、MATSURIの順で表示回数が多かった。
反省改善点
- 利便性を考えたら外部に公開してもいいかも
- マップの機能をつけて現在地とか模擬店情報と連携してもいいかも
- もう少し最初からページ内リンクの機能を付けておいた方が良かったかも
- 管理者の権限を係長全体に付与して、よりリアルタイムに情報を配信できても良かった
- 位置情報とかBLEビーコンとか使って混雑情報取得しても良いかも(ただそんなもの必要ないぐらい当日混雑してた)
- 音楽フェスとか大学祭のアプリの機能とかデザインを参考にしても良いかも
- 大学祭みたいに外部公開しておいて事前に名前とか入力しておけば、一般公開のときにスムーズに学校に入れるようにしても良いかも
4.食券デジタル購入
作った理由
作った理由はいくつかあるけど、ざっくりまとめるとこんな感じ。
今までの課題
- 導入以前の食券販売はむちゃくちゃ混雑してた
- 購入者の把握に問題があった
- 複数商品買う際に店の行き来がありそれでより混雑していた
- 混雑により買いたくても買えない商品があった
得られる効果
- 混雑緩和
- 複数店にまたがるまとめ買いができる
- リアルタイムで購入数が確認できる
- 食券印刷時の手間がいくらか減る(
本当に減ったのか?個人的には疑問) - 副効果というか,食券購入したい!→ウェブアプリを登録する必要がある→公式LINEを登録する必要があるってことで登録者数が大きく増えた
- 沼東と香陵祭のDX化促進
- 何よりも楽しい
歴史
草案
第75回の企画系の話し合いのときに食券デジタル化できたら良いよねーって声があった。
ただ、誰がどうやってやるん?的な問題でその年は成し得なかった。
ちなみに、この時に自分が公式HP作ってたからその時にフロントエンドの知識が身についた。
1回目の作成
第75回香陵祭が終わって、草案のことがあったなーって思って夏休みに開発してた。
ただ、商品写真あった方が良いよねーとか情報量が多すぎて微妙だよねーとかいろいろ改善点があったから没に。(はっきり言ってダサい)
商品名とか金額とか表示項目が多いんよね。
ちなみにこの時からのプラスマイナスのデザインはそのまま。
2回目の作成
だいぶ現行のものに近づいた。
いろんなサイト(特にEC系)を参考にデザインを作った。
かなり星のコーヒー屋さんのデザインにインスパイアされてる気がする
いろんなものを比較検討してこーゆーデザインになった
デザインのコンセプトはSimple is best。この時には決まってなかったけどデザイン的にはロゴの相性が良かった。
(ちなみにロゴは祭典委員長作)
3回目の作成
デザインはそのまま。
こーゆー感じになるよーって見本にするために、機能的な実装を主にしてた。
この時のコードと機能が一番高度かつ複雑。
というのは、食券の選択と支払いを同時にするつもりだったからリアルタイムで管理者と生徒が通信できるようにしてたから。
ちなみに、ウェブアプリでLIFF使ってやろうって考え始めたのがここから。
ウェブアプリのメイン機能としてデジタル食券をやろうとしてた。(この時はそれ以外の機能は皆無)
4回目の作成
これが最終形態。リリースしたやつ。
模擬店担当で同中だったゆーたと文化祭祭典委員長のおーちたちといらない機能の削減とか追加とかいろいろ協議して決定した。
協議した結果、選択と支払いは別日で、選択できるのは一回のみで選択期間は二日間って決まった。
デジタル食券の機能に加えて、PDFとかスケジュールを見れるようにしたりとか利便性を高めるために機能とコンテンツをむちゃくちゃ加えた。
欲しいページにアクセスしやすく出来るように少し狙ってる。
▼作成したページたち
利用方法
Step.0 ウェブアプリの登録
▼認証画面
食券購入するためには、ウェブアプリと公式LINEへの登録が必要。 公式LINEの登録方法についてはご存知だと思うので割愛。 ウェブアプリの初回アクセス時に、「このLIFF使うけど良いよね?」的な画面が出るから〈許可する〉をタップする。 ウェブアプリ本体の登録では、校内の生徒であることを確認するためにHRNOと名前、認証キーの入力が求められる。 HRNOが被ってるとダメだよって言われる(誤登録した人のデータは手動で書き換えてた) 認証キーは各クラスごとに異なってて、前に入力したHRNOのHRのものと一致しないといけない。 ▼各クラスに掲示した認証キーのプリント
ちなみに、生徒情報が丸々入ったExcelデータがあるから、登録情報とそのデータを(pythonでちゃちゃっと)比較して誤登録者と未登録者を見つけてた。
Step.1に行く前に
食券を選ぶ上での注意点を事細かく書いておいたページ(≒利用規約)。
まーどーせ見ないよなーとか思いつつあんま目立たないデザインにしてたらかなりの人が見てなかったと思われる。反省。(選択前のページだから必ず見てるはずだけど、"よく見た"わけじゃない)
▼説明用のページ
▼利用規約の要約
- 商品あたりの選択できる数には制限がある(だいたい3個)
- みんなにあげたいから最大3000円まで
- 払える金額で選ぶ
- 一人一回しか選べないし選び直し効かないから気をつけて【ここ重要】
- 先着順だから売り切れたらすまん
- 支払い方法は現金のみ(できるだけぴったり)
- WAで確認できるけど紙食券がメイン
- 譲渡、代理していいから必ず引き換える
- 紛失しても再発行はしない
〈食券選択へ〉で選択ページに行ける。
選択期間外はその部分が〈時間外のため選択不可〉になる。
管理パネルの方でそれを弄れる。
Step.1 食券の選択
選ぶ上でのルールは利用規約の通り。
〈+〉で追加、〈-〉で減らして選択する。
上限に行くと〈+〉をタップしても何も起こらない。
3000円を超えるとダメだよって言われる。(家族に買いたい?って人はもっと買いたかったみたい。当日買え)
画面下部に合計金額が表示されてて〈+〉〈-〉押すごとに更新される。
誰かが購入した時に売り切れデータを書き換えてほぼリアルタイム(ポーリング)で選択画面の表示を売り切れにしてた。
▼選択ページ
とあるクラスが直前まで商品を変えて煩わせてたのは内緒
商品画像に関しては、模擬店団体の企画書の仕入れ先のHPからあるものをDLして色々加工(透過したり色調補正したり)して自作してた。
本当は全部画像入れたかったけど、そもそもサイトがなかったりリンク切れしてて収集不可なところがあったからそこはNoImageにしておいた。
並び替えとかカテゴリで絞り込みとかつけたかったけど、それには実装時間が足りなかった。
Step.2 注文の確認
選択したものをリストで表示したページ。
特にそれ以外の機能はない。
ECサイト的にこーゆー確認用のページが必要。
ECサイトとかでやらないといけないことは消費者庁の資料によくまとまってる。(本当はアレルギー表示した方が良い)
▼確認ページ
ちなみに、このページが最終画面と思った人がいたらしい。(え、分からんのか?これ)
反省としては、このページで「まだ食券選択は終わっていません」とか「これが最終確認となりますがよろしいですか?」とかポップアップを出した方が良かったかも。
Step.3 食券選択完了
今まではここに整理IDを表示してたけど、某係長のご意向で学年とHRNOの表示に変更した。
ちなみに丸の色は学年ごと色が違う。
選択した食券の一覧は確認ページの使い回し。
たくさん買った人は死ぬほどズラーって表示されてたみたい。
▼提示用ページ
このページは食券引換の時も表示させてた。
ここに食券引換時の館内図とかも表示させてた。(最終日になるにつれて告知とか金銭やり取りの効率化のおかげでどんどん終了が早くなった)
(なんだこのタバコの注意書きみたいなダサいデザインは)
終わった瞬間にアンケートを表示しても良いかも。
購入情報の分析結果
購入情報のマーケティング的な話と分析見た自分の感想を書き留めとく。
ここまで詳しく分析をしてるのは後になってからだけど、模擬店の担当者にすぐに状況を伝えられるように管理コンソールにアナリティクスを設けてた。
ご飯食べながらリアタイで分析見てたけど、ものの数十分で30万とかいってびっくりした。
最終的にほぼ100万ぐらいのお金が動いたみたい。
正確には売上合計金額が96万9260円で、購入者数が614人、購入枚数が4614枚売り上げた。
時間帯で言うと選択日の昼休みはいくつか会議とか長縄の練習とか重なってて忙しかった人も多かったけどかなりここでのびた。
ちょこちょこ授業中にやってね?みたいな時間に選択した人もいたけど、昼休みやった人につられて放課後に選んだ人が多くてそこでずるずると増えていった感じ。
2日目に選択した人はあまりいなかったから別に1日目で終わらせても良かったかもしれない。
選び直しを許してたらもう少し伸びたかもしれない。
公式LINEを公開したのが4月26日の夜で、公式LINEの登録者数はそこで300人ぐらい増えたんだけど、WAの登録は教室に掲示した認証キーが必要だったから翌朝からWAの登録者が出た感じ。
沼東生といえど性悪説で、基本的に運営が呼びかけても義務付けても生徒全員がやってくれることは少なくて今までの公式LINEは登録者数600人ぐらいだったんだけど、今回はWA登録者だけでも生徒の9割が登録してくれてて食券販売をWA上でやった効果はあったんじゃないかなと思う。
ちなみに選択開始したのが2023-05-01 12:32:52で、選択終了したのが2023-05-02 22:00:19。
ちなみに、何か問題があった時に困るから選択開始と終了は完全手動制御にしてた。(別に技術的にできなかった訳じゃないもん!何なら手動の方が処理だるい)
全体的な購入情報(個人が特定されない程度の)分析をすると、購入金額とユーザー数の関係はこんな感じ。
3000円で上限にしてたけどもう少し上限が上でも良かったかもしれない。
制限が上過ぎたり無制限だと、ネタで選んでキャンセルしてくるやつが出てくると思うからその辺の見極めは必要かもしれない。
1000円〜2000円が多いとこ。平均は1578円。
ちなみに3000円ぴったし選んだのは6人だけだけど、ギリギリを攻めた人が結構多かったみたい。
購入枚数のこのグラフを最初に見た時に綺麗な正規分布で感動したのを覚えてる。
一人一回とは知らずにセーブ感覚で注文確定した人もいるけど、たくさん頼む人もいれば欲しい数個だけ頼む人もいて人には人の考え方とか価値観があるんだなぁって思った。
購入の流れとしては①WA開く②説明文読む③選択する④確認する⑤選択完了って感じで、これは③選択開始してから⑤選択完了するまでの時間を計測したもの。結構選び直ししてる人(リロード)もいたみたいだけど、最終的に選んだ時の計測時間が適用されてる。
だから、短くなってる人は何回か選び直してて最終的なのを作業的にやってる人もいるかもしれない。
昼休みに選んだ人が多かったからその影響もあるかもしれない。
人によって時間はまちまちなんだなぁと言うところ。
グラフの下に表示されてるIDは、管理上の模擬店のIDで日にち-場所-団体で割り振ったもの。
一般生徒の方にIDが見えることはないけど食券の裏側の方では全部これで管理してた。
模擬店IDには、場所と日にちとカテゴリとコメントと商品のリストとかのデータが紐づいてる。
▼模擬店ID早見表
模擬店ID | 団体 | 場所 | 概要 |
---|---|---|---|
D2-C2A-Q11 | 旧11HR | 特A教室 | 猫カフェ |
D1-C25-Q12 | 旧12HR | 25HR | お菓子 |
D1-C24-Q13 | 旧13HR | 24HR | お団子 |
D2-C15-Q14 | 旧14HR | 15HR | トゥンカロン |
D2-C25-Q15 | 旧15HR | 25HR | チュロス |
D1-C26-Q16 | 旧16HR | 26HR | パン |
D1-C33-Q18 | 旧18HR | 33HR | パンナコッタ |
D2-C26-Q22 | 旧22HR | 26HR | パン |
D2-C23-Q23 | 旧23HR | 23HR | ケーキ |
D1-C2A-Q24 | 旧24HR | 特A教室 | ポップコーン |
D2-C27-Q27 | 旧27HR | 27HR | シューアイス |
D2-C24-CBD | 女バド | 24HR | ドーナツ |
D1-C28-CND | 野点 | 28HR | 茶菓子 |
商品IDは模擬店IDに連番がくっついたもの。
多い順に並べるとパン>パン>ドーナツ>トゥンカロン>チュロスという感じ。
パンはちゃんと飯になるから食料確保的な動きで人気が出たのかな。
分かりにくいと思うけどバブルチャートは数値しか軸の値を取れないからこーゆー形式になってる。
横軸が商品でID順に75商品並べたもの。縦軸が時間で下から上に向かって5分ずつの間隔で時間が経過して数字が増えてる。5/1の12:00から5/2の24:00までのデータ。
赤い丸は売り切れた時の目印。
円がでかかったり密度が濃いと人気度がわかる。
原価率が低いと高い印象になって割と売れてない感じがする。
HRを省略してプロットしてる。
こうやって見ると3年ってあんま買ってないよねーてとこ。購入者数が少ないからそれに比例してる。
ちなみに40ってなってるのは文化祭企画で買い取った分。文化祭企画でスタンプラリーとかの景品で使ったらしい。そこそこ人気だった。
これは学年別の購入者数の推移。なんかラベル表示してくんなかった。
一日目の昼に選択したのが多かったのは2年で、長縄練習だった1年は少なめに感じる。
その後授業で一旦下がって、部活前に選択した人でぐっと伸びた。
その後ずるずると選択した人が増えていって、就寝時間に突入。沼東生寝る時間結構遅い。
二日目の朝に選択した人も多かった。
授業の合間を縫って選んだ人もすこーしいた。
そろそろ終わっちゃうよーって公式LINEで呼びかけるとちょっと増えた。いろんなSNSとか手段を総合的に効果的に使っていくのが正解だと思われる。
アンケート結果と改善点
選択直後と引換直後にアンケートを実施してこのやり方についてのユーザーの反応を調査しました。
ざっくりまとめると、すごく良かった!だけどDay1/2の切り替えができたりもう一回選べたら良かったというところ。
運営的にはお金のやり取りがスムーズにできるとなお良し。
今回は責任問題とかで結局PayPay導入出来なかったけど、使いたい人はいるみたい。
ちなみに、アンケートの選択肢は運営側(自分)が考えたものだけだから別の意見もあるかもしれない。
来年以降の為のフィードバックと思ってもらえれば良いかな。
総合評価
基本的には4か5でとても嬉しい。
情弱スマホを持っていない人とかの対応がしっかり出来てなかったから一部の層に低い評価がついた感じ。
やや右な人もといった感じ。
買いたいものが買えたか
半分ぐらいの人が問題なく買えたとさ。
後半に選択した人は売り切れ表示がいくつかあって買いたいものが買えなかったっぽい。
3000円以上買いたい人とか一人一回って知らなかった人もちょこちょこいたみたい。
ちなみに、選択期間の途中アクセス数がかなりあって鯖が少しやられたのか動作が不安定になってたみたい。
504とかじゃないから鯖落ちしてたわけじゃないけど通信ができてない感じだった。
よく分からずバグって知らないうちに解決してた。
何で知ったか
公式LINEとかクラスLINEにWA上でやるから早めに登録しとけよーってちょこちょこ言っておいたからわりと効いたみたい。
公式LINEの影響力大きいんだね。
選択前後で知った人はこのアンケートは自主的に回答してくれてる人が多いからこうゆう結果だけど、実際はその割合が大きいと思う。
WAでやったのは良かったか
だいたいそんなもんよね。うん。一定の割合でアンチって存在するからね。
何がわかりにくかったか
何も説明しなくても見ればやり方がわかることがUIUX的な目標だからある程度それは達成されてる感じはする。
WA開く->〈食券デジタル購入〉をタップ->説明文読む->〈食券選択へ〉->食券選択
って流れだったからステップ数多くなってしまったのは反省。導線長いよね。
リッチメニューにその項目作って前半部分をショートカットできるようにした方が良かったかも。
WAの登録方法については若干時間がかかるから事前登録じゃなくて直前に登録した人にとっては煩わしかったかもしれない。
選択方法のチュートリアルを作って掲示してた方が良かったかもしれない。
商品写真について
前にも書いたけど、そもそも写真がないものはNoImageにするしかなかったので全ての写真を用意できなかったのはご自愛ください。
模擬店担当者がネット使って東京本社の会社に注文してる時は大抵写真あるけど、沼津の町のパン屋さんにそんなもんはない。
来年は模擬店担当に写真撮りに行かせても良いかもしれない。
トゥンカロンって何!んーわかんなくてググる。ってことを自分はした。
担当の先生も「え何これー。トゥンカロンとかパンナコッタとか俺知らないんだけどー」的な事を言ってた。(直前の最終確認でやってもいーよねって聞いて商品見た時の反応)
写真見てこれ旨そうって言ってる人も多かった。
逆も然り。(背景ピンクに抹茶チュロスは流石に合わん)
だから、まあ視覚が伝える情報って大きいってこと。出来るだけ写真はあったほうが良いよねというところです。
参考、写真あり=29/75商品
選択画面のデザイン
だいたいの人が綺麗で分かりやすいと回答してくれた。モチベ上がる。
3カラムのが良いって意見もあったけど、実験してみた時にスマホだと2つが限界な気がする。他のサービスもだいたい2カラム。
日にちの部分の表示をでかくしてくれという意見も多かった。たぶんこれにはDay1/2の切り替え機能をつけてくれ的な意見も含んでる気がする。
日付と販売団体と概要はどうせいらんだろって見切りをつけて小さめに表示してたけど、日にちは大切よね。盲点。目悪い人多いもんね。すまん。
値段設定
ちょうどいいっていう人が一番多かった。
その次に多いのが高めって意見。当日販売も爆死してたとこあったけど。
まあ、黒字に持ってくには多少の付加価値はしゃーないのかな。本当に?
安いって言った人がいるのは驚き。
3000円の購入制限
特に問題はなさそう。分析のところ見ても思ったけど大半は1000〜2000円だからそこまでたくさん買う人はいないもんね。
ちなみに、3000円ぐらいで制限設けようって言ったのは自分で決まったのは選択日の前々日。全部選ぶと最大4万円ぐらいに確かなる。
2日間の選択期間
これは結構割れた。2日目あんまいなかったし早期確定を求めるんなら1日だけでもいんじゃないかなって思う。
ただ、もっとあった方が期間長くて焦んなくて良いとも思う。逆に長すぎるといつの間にか終わってたけどまーいっかってなって公式LINEの登録者数減りそう。
一人一回の選択回数
まあ、一人一回だけってなると心理的にきついよね。悪いって言われるならそこだよなって自覚はある。
期間内ならいくらでも選び直し可能だと、売り切れの処理が結構複雑になりそうだしそのルール設定で良いのか判断するのも難しそう。
追加注文なら前のデータに書き足すだけだからやっても良いかもしれない。
ユーザーが悪いとか運営が悪いとか別にしてどんなやり方にしろ何かしら問題は発生すると思う。
この形式の継続について
この形式に定評があって尚且つさらに進化させた形式にも期待がかかってるようには思えた。
(形式について後の方にまとめてあるから参考に)
だけど、少数派のことも考えてやってく必要はあるかもしれない。
少数派対応は、ユーザーと少数派の同意のもとで代理購入する機能をつけると良いかもしれない。
決済手段に関しても割と使いたい人はいるみたい。
PayPay導入に関しては第76回の準備委員会設立当初は結構ホットに議論されてて、やりたいって勢力が大きかった。
まあ、ただやると考えた時にPayPay側に取られる3%どうするかとか、一般の人に事故が発生したら責任どうするとか色々問題があった。
先生側もあれこれ意見はあったっけど、大人どんどん使って良いからやっても良いよ的な風潮はあった。
ただ、結局生徒側が諦める感じでやらない事が決定した。
電子決済導入した文化祭は手で数えるぐらいしかない(※当時)からそれが沼東でとなると夢ではある。
またデジタルで食券販売やる場合のオプション設定
反省と改善点を踏まえて自分がもしもう一回やる場合のオプション設定。
- 販売回数(1回のみor2回以上or再販あり)
- 期間内の在庫変更(ありorなしor無制限)
- 選択方式(1人につき1回だけor追加注文可能or期限内ならいくらでも変更可能)
- 在庫超えたとき(超えないように先着順or抽選)
- 再販時の販売数引継(毎回設定or引継可能)
- 絞り込み機能(なしor日にち切り替えorカテゴリ属性絞込)
- 商品写真(すべてなしor用意できるもののみorすべて)
- 在庫数表示(表示なしor残りわずかなど段階表示or数字表示)
- 購入者属性別絞込(なしor属性で選択日を変更or選択可能商品を変更or選択上限を変更)
- 上限金額(制限なしor制限つき)
- 支払い方法(現金取引orQR系決済導入orすべての決済手段を取り揃えた決済仲介業者の導入)
- 食券使用方法(紙食券利用orユーザー操作型デジタル食券or特権付与の管理者制御型デジタル食券orQRコード提示型デジタル食券)
- デジタル化時の食券譲渡(認めないor申し出で所持者変更orユーザー間の同意で所持者変更する機能or別の人に送りつける機能)
- デジタル化時の外部への食券譲渡(認めないorアプリ等公開して送りつける機能)
- デジタル化時の鯖または回線事故対応(購入者リストからアナログ対応or購入時にLINEに証拠用の購入情報を送りつけるor一応紙も配っとく)
- デジタル化時の外部対応(認めないor公開し内部からの譲渡のみ可能or内部外部問わず譲渡のみ可能or来ることが確定してれば購入可能)
- デジタル化時の食券譲渡(与える1回のみ可能or与えられた人に返すことは可能or誰でも何回でも可能)
- デジタル化時の詐称スクショ対策(操作可能かor管理者制御型or現在時間やアニメーションの描画or使用時の特殊的な操作やアニメーションor顔認証)
- デジタル化時のアナログ対応(無視するor申し出で祭典委員会側で代理購入or代理購入用の機能をつけるorWeb版作ってiPadで購入)
- 模擬店側への情報共有(代表者グループを通じてorみんなが見れる管理パネルor模擬店ごとの管理パネル)
- プラットフォーム(公式LINEに付随したミニアプリorアプリorPWAorWEB)
最後に
伝えたいことの要約
- "ユーザー"にとって便利になるように作るべき
- ユーザーの行動は"ある程度"予測できるし動かせる
- ユーザーを思い通りに動かすには様々な手段と方法を総合的に効果的に使うべき
- ユーザーに"お願い"するよりも"自発的"に利用させる工夫が必要
- 非協力的な人にこだわらない方が良い
とか、ずるずると書いたけど【睡眠が一番大事】なんで寝ましょう