ユーザーニーズ
ペルソナが「何を実現したいか」を定義します。
月間実行回数を設定することで、ROIに基づいた優先順位付けが可能になります。
なぜユーザーニーズが重要か
よくある失敗パターン
「これは絶対必要」「あれも外せない」「全部マストです」
全ての機能が「最優先」になり、何から着手すべきか誰も判断できない。 結果、政治力のある人の要望が通り、本当に価値のある機能が後回しになる。
toishi のアプローチ
各ユーザーニーズに月間実行回数を設定することで、 「この機能は月45,000回使われる」「この機能は月200回しか使われない」と数字で比較できます。 感情ではなくデータで優先順位が決まります。
入力する項目
タイトル
「〜したい」形式で、ユーザー視点でニーズを表現します。
良い例
- • 商品を素早く検索して見つけたい
- • お気に入りに登録した商品の在庫復活を知りたい
- • 購入履歴から簡単に再注文したい
悪い例（機能名になっている）
- • 検索機能 ← なぜ必要かが分からない
- • プッシュ通知 ← ユーザー視点ではない
詳細説明
ニーズの背景や、どのような状況で発生するかを詳しく記述します。
記入例
田中さん（28歳マーケター）は通勤電車の中で、欲しい商品を素早く探したい。 現行サイトでは検索結果の表示に3-4秒かかり、絞り込み条件も使いにくいため、 隙間時間では十分な検索ができずに諦めることが多い。 検索時間を1秒以内に短縮し、直感的なフィルタリングを提供することで、 通勤中でも効率的に商品を探せるようにしたい。
月間実行回数 ⭐ 重要
このニーズが月に何回実行されるかを推定します。ROI計算の基礎となる最重要項目です。
推定方法
- 1. 既存データがある場合
アクセス解析から該当機能の利用回数を確認 - 2. 類似サービスを参考にする場合
業界平均や競合の公開データから推定 - 3. ボトムアップで計算する場合
ターゲットユーザー数 × 1人あたりの想定利用回数/月
記入例
- • 商品検索: 45,000回/月（現行サイトのアクセス解析より）
- • 在庫復活通知: 2,000回/月（お気に入り登録数 × 在庫切れ率 × 復活率で推定）
- • 再注文: 8,000回/月（リピート購入率から推定）
紐付くペルソナ
このニーズを持つペルソナを選択します（複数選択可）。
記入例
• 田中花子（プライマリペルソナ）
• 鈴木太郎（セカンダリペルソナ - 業務用まとめ買い）
Claude Code での操作例
あなた
「toishiのユーザーニーズに追加して。 『商品を素早く検索して見つけたい』、月間実行回数は45,000回、 ペルソナは田中花子」
AI
ユーザーニーズを追加しました。
- タイトル: 商品を素早く検索して見つけたい
- 月間実行回数: 45,000回
- ペルソナ: 田中花子
このニーズの詳細説明も追加しますか？ 例えば「通勤電車で隙間時間に検索したい」など。
あなた
「追加して。現行サイトは検索に3-4秒かかるから、1秒以内にしたい、という背景も入れて」
承認のポイント
承認者はここをチェック
- ✓ ニーズがユーザー視点で書かれているか（「〜したい」形式）
- ✓ 月間実行回数の根拠が示されているか（データ or 推定方法）
- ✓ ペルソナと紐づいているか
- ✓ 詳細説明で「なぜこのニーズが重要か」が分かるか
- ✓ 類似のニーズが既に存在しないか（重複チェック）
月間実行回数の決め方
既存データを使う（最も信頼性が高い）
Google Analytics、Mixpanel などのアクセス解析ツールから、 該当機能の利用回数やページビューを確認します。
ユーザーヒアリングで確認する
「この機能を月に何回使いそうですか？」と直接聞く。 5-10人に聞いて平均を取ると精度が上がります。
ボトムアップで計算する
ターゲットユーザー数 × 想定利用頻度 で計算します。
例：アクティブユーザー10,000人 × 月4.5回 = 45,000回/月
仮説を立てて後で検証する
データがない場合は仮説で始め、リリース後に実データで検証します。 「仮説: 2,000回/月」のように明記しておきましょう。
なぜこの設計なのか
月間実行回数（フェルミ推定）で定量化。「重要」「普通」の主観評価を排除
「この機能は絶対必要」と全員が言うと、優先順位が決まりません。 月間実行回数を設定することで、「この機能は月45,000回使われる」「この機能は月200回」と 数字で比較でき、声の大きい人ではなくデータで優先度が決まります。
受入基準を事前に書く。これが検証テスト計画に直結する
「検索結果が1秒以内に表示される」のような受入基準を事前に定義しないと、 開発終盤に「これでは遅すぎる」と言われて手戻りします。 受入基準を契約前に合意することで、「完成の定義」が明確になります。
「完成の定義」を作る前に合意する — 曖昧な完成定義が手戻りの最大原因
「動けばOK」では、発注者とベンダーで「動く」の定義が違います。 ユーザーニーズごとに受入基準を書くことで、 「この基準を満たせば完成」が契約時に確定し、後から「これも必要だった」を防げます。