成功する企業は、問題定義に「どれくらい」リソースを割いているのか？

Q. 新規事業を成功させた企業は、問題定義（課題の特定・言語化）にどれくらいのリソースを割いていたのか。成功と失敗の分かれ目はそこにあるのか教えてほしい。

• 成功する企業は、ソリューションづくりと「同じか、それ以上」のリソースを問題定義に注いでいる
• 大企業の新規事業が問題定義を軽視する理由は、組織の構造そのものにある
• 「正しい問い」にたどり着いたサインは、現場で必ず観察できる

問題定義には、ソリューションづくりと同じか、それ以上を注ぐ

新規事業を成功させた企業やチームは、問題定義に「ソリューションづくりと同じか、それ以上」のリソースを割いている。 ここで言うリソースとは、時間であり、投入する人の頭数であり、そこに注ぐ熱意のことだ。

ただし、「全体の何割」という厳密な数字を出すことに意味はない。 プロジェクトの性質で適正な比率は変わるし、パーセンテージを決めた瞬間に、その枠を埋めること自体が目的化してしまう。数字は出さない方がいい。

だが、比重の方向ははっきりしている。うまくいったチームは、例外なく、ソリューションのアイデアを広げる前の段階――「本当に解くべき問いは何か」を掘る時間に、初期のリソースを集中的に投下している。

アルベルト・アインシュタインが残したとされる言葉がある。「もし1時間あって、命が助かる問題を解かねばならないとしたら、55分を問題の定義に使い、5分をソリューションに使う」。本人が実際にそう言ったかどうかの真偽は別として、この比重の感覚は、新規事業の現場にほぼそのまま当てはまる。時間の大半を問いに、残りを解に。配分も順番も、この通りだ。

逆に、失敗するチームの時間配分は、きれいに真逆になる。問題定義は数日で切り上げ、残りの数ヶ月をソリューションの作り込みに注ぐ。傍から見れば、手が動いていて生産的だ。だが、問いがずれていれば、どれだけ精巧なソリューションを作っても的を外す。作れば作るほど、的外れなプロトタイプが積み上がっていく。正しくない問いを、正しく解いているだけだ。一生懸命なのに、ズレている。

成功と失敗の分かれ目は、まさにこの配分にある。何を作るかの前に、何を解くべきかへ、どれだけのリソースを寄せられたか。そこで勝負のほとんどが決まっているのだ。

なぜ大企業はソリューションに飛びつくのか

大企業の新規事業が問題定義を軽視してしまう理由は、個人の怠慢ではない。 組織の構造に起因している。

まず、技術・シーズ起点の呪縛がある。 「うちにはこういう技術がある、これで何かできないか」という出発点だ。技術が先にあるから、当然その技術を活かすソリューションを考え始める。問いを立てるより先に答えが決まっている状態だ。これは問題定義とは逆向きの思考だが、多くの大企業の新規事業はここから始まる。

次に、上司やステークホルダーが「形」を求める圧力だ。「で、それってどんなサービスになるの？」「プロトタイプはいつ出るの？」という問いが、プロジェクト開始後すぐに飛んでくる。問題定義の深掘りを続けているチームは、傍から見れば「何も進んでいない」ように映る。進捗が可視化しにくいからだ。一方でソリューションの検討やプロトタイプ制作は、「動いている感」を作りやすい。これが組織内での心理的な安全感につながるため、チームは意識しないままソリューションに引き寄せられていく。

もうひとつ、期限の構造がある。多くの大企業では、新規事業プロジェクトの進捗を「フェーズ」で管理する。ゲートレビューまでに成果を出さなければならないプレッシャーの中で、問題定義に時間をかけ続けることへの承認は得にくい。「課題の言語化」は成果物として見えにくいが、「ウェブサービスのワイヤーフレーム」や「ビジネスモデルの仮説」は提出しやすい。だから、自然と後者に時間が流れていく。

問題定義が軽視されるのは、チームが怠けているからではない。組織の評価軸と承認構造が、そういう行動を選ばせているのだ。

「正しい問い」にたどり着くための実践

では、どうすれば問題定義に十分な時間を割けるか。 そして、どのタイミングで「次のフェーズに進んでいい」と判断できるか。

まず、ソリューションへの着手を「意図的に止める」仕組みが要る。 具体的には、プロジェクトの立ち上げ段階で「問題定義フェーズ」を明示的に設け、そのフェーズ中はソリューションのアイデア出しを禁止するルールを作ることだ。これは荒療治に見えるが、効果は高い。人間は空白を埋めたがる生き物だから、「ソリューションを考えてはいけない」という制約をかけると、自然と問いの精度を上げることに思考が向く。アイデアを禁止するのではなく、「今はまだ問いを深める段階だ」と宣言し続けることが、チームのモードを切り替える。

次に、N=1の深掘りを重ねることだ。「多くの人が困っているはず」という仮説は、一人のユーザーを徹底的に観察しない限り空洞のままだ。10人に浅くインタビューするよりも、一人のユーザーの生活に深く入り込み、「なぜそれが問題なのか」「いつどこで困るのか」「今はどうやって対処しているのか」を掘り続けることで、問題の姿が鮮明になっていく。表層的な「不便さ」ではなく、その背後にある行動の動機や文脈を引き出すことが、問題定義の質を左右する。

「正しい問い」にたどり着いたサインの見極め方

問題定義にどれだけ時間をかければいいかは、「正しい問い」にたどり着いたかどうかで判断する。 そのサインは、現場で必ず観察できる。

ひとつは、チーム内で問いの表現が収束することだ。 最初は「〇〇業界のDXを支援する」という漠然とした言葉で語られていた課題が、「××職種の人が△△という状況で感じる□□という摩擦」という具体的な表現に変わっていく。この粒度の変化が、問題定義の深まりを示している。

もうひとつは、ユーザーインタビューで「まさにそれです」という反応が繰り返し出てくることだ。問題定義があいまいな段階では、インタビューで当たり障りのない回答が続く。だが問いが研ぎ澄まされてくると、インタビュー相手が「それ、すごく困ってます」「その言葉、ちゃんと伝わりますね」と前のめりになる瞬間が増えていく。これが現場からの確かなシグナルだ。

逆に言えば、「問題はなんとなくわかっているが、ソリューションが思い浮かばない」という状態は、問いがまだ深まっていないサインだ。正確に定義された問いは、ソリューションを呼び込む引力を持っている。ソリューションが出てこないときは、問いに戻る。それだけだ。

問いが正確なら、解くのは速い

成功している現場に共通しているのは、問題定義のフェーズで徹底的に問いを磨き、ソリューションのフェーズに入ってからは迷いなく動けるという構造だ。 問いが正確であれば、解くのは速い。問いがあいまいなままソリューションを量産すると、どこまで行っても答えには近づかない。

大企業の新規事業が難しいのは、ソリューションを作る技術やリソースは十分にあるのに、問うべき問いを見つける時間を組織が許容しにくいからだ。 その構造を変えるのは容易ではないが、少なくともチームの内側では変えられる。問題定義フェーズを守ることを、プロジェクト開始時に宣言する。それだけで、チームの動き方は変わる。

ソリューションは後でいくらでも作れる。でも、正しくない問いに答えを出し続けた時間は、絶対に取り戻せないのだ。