ゲーム攻略本をヒントにした「RPG要件定義」─ AI時代の楽しい要件定義のつくり方

要件定義 AI

はじめに：要件定義を「楽しく」したい理由

こんにちは。テクニカルディレクター/ソフトウェアエンジニアの池澤孝治です。

要件定義とは、複雑な業務やサービスを開発できる形に整理・翻訳し、関係者の合意を作るための重要な工程です。 一方で現場では次のような問題が起きがちです。

  • テキスト中心で量も多く内容も読みづらいため、最後まで理解しきれない
  • ドメイン（業務概念）が整理されず、どんな要素や状態を表しているのかの定義がばらつく
  • データや図や構造の整理の手が回らず、最新化や整合性もなされない
  • 仕様変更（アップデート）が入ると、資料が部分的に古くなりどれが正か分からなくなる
  • PdM・ビジネス・デザイン・エンジニアで、同じ言葉でもイメージが揃わない

さらにAI時代には、新たな課題も見えてきます。

AIを活用すれば、機能仕様（How）の記述や更新は大幅に効率化できます。
しかしその結果、大量のドキュメントや細かな仕様が生成され、人が読みきれず思考停止したり、AIまかせにして放置してしまうリスクがあります。
サービスのコア価値（Why）やユースケース（What）を人が掴み続けられなければ、いざという時の判断・修正・改善もできません。

そこで人が読みづらいドキュメントがAIで量産されるなら、人が読みたくなる表現や比喩、RPG（ロールプレイングゲーム）の構造で要件定義を設計してしまおう──それがこの記事のアプローチです。

つまり要件定義をもっと楽しくしたいというコンセプトです。
この「楽しい」は単なる娯楽ではなく、品質向上のための認知設計です。これで読まれる・議論される・更新される要件定義を目指します。

なおこの記事はアイデア段階の提案になります。実際の検証などはこれからですが、考え方としてご紹介します。

1. RPGとは何か


ここでは、ドラゴンクエストのような定番RPGをイメージして説明します。

RPG（Role Playing Game）は、プレイヤーがキャラクターを操作し、物語世界を冒険しながら目的達成を目指すゲームです。
ゲームに不慣れな方でも押さえやすい特徴は次の通りです。

  • メインシナリオ：大きな物語のゴールに沿って進行します（例：魔王を倒す）
  • クエスト：物語途中で受ける依頼です。目的・達成条件・報酬があります。
  • ダンジョン：洞窟や城などの場所で、マップを見ながら敵や罠を乗り越えて進みます。
  • ギミック：ダンジョン内の仕掛けです。ルールやロジックがあり、条件を解くことでアイテムを入手したり、新しい道が開くなどの変化が起きます。

ゲームの攻略本は、これらを「プレイヤーが攻略できる形」に体系化したドキュメントです。
この構造は、要件定義に転用できます。

2. 攻略本は「優れた要件定義」に近い


RPG攻略本の構成をよく見ると、要件定義で作りたい成果物と構造的な共通点が多いことに気づきます。
攻略本は「ゲーム世界を攻略できる形に整理したドキュメント」ですが、その整理のしかた自体が要件定義のヒントになります。

攻略本の主な要素と要件定義の対応

攻略本の要素 要件定義での対応
世界とシステムの説明（ルールブック） プロダクトの目的・ドメイン定義・業務ルール・用語集・制約
ストーリー進行の攻略（メインシナリオ） ビジネスゴール・スコープ・マイルストーン
クエスト／サブイベント 業務ユースケース・業務フロー・前提条件と成果物
マップ・ダンジョン攻略 機能ユースケース・画面設計・状態遷移・操作フロー・例外導線

それぞれ掘り下げます。

世界とシステムの説明 ＝ ドメインの前提を固定する

攻略本は、ゲームのゴールや世界の根本ルール（属性相性・レベルシステム・通貨体系など）を最初に説明します。個々のデータではなく「この世界はどういう法則で動いているか」が主題です。
要件定義も同じで、プロダクトの目的やドメインの根本ルール（業務ルール・権限体系・用語定義・制約）を最初に固定します。

ここが曖昧だと後の仕様は全部ブレます。
攻略本が強いのは、この「世界の前提」を最初に固定し、以降すべての説明がそのルールの上に成り立つ点です。

ストーリー進行の攻略 ＝ ゴールまでの道筋を俯瞰する

