本書の概要

　本書では、マスターデータに関して以下3つを4章に分けて解説しています。

　・設計方法（1章：どんなルールで値を入力するべきか）

　・入力方法（2章：どうやって値を入力するべきか）

　・実践方法（3章・4章：どんなことをすれば1章・2章の内容を実現できるのか）

　そのため、本書をお読みになる際はかいつまんで読むのではなく、1章から4章まで通読することをおすすめします。また、付録としてマスターデータを入力するデータベース側の設計について解説しています。付録はプランナーとしては一段踏み込んだ話となっていますので、興味のある方はご確認ください。

　より詳細な各章の内容は、以下の通りです。

1章：マスターデータのデータ定義

　1章では、マスターデータに入力する値をどうすればよいのか、ゲームプランナーが特に触れる機会が多いIDの発番設計を例に解説します。1章の内容を実践することで、検索しやすくあとから見ても理解しやすいマスターデータをつくることが可能になります。

　注意点として、ここでいう設計はいわゆるデータベースのテーブル構成を設計するという意味ではなく、テーブルに入力する値をどのようにするべきかという意味で用いています。ですので、モバイルゲームのエンジニアの皆様の役に立つ内容ではありません。

2章：マスターデータの入力方法

　1章でマスターデータにどのような値を入力するかを設計したら、次の2章ではその設計した値をどのように入力するべきかを考えます。本書ではできるだけ人間が値を入力しない入力方法として、ラベル入力という入力方法を解説していきます。2章の内容を実践することで、先ほど例で示した誤入力起因の無駄な時間を減らすことができます。

3章：設計シートで使用するべき機能

　3章ではマスターデータの設計シートをつくる際に、使用するべきスプレッドシート（Excel、Google Spread Sheet）の機能解説を行います。3章の内容を実践すれば、設計シートの動作がより速くなり、2章と同様にバグで苦しむ時間が短くなり、結果としてより快適にマスターデータの設計を行うことができます。

4章：設計シートの実装

　4章では、1章から3章まで解説した内容を元に、スプレッドシート上でどのように設計シートを実装するべきかを解説します。

　また、本書はモバイルゲーム（いわゆるソーシャルゲーム）の運用を前提とした解説を行います。そのため、継続してマスターデータを作り続ける前提でデータが増え続けるとどのような問題に直面するか、その場合どのような回避方法を取るべきか、などについて解説しています。そのため、コンシューマーゲームの開発プロジェクトが想定している課題点については記載されておりませんので、あらかじめご了承ください。

本書における用語の定義

　すでに何度か使用していますが、本書では各種開発に関する用語の語義を以下のように定義します。

　ただし、これらの用語は筆者の所属するプロジェクトにおいて使用しているものであり、読者の皆様が所属するプロジェクトでは別の用語を用いている場合もあるかと思います。そのため、本書の呼び方・意味はあくまで本書の都合上のものであることに注意してください。

マスターデータ

　本書ではゲームを動かすために必要なデータベースにデプロイする値全般を、マスターデータと呼びます。ゲーム本体にハードコードしない値はほとんどがマスターデータに当たりますから、ゲームプランナーがゲームをつくっていく上で、必ず関わらなければいけないものでもあります。また、本書では前提としてExcel等のスプレッドシートを用いてマスターデータを設計し、それを何らかのプログラムで変換してデータベースにデプロイするという前提を置いています。

定義する・設計する・実装する

　本書では以降、上記3つの動詞が頻出します。それぞれの意味について、本書では一般に以下の意味で用います。

　定義する：マスターデータの各カラムの中にどのような値を入力するか決めること。たとえば、データ型は何にするべきか、IDは何桁にするべきか等を決めること。

　設計する：定義に則りどのようなマスターデータを入力してゲームをつくるか考えること。本書ではこの設計を楽にすることを目標にしている。たとえば、敵のHPをどのぐらい大きくするか、このバトルではアイテムを何％でドロップするかを決めること。

　実装する：マスターデータを設計するために使用する設計シートをどのような形にするか考えること。またはその考えを実際につくること。

