課題定義シートを書いた瞬間、会議室の空気が重くなったことはありませんか？
デザイン思考 問題定義のフェーズは、共感で集めた事実から「本当に解くべき問い」を見つける段階です。ところが多くの現場では、デザイン思考 問題定義が「正解の課題を当てるテスト」のように扱われ、書き切った瞬間に止まってしまう。この記事ではその構造を解きほぐします。
「今回の課題は〇〇です」と言い切った途端、なぜか身動きが取れなくなる。
後から「やっぱり違うかも」と思っても、今さら変えられない空気が漂う。
課題定義が、プロジェクトを縛る足かせになってしまう。
これは課題定義そのものの問題ではありません。課題定義に対する「たった一つの勘違い」が原因です。
- 課題定義を書いた瞬間に動けなくなる本当の原因（「正解を当てるテスト」化）
- 課題定義は「正解」より「仮説」として置く、という発想転換
- 仮説として置く3つの具体策（言い切らない・更新前提で共有・検証対象に含める）
- 課題定義が“軽くなる”とプロジェクトの空気がどう変わるか
記事を書いている人
R（アール）
Web制作の現場で17年（現役進行中）。精密栄養カウンセラー。
個人開発をアプリ6本並行しながら、AIと「作る・届ける」を実験しています。
うまくいったことも、月収2,000円みたいな冴えない数字も、隠さず公開中。
教える人ではなく、少し先で転んで戻ってきた人として、あなたと同じ目線で現在地を観測していけたらと思います。
デザイン思考の課題定義が一番重くなる理由
多くの人が課題定義を「早く・正確に決めなければいけないもの」だと思っています。
プロジェクトの方向性を決める重要な工程だからこそ、間違えたくない。
だから慎重になる。慎重になるほど、一度決めたことを覆しにくくなる。
この悪循環が、課題定義を重くしている正体です。
前回の共感編では、「相手を理解しきれない」という前提で観察を続けることの大切さをお伝えしました。
実は課題定義にも、同じ発想が必要なのです。
問題定義で決めすぎてしまう典型的な失敗
私自身、何度もこの失敗をしてきました。
あるプロジェクトで「ユーザーは機能が多すぎて迷っている」と課題を定義しました。
自信を持って言い切りました。
ところが調査を進めるうちに、本当の問題は「機能の多さ」というより「どこから始めればいいか分からない」という導線の問題だと気づいたのです。
でも、もう課題は決まっている。チームは「機能を減らす」方向で動き始めている。
今さら「やっぱり違いました」とは言いにくい。結局、ズレを感じながらもそのまま進めてしまいました。
課題定義を「決定」だと思っていたから、修正することが「失敗を認めること」になってしまったのです。
デザイン思考の課題定義は正解ではなく仮説
ここで発想を変えてみてください。
課題定義は「正しい課題を当てる作業」ではありません。
「仮にこう考えています」という合意を作る作業です。
仮説だからといって、適当でいいわけではありません。
むしろ逆です。「更新される前提」だからこそ、今この瞬間のベストな理解を言語化する。
そして新しい情報が入ったら、責任を持って更新する。これが「仮説として置く」ということです。
デザイン思考が現場で使えない理由で「正解を見つけるより育てる」という考え方を紹介しました。
課題定義も同じです。
最初から完璧な課題を見つけようとするより、プロジェクトを通じて課題の解像度を上げていく。
そういう姿勢が大切なのです。
私自身も正解を探すのをやめた体験を通じて、この考え方に辿り着きました。
「正解を当てなければ」というプレッシャーを手放すと、驚くほど動きやすくなるのです。
課題を“仮説”にするって、ただ言い切れていないだけじゃないんですか？
そこが分かれ目でした。仮説とは、今のベストな理解を言語化して、新しい情報が来たら責任を持って更新すること。だから次のやり方では、更新する前提を最初に宣言します。
問題定義を「仮説として置く」具体的なやり方
では、実際にどうすればいいのでしょうか。三つのポイントがあります。
一つ目は、言い切らないこと。
「課題は〇〇です」と言い切らず、「いまの理解では、課題は〇〇だと考えています」と伝える。
たったこれだけで、後から更新する余地が生まれます。
二つ目は、更新前提で共有すること。
「この課題定義は、調査が進むにつれて変わる可能性があります」と最初に宣言しておく。
チーム全体が「変わるもの」として受け止めてくれます。
三つ目は、課題定義そのものを検証対象に含めること。
「この課題設定で合っているか？」をプロジェクト中ずっと問い続ける。
ユーザーテストや調査のたびに、課題定義を見直すタイミングを設けるのです。
デザイン思考の課題定義が軽くなると何が変わるか
仮説として置く習慣がつくと、プロジェクト全体の空気が変わります。
まず、修正が「失敗」扱いされなくなります。
「課題の解像度が上がりました」と報告できる。
むしろ前向きな進捗として受け止められます。
次に、会話が前向きになります。
「この課題で本当に合ってる？」という問いかけが、批判というより建設的な確認になる。
チームの心理的安全性が高まります。
そして、判断がスムーズになります。
「仮説だから」と軽く置けるので、決断に時間がかからない。
スピード感を持ってプロジェクトを進められます。
まとめ
課題定義で動けなくなる原因は、「正解を当てなければ」という思い込みです。
課題は、決めて終わりにせず、仮説として置いておくもの。
更新される前提で共有し、プロジェクトを通じて育てていく。
この発想に変えるだけで、課題定義は足かせから、前に進むための道しるべに変わります。
次に課題を言語化するとき、ぜひ「仮に」「いまの理解では」という前置きを入れてみてください。
きっと、会議室の空気が少し軽くなるはずです。
もう一段だけ。課題を更新し続けられる人と、最初の定義に縛られる人を分けるのは、「自分が今その課題のどこに自信がなくて、どこで詰まっているか」が見えているかどうかでした。新しい時代に自分のスキルを伸ばすというのは、正しい課題を一発で当てる力より、自分の現在地を観測しながら問いを更新していけるようになることでした。
「正解を育てる」シリーズ
このシリーズでは、デザイン思考の各フェーズを「正解を育てる」視点で掘り下げています。全体ガイドは正解を育てる技術 ── 5ステップを「判断の道具」に変えるガイドをご覧ください。
正解を育てるには、まず自分の現在地を知ることから。
自分を観測するための100の問いというPDFを無料で配布しています。
課題を仮説として置く前に、自分自身の思考の癖を観測する習慣をつけてみてください。
「自分の強みは何か」が、見えなくなる時期があります。
診断を受けても、本を読んでも、「結局どう動けばいいか」が分からない。考えるほど止まる。これは個人クリエイターによくある状態です。
個人開発8本、月収2,000円。Web制作17年のクリエイターが、AI と「作る」「届ける」を honest に実験している過程をメルマガで公開しています。「観測する」生き方の実践ログです。
登録特典:「AI時代に取り残されないための構造整理シート」（PDF 12p / 5ステップ）― スキル棚卸しから、自分のポジション設計まで。
