RPGダンジョンライクに要件定義を例えながらWhy-What-Howをつなげる方法を説明してみた

アドベントカレンダー デザイン 要件定義

こんにちは。テックディレクター&エンジニアの池澤です。この記事はGoodpatch Advent Calendar 2023の19日目の記事です。

要件定義で、機能の一覧はできたけど具体的に何を開発すれば良いのか分からないことはありませんか。
各機能についてWhy-What-Howの関係が見通せて簡単に確認できると、開発やUI設計が理解しやすく実装もスムーズに進められると思います。

この記事ではRPGゲームの例えを使いつつ「機能ユースケース」や「UIスペック」を元に、機能の要件定義をやりやすくする方法についてお話したいと思います。

機能の要件定義でよくある問題

要件定義で機能の箇条書きの一覧を作った後、そこから先に進めなくて困ることはありませんか。ざっと機能の概要を洗い出せたとしても、なぜこの機能が必要なのか、具体的に何をどう制作すればよいのかが分からないことはありませんか。

機能の要件定義でよくある問題を以下に挙げてみました。

  • 機能一覧について
    • そもそもどんな機能があれば業務要求や価値提供できるのか分からない
    • 機能っぽい箇条書きの羅列になってしまう
    • あいまい過ぎて具体的な仕様やシステム設計を導き出しづらい
    • または逆に画面定義書のようなUIパーツやクリック挙動等細かすぎる仕様まで書こうとして時間や柔軟性がなくなる
    • Why-What-Howのフローに繋がらず関連情報を辿れない
    • 結局更新されないドキュメントになりやすい
  • 開発時になぜこの要件が必要かWhyが見えない
    • 開発する際、ユースケースや業務背景が理解できない
    • ビジネス企画や提供価値のWhyが分からないので開発は指示待ち姿勢になってしまう
  • 開発実装時の要件修正が困難
    • 実装フェーズで開発側から要件不備を疑っても自ら判断する術がない
    • 開発側からの要件不備が適切に取り上げられない
    • 実現可能性（フィジビリティスタディ）の確認が取れないまま実装時に発覚することが多い
  • 要件の抜け漏れが発生しやすい
    • 開発観点で必要な観点や状態が漏れやすく手戻りが発生
    • 抜け漏れがないか判断するのが非常に難しい

期待される機能の要件定義の姿

上記で挙げたような課題を避けつつ、軽量・コンパクトな機能要件定義を目指したいです。

  • 仕様やシステムについてWhy-What-How（ビジネス要求-機能ユースケース-機能仕様）の繋がりが見える
  • システム設計やUIデザイン、実装にスムーズに連携できる
  • 仕様追加や変更があってもどのドキュメントを追加・修正すればよいのか分かる
  • 分からない仕様があったら一元的に確認する場所があり、そこからWhy-What-Howを簡単に辿れる

RPGゲームとしてビジネスと機能を捉えてみる

要件定義ではビジネス側や機能側で観点が異なります。
例えば「ユーザがログインできる」という要件があっても、ビジネスでは個別情報収集やパーソナルなサジェスト、ダッシュボード表示データの精度向上を考えているが、機能では認証認可やシングルサインオン、MFA、プライバシーポリシーやPマーク取得対応等別のことを考えていたりします。

要件定義をしているとビジネスと機能が混在してしまって、どの観点や粒度で捉えればいいのか分からなくなりがちでした。
そのため私は要件定義とRPGをミックスして、区別したり比喩的に想像するように工夫しています。
ドラゴンクエストのようなRPGに出てくるクエストやダンジョンをビジネス業務や機能になぞらえて、粒度や範囲を明確にしていますのでご紹介します。

ゲームシナリオ

RPGにはゲームのゴールやルール、最終目標のようなゲームシナリオがあります。
これは、要件定義ではプロダクトの目的やビジョン・ミッション・バリュー、PMFやESG等、最終的に目指しているものや状態にあたります。

クエスト

