プロダクトやチームについて仮説を立てるように、進め方自体の仮説 （探索仮説） も立てよう

　課題仮説、ソリューション仮説だと言う前に、現場や組織には「仕事の進め方自体の仮説」が必要なのではないかと思うようになっている。

　　その行為を「作戦」と称し、その手がかりとなるアウトプットを「仕事の設計図」「線表」と呼んで、実践指導にあたっている。もう少しスマートに呼ぶなら、やはり中身は「計画」ではなく「仮説」であるから、「探索仮説」とでも呼ぶことにしたい。

　探索仮説は、WBSでもスケジュールでもロードマップでもない。向かいたい場所、状態に辿り着くための道筋を組み立てたものだ。立てた計画の通りになるように現実を正す、というメンタリティではない。手がかりの少ない状況の下を手探りで進めていく中、ほのかに分かってくることで進め方のプラン自体を機動的に変えていく。プロダクトやチームについて仮説を立てるように、進め方自体の仮説も立てよう。

　そして仮説を立てるならば、当然に検証でもって次の判断を磨いていこう。大事なのは、「思い出したら進め方を見直そう」ではなく、見直す機会を先に約束しておくことだ。そこまで進めてきた道程から学びを得るために「ふりかえり」を、そこから先に目をやったときに向かうべき先を捉え直す「むきなおり」を一定の間隔で実行することを決めておく。こうして「機動的に変わる」という可能性を予定しておく。

　探索仮説が無いと何が起こるのだろうか。

・どこへ向かいたいのか、どこにたどり着きたいのかがあいまいで、当面の仕事としてやるべきこと、必要なことが見出だせない。

・「とりあえず手当り次第に」が動き方となり、やってみた結果を測るための物差しがなく、学びが得られにくい。

・個々人で思い描く範囲が広くなり、「ひとまず向かいたい先」「そこに至るための算段」がバラバラになりがちとなる。

・あいまいで、気持ちの悪い状態が続くことになる。チームメンバーによってはその状態が受け入れ難く、ストレスを抱えることになる。

　分からないことが多いからこそ、お互いに分かりあっていることがまだ少ないからこそ、仮説を置き、その中身を分かるようにしておくのだ。分からないことが多い状況下だからこそ、ともに仕事にとりかかる相手のこと、考え方やスタンスを知っておきたいし、使う道具や技術についてはその全てを不慣れなものでやっていくのではなく得意がいきるようにもしたい。不用意に、多くの分からないもので組み立てて勝てるほど、容易な仕事に私達は挑んでいない。

　ところが、この「仕事自体を組み立てる行為」は様々な観点から落とされやすい。「アジャイルではスケジュールは引かない」として、スケジュールとともに落とされ、「プロセスばかり考えても仕方ない、とにかく手を動かそう」として、始末される。チームビルディングも、技術検証・選定もよく課題になることだが、輪をかけて手つかずになっていることが多い。
　探索仮説はスケジュールではないし、いきなり強固な「型」にはめようとするものでもない。チーム、組織の動きを支えるための最小限の「方」だ。

　探索仮説を立て始めるにあたって、それほど難しい問いかけは要らない。第一声は「どうやってやってく？」だ。パワポでも、miroでも何でもいいから白いキャンバスをみんなで開いて、どこへ向かってみたいのか、から確かめる、あるいは思い出すことからを始めよう。そこへ向かうための「方」を考える際こそ、みんなの知見を寄せ合いたい。