お題箱回156
974.LWさんがよく言う萌えイラストは観たいけど萌えアニメはキツいっていうのはタイムパフォーマンス以外の理由がありますか？
そんなによく言ってましたっけ？ 萌えアニメはキャラが良くてもストーリーが全然面白くなくて結局イラストだけで十分なケースも多いくらいの話です。
アニメは最後まで見ないと評価が確定しないという不確実性が主ですが、長期的には期待値なのでタイパと言えばタイパではあります。
975.ソシャゲの運営において、ファンアートとかXでの盛り上がりを考慮して開発順序を変えるみたいなことって実際にあるんでしょうか？エレグが予想外にバズったからスキン早めに出すぞ！みたいな
かなりよくあると思います。
これは就活のときに前職のイメージを伝えるためによく話したことですが、コンシューマーのプランナーが職人気質であるのに対して、ソシャゲのプランナーはマーケター気質という傾向は明確にあります。良く言えばユーザーの反応を見ながら柔軟に動ける、悪く言えば創作的なこだわりが相対的に薄いので、当初の計画を多少曲げてでもユーザーの盛り上がりを最大化するように施策を柔軟に変えていくことはむしろ肯定されます。
補足527：データ分析職の面接官が元ソシャゲプランナーであることもかなり多かったです（ソシャゲプランナーはゲームデザインだけではなくマーケター的な能力も求められるので、別業界のエンジニアとか分析職にもスライドしやすいということ）。
ただ注意点が二つあって、一つはSNSでの人気がアクティブユーザーの人気と一致しているとは限らないことです。当然ながら実際にRevenueを生むのはアクティブユーザーの方なので、外野の盛り上がりよりはゲーム内チャットやプレイログの方が意思決定材料としての優先度が高いです（逆に言うと新規ユーザーの導入施策をバズベースで作るのはアリ）。
もう一つは、一過性のバズで作る短期的な施策が長期的に悪影響を及ぼす可能性を考慮しなければならないことです。短期的な施策と長期的な施策のバランスを取るのはソシャゲプランナーの至上命題の一つでもあって、例えばTwitterでキャラの誰かがちょっと伸びるたびにそのキャラのスキンをリリースしていたら当然スキンを作られるキャラが偏ってくるわけで、なかなかスキンが作られないキャラを推しているユーザーが愛想を尽かして離脱したら損失になります。
補足528：この辺りの事情は「まだユーザーではない層を相手にする広告施策」と「現アクティブユーザーを相手にする運営施策」では全く異なることに注意が必要です。例えば広告であれば見た人の2割だけを狙い撃ちにする施策を打つのはまずまず悪くないですが（残り8割の人は単に興味を持たないだけでマイナスの影響があるわけではないので）、ゲーム内イベントでプレイヤーの2割だけを狙い撃ちにする施策を打つのは極めてリスキーです（残り8割がゲームを見限って離脱するマイナスの影響が有り得るので）。
なので明確に人気が取れそうなファクターの存在を認識したとしても、その切り札をいつどうやって切るのかはプロデューサーやディレクタークラスの手腕次第でしょう。他にあまりイベントがないタイミングでカンフル剤として使ったり、長期的な影響が出ない範囲でちょっと先のコンテンツを前倒しにしたり、その辺りは本当に状況依存で「早く多く出す」みたいな単純な話ではありません。
976.遊戯王で話題の無限泡影とハイドラントの問題についてどう思いますか。
（現代遊戯王が題材ですが、問題自体は極めて古典的なものです）問題の詳細
「対象に取れないモンスターA（例：ダーク・フュージョンで融合したモンスター）」を対象に、「対象を選択して発動するカードB」（ソウルテイカー）を発動宣言してしまったプレイヤー（甲）に対し、対戦相手（乙）はAが対象に取れないモンスターであることを指摘した際に、「Aの代わりにBの正しい対象となりうる他のカードC（Aの隣の適当なモンスター）」がある場合、「Cを対象にBを発動すること」を甲に強要することができると解すべきかどうか。なお競技シーンとする。
977.「ハイドラント無限泡影問題」が遊戯王界隈で話題になってたのでカードゲーマーとしての意見をお聞きしたいです。
（もうゲーマーマインドが衰えつつあるLWさんに聞くのはお門違いかもしれないですが…）
現代遊戯王の話なのでわからなければお手数ですが適当に流してください。
https://twitter.com/saiya_citypanda/status/1781649223970427146
今日公認大会で起きた出来事
— センチュリオン・サイヤ (@saiya_citypanda) 2024年4月20日
サイヤ「ハイドラント召喚します。召喚成功時手札のファイアエンジン特殊召喚効果を発動したいです。」
相手「チェーンないです。」
サ「処理します。処理後何かありますか？」
相手「何もないです。」
サ「ハイドラント起動効果使います。」… pic.twitter.com/LUGDFLBT5U
僕が最後に遊戯王の大会に出たのは10年以上前なのですが、一応聞かれたので答えます。まず大前提として遊戯王はこういう明確な答えのないイレギュラーな事態はジャッジの裁量での現場対応になっているはずなので、その場にいるジャッジが決めれば何でもいいとは思います。裏でダイスを振るとかでもなんでもいいです。
ただ今後のジャッジングのことを考えるのであれば、「完全な巻き戻しを認める（発動自体をなかったことにして手札に戻す）」の方が穏当だとは思います。というのも、一度裁定を出してしまったら少なくともその大会中くらいは不公平が生じないようにそれを一貫させないといけないからです。
他のシーンでも同じようにジャッジングすることを考えたとき、「対象に取れないはずのカードを誤って対象にした場合、その時点で他の適正な対象が存在すれば、そちらを対象に取り直して発動したことにする」という指針よりも「対象に取れないはずのカードを誤って対象にした場合は巻き戻す」という指針の方が明らかに簡単です。一度前者の裁定を出してしまうとなんかダルいゴネ方をしてくるプレイヤーの出現が予想されますし、ジャッジ指針は一律で出しやすい明瞭なものであるに越したことはありません。
977.ハースストーン勢なのですが、遊戯王を外野から見ていてルール複雑・カードプール多すぎ・テキスト長すぎで初心者入ってこれないだろって思うのですが、実際のところ今の遊戯王事情ってどうなんですか？
僕も今プレイしていない外野ですが同じことを思ってはいます。
ただやっている人の話を聞いている感じだと、今の遊戯王は情報量が多すぎて逆にテキストを完全に把握しなくてもよくなって却って敷居が下がっているらしいです。特にマスターデュエルで顕著ですが、適当にリストを完コピしてきて展開ルートをいくつか覚えておけばOK、あとはなんか光ったところを適当に押すくらいの感じで十分楽しめます。
多分ソシャゲで細かいパッシブスキルとかステータスまで全部把握してなくても普通に遊べるのと同じだと思います。パーティーの要になる主要なバフとかスキルだけ理解しておけばよくて、「与ダメージUP(3%)(持続5秒)」みたいな細かいオマケのスキルは別に覚えていなくても支障ありません。
978.ニュースサイトやアプリは何を見ていますか？
特に見ていません。リビングで飯を食べるときちょっとニュースを見たりするのでそのくらいです（NHKでも民法でもなんでもいい）。
979.データベースを構築したいんですが、何から当たればよいかがわからなくて困っています。
業務フローのカイゼンみたいなものをミッションとして与えられたので、一番上流にある業務を根っこにして、部署またいだ様々な派生業務の把握と、散り散りに存在するそれらの業務に必要なデータをおおむね把握するところまでは来ました。
すべてのデータを統合したデータベースを構築できれば、あとは何かしらの手段でそれぞれの部署に適したデータ入出力ツール・業務サポートツールを提供できるようなシステムが組めるかな、というような想像をしていますが、すべてについて無知で困ってます。まずデータベースの構築をどうすればよいのかわからない。表をどうつくればいいのかがよくわからないのです。最上位の業務単位ごとに行をつくって、付随するデータをひたすら列を増やしていくべきなのか、表はいくつか作って互いに参照するようにすべきなのか。どういう場合にそうすべきなのか、そうだとしてどういう構成にすべきなのか。そもそも今あるデータが業務フロー整理のために必要な要素が抜け漏れなくあるかどうかも実はわからない。
上司同僚は「僕の考えた業務改善」を好きなようにやる方しかいなかったので、いま述べたことに対してのアドバイスはいただけませんでした。社内の情報系の部署にも諸事情により最初に相談には行けないので、ＬＷさんに聞いてみます。参考になる本とかあれば教えてくれるとうれしいです。
それはさすがに知らん無職じゃなくてもっとまともな人に聞いた方がいいと思いますが、聞かれたので一応答えられる範囲で答えます。最初に書いておくと僕はデータエンジニアではありませんし、データベーススペシャリストは持っていますがデータベースを構築した実務経験はありませんし、責任は取れません。
まず前提として、ここまでの進行は概ね問題ないと思います。「部署またいだ様々な派生業務の把握と、散り散りに存在するそれらの業務に必要なデータをおおむね把握する」をしれっともう済ませているのが偉くて（それは他部署へのヒアリングとか属人的な進行が絡むかなりダルい作業のはずなので）、その時点で「このままデータベースを適当に作るとヤバいことになるんじゃないか？」と直観する嗅覚も優れています。実際、データベースの設計はその後のデータのインアウトや業務フローの枠組みまで制約してくるので、ここで立ち止まって熟考するので正解です。データベースを適当に作るとあとで有り得ないくらい面倒なことになります。
ただ、データベース周りの知識は本当にボロボロで全く詳しくないことも伝わってきます。一応警告として言っておくと、「最上位の業務単位ごとに行をつくって、付随するデータをひたすら列を増やしていく」というやり方はマジでめちゃめちゃヤバいです。カレー作るときに「コーヒー煮詰めてればいつかカレーになるかな？ 同じ茶色だし」とか言ってるくらいヤバいです。そして「表はいくつか作って互いに参照するようにすべきなのか」も自明にYESです。ニンジンは一本そのまま鍋にブチ込むのではなく包丁でカットしてから入れるくらい当たり前です。
今の状態がけっこうヤバいことを自覚した上で理解すべきことは恐らくざっくり二つあって、一つはデータベースの理論的な知識、もう一つはデータベース設計が絡むプロジェクトの進め方です。
まずデータベースの理論的な知識について。データベースは大抵の情報システムの根幹の一つなので太古の昔からかなりきちんと体系化されています。表を分割すべき理由や設計指針なども含めて、最初に悩むようなことは基本的には割と基礎的な段階でだいたい結論が出ていると考えていいです（直接的には「正規化」とか「トランザクション系テーブルとマスタ系テーブルの区別」あたりが該当すると思います）。必要なデータのチェックもその過程である程度できるはずです。
個人的には、とりあえずの目安として「E-R図」と「DFD」くらいは理解するまで実際の設計には触らない方がいいと思います。それらはカレーの材料表みたいなもので、必要な材料もわからない人が形式的な手順だけなぞって料理したところでどっかでミスって死ぬ気しかしないので、そこは情報系の人に投げずに自分で全部理解した方がいいです。
また、理論の他にデータベース構築が絡むプロジェクトの進め方もちゃんと見通しを得てから着手したいところです。さっきも書いた通りデータベースの設計は関係する仕事の流れ全体に関わってくるので、エイヤで作ってダメだったときの被害範囲がだいぶ広い上にリカバーも大変です。
本当に必要十分なデータの洗い出しとか各所へのツール連携をどうやるかみたいなところは組織依存もあると思うので、幸いにも社内に情報系部署があるのであればそちらを可能な限り頼るべきだと思います。更に言うと、たぶんこの業務改善計画って今回作ったスコープだけで完結するわけではなく、上手くいったら他の業務も取り込んだり事業拡大に応じてスケーリングしたりすると思うのでその辺りも想定できるならしておいた方がよいです（最初のテーブル設計は今後の拡張計画にも大きく関わります）。
ただ参考になる本については、僕はデータベーススペシャリスト資格で基礎をカバーしてしまったので適当なものが思い浮かびません。もちろんデータベーススペシャリストを取得してから着手しても全然いいのですが、業務フロー改善程度のタスクであれば求められるアウトプットに対して労力が若干オーバーすぎる気もします。他の本にしても「データベーススペシャリスト相当までの知識はある前提で読み飛ばし、他に得るものがあれば吸収する」みたいなスタンスで読んでいるので、本当に全然知らない人向けの適当な本がわかりません。
ただデータベースの本は入門レベルも含めてかなり多くあるはずなので評判の良いものを選べばそう大きな失敗はしないと思います。一応注意点として、その状態でまず読むべき本はAWSだのHadoopだのという個別の商品やアーキテクチャについて解説する本ではなく、データベースの一般理論を解説する本です。
何か買ってもらえると嬉しいです。