RPGには、ギルドが冒険者に依頼する「クエスト」があります。
例えばRPGではよく冒険者ギルドの掲示板にクエスト依頼の紙が貼られています。その内容には達成したい業務依頼や業務達成結果として持ってきてほしいもの、達成後にアンロックされる関連クエストがあったりします。
クエストの成果を通してギルドは業務を回し、ゲームシナリオの進行やゲームの状況・障害が変化します。

この「ギルドの目線」から見ると、依頼主であるギルドは業務目的のためにクエスト依頼（ビジネス要求）を設計して冒険者へ依頼を出します。そのクエストが達成（機能実行と成果獲得）されることでギルド業務や目的（プロジェクト目標）を進行できます。

このクエスト依頼が「ビジネスユースケース」にあたります。
「ビジネスユースケース」はビジネスのゴール・シナリオや業務フローを進めるためのビジネスタスクを抽象度の高いユースケースで描いたものです。ビジネス側の要求や企画をふるまいとして整理し、粒度や形式を揃えたものになります。

観点としては、ギルド側は依頼側であり具体的なダンジョンやダンジョン内部構造（機能やUI）の様子には関心を持ちません。依頼内容と成果のみに関わります。（ギルドはダンジョン現場に行かない）

参考： モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた > クエスト

ダンジョン

RPGにはダンジョンがあります。
ダンジョンはどれも同じではなく、森、氷、溶岩、迷宮等の各種属性で構成されています。
冒険者は特定のクエスト達成を目指してダンジョンに探索に行きます。
途中宝箱や落とし穴、扉の鍵探し、ボス敵等のギミックをくぐり抜けながらダンジョンを達成し、最終的にクエスト依頼成果を持ち帰ります。

「冒険者の目線」から見たダンジョンや攻略方針が「機能ユースケース」にあたります。
ビジネスユースケースが抽象度の高いビジネス上のシナリオや業務フローだとしたら、機能ユースケースは具体的なUI画面やボタン構成、クリック後の処理をした結果の報酬や状態変化を表します。

ダンジョン開始条件や属性が機能カテゴリや必要な初期データや表示条件となり、ダンジョン報酬が機能実行結果後の出力や状態変化にあたります。このダンジョンを多数組み合わせることで、複雑な機能や大きなクエスト（ビジネス要求）を行います。
ゲーム世界観としては大小様々なダンジョンがあり、そのダンジョンから得られる報酬でゲーム進行できるイメージです。

観点としては、冒険者の関心はあくまで具体的な現場であるダンジョン内のみに関心を持ちます。（冒険者はギルドの抽象的な議論より手を動かす方が好き）

ダンジョン攻略の上流には、ギルドの意図するクエスト（ビジネスユースケース）やゲームシナリオ（サービス目標・価値したい提供）が繋がっています。Whyが知りたければクエスト内容を辿れば確認できるリンクのあることが重要になります。

参考： モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた > ダンジョン

ギミック

RPGでダンジョン内には宝箱や落とし穴、扉の鍵探し、ボス敵等の仕掛けがあります。
冒険者はダンジョンでこれらのギミックを操作攻略して、クエスト依頼成果（業務の状態変化や出力結果）を持ち帰ります。
ギミックにはダンジョン内で見えている宝箱やザコ敵・ボスの他に、壁や床に埋まって見えないがトリガー発動をきっかけに動作するような仕掛け（ロジック・開発処理）もあります。

このダンジョン内のギミックが「機能仕様」にあたります。
見えている宝箱や敵をUIデザイン部分、見えない仕掛けや罠を開発ロジック部分として捉えます。
冒険者の操作（クリックや入力）によって各種の仕掛け（APIや状態遷移）が動き、ダンジョン（機能ユースケース）を構成しています。
ギミックは、いわばダンジョンという機能ユースケースを作るための部品や設計図のようなものです。

Why・What・Howで軸となる項目について