　このような書き方をするのは、意味の区別をより明確に行うためです。上記のような動作は全て「設計する」というひとつの動詞だけで表現することが多い（と筆者は考えています）が、そのまま書くと3つある意味のどれかがわかりづらくなるため、本書では意図的に意味が近い言葉を用いて区別するようにしています。

設計シート

　本書ではマスターデータを設計・入力するために、使いやすくしたスプレッドシートのことを設計シートと呼びます。設計シートは何らかの関数が入力されたスプレッドシートであり、その関数の出力結果を見ながらマスターデータを設計していくのが一般的です。また、ゲームプランナーが設計シートを作成してマスターデータの設計を行うという方法が普通ですが、プロジェクトによってはエンジニアが準備したWebアプリケーションでマスターデータを設計する場合もあるようです。そのような場合、本書3章と4章はあまり有益ではないかもしれません。

施策

　本書ではゲーム中で開催するイベントのことを施策と呼びます。プロジェクトや文脈によって意味（というよりもスコープ）が異なることが多いですが、本書では一般にゲーム中でイベントと呼ぶぐらいの大きさのキャンペーン（グラブルでいえば古戦場、シャニマスでいうコラボフェス、バンドリでいう対バンイベント）のことを施策と呼びます。

バグ・データバグ

　一般にバグと呼ばれるものは、マスターデータ起因（ゲームのデータ側）で起きるバグとソフトウェア起因（ゲームのプログラム側）で起きるバグの2種に分けられます。このうちマスターデータ起因で起きるバグのことを本書ではデータバグと呼びます。本書でバグという場合は、そのほとんどがデータバグを意味します。全人類の敵です。

電子書籍化にあたって

　本書は2020年9月に技術書典9にて頒布された同人誌の商業誌版となります。ゲームプランナーが業務上作成するマスターデータの扱いを楽にするノウハウを集めた一冊として、作った同人誌版は想像以上の皆様に手に取っていただける形となりました。このたび、改めて書籍の形としてお手にとっていただける形となったことを嬉しく思います。本書を同人誌版から商業誌版に書き換えるにあたって、以下のような加筆・修正を行いました。

付録の加筆

　先述したとおり、同人誌版では記載しきれなかった、マスターデータのデータベース設計に関して付録を作成しました。同人誌版よりも更にマスターデータに踏み込むことで、より深い理解に繋がればと思います。

事例のオリジナル化かつ一般化

　同人誌版では実際に存在するゲームタイトルをベースに解説を行いましたが、その記載を削除してより一般的な事例をベースとした説明に切り替えました。同人誌版ではわかりやすさのためにゲームタイトルをベースにするということをしていました。しかしながら、開発の流れによっては製品レベルで仕様が固まっていない状況でマスターデータを設計することがあり、そのような場合は以前の内容だととっつきやすさはあったものの、仕様を決める前から仕様が固まっているという、実践的ではない内容となってしまっていました。そのため、本書では拡張性も含めたマスターデータの設計を行うためにも、実例を記載せずに仕様を組み立てるところから設計を行うこととしました。

図の再制作

　作図に関して一部作り直しを行い、収録箇所も増やしてより理解しやすい形としました。

　同人誌版より冒頭「はじめに」にて記載していた「ゲームプランナーがマスターデータをつくる上で発生する無駄な時間をできるだけ減らし、ゲームづくりに集中できる時間を増やす」という目的はそのままに、その目的をより達成しやすい形となるように作成した一冊となります。本書をお読みいただいた方を経由して、何らかの形で世に出るゲームのクオリティ向上に繋がれば、それほど嬉しいことはありません。

　最後に、この度このような機会を与えて下さったインプレスR&Dの山城様、そして素敵な表紙イラストを作成いただいたべこ様、そして職場で自分を支えて下さる先輩プランナー・エンジニアの皆様にこころから感謝します。

本書に関する問い合わせ先

　本書の内容について問い合わせ（感想・内容についての指摘）をしたい場合は、筆者宛のメールアドレス（tsumire.sunajima@gmail.com）までご連絡ください。