layers-user-needs

/layers-user-needs

/layers-intro が読み込まれていることを前提とします。このスキルはテクニックのライブラリであり、スクリプトではありません。詳しくは、そちらの「これらのスキルの使い方」をご覧ください。

ユーザーニーズとは、ユーザーが何を達成しようとしているのか、そしてその理由についての私たちの考えです。観察された行動とドメイン知識をもとに解釈したものであり、現実を直接捉えたものではありません。このレイヤーは、観察から得られた雑多な素材と、ソリューション空間における意図的な意思決定の間に位置します。

ここで導き出すのは機会です。ニーズ（ユーザーが達成したいこと）、ペイン（摩擦の原因）、願望（ユーザーが価値を感じる改善）が含まれます。いずれも有効なため、3つすべてを引き出してください。

---

このレイヤーで行う意思決定

• ニーズを定義する対象となるユーザーは具体的に誰か、またどのような状況にいるのか
• どのような用事を果たそうとしているのか：機能的、感情的、社会的なもの
• どのニーズがエビデンスに裏付けられていて、どれが仮説なのか
• どのニーズが最も重要で、その理由は何か

ニーズがすでに明確で根拠もあるなら、必要もないのに改めて引き出さないでください。/layers-product-strategy に進めてください。

---

規律 — ニーズの妥当性を保つために

• ソリューションではなく、ニーズを捉える。 「レポートが必要なとき、CSV にエクスポートしたい」はソリューションです。その根底にあるニーズを掘り下げてください。
• 仕組みを取り除く。 「When」の節で特定のソリューション（自社のダッシュボード、CSM、週刊メールなど）に言及している場合、ニーズではなく現行のシステムを説明しています。誰が、あるいは何がそれを提供するかに左右されない形で言い換えてください。そのニーズが生じた瞬間、ユーザーには何が起きているのでしょうか？ ニーズは仕組みではなく、その状況から導かれます。
• 「When」は具体的に思い描けるものにする。 その瞬間が起きる様子を想像できるほど具体的にしてください。きっかけは、出来事、感情、周期、あるいはしきい値を超えたことかもしれません。具体的になるまで掘り下げてください。
• 機能的な用事だけでなく、感情的・社会的な用事も引き出す。 行動に影響していても、これらは恒常的に言語化されにくいものです。明示的に尋ねることで、表面化することが多くあります。（機能的 → インタラクションとモデル、感情的 → 表面のトーン／フィードバック、社会的 → 表面、場合によっては戦略。）
• 確信度を示す： 観察済み／推論／仮定。
• 回避策は重要なサインです。 スプレッドシートや回避のためのメールを使う動機になるほどのニーズは、強いニーズです。

---

テクニック

ジョブストーリーが基本です。それ以外は特定の状況に適しています。

テクニック	使用する状況
ジョブストーリー（JTBD）	基本。When [状況]、[動機] のために [目的] したい。 ソリューションを持ち込まずに済み、「When」の節によって具体性が求められます。
ユーザーストーリー	チームが役割ベースの表現や、既存のアジャイルワークフローを好む場合。
最重要タスク分析（Gerry McGovern）	既存ユーザーが多い場合。頻度をもとに、どのタスクが最も重要かを特定します。統計的な調査手法です。
ペルソナ＋シナリオ	アーキタイプで考えるステークホルダーに伝える場合。認識合わせには有効ですが、デザインの精度は低めです。
ODI の望ましい成果（Ulwick）	「[状況] における [指標] を最小化する」のような、精密で測定可能な表現です。機会スコアリングに直接対応します。
隠れたニーズを表面化する	見過ごされていることを探るための問いかけです。注目している瞬間の前後にユーザーが何をするか、何をしなくて済めばよいと思っているか、回避策が現在どのような役割を果たしているかを尋ねます。
大まかな優先順位付け	重要度 × 現在どれだけ満たされていないかで順序を決めます。重要でありながら十分に満たされていないニーズは、価値の高い機会です。概算にとどめてください。精密なスコアリングは戦略策定の領域です。

---

デザイナーとの協働

まず、ユーザーが誰で、どのような状況にいるのかを明確にします。「ユーザー」全般ではなく、どのタイプのユーザーが、いつ利用するのかを特定します。ニーズの異なるタイプが複数ある場合は、それぞれ分けて検討します。情報源（リサーチ、ドメイン知識、または仮定）を記録し、仮定の場合はその旨を明記して、検証計画を立てます。

次に、デザイナーが挙げたニーズを、上記の各分野に沿って検討し、表面化していないニーズも探ります。状況に合った手法を提案します。通常はジョブストーリー、測定可能性が重要な場合はODI、ユーザーベースが大規模な場合はトップタスクを使います。決められた順序で進める必要はありません。

判断に役立つ要素だけを残します。優先順位と確信度を付けたニーズ、優先順位は付いていないものの明らかになったニーズ（見落とさないため）、不足している情報（実在する可能性は高いものの、まだ根拠が得られていないニーズ）、ユーザータイプ間の矛盾です。

これらのニーズが、/layers-product-strategy に取り組む機会になります。ニーズの大半が仮定に基づいている場合は、戦略を立てる前に証拠を集めるため、/layers-observed-behaviour の利用を検討してください。