これから以下で機能要件定義をご説明して行きます。
要件定義では軸となるWhy-What-Howは保ちたいです。軸を保った上で、各種資料や仕様の書き方、メソッド等の付け外しが可能な形であれば、ぶれのなさと柔軟性を両立しやすいと思います。

この機能要件定義を使って、これまで実際に大手証券会社や広告代理店等のサービス開発を行ってきました。軽量・コンパクトで取り回ししやすく、特に小〜中規模のサービス開発で便利に使いやすいと思います。

この記事で取り上げている機能の要件定義では、以下の項目を想定しています。

  1. Why
  2. What
  3. How
  4. システム設計・非機能要件・その他設計

4番のシステム設計等はプロジェクトによって様々ですので、今回は1〜3番のWhy-What-Howをぶれないようにしながら定義する方法を見て行きます。

Whyについて

Whyはビジネスのゴール・シナリオや業務フローを進めるために戦略・戦術タスクを抽象度の高いユースケースで描いたものとなります。
経営や事業部、ビジネスチームで企画の狙いやサービスプロセスを確認したりするケースや、業務の流れを概念的に表して企画書内で業務フローとして記載するのに使われます。
逆に具体的な画面やボタン操作といった要素については関心を持たないです。
Whyの軸には「ビジネスユースケース」を使用します。

Whyには主に以下のような情報があります。

  • ビジネス要求・企画
  • 提供価値
  • 業務フロー
  • UXデザイン・分析情報（各種ユーザーストーリーマッピング、ペルソナやユーザーインサイト等）
  • 業界、ブランド、組織構成、意思決定者巻き込み、競合、ドメイン理解等

これらを元に軸となる「ビジネスユースケース」を作成して行きます。
ビジネスユースケースの例：

  • 顧客の利用促進を図るため、顧客の関心のあるトレンド業務情報を定期配信できる
  • 事務局が登録途中での顧客離脱箇所を把握できる
  • 顧客は入力した情報が外部ユーザに公開されることを認識できる
  • 新規登録のメリットを分かりやすく訴求できる
  • ユーザごとの情報取得や認証認可での管理ができる
  • 受注状況を確認する

※ 場合によってはビジネスユースケースと機能ユースケースの表現が似たものになる場合がありますが、ビジネス・業務と機能では観点が違うのでかぶっても特に問題ないです。

RPGで言うと「ギルドの目線」から見たクエスト依頼の計画定義の工程になります。ここでサービスがどう使われるのかを表して行きます。
例えると、ギルドがゲームシナリオ進行のために様々なクエスト依頼を作成するのに似ています。このクエストを達成する毎にゲームシナリオが進行し、メインストーリーもゴールに近づきます。

なお「ビジネスユースケース」の元になった考えは「RDRA」の『ユースケース』や前回記事の「業務ユースケース」から得ています。

参考：
モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた > 業務ユースケース

ビジネスユースケースのテンプレート

業務要求・企画

■ 目的
※ 企画の目的や課題、やりたい事の内容を記載（例：「顧客の有料プラン促進を図るため、顧客の関心のあるトレンド業務情報を訴求したい」）

■ 内容
※ この⽬的達成に必要な企画の内容をビジネスや業務の観点で記載
（例：「顧客に●●のニーズがあるとの報告を営業から受ける。登録促進の施策のためには●●の課題が問題となっている。そのために顧客視点で使いやすく好循環を作れるサイト内循環を充実できる機能を追加したい。」）

■ 備考
※ 法令や特殊な業務ルール、制約条件や備考等を記載

■ 機能ユースケース
※ （任意項目）この企画に紐づく機能ユースケースがあれば記載して遷移できるようにする

ビジネスユースケースの例

ビジネスユースケース例

----------------------------
ビジネスユースケース 一覧サンプル
----------------------------
・顧客の利用促進を図るため、顧客の関心のあるトレンド業務情報を定期配信できる
・事務局が登録途中での顧客離脱箇所を把握できる
・顧客は入力した情報が外部ユーザに公開されることを認識できる
・新規登録のメリットを分かりやすく訴求できる
・ユーザごとの情報取得や認証認可での管理ができる
・受注状況を確認する


