RM-BLOG

IT系技術職のおっさんがIT技術とかライブとか日常とか雑多に語るブログです。* 本ブログに書かれている内容は個人の意見・感想であり、特定の組織に属するものではありません。/All opinions are my own.*

テナモバの「今日の一曲」の仕組みの予想と、システム開発者心得について思うところ

テナモバの「今日の一曲」の仕組みの予想と、システム開発者心得について思うところ


 

 
テナモバの「今日の一曲」は、
コンテンツ開始当初、その紹介順序は恐らく「曲名のアルファベット順」だった。
開始10日前後でそれが一旦ランダムに変わったように思われたが、
以後、ツイッターのフォロワーさんを見るに、俺と同じ順序で紹介されてる人がいる。
この「差」は、そのフォロワーさんの話を聞いている限り、
テナモバが当初「曲名のアルファベット順」で紹介されていたときと同じで、
「俺の2日前」を紹介され続けている。(2017年9月13日現在同様)

そのフォロワーさんともコンタクトを取り、
この「2日ずれ」を論理的に裏付けるデータ上の特徴がないかを、
会員番号、メールアドレス等の観点から(個人情報に触れない範囲で)探ってみたが、
ぴったり差が「2」になるものは見当たらなかった。
(例えば俺が会員番号102番で、そのフォロワーさんが100番なら、
 「会員番号を基準に紹介順序を決定している」と言えるのだが
 ヒアリングした限りでその辺を決定づける情報は得られなかった)

もしかしたらこの「ずれ」を決める要因に、論理的なルールはなくて、
本当に会員ごとにランダムで順番を割り振っているだけなのかもしれない。
Twitterを通じて広く情報提供を呼びかければ、
もう少し精緻な解析ができそうなものだが、
面倒くさいのでやめた。

いずれにせよここから予想できるテナモバの「今日の一曲」の紹介順序は、

  • もとになる曲目リスト(並び)は全会員で共通
  • 会員ごとに違う開始位置が設定され、そこから1日1要素ずつ紹介されている


というところだろう。
もしかしたら人によって昇順降順等の順序の違いはあるかもしれないが、
基本的にはこの仕組みになっていると予想する。
要するにテナモバの画面で表示する「今日の一曲」を
紹介(選定)する機能自体にランダム性はなく(というかそんな「機能」自体存在しない)
決まった順序で紹介され続けているだけということだ。
元の曲目がアルファベット順に並んでいるから開始10日程で気づかれたが、
一度それをシャッフルしたことで一見「ランダム」っぽくはなったものの、
本質である「紹介の仕組み」自体は↑の機構に則っているだけだから
人によってかなり近い位置(なんなら「毎日同じ」)の曲を紹介されている。

逆に言えば、日が経過していくに連れて、
誰かがいつかたどった紹介順序と同じ順序で、
別の誰かが「今日の一曲」を紹介され始める可能性がある。
この状況が常態化すれば、いつかこのあたりの仕組みが露呈される懸念はあるだろう。
まあ、Early Yearsを含め、テナーでリリースされている曲は全部で250~300曲程度、
一週するまで少なく見積もっても8か月~10か月程度かかるので、
その頃には今より熱が冷めている(そこまで注目していない)可能性もあるから、
ほっといても気付かない可能性もなくはないが。
加えて、その一週し始めるくらいのタイミングでまた、
もとになる曲目リストをシャッフルしなおせばいいので、
熱心に毎日テナモバの「今日の一曲」の紹介記録(今日は何の曲だった、という記録)を
つけてる人間以外にはほとんど気づかれないだろう。
この件に関して幸か不幸か、だったのは、俺の身近にいる「某フォロワーさん」が
基本的に毎日テナモバの「今日の一曲」をつぶやいてくれることで、
それと俺の記録を照合させて「2日違いで進んでいる」ことを気付けた(気づいてしまった)ことだろう。
(強いて言うなら俺が「暇で仕事をサボりがちなダメSE」だったことも要因(テナモバ開発側からしたら「誤算」)の一つに挙げられる)




