Go to Qiita Advent Calendar 2024 Top
LoginSignup
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tari3210

GBBINFO-JPNの設計図

Last updated at Posted at 2024-08-30

2021年から運用しているWebサイト「GBBINFO-JPN」について、最近他人に説明する機会が増えたので、目的や歴史、設計思想を書き起こしてみた。

想定読者はエンジニアの方。

採用担当の方へ

ご覧いただきありがとうございます。

  • GBBINFO-JPNの利用者20万人(2024年9月現在)のうち、8割がスマホからのアクセスです。GBBINFO-JPNにアクセスする際は、是非スマホか、PCブラウザのレスポンシブモードをご利用ください
  • レスポンシブモードをご利用いただける場合は、解像度設定を 375×667 にしてください
  • 詳しい仕様は「設計思想」の項目以下に書いてあります
    ぜひ「設計思想」の項目をご覧ください

Beatboxファンの人は何言ってるかわからない部分が多いと思う。sry

GBBINFO-JPNとは

GBBINFO-JPNは、Human Beatbox 世界大会 "Grand Beatbox Battle" の非公式情報サイト を名乗っている。
Beatboxってなんだ？と思ったら HIKAKIN でググってください。ブンブンハローYouTube

Grand Beatbox Battle 略してGBBは、Swissbeatboxっていう会社(団体？)が毎年開いているHuman Beatbox 世界大会。
GBBといえば、多分この動画を見聞きしたことある人が多いと思う。

確か2018年に10周年だぜウェーイって言って盛大にやってた気がするから、まだまだ歴史は浅い。

GBBINFO-JPNができるまで

Grand Beatbox Battle公式サイトは、なんと2024年1月まで存在しなかった1。
その代わり、ほぼすべての情報をInstagramでばら撒くもんだから、後から検索できないし、めちゃくちゃ分かりにくい。
一企業が開いているイベントとして、Webサイトすら持っていないというのはいかがなものかとは思うが...

2021年ポーランドで開催されたGBB 2021を筆者は見に行ったが、Webサイトがないので最新情報の入手にはめちゃくちゃ苦労した。その経験から、次のGBBまでにはこの状況を何とかしたいという思いで、ポーランドから帰国後1週間、文字通り朝起きてから夜寝るまで、 ひたすらGBBINFO-JPNの制作に明け暮れた。2日で大まかな形ができて、公開に踏み切った。

帰国後隔離期間でひまだったから、ちょうどよかった。

運用方針

1. 最初期 2021年10月

おかねないので無料サービス縛りという制約下での開発になった。

まず最初は、Webサイト作成サービス「JIMDO」を利用して作った。
無料サービスのなかで一番機能が充実しており、少しだけなら自作CSS, Javascriptを書けた。

当時からプログラミングの勉強はある程度していたが、Pythonだけでフロントエンドはほぼ何もしたことなかったし、自分の性格的に、一から勉強なんてしていたら途中で飽きる。
ノーコード開発は拡張性に欠ける、というデメリットは頭の片隅にあったものの、そうするしかなかった。

初期の目的は、主に2つ。

  1. GBB 2021 ポーランド現地にまで行った経験を、記憶があるうちに、形に残すこと
    日本からは3名 (+出場者) しか行っていない、この経験を無駄にしたくなかった。自分にとって初めての、自分で計画した海外旅行だったし。
  2. GBB 2022 最新情報をまとめておく、データベースを作ること
    要するに、GBB運営のマーケティングがあまりにも酷すぎるので、自分で勝手にやろうとしていた。なお、GBB 2022は中止になったので、この目的の達成はGBB 2023まで待つことになる。

現在では、このうち後者のみが運用方針として残っている。GBBが2023年から史上初・東京開催になり、 前者はもはや不要になってしまったため。
現在まで残っている「GBB 現地観戦計画のたてかた」は、初期の運用方針の名残。

つまり、本来公式サイトがやるべきことを全部やってしまおう、という考え。
公式乗っ取り計画だ。

2. 2022年11月~2024年6月