----------------------------
ビジネスユースケース 詳細サンプル1
----------------------------

【タイトル】：新規登録のメリットを分かりやすく訴求できる
■ 目的
顧客の有料プラン促進を図るため、顧客の関心のあるトレンド業務情報を訴求したい

■ 内容
顧客に自社サービスのニーズがあるとの報告を営業から受ける。
登録促進の施策のためには登録のメリットが見えづらいという課題が問題となっている。
そのために顧客視点で使いやすく好循環を作れるサイト内循環を充実できる機能を追加したい。

■ 備考
利用規約や機密保持契約を満たせるようにする。


----------------------------
ビジネスユースケース 詳細サンプル2
----------------------------

【タイトル】：ユーザごとの情報取得や認証認可での管理ができる
■ 内容
ユーザごとに最適化した情報をレコメンド提案する。ユーザの行動情報を蓄積し、データ分析やマーケティング施策が行えるようにしたい。

Whatについて

ビジネスユースケースが抽象度の高いビジネス上のシナリオや業務フローだとしたら、Whatはビジネスユースケースを達成するために必要な機能群を指します。
各機能を実行し、状態変化や機能実行後の成果を生み出し、結果としてビジネス要求を達成します。

ビジネス要求を達成するために必要な具体的な機能の観点を持っています。
Whatの軸には「機能ユースケース」を使用します。

Whatには主に以下のような情報があります。

  • ビジネス要求を達成するための各種機能洗い出し
  • UI設計、UIワイヤーフレーム
  • 開発概要フィジビリティスタディ確認
  • ユビキタス言語での用語・認識の統一

これらを元に軸となる「機能ユースケース」を作成して行きます。
スクラム開発でいうプロダクトバックログアイテムに近いイメージです。
機能ユースケースは高頻度で閲覧するので、ここからリンクされるドキュメントは目が届きやすく、情報の更新や保守がされやすいメリットがあります。
機能ユースケースの例：

  • ログインでユーザ認証認可ができる
  • アイテム一覧画面を閲覧できる
  • アイテム詳細で内容を編集できる
  • 新規アイテム登録ができる
  • アイテムに変更があったらメール通知が届く
  • 管理サイトで登録ユーザが確認できる
  • アイテムの使用進捗をレポート機能で確認できる

RPGで言うと「冒険者の目線」から見たダンジョンやギミック攻略になります。ここで機能がどう使われるのかを表して行きます。
「冒険者」はダンジョン攻略のために、様々なギミックを操作し、何らかの出力や状態変化を起こし、ダンジョン攻略を通してクエスト依頼を達成します。「機能ユースケース」とはこの「対象ダンジョンと成果」を表したものになります。

参考：
モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた > 機能ユースケース

機能ユースケースのテンプレート

機能ユースケース

■ 内容
※ 業務要求や企画の⽬的達成に必要な内容を「機能」の観点で記載する（スクラム開発のプロダクトバックログアイテムに近いイメージ）。
業務/機能の観点の違いがあるなら例えば業務要求・企画と重複した内容でも可。
（例：「顧客が案件を新規作成できる」「ログインでユーザ認証ができる」「ユーザが詳細ページで内容確認・編集ができる」）

■ 備考
※ 法令や特殊な業務ルール、制約条件や備考等を記載

■ 機能要件・UIスペック
※ （任意項目）この企画に紐づく機能要件やUIスペックがあれば記載して遷移できるようにする。
機能ユースケースの子要素にしておくとWhy-What-Howが見通しやすい。

機能ユースケースの例

機能ユースケース例

----------------------------
機能ユースケース 一覧サンプル
----------------------------
・ログインできる
・アイテム一覧画面を閲覧できる
・アイテム詳細を確認できる
・アイテム詳細で内容を編集できる
・新規アイテム登録ができる
・アイテム一覧データをインポートで登録できる
・アイテムに変更があったらメール通知が届く
・管理サイトへログインできる
・管理サイトで新規ユーザ登録ができる
・管理サイトで登録ユーザが確認できる
・アイテムの使用進捗をレポート機能で確認できる
・レポートをログイン無しで一定期間有効なURLで閲覧できる


