ベイジのプロジェクトのフローの中には、デザイナーが主に担当する「設計」や「デザイン」フェーズの前に「戦略」フェーズというものが存在する。
業務システム関連の案件の場合はその戦略フェーズに段階で「ユーザビリティ評価」や「ユーザーインタビュー」「ユーザーテスト」などといったUXリサーチのフローが含まれている。
今までこれらはコンサルタントやディレクターといった、主に戦略工程を担当するメンバーが行うことが多かったのだが、リサーチの結果や、リサーチの中で見えてきた課題などをデザイナーも把握しておくことで、より設計フェーズや、デザインフェーズにおいて納得感を持った改善が行えるということで、デザイナーがリサーチ工程に関わる機会も増えてきている。
私自身、ディレクターさんからリサーチ結果を共有してもらうだけではなく、直接顧客の話を聞いたり、チーム内で課題について話し合ったする過程を経た方がプロジェクトに対するう解像度の上がり幅がかなり異なるということは身をもって経験したことがあるので、徐々にではあるがリサーチ工程にも参加し、いずれはサポートではなく、自分主導でリサーチ工程を担当してみたいという望みもあった。
「でもリサーチって最近よく聞く言葉ではあるけど何をするの？」
「そもそも、どんな効果が求められているの？」
これがリサーチ工程の一部に初めて参加させてもらっていた頃の、私自身のリサーチに対する理解度だ。
今でこそ、もう少し理解度は上がっているとは思うが、まだまだ初心者から抜け出せていない、といったレベル感なので、そんな中で初めてリサーチに関する勉強として手に取った『デザインリサーチの教科書』はレベル感としてもとても最適だったと感じている。
具体的なリサーチの手順はもちろんのことその前提となる「なぜ？リサーチなの？」という疑問に関してもかなりページ数を割いて、「なぜ？」に向き合った説明がされている。
私はこれを読んだことにより、だいぶリサーチ工程で求められていることに関して理解が深まったと感じた。
また本書の主題である、具体的なリサーチ手順の説明の項目でもかなり参考になることが多く、個人的になるほど！と感じたのは「チームビルディング」と「調査」のセクションだ。
「チームビルディング」は一見するとリサーチ工程には関係ないのでは？と感じるのだが、いざ読み進めていくと、チーム前提でプロジェクトに対して同じ認識を持つことの重要性がとても理解できる。
案外、同じプロジェクトに携わるメンバーであっても、担当するフェーズが異なる場合、プロジェクトの課題に対する認識が異なる場合が多く、その認識が異なるために、対応方針が固まらず、終盤になって改めて議論する、といったような事態になったこともあるので、チーム内で同じ方向を向き、プロジェクトで求められていることや課題感を理解し、プロジェクトの成功をあらためて定義し直す機会を設けるというのは、かなり重要なことだと感じた。
「調査」はその見出しの通り、リサーチ工程の中でのユーザーインタビューやアークショップなどの具体的な手法に関する説明がされているセクションなのだが、顧客やユーザー自身がうまく言葉にできないような潜在的なニーズを引き出し理解するためにはどうすれば良いのか？という観点での説明もあり、それが現状自分が一番課題に感じているユーザーや顧客から要望をヒアリングするにはどうすれば良いのか？という点の課題解決に紐づけることができたので、より印象に残っている。
インタビューなどの会話の中で引き出せるようにするスキルも必要だとは思うが、リサーチの場合はその手法だけに固執せず、「カスタマージャーニーマップ」や「ユーザーテスト」などといったリサーチツールもうまく活用し、それらを組み合わせることで、情報を引き出していくことを目指すのが良いのだと知ることができた。
またこれは完全に余談だが、リサーチツールに関しても、「カスタマージャーニーマップ」や「ユーザーテスト」はもともと知っていた手法ではあるが、それ以外にもたくさんのリサーチツールが紹介されていたので、機会があれば、普段ベイジでは行っていない手法の方も取り入れることができるのであれば、試してみるのも面白そうだと感じた。
本書はかなりボリュームも厚く、前提の「なぜ」という疑問から向き合って解説してくれている、リサーチ初心者が初めて手に取るにはとてもちょうど良いレベル感の書籍だった。
この本で基礎を身につけ、そこからでは自分ならどうやってリサーチを実践していくのかを考え試行錯誤していくのが、リサーチ工程をできるようになるうえでの近道なのかなと感じている。