前述の通り、GBB 2022は中止になってしまったので、11月まで何もやることがなかった。

  • 2022年11月 GBB 2023 ルール発表
  • 2022年11~12月 チケット販売 (1分以内に完売)
  • 2023年2~3月 出場者発表
  • その後 複数の出場者辞退 & 予選下位の繰り上げ出場発生

話は飛んで2023年。
上記の出来事を経て、編集を進めるにつれ、ユーザーの求めるもの、ユーザーにとって使いやすいデザインなどのノウハウがある程度わかってきた。

以下の内容は、その中でもほんの一部。

ある程度長文でもみんな読む
文が長いほど滞在時間が伸びている。
これはただ単に、あまりにもみんな最新情報に飢えすぎて、少しくらい分かりづらい文でも必死に読み解こうとしているだけだと思われる。

ただし、長文ページは、時期によって平均滞在時間が変化する
閲覧者数と滞在時間にある程度相関関係が見られた。
これは、需要が低い期間、つまり注目度が低い期間は、長文ページの情報のうち、一部の情報をかいつまんでいく人がいると考えている。筆者自身もそういう使い方をしている。
需要が増えると、すべての情報を求める人が出てくる。そういう人は長く滞在する。

需要が高いコンテンツはそう多くない
イベントを一度開くと、参加者、視聴者に伝えなければいけない情報は多岐にわたる。そのため、様々な情報をどう整理し、アクセスしやすくするかが課題だと思っていた。
しかし、GBBの場合、みんなが欲しがる情報は 「出場者(特に日本代表)」「出場者発表日」「チケット」 の3つだけである。ほかの需要は意外と低い。

運営の発表タイミングより早く情報を求める人が多い
これは運営の発表が遅いだけ。
例えば、GBB 2023のタイムテーブルが出てきたのは、なんと本番1週間前。遅いなんてもんじゃない。GBB当日の行動計画をなかなか立てられず、本当に迷惑した。
無い情報を「無い」と伝える必要が出てきた。

ノウハウがだんだんわかってきたから、次は 「選択と集中」 を行うべきと考えた。
初期の運用方針は維持しつつ、運用コストを下げ、かつ質を上げることができるようになってきた。

3. 2024年6月 大規模アプデ

2024年になって、運よく学生エンジニアとしてプログラミングのバイトをゲット。そこで、自分の作ったプログラムを実行するためのWebサイトを作り、「あれ？俺意外とフロントエンドいける？」と思い始める。

2024年5月から少しずつGBBINFO-JPNの移行作業に取り掛かる。Webサイト作成サービス「JIMDO」にはexport機能がなく、一からフロントエンドを作らざるを得なかった。
とはいえ、移行前のUIは、改善を重ね、ある程度満足のいくものになっていたので、ほぼそのまま再現した。
CSS完全に理解した（してない）

PaaSはRenderを採用。あくまで無料での運用を維持する姿勢は変えなかった。
Renderの良いところはデプロイが簡単で、運用しやすいこと。あとサポートのレスポンスも早い。
無料URLで.comをもらえるのも良い。

バックエンドはflask、フロントエンドは普通にHTML, CSS, JSを採用。
大学生になってからずっとPythonであそんでたので、flaskが自分にとって一番扱いやすかった。
バイト先ではtailwind cssを使っているが、いまいち恩恵がわからないので現状は採用を見送っている。

また、出場者をCSVで管理している。データベース作っても良かったけど、お金かかるし、せいぜい40名くらいしか名前がないのでCSVでいいやという考え。pandasで取り出して表示している。

自作コードによる運営で、何よりもうれしかったのは、JIMDOではできなかった複雑なUI、動的処理ができるようになったこと。

これまでの、すべてのページを人力で書くという骨の折れる作業からやっと解放された。
また、拡張性を考えた設計 ができるようになったので、思いつきで新機能を実装することが増えた。
ふと頭に浮かんだアイデアって意外と大事 なんだなとつくづく思う。

※思いつきとは言いつつ設計はちゃんと考えている。

