推敲的UX改善と価値の仮説検証を分ける

　制作していた書籍が完成した。

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

ざらざらをつるつるにする「推敲」

　人にも依るのだろうけども、執筆行為でかけている時間のうち、約半分かそれ以上を推敲の方に費やしている。推敲とは、自分が伝えたい内容になっているか、その表現が読み手に伝わるかを見直し、文章を整えることである。

　それまでは自分の頭の中にあるものを吐き出すのに必死だったわけだが、この段階では自分以外の人物（想定読者）もあらわれ、制作に関与することになる。読み手としての自分自身による推敲とは別に、自分とは異なる視点を持ち込み、読みの体験が成り立つかを検証する。

　やり方は2通りある。一つは、自分自身に想定読者を宿すこと。ゆえに想定読者として置いている人物が何を思い、何に悩むかを知り、それでもってどのような読み方をするか自分自身を使って再現できなければならない。

　もう一つは、想定読者に実際に読んでもらうことだ。いわゆるレビューと呼ばれる。直接的なフィードバックを受けて、推敲のための「問い」にする。そう、フィードバックは「答え」ではない。

　例えば「XYZの意味がよくわからない」という指摘は、「なぜXYZと書いているのか？（XYZで何を伝えたかったのか？）」「それがなぜXYZでは伝わらないのか」という「問い」に仕立て直し、あらためてその問い答えるようにする。そうしなければ、文章は場当たり的な修正が至るところに入り、いびつなものになっていくだろう。

　こうした行為を通じて、最初は独りよがりで人の読みに適していなかった状態から、視線をすべらすのにつんのめるのような違和感が無い状態へと変えていくことができる。こうした状態変化に挑む姿勢を「ざらざらをつるつるにする」と呼んでいる。

　という推敲の捉え方が、UXの改善にも通じる。

推敲的UX改善

　何らかのプロダクトを作っているとして、最初は作り手たちの頭の中にあるものを、かたちにするので必死だ。一通り、想定していた感じで動くようになって、利用の体験が成り立つかどうか、利用の開始時点からプロダクトを検証する。

　やり方は２通りある。一つは、自分自身に想定ユーザーを宿すこと。ゆえに想定ユーザーとして置いている人物が何を思い、何に悩むかを知り、それでもってどのような使い方、捉え方をするか自分自身を使って再現できなければならない。

　もう一つは、想定ユーザーに実際に使ってもらうことだ。いわゆるユーザーテストと呼ばれる。直接的なフィードバックを受けて、改善のための「問い」にする。そう、フィードバックは「答え」ではない。

　こうした行為を通じて、利用体験も「ざらざらをつるつるにする」ように磨いていく。意図的な視点の置き換え（想定ユーザーを自分に宿す）と、ユーザーテストを併用し、プロダクトに問いを何度もぶつける。

　このとき、利用体験の改善と、価値の仮説検証は混ぜ込まないほうが良い。

推敲的UX改善と価値の仮説検証を分ける

　仮説には、3つの構造がある。もっとも根源的な仮説は、「課題」の仮説だ。ある課題があるからこそ、その解決のための「機能」が必要になる。そして、機能を使いこなし役立たせるために、利用者に適した「形態」が問われることになる。

　「このプロダクトは利用者にとって価値があるのか？」という問いは課題仮説の検証のために用いられるものだ。そもそも我々の企てには価値があるのかを突き詰めるための検証は、他の検証よりも先に行う必要がある。

　一方、利用体験の改善とは「このプロダクトを手にとり活用してもらうためにはどうあるべきなのか？」という形態仮説についての問いに向き合う行為と言える。

　この2つの問いに同時に答えようとすると、後者の改善の手をゆるめる可能性がある。形態仮説は、「このプロダクトには価値がある（はずだ）」という前提の上に成り立っている。根幹を揺るがしながら、それを表現するものを精妙に修正していこうというのは、ムリがある。利用体験の改善はかなり細かい仕事になるので、振り切って臨む必要がある。そうでなければ、改善は中途半端になってしまう。

　結果的に、プロダクトは想定ユーザーに届かず、価値があるのかないのか？　利用体験に問題があるのかないのか？　という判断がつかず、プロダクト作りを誤ってしまう。

　ゆえに、価値の仮説検証と、利用体験の改善は分けて行うようにしたい。観点は2つだ。一つは、時期を分けること。価値の仮説検証を先行させて、一定の評価が出来たあとに、利用体験の磨き込みを行うようにする。その後、再び価値は問われることになるだろう。その往復を繰り返していくのがプロダクト作りと言える。

　もう一つは、役割を分けること。検証をリードする役割と、改善をリードする役割を、一人の人間に同居させるのは相当難しい。ゆえに、チーム内で主として、その役割を負うものを分けるようにする。その上で、両者間で協働することになるが、プロダクトの方向性についての意思決定が難しくなる可能性が引き続きある。時期的な分割を含めて、プロダクト作りに挑みたい。