ゲームプランナーのための脱Excel仕様書ガイド

── 現場で起きている3つの問題と、モダンなドキュメント戦略

はじめに

多くのゲーム開発現場では、今もなおExcelが仕様書作成の主流ツールであり続けている。あるゲーム業界経験者がX（旧Twitter）上でゲーム業界人に向けて実施したアンケートによれば、ゲーム会社の仕様書はExcelなどの表計算ソフトを使用しているケースが半数近くを占めるとされている。Excelは誰でも知っていて学習コストがかからず、表・文字・図を一つのファイルにまとめられるという強みがある。しかし、そのメリットの裏側では、プランナーの生産性を大きく蝕む問題が慢性的に発生している。[1][2]

本ガイドでは、現場で頻発するExcel仕様書の3つの具体的問題を示し、それを解決するモダンなツールと書き方を提案する。さらに、ディレクターやプロデューサーへの新ツール導入提案の実践的なコツまでをカバーする。

Part 1 ── Excel仕様書、3つの現場あるある問題

問題①：「どのファイルが最新かわからない」バージョン管理地獄

典型的なシナリオ：

仕様書がネットワークドライブに置かれており、各自がローカルにダウンロードして編集→Slackに添付して共有、という運用をしていた。その結果、サーバーにはキャラクターパラメータ_最終.xlsx、キャラクターパラメータ_最終_FIX.xlsx、キャラクターパラメータ_最終_FIX(2).xlsxという3つのファイルが共存。誰も「どれが本当の最新か」を断言できなくなった。

これは珍しい話ではない。Excelファイルによる仕様書管理では「xxxxxxxx_20200223.xlsx みたいなファイルが大量生産され」、最終的にはファイル名を信じるべきかタイムスタンプを信じるべきかすら不明になる。実際の現場報告でも「誰かがローカルで編集中で、ネットワークドライブに上がっている情報は古いかもしれない」という状況が日常的に発生していた。[2][1]

さらに深刻なのが、複数人による同時編集の問題だ。別の担当者がローカルに落として編集していた場合、自分の編集内容と競合する可能性がある。チームが5人・10人と増えるほど、この競合リスクは指数的に高まる。[1]

なぜ起きるか： ExcelファイルはGitのような差分管理の仕組みを本来持っていない。変更履歴欄を「手書きや関数でコツコツ更新する必要がある」のが実情で、これはプランナーの貴重な時間を形式的な管理作業に浪費させる。[1]

図1　バージョン管理地獄（Before）と単一の真実のソース（After）

問題②：「どこに書いてあるか探せない」検索性の壊滅

典型的なシナリオ：

「敵キャラのヘイト計算式ってどこに書いてあったっけ？」と思い、Windowsの検索でファイルを探そうとするが、ファイル内のセルに書かれたテキストまでは検索できない。結局、10個近いExcelファイルを1つずつ開いて、Ctrl+Fで調べるはめに。30分後にようやく別フォルダの別ファイルに書いてあったと判明。

Excelの致命的な弱点の一つは「ファイルをまたいだ検索ができない」点だ。しかも、ファイルの肥大化によって「重いので開かなくなる・見なくなる」という問題も引き起こされる。追加開発の際に既存仕様書が参照されなくなり、「設計書ではなく実装メモに堕落していく」という悪循環が生まれる。[2]

また、Excel内にハイパーリンクを設定して他ファイルを参照している場合、ファイル名変更やフォルダ移動で「リンクが切れる」問題も頻発する。「誰だ仕様書の名前を変えてフォルダを移動したのは！もうその仕様書見つけられないよ！」という状況は、多くのプランナーが経験している。[1]

なぜ起きるか： Excelのデータは構造化されておらず、全文検索エンジンと相性が悪い。ゲームの仕様書は開発中に数十〜数百ファイルに膨れ上がることも珍しくなく、ファイルベース管理では検索コストが線形増加してしまう。[3]

図2　ファイル横断検索の不在と、検索コストの線形増加

問題③：「方眼紙の調整に時間を使う」レイアウト沼

典型的なシナリオ：

新入社員が先輩から「秘伝のテンプレート」を引き継ぎ、A4印刷にぴったり収まるように行間隔を揃えてセル幅を調整し、印刷範囲を設定する作業に半日を費やす。さらに後日、行を1行追加したら図が盛大にずれて元に戻す作業で残業……。