----------------------------
機能ユースケース 詳細サンプル1
----------------------------

【タイトル】：ログインできる
■ 内容
ユーザがサイトにログインし、認証認可を行えるようにする。ユーザが行動や編集した履歴を収集し、集めたデータからレポートを生成したい。

■ 備考
多要素認証（MFA）が行えること。
Pマーク（プライバシーマーク制度）の取得条件を満たせるようにすること。

----------------------------
機能ユースケース 詳細サンプル2
----------------------------

【タイトル】：アイテム詳細で内容を編集できる
■ 内容
アイテム詳細でログインしたユーザ権限に応じた編集が行える。名前やステータス等アイテム固有の項目を変更できるようにしたい。

Howについて

HowではWhatの機能ユースケースに対して、それを実現するためのロジックやUI等の具体的な仕様を作成して行きます。

UI設計や画面デザイン、状態遷移や必要な入出力データ設計、関連する外部システムとの連携等を定義し作って行きます。
なお、ここでウォーターフォール的に詳細を全て定義し切るのは難易度が高いです。また、システム設計は軸とするには複雑で粒度が細かすぎるので、Howの次の工程として行うようにします。

Howには主に以下のような情報があります。

  • UI画面・パーツ
  • UIスペック
  • 画面一覧
  • 開発フィジビリティスタディ確認
  • 技術・アーキテクチャ確認
  • 外部システムや外注業者との連携方法

RPGで言うとダンジョンの属性に応じた壁や床、ギミックの形や各種仕掛けの動作ロジックです。ここで機能の表面や裏側の仕組みを表して行きます。
例えると「冒険者」がダンジョンの現場で見たり手を触れたり操作する対象のことです。このギミックを様々に操作して全体としてダンジョンクリアし報酬獲得を目指します。

Howの要素は様々なものがあるので軸を一つにするのは難しいです。ですが私は「UIスペック」をHowの軸としてよく使用しています。
UI設計では、ビジネス要求やUXおよび機能ユースケースを満たすために、概念モデルや画面遷移、情報項目の表示と操作を考えます。そしてそれを元にUI画面やパーツを具体的なUIデザインを作成して行きます。
この時にUI設計やデザインとともに「UIスペック」を作ります。

UIスペックとはUI Specificationの略です。一般的な仕様書は画面ごとに機能仕様を記述しますが、UIスペックは機能ユースケースを元に作ります。
UIスペックには以下のような利点があります。

  • 機能ユースケースをベースにするので機能単位で仕様がまとめられる
  • 機能ユースケースに紐づいているので機能の優先順位が変わっても影響範囲や変更が柔軟にできる
  • UI画面やパーツだけでは抜け漏れてしまう開発情報を定義することができる
  • デザイナーとエンジニア両者が仕様のやりとりするためのベースとなる
  • サービス全体仕様の一部として継続してドキュメントを残せ、アップデートもかけやすい。
  • 実装時にエンジニアからよくあるUI質問を事前に明記できる

※UIスペックに似たUI用語で「UI Stack」があります。スペルが似ていてまぎらわしいためカタカナで「UIスペック」と表記しています。

参考： ユーザー体験を軸とした開発仕様書「UI Spec」とは

UIスペックのテンプレート

UIスペック

＜機能ユースケース＞
■ 機能ユースケース：
■ 対象画面：
【画面】：
【画面】：

---

＜機能仕様＞
画面毎に機能仕様を記載します。


【画面】：

■ 対象内容：
■ 画面タイプ（ページ/モーダル/パーツ他）： 
■ 表示・非表示導線：
■ 表示件数：
■ 表示順列：
■ 入力要素（形式、複数可否、見切れ等）：
■ 文字数：
■ 状態遷移/エラー/バリデーションの挙動：
■ クリッカブルエリア・挙動：
■ 遷移元/遷移先：
■ 補足：

