最初は一人、あるいは少数名で考えてきたプロダクトについて、いよいよ開発チームも巻き込んで開発を進めていく。そのような局面の前後に立ち会ってみると、開発の立ち上がりが上手くいっていないということが少なくありません。
チームやプロジェクトの立ち上げ特有の難しさというのは、今に始まったことではありません。むしろ、ずいぶん昔から、課題として捉えられてきている事案です。今回はこの、プロダクト作りで必ず直面する「最初の立ち上がり」をテーマにします。
なぜ立ち上がりが上手くいかないのか
では、なぜ立ち上げが上手くいかないのか、から考えてみましょう。さっそく結論から述べると「作るべきものの意図への理解が十分ではない」という点が挙げられます。なぜ、このプロダクトを作るのか、なぜこれらの機能性を最初に作らなければならないのか、その狙いは何なのか。こうした「意図」が十分に開発チームに伝わらないまま雰囲気で作り始めてしまう、その結果意図したプロダクトに仕上がっていかない。あるいは、そもそも作り始めるまでの違和感が払拭できず、なかなか開発のスタートを切れないといった問題に直面することになるわけです。
ゼロから時間をかけて構想を練ってきた人たちからすると「意図」は自明です。長く検討してきただけに多くのことが本人たちにとっては自明であり、それだけ「どういう内容をどのくらいの時間をかけて伝えなければならないのか」が分からなくなっていると言えます。プロダクトの企画者(あるいはプロダクトオーナー)と、開発チームの間には情報の非対称性がある、そのことに双方が気付けないまま、物事を進めようとする。立ち上げの問題の本質はここにあります。
そんなことは分かっている、だからこそ時間をかけて意図を伝えている、そんなプロダクトオーナーも少なくないでしょう。「ドキュメントに書いておいたので、読んでおいて」では、開発チームには伝わりづらい。だからこそ、キックオフミーティングを開いて、1、2時間かけて説明をしている。そこに十分な時間を割いている…にも関わらず、理解のズレが起きてしまう。
そう、「ドキュメントに書いてるから読んでおいて」は問題外として、真面目にプロダクト作りに向き合っている人ほど、きちんと「説明」を行っているのですよね。なんなら開発チーム側も同じ認識で、「説明」を受けていることには合意している。それにも関わらず、必要な理解がチームに行き渡らない。つまり、問題は説明の有りなしだけではない、ということなのです。
全員で理解を「つくる」
もう少し解像度を上げて捉えてみましょう。「知る」と「理解する」が別物であるという前提に立つ必要があります。「説明する」ことで相手は「知る」ことができるかもしれません。ですが、それは内容を把握しただけで、理解までできたかどうかはまだ言えないのです。では、理解とは何でしょうか。
理解とは、「判断できる」ということです。もちろん、各々の勝手な判断ではなく、本来の(意図として置いている)「目的」に基づいて判断ができるということです。さらに言うと、目的自体を「説明」し、相手が「知る」ことはできますが、それだけではズレる可能性があります。判断には「解釈」が伴います。
つまり、目的をどのように解釈し、そのための優先基準をどう解釈するかまで整える必要があるということなのです。解釈まで合わせる、この段階には「説明」だけでは到達できないことが多いと言えます。相手がどう受け止めたかが、他人からは分かりにくいからですね。
では、目的に適した「解釈まで合わせる」にはどうすれば良いのでしょうか。それは、全員で理解を「つくる」ことです。
つまり、あらかじめ定義されたもの、言葉になっているものをただ一方的に伝えるのではなく、そうしたものの「説明」を踏まえて、あらためて自分たちで「理解」を言語化し直し、その内容によって「解釈」があっているかを確認し合うということです。
言語化を行うにあたっては、「インセプションデッキ」などのワークを活用すると良いでしょう。プロダクトオーナーが作成してきた「インセプションデッキ」をただ眺めるだけでは、ここまで示してきた問題が解消できないのは明らかですね。こうしたワークを通じて、その言語化の過程で「理解」を示しあって、「解釈」の一致感を確認し合うことが狙いとなるわけです。
インセプションデッキの内容については、解説書籍として本家にあたる「アジャイルサムライ」や、その他副読本として「カイゼン・ジャーニー」などをあたってください。
インセプションデッキのワークを通じて、言語化されたアウトプット自体が理解を確認する対象であり、時を経て後で、確認しあった内容を思い出すためにも、理解の断片を残しておくことには価値があります。
しかし、こうしたワークの真骨頂とはその過程にこそあります。対話の中で理解のズレや違和感を検知し、すぐにフィードバックを示し合い、さらに対話を重ねる。密度の高い対話によって、一気に理解の度合いを揃えていくところに最も価値があります。
こうしたあらためての言語化を行うと本来、プロダクトオーナーが考えてきた狙いがズレてしまう恐れはないのかと思われる方もいるかもしれません。プロダクトオーナーが定めてきた内容を無理にアップデートしようとすると、確かにそうした恐れはあります。ですから、もともとの内容を更新するのではなく、あらためてチームで言葉を作り出すほうが良い場合もあります。チームでアウトプットしてみて、もとの内容と比べてみて、かけ離れた内容になっていないか、あるいはもとの内容にはなかった新たな発見はないか、そうした確認が行えると良いでしょう。もちろん、プロダクトオーナーとして言語化した内容にそもそも自信がまだ持てていないような段階であれば、チームでアップデートしていきましょう。
チームによる言語化、その過程での確認を通じて、プロダクトの目的について違和感であったり、プロダクトオーナーでも判断できないことが新たに分かったりすることもあります。作ってから方向性の誤りに気づくよりも、こうした対話に時間を割いたほうが、より早く、より労力をかけずに修整が効きます。対話の時間を惜しむことなく、チームでお互いの「理解」に向き合うようにしましょう。