Excel方眼紙とは「エクセルのセルの縦横を同じくらいの大きさに調整し方眼紙のようにして、そこに設計書として文字と図と表を記載する方式」だ。ゲーム業界では多くのプランナーがこのフォーマットを強いられてきた。入社後の研修でありがたく「秘伝のExcelテンプレートをいただき、必死に行間隔を揃えて方眼紙にしたり、A4印刷にピッタリ収まるように範囲を調整したり、最終更新日の日付を欠かさず更新したり」という経験は、業界の多くのプランナーが共有している。[2][1]

問題はこれだけでない。「セル結合や複雑なオートシェイプを使いすぎると、あとからレイアウトの融通が利かなくなったり」、「行や列を追加することで、意外なところで図表や関数が崩れたり」することも常態化している。さらに担当者・プロジェクトごとに異なる独自フォーマットが横行し、「他人の作成した仕様書を更新しづらい。どこが壊れるかわからない」状態になる。[1]

なぜ起きるか： Excelは表計算ソフトであり、文書作成ツールとして設計されていない。方眼紙化は「ないものねだり」の産物であり、本来の用途から逸脱した使い方である。[4]

図3　Excel方眼紙の構造と、行追加で連鎖するレイアウト崩壊

Part 2 ── Excelが「本来の強さ」を発揮できる場面

脱Excelを主張するにあたって重要なのは、「Excelはすべて悪」と言わないことだ。正確には「用途を選べば、Excelは最強ツール」である。

以下の場面はExcelを積極的に使うべきだ：

「表を作るのはExcelの方が向いている」という意見は正しい。Excelは「データの入れ物」として使う場面では無類の強さを発揮する。問題は、これを「文書」として使おうとするときに起きる。[1]

図4　Excelの得意領域（データの入れ物）と不得意領域（文書）

Part 3 ── 代替ツールの選び方と実践的な使い方

ツール1：Markdownテキストファイル ＋ Wiki

どんな仕様書に向いているか： ゲームシステムの説明、フロー・ロジックの記述、UI挙動の定義など「読ませる文章」が主体の仕様書。

Markdownは「#や*のような記号を使って見出しやリスト、強調といった文章の構造や装飾を表現できる」軽量マークアップ言語だ。ゲーム開発文脈でも「技術的な仕様書も、Markdownで記述すれば変更履歴が追いやすく、複数人での編集もスムーズ」とされている。[7][8]

具体的な記述例：

## バトル開始フロー

### 前提条件
- プレイヤーがマップ上の敵シンボルに接触する
- あるいは、プレイヤーが「戦闘開始」フラグを持つNPCに話しかける

### 処理手順
1. バトル画面に遷移（フェードアウト → フェードイン）
2. 先制判定：プレイヤーの`SPD`と敵の`SPD`を比較
   - プレイヤーSPD > 敵SPD × 1.2 → プレイヤー先制
   - それ以外 → 通常ターン順
3. 敵AIの初期行動を決定

### 未解決事項
- [ ] 先制ボーナスの具体的な数値はバランス調整フェーズで確定

このような記述は、Gitとの組み合わせでバージョン管理が可能になる点が最大のメリットだ。git diffコマンドで変更前後の差分が一目瞭然になる。[9]

MarkdownはAIにとってもアクセスしやすい形式であり、「コンピュータが容易に解析できる形式」として近年特に注目されている。AI支援ツールとの親和性は、Excelには到底及ばない。[9]

現場への導入ステップ： 「一気に切り替えるのではなく、『新しく書くものからMarkdownにする』というルールにするだけで、自然に移行が進む」。まず新規機能の仕様書から始め、既存のExcelファイルはそのまま残して参照可能な状態を維持するのが現実的だ。[10]

ツール2：XMind（マインドマップ）→ PDF出力

どんな仕様書に向いているか： 機能の全体像・システム設計のツリー構造・ゲームループの俯瞰図。

XMindは「アイデアや情報を視覚的に整理するためのマインドマッピングツール」であり、「PNG、PDF、Excel、Wordから選んでエクスポートできる」。マップ・ツリー・ロジック・タイムラインなど複数のテンプレートを選択可能で、トピックごとに優先順位や進捗を示すアイコンを付けることもできる。[11][12]

