デザイナー視点で「要求定義書」に書いてあって欲しいこと
私はプロダクトのUIデザイナーをしていて、業務の中で要件定義書と画面仕様書は書くのですが要求定義書は書きません。自分の業務をする上で要求がこういう形で書いてあったら助かるなぁというのを勝手に考えてみました。
参考にした書籍
最初から要求定義のこと考えよう！と思ってやったわけではなく、書籍「カイゼン・ジャーニー」を読んでいて、備忘録的に要求定義のテンプレを作ってみました。とはいえ私は業務上、要求定義をすることはないのでそのままになるはずが、進行中のプロジェクトでたまたま活用する機会があり結果的にとっても役に立ちました。（学んだことは小さくても形にしといて損はないなぁとしみじみ。）
主に書籍の中で出てきた「ゴールデンサークル」と「インセプションデッキ」を元にし、会社でも使われていたテンプレをアレンジしました。
「インセプションデッキ」の全ての項目を網羅するのはとても大変そうなので、記載内容を参考に必要そうな項目だけチョイスしました。
以下考えたテンプレと解説です
（任意）と書いてある項目は案件ごとに必要だったら書くものです
背景
なぜこのようなニーズが発生するのかなど、チームが必要とする情報を説明します
課題
課題を提起します。利用可能な機会、およびユーザーにとって生み出される価値について説明してください。
なぜこれが課題なのか，なぜそれがあなたのビジネスにとって重要なのかを説明します。
目的とゴール
この問題を解決することにおける「成功」とはどのようなものでしょうか？なぜこれを作るのか，何を達成したいのかを説明します。
ここにはビジネスゴール・戦略が入る場合もあります
💡ユーザーニーズを満たすためだけでなく、競合対策や売り上げなどビジネス戦略的色合いが強い案件もあると思います。（UXとビジネス両戦略は切り離せるものではないと思いますが）その場合、ゴール達成の基準やステークホルダーが変わる可能性があるので、きちんと明示しましょう。
💡直近では「効果検証する」が目的に入っていたので、KPIもここにそのまま書いていますが別途KPIっていう項目を作ったがいいかもしれません…
ユーザーストーリー
ユーザーストーリーは機能ではありません。その対象者にとっての価値を表すものです。（その価値をもたらすための手段が機能になります）
あいまいな表現は避け、適切な抽象度のストーリーで書いてください。
具体的過ぎないタスクで記述されており、プロダクトオーナーと実現方法について交渉できる
ストーリー単独で顧客にとっての価値がある
そのストーリーが実現可能になった状態かどうかを確認するための基準が明確になっている
💡期待する影響は本案件によりユーザーのニーズが満たされることで、ユーザーの感情と行動がどうなることを期待してるかを書きます。
（例：学習アプリであれば）
- 感情→「学習が楽しくなる」「自分に自信がつく」
- 行動→ 「学習時間・セッション数が増える」
💡行動の内容は効果検証時のKPI指標にもなります。
夜も眠れない問題（任意）
UXやビジネス戦略上のリスク、進捗を妨げるリスクなど考えられるものを洗い出し見える化しましょう
やらないことリスト（任意）
何を諦めるかを予め明らかにしましょう。
本案件のスコープが明確になり、本当に重要なことにフォーカスできるようになります。
トレードオフスライダー（任意）
何を優先し、何を調整する（捨てる）のか、意思決定時の判断材料になります。原則としてすべての項目をMaxにはしないでください
💡項目は一般的に下記4つだそうです。
①予算内に収める（予算）
②機能を全部揃える（スコープ）
③期日を死守する（時間）
④高い品質、少ない欠陥（品質）
※自社案件だと、その時々で必要な項目が違いそうだなと思いテンプレ上の項目は空にしました
↓なかがわはじめさんが公開していたNotonからインセプションデッキのデータテーブルを拝借しました
心得）ゴールデンサークルを意識しましょう
ゴールデンサークル（Golden Circle）は、サイモン・シネック（Simon Sinek）によって提唱されたコンセプトで、「Why（なぜ）」から始めることの重要性を強調しています。
たいていは「What（何を）」から考え始めるのがわかりやすいためWhat（何を）から始めがちです。「Why（なぜ）」から始めることでより強い共感と信頼を築くことができるとされています。
Why（なぜ）：
企業やプロダクトの存在理由や目的を明確にします。なぜそのプロダクトを作るのか、企業の使命やビジョンは何か、という根本的な問いに答えます。
How（どのように）：
そのプロダクトやサービスがどのようにして提供されるのか、他と異なる点や競争優位性を説明します。具体的な手法や戦略について焦点を当てます。
What（何を）：
企業が提供する具体的なプロダクトやサービス自体を説明します。顧客に提供される製品やサービスの詳細です。
WhatとWhy、どちらを起点として考え始めるかで、Howの選択肢が大きく異なります。
（中略）
目的ではなく、具体的な手段の説明をどれだけされても、たいてい最後に聞き返したくなるでしょう。「それで、どうしてこれをやるんでしたっけ？」
補足）開発アイテムに親子関係がある場合
MVPでの開発を目指す場合、あるプロジェクトがあってその中で段階的にリリースしていくことになります。その場合、親であるプロジェクトの要求があって、それを背景とした子の開発アイテムの要求があるとわかりやすいのではと思います。
子である開発アイテムにアサインされた際に、親プロジェクトの全体像や要求が名文化されていると子アイテムの要件も立てやすくなります。
大きいプロジェクトであるほど、やること自体既に決まっているし、やるべきなのはみんなわかっている。でも「そのプロジェクトの1番の目的は？」と問われた時にみんなの答えが微妙に噛み合わない…ということが往々にしてあるように思います。
それぞれの単位でのスコープや優先すべきことが明確になれば、意思決定の精度も上がりそうです。
また、子アイテムで小さくリリース＆検証を繰り返していく過程で、親プロジェクトの要求に調整がされていることもあるでしょう。最初から明文化されてることで、その変化もメンバーが認知できるようになります。
おわりに
ここに書いた要求定義のテンプレは、まだまだ乏しい私の経験をもとにデザイナー目線で文書化してあると助かるなと思った内容です。エンジニアやPDM目線だと不足しているものもあるでしょう。
これから、実際のプロジェクトで活用してどんどんブラッシュアップしていけたらいいなと思っています。
この記事が気に入ったらサポートをしてみませんか？