ちなみにこれまでの静的管理のせいで、出場者名を間違えるという失礼なミスをしてしまったことがある。ごめんなさい

4. 2024年11月 外国語対応

エンジニアとしての実績アピールとしてGBBINFO-JPNを使う機会が増えてきたため、GBBINFO-JPNを技術的に高度な機能実装の練習場として活用することにした。ただ機能強化も煮詰まってきたので、次のステップとして英語を含めた外国語対応の基盤を固めることにした。

技術スタックは、ReactやVue.jsなど新しいjsフレームワークの導入を検討したものの、いろいろ悩んだ末にflask-babelを採用。順当に現状の技術スタックにあったものを選ぶことにした。ただReactの勉強もしたいので将来的にどうにかして導入したいな。

翻訳は原則ChatGPTにやらせた。いやーラクっすわ。

まずは2024年・2025年に対して翻訳ファイル messages.mo を完備。ページ内上部・下部のあまり目立たない場所に言語切り替えボタンを設置。なお、ボタンを押したら、その時点で見ていたページにリダイレクトされるため、ユーザーがわざわざトップへ戻されることは無い。

GBBINFO-JPNのユーザーはほとんどが日本からのアクセスだが、本来GBBは国際大会。
国際化という難しい作業を練習するには最適な場である。
Flaskを採用したおかげで、翻訳ファイルさえあれば簡単に実装できた。また、今後英語以外の言語実装も視野に入れられる。

ただ翻訳にあたって、日本語と外国語で語順が変わることを考慮し、文章構成を多少変更せざるを得なかった。これがめちゃくちゃ骨の折れる作業だった。

外国語対応アップデートにより、海外からのアクセスも考えた運用を行うようになった。
また、今後は、自分自身が エンジニアとしてのキャリアを積むための勉強、実績を積む場 としてこのサイトを使うことにした。

設計思想

おさらい
前述の通り、2024年6月まではJIMDOによるノーコード開発、6月からRenderで運用するコード開発に移行した。
GBBは、2021年までポーランド開催だったが、2023年から史上初・東京開催となった。2024年は11月1~3日 東京開催予定。

全体設計

Webサイトを作るうえでは当然考えるべき、「見やすくて、わかりやすい設計」
そのためにまず、フォントや色、ボタンなどの各種要素設計にこだわった。

フォント
JIMDOで制作していた当初から、フォント選びは迷走していた。どれもしっくりこなかった。
航空会社のサイト、遊園地（ディズニー、USJ）、note.com、デジタル庁、その他閲覧数が多そうなWebサイトをいろいろ見て回った結果、安定のNoto sans JPに落ち着いた。
そもそも日本語フォント、選択肢が少なすぎる。

色
note.comが採用している #222222 を採用。真っ黒はあまり良くないというのはなんとなくわかっていたので、良い塩梅の色を探していたが、どっかのサイトにおすすめカラーとしてこれが掲載されていた気がする。
note.comもいろいろ考え抜いた末での設計らしいので、素直に従うことにした。

背景
背景画像は、筆者自身がGBB 2021で撮影した写真を採用している。この写真には愛着がある。様々な事情で、もう二度と見られないBeatboxerがたくさん映っている。
すると今度は文字が見にくくなるという問題が生まれるので、背景写真がちゃんと見えるギリギリの透明度を狙って白 #FFFFFF の背景色を敷いてある。ここの透明度は悩みの種の一つ。現状70%。

題名 (h2)
マレーシア航空公式サイトを参考に、画面上に常に題名と、画面の位置(どれくらいスクロールしたか)を表示している。また、画面の上部に固定されている題名をクリックすることで、題名一覧を表示できる。もちろんどれかを選択すればそこまで移動できる。
ある日マレーシア航空公式サイトを見て、良いなと思い導入した。

表
表デザインのテンプレをググって、直感で良いと思ったやつを採用。
線を控えめに、背景色で境界を明確に。縦線はひかない。掲載している情報の性質上、ほとんどの場合縦線は要らない。
表はJIMDOから移行する際に大きく変更した。今までのデザインが気にいってなかった。
JIMDOの制約から解放された要素の一つ。