ゲーム仕様書での活用法：

• ゲームシステム全体図：コアループを中心に、各サブシステムを枝として展開
• クエスト分岐マップ：選択肢と結果をツリー状に整理、Excelの方眼紙よりも視認性が高い
• スキルツリー設計：前提条件や解放順序を視覚的に整理

PDFエクスポートすることで、印刷・共有・レビューに耐えられる「成果物」として仕上げられる。Excelの複雑なオートシェイプで描いた図と比べて、更新・修正の手間が格段に少ない。

ツール3：Confluence / Notion（Wikiツール）

どんな仕様書に向いているか： プロジェクト全体のナレッジ管理、複数人が関わる大型仕様書。

ConfluenceはAtlassian社が提供する企業向けWikiツールで、「世界で60,000を超える企業で利用されるグローバルスタンダードな企業向けwikiツール」だ。ゲーム業界でも、ExcelからConfluenceに移行したプランナーが「Excelでミリ単位のセル幅調整をしていたあの頃がアホらしく思えてくる」と評するほどの利便性を持っている。[3][1]

ConfluenceはJiraとの連携が特に強力で、「チケット名やステータスをリアルタイムで反映するので、その仕様に紐づくタスクなどを添付しておけば便利」。タスク管理ツールJiraを既に使用しているプロジェクトなら、Confluenceとの組み合わせは特に推奨できる。[1]

Notionは「個人利用や小規模チームでの利用が多く、その柔軟性と豊富な機能」が特徴で、スタートアップや少人数のインディーゲーム開発チームに向いている。実際にゲーム開発でNotionを活用しているチームでは「運用ルールを提示したうえで各メンバーに自由に使ってもらうと、効率よく資料が蓄積され、ゲーム開発の進行に良い結果をもたらす」という実感が報告されている。[13][14]

ツール4：Figma（UI仕様・プロトタイプ）

UIデザイン・画面仕様書については、Figmaが現在最も有力な選択肢だ。サイバーエージェント（アプリボット）のゲーム開発事例では、新規ゲーム開発のプロトタイピングツールとしてFigmaが導入され、UI設計から画面遷移確認までを一気通貫で行えるようになっている。一般に、Excelによる仕様書では「仕様書作成に時間がかかり、実装ミスが増加」しがちだという課題が指摘されているが、Figmaは「コラボレーション機能やデザインシステムの導入・活用、バージョン管理、さらにはプラグインやAIの活用など、UIデザイナーの日常的な作業を大きく効率化」する。画面遷移図やワイヤーフレームを直接仕様書として扱えるため、従来のExcelによるUI仕様書より遥かに実態を伝えやすい。[15][16][17]

Part 4 ── ツールの使い分け：仕様書の種類別マトリクス

仕様書の種類によって最適なツールは異なる。「Excelをすべて捨てる」ではなく「用途ごとに最適なツールを使う」が正解だ。

図5　仕様書の種類別・ツール選定フローチャート

Part 5 ── ディレクター・プロデューサーへの提案術

新ツールの導入で最も高い壁は、技術的な問題ではなく 組織的な慣性 だ。ここでは、上位職者への提案を成功させるための実践的なアプローチを解説する。

提案の大原則：「敵を作らない」

強固なExcel派に「Excelは悪だ」と正面衝突すると、提案は必ず失敗する。「Excelを否定しているのではなく、Excel本来の強さを活かしながら、苦手な部分を補うツールを追加したい」というフレームで話すことが重要だ。[1]

ステップ1：問題を「数字と体験」で可視化する

感情論では人は動かない。「仕様書を探す時間」「フォーマット調整の時間」をざっくりでも記録・計算しておくと説得力が増す。

例：「先月、自分が仕様書の最新版確認に使った時間を計ったところ、週に約2時間でした。チーム5人で計算すると月40時間のロスです」

これは誇張ではなく、Excelベースのプロジェクトでは「検索性が悪いので、作った人に聞くがベターな解決策になる」という状況が「将来を見据えて設計するモチベーションがわかなくなる」事態を招いている。[2]

ステップ2：小さく始める「パイロット提案」

「プロジェクト全体の仕様書をConfluenceに移行したい」と一度に提案すると、コスト・学習コスト・リスクへの不安から却下されやすい。

