POV（Point of View）ステートメントは、デザイン思考のDefineフェーズにおける核心的な成果物です。スタンフォード大学d.schoolが体系化したフレームワークで、共感フェーズで発見したインサイトを、チーム全員が共有できる「解くべき問い」に変換する役割を担います。
構造
POVステートメントの基本形は以下の通りです。
[ユーザー]は[ニーズ]を必要としている。なぜなら[インサイト]だから。
この3要素---ユーザー、ニーズ、インサイト---を明確に言語化することで、問題の焦点が定まります。d.schoolではこの形式を「POV Madlibs（穴埋め式）」と呼んでいます。
ニーズは動詞で表現するのが原則です。「安心感」ではなく「自分のペースで進められること」のように、行動に落とし込める形にすると、後のIdeateフェーズで具体的なアイデアが出やすくなります。
良いPOVと悪いPOVの違い
悪い例を見てみましょう。
「ユーザーは使いやすいアプリを必要としている。なぜなら現在のアプリが使いにくいから。」
この文はトートロジー（同語反復）に陥っています。「使いにくいから使いやすさが必要」では何も新しい情報がありません。インサイトの部分が、ニーズの言い換えになってしまっています。
良い例はこうなります。
「週末に一人で旅行する30代の会社員は、現地で偶然の出会いを楽しめる体験を必要としている。なぜなら、計画通りに進む旅行に物足りなさを感じており、予定外の体験にこそ旅の価値を見出しているから。」
ユーザーが具体的で、ニーズが動詞で記述され、インサイトが「意外性」を含んでいます。 「旅行者は効率的な計画を求めている」という一般的な仮説を覆す視点がここにあります。
作成プロセス
POVステートメントは、ユーザーインタビューや共感マップで集めたデータを、親和図法でグルーピングした後に作成します。
作成のステップは以下の通りです。
- ユーザーの特定 --- 具体的なペルソナや実在のインタビュー対象者を設定
- ニーズの抽出 --- 「ユーザーが達成したいこと」を動詞で表現
- インサイトの言語化 --- 共感フェーズで得た、チームの前提を覆す発見を明文化
- 統合 --- 3要素をPOVの型にはめ込み、チーム全員でレビュー
1つのプロジェクトで複数のPOVを作成し、最も可能性のあるものを選択するのが一般的な進め方です。3〜5個のPOV候補を作り、チームで議論して絞り込みます。
Ideateフェーズへのつながり
POVステートメントが確定したら、**「How Might We（どうすれば〜できるか）」**の問いに変換し、Ideateフェーズに進みます。
POVとHMWの関係は、問題の定義（POV）から解決の探索（HMW）への橋渡しです。HMWが広すぎる場合はPOVの焦点がぼやけているサインであり、定義に戻って再検討します。問題定義フェーズの記事も合わせてご覧ください。
参考文献
- Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018）