こんにちは、さおり(@iropon30)です。
この記事では、私が受講している実際のプロダクトで学ぶB2B UIデザイン [Uzabase B2B SaaS Business CDO]×[1on1] を通して学んだことや感じたことなどをまとめていけたらなと思います。
今回3回目の1on1です。受身の姿勢、ダメだ！と意識して臨んだ3回目。結果とっても楽しかった。自分の学びの成功体験になったような回でした。（そして次はまた落ちます（笑）。 お楽しみに！）
前回の1on1はこちら
途中であった交流会とインタビュー前のうちあわせはこちら
ちなみに、今回からDiscordに振り返りを残すようになり、ブログを書くのがはかどります。熱々の時に感想や思ったことを残すのは大事だなという気づきも大切にしたいです。
今回の課題
- リサーチボードをつくろう
- ビジネスインタビューとユーザーインタビュー、それぞれの「Research Question」を考えましょう！
- それぞれのRQに対して、Key Questionを３つずつ考えましょう！
- Key Questionをそれぞれ、5W3Hで深ぼる質問を考えましょう！
出ていた課題は上記。ですが、トモさんから「この1on1の時間をどんな時間にしたいですか？」と問われました。
いつも「どんな時間にしたいか？」を聞いてくださるので、とても前向きな時間になります。
ちなみに、次の日にビジネスインタビュー、週末にユーザーインタビューを控えていたので「その時間が有意義な時間になるようにしたいです！」と言いました。それでは今日の1on1スタートです。
リサーチボードをつくろう
前回の課題の「関係性を調べる」で調べていた事を、リサーチボードにして、目に見えるようにしていきました。
調べたことのスクリーンショットを置いたり、その内容を読んで私はどう思ったのかとメモをしていったりまとめていきます。
私は採用の記事とかを集めてみましたが、競合はどんなサービスがあるのかをまとめている方もいて、こういうまとめ方もある！！と勉強になりました。（競合が提供しているサービスは、自社の喉から手が出る課題につながるのでは？）
ビジネスインタビューとユーザーインタビュー、それぞれの「Research Question」を考えましょう！
前回、「Research Question」はインタビュー後、私たちが回答する問いということから、必要なことを考える。何を答えれるようになったらプロダクトをつくれる（リニューアル）できるのだろうか。
と考えていると、ビジネスインタビュー、ユーザーインタビューともに「アプリに必要な機能はなんですか？」というのがRQになるのではないか？と思いました。必要な機能がわかれば、デザインもできる！そこから「Key Question 」を考えれば良いのではと思いました。
でもどちらも一緒でいいのだろうか。それぞれのインタビューの目的はなんだろうと考えて…
「アプリに必要な機能はなんですか？」という問いと別に、
ビジネスインタビューは「アプリをどのようにしたら、事業が最大化しますか？」
ユーザーインタビューは「アプリを使う用途はなんですか？」
という質問にしました。
改めて見ると、このRQに回答できるようになったところで、アプリはできるのか？ユーザーインタビューは課題を見つけること、解決したいジョブはなにか？を見極めることなので本当にこれでいいのかな？と。
フィードバックです。トモさんのRQは
ビジネスインタビューは「プロダクトの１年後の姿は？」
ユーザーインタビューは「アプリのユーザーが喉から手が出るほど解決したい業務（Job to be Done）は何か？」
なぜそのRQにこの内容を設定したんですか？という質問に対して「仕事が始まる時に何しますか？」と聞かれて。
「勤怠管理のボタンを押します」と返答すると「そのボタンを押すとき、どう思ってる？」と。
何も考えていない…何も考えずに勤怠を押して仕事に入るなぁ…何を思う？？と考えていると
「そうだな…You Tubeは見ますか？」と聞かれたので「見ます」と。
「何の制約もない状態でYou Tubeアプリと勤怠アプリどちらをひらきたいか？と聞かれたら、You Tubeですよね？」ときかれたので「そうですね…！！」
「僕自身デザインの仕事は大好き。だけど仕事ってそれだけではないし、ノンコア業務を喜んでやっている人はすくない。アプリを使う目的は、ユーザーが喉から手が出るほど解決したい業務を1秒でもはやく終わらせること」
なるほど。そう考えると、B2BのユーザーインタビューのRQは横展開できるかも？とふと思い「B2BのRQは横展開できますか？」と質問すると、「そうだね、B2Bの普遍的なところは変わらないので、できますね」と返答いただき、「じゃあなんでB2BのUIデザイナーは人が足りないのでしょうか？」とさらに質問すると、「事業ドメインの理解が難しいから」と。
たしかにtoBは事業ドメインの理解が難しい。toCは自分が体験できることも多いので、理解を深めやすいのはあるなと思いました。ここらへんも思っていることがあるので、別にブログで書きたい。（ホームページとアプリデザインのプロセスや思考の違い…みたいなことを書きたい。ぜんぜん理解していないけど、アウトプットする中で自分で咀嚼したい）
RQに答えることはは言わば課題を見つけるための手段。プロダクトをよくする目的のための手段のひとつであることを忘れないようにしなければと思いました。
他に考えたこととしては、Job to be Done をどう感じるかは人それぞれかもしれないと思いました。 例えばWebデザインで下記のjobにわけた時、コーディングが苦痛な人、そうでもない人とスキルや思想によって変わるよなぁと。そう考えると事業ドメインの理解は大切だと改めて感じたといいますか。
- 企画／立案
- デザイン
- コーディング
- アップロード／連絡
それぞれのRQに対して、Key Questionを３つずつ考えましょう！
キークエッションはちょっと具体的になり、プロダクトをリニューアルする会社さんの名前を言えないのであまり詳しくは欠けないのですが…
トモさんのどのKQを見ても、RQに行き着く内容。RQをどういう視点で切り取るかなんだと思いました。その点私のKQはブレブレでした。
トモさんからのアドバイスは
- インタビューの質問は抽象的な事を聞くのもいいが、ストレートに「次の機能は？」と聞くのもいい
- アプリの状況を頭に入れ「インスピレーションを刺激してくれそうな答え」を引き出すために質問を考える
仮説検証としてのリサーチであれば、「求めていた答え」だと思いますが、今回は仮設”探求”のリサーチの側面が強いかなと思ったので「インスピレーションを刺激してくれそうな答え」に。 - 使い倒されているものではなく、アプリもまだ芽が出て、これから花が咲くということを忘れない
- 聞き方を気をつける。例えば「アプリじゃないとやれないことは？」ではなく「もしアプリでひとつ仕事が片付くとしたら何がいい？」という風に「インスピレーションを刺激してくれそうな答え」を引き出すために、質問も工夫が必要
- いつもインタビュイーが考えていること（いそうなこと）を最初に聞くとアイスブレイクになって良い
toCのことやtoBのこと、質問の仕方や抽象的な質問の横展開など…とても学び多かった1on1でした。
その後、色々質問をしたのですが、私はいろんなものを「型にはめよう」とする癖があるなぁと感じました。大事なのは「なんのため」。それを忘れずに進んでいこうと思いました！
まとめというか、願望。学びについて
このクラスは関係ないのですが、もし3億円目の前にあったらどうする？という話を同居人としまして。
うーん…マンション（居住用）を買って、あとは…サービスを心ゆくまでつくったり、大学院とかで学びなおしたいなってお互い言ってて。住まい以外の欲しいものは「学び」でした。
こんなにたくさん「学びたい！」と思える仕事に出会ったのは、幸せなことかもしれないなぁと思い、その日は眠りにつくことにしました。