リンク・ボタン
文字色は #0044CC を採用。実はこれ、Microsoftが実験して見つけた「ユーザーが一番クリックしてくれる色」らしい。色をちょっと変えるだけでクリック率が大きく変わるとか。
リンクの色は各種Webサイトで意見が分かれているらしいが、この色を気に入ったから、今後もこれでいいかなと思っている。
ただ、これだけガイドのみ唯一、ボタンが8個も並んでいる。これらすべてが同じ色だと見づらいので、複数のボタンが並ぶ場合、偶数個目のみ #1b94e0 を採用。これはTwitterのリンクカラーであり、かつ #0044CC と十分に見分けがつく色と判断して導入。

ヘッダー・フッター
GBBINFO-JPN開設当初、知り合い（確かlalaさん）からもらったフィードバックとして 「1ページ読み切ったら、その後ほかのページに行けない。ブラウザの戻るボタンを使わなければいけなくなる」 と言われた。当時まだデザインのノウハウが全然なかったので、今考えるとありがたいフィードバックだなと思う。lalaさんありがとうございます。
そこからどうサイト内を回遊してもらうかを考えるようになった。それに対するアンサーとして、FC東京のホームページを参考に、ヘッダーを常に表示することを思いついた。
これもJIMDOではできなかった。

なお現在はヘッダーを取りやめて、フッターとしてスマホアプリのような見た目に仕上げている。

JIMDOから移行して、これまで 思いついたけど実装できなかったアイデア を一気に実装できた。
デザイン工学に基づいた、使いやすい設計にはこだわったが、芸術性の観点ではこだわっていない。これは、最低限のリソースによる応答速度向上 を図ったため。

実際、青森在住・下り速度 0.01Mbps のSoftbank Airユーザーからも好評。

想定ユーザー

GBBINFO-JPNは、ある程度Beatbox、特にGBBに興味があるユーザーを想定している。
また、これまでの統計により、全ユーザーのうち8割がスマホからのアクセス、9割が解像度 375×667 以上の端末でアクセスである。

そのため、GBBINFO-JPNのUIは、 375×667 で、改行や表示がある程度問題なく行えることを確認している。

すべての解像度に対応できるレスポンシブデザインを採用しているため、この解像度をもって、ほぼすべてのユーザーに対応できると考えている。

階層構造

GBBINFO-JPNの階層構造は以下の通り。

.
└── 年度(2023~)
    ├── top
    ├── rule
    ├── participants
    └── ... (other contents)
└── others
    └── ... (other contents)

ルートディレクトリにアクセスすると自動で最新年度にリダイレクトされる。そのため「ホームページ」が存在せず、各年度ごとにホームページ（これだけガイド）を持つ構造にしている。
これにより、仮に長期にわたってこのサイトを運用しても、ユーザーは毎年常に同じUIを利用できる。

年度間の行き来は一応可能で、複数箇所にリンクを用意しているが、わかりやすい形では配置していない。
これは意図的な設計で、知らない間に過去のページに来てしまい、サイト内で迷子になってしまうことを防ぐ狙いがある。
仮に過去のページに来てしまっても、ほとんどのページにおいてポップアップで最新年度へ誘導。ポップアップを消しても、サイト内で一番大きなフォントサイズを用いて、過去年度のページにアクセスしていることを示す。
ユーザーがいつでも最新年度のページに戻ることができるよう配慮している。

resultの下にあるothersは、特定の年に限らない内容が書かれたページのディレクトリ。
例えば、
GBB 現地観戦計画のたてかたhttps://gbbinfo-jpn.onrender.com/others/how_to_plan
などがこれにあたる。
othersディレクトリの各種ページはすべて最新年度と同様に扱われ、ページ内に表示されるリンクは、すべて最新年度のページへのリンクになる。

