ファミコン全タイトルの傾向をTableauで分析してみた。（前編：Prepでのデータ整形）
――「レンダーマン」
この言葉を聞いて反応できる人間は、
今は亡き「エクスツールス」社の「Shade」で「分散レイトレーシング」をしながら「なんでQVGAサイズのレンダリングに10時間以上もかかるんだ」と嘆いた経験を持っているか、
レンダーマンが高価で買えないから無償のPovRayでコーディングしながらラジオシティレンダリングをした経験を持っているか、
あるいはTableauのコアなファンかの、いずれかでしょう。
1995年11月22日。
世界初のフル3DCG長編アニメーション映画「トイ・ストーリー」公開。
メタボールによるドクロのCGに未来を感じた「劇場版ゴルゴ13」が1983年、実写レベルのCGに驚いた「アビス」が1989年、液体金属のCGが印象的だった「ターミネーター2」が1992年、数々のリアルなCGの恐竜に度肝を抜いた「ジュラシックパーク」が1993年。
同時期の日本では「ビット・ザ・キューピッド」が1995年4月から放映開始されており、フル3DCGではないものの、CG表現の未来を感じさせるアニメでした。（フォトショで描いたとかなんとか）。amigaで描かれた「ウゴウゴルーガ」なんてのもありましたね。
※超絶余談ですが「ジュラシックパーク」も3DCGレンダリングした静止画を1枚ずつフォトショップでつないでいたそうで、これがきっかけとなってのちのAdobe「AfterEffects」が誕生したという逸話があります。私もコアなAE使いです。
が、とにもかくにも1995年に「トイ・ストーリー」があれだけの高品質なCGアニメを実現した事は、本当にすごい事だったのです。
そんな「トイ・ストーリー」を支えたのが、当時とても画期的な3DCGレンダラーであった
「レンダーマン」
でした。
（もっと言ってしまうと、「アビス」も「ターミネーター2」も「ジュラシックパーク」もレンダーマンが使われてます）
レンダーマンはPixerのインハウスツールで、とにかく「レンダリング速度が速い」のが特徴だったようです（速いって言っても、1フレームあたり何時間というオーダーですが）。
というのも、さすが映画向けに開発されたレンダラーで、基本的には「カメラの画角に入っている物しか計算しない」設計概念でした。
この設計思想のため「レンダーマンはレイトレーシングすらできない」と言われていましたが、実際は使い分けができたようです。
（陰面消去とかサブディビジョンサーフェスとかは普通のレンダラーでもやってたりしますが）
で、なんでこの「レンダーマン」がTableauと関係があるのか、なんですが…。
Tableauの初期開発メンバーである
パット・ハンラハン氏。
実はこの「レンダーマン」の開発設計に携わり、
アカデミー賞をなんと3回も受賞
してるんです。
そう。
Tableauが、他のBIツールと比較して、あれほどUIやUX、スピード感（フロー）やヴィジュアルにこだわっているのは、何を隠そう、この「レンダーマン」の設計思想が息づいているからなんですね（多分）。
もし、あなたが「邪魔なイルカに対して『お前の消し方を教えろ』と入力した」「英単語の頭文字を自動で大文字にされたり、自動で箇条書きにされてレイアウトがくるってキーボードクラッシャーになった」「画像を貼り付けるたびに、勝手にデザインテンプレートを提案してきて憤死しそうになった」などの経験が1度でもあるのであれば、「とにかく、全くユーザーの言葉に耳を傾けず、インターフェースを徹底的にダサくする事だけに腐心している」あのメーカーが作ったBIソフトだけは絶対に選ばない筈です。
で、2001年。
「当時の技術では存在できなかった筈の映画」とまで言われる、1本の驚異的な3DCG映画が誕生します。
しかも、日本から。
映画「ファイナルファンタジー」です。
そしてまた、この映画にも「レンダーマン」が使われていました。
167億円もの制作費用を投入し、スクエアが社の命運をかけて作り上げたにもかかわらず、原作ファンの期待を裏切る舞台設定と同時期に公開された「千と千尋の神隠し」の影響で興行収入が90億円ほどしかいかず大失敗。その後のエニックスとの合併を決定づけたと言われる、伝説の作品です。
制作スタジオはハワイに置かれたスクエアUSA。1Uサーバすら存在しなかった時代、一般人では到底用意できない、独自設計のラックに並んだLinuxベースで数千ものintelCPUを並列接続したレンダーファーム（3DCG計算用のちょっとしたスーパーコンピュータ）で「レンダーマン」は動いていたわけです。
※ちなみに、知財の世界では「製作」と「制作」は違う定義の言葉として扱われます
※余談ですが、私は古くはShadeを使い、その後、現在までCinema4Dを使い続けておりますが、3DCGの話をこれ以上すると、おそらく10時間あっても終わらないので、このくらいにしておいて…。
という訳で。
今回の本題は「ファイナルファンタジー」に代表される「ゲームソフト」です。
私が人生で初めて触ったゲームソフトは、おそらくMSX2の「ツインビー」「高橋名人の冒険縞」あたりだったと記憶しております（3歳とかそのくらいの頃）。
特に高橋名人はすごく好きでしたので、漫画も持っていましたし、高橋名人の歌も大好きですし、最近では自作のボカロ曲の歌詞にも登場させました。
当時のゲームソフトは、とにかく容量が少なかったです。
初代「ドラゴンクエスト」ではカタカナの数を減らさなければならず「ダークドラゴン」が「ダースドラゴン」になったり「にじのペンダント」が「にじのしずく」になったのは有名な話ですし、「ファイナルファンタジー」でも「あと1音の容量が欲しい」と社内の各部署を植松伸夫氏が交渉して回ったのも有名な話です。「ハイドライド3」が「大容量４メガロム」なんて謳ってましたね。
「ファミリコンピューターマガジン」なんかを紐解けば、ゲームソフトの紹介欄には必ず「容量」が記載されており「24MB」とか「32MB」という大容量のソフトの登場には興奮したものです。
（「ファイナルファンタジー6」や「マザー2」が24MBでした。いまだに24MBという言葉には興奮しちゃいます）。
ただ、同時に、当時の私は知らなかったのです。この「24MB」が「メガバイト」ではなく「メガビット」（1バイト=8ビット）であり、実際は「3メガバイト」しかなく、少しでも大容量に見せるための涙ぐましい努力がされていたことを。
前置きが長くなりました。
今回は、Tableauを使ってファミコンにまつわる以下の4つの仮説を検証したいと思います。メインの焦点はずばり「容量」です。
①容量が大きいと石（ICチップ）の数が増えるため、価格が高くなっているのではないだろうか
②容量当たりの単価は年々安くなっているのではないか
③容量が大きいソフトは壮大なグラフィックや音楽が重要な「RPG」のジャンルが多いのではないだろうか
④発売日に傾向があるのではないか（クリスマスとか）
という訳で、今回はこちらのサイトのデータをお借りすることにしました。
せっかくなので、ファミコン以外の様々なハードのソフトもいっしょに分析してみようと思います。
はい。データです。
色々な項目が並んでいますね。
これらのデータをTableauにつっこんで分析をしていこうと思うのですが…。
このデータ、少し厄介です。
まず、ハードウェアごとにデータが複数のエクセルに分かれています。
次に、ハードウェアごとに少しずつ項目数や項目名が異なります。
そして、データ以外にも余分な情報がたくさんくっついています。
このままでは使えません。
どうしますか？
エクセルで全部くっつけて加工します？ でもそれって面倒じゃないですか？
このくらいの加工、Tableau Desktop側でもできるでしょうが、今回はせかっくなので
Tableau prep
を使ってみようと思います。
Prepでのデータ整形
正確には「Tableau Prep builder」と言います。
一言でいえば「Tableauに突っ込む前のデータクレンジング専用ソフト」
私はデータベース畑の人間ではありませんが、その手のプロフェッショナルの方にお話を聞くと「分析2割、データ整形8割」なんて言葉を教えていただく事があります。
そのくらい、データを使いやすい形に準備する事は重要ということです。
では、今回のデータの問題点をもう一度整理していきましょう。
①複数のファイルにまたがっている
②なにやら余分な情報がくっついている
③ファイル間でフォーマットが異なる
今からPrepを使って、この3つを解決し、1つのキレイなデータにまとめていきます。
まずは素直にPrepに突っ込んでみて、Tableauがこのエクセルファイルをどのように解釈するかを見てみましょう。
あらら…。
見事にNULLですね。
ぬるぽ
ガッ！
3DCGをやる人にとっては、NULLオブジェクトは応用性の高い重宝する言葉ですが、Tableauをやる人にとっては一概にそうではありません。
さらによく見ると、表頭の項目も「F2」「F3」とかになっており、うまく読み込めていない事が解ります。
これは②の「余分な情報がついている」が原因です。
つまり、Tableauが「どこに表があるの？ わからないよ」となっているのです。
でも、あんしんしてください。
Tableauには「表を自分で解釈する」機能がついています。
ああっ！ データインタープリター！
そう。
この機能を使うと、シートの中から「表だと思われるもの」をTableauが自動で切り分けて、提示してくれます。
例えば↑↑↑だと、赤枠で囲んだところなんかを「独立した表」として読み込んでくれるわけです。
今回使いたいデータは、画像下の大きな赤枠の表なので…
「B9：R1077」を選択します。（エクセルのセル番号と一致）
すると…
無事、正しく解釈してくれたようです。
これを、すべてのデータに対して行っていきます。
さて。これで①②の作業が完了しました。
え！？ もう終わったの！？
はい。もう終わってしまったんです。
では、③の「ファイル間でフォーマットが異なる」を解決していきましょう。
今回の問題は「ファイルによって項目数が違うので、そのまま1つのファイルにくっつけるのが困難」です。
別にすべての項目を使いたい訳じゃないので、必要な項目だけに絞ることができれば、それでいい訳です。
まず、仮説検証に必要な項目を洗い出しましょう。
・発売日
・タイトル
・ジャンル
・メーカー
・容量
・価格
・ハードウェアの種類
つまり、今回読み込んだファイルをすべてこの項目に合わせる事ができればいいんです。
そんなの、こんとんじょのいこ～。
ファミコンの場合「PRG-ROM」と「CHR-ROM」の合算（しかも、ビットではなくバイト）が容量になるそうです。
これで「欲しい項目だけが、欲しい項目名で抽出」できました。
ので、全てのファイルに対して同じことをやっていきます。
ただ、これだけではファイルは複数に分かれたままです。
別々のファイルをTableau Desktopに読み込んでもいいんですが、せっかくPrep使ってるのですから、1つのファイルにまとめたくないですか？
ユニオンを使います。
あ、私3Dプリンタでプロダクト開発もやってます。
ユニオンとは「複数のデータ間で、同じ項目（表頭）のレコードを下方向に接続する」行為の事です。
やってみましょう。
これで、データがくっつきました。
全部やっていきます。
ごめんなさい、もっといいやり方があるかもです。
全部くっつけたら、クリーニングステップを噛ませて内容を確認してみましょう。
を、このクリーニングステップで全て削除しました。
「日付」に修正しました。
最後のクリーニングステップで最終調整をしたら、いよいよ出力です。
Tableauには「.hyper」という専用のデータ様式が存在します。これはTableauのパフォーマンスを最大限活かせる形式なのだそうですが、今回は汎用性を優先して、あえての「.xlsx」で出力します;^^
という訳で「フローの実行」。
はい、これで無事に、データ整形して1つのファイルにまとめることができました。
後編ではいよいよ、このデータをTableau Desktopにつっこんで、仮説検証をしていきます！
お楽しみに！
あ、因みに、今回の記事の表紙絵は「Novel AI diffusion」でAIに描いてもらいましたよ。
以下、失敗作。
（まだまだAIは手を描くのが苦手）
※当記事に書かれた内容は、全て著者の解釈によるものであり、公式の見解を代弁するものではありません。
この記事が気に入ったらサポートをしてみませんか？