問題定義 NEW

POV文（Point of View文）の作成ガイド — デザイン思考問題定義を完結させる書き方

デザイン思考のdefineフェーズで使うPOV文（Point of View文）の書き方を、テンプレートと実例で解説。「ユーザー×ニーズ×インサイト」の3要素で問題定義を完結させる実践ガイド。

2026年5月13日 13分で読める

#POV文 #Point of View #問題定義 #インサイト #HMW #define #デザイン思考

共感フェーズで大量のインタビューデータを集めた後、チームは途方に暮れることが多い。「何がわかったのか」「何を解くべきなのか」——ここで問題定義を怠ると、数週間の調査が「なんとなく参考になった話」で終わる。POV文（Point of View文）は、インサイトを「解くべき問題の宣言」に変換する技術だ。

POV文とは何か

POV文（Point of View文）は、スタンフォードd.schoolが体系化した問題定義ステートメントだ。デザイン思考のdefineフェーズにおいて、共感フェーズで得た観察データを「チームが向かうべき問いの宣言」として凝縮する。

d.schoolの定義では、POV文は以下の3要素で構成される。

[ユーザー] は [ニーズ] が必要である。なぜなら [インサイト] だから。

この3要素が揃わない問題定義は、HMW（How Might We）の問いを立てるときに迷子になる。「インサイト」が抜けた状態でHMWを書くと、解決策が「当たり前の改善」に収束してしまうのが典型的な失敗パターンだ。

なぜPOV文が必要なのか

問題：インサイトが「感想」で終わる

ワークショップでよく起こるのは、インタビューのデータが「Aさんは忙しそうだった」「Bさんはアプリをあまり使っていなかった」という観察の羅列で終わるケースだ。観察事実は集まっても、そこから「なぜそうなのか」という解釈（インサイト）まで踏み込まないと、問題定義に使えない。

実際にやってみると、チームでポストイットを並べた後に「で、何が問題なの？」という問いで全員が沈黙する瞬間が訪れる。これは調査の失敗ではなく、観察からインサイトへの変換を省略したことが原因だ。

共感：「問いの合意」なしにアイデア出しが始まる

参加者からの声として多いのは「アイデア出しで全員がバラバラな方向を向いていた」という振り返りだ。Aさんは「UIをシンプルにする」、Bさんは「サポート体制を強化する」、Cさんは「機能を削る」——それぞれのアイデアが別の問いに答えている状況が生まれる。

問いの合意がないままアイデア発散を始めることが、収束不能なブレストの構造的原因だ。POV文はアイデア出し前にチームの問いを一本に絞る役割を担う。

POV文の3要素を理解する

要素1：ユーザー（User）

具体的な一人のユーザーを記述する。ペルソナの属性のリストではなく、「観察した実際のユーザー」または「複数の観察を統合した典型像」だ。

NG例：「30代のビジネスパーソン」（属性のみ、具体性ゼロ）

OK例：「新しいプロジェクト管理ツールを導入したばかりの中堅企業の人事担当者」（文脈と状況を含む）

スタンフォードd.schoolの実践では、ユーザーを記述する際に「インタビューで出会ったあの人」として一人に固有名詞を与える演習が行われる。「ユーザー全般」ではなく「あの人の問題」として向き合うことで、問いの解像度が上がる。

要素2：ニーズ（Need）

ユーザーが「本当に達成したいこと」を動詞で表現する。ここで注意が必要なのは、ニーズはソリューションを含まない点だ。

NG例：「アプリの通知設定を変更したい」（ソリューション前提）

OK例：「重要なタスクを忘れずにこなした感覚を持ちたい」（達成したい状態）

実際にやってみると、最初の「ニーズ」にはソリューションが混入していることが多い。「〜を使いたい」「〜できるようにしたい」という表現がソリューション混入のサインだ。「〜を感じたい」「〜でありたい」という感情・状態の表現に変換することで、ニーズの純度が上がる。

要素3：インサイト（Insight）

最も難しいのがインサイトの抽出だ。インサイトとは、観察事実の背後にある「なぜそうなのか」という驚きのある解釈だ。

観察事実（データ）：「ユーザーはリマインダー通知が来ても確認しないことが多い」

インサイト（解釈）：「通知は情報の到達を保証するが、行動への移行を保証しない。ユーザーは『見た』ことと『やった』ことの間に明確な区切りを求めている」

インサイトは「なるほど、だからそうなるのか」という腑に落ちる感覚を引き起こす。表面的な観察を解釈したとき、「そうか、そういうことか」という感覚が起きないなら、まだ観察止まりだ。

POV文の書き方：ステップバイステップ

ステップ1：観察データを並べる（10分）

インタビューや観察で得たデータをポストイットに書き出す。この段階では解釈せず、「見た・聞いた」事実のみを記録する。

ステップ2：ニーズの候補を動詞で書く（15分）

「このユーザーは本当に何を達成したいのか」を5〜10個列挙する。ソリューションが混入しているものは「状態・感情」の言葉に変換する。

ステップ3：インサイトを1行で書く（20〜30分）

「なぜそのニーズが満たされていないのか」を解釈する。「しかしながら（but）」「なぜなら（because）」「驚くことに（surprisingly）」で始まる文を試みると、インサイトらしい解釈が出やすい。

しかしながら、〇〇という状況がそれを妨げているなぜなら、ユーザーは〇〇という前提で動いているから驚くことに、ユーザーは〇〇を求めているのではなく〇〇を求めていた