JIMDOで運用していたサイトは、すべてのページがルートディレクトリに存在し、非常に分かりづらい構造だった。
そこで、年度ごとに情報をまとめ、年度間の行き来を制限。過去年度の情報へのアクセス手段は提供しつつ、意図しないページへのアクセスを妨げる仕組みにした。

AIサポート botpress

UIは十分突き詰められたが、まだ課題があった。

SNSを見ていると、Beatboxファンの中の有名人（Mayc〇さん）のもとに、GBBに関する質問が大量に届いていた。GBBINFO-JPNが使いにくいとかそういう問題ではなく、なんと 日本国内で開催され、日本語で情報公開がしっかりなされているイベント に対する質問が大量に届く。

これに対する仮説として、どれだけ情報が充実しようと、みんな結局「自分の言葉で」誰かに質問しないと気が済まないのではないか、と考えた。
ググったら出てくる情報をすぐ他人に聞くような人ってよくいるじゃん？

それに対するアンサーとして、AIの活用を思いついた。ちょうどChatGPTが出てきたころのアイデアだったけど、JIMDOの制約、無料で運用するという制約上、実装は難しかった。
（今でこそchatgpt-4o-miniのおかげで、ちょっとくらいAPIにお金払ってもいいかなと思えるようになったが、それまでは実装を諦めていた）

AIも、まずノーコード開発で実装した。botpressを利用して、お問い合わせチャットボットのような設計にした。
こいつもJIMDO同様、太っ腹な無料枠をもつ。応答の遅さがネック。
いかなる質問に対しても回答はURL（質問内容に合うページを提案）なので、ハルシネーションの心配は無い。

簡素な設計ではあるものの、チャット形式でGBBに関する質問を行えるようになった。
また、ユーザーの入力内容から、ある程度の需要調査もできるようになった。

2024/9/23
UIのじゃまになる・なんでも検索の影響で利用数が減ったので廃止

AIサポート なんでも検索

botpressが完成した後、どっかの記事に「AIを前面に押し出したプロダクトは、消費者に敬遠される。AIであることをわかりにくくするべき」と書いてあったのを見つけた。
実際、botpressのチャットボットはなかなか利用数が伸びなかった。レスポンス遅いし、ちょっと使うハードル高いのかな。

そこで、無料枠があるAI Geminiを使って、一見AIに見えないような検索サービスを作ってみようと考えた。
仕組みは単純。ユーザーの入力をGeminiに投げて、最適なページを選ばせる。botpressのチャットボットとほぼ一緒。

唯一の違いは、AIが選んだページに自動でリダイレクトされること。 ユーザーは何も選択する必要がない。ただ知りたいことを書いたら、ページに勝手に飛ばされる。
UIは、Google検索のように、ただ1行分の入力を用意するだけで、AIとはどこにも書かない。
Gemini 1.5 flashを採用したので、応答も非常に速い。

導入すると、さっそく多くの方にご利用いただいている。ユーザーの入力を確認すると、おそらくはGoogle検索しても何も引っかからないであろう表現が多くみられる。例えば、自分の好きなBeatboxerの名前をそのまま入力したり、わからないことを文章にして質問するなど。AIだからこそ対応できた質問である。
すべての入力に対してAIの回答を確認しているが、今のところ精度は100%と言っていい。

質問によっては、クエリパラメータをつけて自動スクロールする機能も追加。ユーザーは、より手間なく素早く情報へアクセスできる。

AIサポートも、ノーコード開発をやめて自分で作ったら、よりシンプルで使いやすいものが作れた。
ユーザーの導線を突き詰めた結果、そもそもユーザーに選択肢を与えないという結論に至った。

思いついてから、実験して、実装。
ここまでわずか1時間。

ページ別設計

ここまでの要素は、すべてのページに共通する要素として、基盤となるHTMLファイルに記述してある。
その基盤ファイルに、flaskのextendsを使う形で、各種ページが載っている。

トップ/これだけガイド

まず「これだけガイド」という名前は、初期の運用方針にある「最新情報をまとめておく、データベースを作ること」に基づいたものだった。
GBBに関する情報をすべて1つのページにまとめる。「これだけ」見ておけば、あなたの知りたい情報はすべて手に入りますよ、 というメッセージをこめた。

