問題定義：POV（視点）とHMW（How Might We）で、取り組む問いを立てる｜デザイン思考入門 第3回

集めた情報を整理する

共感のモードで集めた発言、行動、気持ちを、次の手順で整理します（図1）。

1. 書き出す：インタビューや観察の記録から、印象に残った発言や行動を、1枚の付箋に1つずつ書き出します。発言はできるだけそのまま書きます。
2. 似たものをまとめる：付箋を並べ、似ているものどうしを近くに集めます。最初から分類の名前を決めず、まとまりができてから名前をつけます。
3. パターンを見つける：複数の人に共通していること、意外だったこと、言っていることと行動が食い違っていることに注目します。
4. インサイトを言葉にする：パターンの奥にある「なぜ、そうなっているのか」を言葉にします。

インサイトとは

インサイトとは、集めた事実を読み解いて得られる、新しい気づきのことです。単なる事実（「申請者は規程のPDFを何度も見ている」）ではなく、その事実がなぜ起きているのか、何を意味しているのかを示すものです。

• 事実：申請者は規程のPDFと申請画面を何度も行き来している。
• 事実：経理の担当者は、差し戻しの理由として「科目の選び間違い」をいちばん多く挙げた。
• 事実：申請者の多くが「間違えたくない」「差し戻されると恥ずかしい」と話した。
• インサイト：申請者が時間をかけているのは入力そのものではなく、「間違えて差し戻されることへの不安」から確認を繰り返していること。

このように、インサイトは「なるほど、そういうことか」という発見を含みます。作り手が最初から思っていたことと同じなら、それはまだインサイトになっていないかもしれません。

POV（視点）：誰の、どんなニーズに、どんな気づきがあるのか

整理した結果を、ひとつの文にまとめたものがPOV（Point of View、視点）です。d.schoolは、POVを、利用者、ニーズ、インサイトの3つを組み合わせた、行動につなげられる問題の言い方だと説明しています（参考資料1）（図2）。

POVは、たとえば次のような型で書きます。

［利用者］は、［ニーズ］を必要としている。なぜなら（驚いたことに）、［インサイト］だからだ。

経費精算の例なら、次のようになります。

月に数回だけ経費精算をする社員は、自信を持って一度で申請を終えられる手がかりを必要としている。なぜなら、彼らが時間をかけているのは入力ではなく、差し戻されることへの不安から確認を繰り返しているからだ。

よいPOVの条件

• 利用者が具体的：「社員」ではなく、「月に数回だけ申請する社員」のように、共感のモードで会った人の姿が浮かぶ。
• ニーズは動詞で書き、解決策を含まない：「AIで科目を自動判定する機能が必要」は、すでに解決策です。「自信を持って一度で申請を終えたい」のように、利用者が何をしたいのか、どうなりたいのかを書きます。解決策をPOVに入れてしまうと、次の発想のモードで、ほかの選択肢を考えなくなります。
• インサイトが含まれている：「なぜ」の部分に、共感のモードで見つけた新しい気づきが入っている。

HMW：アイデアを広げられる問いに変える

POVができたら、それをHMW（How Might We、どうすれば〜できるだろう？）という形の問いに変えます。IDEOの非営利組織であるIDEO.orgが公開している手法集「Design Kit」は、HMWの問いについて、次のように説明しています（参考資料2）。

• 「どうすれば〜できるだろう？」という言い方は、解決できる可能性があることを示しつつ、特定の答えを決めつけないので、創造的に考える余地を残す。
• ブレインストーミングの「出発点」になる。
• 作り方：インサイトを「どうすれば〜できるだろう？」で始まる問いに言いかえる。インサイトが支えるなら、複数の問いを作ってよい。
• 広すぎず、狭すぎないように調整する。いろいろな答えが考えられないほど狭ければ広げる。ただし、どこからブレインストーミングを始めればよいか分からないほど広くてもいけない。

ちょうどよい広さを探す

経費精算の例で、広さの違いを見てみましょう（図3）。

• 広すぎる：どうすれば、社員の仕事をもっと楽にできるだろう？（どこから考えればよいか分からない）
• ちょうどよい：どうすれば、月に数回しか申請しない社員が、自信を持って一度で申請を終えられるだろう？
• 狭すぎる：どうすれば、科目の選択欄に説明のツールチップをつけられるだろう？（答えが1つに決まっている）

1つのPOVから、いくつものHMWを作る

1つのPOVから、見る角度を変えて、いくつものHMWを作ることができます（図4）。

