ゲームの仕様書を書こうまとめ
•
95 recomendaciones•68,850 vistas
ゲームの仕様書を初めて作成する人のための足掛かりのスライド ▼以下のスライドを一つにまとめました ・ゲームの仕様書を書こう１ 仕様書作成の分業とリストの作成 https://www.slideshare.net/ChizuruSugimoto/ss-173331109 ・ゲームの仕様書を書こう２ 仕様書に記載する機能内容 https://www.slideshare.net/ChizuruSugimoto/ss-173332578 ・ゲームの仕様書を書こう３ 仕様書に記載するデータと画面 https://www.slideshare.net/ChizuruSugimoto/ss-173333150 ・ゲームの仕様書を書こう４ 仕様書作成で楽をするconfluenceの活用 https://www.slideshare.net/ChizuruSugimoto/confluence-173333413
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a ゲームの仕様書を書こうまとめ
Similar a ゲームの仕様書を書こうまとめ (20)
Último
Último (17)
ゲームの仕様書を書こうまとめ
- 3. このスライドが役に立つとき 3 「ワタシハ シヨウショ チョットデキル」 という人は、このスライドは必要ありません 「はい！ ゲームの仕様書、初めて書きます！」 「みんな… 仕様書… 書き方違う」 …っていう場合はこのスライドを読み進めるといいことあるかも？ お 前 見 込 み ア リ守 破 離 仕様書を書くための一つの型や技を 獲得するためのスライド（守の段階）として活用します 「守破離」を知らない人は検索してね！
- 7. 分業とリストの作成で大事なポイント 7 企画 すること ３ 企画 確認 ２ 仕様 書面化 ２ 要件 精査 ２ リスト 化 １ • 仕様を分割して担当を決定 • 機能リストと機能階層図の作成 • 仕様問題点(issue)リストの作成
- 8. そもそもの話 8 一人で仕様書を全て作成することは、ほぼありません なので、まず仕様書を分割します • 仕様を分割して読みやすさを確保し、早く終わらせる • 作業自体を分割して工数＆工期見積に役立てる • 作業範囲に共通認識を持たせる 分割の目的
- 9. 仕様書項目の分割方針 9 機能単位で仕様を分割する 1. 全仕様を2段階で分割して 「大項目」と「小項目」に分ける 2. まずは、大項目ごとに 担当者を決定する 3. 次に、適性とタスク量を観察し、 小項目毎に担当を割り振っていく • 一つの機能が小項目の一つに なるように分割する • 小項目の分割基準は 画面（UI）毎で判定する • 関連する機能は、別項目に 記載して参照リンクを記載する ２段階で分割 機能=小項目
- 12. リストを作成することによって、以下ができるようになります ゲーム全体で実装するべき機能ボリュームが類推できる マイルストン毎の機能実装＆検証の簡易リストができる 機能リストに「画面数」「ポップアップ数」を記載すると機能単体の規模感がわかる 機能リスト 12 大項目 小項目 項目概要 画面数 Popup 数 Pre α β β2 R 担当者 起動処理機能 初回起動処理 利用規約同意やユーザーアカウント作成 １ ５ 〇 担当Ａ 通常起動処理 初回以降の起動処理 １ ３ 〇 担当Ａ タイトル タイトル画面 １ ２ 〇 担当Ａ ホーム機能 ホーム ゲームのハブとなるホーム画面 １ ４ 〇 担当Ｂ ホームキャラクター表示 ホーム画面内のキャラクター表示部分 － － 〇 担当Ｂ ミッション 日々のプレイヤー行動で報酬を付与する機能 ０ ４ 〇 担当Ｃ （機能リスト例） 分割した仕様をリスト化
- 13. 大項目 小項目 01_起動処理機能 01-01_初回起動処理 01-03_通常起動処理 01-03_タイトル 02_ホーム機能 02-01_ホーム 02-02_ホームキャラクター表示 02-03_ミッション 付番することによって、以下ができるようになります 他メンバーへの仕様確認の際に指定しやすくなる ソートするときに便利（特にconfluenceのサイドバーは名前で自動で並び替えられる） 番号でファイル名を付ける（UIパーツファイルなどで過去に例があった）時に便利 仕様の付番 13 （付番例） 分割した仕様に番号をつける 〇基本の付番方法 ・大項目番号(2桁)_大項目名 ・大項目番号(2桁) -小項目番号(2桁)_小項目名 上記方法でなくてもまったく問題ありませんが、 上記の付番方法は、汎用的で且つ実際に使いやすかったので オススメします
- 14. 【補足】あらかじめ作っておくと便利なリスト１ 14 報酬付与タイプ payload_type バトル ドロップ クエスト 報酬 クエ課題 報酬 ショップ ガチャ ミッション 報酬 運営 付与 ログボ 報酬 無償クリスタル CRYSTAL － － 直接 － － 直接 プレ プレ 有償クリスタル CRYSTALB － － － 直接 － － － － コイン COIN － 直接 直接 － － 直接 プレ プレ キャラピース PIECE プレ － プレ プレ 直接 プレ プレ プレ 武器 WEAPON 直接 － 直接 － － 直接 プレ プレ プレイヤーEXP EXP － 直接 － － － 直接 － － ガチャチケット TICKET － － － － － 直接 プレ プレ AP AP － － － 直接 － － － － 各種アイテム ITEM － － － 直接 － 直接 プレ プレ （報酬付与タイプリスト例） ※本当はもっとたくさんの報酬付与シチュエーションがある 〇報酬付与タイプリスト（payload_typeのリスト） プレイヤーに報酬などで付与するものは複数のタイプがあり、各仕様にまたがって記載されがち 先にリストを作成し、一元化した記載を行い、各仕様にはリンクのみを記載する リスト内で「直接付与」か「プレゼントボックス付与」を指定する 報酬付与タイプ自体の簡易説明を記載し、関連仕様にリンクを記載できる（※下の例では行っていない）
- 15. 【補足】あらかじめ作っておくと便利なリスト２ 15 （文字数リスト例） 〇文字数リスト DBに記載した文字列を表示するなど可変のテキストの文字数を記載するリスト 他にも、UIレギュレーションで折り返し文字列を規定するときに使用してもよい もちろん、各仕様書に書かれてもよいが、複数の職種が閲覧する（UIアーティストとサーバーエンジニアなど）場合 一つのリストにまとめて、各仕様からリンクを貼るときに便利に扱える時がある 記載個所がまとまっているので、追加や変更時のコストが低い 大項目 小項目 内容 文字数 備考 02_ホーム機能 02-05_プレゼントボックス プレゼントボックス格納理由 全角20文字 03_編成機能 03-03_キャラクター詳細 キャラクター名 全角12文字 03_編成機能 03-03_キャラクター詳細 キャラクター二つ名 全角6文字 03_編成機能 03-03_キャラクター詳細 キャラ説明解放情報 全角64文字 09_メニュー 09-02_アイテムインベントリ アイテム名称 全角16文字 09_メニュー 09-02_アイテムインベントリ アイテム説明 全角32文字 10_ストーリー 10-01_ストーリー呼び出し あらすじ 全角64文字 10_ストーリー 10-02_ストーリースクリプト 通常会話ダイアログ 全角72文字 全角24文字×3行
- 16. 【補足】あると便利な仕様 16 〇画面/ポップアップ基本構成 詳細な画面デザインはUIアーティストに任せますが、以下を仕様として決定しておきます 対応する機種の想定リスト 対応するアスペクト比と対応方法（ノッチやホームインジケーター類の領域確保も含める） ※実際の対応方法はUIアーティストとクライアントPGに任せ、 「どの機種に対応したいか」「何を犠牲にしてもいいか」などの対応方法の指針を示す ポップアップ表示時の画面外の表示とタップした時の処理方針 Android機種でBackキーを押下したときの処理方針 リストを表示する部分で、リスト内に表示するものがない場合の代替表示方針 〇ソート/フィルタ基本構成 詳細な画面デザインはUIアーティストに任せますが、以下を仕様として決定しておきます ソート（並び替え）、フィルタ（切り替え）の基本的なインターフェイス指定 ラジオボタン・チェックボックス・プルダウンなどの画面パーツの指定 項目の保存期間（アプリを立ち上げている間のみ保存するか、ユーザー毎に永久に設定を保存するか） 動的な項目の場合、アップデート時にどのように対応したいかをクライアントPGと相談して決定
- 17. 【補足】忘れがちな仕様 17 〇例外処理 詳細な例外処理実装はエンジニアに任せますが、以下を仕様として決定しておきます 「インゲーム中にアプリが強制終了した場合」の処理方針 「ストレージが足りなくなった場合」の処理方針 「日次のリセットタイミングを挟んだ場合」の処理方針 〇既読処理 詳細な既読処理実装はエンジニアに任せますが、以下を仕様として決定しておきます アイコンやタブの新着バッジのなくなるタイミングの方針 プレゼントボックスの新着バッジの扱いの方針（未読時に表示か未取得時に表示か） ヘッダーやフッターなどグローバルなメニューでの新着バッジ表示の方針 〇ムービー再生とローディング（ダウンロードを含む） ローディングとムービー再生はコンテンツによっては密接に関係することがあります。以下に気を付けて仕様を決定します ムービーの解像度別（高解像度と低解像度）の再生とダウンロード 各種ローディング画面の種類の記載と、シチュエーション別のローディング画面表示の方針 初回の大容量ダウンロード時にムービーをどのように再生させるかの方針
- 18. 機能階層図を作成することによって、以下ができるようになります 一つ一つの機能にどういう「つながり」があるか分かる リストと一緒に図示することで、機能リストの内容がより分かりやすくなる 機能階層図 18 リスト化した機能を繋げる 通常起動処理 ホーム ログインボーナス ミッションタイトル 第１階層 第２階層 第３階層 機能リストの項目をノード（機能 名を記載した四角形）で記し、 ノードのつながりを矢印で記載する 階層の深さがそのまま遷移の深さ の指標となる （機能階層図の例）
- 19. 【例】よくあるスマホゲームの機能階層図 19 起動処理 ホーム 編成トップ バトル編成 武器装備 キャラクター詳細 武器詳細 助っ人選択 育成トップ キャラレベルアップ キャラ上限解放 武器レベルアップ 武器上限解放 ガチャトップ 課金ガチャ 無料ガチャ ログインボーナス プレゼントボックス クエストトップ ミッション 特殊クエスト 課金チャージ購入 オプション プロフィール アイテム購入 ムービー再生 ヘルプ・問い合わせ メインクエスト D/Wクエスト バトル バトルリザルト メニュートップ お知らせ コンティニュー バトル用オプション チュートリアル PUSH通知 ローディング ストーリー呼び出し 例外処理 サブチュートリアル ヘッダー/フッター 既読処理 ストーリースクリプト プレイヤー/エネミー情報 フレンド タイトル 文字数リスト 報酬付与系タイプリスト 助っ人選択 デイリーリセット 効果音/BGM/ボイス ヘッダーで遷移可能 ヘッダーで遷移可能 画面/ポップアップ基本 ソート/フィルタ基本 アイテムインベントリ
- 20. 仕様問題点は以下の時に、都度都度、書き出してリスト化します 要件が決まっていなく、仕様に穴ができてしまう場合 実装者と相談しないと仕様が決定できない場合 仕様に誤りがある時（いずれ仕様を修正するというメモ書き） 仕様問題点（issue）リスト 20 STATUS 大項目 小項目 問題点 対応 担当者 NOT YET その他機能 端末引き継ぎ 有償クリスタルの扱いを社内共通検討 担当Ａ DONE 編成機能 バトル編成 衣装替えキャラを同じ編成に入れられるか 編成可能で仕様作成 担当Ｂ DONE 編成機能 武器装備 表示切替がない フィルタポップアップで仕様作成 担当Ａ WORKING その他機能 バナーリンク バナーのページネーションがない 担当Ａ ABORT バトル機能 バトルオプション スキルアニメスキップに「その日だけ」がない 却下します 担当Ｃ NOT YET バトル機能 ＊新規＊ PVPをいれたいという要望がある 要件決定後に検討 担当Ｃ 仕様作成時の問題点を書き出す （問題点リスト例）
- 21. 【補足】それぞれのリストの作成ツール 21 Google SpreadSheet Confluence Wrike Redmine Jira 機能リスト △ ◎ × × × 報酬付与タイプリスト △ 〇 × × × 文字数リスト △ ◎ × × × 仕様問題点(issue)リスト △ △ 〇 〇 △ 「コレ！」というものはありません。それぞれの組織や状況によって 使用するツールは違います。独断と偏見な個人的オオスメは以下 （この場合、仕様書類をconfluenceで作成する想定です）
- 24. 期待される効果 24 企画 すること ３ 企画 確認 ２ 仕様 書面化 ２ 要件 精査 ２ リスト 化 １ 企画 すること ３ 企画 確認 １ 仕様 書面化 ３ 要件誤りや 伝達ミスの手戻り ３ 伝達ミスによる手直しの削減 仕様の抜け･重複記載を防ぐ • 仕様を分割して担当を決定 • 機能リストと機能階層図の作成 • 仕様問題点(issue)リストの作成 理想 現実 「企画すること」「企画確認」「要件精査」に注力できる
- 26. リスト 化 １ 企画 すること ３ 企画 確認 ２ 要件 精査 ２ 仕様 書面化 ２ 記載する機能内容の大事なポイント 26 • 仕様書記載のルールを決定 • 機能の目的を策定 • 適切な表現方法で仕様を記載
- 29. 仕様書の標準記載ルール例 29 大見出し 小見出し 内容 仕様書タイトル 仕様書のタイトル 更新履歴 仕様書の更新履歴。日付・変更タイトルや変更した概要・変更者を記す 目次 仕様書の目次 [機能名]とは 機能の概要を記載する [機能名]の目的 どういった意図で機能を開発するかを記載する [機能名]について 個別に書き記す機能がある場合に記載する データ構造 データに関する内容を記載する。ほとんどの場合マスター（static）データ項目を記載する [機能名]のデータ構造 各データの関係を図示する。一つの機能に単一のデータの場合はこの項目は必要ない [機能名]のデータ 機能が必要とするデータ項目の名称・内容・カラム名を表組みで記載する 処理 必要であれば、機能が必要とする特筆すべき処理を記載する [機能名]の処理 特筆すべき処理があれば、必要に応じて記載する 画面 機能が必要とする画面を網羅して記載する [画面]の流れ 機能の画面遷移図・フロー図を記載する [画面名]の画面 画面の詳細な内容を図と表で記載する 備考 何か必要があれば記載する
- 30. 【例】ミッション機能の仕様記載項目 30 大見出し 小見出し 内容 仕様書タイトル 【ミッション仕様】 更新履歴 目次 [機能名]とは ・ミッションとは ・ミッションの「達成」の定義 [機能名]の目的 ・ミッションの目的 [機能名]について ・ミッションの分類 ・ミッション達成の判定タイミング ・ミッション達成時の表示 ・ミッション報酬の付与 ・ミッションのリセットと進行状態の破棄 ・ミッションのバッジ表示 データ構造 【ミッションのデータ構造】 [機能名]のデータ構造 ・ミッションのデータ構造 [機能名]のデータ ・ミッションの基本データ ・ミッション達成条件のデータ ・ミッション補助遷移のデータ ・ミッションの標準説明データ 画面 【ミッション画面】 [機能名]の画面の流れ ・ミッションの流れ ・ミッション画面のタブ自動遷移の流れ [画面名]の画面 ・進行中ミッション画面 ・プレゼントボックス格納案内ポップアップ ・アイテム詳細ポップアップ ・完了済みミッション画面 ・ミッション達成時のドロワーポップアップ 備考
- 31. 仕様書作成時に決める最初のルール 31 仕様書作成時にルールや決定者を決めておくと、 実際に記載するときにスムーズに作成することができます 決定事項 決定事項詳細 ルール例 決定者 テキストルール 丁寧語の扱い 進捗管理担当 句読点 文末に句点（。）は使用しない。文中であれば使用する ※仕様書内のテキストルールのみ適用。ゲームテキストには適用しない 進捗管理担当 文語体の記載 ・「もの」「こと」を避ける ・「～を行う」「～をする」を避ける ・「～として」の使用は注意する ・「～ようなとして」の使用は注意する ※ただし日本語自体が難しいので心がける程度でいい 進捗管理担当 仕様書全体の目次 進捗管理担当 世界観用語 世界観設定担当 システム用語 担当企画者 仕様書タイトル あらかじめ機能リストを作成し、英語のタイトルを策定して、リストを作成する ※confluence仕様時はすべて英語の場合URLが分かりやすくなる ・機能リストは 「00-01_function_list」 ・ホーム仕様は 「02-01_home_spec」 ・ホーム表示するキャラ仕様は 「02-02_homecharacter_spec」 ・ログインボーナス仕様は 「02-04_loginbonus_spec」 進捗管理担当
- 32. 機能の目的を記載するメリットは？ 32 • みんなで同じことを考えて作るため • 書類にして伝達の抜け漏れを防ぐため
- 35. コンテンツ目的 機能の目的思考（2/2） 35 プレイヤー 要望･感情 モチベーション 開発内容 ○○させる ○○させる ○○したい ○○でいいかな？まず○○しよう ○○もらえる ○○機能 ○○機能 ○○機能 ○○したい 目的から必要な機能を導き出す 目的と機能をつなげるための ワークシート ○コンテンツ目的 ○プレイヤー要望、 感情、モチベーション ○開発内容 以上の3つのレイヤーをつなげ ると、目的から作るべき機能 が、より明確になります 【目的のワークシート】
- 37. 仕様に記載する「機能の目的」 37 仕様書には表形式で記載する 機能の目的 プレイヤー要望、感情、モチベーション 開発内容 初期プレイヤーの継続 「チュートリアル後に何をしたらいいかわからない」 「次のミッションは何をしたらいいかわからない」 • メインミッション機能 • ミッション解放制御機能 • 新着バッジ表示機能 初期プレイヤーの継続 「キャラキャラや武器などゲームの資産を築きたい」 • 報酬付与機能 初期プレイヤーの継続 「達成したミッションがわからなくなった」 • 達成バッジ表示機能 短期的な目標 「特に目的なく起動した。何をしよう」 • デイリーミッション機能 短期的な目標 「数日続けて価値のあるアイテムをゲットしたい」 「日付がかわるまでに達成したい」 • デイリーミッション機能 • ウィークリーミッション機能 • ミッションリセット時間制御機能 短期的な目標 「イベントでもっと遊びたい」 • イベントミッション機能 仕様書には、目的ワークシートを記載することはコストが高すぎるので… 図を表形式に変換し「機能の目的」「プレイヤー要望、感情、モチベーション」「開発機能」を表記します （ミッション機能の目的例）
- 39. わかりやすく伝えるための表現方法 39 機能の概要など、短い文章で完結に説明する基本的 な表現方法です 項目に対して2つ以上の適用がある際に効果的です （例）ミッションの分類 以下の場合の表現に効果的です 列挙される項目が３個以上の場合 同じ粒度の項目を列挙する場合 適用や項目軸が単体の場合 文章で説明しにくい状態を補填する時に効果的です （例）実績解除型とは プレイヤーが任意にミッションを受託選択することなく、 常時ゲーム進行を監視して、条件達成したミッションを案内する 表組み 箇条書き文章 図示 分類 リセット 期限 目的 メイン × 無し 初期･通期のゲームサポート ウィークリー 週ごと 週ごと 毎日の積み重ねで長くプレイ デイリー 日ごと 日ごと 毎日ログインしてプレイ イベント × 指定日 運営イベントの報酬や誘導
- 41. 【例】それぞれの表現方法 41 「実績解除型ミッション」とは、プレイヤーが任意にミッションを受託選択することな く、常時ゲーム進行を監視して、条件に合致したミッションを発生させる また条件を達成したミッションがあればプレイヤーにその案内を行う。案内された達 成状態のミッションはプレイヤーが「完了」処理を行い、報酬を受け取る 本ゲームは「実績解除型ミッション」を採択する 本ゲームのミッションは「実績解除型ミッション」を採択する。受託などは行わない 実績解除型ミッション 発生：条件を満たせば発生 達成：条件を満たせば達成。案内をする 完了：プレイヤーが任意に完了させる。報酬を付与 受託達成型ミッション 発生：条件を満たせば発生 受託：プレイヤーが任意に受託。同時受託数に制限 達成：条件を満たせば達成。案内をする 完了：プレイヤーが任意に完了させる。報酬を付与 箇条書き文章 本ゲームのミッションは「実績解除型ミッション」を採択する。受託などは行わない 表組み 発生 受託 達成 目的 実績解除型 条件を 満たせば達成 － 条件を 満たせば達成 任意に完了し 報酬受取 受託達成型 条件を 満たせば達成 任意に受託 条件を 満たせば達成 任意に完了し 報酬受取 図示
- 43. 『なるはや更新』はつらいよ 43 更新コストを考えた仕様構成へ 更新コスト高 更新コスト低 表組み 箇条書き 文章 図示 図や表組は 以下の用途で多く使います ⇒ 機能の目的 ⇒ 機能の分類 更新が少ない要件を記載 箇条書きや文章は 以下の用途で多く使います ⇒ 機能の詳細説明 ⇒ 補足説明 仕様が変更しやすい部分を記載 更新コストと仕様の表現方法 図示や表組は、追加・変更のコストが高く、 内容が変わりにくい部分で使用して更新がつらくないようにする…とか？ 散らばった仕様をまとめる 各仕様に散らばった 共通の項目を一つの 仕様やリストにまとめて、 更新個所を一つにして コストを削減します ツール(confluenceの機能)を使う 「抜粋」を利用して 変更箇所を集約して コストを削減します 仕様書作成の 分業とリスト作成 報酬付与タイプリスト （payload_typeのリスト） 参考 confluence活用 参考
- 45. 期待される効果 45 企画 すること ３ 企画 確認 ２ 仕様 書面化 ２ 要件 精査 ２ リスト 化 １ 企画 すること ３ 企画 確認 １ 仕様 書面化 ３ 要件誤りや 伝達ミスの手戻り ３ フォーマット化して伝達スピードアップ 機能の要旨をチームに共有 仕様書の読みやすさが向上 • 仕様書形式とルールを決定 • 機能の目的を策定 • 適切な表現方法で仕様を記載 理想 現実 「企画すること」「企画確認」「要件精査」に注力できる
- 47. 企画 すること ３ 企画 確認 ２ 要件 精査 ２ リスト 化 １ 仕様 書面化 ２ 記載するデータと画面の大事なポイント 47 • マスターデータの記載 • 画面遷移フロー図の記載 • 画面レイアウトの記載
- 48. プラットフォームストア画面の内容は主にココ データの内容は主にココ 超簡単に書いたスマホオンラインゲームの構造 48 クライアント プログラム インターネット サーバー プログラム マスターデータ ユーザーデータ 超簡単に書いています！ 本当はもっと複雑ですよ！※ 読み込み ダウンロード 書き込み 操作送信 結果受信 モバイル通信 WiFi通信
- 50. マスターデータとは？ 50 インゲームステージの難易度やアイテムの効果やキャラ説明など、運営（ゲーム製作者）が設定するものです 以下の例のような表で記載します ユーザーデータ マスターデータ ゲーム処理 マスター（static）データ ゲームを構成する静的なデータ オンラインゲームはマスターデータの設定が必要です マスターデータが必要ない機能もあります ユーザー（dynamic）データ ユーザーの現在のゲームの進捗を表す動的なデータ ユーザーデータは仕様書では規定しにくい個所です データベース設計者と一緒に作成しましょう マスターデータとユーザーデータの簡単な概念 書き込み メイン 読み込み ミッション ID ミッション カテゴリ ミッション名 曜日 ミッション 発生条件 ナビ遷移 ナビ 遷移値 達成条件 達成 条件値A 達成 条件値B … 表示 優先順位 1001 MAIN クエスト1-1をクリア ALL APPOINT_QUEST 10101 APPOINT_QUEST_CLEAR 10101 … 10001 1002 MAIN クエスト1-2をクリア ALL 1001 APPOINT_QUEST 10102 APPOINT_QUEST_CLEAR 10102 … 10002 2001 DAILY 任意のクエストを1つクリア MON QUEST COUNT_QUEST_CLEAR 1 … 20001 マスターデータ 覚えておくと 便利だよ！
- 51. マスターデータの記載 51 実際に記載するマスターデータは、以下の要素があります ・テーブル： データのカタマリであり表全体のこと ・カラム： データの内容を決めるものであり列のこと ・レコード： 一つのデータであり行のこと ・フィールド： データの最小単位のことでありセルのこと 仕様書に記載するときは「カラム項目」と「カラムの内容」を重点的に記載します カラム項目 カラム内容 データベースのカラム名 カラム名を記載 カラムの説明を記載 実際のカラム名を記載 マスターが出来るまでは空欄 ミッションID ミッションのID。自動インクリメントではなく、手動で記載 mission_id ミッションカテゴリ ミッションのカテゴリは以下の通り指定する 1：デイリーミッション 2：ウィークリーミッション 3：メインミッション 4：イベントミッション 5：初心者ミッション mission_category ミッション名 プレイヤーが見ることのできるミッションの名称を記載 misssion_name ・・・ ミッション ID ミッション カテゴリ ミッション名 曜日 ミッション 発生条件 ナビ遷移 ナビ 遷移値 達成条件 達成 条件値A 達成 条件値B … 表示 優先順位 1001 MAIN クエスト1-1をクリア ALL APPOINT_QUEST 10101 APPOINT_QUEST_CLEAR 10101 … 10001 1002 MAIN クエスト1-2をクリア ALL 1001 APPOINT_QUEST 10102 APPOINT_QUEST_CLEAR 10102 … 10002 2001 DAILY 任意のクエストを1つクリア MON QUEST COUNT_QUEST_CLEAR 1 … 20001
- 52. テーブル（表）が複数あり、それぞれに 関係がある場合は関係性を記載します • テーブルはアイコンとデータ名称で記載 • 関係性は矢印でつないで記載 • マスターとユーザーは別の色で記載 • 矢印の向きに注意 データ構造と正規化 52 データ構造 ゲーム進捗 プレイヤー情報 ミッション データ ミッション説明 データ ミッション データ ミッション説明 データ ▼ミッション説明からミッションへの指定がある場合 ミッション データ ミッション説明 データ ▼ミッションからミッション説明への指定がある場合 正規化の簡単な概念は以下です • データに関係性を持たせつつ、 テーブルを分割する • データ入力のコストを削減する • データの重複と矛盾を排除する • データアクセスの効率化 正規化の簡単な概念 ユーザ ID ユーザ名 住所 送料 区分 送料 日数 目安 U001 すぎもと 東京 関東 980円 1～2日 U002 すずき 神奈川 関東 980円 1～2日 U003 たなか 沖縄 離島 2380円 5日～ ユーザ ID ユーザ名 住所 区分 U001 すぎもと 東京 K001 U002 すずき 神奈川 K001 U003 たなか 沖縄 K002 区分 ID 送料 区分 送料 日数 目安 K001 関東 980円 1～2日 K002 離島 2380円 5日～
- 53. 【例】ミッション機能のデータ（1/2） 53 カラム項目 内容 カラム名 ミッションID ミッションのID。自動インクリメントではなく、手動で記載 mission_id ミッションカテゴリ ミッションのカテゴリは以下の通り指定する 1：デイリーミッション 2：ウィークリーミッション 3：メインミッション 4：イベントミッション 5：初心者ミッション mission_category ミッション名 プレイヤーが見ることのできるミッションの名称を記載 曜日 ミッションカテゴリがデイリーミッション時に以下の通り指定する ALL：すべての曜日 SUN：日曜日 MON：月曜日 TUE：火曜日 WED：水曜日 THU：木曜日 FRI：金曜日 SAT：土曜日 week 表示優先順位 表示の優先順位を規定する。数字が若い順に並び替える mission_order ミッション説明 プレイヤーが見ることのできるミッションの説明を記載 ミッションの説明は個別に記載できるが入力をしない場合はミッション達成条件に基づいて定形文章が表示される mission_description ミッション発生条件 ミッションが発生する条件のミッションIDを指定する unlock_mission_id ナビゲーション遷移 ミッション補助遷移を指定する navi_type ナビゲーション値 ナビゲーション遷移によって指定する値が変わる（内容は「ナビゲーション遷移コンテンツの指定」のデータを参照） navi_value 開始日時 当該ミッションが開始する時刻をyyyy/mm/dd hh:mm:ssで指定する start_date 終了日時 当該ミッションが終了する時刻をyyyy/mm/dd hh:mm:ssで指定する end_date 達成条件 ミッション達成条件を指定する（内容は「ミッション達成条件」のデータを参照） mission_type 達成条件値1 上の達成条件によって指定する値が変わる（内容は「ミッション達成条件」のデータを参照） mission_type_value1 達成条件値2 上の達成条件によって指定する値が変わる（内容は「ミッション達成条件」のデータを参照） mission_type_value2 付与物タイプ 報酬の種類を以下の通り指定する（payloadtypeリストを参照） ITEM：アイテム / CHARA：キャラクター / WEAPON：武器 / GOLD：ゲーム内通貨 / COIN：課金通過 reward_type 付与物ID 付与するアイテム/キャラクター/武器のIDを指定する ※付与は1種類とする reward_id 付与物数 付与する数量を記載 amount
- 54. 【例】ミッション機能のデータ（2/2） 54 ナビゲーション 遷移先指定 遷移先内容 ナビゲーション 遷移値 HOME ホーム画面に遷移 QUEST クエスト一覧画面に遷移 APPOINT_QUEST 指定したクエストが表示されるクエスト一覧に遷移 クエストID GACHA ガチャ画面に遷移 CHARA キャラクター一覧に遷移 ▼ナビゲーション遷移詳細コンテンツの指定 ミッション 達成条件指定 達成条件内容 達成条件値 [val1] 達成条件値 [val2] APPOINT_QUEST_CLEAR [val2]クエストを[val1]回クリアすると達成 クリア回数 クエストID COUNT_QUEST_CLEAR 任意のクエストを[val1]回クリアすると達成 クリア回数 TYPE_QUEST_CLEAR [val2]タイプのクエストを[val1]回クリアすると達成 （クエストタイプ：メインクエスト・日常クエスト・ゲリラクエスト） クリア回数 クエストタイプ APPOINT_QTASK_COMPLETE [val2]クエストのクエスト課題（☆３つ）を全て達成する クエストID ACHIEVE_CHARA_LEVEL 任意のキャラのレベルを[val1]にする キャラレベル APPOINT_CHARA_LEVEL キャラクター「[val2]」のレベルを[val1]にする キャラレベル キャラID COUNT_DEFEAT_ENEMY 任意のエネミーを[val1]体撃破する エネミー体数 TYPE_DEFEAT_ENEMY [val2]タイプのエネミーを[val1]体撃破する（エネミーの属性や種類など） エネミー体数 エネミータイプ TYPE_MISSION_CLEAR [val2]カテゴリのミッションを[val1]回クリアする クリア回数 ミッションカテゴリ COUNT_GACHA ガチャを[val1]回引く 施行回数 ▼ミッション達成条件 （ほかにもたくさん達成条件があるがページの関係で割愛します）
- 55. 難しいので、オススメはこちら！ 55 マスターに設定したい項目リストを作る マスターデータとして運営で設定したい項目をリストにします エンジニアはリストから必要な要件を見出して、データ構造を作ることができます • ミッションの名前が設定したい • ミッションのカテゴリを設定したい • デイリーミッションだったら適用される曜日を指定したい • ミッションの画面の中で並び替えを設定したい • ミッションAをクリアしたらミッションBが表示されるようにしたい • ミッションには表示期間を設定したい 運営イベントとかミッション入れ替え時に（大型アップデート）使うのみ • ミッションの説明を自由に設定したい • ミッションの説明を記入しなかったら達成条件で定型説明を表示したい • 報酬を付与したい。報酬は1種類複数個にする • ミッション毎に「挑戦するボタン」で遷移する箇所を変えたい • クエスト一覧 • 指定したクエストが画面にあるクエスト一覧 • ホーム画面 • ガチャ画面 ・・・などなど • ミッションの達成の条件を設定したい • 任意のクエストを指定回数クリアする • 指定のクエストを指定回数クリアする • 指定のタイプのクエストを指定回数クリアする • 指定のクエストのクエスト課題を全てクリアする ・・・などなど ▼マスターデータとして運営で設定したい項目例（ミッション） ※実装者と相談するとより良い実装ができます
- 56. 画面制作のワークフロー 56 ゲームの画面作成は以下のワークフローで作られる（だいたいの場合） 要件作成 画面遷移フロー図 作成 レイアウト 仕様作成 レイアウト モック作成 デザイン パーツ作成 デザイン モック作成 本データ 作成 組み込み 制作項目 主担当 推奨使用ツール （独断と偏見による）推奨理由 画面遷移フロー図作成 担当企画 まずはドキュメントとしての残すため画面遷移フロー図および画面レイアウト（レイ ヤーフレーム）を画像などで作成。その際には多くの人が使い慣れたツールとして PowerPointを推奨 まとめたドキュメントを残さないのであれば、この項目自体省略するなども可。その 際はレイアウトモックを書類と同等のものとして扱うレイアウト仕様作成 担当企画 レイアウトモック作成 担当企画 遷移および画面を、スマートフォンで確認するためにモックを作成する Adobe XD以外にもツールはあるが組織として知見がたまりやすく、前例が作られ やすいので、シェアの高くなりそうなツールを推奨（組織都合） デザインモック作成 UIアーティスト 最終的な画面のデザインで遷移確認するためにモックを作成する UIアーティストのデザインパーツはAdobe Photoshopで作られる場合が多く、 パッケージ群として選ばれやすいツールを推奨する（組織都合）
- 57. 画面遷移フロー図の記載 57 画面遷移図は愚直に作成＆更新 • フローは左上から右下に流れる。例外もある • 条件分岐はダイヤ形。YESは下。NOは左右どちらか 1つの条件から2つ以上に分岐しない • つながりの矢印線は交差しない • 右図のように要素で図形を分ける • 画面・ポップアップ・警告ポップアップは色を分けておく • 遷移元の操作や画面を記載しておく 画面遷移フロー図の最低限のルール 画面 つながり システム処理 プレイヤー行動 条件分岐 別遷移の呼び出し 画面 ポップアップ 条件内容 完了処理 アイテム詳細 指定画面へ
- 58. 【例】ミッション機能の画面遷移 58 判例 画面 ポップアップ 警告ポップアップ SDK利用 ホーム画面から デイリーミッション メインミッション ウィークリーミッション イベントミッション 進行中ミッション デイリーミッション メインミッション ウィークリーミッション イベントミッション 完了済みミッション 報酬受取/一括報酬受取 アイテム詳細 ナビゲーション 所持枠を超えた 報酬がある プレゼントボックス格納案内 アイテム詳細 指定画面へ NO YES 左上から右下に流れる 逆流は例外として 行うこともあり 遷移元を記載する 条件分岐はダイヤ型 YESは下。NOは左右 1つの条件から 2つ以上に分岐しない 画面とポップアップは 色を分ける プレイヤー操作は 点線角丸四角形 別機能への遷移は 専用の図形で作成 画面をまとめるなど 見えやすいように 工夫を行う 完了処理 ゲームの処理は 点線四角形 システム処理は 点線四角形
- 59. 画面レイアウトを記載 59 ワイヤーフレームと表組みで記載 ワイヤーフレームの画面図 戻 ミッション デイリー ウィークリー メイン ？ ステージをクリアしよう 報酬 アイコン 50/999 挑戦する 1 2 3 4 5 NEW！ 6 7 8 9 10 表組みの要素説明部 • 画面図のワイヤーフレームを描画する • 要素の名前と番号を記載する • ボタンは各丸四角形。ラベルは四角形で記載する • ワイヤーフレーム外に表組みで記載する 番号 パーツ 内容 処理 画面図対応 番号を記載 パーツ名を記載 注意点や表示文 言を記載 ボタン押下時の処 理を記載 ワイヤーフレームはPowerPointで作成して画像で保存し、 confluenceに添付します。表組みはワイヤーフレーム外に 記載して、編集部分を二つに分けます 「後から編集しやすい」と「読みやすい」を 両立した記載ルールを構築しましょう
- 60. 【例】進行中ミッションの画面 60 番号 パーツ 内容 処理 1 戻るボタン 戻るアイコンを表示 押下すると、直前画面に遷移する - AndroidBackキー － 押下すると、直前画面に遷移する 2 タイトル 文言「ミッション」 3 ヘルプボタン ヘルプを表すアイコン 押下すると、ヘルプ画面を表示 → ヘルプ/問い合わせ（help_spec）を参照 4 ミッションタブ タブ形式 文言「デイリー」「ウィークリー」「メイン」 選択されて画面が表示されているボタンは不活性状態 押下すると、該当のミッションカテゴリのミッションを表 示する 5 ミッション名 ミッション名を表示 6 報酬アイコン 付与物のアイコンを表示 7 進行数 ミッションの進行を（進行数/必要数）で表示 必要数が4桁を超えた時は項目自体を表示しない 8 進行ゲージ ミッションの進行をゲージで表示 9 新規バッジ 新規ミッションに「NEW」バッジを表示 →既読処理（unread_spec）を参照 10 ナビボタン 文言「挑戦する」 未達成でかつ、ナビゲーションが設定されているときのみ表示 押下すると、ミッション補助遷移で指定された画面 に遷移する 11 報酬受取ボタン 文言「報酬受取」 達成済みでかつ報酬未受取りの場合のみ表示 押下すると、報酬を受け取り、当該ミッションの完了 処理を行う 12 一括報酬 受取ボタン 文言「報酬受取」 報酬受取ミッションがない場合は不活性表示 「デイリー」が表示されている場合はデイリーのみ対象とする 押下すると、一括で報酬を受取、該当ミッションの 完了処理を行う 13 スクロールバー スクロールバーを表示 ヘッダー領域 戻 ミッション デイリー ウィークリー メイン ？ ステージをクリアしよう 報酬 アイコン 50/999 挑戦する 1 2 3 4 5 NEW! 6 7 8 9 10 フッター領域 報酬受取 一括報酬受取 11 12 13
- 61. 【例】進行中ミッションの画面 61 ヘッダー領域 戻 ミッション デイリー ウィークリー メイン ？ ステージをクリアしよう 報酬 アイコン 50/999 挑戦する NEW! フッター領域 報酬受取 一括報酬受取 別仕様に記載されている場合は詳細を記載しない ボタンは各丸四角形で記載する ラベルなど押下するところがなく、テキストのみ を表示する箇所は四角形で記載する ゲージなどはそれとわかるように図を記載する アイコン内容の詳細はワイヤーフレーム外の表組 で記載する リスト表示などで適用を連続で表示することを示 したい場合は、枠のみを記載して読みやすさを担 保する。詳細全てを記載しない 詳細全てを記載しないで、変更のある部分を抽出 して記載する 「戻る」ボタンや、ポップアップの「閉じる」ボ タンは、以下の処理を考慮して表組みに記載する ・AndroidBackキーを押下した場合 ・ポップアップ外を押下した場合 スクロールバーが表示されるかどうかはUIアー ティストに任せるが、要素としてはスクロール バーの領域を必ず記載する 明らかに画像で表示するパーツについては、枠と 概要をワイヤーフレームに記載して、表組みに詳 細を記載する
- 64. 期待される効果 64 企画 すること ３ 企画 確認 ２ 仕様 書面化 ２ 要件 精査 ２ リスト 化 １ 企画 すること ３ 企画 確認 １ 仕様 書面化 ３ 要件誤りや 伝達ミスの手戻り ３ • マスターデータの記載 • 画面遷移フロー図の記載 • 画面レイアウトの記載 理想 現実 「企画すること」「企画確認」「要件精査」に注力できる フォーマット化して伝達スピードアップ 仕様の抜け･重複記載を防ぐ 仕様書の読みやすさが向上
- 66. 企画 すること ３ 企画 確認 ２ 要件 精査 ２ リスト 化 １ 仕様 書面化 ２ confluence活用の大事なポイント 66 • confluenceの長所と短所 • スペースのCSS設定 • 更新履歴と目次のヘッダーセット • ドキュメントのテンプレート • プロジェクトトップページ ※confluenceはサーバー版が対象です。クラウド版ではありません
- 67. 仕様書作成時のconfluenceの長所と短所 67 confluenceの長所 confluenceの短所 • 「ページ」という括りがない • 更新や共有が簡易 • ブラウザで閲覧できる • 横断的なキーワード検索が可能 • ハイパーリンクの挿入が楽 • 便利なマクロがある • 入力が他wikiに比べて楽 • 印刷に向かない • 図の挿入が不自由 • 初期設定がクソ • 便利な機能があるが それがどこにあるか ぜんぜんわからない
- 68. スペースのCSS設定（1/2） 68 ① スペースツール ② ルックアンドフィール ③ スタイルシート ④ 「編集」ボタン ⑤ 設定を入力する ⑥ 「保存」ボタン １ ２ ３ ４ ５ ６ 書類を読みやすくするための最初の設定 初期標準設定のスタイルは行装飾がほとんどされていません 非常に見にくい！（初期設定がクソ案件）
- 69. スペースのCSS設定（2/2） 69 設定例 .wiki-content h1{ font-size: 24px; } .wiki-content h2{ background-color: #eeeeee; font-size: 20px; padding: .1em.2em.1em.2em; } .wiki-content h3{ font-size: 16px; font-weight: bold; border-bottom: dotted 2px #999999; } .wiki-content h4{ font-size: 18px; border-left: 7px solid #888888; font-weight: normal; padding: 0em.3em; } before after
- 71. ドキュメントのテンプレート（1/2） 71 仕様書に記載する 機能内容 仕様書の標準記載ルール例 参考 テンプレート項目例 ページ作成時にテンプレートを利用 confluenceのテンプレート機能を使用してページ作成時に利用することができます ① スペースツール ② コンテンツツール １ ２ ４ ３ ③ テンプレート ④ 「新規テンプレートの作成」ボタン テンプレート登録時
- 72. ドキュメントのテンプレート（2/2） 72 ① 「テンプレートから作成（…）」ボタン ２ １ ② 利用したいテンプレート ③ 「作成」ボタン テンプレート利用時 通常のページ作成時と同じで、 作成したいページの親ページに遷移して「テンプレートから作成」する ３
- 73. メール通知の設定 73 必要のないメール通知は送信させない confluenceの初期設定は、ウォッチにかかわらず、 ページの作成と更新でメールが配信されてしまうことがあります（初期設定がクソ案件） １ ２ ３ ４ ① ユーザーアイコン ② 設定 ③ メール ④ 「編集」ボタン→チェック→「送信」ボタン （「日々の更新を配信登録」チェックくらいでいいかも）
- 74. サイドバーの設定 74 サイドバーはスペースショートカットが便利 よく使うページをスペースショートカットに追加しましょう また「ページツリー」はconfluenceでもっとも使われる可能性が高いです １ ２ ３ ４ ① スペースツール ② サイドバーの設定 ③ 「ページ」「ブログ」は不活性に ④ スペースショートカットを追加 横断的な機能を スペースショートカットに 入れると便利！
- 75. プロジェクトトップページ（1/2） 75 一覧で目にしやすいトップページを作ろう トピックス マイルストン お知らせ 仕様書類 カラム１ カラム２ カラム３ パネルマクロで 見た目を整形 仕様書類の ページ内容を そのまま表示 （ネスト） 仕様書類ページはセクションを利用して 3カラムにして内容を記載する
- 78. 自動更新リンクの工夫 78 プロジェクトトップページでリンクを張りかえる更新が面倒… な場合、 自動で最新版のページにリンクする工夫をすることもできます 自動的に リンクが 更新される 固定リンク ・親ページを指定する ・子ページの数→1 ・子孫ページの深さ→指定なし ・見出しのスタイル→指定なし ・抜粋の表示→none ・子ページで並び替え→creation 更新したいリンク先ページを一つの階層にまとめる 朝会のログなど 最新版を見たい リンクに便利！
- 81. 期待される効果 81 企画 すること ３ 企画 確認 ２ 仕様 書面化 ２ 要件 精査 ２ リスト 化 １ 企画 すること ３ 企画 確認 １ 仕様 書面化 ３ 要件誤りや 伝達ミスの手戻り ３ • スペースのCSS設定 • 更新履歴と目次のヘッダー • テンプレート 理想 現実 「企画すること」「企画確認」「要件精査」に注力できる 自動化で仕様作成スピードアップ 仕様書の読みやすさが向上