前の章に戻る
- ✓リサーチ結果（ペルソナ・ジャーニー・インサイト）から、作るべき機能とコンテンツを独力で洗い出せる
- ✓洗い出した要件を、MoSCoWでMust・Should・Could・Won'tに独力で優先順位づけできる
- ✓要件定義書にまとめ、クライアント役に提案してすり合わせ、合意版に更新できる
前回（2-5）では、ペルソナとジャーニーマップを作り、リフトのユーザー像とつまずきどころを固めました。今回は、それを作るものの要件に落とし、優先順位をつけてクライアントと合意します。仕上げる成果物は、要件定義書（合意版）の1点です。
リサーチを終えると、あれもこれも作りたくなります。空き枠が見える予約、リマインド、マイページ、口コミ機能。どれも良さそうに見えますが、今回すべてを作る時間はありません。しかも、あなたが良かれと思って決めた要件を、オーナーの織田さんは望んでいないかもしれません。作り始めてから違うと言われれば、時間も信頼も失います。この章でやるのは、前回のリサーチ結果を作るべき機能へ翻訳し、MoSCoWで優先順位をつけて絞り込み、作り始める前に織田さんと合意することです。
リサーチ結果を要件に翻訳する
リサーチで見えたユーザーのつまずきは、そのままでは作れません。ジャーニー上のつまずき（課題）を、それを解く機能やコンテンツに一つずつ対応させるのが、要件への翻訳です。
- 空き枠が電話やLINEでしか分からず、予約に何度もやり取りが要る
- 空き枠がひと目で分かる予約カレンダー
- リマインドがなく予約を忘れ、無断キャンセルにつながる
- 予約前日のリマインド通知
- 見込み客はネットの情報が古く、料金や予約方法が分からず申込をためらう
- 最新の料金・アクセス・トレーナー紹介ページ
- 運動初心者は続けられるか不安
- 初回体験の流れと雰囲気が分かるコンテンツ
対応表にすると、その機能がなぜ要るのかを、課題までさかのぼって説明できます。逆に、対応する課題が見つからない機能は、今回の要件から外します。
機能の一覧だけを見せられても、クライアントは判断できません。どのユーザーのどのつまずきを解くのかを添えると、要件に説得力が生まれ、後の優先順位づけもぶれません。
まずはジャーニーのつまずきを書き出し、その一つひとつに、解く手段を並べましょう。実務でも、この対応表があれば、提案した機能が解く課題までさかのぼって説明でき、追加の要望が来てもどの課題を解くのかを問い返して、必要かどうかを一緒に確かめられます。
MoSCoWで優先順位をつける
洗い出した要件を、すべて今回作れるわけではありません。MoSCoWは、要件をMust・Should・Could・Won'tの4段階に仕分ける、優先順位づけの方法です。
必ず必要
後回し可
あれば嬉しい
今回やらない
Mustは、これがないとサービスとして成り立たない要件だけに絞ります。迷う要件はShould以下に置き、今回やらないものはWon'tにはっきり書きます。
すべてをMustにすると、優先順位そのものが消え、限られた時間で作りきれなくなります。今回やらないこと（Won't）を先に決めると、何に集中するかがはっきりします。
要件を一つずつ4段階に置き、Mustが多すぎないか見直すことが重要です。予算や納期が限られる案件では、このMoSCoWがそのまま交渉の土台になり、クライアントが要件を増やしたがっても、Mustを守るために何をWon'tへ回すかを一緒に決められます。
要件定義書にまとめる
優先順位までつけたら、判断の全体を一つの文書にまとめます。要件定義書は、何のために・誰のために・何を作るのかを、後から誰が見ても分かる形に固定する成果物です。
各項目は、前の工程の成果物をそのまま引いて埋めます。ゼロから考えるのではなく、ヒアリングやペルソナ、MoSCoWの結果を、該当する欄に移すだけです。
やること以上に、今回やらないこと（Won't）を書いておくと、後からの追加要望や認識のずれを防げます。作る前に、範囲を1枚で示せる状態にしておきましょう。
テンプレートの空欄を、前の工程の成果物で一項目ずつ埋めましょう。1枚にまとまった要件定義書は、そのままクライアントへの提案資料になり、打ち合わせで合意を取りやすく、次の情報設計やワイヤーフレームの出発点にもなります。
クライアントと合意する
要件定義書ができても、それはまだあなたの案にすぎません。実務では、要件を自分で決めて終わりにせず、クライアントに提案して合意を得るところまでが要件定義です。
提案すると、あなたの優先順位とクライアントの実感がずれることがあります。ずれたら、相手の話から実態を引き出し、MoSCoWを組み替えて合意版に更新します。
作り始めてからのずれは、手戻りが大きくなります。要件の段階でクライアントと握っておけば、修正は文書の1行で済み、時間も信頼も守れます。
この講座では、織田さん役をAI（Gem①）が演じます。次の演習で提案し、実態が出たら遠慮なく優先順位を握り直しましょう。実案件でも、要件定義書は合意を取るための1枚で、提案して合意を得ておけば後の工程での大きな手戻りを避けられ、頼れる相手だと信頼されます。
2-2と同じGem①です。要件定義書を提案してすり合わせましょう（Googleアカウントのログインが必要）。
演習：要件定義書を作ってクライアントと握る
これまでの手順を、リフトの案件で最後まで通します。要件定義書を自作し、クライアント役の織田さん（Gem①）に提案してすり合わせ、合意版に更新します。
STEP 1：リサーチ結果を要件に洗い出す
- 前回のペルソナ・ジャーニーから、ユーザーのつまずき（課題）を書き出す
- 各課題を解く機能やコンテンツを、一つずつ対応させる（対応する課題がない機能は入れない）
STEP 2：MoSCoWで優先順位をつける
- 洗い出した要件を、Must・Should・Could・Won'tの4段階に仕分ける
- Mustはこれがないと成り立たないものだけに絞り、今回やらないことをWon'tに明記する
STEP 3：要件定義書にまとめる
- 背景・目的／対象ユーザー／成功指標／機能要件（MoSCoW）／スコープ（やること・やらないこと）／制約・前提の6項目を埋める
- 各欄は、前の工程の成果物から引いてくる
STEP 4：クライアント役に提案して、すり合わせる
- 上の「💬 Gem①を開く」ボタンから織田さん役を開き、要件定義書を提案する
- 相手の反応を聞き、実態が出たら、どこがずれたかを書き留める
クライアント役の織田さん（Gem①）は、2-2のヒアリングと同じGemです。上の「💬 Gem①を開く」ボタンから開き、挨拶のあとに要件定義書を提案してすり合わせます。Gemとの対話は、音声入力を活用して実際の会話のように進めましょう。相手の回答は演習用の擬似で、最終的な合意の確認と評価はコーチが行います。実在する個人が特定できる情報や機密は入力しないでください。
STEP 5：合意版に更新する
- すり合わせで分かった実態をもとに、MoSCoWを組み替える
- 変えた箇所と、なぜ変えたかを、要件定義書に書き添える
完了条件（提出物）
この成果物は、章の最後でまとめてコーチに提出しましょう。
- ユーザーの課題と、それに対応する機能要件の一覧ができている
- 機能要件がMoSCoWの4段階に仕分けられ、Won'tも書けている
- 6項目の要件定義書（合意版）ができ、すり合わせで変えた箇所とその理由が書き添えられている
リサーチを要件に落とし、優先順位をつけ、クライアントと握るこの流れは、実案件の要件定義そのものです。次回は、この要件の土台となる価値を、あらためて定義します。