• どうすれば、申請者の「間違えたらどうしよう」という不安を小さくできるだろう？
• どうすれば、規程を見返さなくても、正しい科目が分かるようにできるだろう？
• どうすれば、間違いを申請の前に気づけるようにできるだろう？
• どうすれば、差し戻しを「責められる経験」ではなく「すぐ直せる経験」にできるだろう？
• どうすれば、経理の担当者の知識を、申請者が必要なときに借りられるようにできるだろう？

角度を変えると、「申請画面の改善」だけでなく、「経理の担当者とのやりとりの改善」「規程そのものの見直し」など、さまざまな方向のアイデアにつながります。次回の発想のモードでは、この中からいくつかのHMWを選んで、ブレインストーミングを行います。

この記事の監修者に相談できます

監修者の田中磨生が代表を務める株式会社Abinで、ご相談をお受けしています。

相談無料ツギノテ編集部に相談する→

よくある誤解

誤解1：問題は、依頼された時点で決まっている
「経費精算の画面を使いやすくしてほしい」という依頼を受けると、問題は「画面の使いにくさ」だと決めてしまいがちです。しかし、共感のモードで分かったように、本当の問題は「差し戻されることへの不安」にあるかもしれません。依頼された内容は、問題を考える出発点であって、答えではありません。問題定義の結果、依頼とは違う問いに取り組むべきだと分かったら、依頼した人にその理由を、共感で集めた事実とあわせて説明します。

誤解2：問いは1つに絞らなければならない
問題定義の目的は、たった1つの「正解の問い」を見つけることではありません。インサイトにもとづく問いを複数用意し、その中から発想に使うものを選ぶほうが、アイデアの幅が広がります。発想やテストの結果、別の問いのほうがよかったと分かれば、戻って選び直してもかまいません。

誤解3：インサイトは、データをたくさん集めれば自然に出てくる
大量の記録を集めても、それを読み解く時間をとらなければ、インサイトは見えてきません。「なぜ、この人はこう言ったのか」「なぜ、言葉と行動が食い違っているのか」をチームで問い続けることで、初めて新しい気づきが言葉になります。

実務ではこう使う：問題定義のワークの進め方

チームで問題定義を行うときの進め方の例です（図5）。

コツは、問いを決める前に、解決策の話をしないことです。メンバーから「それなら、こうすればいいのでは」とアイデアが出たら、別の紙（アイデア置き場）に書いておき、発想のモードで使います。ここで解決策の議論を始めると、問いを広く考える前に、答えが1つに決まってしまいます。

問いを書いたら、声に出して読んでみる

POVやHMWは、書いたあとで声に出して読んでみると、問題点に気づきやすくなります。読んだときに、共感のモードで会った特定の人の顔が浮かぶか。思わず「それなら、こんなこともできそう」とアイデアが湧いてくるか。逆に、どこかで聞いたような一般的な文になっていないか。チームの何人かに読んでもらい、受け取り方がそろっているかも確かめましょう。

問いを選ぶときの目安

HMWがたくさんできたら、次のような観点で、発想のモードで使う問いを選びます。

• 共感のモードで見つけたインサイトに、しっかりもとづいているか
• 解決できたとき、利用者にとっての価値が大きいか
• チームが取り組める範囲か（予算・期間・権限）
• いろいろな方向のアイデアが出そうか

この回のまとめ

• 問題定義は、共感で学んだことを読み解き、取り組むべき正しい課題をはっきりさせるモード。問いの良し悪しがアイデアの良し悪しを決める。
• 記録を付箋に書き出し、似たものをまとめ、パターンを見つけ、インサイト（事実の奥にある新しい気づき）を言葉にする。
• POVは、利用者・ニーズ・インサイトを組み合わせた問題の言い方。ニーズは動詞で書き、解決策を含めない。
• HMW（どうすれば〜できるだろう？）は、答えを決めつけずに発想を広げる問い。広すぎず、狭すぎないように調整する。
• 1つのPOVから角度を変えて複数のHMWを作り、発想で使う問いを選ぶ。問いを決める前に解決策の議論を始めない。

確認テスト

次回予告

第4回は「発想」です。選んだHMWの問いをもとに、ブレインストーミングの7つのルールに沿ってたくさんのアイデアを出し、その中から目的に合った方法でアイデアを選ぶ方法を学びます。

参考資料

1. Hasso Plattner Institute of Design at Stanford「An Introduction to Design Thinking PROCESS GUIDE」 https://web.stanford.edu/~mshanks/MichaelShanks/files/509554.pdf （確認日：2026年11月12日）
2. IDEO.org「How Might We」Design Kit https://www.designkit.org/methods/how-might-we.html （確認日：2026年11月12日）