1.
Ver1.2.0
ゲーム仕様書の書き方
～大久保 磨編～

2.
ネットや書店で発売中！
ブログもやってます。→

3.
前書き
ゲームの企画仕事に就いていると、ふと気付くことがあり
ます。デザイナーやプログラマーは参考書や技術書がたくさ
んあるのに、プランナーの教科書になるような物は無いと。
ほとんどの方が先輩や上司から、ほぼ一子相伝的に学んでい
ると思います。特にこの日本では。
当然クリエイティブな仕事は理論だけでは埋まらない部分
も沢山ありますから、全てをドキュメント化することは難し
いです。しかし、仕様書等の書類系であれば一定の理論体系
化が可能だと思っています。
そんな思いで簡単なスライドを作りました。少しでもゲー
ムプランナーやそれを目指す人の役に立てればと思います。

4.
スマートフォンで遊べるゲームの
「ホーム画面」仕様サンプル紹介

5.
お品書き
1. 名称
2. 参考イメージ
3. 概要(ユーザー体験)
4. ポイント！
5. 機能一覧
6. 基本フロー
7. シーケンス図
8. 画面、操作仕様
9. メモ
10. 関連項目
上記１０項目が、仕様書に必ず書かなければいけない内容、情報です。
仕様書は「受け取る側が理解できるもの」であることが大変重要です。

6.
CAUTION！！！
次のページからは細かい文字がたくさんあるので、
右下の ボタンを押すか、ファイルをダウンロード
して見ることをお薦めします。
このへん。

7.
1. 名称
「ゴキブリバンバン ホーム画面」
2. 参考イメージ
※右図参照
3. 概要（ユーザー体験）
ホーム画面はゲームの基本となる各種機能にアクセスすることができる
文字通り、プレイヤーのホームとなる機能です。ここからゲームをプレイする
ための「クエスト」や、ゲームを有利に進めるための「デッキ、ショップ」などの
基本的な機能全てにアクセスすることができます。
また、プレイヤーがクエストやガチャなどで獲得したキャラクターの
「ホーム画面専用のセリフ」を楽しむことができ、より一層キャラクターに
対する愛着が沸くのが、ホーム画面の一番の魅力です。
解説
「名称」は、各機能単位で付けます。「ショップ」「バトル」等の画面単位での
大まかな名称もありますし、「アイテム売却」「必殺技」等の細かい機能単位で
付ける場合もあります。ここで重要なのは「名前があること」です。
名前があることで共通認識化され、開発中もその名称をキーワードに
コミュニケーションがとれるため、無名な状態よりも遥かに便利です。
「参考イメージ」は、仕様書の作成段階では存在しないゲーム画面を、どのような
雰囲気、クオリティにしたいかをイメージするためのものです。当然そのまま同じ
物ができるわけではないですが、デザイナーやプログラマーが「どこに向かって
どのぐらい走ればいいか？」の指標を体感的に感じるためには、実はとても有益です。
「概要」は、細かい機能を説明する前に、「何故その画面が必要なのか？その画面が
あることでゲームの魅力がどうユーザーに伝わるのか？」を端的に書き記した物です。
実はここが無いと、プログラマーやデザイナーは本質的には面白さを理解せずに
作業しているケースが多いです。ですんので必ず書いて、しっかり共有しましょう。

