嵐の特別映像は、最高のファンサに見える負荷分散だったのでは

嵐のライブ前に流れていた特別映像についての投稿を見て、かなりいい企画だなと思った。

一番おもしろいと感じたのは、ファンにとって嬉しい企画に見せながら、裏側ではログイン集中や現地混雑みたいな運営上の問題も解いていそうなところだった。

問題解決って、実装だけではなく仕様や体験の作り方でもできるんだなと感じたので、忘れないうちにまとめておきたい。

きっかけはこの2つの投稿。

ファンサに見えて、実は負荷分散でもある

最初は、ライブ前に特別映像が見られるのは普通に嬉しいファンサだな、くらいに思っていた。

ライブ前に特別な映像が見られるのは、ファンからするとかなり嬉しい。気持ちも高まるし、本番までの時間も含めて体験になる。

ただ、よく考えるとそれだけではなかった。

ライブ配信みたいな、絶対に落とせない本番がある時に怖いのは、本番直前にユーザーが一気にログインしてくることだと思う。ログインできない人が出たり、配信の入り口で詰まったりすると、その時点で体験が壊れてしまう。

とはいえ、運営都合で「事前にログインしておいてください」と言われても、ユーザー側の動機としては少し弱い。分かるけど、ちょっと面倒。やった方がいいのは分かるけど、わざわざ今やる理由がない。

そこで特別映像を流す、というのがかなりうまいなと思った。

事前配信で解けていそうなこと

この事前配信には、たぶん大きく3つの効果があったのではと思う。

ユーザー体験としては、

ライブ前の特別なコンテンツとして嬉しい
本番までの時間も含めて気持ちが高まる
「事前にログインする」が面倒な作業ではなく、楽しみの一部になる

システム運用としては、

本番前に自然とログインしてもらえる
ログインできない人やトラブルに事前に気づける
本番直前のログイン集中を前倒しできる
配信基盤にどれくらい負荷がかかるかを事前に見られる
本番前のリハーサルとして、実際に近い状態で検証できる

現地運用としては、

家で見たい映像があることで、会場周辺に音漏れを聞きに行く人を減らせるかもしれない
結果として、現地の混雑やアクセス集中の緩和にもつながるかもしれない

ユーザーにはファンサとして見えている。でも裏側では、ちゃんと負荷分散にもなっている。

一つの企画で、ファンの満足度、本番前のリハーサル、ログイン分散、会場周辺の混雑緩和を同時に解いている感じがして、かなり良い設計だなと感じた。

技術で殴る前に、仕様で解けないかを考える

こういうのを見ると、問題解決って実装だけではないなと感じる。

システムが重いなら、インフラを強くする、クエリを速くする、キャッシュを入れる、みたいな解き方はもちろんある。そこをちゃんとやるのは大事だし、技術で解くべき問題もたくさんある。

でも、全部を真正面から技術で殴るのが正解とは限らない。

本当に達成したいことを見直すと、仕様や体験の作り方で解けることがある。しかもその方が、ユーザーにとって自然で、プロダクトとしてもいい形になることがある。

今回の特別映像の話は、まさにそれに近い気がした。

「ログイン集中を避けたい」という運営側の問題を、そのままユーザーに押し付けていない。ユーザーにとって嬉しい体験に変換している。しかも、ただの飾りではなく、システム的にも意味がある。

使われていない機能を消して、負荷問題が解けた話

この話を見て、自分の仕事で重いクエリに向き合った時のことを思い出した。

ある機能の裏側で重いクエリが走っていて、小さな負荷の積み重ねでユーザー影響が出ていた。普通に考えると、クエリを改善する、処理を分割する、キャッシュする、みたいな話になる。

ただ、その機能自体を見直してみると、実は数年ほとんど使われていなかった。効果もそこまで大きくなさそうだった。

そこで「この機能、仕様として変えられないか」と相談したら、PdM側でも削除して問題ない機能として認識されていて、むしろ消したいものとしてバックログにも入っていた。

結果として、機能削除で解決した。

これは、エンジニアとして派手な最適化をした話ではない。たぶん技術記事として書くと地味だと思う。でも、プロダクトとしてはかなり健全な解き方だった気がしている。

ユーザーにとって価値が薄い機能を残すために、システムを頑張らせ続ける必要はないこともある。そもそも消した方が、ユーザーにもプロダクトにもシステムにも良い、みたいなことがある。

強いエンジニアは、実装前に問いを変えられる

この時に、エンジニアは渡されたタスクをそのまま解くだけではもったいないなと思った。

「このクエリを速くしてください」と言われたら、まず速くする方法を考える。それは大事。

ただ、その前に、

この機能はまだ必要なのか
本当に守りたいユーザー体験は何か
仕様を変えても目的は達成できるのか
ユーザーにとって価値が薄いものを守るために、システムを頑張らせていないか

みたいなことを考えられると、解き方が変わる。

嵐の特別映像の話も、同じ構造がある気がした。

技術だけを見ていてもたぶん出てこないし、ユーザーの気持ちだけを見ていても足りない。システムの制約、ユーザーの気持ち、プロダクトの目的を一緒に見て、ちょうどいい仕様に落とせることが大事なんだと思う。

学び：いい仕様は、対策っぽく見えない

問題を実装で解くのは大事。

でも、問題を仕様で解けることもある。

そして、いい仕様はユーザーに「対策されている」と感じさせないのかもしれない。

ユーザーには普通に嬉しい体験として届いていて、裏側ではちゃんと安全側に倒れている。

たぶん、いい仕様は「対策しています」と見えない。普通に楽しい、普通に便利、普通に自然。けど、その裏でちゃんと問題を解いている。

そういう設計ができるようになりたい。