試作までは進められる。
でも「見せる」「評価される」ところで止まってしまう。
検証フェーズが一番苦しいのは、あなただけではありません。
私自身、何度もそこで立ち止まりました。
なぜ検証フェーズが一番怖くなるのか
フィードバックをもらうのが怖い。
その感覚は、多くの人が抱えています。
「ダメ」と言われたら、自分の仕事が全否定されたように感じてしまう。
この怖さの根っこには、検証を「自分や案の価値を測られる場」として捉えてしまう構造があります。
合格か不合格か。
OKかNGか。
そう考えると、できるだけ完成度を高めてから見せたくなるのは自然な心理です。
しかし、完成度を上げてから見せようとすると、かえって失敗したときのダメージが大きくなります。
時間をかけた分だけ、やり直しが苦しくなる悪循環です。
検証を「合否判定」にしてしまう失敗
以前、ある案件でやらかしたことがあります。
「もう少し詰めてから見せよう」と思って、2週間かけてプロトタイプを磨き込みました。
結果、クライアントからの第一声は「方向性が違う」でした。
最初の段階で確認していれば30分で済んだ話を、2週間の作業の後に聞くことになったのです。
問題は、検証のタイミングではありませんでした。
「ある程度完成してから見せよう」という思考そのものが、検証を「合否判定」に変えてしまっていたのです。
視点転換：検証は次のサイクルの始まり
検証は「終わり」ではありません。
正解を育てるループの「再スタート地点」です。
この視点転換が腑に落ちると、フィードバックの意味が変わります。
「ダメ出し」ではなく、「次に何を見ればいいかの情報」として受け取れるようになります。
ただし、ここで誤解してほしくないことがあります。
検証を「次のサイクルの始まり」と捉えることは、判断を先延ばしにすることではありません。
むしろ逆です。
検証は「判断の精度を上げる行為」です。
責任を放棄するのではなく、より確かな判断をするために情報を集めているのです。
フィードバックを情報に変換する考え方
フィードバックを「感想」から「情報」に変えるコツがあります。
それは、見せる前に「今回は◯◯を見るための検証です」と前置きすることです。
「今回は、何が分かれば成功ですか？」と自分に問いかけてみてください。
その答えが明確になっていれば、フィードバックは感想ではなく、次のアクションにつながる情報になります。
たとえば「今回はナビゲーションの分かりやすさを確認したい」と決めておけば、色味の指摘があっても「それは次のサイクルで見ます」と整理できます。
すべてを一度に解決しようとしないことが、検証を軽くするポイントです。
小さく試すことで何が変わるか
プロトタイプは完成品ではなく「判断できる状態」を作る工程で書いたように、試作は判断材料を揃えるための作業です。
そして検証は、その判断を実際に行う場面です。
小さく試して学ぶと、修正は「失敗の後始末」ではなく「自然な次の一手」になります。
早く・小さく失敗した方が、結果的にプロジェクトはうまくいく。これは精神論ではなく、構造の話です。
シリーズを通して「正解を育てる」が実感できる
このシリーズでは、共感とは「分かる」ことではないから始まり、問題定義は仮説アプローチで進める、発想は正解を探すことではない、プロトタイプの目的は完成ではないと進んできました。
最終回の検証編まで読んでいただいた方には、「正解を育てる」という考え方が実感として伝わっているのではないでしょうか。
正解は最初から存在するものではなく、共感し、問いを立て、発想し、試作し、検証するサイクルの中で育っていくものです。
まとめ
検証が怖いのは、それを「合否判定」として捉えているからです。
次の検証で、ぜひ試してみてください。「今回は、何が分かれば成功ですか？」と問いかけること。その問いに答えられたとき、フィードバックは怖いものではなくなり、プロジェクトを前に進める情報に変わります。
シリーズ全5回の内容をまとめた無料PDFを配布しています。
気になった方は行き詰まったときに問いかける5つの質問からどうぞ。