8.
4. ポイント！
１・入手したキャラクターの表情やセリフが楽しめ、より愛着が沸くこと
２・必要な機能がわかりやすく整理、表示されていること。また、簡単にアクセスできること
３・プレイヤーが興味を持つ新しい情報が、常に分かる状態にすること
5. 機能一覧
１・キャラクターのビジュアル、表情、セリフを見る
２・イベントやガチャなどの最新情報をキャッチできる
３・残行動コスト、回復時間のチェックができる
４・プレイヤーレベル、次レベルまでに必要な経験値のチェック
５・各種メニューへのアクセス
・クエスト ・デッキ ・ショップ
・ガチャ ・サイドメニュー
解説
「ポイント！」は、概要をより簡潔にまとめたものです。ここで重要なのは、
同じ機能を作る場合でもどういった点に注意して作ることで、より魅力的
で「ユーザー満足度」が高くなるかを、敢えて言葉にすることです。
そして、あれもこれもというわけにはいかないので、３つぐらいにポイントを
絞って簡潔に書くことが大切です。これがあることで、デザイナーは
「こうすればもっとキャラクターの魅力が引き立つ」と自らアイディアを出して
くれるようになったり、プログラマーが「そうすると、こういう機能もあった方が
よりユーザーが使いやすい、分かりやすい」と想定してくれます。
意外とここを書かないプランナーが多いので、作る前の段階からどういう
魅力のある画面にしたいかを強くイメージして、言葉にしてみてください。
方や「機能一覧」は言葉通り、その画面で出来る機能全てを一覧化し、
システム的に何が必要かを差したものです。当然上記だけでは全然情報が
足りませんが、詳細は別途記載しても構わないので「このシステム要件を
満たすためには何が必要か」が伝わることが大切です。また、スケジュールの
都合から何かしらの機能を削らないといけない場合等に、優先順位を
付けておく意味合いもあり、最悪の場合は一番優先度の低い機能を
削る、などの判断もこれがあることで素早く行うことができます。

9.
メーカーロゴ タイトル お知らせ ローディング ホーム 他シーン
ホーム
クエスト デッキ ショップ ガチャ サイドメニュー
キャラクター
（中央）
【通信】最新データチェック
通信エラー 最新データあり 最新データなし
クエストトップ
へ遷移
デッキトップ
へ遷移
ショップトップ
へ遷移
ガチャトップ
へ遷移
サイドメニュー
トップを表示
キャラクター
詳細を表示
最新データ取得
エラー
ウィンドウ
OK
キャラクター
テキスト
キャラクター
セリフ表示変更
タイトルに遷移
不正通信
エラー
ウィンドウ
OK
インフォメーション
バナー
該当シーンに
遷移
キャラクター
（左右）
キャラクター
を切り替え
シーン 処理操作 表示
6. 基本フロー
7. シーケンス図
解説
「基本フロー」は、該当する画面の“前後”に、他のどのような画面が入るかを表しています。ゲームでは、「お金がある、ない」「特定のアイテムを持ってい
る、持っていない」など、プレイヤーの状態によって条件が分岐することがありますが、フローではそういった細かい条件については書かず、「どの画面か
らアクセスできるか、どの画面に行くことができるか」だけを簡潔に記載すれば問題ありません。
「シーケンス図」は、フロー図では記載していない細かい条件を書きます。先ほど言った「条件」によって変わるという部分も“全て”書き記す必要がありま
す。設計図としての精度が求められるため、作成の段階でプランナーはそのゲームを何度も“脳内プレイ”して、不足が無いか、分かりやすいか、魅力的
か、等を想定する必要があります。また、シーケンス図はプログラムやデザインにも影響が強い箇所なので、ある程度できた段階でスタッフに見せて、意
見交換や指摘をもらった方が、より精度の高い資料として作ることができます。

