研究やPoCが、なぜか前に進まないことがある。
手は動いている。
実験もしているし、コードも書いている。
それなのに、何ヶ月経っても「で、結局どうなの」に答えられない。
逆に、同じ時間で、するすると本質へ迫っていく人もいる。
両者を分けているのは、個別のスキルの差ではなさそうだ。
仮説を立てる力でも、実装力でも、段取りの良さでもない。
その手前で、たった一つの問いを、いつも自分に向けているかどうかの差だ。
良い仮説の定義を更新する
反証可能性を超えて
まず、その問いの手前にある「良い仮説とは何か」から入る。
仮説の形式的な条件として、まず反証可能性がある。
ポパー的な定義で、科学哲学の基本中の基本だ。
だが、それを一段超える定義がある。
良い仮説とは、間違っていたときに最も多くのことを教えてくれるものだ。
正しくても確認にしかならない仮説より、外れたときに世界の見え方が変わる仮説のほうが価値がある。
結果がどちらに転んでも、学びが残る。
それが、良い仮説の手ざわりだ。
もう一つ、条件がある。
現実との接点だ。
頭の中だけで閉じず、観察や実験で検証に近づけられること。
この二つが揃って初めて、仮説は前進の起点になる。
自分の前提を疑う
とはいえ、「間違っていたときに多くを教える仮説」を立てるのは難しい。
自分が思ってもいないことを、わざわざ狙わないといけないからだ。
未知の領域を直接狙うのは、ほとんど無理がある。
そこで、手が届く別ルートを取る。
自分が「当然こうだろう」と思っていることの中で、いちばん根拠の薄いものを疑う。
人は信念の中に、検証済みのものと、なんとなく前提にしているものを、混ぜて持っている。
後者を見つけて、そこを突く。
実用的な問いは、こうなる。
もしこの前提が間違っていたら、自分の計画のどこが壊れるか？
ここで真っ先に壊れるものが、検証すべき第一候補になる。
重要なのは不確実性の優先順位づけ
仮説を立てる力、問題解決力、目的志向、タスク管理、コミュニケーション。
個別のスキルはいくらでも挙がる。
だが、それらの上に立つ、もっと根っこの能力がある。
何を明らかにしたら次に進めるかを見極める力、つまり不確実性の優先順位づけだ。
どれだけ仮説が優れていても、今解くべき不確実性に向いていなければ、空振りに終わる。
PoCで「技術的に可能か」を確かめるべきタイミングで「ユーザーに受け入れられるか」を検証しても、進捗にはならない。
個別スキルは、この一つの能力が、場面ごとに違う顔で表れたものだと見ることができる。
Unknown-UnknownとKnown-Unknownの並行処理
不確実性は、ラムズフェルドのマトリクスで整理できる。
- Unknown-Unknown → Known-Unknown：発見・探索
- Known-Unknown → Known-Known：検証・実行
研究やPoCでは、この二つを並行して回す必要がある。
そして、使う思考のモードが違う。
切り替えること自体に、コストがかかる。
Unknown-Unknownの発見は、一見「メタ思考の能力」に見える。
だが、半分は環境と仕組みの問題だ。
経験豊富な人がUnknown-Unknownを見つけやすいのは、メタ認知が優れているからだけではない。
「前提が崩れた経験」のストックが多く、それがパターン認識として働くからだ。
だとすれば、ジュニアに「メタ思考を鍛えろ」と言うより、チームの仕組みで支えるほうが効く。
一人で閉じない
Unknown-Unknownの発見を、個人の才能に帰さないと決めると、面白い構造が見えてくる。
個人、チーム、チーム外と、視点の範囲を広げるほど、見落としは減る。
ただし、無限に広げればいいわけではない。
広げるほど、ノイズと合意形成のコストも増える。
では、どこまで開くか。
その判断基準も、結局「今どの不確実性が最もクリティカルか」に戻ってくる。
- 技術的リスクが最大なら、技術に強い外部の視点を入れる
- 市場の前提が怪しいなら、ユーザーや事業側の視点を入れる
良い仮説を一人で立てにくいのと、Unknown-Unknownを一人で見つけにくいのは、同じ理由だ。
どちらも、自分の認知の外側にある。
だから、研究やPoCで効いてくる能力の一つは、自分の認知の限界を自覚したうえで、他者の視点を引き込む力になる。
たった一つの問いに集約する
ここまでを一本につなぐと、良い仮説を立てるとは、実は一つのプロセス全体を指していたことが分かる。
今最も危うい前提を特定し、それを検証可能な形にし、適切な視点を借りて検証する。
仮説単体の品質より、この一連の動き方の質が、研究やPoCの成否を分けている。
そして、この長いプロセスを、日常的に駆動する短い問いがある。
冒頭で伏せておいた、たった一つの問いだ。
それをやると、何がわかるの？
タスクに着手する前に、毎回これを問う。
答えられないなら、目的が不明確だと本人にも見える。
「動くかどうかがわかります」と返ってきたら、「動くとわかったら、次に何が言えるの？」と重ねる。
責める調子ではなく、純粋な好奇心として聞ける形をしているのがいい。
問いが回り続ける仕組みを残す
ただし、この問いには弱点がある。
問いかける人がいるあいだしか、機能しない。
問いかけ、返答の甘さに気づき、さらに掘る。
この対話のサイクルは、問いかける側の能力に丸ごと依存している。
だから、問いを伝えるだけでは足りない。
問いが回り続ける仕組みまで、設計する必要がある。
たとえば、タスク着手前に「このタスクで検証したいこと」「それが確認できたら次に何が言えるか」を一行ずつ書くルールを残す。
フォーマットが問いかけの代わりになり、問いが個人から仕組みへ移る。
不確実性の優先順位づけは、個人のメタ認知に頼るほど、その人が抜けた瞬間に止まる。
仕組みに埋め込んだぶんだけ、問いは残る。
次に自分が新しいタスクに手をかけるとき、まず一度だけ、声に出さずにこう聞いてみるといい。
それをやると、何がわかるのか、と。