攻略本は、メインシナリオの進行順を示します。多数のクエストを達成した先にある最終ゴールまでの道筋を俯瞰し、「まずここ、次にここ、最後にラスボス」というマイルストーンを見せます。
要件定義でも同様に、プロジェクト全体のゴール、成功指標、スコープのロードマップを示します。個々の機能要求ではなく、全体の道筋とマイルストーンを俯瞰します。

要件定義が「読み物としてつらい」理由の一つは、メインシナリオが見えないことです。
攻略本は「まずクリアまでの一本道」を出すため、理解が速いです。

クエスト／サブイベント ＝ 抽象的な依頼構造を同じ型で並べる

攻略本は、クエストの発生条件、達成条件、報酬、失敗時の影響を同じ型で並べます。ダンジョンの具体物（UI）とは異なり、「何を達成すればよいか」「前提は何か」「成果は何か」という抽象的な依頼構造を扱います。
要件定義でも同様に、業務ユースケースとして、前提条件、実行内容、成功／失敗条件、成果物、業務フローを同じフォーマットで整理します。画面や操作の具体ではなく、業務が果たすべき役割と条件を抽象的に定義します。

攻略本が強いのは「条件 → 行動 → 結果」を同じフォーマットで大量に扱えることです。
要件もここが揃うと、人間も読みやすくなります。

マップ・ダンジョン攻略 ＝ 具体的な対象を操作して結果を得る場所

攻略本のダンジョン攻略は、クエスト（何を達成するか）とは異なり、「何を見つけ、どう操作し、どこへ進むか」という具体的なHowを扱います。マップ上の宝箱やスイッチなどの操作対象、分岐、トラップを示し、操作した結果どんな状態変化が起きるかを説明します。
要件定義でも同様に、画面や操作対象（ボタン・フォーム・リスト等）という具体物をユーザーがどう操作し、その結果どんな状態変化・エラー表示・関連要素への影響が起きるかを定義します。

クエストが「抽象（何を達成するか）」の世界なら、ダンジョンは「具体（どう操作して結果を得るか）」の世界です。
攻略本はこの具体のHowを、マップや手順として読者に伝えるのが上手く、要件定義にも直結します。

なぜ攻略本と親和性が高いのか

攻略本と要件定義は、どちらも次の構造の問題を解いています。

  • 複雑な世界を、迷わず実行できる行動に落としこみ
  • 失敗（行き止まり）を避ける道筋を示し
  • スコープ（範囲）と優先順位を整理し
  • 変更や分岐を扱う

つまり攻略本は、ある意味で「ユーザー（プレイヤー）向けの要件定義」と言えます。

攻略本と要件定義の違い

  • 攻略本は「遊び方を導く」＝プレイヤーの成功が目的です
  • 要件定義は「作り方を導く」＝プロダクトの成功が目的です

本記事のRPG要件定義は、攻略本の"情報設計"を借りつつ、目的はあくまで「プロダクトの成功」に置きます。

3. RPG要件定義の全体構造


RPG要件定義は、次の状態を目指します。

  • 人に読まれる（理解しやすい・議論しやすい）
  • AIにも読める（構造化されている・整合チェックできる）
  • 更新し続けられる（変更が入っても最新化できる）
  • そのまま実装・UI設計に渡せる（ギミックで実装粒度を確定する）

つまり、Why（目的）→ What（ユースケース）→ How（機能仕様）が辿れる構造を作ることが主眼です。
この「Why→What→Howの追跡性」は、要件定義手法RDRA（Relationship Driven Requirement Analysis）の考え方を参考にしています。

この章では、攻略本の章立てをヒントにした具体的な構造を示します。
※呼び名はチーム文化に合わせて変更して構いません（「ダンジョン」「ギミック」は言い換えてもOKです）。

# 要素 役割
3-1 メインシナリオ Why：目的と範囲
3-2 クエスト What：業務ユースケース
3-3 ダンジョン What/How：機能ユースケース・画面・状態・操作サイクル
3-4 ギミック How：機能仕様詳細
3-5 概念モデル What〜How：ドメイン概念の整理と、具体要素へのマッピング
3-6 絵コンテ What〜How：価値と感情をイメージで伝える

以下、各要素を順に説明します。

3-1. メインシナリオ（Why：目的と範囲）

  • 背景・目的・解決したい課題
  • 成功指標（KPI：判定基準となる数値や状態）
  • 対象ユーザー
  • スコープ／非スコープ（今回の対象範囲／対象外）