ちなみに、「予想が出来る(出来得る)」というのの最大のポイントは、
恐らく↑で述べた「もとになる曲目リスト(並び)は全会員で共通」というところだろうが、
逆に言えば「人によってばらばらの曲目」にするというのは、ちょっと仕組みを工夫しないと実現できない。
表示の度に切り替えるならそこまで難しくもなさそうだが、これに加えて「1日毎に曲を変える」というのも付きまとう。
(なお、暗黙的に、「前回までに紹介された曲は紹介しない」という条件を加えている)

仕組みを簡単に図示してみると

 全員で同じ曲目を利用人によって異なる曲目を利用

20170914_neta_01_common_pattern.jpg 20170914_neta_01_different_pattern.jpg
特徴 人によって開始位置が異なるだけで、
もとになる曲目が同じなので、
先に辿った人がいると
その人と同じ順序を辿らざるを得ない。
この場合、
Aさんは「POSTMODERN」⇒「泳ぐ鳥」⇒「MEMORIES」…
となるが、
Bさんは「MEMORIES」⇒「ネクサス」⇒「From Noon~」…
であり、
Aさんの「MEMORIES」以降を
先んじてBさんが体験していることになる。
このため、Bさんからは
Aさんの次の曲が「予想」できる。
同様のことはCさんとBさんの関係にも言える。
(CさんはBさんの次の曲が予想できる)
人によってランダムに曲を選びにいくので
元になる曲目がなんであろうと人によってそれぞれ異なる曲が紹介される。
勿論確率に依存するので「誰かと同じ曲が紹介される」という可能性もある。
仕組み 全員で共通の曲目を一つ用意しておけばいいだけなので、
人によって開始位置をバラけさせておけば
実現は比較的容易。
曲目自体も一定間隔でシャッフルしてしまえば
一見ランダム性は失われず継続できる。
各会員の「現在位置」を毎日カウントアップするか、
もしくは登録日から現在日数までの差分の日数を
テナモバにアクセスしてくるたび計算して、
開始位置に足してしまえばいい(こっちのが簡単か)。
全会員1人1人に対して
「その日の紹介曲」を毎日選定しなおしてあげる必要がある。
しかもその人が「既に紹介された曲」を除きつつ、である。
そのうえ選び方はランダムだし、
紹介するまでにやっておくべきことが結構多い。
会員数に寄るだろうが、
これを0:00の日付切り替えタイミングで
全員分キチッと全てこなすのは不可能だろうから、
例えば23:00くらいからデータの準備をしといて、
0:00になったタイミングでそれを表に出す、
みたいなバッチの仕組みが必要になりそうだ。


図で挙げた曲目はただの例なので気にしないでいい。

こうして考えると「人によって異なる曲目を利用」は結構面倒くさいことがわかる。
正直ちょっとしたDB(テーブル)を使いたくなるほどである。
まあ会員情報を持ってる以上はなんらかデータ保持機構があるんだろうが、
こういうことに柔軟に対応できるほど臨機応変なDBかどうかは怪しいし、
バッチの実装も視野に入れるとより現実的ではないだろう。
仮にやるにしても、こうした環境的制約等で実現できないような気がする。(単に予想だが)
こういうことから考えると、
簡易に実装できてランダム性も実現できる「全会員で同じ曲目を利用」のパターンの方を
採用したくなる(せざるを得なくなってくるように思う)。

まあ、真面目にやろうとするとそうなんだろうが、
「最後にアクセスしたときから日を跨いでアクセスしてきたら選定しなおす」みたいなことも
可能なので、というかむしろこっちの方が実現難易度は低いからこっちかもしれない。
「全員で同じ曲目を利用」も、裏で「現在位置」をいじくるよりは、
アクセスの度に日を跨いだかどうかを検査して選定しなおす仕組みなんだろうな。
これを採用すると、例えば9/11アクセス→9/12アクセスしない→9/13アクセスとしたとき、
アクセスしてない9/12紹介分を用意する必要がないため、システム側の負荷は軽くなる。
確かに全員が毎日アクセスしてくるとは限らないから、
アクセスしたときにだけ構えておけばいいのは事実だな。
うん。多分このやり方だろうな。(勝手に納得した)

