  |
仕事柄、UXとかデータ分析とか、その辺が少し強いと思われているらしい。
職場の人からその辺の勉強の仕方を聞かれたので答えようとしたら、意外と長くなりそうだったのでメモがわりに書く。
そもそも、UXという言葉が流行りだしたのは最近の話だと理解していて、バズワードに近いと思っている。概念自体は遥か昔からあるものだし、何を今更世の中がUXというワードを使いたがっているのかが良くわからない。（が、ここでは面倒くさいので、定義が曖昧なUXという言葉で色々お茶を濁す）
また、UXを勉強するという言葉も、正直なところ違和感がある。
というのも、具体的なケースと紐づいて考えない限りは意味がない気がするからだ。文章の批評ばかりしていても小説家になれないのと一緒で、UXについて本や講義だけで勉強していても、UXに強くなることはないと思っている。つまり、自分たちが作っている（関わっている）サービスの中でUXを考えつくすこと自体が、一番の勉強なんじゃないかと思っているので、UXを本や何かで勉強するというのは効果は薄いんじゃないかと思っている。
とはいえ、体系化出来るメタスキル的なものがあるのは事実だし、その部分の話を書いてみる。
「UXを良くしたい」という話をよく相談されるのだが、そもそもとして、UXが良くなった後の世界をちゃんと考えられていないことが多い。
「そのサービスを使ってユーザは幸せになるの？」という問いにきちんと答えられない場合、黄色信号という印象。
UXUXってバカみたいに唱えている人はたくさんいるけど、自分たちのサービスのUXが良くなることでこんな世界が実現できるよっていう話を、具体的に、鮮明に、誰が聞いても腹落ちする形で話せる人ってどれだけいるのかな。UXを良くしたいと言っているのに、良くした後の先の世界がイメージできていなくて、どうやって良くしていくのか甚だ疑問なんだよね。
なので、UXを考えるにあたっては、「自分たちがどうしても叶えたい世界」があって、それが叶うことによって「世の中の誰かがすごく幸せになる」という確信が必要条件だと思ってる。なので、そこがない時点でUX改善どころかサービスを作ること自体をやめた方がいい。
もし、そんな感じの祈りにも似た思いが少しでもある場合は、自分たちが作りたい世界についてしっかりと考えて、そしてそれらを検証して確信に変え、具体的な言葉に落とし込むというプロセスを徹底的に行うことを、UX改善の前に行なった方が良い。そうやって生み出された言葉が、UXを考えるにあたっての拠り所になる部分になっていくから。
自分たちが作りたい世界を言語化できた後は、ユーザの観察と妄想に尽きる。
課題解決系のサービスなら、ユーザに当たる人が本当に困っているのか、何に困っているのかを見極めるために観察すべきだし、何らかのバリューを付加するサービスなら、「このサービスを使ってもらうことで幸せになるのかという妄想」をいかに具体的にできるかが鍵になる。
これらの観察および、具体的な妄想をしていくこと自体がUXを考えることである。
炊飯器が目に入ったので炊飯器のUXを考えるとした時の例で話す。
多分、こんな妄想をする。
炊飯器とか既に他の製品が存在するものは、ユーザの行動もだいたい想像できるし、何より自分が使うものだから妄想しやすい。
逆に、全く新しいものを作ろうとする時なんかは、妄想も中々大変だと思う。バイアウトして話題のCASHとかは、その辺りの参考になるものが中々なく、妄想もやり辛かったと思うので、それを形にできたUXデザイナーの人はすごいなと思う。会ってみたい。
これはかなり適当に書いたが、自分たちが行なった観察に基づく妄想に対して、それらが意味のあるものかどうかを見極めていく必要がある。これがいわゆる価値仮説の検証と呼ばれるもので、妄想が本当に必要とされるものなのかを見極めるフェーズである。必要とされないものなんて作っても意味がないから、この段階できちんと仮説の検証をしておく。検証については対象によって全く異なるため、都度考える必要があるので割愛。
例はかなり適当に書いたが、ユーザをしっかり観察して、その上でどうやったら幸せになるかを妄想して、それらを検証していくというフェーズを、手抜きせず行うことが大事だ。これが業務系のサービスだと、業務フローを作ったりするのだろうし、C向けサービスだとカスタマージャーニーなんかを作ったりすることになる。その辺りの手法は色々あるが、ユーザを見て、考えて、検証してという基本はどれも変わらない。
ユーザをひたすら観察したあとに、初めて解決策を考えるフェーズに移る。
解決策ありきのプロダクトだと（昔の技術先行型の日本の家電だけど）、あまりいい感じにはならない。
あくまでも、ユーザの観察が先にあって、それに対する「解」としてプロダクトを作っていく。
この、課題に対して適切な解を出していくこと自体が、UXの磨き込みに当たるという理解をしている。
そして、それらが部分最適にならないよう、全体最適も意識しながら解決策を考え、プロダクトに落とし込んでいく。
「ご飯は1分で炊けるけど、風呂釜より大きい炊飯器」とか、誰も必要としないよね。だけど、部分最適だけを考えるとそんなことになりがちである。そのためにも、部分を考えたら、全体を見るということを繰り返し行なっていくことが大切だと感じている。その意味では、捨てるべき部分と、活かすべき部分のバランスをどう取るかが大切になる。ここも結局ユーザが教えてくれるので、事前にしっかり観察できていれば、勝手に答えが出る。
長々と書いたが、自分たちが作るサービスを使ってくれる人たちが、「どうやったら素敵な感じになるかを考え尽くすこと」が最高の勉強方法だと思っている。なので頑張って考えると良いと思う。
とはいえ、何を考えればいいかわからないということもありそうなので、その時は
・誰のためのデザイン
・複雑さと共に暮らす
・融けるデザイン
あたりを読んでみるのは良いかもしれない。少なくとも、何かを考えるにあたっての視野は広がるような気がする。
また、解決策を生み出していくにあたっては、ロジカルシンキングが出来るに越したことはないので、
あたりを読んで見るのも良いかもしれない。後者は分類的にはロジカルシンキングの本ではないのだが、ロジカルに考えた時の解決策って一つだけじゃないよねということを身を以て知るためには良い本だと思う。
また、散々書いたが、UX云々の前に、自分たちが作っているサービス（だったり、炊飯器だったり椅子だったり）で「何を届けたいか」という部分が一番大事だと思う。それ抜きにはUXがどうとか議論するのは無駄というか、意味がないので、しっかり考え抜いてほしい。
データ分析というと、Pythonでごにょごにょやるのがそれだと思われがちだが、一部のデータサイエンティストを除いては、基本的にスプレッドシートで十分なんじゃないかと思っている。むしろ、電卓レベルでも足りるんじゃないかという気がしている。（ここで話しているのは一般的なインターネットサービスを運営していくときの話で、気象予報とか経済予測とかそんな感じの難しいデータ分析の話ではない）
というのも、多くの場合において、四則演算以上のことをしなくてもなんとかなるからだ。
どちらかといえば
といったことの方が大事だし、そもそも「何のために分析するか」が抜け落ちていることが多い。
whyの部分が明確でない分析はそもそも意味がないので、まずはなぜ分析するのかを考えるところから始める方が良い。
データ分析ときいて「統計学」や「Python」を勉強すること自体は悪くないのだが、それよりもまず先に、「なぜ分析するのか」「どんなデータが自分たちのサービスのキモになるのか」といった分析の前提になる部分をまずはしっかり見極めることの方が、統計学の勉強よりも優先されるべきだ。それらがハッキリすれば、手法はいくらでもあるし、だいたいはスプレッドシートの関数でなんとかなるので、難しい計算は特に必要ない。
実務でよく使うデータなんて、売上、利益、利益率、ARPU、CPA、CTR、CV、CVRとかくらいだし、これら全て四則演算のみで出せる。分析といっても、平均だったりそれらをユーザの属性で割り振ったりするだけだし、中学生でも問題なく出来ると思う。ただ、重ね重ねになるが、whyの部分がない場合はいくら分析しても何も生まないので、まずはそこを見極めることに重点をおいた方が良い。
長くなったので無理やりまとめる。
勉強＜＜＜＜＜実務であることは間違いないので、まずは自分が関わっているサービスについて真剣に考えたり、真剣に考える上で必要な数字が何かを自分の頭で考えることが、最高の勉強だと思う。教材とか、具体的なHowを期待していた人、ごめんなさい。でも、Howの意味で見ても、実践に勝るものはないと思っている。
長い産業で
12