3-2. クエスト（What：業務ユースケース）

  • 依頼内容（業務上の目的）
  • 発生条件（いつ・何をきっかけに始まるか）
  • 達成条件（何をもって完了とするか）
  • 失敗条件（どうなると業務が止まるか）
  • 主フロー（基本の業務手順）
  • 代替フロー（中断・差し戻し等の分岐）

3-3. ダンジョン（What/How：機能ユースケース・画面・状態・操作サイクル）

  • 機能ユースケース（ユーザーが具体的に何をできるか）
  • 画面一覧（必要な画面、構成やレイアウト）
  • 画面構成要素（表示要素の粒度を揃える）
  • 状態遷移（主要状態を簡易に整理）
  • メイン操作サイクル（ユーザーの主要な操作の流れ）

3-4. ギミック（How：機能仕様詳細）

  • 表示仕様（表示件数・順序・非表示・disabled条件）
  • 入力仕様（型・必須・文字数・禁止文字・選択肢）
  • バリデーション（タイミング／文言／復帰動作）
  • クリック時処理（ローディング・二重送信防止・遷移・楽観/悲観）
  • API仕様（Request/Response・ステータス別挙動）
  • 権限制御（ロール別に何ができるか）
  • ログ／監査（必要な記録）
  • 非機能（代表例：性能・アクセシビリティ・対応端末など）

ダンジョン・ギミックの難易度ラベル

ダンジョンやギミックには、複雑性（実装の重さ）と不確実性（未知・リスク）のラベルを付けておくと、要件定義の段階で「どこが難所か」が可視化できます。

ラベル 意味 要件定義での判断
複雑性：高 機能が重い・要素が多い・分解が必要 ギミックをさらに分解し、レビューに時間をかける
不確実性：高 仕様が未確定・外部連携が多い・前例がない PoC・フィジビリティ検証を要件定義の段階で先行させる

例えば「このダンジョンは複雑性：中、不確実性：高」と共有するだけで、チームは「仕様は重くないが未知が多いので調査を先にやろう」と判断できます。
攻略本における「難所マーク」のような役割です。

3-5. 概念モデル

ここでは、ドメイン（業務概念）を整理し、それが具体的な実装要素（画面の表示項目、データ構造、API連携、システム間の連携など）にどう対応するかを明確にします。
狙いは、抽象的な業務概念と具体的な実装要素の橋渡しをし、関係者の認識ズレを減らすことです。

図の記述にはMermaid記法を推奨します（理由は4章で述べます）。

概念モデル図（簡易ER図）

厳密なER図（DB設計）まで作り込まない方針です。
ドメイン（業務概念）の見取り図として、最小限にしつつ、各属性が具体的にどこで使われるかを意識します。

  • エンティティ（業務上の登場人物や要素）
  • 主な属性（ID・状態・日時など要点）
  • 関係（1対多程度で十分）
  • 必要な場合のみ状態（ライフサイクル）
  • 属性と具体要素の対応（例：「カテゴリ」→ 一覧画面のフィルタ、DBのカラム、APIの項目）