===

【画面】：

■ 対象内容：
■ 画面タイプ（ページ/モーダル/パーツ他）： 
■ 表示・非表示導線：
■ 表示件数：
■ 表示順列：
■ 入力要素（形式、複数可否、見切れ等）：
■ 文字数：
■ 状態遷移/エラー/バリデーションの挙動：
■ クリッカブルエリア・挙動：
■ 遷移元/遷移先：
■ 補足：

UIスペックの例

UIスペック例

UIスペック

＜機能ユースケース＞
■ 機能ユースケース：
新規アイテム登録ができる

■ 対象画面：
・新規アイテム登録
・アイテム情報未登録状態
・グローバルナビゲーション


---

＜機能仕様＞
画面毎に機能仕様を記載します。


【画面】：新規アイテム登録
https://www.figma.com/xx

■ 対象内容：
[新規アイテム登録のスクリーンショットイメージ]

■ 画面タイプ： ページ

■ 表示・非表示導線：
・パンくずリスト：次の文字を固定表示する。`アイテム一覧` > `アイテム詳細` 「アイテム一覧」にはリンクを貼る。
・ステータスチップ： 該当ステータスに応じたチップを表示
・セクション項目のアコーディオン表示： セクションでをアコーディオン式に収納・展開表示を切り替えられる。矢印ボタンを押すとトグル式に収納・展開が切り替わる。
・アイテム行：以下を表示する
  ・ ID（アイテム番号）
  ・ アイテム名
  ・ 日時： yyyy/MM/dd HH:mm 形式で表示（0埋め）

■ 表示件数：
・添付画像：最大3個。10MB以下のPNG / JPEG(JPG) / GIF形式のみ。
・添付資料：最大3個。PDF形式のみ。

■ 表示順列：

■ 入力要素（形式、複数可否、見切れ等）：
アイテム説明： 
・アイテム説明欄内にURLが記入されていた場合は自動リンクする。リンクはhttps~のみ（http~はリンクさせない）
・リンク押下時は外部のサイトに接続する確認のモーダルを表示する。外部サイトは別タブで開く。
・URLの表示が一定幅を超える場合は末尾を三点リーダー「…」で省略表示する。マウスオーバーしたら吹き出しを出し、全体URLを表示する

■ 文字数：
・項目タイトル：最大文字数100文字
・項目説明：最大文字数1000文字
・アイテム：最大文字数100文字
・ユーザ名：最大100文字まで

■ 状態遷移/エラー/バリデーションの挙動：
・閲覧期限：過去日は選択不可。最大翌年同日まで選択可能。

■ クリッカブルエリア・挙動：
・上部説明テキストの「ビジネス利用規約」 のリンク先は利用規約
・添付資料リンクを押すとPDFをダウンロード

■ 遷移元/遷移先：
・遷移元：グローバルナビ > 新規アイテム登録
・遷移先：登録アイテム確認画面

■ 補足：
共通UI部分（グローバルナビ、ヘッダー、フッター）は各コンポーネントを参照


===


【画面】： アイテム情報未登録状態
https://www.figma.com/xx

■ 対象内容：
アイテム情報なし状態の画面。
[アイテム情報なしのスクリーンショットイメージ]

■ 画面タイプ： 画面内パーツ

■ 表示・非表示導線：
・アイテム情報無しのサムネイル
  表示対象がないことを示すサムネイルを表示
・アイテム新規登録ボタン

■ クリッカブルエリア・挙動：
・アイテム新規登録ボタン

■ 遷移元/遷移先：
・遷移元：各ページ共通表示される
・遷移先：
  ・アイテム新規登録ボタン：アイテム新規登録画面へ遷移。


===


【画面】： グローバルナビゲーション
https://www.figma.com/xx

■ 対象内容：
[グローバルナビゲーションのスクリーンショットイメージ]

