以前、仮説キャンバスについて紹介をしました。今回はこの仮説キャンバスをどのようにしてチームで扱っていくのかについて解説します。
まず、おさらいとなりますが、仮説キャンバスはプロダクト作りを構想するにあたって軸となる存在です。仮説キャンバスでプロダクトに関する仮説を立て、検証の方針を決め実施し、結果を得る。その結果でもって、プロダクトバックログを導き出す流れです。仮説キャンバスの「提案価値」「実現手段」がプロダクトバックログの元ネタになります。
まず仮説の見える化
さて、チームで仮説とどう向き合っていくかですが、まずもって「見える化」がその第一歩となります。仮説検証を引っ張っていくのは役割上プロダクトオーナーが務める場合が多いものです。プロダクトの仮説が今どうなっているのか。プロダクトオーナーの頭の中にしかない、という状態がたいていの場合の出発点でしょう。
もしくは、仮説を立てるということ自体が行われていないことも珍しいことではありません。この場合は見える化しようにも対象となるものが存在しないため、仮説を立てるところからになります。
また、プロダクトオーナーの頭の中にあるといっても、内容が漠然としていて、雰囲気で捉えているということもまた、よくあることです。仮説の言語化、そしてイメージ化を進める必要があります。仮説キャンバスは特にこの言語化を担う道具になります。
頭の中で雰囲気で捉えていることを具体的な言葉に置き換えていく。その過程で、捉え方の解像度が高まり、仮説はより精緻になっていきます。言語化しようとするだけで、仮説が磨かれるわけです。
ただ、この言語化を漫然と行っただけでは仮説を形作るための観点が不足し、十分な磨き込みにならない可能性があります。仮説キャンバスは、その観点を提示するガイド役になります。14個のエリアはそれぞれ「問い」になっています。14の問いを通じて、初期段階の仮説を形作れるようにするのが狙いです。
「問い」によってはまだ十分に答えきれないものもあるでしょう。初期段階からすべての問いに理路整然と答えられなければならないわけではありません。そうした答えられない問いに答えれるようにする。新たな理解を得られるようにする、そのための活動が仮説検証です。
仮説キャンバスを通じて仮説作りを行うと、当然そのアウトプットが残ることになります。このアウトプットをチームで共有し、いつでも見れるようにすることでプロダクトへの理解をチーム全体で高める。これがキャンバスを用いるもう一つの狙いです。
こうした仮説の見える化が行われないとどうなるでしょうか。チームの理解は不足し、意図しないプロダクトを作り上げてしまう可能性が高くなります。このチームで何のために何を作るのか、この理解を揃えることが、プロダクト作りの入り口です。仮説キャンバスによる仮説の見える化はその一歩と言えます。
仮説をみんなで考えて、一つに絞る
仮説の見える化の段階から次へ進みましょう。それは、仮説をチームで考えて、合意形成するということです。
いくら仮説が見える化できたとしても、その中身がプロダクトオーナーただ一人が考えたものだとしたら、チームの力を十分に引き出せているとは言えません。一人で考えた仮説は、その人の持っている経験や知識を前提としたものにしかなりません。プロダクトオーナーが仮説立案に最も影響を及ぼすのは違いありませんが、チームにある多様な経験や知識も活用し、より仮説の幅を広げたり、深みを作っていくことを考えましょう。それがチーム開発の意義です。
具体的には、仮説キャンバスをプロダクトオーナーだけで作るのではなく、チーム全員で作るようにしましょう。もちろん、プロダクトの狙いや、対象としている利用者に関する理解・知識には、チーム内でばらつきがあるでしょう。プロダクトオーナーが仮説作りのたたき台として、キャンバスをある程度埋めておくのも一案です。あるいは、プロダクトとして中核となるコンセプトの仮説がすでにある場合も、あらかじめキャンバスの上に表現しておくと良いでしょう。
また、チームで仮説キャンバスを作っていくとはいえ、すべての意見を拾い上げて、くまなくキャンバス上に表現していくことが望ましいわけではありません。ノイズになってしまう情報の方が多いでしょう。ですから、広く意見は出すものの、仮説キャンバス上に何を残していくかについての基準を設け、それに合致するものに絞っていきましょう。
ここでいう基準は2つです。
1.「事実」といえるもの
すでに既知の事実として捉えられることであれば仮説キャンバスに残すようにする（もちろん、プロダクトに影響を与える可能性があるものが対象です）。
2.「事実かは分からないが仮定としておけるもの」
「Aという状況に置かれている人たちのBという課題を手段Cによって解決し、結果Dの状態にする」というコンセプトについて、プロダクト作りを進めるにあたってはABCDが事実としての確からしさを高めた上で開発に臨みたいわけです。ですが、実際にはABCDがすべて事実であると事前に明らかにするのは困難だったり、作って試してみないと分からないものもあります。
ですから、仮説キャンバスを作る段階では、例えば「Bという課題が本当に存在するかどうか分からないけども、このコンセプトを成り立たせるためには必要」という仮定を置いて、構想を進めるわけです。こうした仮定が妄想レベルもあれば、ある程度の根拠を踏まえたレベルもありと、幅があります。
いずれにしても仮説検証によって事実かどうかの確からしさを高めにいきます。もちろん、仮定として置いている内容が多ければ多いほど、仮説としては不安定で、試行錯誤の度合いは高まるでしょう。そうした不安定さを補うために、チームの多様な経験、知識を引き出しように仮説作りを行うわけです。
仮説をみんなで考えて、それぞれも仮説を持つ
チームの仮説作りには、さらに先があります。仮説キャンバスを使って、チームが概ね合意できる仮説を見出すと、追いかける仮説が一つとなって目標が明確になり、チーム活動が進めやすくなります。
その反面、仮説に幅が持たせにくくなってしまいます。チームによる合意形成というセレモニーを経ると、「これがチームの仮説」=「これ以外はノイズ、余計なもの」という見方が暗黙的に高まる場合がほとんどです。
それはそうなるでしょう、皆で理解を合わせたいために、一つのキャンバスを作っているのですから。仮説キャンバスを作ったそばから、内容と真逆の開発や検証を誰かが始めたら「何やっているの？」という話になりますよね。ここが、一つの仮説キャンバスで合意形成することの課題です。
同じ検証結果をみても、個々人によって解釈が異なることがあります。先述したように、個々の経験や知識の違いから理解の仕方に差が生じるのです。解釈を唯一つに抑圧するのではなく、むしろ幅が広がるようにする。そうして、プロダクトとしての当たりが引けるようにその可能性を高めるのです。これが、重奏型の仮説検証の考え方です。
もちろん、チームとして一つ合意したものを置かなければその後の活動がやりにくくなります。ですから、チームとして一つの仮説キャンバスを置きながら、個々人でも自分自身の仮説キャンバスを持つようにして、ときにチームの仮説キャンバスをアップデートする機会を設けるようにします。
多くの場合、プロダクトの仮説検証は繰り返し実施されていますから、1回の検証を終える度に、個々人が持つ仮説をチームの仮説キャンバスにぶつけるようにすると良いでしょう。
チームとして一つの合意形成を得ながら、個々人は個々人の意見を育むようにする。これをばらばらのままの合意形成と呼んでいます。チームの多様性を活かすプロダクト作りに挑戦していきましょう。