erDiagram
  商品情報 {
      _ 【属性ID】"【コメント】"
      _ 【属性名】
      array カテゴリ[]
      date 更新日時
  }
  管理情報 {
      _ 【部署】
      _ 【担当者】
  }
  商品情報 ||--o{ 管理情報: "管理"

状態遷移図（メインサイクル／ユーザーインタラクション）

画面内でユーザーが目的を達成するまでのサイクルや、操作によって起きるイベント・状態変化（例：下書き→送信→完了、フィルタ条件→検索→保存済み など）を、簡易に整理します。

  • 主要状態（操作によって変わる画面やデータの状態）
  • 遷移条件（どの操作で状態が変わるか）
  • 例外時の戻り先（処理失敗時にどの状態に戻すか等）
stateDiagram-v2
  [*] --> 初期表示 : ページロード
  初期表示 --> 編集モード : 編集ボタン
  編集モード --> 保存中 : 保存ボタン
  保存中 --> 初期表示 : 保存成功
  保存中 --> 編集モード : 保存失敗


状態遷移図を置くことで、「どの状態で何ができるか」「どこで止まるか」が議論しやすくなります。

ユビキタス言語（用語集）

要件定義全体で使う言葉を、チームで同じ意味・同じ像で共有するために、用語と定義をまとめます。
（例：検索サジェスト／検索条件／保存済み／よく見る商品 など）

3-6. 絵コンテ（価値と感情をイメージで伝える）

テキストはAIには扱いやすい一方で、人には負担が大きい場合があります。
AIがHowを量産する時代だからこそ、人がWhy/Whatに感情移入し、仕様に主体的に関わり続けるための手段が必要です。
そこで、特に重要な機能は絵コンテ形式で、価値・やりたいこと・変化を共有します。

絵コンテとは、映像制作で使われる設計図で、場面ごとに「誰が何をするか」「セリフ」「状況」をラフな絵＋テキストで並べたものです。
完成品のクオリティは不要で、棒人間＋テキストでも成立するため、エンジニアやPdMでも作れます。

狙いは、ユースケースやユビキタス言語（用語）を、人が「状況」と「会話」としてイメージできるようにし、 関係者間で同じ言葉を同じ像で共有できる状態を作ることです。

基本の流れは次の通りです。
機能が複数ある場合は3を分割するなど、カット数は柔軟に調整します。

  1. 困りごと（状況）
  2. 従来のNG（つまずき）
  3. 新機能で解決（行動）
  4. 得られる価値（成果）

目的は「演出」ではなく、認知負荷を下げ、合意形成を早く強くすることです。

絵コンテの台本例

まずは絵を描かなくても、台本（セリフと状況）を置くだけで共有が進みます。
以下は型を示すためのシンプルな例です。複雑な業務フロー（承認・差し戻し・権限分岐など）ほど、台本で認識を揃える効果は大きくなります。

  1. 困りごと（状況）：ユーザー「あれ…あのワイヤレスイヤホン、なんて名前だっけ？」
  2. 従来のNG（つまずき）：商品検索してもなかなかヒットせず困った様子
    • ユーザー「似た商品が多くて、なかなか見つからない…」
  3. 新機能①：検索サジェスト（行動）：検索フォームに「ワ」と入力すると候補がサジェスト表示される
    • 候補例：ワイヤレスイヤホン／ワックス／ワカメスープ／ワイン
    • ユーザー「これだ！」
  4. 新機能②：検索条件の保存（行動）：「この条件を保存します」を押し、検索条件を保存する
    • ユーザー「これ、ホームからすぐ見られて便利になったね！」
  5. 得られる価値（成果）：ログイン後のHome画面（保存済み）から、よく見る商品や検索条件にすぐアクセスできる
    • 表示例：保存済み → ワイヤレスイヤホン
    • 同僚「検索条件ごとに保存できているのが分かるね！よく見る商品にすぐアクセスできそう」

この台本は、ユースケースの主語と目的（思い出せない商品名でも探す／候補から選ぶ／保存して再利用する）を短い物語に落とし、「検索サジェスト」「検索条件を保存」「保存済み」「Home」などのユビキタス言語を、関係者が同じ像で共有するための入口として使えます。
なお、複数の資料が並ぶ場合は、項目ごとに一次参照（どこが正か）を決めておくと、重複や矛盾を防ぎやすくなります。

4. AIで書く要件定義

人手の限界

はじめにで挙げた問題（読みきれない・最新化できない・整合性が崩れる）は、従来の要件定義で繰り返し起きてきました。
しかしこれらは担当者の怠慢ではなく、人手による記述・更新の限界に起因しています。仕様変更のたびに概念モデル図や状態遷移図を追随させ、複数画面にまたがる共通仕様の整合を保ち続けることは、人手では現実的に不可能です。

方針：記述はAI、判断は人

RPG要件定義では、ドキュメントの記述・更新自体をAIが担い、人はレビュー・判断・合意形成に集中することを基本方針とします。

ただし、AIのみで書かなければならないという意味ではありません。整合性の維持や関連箇所への更新反映ができるなら、人が直接書いても構いません。AIを基本とするのは、人手では維持が困難だった整合性と更新の問題を解消するためです。

人が担うのは、Why（なぜ作るか）の意思決定、ユースケースの妥当性判断、関係者との合意形成です。具体的なツールやワークフローは、実プロジェクトでの検証後に別記事で共有する予定です。

フォーマット：Markdownを基本とする

AIが記述・更新を担う前提では、フォーマット選定が重要です。
RPG要件定義ではMarkdownを基本フォーマットとします。

Markdownが適する理由は次の通りです。

  • AIが読み書きしやすい（構造が明確で、生成・解析・変換が容易）
  • 差分が取れる（変更箇所が行単位で特定できる）
  • Git等のバージョン管理と相性が良い（履歴・ブランチ・レビューが回る）
  • Mermaid記法で図もテキストとして管理できる（概念モデル図・状態遷移図を含む）

逆に、ExcelやWordは次の理由で不向きです。

  • ファイル内の参照関係が追いにくい
  • 差分が取れない（バイナリファイルのため行単位の比較ができない）
  • 更新履歴の管理がツールに依存し、自動化しにくい
  • AIによる直接的な読み書きが困難

AIが特に効く領域

RPG要件定義の構造の中で、AIは特に以下の領域で効果を発揮します。

  • What/Howの複雑な仕様記述：ギミック（機能仕様詳細）のように項目が多く網羅性が求められる記述は、AIが得意とする領域です
  • 共通部分の横断更新：権限制御やエラーハンドリングなど、複数のダンジョン（画面）にまたがる仕様を一括で更新し、漏れを防ぎます
  • ツリー構造の整合維持：メインシナリオ→クエスト→ダンジョン→ギミックのWhy〜How構造で、上流の変更が下流に波及する際の整合チェックを自動化できます
  • 概念モデル図・状態遷移図の差分更新：要件テキストから概念（エンティティ・関係・状態）の候補を抽出し、仕様変更時に図を追随させます
  • 用語・状態遷移の抜け漏れチェック：ユビキタス言語の不統一や、状態遷移の矛盾をAIが検知します
  • 絵コンテの台本作成：ユースケースやユビキタス言語をもとに、絵コンテの台本（セリフと状況）をAIが生成・修正できます。人が価値やシナリオの方向性を示し、AIが台本に落とす分担が効率的です

AIの価値は、記述の効率化に加え、継続的な更新と整合チェックに出やすいです。

AIの限界と人の役割

ただし、AIは万能ではありません。

  • 実ユーザー行動の完全再現はできません（ログや調査がないと外れます）
  • 法令・制度の最終判断は人が担う必要があります
  • UIの使いやすさ評価はテキストだけでは限界があります（プロトタイプとの併用が有効です）
  • Why（目的・価値）の意思決定は、ビジネス判断であり人にしかできません

役割分担をまとめると次の通りです。

役割 AI 人
仕様の記述・更新 ○ 主担当 レビュー・修正指示
整合性チェック ○ 自動検知 最終判断
概念モデル図・状態遷移図の維持 ○ 差分更新 妥当性確認
Why（目的・価値）の決定 選択肢の提示 ○ 意思決定
ユースケースの妥当性 網羅性チェック ○ ビジネス判断
合意形成 資料の整形・可視化 ○ 関係者との対話

5. ソフトウェアの「本質的複雑性」とRPG要件定義


ここまでRPG要件定義の構造（3章）とAI活用の方針（4章）を説明してきましたが、そもそもなぜこのアプローチが必要なのでしょうか。
その背景には、ソフトウェアが本質的に抱える構造的な困難があります。以下は、既存の理論的枠組みを借りた筆者なりの解釈です。

広木大地氏のスライド「なぜAIで生産性があがっていると錯覚してしまうのか」では、Fred Brooksの「銀の弾丸などない」を引きながら、ソフトウェアの本質的な困難を「本質的複雑性の四騎士」として整理しています。以下で一部引用させてもらいます。

本質的複雑性 内容
複雑性 Complexity 要素が増えるほど相互作用が非線形に増大する。規模の拡大が本質的に複雑さを増す
同調性 Conformity 既存システムや制度、人間の慣習に合わせる必要があり、再設計では除去できない
可変性 Changeability ソフトウェアは常に変更圧力にさらされ、成功するほど変更要求は増え続ける
不可視性 Invisibility ソフトウェアは目に見えず、構造や関係性を直感的に把握する手段がない

RPG要件定義は「不可視性」に効く

ソフトウェアには本質的な4つの難しさ（複雑性・同調性・可変性・不可視性）があるとされています。 RPG要件定義は、この中でも特に不可視性に対して効果を発揮します。

要件定義ドキュメントが「読まれない」根本原因の一つは、ソフトウェアが目に見えないことです。テキストだけでは、サービスの全体像・機能間の関係・ユーザーの体験が頭に入りにくく、関係者は「読んだつもり」で認識がズレたまま先に進んでしまいます。

RPG要件定義は、この不可視のものを「攻略本」の構造と比喩で可視化します。

  • メインシナリオで、ゴールまでの道筋を「冒険の全体地図」として見せる
  • クエストで、業務の目的・条件・成果を「依頼書」として同じ型で並べる
  • ダンジョンで、画面・操作・状態遷移を「攻略すべき構造」として可視化する
  • ギミックで、入力・バリデーション・API等の仕様を「仕掛けの仕組みと動作条件」として具体化する
  • 概念モデル図・状態遷移図で、ドメインの構成要素とそのつながり・状態変化を「構成要素と変化のルール」として図示する
  • 絵コンテで、ユーザーの行動と感情を「場面」として描く

RPGの比喩がここで実用的な意味を持つのは、ゲームが本来「複雑なルールや構造を、プレイヤーが理解・操作できる形に可視化する」メディアだからです。攻略本はその可視化をさらにドキュメントに落とし込んだものです。
つまり、攻略本がゲーム世界の不可視性を解消する手段であるのと同じように、RPG要件定義はソフトウェアの不可視性を解消する手段として機能します。

意思決定の認知負荷を下げる

前述のスライドでは、AIがHow（実装）を担うほど、人間の仕事はWhat/Why（何を作るか・なぜ作るか）の意思決定に移行すると整理されています。
しかしWhat/Whyの意思決定は、実装と違って「遅い・迷う・揉める」領域です。正解がなく、関係者の立場や前提が異なるため、合意形成に時間がかかります。

認知負荷を下げる構造がなければ、この意思決定は停滞します。
RPG要件定義の絵コンテ（ユーザーの困りごとと解決を場面で見せる）、クエスト（業務の条件・手順・成果を同じ形式で並べる）、メインシナリオ（ゴールまでの道筋を俯瞰する）は、まさにこの「遅い・迷う・揉める」領域での合意形成を加速するための認知設計です。

比喩や物語構造で情報を整理することは、人の理解と記憶を助ける認知的に合理的な手段です。「楽しさ」はいい加減なものではなく、読まれ・議論され・更新される要件定義を実現するための設計判断です。

RPG要件定義が主に効くのは、この不可視性と、意思決定の認知負荷です。4つの本質的複雑性すべてを解決するものではありませんが、「見えない・伝わらない・揉める」に起因する問題に対しては、構造と比喩の力で対抗できます。

6. 仕様駆動開発（SDD）と何が違うのか


近年、AIを活用した「仕様駆動開発（SDD: Spec-Driven Development）」が注目されています。
SDDは、仕様書を唯一の真実源泉（Single Source of Truth）として最初に定義し、その仕様に基づいてAIと人が設計・実装・テスト・ドキュメントを一貫して進める開発アプローチです。仕様レビューを通じた関係者の合意形成や、設計判断の透明性確保も重視されています。

本記事の「RPG要件定義」は、SDDの置き換えではなく、補完的な関係にあると考えています。
SDDの中心思想は「仕様＝コードの契約」です。仕様を書けばAIがコードを生成し、仕様が変わればコードも変わる。追跡性は実装の正確性のためにあり、仕様はAIへの入力として最適化されます。SDDはAIによる自動実装を前提にワークフローが設計されている点で、開発手法の中でも特殊な位置づけです。
一方RPG要件定義の中心思想は「仕様＝人の理解の足場」です。追跡性は認知負荷を下げて合意形成を助けるためにあり、仕様は人が読み続けることに最適化されます。実装者がAIでも人でも使える構造であり、実装手段に依存しません。

比較表（従来要件定義 / 仕様駆動開発 / RPG要件定義）

観点 一般の要件定義（従来） 仕様駆動開発（SDD） RPG要件定義（本記事）
中心目的 合意形成・要求整理 仕様をSSoTとし、AI＋人で一貫した開発を回す Why→What→Howの追跡性と、人が読める認知設計
仕様の位置づけ 合意と要求の記録 コードの契約（仕様が変われば実装も変わる） 人の理解の足場（読まれ・議論され続けることが前提）
実装の前提 特に限定しない AIによる自動実装を前提に最適化 実装手段に依存しない（AI実装にも人の実装にも渡せる）
仕様の粒度 ドキュメント中心・粒度が揺れやすい 実装可能な粒度に構造化（機能仕様〜タスク） Why〜Howの段階ごとに粒度を変え、ギミックで実装粒度まで落とす
強み 説明と合意を作れる 仕様とコードの整合性維持・実装ブレの低減 比喩と構造で読まれやすい／議論しやすい
つまずきがち 読まれない／更新されない 仕様が巨大化するとレビュー困難・仕様が曖昧だと手戻りが大きい 遊びに見える・仕様の厳密性や一貫性はSDDに劣る
目指す形 要求と合意を文書で残し、開発の拠り所にする 機能仕様書が基準（SSoT）として常に最新 人が理解し議論し続けられる形で、Why〜Howを辿れる構造

RPG要件定義は、SDDが持つ仕様の厳密性やSSoTとしての運用ルールをまだ取り込めていません。現時点ではアイデア段階の仮説であり、SDDやRDRAなど実績のある手法から学びながら発展させていく必要があります。

7. ギミック内容とサンプル


以下は「申請作成フォーム（保存）」を想定したサンプルです。

7-1. 入力仕様（例）

項目 型 必須 制約 備考
タイトル 文字列 ○ 100文字以内 先頭/末尾空白はトリム
金額 数値 ○ 0以上、整数 カンマ入力は許容し内部で除去
備考 文字列 - 500文字以内 絵文字は可/不可を決める

7-2. バリデーション（例）

  • 必須チェック：blur時
  • 文字数超過：入力中に表示（リアルタイム）
  • エラーメッセージ：ユーザーが次に何をすればよいかが分かる文言にします
  • エラー時の復帰：エラー項目へスクロール＋フォーカス

7-3. ボタン押下時処理（例）

  • 送信中はボタンをdisabled（二重送信防止）
  • 送信中はローディング表示
  • 成功時：完了メッセージ表示 → 一覧へ遷移
  • 失敗時：ステータスコード別に表示を切替
    • 400：入力エラー（項目エラーに紐づける）
    • 403：権限不足（説明＋問い合わせ導線）
    • 500：一時障害（再試行導線）

7-4. API仕様（例）

  • POST /applications
  • Request：{ title: string, amount: number, note?: string }
  • Response：{ id: string, status: "draft" }
  • 二重送信：どう扱うか（サーバ側の方針と合わせて定義）

この程度まで書けると、UIデザイン・フロント実装・バックエンド実装で「解釈のズレ」が大幅に減ります。

8. 「ふざけて見える」リスクへの対策


RPG表現は、使い方を誤ると「遊び」に見えます。
そのため、次の原則を置くと安心です。

  • RPG用語の呼称はチーム文化に合わせて調整します（対外向けは「画面設計」「詳細仕様」などでもOK）
  • 絵コンテは全機能に作る必要はありません（重要機能・認識ズレが起きやすい機能に限定します）
  • 各機能やユースケースにMust/Should/Couldなどの優先度を付け、記述範囲の肥大化を防ぎます
  • RPG表現を使う目的は「理解促進」と「合意形成」であることをチームで共有し、演出が目的化しないようにします

「楽しい」は手段です。品質と合意形成のための設計として扱います。

まとめ


RPG要件定義は、攻略本の構造をヒントに、要件定義を次の状態へ近づけます。

  • 人が読みたくなる（RPGの比喩と構造で、複雑な業務を直感的にイメージできる）
  • 人が理解しやすい（絵コンテや概念モデル図・状態遷移図で、価値と構造を可視化）
  • AIが記述・更新・整合チェックできる（Markdownで構造化し、差分更新と整合性検証が回る）
  • 実装・UI設計にそのまま渡せる粒度まで落とせる（ギミックで機能仕様を具体化）

ソフトウェアは本質的に目に見えず、関係者の認識はズレやすいです。RPG要件定義は、この見えにくさに対して、RPGという誰もがイメージしやすい比喩と構造の力で、要件定義を直感的に分かるものに変えるアプローチです。

AIがHowを書き、仕様が大量に生成される時代に、人がWhy-Whatを掴み続けるには「読みたくなる構造」が重要です。ともすると書くのも読むのも辛くなりがちな要件定義、それを少しでも楽しく面白く感じられるものにしたい──そんな思いからこの「RPG要件定義」を考えてみました。

この記事はまだアイデア段階ですが、なにかのお役に立てれば嬉しく思います。

参考記事

この記事の考え方の背景は、以下の記事で詳しく書いています。

また、本記事の理論的な枠組みとして以下のスライドを参考にしています。

Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！