おすすめは「新規実装の1機能分だけ、MarkdownかConfluenceで書いてみていいですか？」という限定提案だ。「新しく書くものからMarkdownにする」というルールにするだけで自然に移行が進んでいく。1つ成功例を作れば、次の提案が通りやすくなる。[10]

ステップ3：上位職者のニーズに合わせた「翻訳」

ディレクターとプロデューサーでは気にするポイントが異なる。

• ディレクターへの訴求：「仕様書の最新版が誰でもすぐ見つかるようになり、実装ミスが減ります。アップデートの反映確認も速くなります」
• プロデューサーへの訴求：「新メンバーのオンボーディング時間が短縮でき、開発効率が上がります。コスト対効果を数字でお見せできます」

Jiraを使用しているプロジェクトなら「Jiraチケットと仕様書がリアルタイムで連携するので、タスク管理の透明性が上がります」という観点で話すと特に刺さりやすい。[1]

ステップ4：「移行コスト」への反論を先回りして用意する

提案時に必ず出てくる反論とその返し方：

図6　脱Excelを通すための提案4ステップ

Part 6 ── ExcelをMarkdownに変換する実践的な方法

既存のExcel仕様書が大量にある現場では、移行の第一歩として「変換」が使える。

AIツール（Claude、GPT-4など）に対して、Excelのスクリーンショットを貼り付けて「このExcel表をMarkdown形式に変換してください」と指示するだけで、かなり精度の高い変換が可能だ。プロンプトの例は以下の通り：[18]

添付したExcel表の画像を読み取り、以下の条件に従って
Markdown形式で出力してください。
・結合されているセルは意味を理解して各行・各列に値を補完すること
・レイアウト調整用の空白セルやインデントは無視すること
・ヘッダー行とデータ行を正確に分離すること
・出力はMarkdownのみとし、余計な解説は不要です

なお、大きな表は「ヘッダー部分」と「データ部分（10行ずつなど）」に分割してキャプチャし、個別にMarkdown化してから結合するという手法を取ることで「精度が飛躍的に向上する」。[18]

図7　Excel表をMarkdownへ変換するワークフロー（分割キャプチャ方式）

モダンな仕様書管理の5原則

最後に、モダンなゲーム開発における仕様書管理の指針をまとめる：[1]

1. 誰もがいつでも最新版を閲覧・編集できるようにする ── ローカルで作業せず、クラウド上で直接編集する
2. 二重管理しない ── ファイルの添付ではなく、ハイパーリンクを貼る
3. バージョン管理を自動化する ── 共有フォルダでの上書き保存をやめる
4. 用途に合ったツールを使い分ける ── Excelは「データの入れ物」として、Markdownは「読ませる文章」として
5. 根性や心がけではなく、仕組みで解決する ── 良い運用はテンプレートや構造として実装する

Excelは「悪いツール」ではない。問題なのは「向いていない用途に使い続けること」だ。レベルカーブやパラメータ管理ではExcelを使い、システム設計や仕様説明にはMarkdownやWikiツールを使う。この使い分けができれば、プランナーの仕事はより本質的なゲームデザインに集中できるようになる。[19][20][2]

References

1. 【ゲーム開発】脱Excel！Confluence仕様書のススメ - 前置きが長くなったが、以降は伝統的なExcel仕様書の欠点と、それを補うConfluence仕様書のメリットを取り上げ、皆さんにもぜひConfluence仕様書の導入を …

2. Excel設計書を抹殺したくて4年前にWiki設計書を導入したら - Qiita - 発生する問題 · 重いので開かなくなる・見なくなる. 追加開発時に参照されない・設計書が使い捨てになる · 検索性が悪いので、作った人に聞くがベターな解決 …

3. Confluence(コンフルエンス)ナレッジ共有&共同作業ワークスペース - Confluenceは、企業向けwikiツールとして情報の一元管理に役立ちます。 例えば、これまで複数のファイルで作成され、別々に保管されていた要件定義書や基本設計書、議事録 …

4. クラウド時代に求められる 「実行可能な仕様書」とは？ - ITmedia - Excel方眼紙の問題. 業務システム開発の世界には「Excel方眼紙」と多少軽蔑的に呼ばれるものがある。行間と列間を細かく設定したExcelシートのことで …