ただどのような方式にするにせよ
「人によって異なる曲目を利用」だと「過去紹介済の曲を除く」がある以上、
それ用の判定ロジック実装のために軽くDBが使いたくなる(もしくはサーバ上にファイル置いて…とか?)
それがなければ「人によって異なる曲目を利用」もそこまで難易度高くないのだが。
実際、テナーでリリース済みの250~300曲のうち1つを選ぶということは、
同じ曲が連続する確率は、250曲だとしても1/(2502)=0.000016…であり、結構低い確率だ。
確率なのでなんとも言えない(起きるときには1日目・2日目で連続することも有りうる)が、
紹介曲の切り替わりタイミングが日別であることから、
遭遇するまで62500日は必要な計算になるので、
ほとんど起きないレベルの現象だと考えれば、
「過去紹介済の曲」かどうかの判定を実装する必要はないという判断もありかもしれない。

対して「全員で同じ曲目を利用」では、紹介する曲目を常に一定方向に進み続けながら選定していくため、
必然的に「過去紹介済の曲」が連続して紹介されることはなくなる。
勿論1週すると元に戻る(んだろう)が、それは仕組みの都合の話であって連続性とは違う。
加えて、途中で再度シャッフルすればそれも有耶無耶になる。
なんかいろいろ考えて天秤にかけると「全員で同じ曲目を利用」の方がメリット大きい気がしてきたね。
どっちかというと開発側の都合によるところが大きいが。




ここから先は私見である。(少し愚痴も入る)

テナモバの「今日の一曲」については、コンテンツの特性上、
「次に何の曲が紹介されるかわからない」ことに個人的に意味があると思っている。
なので、少なからず「予想が出来る(出来得る)」という現状は、正直良いことだと思っていない。
とはいえ「今日の一曲」が厳密に定義化されてサービス提供されているわけでもないし、
今のところ「俺より先に進んでいる人」というのを見たことがないので俺自身は予想がつかないのも事実なので、
この辺は単に私見による、一方的な「愚痴」に近いものなのだろう。
特に”厳密に定義化されてサービス提供されているわけでもない”というあたりが重要なのだが、
利用規約や約款等で「完全ランダム」を謳っているならまだしも、
意味合い的にも「思い出の一曲を紹介します。楽しみましょう」ってレベルのものなのだから、
そこに勝手な厳密性を求めるのも正直お門違いで、
むしろどのようなメカニズムであれ、日々紹介される曲を楽しめばそれでいいのだ。

といいつつ、少なからず裏の仕組みを予想され得る材料を作ってしまったのは
「今日の一曲」を作った人からしても想定外だったろう。
ここまで勘ぐって探りをいれてくるやつがいるとは思わなかったんだと思う。
職業柄、俺はこうした「裏の仕組み」に着目して探りをいれたくなる感覚があったのは事実だが、
自分がすごい考察力をもっているとは全く思っていないので、
同じようなことを、こうして文章化していないまでも、やってる人は少なからずいるのではと考えている。
テナモバの「今日の一曲」を作った人は、
テナーファンたちのこの辺の熱狂的な意識について考慮漏れしているように思う。
俺にとってはこの辺の考察は全然ガチではない。
テナーファンがこの程度「予想」するとは思ってなかったのではないだろうか?
そんなことはない。テナーのガチファンは恐らくもっとガチになって曲目を予想する。
テナーファンってもっとすごいと思うのだ。俺なんか大したことないくらい…




ちょっと違うが、似たような経験が俺にもある。
それはシステム開発サイドから見る利用者サイドの利用内容に関する考慮漏れ」である。
昔、「注文履歴一覧」みたいな画面を作ったことがある。
「注文データ引っ張ってきて表示するだけの機能だろ」という程度にしか考えていなかった。
実際一言でいえばそうだった。
要するにナメていたのである。
しかしいざリリースしてみたら思ったより利用する人がいるうえ、
いろいろ課題が出てきて対応に苦慮した。

No内容言い訳