ステップ4：3要素を組み合わせてPOV文を書く（10分）

テンプレートに当てはめて文として成立させる。

[ユーザー] は [ニーズ] が必要である。なぜなら [インサイト] だから。

完成したPOV文を声に出して読む。「この問題を解くチームに自分はなりたいか」という感覚が起きれば、問いに引力がある。感覚が薄ければ、インサイトの掘り下げが不足している可能性が高い。

ステップ5：HMWに変換して確認する（5分）

良いPOV文は、自然にHMWへと変換できる。変換が難しいと感じる場合、POV文のどこかに曖昧さが残っている。

POV文： 「新しいツールを導入した人事担当者は、変更への抵抗なくチームに使い続けさせたい。なぜなら、ツールの価値はチーム全員が使い始めて初めて発現するものだと認識しているから」

HMW： 「どうすれば、チームメンバーが抵抗感なく新しいツールを使い始める体験を設計できるか？」

よくある失敗パターンと対策

失敗1：POV文が「ソリューションの言い訳」になる

「（ユーザーの名前）は、私たちのソリューションを使う必要がある。なぜなら〜」という形になっているケースが多い。これはPOV文ではなく、プレゼンの正当化だ。

対策： ユーザーのニーズを書いた後、「もし私たちのソリューションが存在しないとしても、このニーズは残るか？」と問う。残るなら本物のニーズだ。

失敗2：インサイトが「調査の要約」になる

「ユーザーは忙しいから〜」「ユーザーはITが苦手だから〜」という記述は、インサイトではなく属性の説明だ。

対策： 「この事実は他のプロジェクトでも言える普遍的なものか」を確認する。普遍的なら差別化のないインサイトだ。このユーザーの文脈でのみ成立する特異な解釈こそが良いインサイトになる。

失敗3：チームで合意形成なしに一人が書く

POV文をファシリテーターが一人で書いてチームに配布するケースがある。形式は整うが、チームの「問いへのオーナーシップ」が失われる。

対策： POV文はチームで書く。複数のPOV文候補を書き出し、投票と対話で一本に絞るプロセスが重要だ。このプロセスで「私たちは何を解くチームなのか」という共通認識が生まれる。

POV文の実例：ワークショップ3シーン

シーン1：医療機関のデジタル化プロジェクト

観察： 看護師が電子カルテを更新するのは、患者の部屋を出た廊下のナースステーションでまとめて行う。患者の前ではほとんど入力しない。

POV文： 「夜勤の病棟看護師は、患者との関係を損なわずに記録の正確性を保ちたい。なぜなら、スクリーンを見ながら患者と話すことは、患者に『機械に話しているようだ』という感覚を与えると彼女が知っているから」

HMW： 「どうすれば、患者の目の前でも記録行為が『ケアの一部』として受け取られる体験を設計できるか？」

シーン2：B2B SaaSのオンボーディング改善

観察： 導入3週間後にチャーンしたユーザーに話を聞くと、機能の「使い方がわからなかった」ではなく「何に使えばいいかわからなかった」が多かった。

POV文： 「導入初期の経営企画担当者は、このツールで自分たちが抱える問題を解けるかどうかを確信したい。なぜなら、使い方の理解より前に『これは自分たちの問題の道具か』という確信がないと操作を学ぼうとしないから」

HMW： 「どうすれば、初回ログインの体験が『使い方の学習』より前に『私の問題に効く』という確信を生み出せるか？」

シーン3：社内コミュニケーションツールの導入

観察： 全社展開したチャットツールで、マネージャー層だけ使用率が低い。デジタルツールへの拒否感は見られない。

POV文： 「中間管理職のマネージャーは、チームとのコミュニケーションの記録が残ることへの心理的安全を必要としている。なぜなら、テキスト化された自分の発言が文脈から切り取られて共有されるリスクを強く意識しているから」

HMW： 「どうすれば、テキストコミュニケーションの記録性がマネージャーにとって脅威ではなく資産として機能するか？」

POV文とHMWの連携：問いの設計全体像

POV文は単独で機能するのではなく、HMW（How Might We）とセットで問い設計を完成させる。

デザイン思考の問い設計は「POV文 → HMW → アイデア発散」の流れで進む。POV文が「解くべき問題の宣言」、HMWが「アイデアを引き出す問いの形式」、そしてアイデア発散で具体的な解決策の候補が生まれる。

実際にやってみると、POV文の解像度がそのままHMWの引力に変換されることがわかる。浅いPOV文からは「まあそうだよね」というHMWしか生まれない。深いインサイトのあるPOV文からは「これ、面白い問いだな」と感じるHMWが自然に出てくる。

やってみよう：POV文1本を書く

手元にインタビューデータがない場合でも、以下の練習から始められる。

練習1（5分）： 自分が最近不便を感じた体験を選ぶ。その体験を「ユーザー・ニーズ・インサイト」の3要素に分解してPOV文を書く。

練習2（15分）： 身近な人（家族・同僚）に5分インタビューして、一つの観察事実を深掘りする。「なぜそうしているのか」「どんな気持ちか」「何が理想か」を聞き、インサイトを抽出してPOV文を書く。

ポイント： 最初から「良いPOV文」を書こうとしない。3本書いて、チームで一番引力を感じる1本を選ぶプロセスがそのままファシリテーションの実践になる。