これだけガイドに一切の情報を掲載しない のも、こだわりの一つだった。唯一開催日は例外として書いてあるが、このページに情報をたくさん書くと、ごちゃごちゃした印象になってしまう。また、これだけガイドという名前からは、具体的に何の情報があるかは分かりにくい。どこの何の情報があるか分かりやすくするための設計だった。

JIMDOで作っていたころ、トップページとこれだけガイドは分けていて、これだけガイドは数あるコンテンツの中の1つという位置付けだった。ただふたを開けると、これだけガイドの閲覧数がトップページを大きく上回り、 トップページの存在意義が薄れていった。そこで、思い切って統合してみた。

未発表項目は、ボタンの色を半透明にすることで、情報がないことを直感的に分かりやすくしている。

これだけガイドは、GBBINFO-JPNの中で一番重要、かつ閲覧数が多いページ。
全ての情報をコンパクトに集約している。「これだけ」見れば大丈夫。

GBB運営に対する「俺たちが求めているものはこれだ。今すぐこれを作れ」というメッセージでもある。

Wildcard結果&出場者

Wildcard2の結果、出場者一覧のページ。

GBBにおいては、Wildcard以外で出場する方法があるため、Wildcard結果と出場者は必ずしもイコールではない。
出場者一覧は、Wildcard結果を内包している。

わざわざ両方表記するのは、「GBB 出場者」「GBB Wildcard結果」両方のワードが人気の検索ワードだから。

CSVで出場者を管理しており、クエリパラメータに応じてpandasで情報を引き出し、表示している。
これにより、出場者に変更が生じても（割とよく発生する）、CSVを書き換えるだけで、CSVと連携した各種ページがすべて更新でき、運用コストの削減につながっている。

クエリパラメータの数は3種類。

  • 出場する部門（GBB 2024は5種類の部門がある）
  • 出場権獲得方法（Wildcard、その他、両方表示）
  • 辞退者の扱い（表示、非表示、辞退者のみ表示）

5×3×3=45種類の表示から、ユーザーはお好みの表示を利用できる。
全部門の出場者を一括に表示することはできない。 とんでもない長さになって、見づらくなってしまうことを防ぐため。

一番人気である Solo部門全出場者をデフォルトとして設定 してある。適当に選んだわけではない。世の中に知られている"Beatbox"は、たいていSoloを指す。

表のデザイン設計は、前述の通り、縦線が一切ない。その理由は、出場者1名ごとの追加情報を横に表記しているため、縦線を引くとかえって分かりづらくなる。 ここも意図的な設計。
出場者のうち、Wildcardを勝ち抜いた人と、それ以外の人を分けているのも、見やすくする工夫の一つ。

表の下にある世界地図は、CSVで出場者を管理しているからこそ実現した機能。 JIMDOから移行して本当に良かった。手作業で作ったら手間がかかる。
事前に、ChatGPTに国ごとの緯度経度データを別のCSVにまとめさせた。
それをpandasで読み込んで、foliumで地図を制作し、表示している。

GBBINFO-JPNの中でも常に注目を集めるページ。
情報量が多いからこそ、コンパクトにまとめ上げた。
国ごとに情報を確認できる、世界地図もある。

出場者検索

すでに説明した「なんでも検索」を運用していると、特定のBeatboxerの名前（例：HIKAKIN）を入力している人が見られる。ただ内部で動かしているAIは出場者名まで把握しておらず、Wildcard結果&出場者ページへの誘導しかできない。
しかし、なんでも検索のコンセプトはあくまでも「適切なURLを選んでリダイレクトすること」なので、特定のBeatboxerの出場可否まで回答させるのは難しい。

この問題を解決するため、2つのアップデートを入れた。

  1. Wildcard結果&出場者ページに新規項目 出場者検索 を導入
  2. Beatboxerの名前が なんでも検索 に入力された場合、出場者検索 にリダイレクト、検索入力まで行う