1 ソート順がおかしい 何も考えずに「注文日の昇順」にしていたが、
よく考えたらこのテの一覧で注文日の昇順で並べてる画面はほとんどない。
普通は「注文日の降順」
(直近の注文が一番上にくる。Amazonの注文履歴とかもそうだし)だろ、
というクレームだった。
言われて見れば確かにそうだ仰る通り!とは思った(本当に思ったんだ!)が
設計書にソート順書いてあるからねぇ~
この設計内容で合意してるんだよねぇ~
となると仕様変更だねぇ~

…とは言わなかった(喧嘩になるからね)。
おとなしく直した。
2 検索がイケてない 検索条件が厳しかった。
「注文日」に加えて「注文時刻」が必須。
そのうえFROM~TOに同じものがあり、
両方に入力(選択)しないとエラーになる。
→この日のこの時刻からあの日のあの時刻まで、っていう入力を強制される
なんか「あの日見た花の名前を~」みたいだな。
作ってるときは全然なんとも思っていなかったが、
言われて見ればキツすぎる検索条件だなと感じた。
(注文日はともかく、注文時刻って普通覚えてるかあ~?っていう。確かにそうだ)

結構な大規模データを取り扱うことになるシステムだったこともあり、
「緩い条件で検索されると、大量件数ヒットして
 メモリ圧迫を起こす可能性があるので、
 なるべくキツめの検索条件にしましょう」

っていう設計時の決め事は確かにあった。
当時の議事録にそのことも明記してある。
しかし「使い勝手が悪い」という理由で改修を余儀なくされた。
(その際改修費用発生したかどうかは黙っておくw)

この件はミドルウェア(WEBサーバ)のメモリ問題との兼ね合いで
単純にプログラム直せば済むだけの問題ではなく、
対応完了までにいろいろ揉めた。
しかも蓋を開けてみればメモリ全然余裕だったってんだから笑わせる。
3 初期表示が0件 これも言われて見ればという感じでもあるが、
普通注文履歴って最初に画面表示した段階で一律ばーっと見えるもんじゃない?
いちいち検索しないと見れないって変じゃない?
と言われて、まあ確かにそうかもしれないねと思うに至った。
No.2の件とも相まって余計に目立つ問題と化してしまった。

「検索条件を入力する画面は検索してこそ検索結果明細が表示できる」という
システム都合オンリーの固定観念でこうしたつくりにしてしまっていたが、
画面特性によってその辺はまちまちだというのは事実であろう。
「絞り込みの条件が付いてるだけの画面」という認識が薄かった。


細かいところだともっといろいろあるが
総合的に見て「イケてないな~」って思った課題群はこんなところである。

一応、発注していただき、
レビューやテストを通じて開発し、発注者側での受入検証も実施したうえで、
納品し、検収し、リリースした案件であるから、
これら全て100%、システム開発側に瑕疵責任があるとは思っていない。
ただ、「エンドユーザに指摘されなければ気付けなかったのか」という点において
個人的に振り返ってみて反省すべき点があるのではと、思うところはある。
業務機能である以上は、
業務特性に合わせた特有の使い方や求められる利便性のベクトルは独特であるので、
「エンドユーザーが求めているもの」を全て把握して理解することは不可能だ。
それは俺らのようなベンダーに限らず、発注する側(俺にとってみれば顧客)も同様だろう。
リリースしてみて初めてわかる状況もある。
しかし「利用者の立場に立って一般的な見地でシステムに触れたとき」、
その前提には「業務特性等の専門知識がなくても」というのがあるが、
いわゆるそういう見え方ができるのかどうか?で、
多少なりとも開発物に対する品質に影響を及ぼすことは間違いないと思う。
そうしたところをなるべく常に心がけておくのは、
システム開発者として重要なポイントだろうと思っている。

一方で、日々の業務に追われて
そうしたところに頭が回らないような状況が常態化している点も事実である。
この辺はシステム開発という仕事を進めるうえでのジレンマであり、
またいつまで経っても解決されることはない永遠の課題だろう。
(残念ではあるが…)

今回のケースがこれと同じ、ないし類似する内容とは思っていないが
システム開発者の立場にあって、利用者視点(目線)で開発へ取り組む意識、
というのは大事だなと改めて思ったのであった。