ポイント・オブ・ビュー（POV）文は、共感フェーズで集めた観察データを「解決すべき問題の定義」に変換するための文章フォーマットです。定義フェーズの核心的なアウトプットであり、この後の創造フェーズで使うHow Might We（HMW）の出発点になります。

POV文の基本構造

POV文の標準フォーマットは次の通りです。

[ユーザー] は、[ニーズ] を必要としている。なぜなら [インサイト] だからだ。

各要素の定義：

ユーザー： 共感インタビューや観察で出会った、具体的な人物。「34歳の会社員」ではなく「毎朝コーヒーを飲みながら通勤電車で30分を過ごす田中さん」のように、状況と文脈を含める
ニーズ： ユーザーが達成したいことや解消したいこと。「〜できること」「〜な状態」で表現する。解決策（「アプリがほしい」「機能がほしい」）にしないことが重要
インサイト： なぜそのニーズがあるのかを説明する洞察。表面的な理由ではなく、観察・インタビューから引き出した「なるほど」という発見

なぜPOV文が必要か

ワークショップでよく起こるのは、共感フェーズで膨大なインタビュー記録・観察メモが集まった後、チームが「さあ、アイデアを出そう」と創造フェーズに飛びつくパターンです。

この飛びつきが問題です。問題が定義されないまま解決策を生成しても、「誰のどんな問題を解く答えなのか」が不明瞭なアイデアの山ができるだけです。POV文はこの移行を構造化します。

実際にやってみると、POV文を書くプロセスで「私たちが本当に解くべき問題は何か」について、チームで初めて真剣に議論が生まれることが多い。

ステップ

Step 1：共感データの棚卸し

インタビュー記録・観察メモから「印象的な発言・行動・感情」を付箋に書き出します。1枚の付箋につき1つの発見を書きます。グループ全員の発見を壁に貼り出し、全体を俯瞰します。

Step 2：ユーザー像のプロファイリング

複数の人へのインタビュー・観察から得た発見を統合し、「誰のPOV文を書くか」を決めます。実在した1人の人物を元に書くか、複数のインタビューから構成した「典型的なユーザー像」を設定します。

ユーザー像は属性（年齢・職業・性別）ではなく「状況と文脈」で定義します。「30代の働く母親」より「保育園のお迎え後、夕食準備をしながら宿題も見なければならない状況の人」の方が、問題定義に接続しやすいユーザー定義です。

Step 3：ニーズを動詞で表現する

ニーズは「〜を必要としている（needs to…）」で始まる動詞句で書きます。

ニーズの書き方の例（悪い例と良い例）：

悪い例：「通知機能がほしい」→ これは解決策
悪い例：「便利なアプリがほしい」→ 抽象的すぎる
良い例：「重要な情報を他の情報に埋もれさせないでいつでも確認できる状態にする」
良い例：「夕方の忙しい時間帯に、最小限の決断で夕食の準備を終わらせる」

Step 4：インサイトを「なぜ」から引き出す

インサイトは「なぜそのニーズがあるのか」の洞察です。表面的な理由（「忙しいから」）ではなく、観察から得た「知らなければ気づかなかったこと」を書きます。

インサイトを引き出すための問い：

「このユーザーが[ニーズ]を持つ背景には、何があるのか？」
「表面的な理由の、その奥に何があるか？」
「なぜ今の解決策では不十分なのか？」

インサイトの例：「料理の手順は覚えているが、『何を決めなければいけないか』が多すぎることへの疲弊感が、料理を億劫にさせている」

Step 5：POV文を書いて声に出して読む

フォーマットに当てはめてPOV文を書きます。書いたら声に出して読み、以下を確認します：

ユーザーの状況が目に浮かぶか
ニーズが解決策ではなく、解決すべきことの表現になっているか
インサイトが「知らなければ気づかなかった発見」になっているか
このPOV文を読んだ人が「なるほど、この問題を解きたい」と思えるか

実例

共感インタビューから：
田中さん（45歳・管理職）は、毎朝の朝礼で部下に話すことを「前日の夜に考えなければならない」ことが負担だと言っていた。「話すことが思い浮かばないとき、プレッシャーを感じる」「何か役立つことを言わなければという義務感がある」

POV文：
「毎朝の朝礼で部下に向けて話す田中さんは、その日のチームに意味のある問いや気づきを届ける言葉を、日々の業務の流れの中から自然に見つけられることを必要としている。なぜなら『良いことを言わなければ』というプレッシャーが、スピーチを義務感のある作業にしてしまい、本来の目的であるチームとの対話を遠ざけているからだ」

ファシリテーションのコツ

複数のPOV文を書く

1つのプロジェクトで3〜5本のPOV文を書くことを推薦します。複数のユーザー像について書くことで、問題の多様な側面が見えてきます。創造フェーズでどのPOV文に集中するかを議論するプロセス自体が、問題定義の深化になります。

「ニーズvs解決策」の混同を防ぐ

POV文を書く際に最も頻出する誤りは「ニーズ」の箇所に「解決策」を書いてしまうことです。「アプリが必要」「機能追加が必要」はすべて解決策です。「状態・体験・達成すること」という問いに変換して確認します。

チームで「アクション可能性」を確認する

書いたPOV文に対して「このPOVから、どんなHMWが生まれそうか？」という問いでテストします。アイデアの方向性が全く浮かばないPOV文は、ニーズかインサイトが曖昧なサインです。

よくある失敗と対策

失敗1：インタビューしていないユーザーのPOVを書く
「こういうユーザーがいるはずだ」という想像でPOV文を書いてしまうケース。POV文は必ず実際の観察・インタビューから引き出したデータを元に書く必要があります。

失敗2：インサイトが「事実の説明」になる
「忙しいから時間がない」はインサイトではなく事実の説明です。インサイトは「なぜその状況が問題として体験されるのか」の洞察であり、観察者の解釈が含まれます。

失敗3：ニーズを「より良い」で形容する
「より良い通知が必要」「より使いやすい画面が必要」は比較の基準が曖昧で、創造の方向性を制約します。具体的な状態・体験の言葉で書きます。

POV文の次のステップ

POV文が完成したら、そのままHow Might We（HMW）への変換に進みます。「[ユーザー]が[ニーズ]を達成できるのは、どうすれば可能か？」という問いの形に変換することで、創造フェーズへの橋渡しが完成します。

参考文献

Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018）
IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015
Liedtka, Jeanne & Ogilvie, Tim, Designing for Growth, Columbia Business Press, 2011