10.
【A】ユーザーステータス
「１・行動コスト：APT」 最小０～最大９９＋ゲージ
「２・行動コスト回復時間：Time」 １回復までの時間（全回復までの時間）
「３・レベル：LV」 最小１～最大９９９
「４・経験値：EXP」 最小１～最大９９９９９＋ゲージ、次レベルまでの残経験値
「５・ゴキストーン所持数」 最小０～最大９９９
【B】背景
・ホームルーム専用の学校の背景が表示されています
【C】キャラクター（中央）
・デッキにセットしているキャラクターが表示されます
・中央に１体、両端に２体表示されています
・中央のキャラはタップするとキャラクター詳細画面に遷移します
【D】キャラクター（左右）
・タップすると、左右の別キャラクターが画面中央に来ます
【E】キャラクターセリフ
・タップするたびに該当キャラクターのセリフをランダムで表示
・３行構成、１行全角１４文字
【F】インフォメーションバナー
・イベントやガチャなどの最新情報のバナー
・タップすると、それに該当する画面へ遷移する
・動的に追加編集できるようにする（画像、遷移先）
【G】メニューボタン一覧 ※左から
「１・ホーム」 タップ→ホームに遷移
「２・クエスト」 タップ→クエストトップに遷移
「３・デッキ」 タップ→デッキトップに遷移
「４・ショップ」 タップ→ショップトップに遷移
「５・ガチャ」 タップ→ガチャトップに遷移
「６・サイドメニュー」 タップ→サイドメニュートップに遷移
【H】ノティフィケーション
・該当メニューに未確認情報がある場合に数値が表示されます
・最小１～最大９（※９以上の場合でも９を表示）
※各メニューごとのノティフィケーション詳細は別途記述
Character
Time 2:55 (15:02:55) LV 999 ●999
APT EXP
Character text
Character text
Character text
information
3
A
C
B
D
G
E
H
F
8. 画面、操作仕様 (1/2)
操作仕様
■ タップ反応あり ■ タップ反応なし、OFF状態
□ タップ反応なし or タップ不可 ■ 諸条件で動的に変化
解説
画面、操作仕様書のサンプルです。左側が完成図、右側が機能分解して各機能ごとにアルファベットを付けた物です。アルファベットごとの機能説明が右側のテ
キストです。ここでキッチリ書くべき内容は「画面要素、画面構成、操作方法、機能説明、数値」の５つです。もし、画面が無くて右側のテキストだけでは、デザイ
ナーはどんな画面にすれば良いのか分かりませんし、プログラマーも機能は分かったけど、どういうプログラムを書けば良いのかが分かりません。構成、は画面
のどこにどんな大きさで何が置いてあるか、を差しています。会社に寄ってはここをデザイナーが担当するケースもありますが、ユーザー体験（本質的な意味で
のUX）においては、プランナーから「何故そのような体験、感覚を与えるべきか」という意味で、イニシアチブをとらなければいけません。
例えば「操作ボタンが全部画面の上側にあったら→操作しづらい＝ストレス」となるため、そう言った設計は避けるべきだと分かります。こういった事は、デザイ
ナーに自由勝手にやらせるのではなく、「どんな体験をさせたいか、させたくないか」をちゃんと共有するためにも、とても大切です。

11.
読み込み 通信エラー（１）
CAUTION!!!
通信ができませんでした。再度通
信を行います。電波の良い場所
でプレイしてください。
OK
通信エラー（２）
CAUTION!!!
不正な通信データを確認しました。
タイトル画面に戻ります。
OK
A ローディングバー
進捗感をより感じられるよう長めにする
B 数値(0%～100%)
バー＋数値でより進捗を感じられるよう
B キャラクター
バーの“現在進捗位置”に移動する
世界観を感じられる演出として入れる
D Processing
ローディング中は常時点滅させる
音声OFF時でも「画面が止まっていない」
ことを視覚で分かるために入れる
E 背景
最中は現在のシーンを黒50%表示する
画面手前の要素を見やすくするため
A ウィンドウ
警告色の赤色を使用してください。
B ヘッダー
CAUTION!!!
C テキスト
通信ができませんでした。再度通信を行いま
す。電波の良い場所でプレイしてください。
※テキストカラーは白100%
D OKボタン
タップすると再度通信を開始します
E 背景
最中は現在のシーンを黒50%表示する
A ウィンドウ
警告色の赤色を使用してください。
B ヘッダー
CAUTION!!!
C テキスト
不正な通信データを確認しました。タイトル画
面に戻ります。
※テキストカラーは白100%
D OKボタン
タップするとタイトル画面に強制的に遷移
シーン遷移時はブラックでフェードアウト
E 背景
最中は現在のシーンを黒50%表示する
8. 画面、操作仕様 (2/2)
説
明
箇
所
に
は
「
何
故
そ
れ
が
必
要
な
の
か
？
」
と
い
う
補
足
説
明
も
必
ず
入
れ
る
よ
う
に
し
ま
し
ょ
う
。
（
※
赤
文
字
箇
所
参
考
）