■ 画面タイプ： 共通コンポーネント（左サイドナビ）

■ 表示・非表示導線：
・サービスロゴ
・矢印ボタン（左サイドに収納・展開）
  クリックすると画面左サイドにグローバルナビを折りたたみ収納する。再度クリックするとグローバルナビが元の展開表示に戻る。
・ナビゲーションメニュー
  ・メニュー名
  ・未読バッジ
    前回ログイン日時から未閲覧のアイテムがあったら件数をバッジで表示する
  ・設定メニュー
  ・ログアウトボタン

■ 表示件数：
・未読バッジ：2桁表示。100を超えたら「99+」のように省略表示する

■ 文字数：
・ナビゲーションメニュー：グローバルナビの横幅に収まらなかったら折り返して表示。極力1行で収まる名前を設定する

■ 状態遷移/エラー/バリデーションの挙動：
・ユーザ権限：ログインしているユーザの権限で使用不可のメニューはdisabledにし、色もdisabledカラーにする。
・矢印ボタン：クリックするとトグル式に左サイドに収納・展開表示される

■ クリッカブルエリア・挙動：
・サービスロゴ
・矢印ボタン（左サイドに収納・展開）
・ナビゲーションメニュー
・設定メニュー
・ログアウトボタン

■ 遷移元/遷移先：
・遷移元：各ページ共通表示される
・遷移先：
  ・サービスロゴ：トップページ
  ・ナビゲーションメニュー：メニューに対応したページ
  ・設定メニュー：設定画面
  ・ログアウトボタン：ログアウト処理後にログイン画面へ

ドキュメント管理ツール

要件定義を作成する上でドキュメント作成のツールも大切です。
顧客や環境によっては既に使われているツールがあったり、海外のツールは使用不可等、選択が限られる場合もあります。

できればよく使われるリンク遷移、入れ子構造の可否、コメント機能等は便利に使えるツールがほしい所です。特にwhy-what-howを簡単に確認できることが大事なので、各ページへの遷移やリンク設定・参照等は重要と思います。

私が主に要件定義で使ってきたツールを参考にご紹介します。

  • Notion
    • Notion Labs社製のドキュメント管理ツール
    • 特に制限がなければ大抵はNotionで要件定義を作成することが多いです。
    • データベースやリンク、ページの入れ子の他、かなり豊富な機能が一通り揃っている定番ツールです。
  • Jira / Confluence
    • ATLASSIAN社製のタスク管理ツール（Jira）およびドキュメント管理ツール（Confluence）
    • タスク管理やエスカレーションで有名なJira。顧客の状況によってはこうしたAtlassian製ツールを使うこともあります。
  • backlog
    • ヌーラボ社製のタスク管理ツール
    • 顧客によっては日本製のツールという制限のある場合があり、その場合はbacklogを使ったりします。
    • タスク管理ツールですが、チケットの使い方を工夫すれば要件定義を書くこともできると思います。

まとめ

RPGダンジョンライクな観点で要件定義が少しでも楽しくなるように考えてみました。
要件定義は様々な手法や書き方がありますが、イメージしやすく感情移入しやすいテーマを元にした方が、いざ要件定義で困った時にミスや失敗を減らせて便利です。

RPGの世界と要件定義は何となく似ていると個人的に感じていました。
今ギルドスタッフの立場なのか冒険者なのか、ダンジョンの報酬に関わるものなのか、ギミックに関わるものなのか等を考えたりします。ダンジョンを作るのに必要なものを定義すれば、実際のサービスにも応用できるというのはちょっと楽しく感じます。

また「機能ユースケース」や「UIスペック」は実際の案件でもよく使用していて、コンパクトかつ効果的に感じます。複数事業部にまたがったり開発ベンダーの連携が必要なプロジェクト、サービス全体仕様のドキュメントがあまりなかったプロジェクトでも適宜カスタマイズして使用できます。

このRPGダンジョンライクな要件定義で、何か皆さんのお役に立てれば嬉しく思います。

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