はじめに
超ミニ4X（シヴィライゼーション風のターン制経済シミュレーション）ブラウザゲーム「小さな帝国」の開発連載、第2回です。
- サービスURL：https://satou20250828.github.io/micro-empire/
- リポジトリ：https://github.com/Satou20250828/micro-empire
- 前回：#1 企画・課題発見（1年前の自分と今の自分を比べるために、Civilization風のテーマを選んだ経緯）
| 回 | 内容 |
|---|---|
| #1 | 企画・課題発見 |
| #2（本記事） | 要件定義 |
| #3 | 設計（技術選定・状態設計・アーキテクチャ） |
| #4 | 開発①ゲームロジック実装編 |
| #5 | 開発②UI・画面実装編 |
| #6 | 開発③テスト・CI/CD構築編 |
| #7 | 開発中に遭遇した技術的問題 |
| #8 | 完成・振り返り |
今回は要件定義編です。ゲームの中核ルールが3段階で作り変わった経緯と、MVPから外した機能について書きます。
プロジェクト全体の方針・仕様は1本のGitHub Issue（#1 プロジェクト全体方針・仕様）に集約し、確定した仕様は本文のToDoチェックリストへ、仕様が変わった経緯はコメント欄へ追記していく形で管理しました。
最初に固めたコア要件
Issue #1の本文には、以下の9項目を最初に決めるべき核として書き出しました。
- ゲームコンセプト（シヴィライゼーション風・超ミニ4X）
- マップ仕様（5×5グリッド）
- プレイヤー構成（自都市1つ＋CPU都市1つ）
- 資源仕様（食料・生産力・金の3種類）
- テックツリー仕様（3系統×5段階＝計15技術）
- 進行方式（ターン制）
- 勝利条件（全テック解放 または 一定資源到達）
- 技術スタック（Vite + Vanilla JS + Tailwind CSS v4）
- 開発フロー（Git Flow、Issue駆動開発）
このうち技術スタックと開発フローは早い段階で固定し、以降のセクションIssue（盤面表示・資源管理・ターン進行など）はすべてこのIssue #1を参照する形で着手しています。
一方で、ゲームの中核ルール（何をどう動かして、何が起きるゲームなのか）は、この時点ではまだ確定していませんでした。 ここが今回の要件定義で一番苦労した部分です。
要件は一度で決まらなかった：中核ルールの変遷
Issue #4（ターン進行）が完了した時点で、「盤面が単なる飾りで、ボタンを押すだけのゲームになっている」という課題に気づきました。ここから中核ルールが3段階で作り変わっていきます。
第1段階：陣地拡大ルール
まず、隣接する未所有マスをクリックすると自領地にできる、1ターン1マスまでの陣地拡大ルールを追加しました。資源の加算も固定値から、所有している地形タイルの合計値をベースにする方式に変更し、勝利条件にも「全マス制圧」を追加しました。
第2段階：開拓者（駒）移動方式への変更
第1段階の仕様のまま検討を進めたところ、「隣接マスを自由にクリックして取得」できると拡大が速すぎて単調になる懸念が出ました。そこで、開拓者🚩を1体だけ用意し、毎ターン隣接マスへ1マス移動させる方式に発展させました。移動先が未所有マスなら取得、相手の領地なら奪い取れる（占領あり）という、駒移動による陣取りゲームです。あわせて？マスやテックツリーの効果もこの時点で一度確定させています。
第3段階：労働者移動モデルへの再設計
しかし第2段階の方式には、①相手都市マスの扱いが曖昧、②全マス制圧を勝利条件にすると理論上達成不可能（都市マスを保護すると25マス埋まらない）という2つの構造的な問題がありました。加えて「戦闘・陣取りより、労働者を動かして資源を稼ぐゲームにしたい」という方向転換の判断もあり、最終的に以下の形へ再設計しました。
- 陣地の所有・占領という概念を廃止。マスは誰のものにもならない
- 労働者🧑🌾を自都市・CPU都市それぞれ2体配置し、毎ターン隣接マスへ1マス移動
- 資源は「陣地の広さ」ではなく「労働者が今立っているマスの地形」に応じて毎ターン加算
- テックツリーの効果も、労働者の産出量を強化する形に再定義（例：🌾農業＝食料マスの労働者の産出+1）
- 勝利条件から「全マス制圧」を撤回し、当初の2条件（全テック解放／一定資源到達）に戻す
3段階を経て、盤面を移動して稼ぐ「労働者配置」がゲームの中核に据わりました。この変遷はすべてIssue #1のコメント欄に、変更前の状態・変更理由・変更後の状態というセットで記録してあります。
細部の要件も、理由とセットで確定させる
中核ルールが固まったあとも、細かな要件を詰める際は必ず「なぜその制約を入れるか」を言語化してから確定させました。
- 労働者は相手の労働者がいるマスへ移動できない：完全に無干渉にはせず、相手の動きを見て良いマスを取り合う駆け引きを残すため（#12）
- 同じマスへの滞在は3ターンまで、4ターン目は強制移動：1箇所に居座り続けられないようにするため（#12）
- テックツリーを3系統×5段階・計15技術に拡張：当初は「簡易テックツリー：3〜5個程度」としていたが、Civilization VIの科学ツリーのような規模感にしたいという方針変更を受けて拡張（#5）。各系統の1〜3段階目は産出量強化、4段階目はルールの制約解除、5段階目は系統ごとの強力な仕上げ、という構成にすることで、「どの系統をどの順で解放するか」に戦略性を持たせています
MVPから外したもの
要件定義でもう一つ重要だったのが、「何を作らないか」を早めに確定させることでした。
- 戦闘要素（eXterminate）はスコープ外：4X（eXplore, eXpand, eXploit, eXterminate）のうち、戦闘要素は当初から実装対象外と決めていました。中核ルールが3段階で変遷する中でも、この方針だけは一貫して維持しています
- 陣地の所有・占領：第2段階までは仕様に含まれていましたが、相手都市マスの扱いが曖昧になる問題を解消しきれず、最終的に撤回しました
- 盤面サイズの拡大：駒移動方式に変えた段階で「拡大するかもしれない」と検討しましたが、労働者移動モデルにすると拡大ペースが自然と抑えられると判断し、5×5のまま据え置きました
次回予告
次回（#3）は設計編です。要件定義編で固まった仕様を、実際にどう状態設計・アーキテクチャに落とし込んだか（フレームワークなしでの状態管理の設計判断を中心に）を書きます。