5. 【新卒ゲームプランナー向け】エクセル・スプレッドシートは関数 … - 中でもプランナーとして重要なマスターデータなどの入力作業と呼ばれる作業は、非常に時間がかかります。 数値入力の過不足・入力ミスがあった際は不具合 …

6. マスターデータ入力とは - 共有の際には細かい擦り合せや疑問点、仕様書への記載漏れがあるかもしれませんので打ち合わせを行うことでスムーズに進める事ができます。もしデザイナーやエンジニアの …

7. 【わかりやすい】マークダウンの書き方って？システム開発者目線 … - 技術的な仕様書も、Markdownで記述すれば変更履歴が追いやすく、複数人での編集もスムーズです。 開発フェーズ. GitHub上でのIssue管理やPull Requestの …

8. Markdownとは？様々な形式に変換可能！活用メリット、課題 - Markdownは、ソフトウェア開発や技術文書の現場で特に普及しています。仕様書のような社内文書のほか、ユーザー向けのReadmeでも使われています。

9. 仕様駆動開発に不可欠なMarkdownとGit/GitHub、AIエディタ - 仕様駆動開発を実現するためには、基盤として3つの技術要素が不可欠です。それは、Markdown、Git/GitHub、そしてAI/AIエディタです。

10. 画面設計書を Markdown で書く文化を浸透させたい - Zenn - 画面設計書は、開発の途中で何度も変わります。 項目名が変わる; 必須条件が変わる; 活性条件が追加される; ボタン押下時の挙動が変わる; エラー表示の …

11. マインドマップツールXMindの特徴や使い方｜無料版と有料版 … - さらに、学習リソースにはPDFマニュアルもあり、オフライン環境でも確認できるため、必要な時にすぐに参照できます。 効率的にXmindを習得するには …

12. 誰でも簡単に使えるマインドマップ作成ツール「XMind」とは？ - XMindは、シンプルで簡単なマインドマップツールです。作成したマインドマップにはトピックごとに優先順位や進捗を示すアイコンがつけられるので、 …

13. Notion と Confluence: モダンなナレッジ管理ツール徹底比較 - aslead - NotionとConfluenceはそれぞれ狙うユーザー層や得意分野が異なります。一般に、Notionは個人利用や小規模チームでの利用が多く、その柔軟性と豊富な機能 …

14. ゲーム会社、ガチでNotion使う#3運用編 - note - ゲーム開発におけるNotion運用4つの方針 · 方針1：むやみにDBを作らない。作りたい場合は相談。 · 方針2：サイドバーの構成を整える · 方針3：DBはページ上に …

15. ゲーム開発における、Figma活用事例の紹介 [CADC2024] - この事例では、新規ゲーム開発におけるFigma活用の特徴、開発フェーズ内におけるFigma使用場面、プロジェクトファイル構成、そしてFigma仕様のメリット …

16. 中小企業向け Figma デザインシステム導入事例とロードマップ … - 開発との連携不足, 仕様書作成に時間がかかり、実装ミスが増加. 2.2 デザインシステム導入による定量的効果. 効果項目, 定量指標（出典）. 新規画面作成 …

17. Figmaが制作現場のゲームチェンジャーである8つの理由 - Figmaが制作現場のゲームチェンジャーである8つの理由 · 理由①｜UIデザイナーの業務を大きく効率化し進化させる · 理由②｜分野を超えた協働を可能とし、 …

18. 【全手法比較】方眼紙Excel→Markdown変換、マルチモーダルLLM … - 1. Capture（対象範囲の画像化）：対象のExcelシートを開き、必要な表の範囲をスクリーンショットでPNG画像として保存します。 · 2. Vision Prompt（構造の推論 …

19. ゲームの仕様書に必要なコト｜mTsuruta - note - 仕様書にまとめるゲームの内容なについては、ある程度考えがまとまっているとします。 勿論、仕様としてまとめるうちに問題点や各要素の相互矛盾に気付き …

20. 【ゲームプランナー基礎講座】「仕様書の書き方」 - 株式会社オーツー - 今回は、先日社内で行われた、ゲームプランナー基礎講座「仕様書の書き方」の内容とその様子をご紹介します！ ※追記（2018/8/8） 「企画書を作る工程や …

この文書は、Perplexity、Claude、OpenAI Codex の3つのAIの支援を受けて著述されたものです。引用画像を除き、MIT License にて提供されています。