ここでの出場者検索の仕様は、レーベンシュタイン距離による類似度検索を採用。入力内容と、システム内部にある出場者CSVデータを照合し、類似度が高い出場者名を表示する。なおここでの類似度計算には、Tag Team・Crewなど 複数名部門のメンバー検索にも対応している。

また、なんでも検索と違い、検索ボタンを撤廃し、文字入力イベントを検知して自動で検索を行う。これにより、俗に言う「あいまい検索」を実現。

これにより、なんでも検索に名前と思われる入力があった場合でも、AIによる回答にはならずに、 最終的にユーザーに届く情報はあくまで類似度検索となる。

GBBINFO-JPNにおけるAI活用は、一貫して あくまで選別作業を任せるだけ。自由な出力はさせない という方針である。
AIの利点を生かしつつ、不確実性をなるべく下げられる仕組みを実現。

ルール

おおざっぱなレギュレーションから、出場者が守るべき細かいルールまでの総称としてルールと表示している。
毎年GBBに関する情報として一番最初に出てくるのがこの情報。毎年運営であるSwissbeatboxが、Webサイトにクソ長い英文を掲載する3。よほどの物好きか、出場希望者しかちゃんと読まない。

筆者は物好きなので全部読むが、全部訳しているととんでもない量になる。そしてほとんどの情報はBeatboxファンにとって価値がない（契約うんぬんとか）。

そこで、GBBINFO-JPNのルールページは、大胆な方針をとった。
正確さを捨てる。Beatboxファンにとって真に必要な情報以外、載せない。

これを突き詰めた結果、初期の運用では長文が散見されたが、現在は最低限の説明と表のみ。シンプルで分かりやすく仕上がった。

また、このページには出場者のうちシード権保持者を掲載しているが、Wildcard結果&出場者のセクションで紹介したCSVと連携してあるため、辞退が発生してもすぐ対応できる。
JIMDOで開発していたころは、このページとWildcard結果&出場者ページ、両方を編集する必要があり、手間になっていた。ミスを誘発する原因にもなっていた。

ルールなので、どうしても複雑になってしまうことが当初の課題だった。
情報量が多すぎるので、割り切って取捨選択し、シンプルな見た目を実現。
GBBINFO-JPNでこのような対応をしているページはここだけ。

日本代表

Wildcard結果&出場者のうち、日本人のみをピックアップしたページ。CSVから情報を取得する仕組みは同じ。
日本代表をわざわざ作った理由は、AIサポートやSNSでの利用者の声から、需要が高いと判断したため。実際、ルール、Wildcard結果&出場者に次いで閲覧数が多い。

大会結果

GBBINFO-JPNの中で唯一、ページ内に年度を行き来することのできるセレクトメニューを設置。今年の結果を知ったら、去年の結果も知りたくなるかな？という配慮。
出場者一覧と同様、CSVで管理されている。

タイムスケジュール & 当日配信

これらのページは、アクセス数が増える割に、GBB運営の発表がいつまでたってもなされないので中身がどうしても空っぽになる。
情報が無い分には何もできないので、何もしない。でもいいのだが、筆者には恐れていることがある。

デマの発生。

Beatboxに限らず、コミュニティ（というか人間の心理）では、極度の情報不足からくる不安に陥ると、自分で頑張ってそれっぽい情報を見つけて、それを真実だと信じこみ、すがってしまう傾向にあると思う4。
GBBINFO-JPNであれば、それを完璧に予防することはできずとも、「今は情報が無い」 という立派な情報を提供することはできると考えている。

また、昨年度の情報からある程度予測を立てることはできる。昨年度の情報提供を行う役割も果たすページになっている。

情報がないことを正直に伝え、最新情報を待つよう呼びかける役割も果たしている。

7toSmoke これだけガイド

GBBの全日程が終了した次の日に開催されるアフターパーティー「7toSmoke」
これもGBBの人気コンテンツの一つなのだが、今まで運営が最新情報を全く公開しなかったこともあり、情報が散らばってしまっていた。しかし、7toSmokeは（一応）GBBとは別の独立したイベントである。