12.
デザイナーさんへ
・キャラクターの台詞下敷きは透明度（１０％）を入れてください。そうすることで、空間を広く感じるようにしたいです。
・画面下部のメニューボタンはそれぞれ「現在選択中のシーン、非選択のシーン、非選択をタップ時」の３種類ずつ用意してください。
・ボタンのシンプル感は、◯◯◯ゲームを参考にしてください。（色は△△△ゲームが良いです）
・キャラクターは画像が大きいので、メモリ軽量化のために恐縮ですが、256色に必ず減色してください。
・警告ウィンドウなどのボタンの位置、大きさは仕様記載内容に沿ってください。左右どちらが利き手でも、親指で簡単に押ようにするためです。
プログラマーさんへ
・タイトル画面からホーム画面に遷移する時に、以下４つの情報を取得してください。
１・ユーザー情報（レベル、次のレベルまでに必要な経験値、現在の残アクションポイント、アクション全回復までの時間）
２・デッキにセットしているキャラクターの画像（１～５）、各キャラクターのホーム用台詞情報
３・各種ノティフィケーション（プレゼントボックス未確認、新規カード未確認、フレンド申請未確認、一日一回無料ガチャ未プレイ）
４・バナー画像、それに伴うリンク先情報
・ホーム画面のキャラクターは頭～太ももぐらいを入れてください。
・キャラ中央、キャラ左右、台詞、バナーは右図の“矩形”でタップ判定をとってください。
・キャラクターは左右タップでも変更できますが、スワイプ操作でも変更できるようにしてください。
※スワイプの最初と最後に加減速を入れて、よりそれっぽくしてください。
・5sサイズの場合は上下端に専用画像を入れてください。
9. メモ
10. 関連項目
・ホームで使用するサウンドは以下です。
・最新のサウンドファイルは共有の「Fhogehoge/hogehoge/sound」を参照してください。
１・メニュー専用ボタンタップ音(se_001.caf)
２・汎用ボタンタップ音(se_001.caf)
３・ウィンドウ開く (se_010.caf)
４・ウィンドウ閉じる(se_011.caf)
５・警告ウィンドウ表示(se_012.caf)
６・キャラ台詞フキダシタップ(se_020.caf)
７・キャラ変更移動音(se_021.caf)
８・ホーム用BGM「ゴキブリ君！さぁ冒険だ！/ remix ver.」(bgm_002.caf)
解説
メモ、と関連項目で一番重要なのは、「１～８までで、書けなかったことを全部書くこと」です。「資料を受け取る相手が
欲しい情報」を全てキッチリ書くことで、よりスムーズなゲーム開発を行うことが出来るようになります。多分ね。

13.
出題「仕様書とは何かを答えよ」
1. 設計図
2. 航海図
3. 恋文
4. 脚本
5. 契約書
２点問題
正解は次のページ

14.
正解「たぶん全部」
仕様書は当然ながら設計図としての役割が非常に強いですが、引いては「１
つの面白いサービスを仲間と一緒に作るための、航海図」という考え方もでき
ると思いますし、本質的にはそちらの方が重要だと考えます。精度の悪い航海
図では仲間全員がバラバラの行動をとってしまい、最終的には船が挫傷したり、
船員が脱落することもあります。
相手が受け取って嬉しいもの、理解してもらえるもの、と考えた時に、恋文
という考え方もとても重要で、ラブレターに書くべき内容というのは、「自分
がいかに貴方を好きか？」を羅列しただけのものでは、相手は喜びません。こ
んなステキな手紙をもらった！と思ってもらうには相手を知ることが重要です。
相手ありきで仕様書は作れると考えれば、おのずとどんな内容や言葉がそこに
無ければいけないかが、自分本位よりは遥かに見えてくるのではないでしょう
か？脚本、はそれに対して「何をしてほしい」が加わった感じでしょうか。
契約書に関しては、「この設計図がある以上は、約束通りきっちりと製品を
作ってください。」という意味があります。よく「仕様書ねーのに作れるか
ヴォケカスっ！！」と言いたい放題のスタッフがいますが、であればキッチリ
作ってしまえば相手も納得しますし、言い訳無用な状態をこちらがコーディ
ネートできるわけです。

15.
姉妹スライドもヨロシクね♪

16.
お目汚し、マヂ恐縮です。
Twitterはコチラ
@Osamu_Ohkubo