課題定義シートを書いた瞬間、会議室の空気が重くなったことはありませんか？
「今回の課題は〇〇です」と言い切った途端、なぜか身動きが取れなくなる。
後から「やっぱり違うかも」と思っても、今さら変えられない空気が漂う。
課題定義が、プロジェクトを縛る足かせになってしまう。
これは課題定義そのものの問題ではありません。課題定義に対する「たった一つの勘違い」が原因です。
なぜ課題定義が一番重くなるのか
多くの人が課題定義を「早く・正確に決めなければいけないもの」だと思っています。
プロジェクトの方向性を決める重要な工程だからこそ、間違えたくない。
だから慎重になる。慎重になるほど、一度決めたことを覆しにくくなる。
この悪循環が、課題定義を重くしている正体です。
前回の共感編では、「相手を理解しきれない」という前提で観察を続けることの大切さをお伝えしました。
実は課題定義にも、同じ発想が必要なのです。
課題を決めすぎてしまう典型的な失敗
私自身、何度もこの失敗をしてきました。
あるプロジェクトで「ユーザーは機能が多すぎて迷っている」と課題を定義しました。
自信を持って言い切りました。
ところが調査を進めるうちに、本当の問題は「機能の多さ」ではなく「どこから始めればいいか分からない」という導線の問題だと気づいたのです。
でも、もう課題は決まっている。チームは「機能を減らす」方向で動き始めている。
今さら「やっぱり違いました」とは言いにくい。結局、ズレを感じながらもそのまま進めてしまいました。
課題定義を「決定」だと思っていたから、修正することが「失敗を認めること」になってしまったのです。
課題は正解ではなく仮説
ここで発想を変えてみてください。
課題定義は「正しい課題を当てる作業」ではありません。
「仮にこう考えています」という合意を作る作業です。
仮説だからといって、適当でいいわけではありません。
むしろ逆です。「更新される前提」だからこそ、今この瞬間のベストな理解を言語化する。
そして新しい情報が入ったら、責任を持って更新する。これが「仮説として置く」ということです。
デザイン思考が現場で使えない理由で「正解を見つけるのではなく育てる」という考え方を紹介しました。
課題定義も同じです。
最初から完璧な課題を見つけようとするのではなく、プロジェクトを通じて課題の解像度を上げていく。
そういう姿勢が大切なのです。
私自身も正解を探すのをやめた体験を通じて、この考え方に辿り着きました。
「正解を当てなければ」というプレッシャーを手放すと、驚くほど動きやすくなるのです。
「仮説として置く」具体的なやり方
では、実際にどうすればいいのでしょうか。三つのポイントがあります。
一つ目は、言い切らないこと。
「課題は〇〇です」ではなく「いまの理解では、課題は〇〇だと考えています」と伝える。
たったこれだけで、後から更新する余地が生まれます。
二つ目は、更新前提で共有すること。
「この課題定義は、調査が進むにつれて変わる可能性があります」と最初に宣言しておく。
チーム全体が「変わるもの」として受け止めてくれます。
三つ目は、課題定義そのものを検証対象に含めること。
「この課題設定で合っているか？」をプロジェクト中ずっと問い続ける。
ユーザーテストや調査のたびに、課題定義を見直すタイミングを設けるのです。
課題定義が軽くなると何が変わるか
仮説として置く習慣がつくと、プロジェクト全体の空気が変わります。
まず、修正が「失敗」扱いされなくなります。
「課題の解像度が上がりました」と報告できる。
むしろ前向きな進捗として受け止められます。
次に、会話が前向きになります。
「この課題で本当に合ってる？」という問いかけが、批判ではなく建設的な確認になる。
チームの心理的安全性が高まります。
そして、判断がスムーズになります。
「仮説だから」と軽く置けるので、決断に時間がかからない。
スピード感を持ってプロジェクトを進められます。
まとめ
課題定義で動けなくなる原因は、「正解を当てなければ」という思い込みです。
課題は決めるものではなく、仮説として置くもの。
更新される前提で共有し、プロジェクトを通じて育てていく。
この発想に変えるだけで、課題定義は足かせではなく、前に進むための道しるべになります。
次に課題を言語化するとき、ぜひ「仮に」「いまの理解では」という前置きを入れてみてください。
きっと、会議室の空気が少し軽くなるはずです。
正解を育てるには、まず自分の現在地を知ることから。
自分を観測するための100の問いというPDFを無料で配布しています。
課題を仮説として置く前に、自分自身の思考の癖を観測する習慣をつけてみてください。