そこで、7toSmokeの特設ページを作成した。

ただ、内容はGBB本体と重複していることが多い（タイムスケジュールなど）。そのため、ページ内に設置している「7toSmoke これだけガイド」のほとんどのページは、もともとGBB本体のために作ったページをかき集めたものである。

GBBアフターパーティーである「7toSmoke」も、GBBと同様これだけガイドを設置。情報を一点に集めるアイデアはそのまま。

これもパッと思いついてすぐ実装したアイデアの一つ。

GBBINFO-JPNによる影響

運用を始めてもうすぐ3年、いろいろなところに影響を与えた。
データはすべて2024年9月現在。

  • ユーザー数（2022年11月 統計記録開始～）
    • 20万ユーザー
    • 81万ビュー
    • 参考：GBB 2023 初日配信視聴者数 20万人
  • Google検索結果 平均順位1位を多数獲得
    • 該当ワードは 300種類
      • GBB 2024 GBB 2023 結果 GBB 2024 出場者 など
  • GBBの日本運営チーム5である テレビ朝日ミュージック (BEATCITY JAPAN) からある日突然連絡がきた
    • 六本木ヒルズオフィスに招待された
      • GBBINFO-JPNの運用経験、ノウハウを提供、様々な提言を行った
        提言は一部本当に採用されている
    • どうやら GBBINFO-JPNを見て危機感を抱いた らしく、やっとこさGBB公式サイトができた（2024年1月）
      • なおGoogle検索上ではGBBINFO-JPNのほうが圧倒的に検索結果順位が高い
        （本来GBBINFO-JPNは公式に負けるべきなんだけど...）

割とマジで、
GBBINFO-JPN = 公式サイト
とよく勘違いされるレベル。
※GBBINFO-JPNは公式サイトではない

まさかここまでうまくいくとはおもわなかった

GBBINFO-JPNを作る上でなんとなく考えていたことを書き出してみた。
今後も随時改善を行っていく予定。

  1. 実は2018年ごろまで運用されていたWebサイトが存在したが、確か2022年あたりに突然消えた。なんで消した？？ ↩

  2. ワイルドカード：動画予選を指す。業界用語。
    動画予選と表記しても良かったが、ファンの間でも割と知られているので、あえてそのまま表記している。 ↩

  3. 2024年版はこちら
    え？GBB公式サイト無いんじゃないの？と思われたはず。
    実は、Swissbeatboxはルールを掲載するWebサイトを持ってるのに、なぜかルール以外何にも掲載しない。
    ちなみに、2024年にGBB公式サイトができたが、ルールに関してはもともとあるルールページへのリンクを載せるだけで、公式サイト自体には何も書いていない。 ↩

  4. 人間には、自分が努力して獲得した情報は正しいと思い込むバイアスがあるらしい。
    有名人のスキャンダルだったり、コロナにまつわる陰謀論など。一度誰かが発信し、それを努力の末見つけてしまった人は、それを簡単に信じてしまう。そのために情報が見つかるまであちこち必死に探し回り、情報を追い求める。
    ニコニコがサイバー攻撃を受けた際、ニコニコ公式SNSや、関係者のSNSアカウントに、一刻も早い情報提供を求める声が多く届いたのはご存知の通り。
    GBBでサイバー攻撃のような不安を煽る事態は発生しないが、情報難民がデマをうっかり発信してしまうことは起こりうる、と筆者は考えている。 ↩

  5. 日本でイベントを開く場合、基本的に日本の法人に手伝ってもらわないとイベント開催は難しい。さらに出場者のビザ申請などもあるので、GBBはテレビ朝日ミュージックが主催しているという体裁をとっている。実際はSwissbeatboxが主導権を持っていると思われる。
    テレビ朝日ミュージックとSwissbeatboxは全然連携取れてないらしく、そのせいでテレビ朝日ミュージックはGBBINFO-JPNを情報源に最新情報を得ていたと直接言われた。 ↩

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?