こんにちは、さおり(@iropon30)です。
この記事では、私が受講している実際のプロダクトで学ぶB2B UIデザイン [Uzabase B2B SaaS Business CDO]×[1on1] を通して学んだことや感じたことなどをまとめていけたらなと思います。備忘録です。
前回の1on1記事はこちら
前回曖昧な言葉を使っていると気付かされ、それが嫌になり変わりたいと思いました。
Twitterでつぶやいたときにアドバイスいただいたり、毎週休日の朝に積読会をしているのですが、そこの参加者の方に「悩んでる」とぼそっと言うと、いろんな方が「自分はこの本が良かった！」と本を紹介してくれました。恵まれた環境です。（いつか積読会のことも書きたいなー。私はひとりで本を読むより積読会で読むのがとってもあってる気がするのです！！）
今回は前回の反省を踏まえて、自信をもっていくために随所に事前準備を！（仕事では当たり前ですが、その当たり前すらできてなかったのかも。反省。）という気持ちで臨んだ1on1です。
今日はどんな時間にしたいですか？
いつも1on1のはじまりに聞かれるのですが、「これは聞きたい！」という事を忘れたりするんですね。ポンコツなので。
今回から事前にどんな時間にしたいかを事前に書いてチャットで送りました。実はこの「どんな時間にしたい」というのをあらかじめ送るの、だいぶ迷いました。というのも、この「どんな時間にしたいのか？聞きたいことは？」というのを書いてしまうと、それ以上広がりがないんじゃないか…という不安があったので。
結果は書いてよかったです。書いていること以外でも話は広がります。むしろあとから「これも聞けばよかった」になるよりも（チャットで質問できますが）有意義だと思いました。
課題のフィードバック
今回の課題はこちら。盛りだくさんでした。
- ビジネスインタビューとユーザーインタビューを分析し、構造化してみる。構造化のあと、リサーチを通して発見したことを文章でかいてみる。その後、Research Questionに対して回答してみる
- 今回のリサーチを通してアプリを良くするための解決策を考える
- ユースケースを特定する
- ユースケースのストーリーに登場する画面案を描いてみる
- 描いた図面案をみながら、必要なオブジェクトを追加し構造化してみる
前回突っ込まれても、答えられなかった。私は何をしているんだ、と悔しくなったので、今回はそういう思いをしないぞ！と思い、インタビューを3回は聞きました。うち1回は自分で文字起こしをしました。聞いては戻し、聞いては戻しをしました。
その後は、ラジオのようにインタビューを聞き、この時にこういう事を聞いておけばよかったな…と思うことが出てきたり、もしかしてこれはこういう意味で言っている？と違う受け取り方を考えてみたり。結果、インタビュー後に印象に残ってたところよりここのほうが良いんじゃ？と思うところが出てきたりと新しい発見がたくさん。
きっと、回数や練習を重ねることで、インタビュー中にあたりをつけられるのかな？と思ったりします。が、今の私にはこれがきっと一番いい選択肢だった気がします。改めてインタビューを聞いてよかった！
インタビューを構造化し、Research Questionに回答する
私はこの「構造化」の仕方がわからず…（先週も教えてもらいましたが、自分の中に落とし込めていない…）
だけど、何もしないのは良くないし、自分なりにやってみよう！ということで、一番最初の課題「関係性を図にしてみる」というのをインタビューを受けてやり直してみました。
インタビューから見えてきたそれぞれの関係性を図にすると、また新しく気づくこともありました。そこからResearch Questionを立て直し、回答しました！
課題のフィードバックを受けるときも「構造化がやっぱりよくわからなくて…」と伝え、説明してもらいました。
自分なりにまとめておきます。
構造化とはざっくりいうと、「node（結び目）、Link（つながり）の関係」である。インタビューの内容は「具象度が高い」ものが多いので、「抽象度が高い」ものにしていく。具象度と抽象度を行き来して、丁度いい塩梅に落とすのが大切。「抽象度：高い」ものをインタビュー分析から導き出す。（例. https://goodpatch.com/work/speeda ）
インタビューから、何が課題か？提供価値はどうすればいいのか？解決策は？と導くために構造化する。
今回のリサーチを通してアプリを良くするための解決策を考える
会社さんやアプリのことはかけないので、課題・提供価値・解決策を考える時にこういう事を気をつけたほうがいいのでは？と思ったことを書いていきます。
本当の課題は？提供価値は？解決策は？と考えたりすることも多いですが、それ単体で考えているだろうかと。
課題がなければ、提供価値は考えられない。提供価値がなければ、解決策を考えることができない。
解決策は課題を解決するものになっているか？と解決策を疑うことも忘れてはいけない。
だけど、単体で考えるときは混ぜてはいけない。難しいなぁと。
例えば「テストの点を降順に並べたい」という課題があるとする。（本当にその課題でいいのか？というのも問わないといけないことなのだけど…ここでは無視）
とすると、入力はテストの点の配列で、その配列を降順に並べることが提供価値。提供価値を得るための解決策はバブルソート？クイックソート？それとも新しくアルゴリズムをつくる？など色々考えられます。
トモさんは今回、インタビュー中にアプリの形が浮かんだそうです。ちなみに、実務でも浮かぶ時、浮かばないときがあるそうです。
浮かぶときは、アブダクションでどういう提案をしたら、この提案が通るかのストーリを決める。(後付といったら、自分が嫌になるでしょうと言われていたのが印象的でした)
浮かばないときは、リサーチを分析しなおす。出るまでしなおす。
記憶したいこと
構造化は課題を導くためのひとつなので、課題や提供価値、解決策が見つかればしなくてもOK。課題を見つけるための手段。浮かぶときは、アブダクションでどういう提案をしたら、この提案が通るかのストーリを決めれば良い。
インタビュー中に何をしている？何を考えている？という質問の返答は、今回は「新規提案」をずっと頭の中で考えている。インタビュー中の質問は思い浮かんだ時に、手元のメモに書き出す。その書き出した質問は、必要な問いなのか、ゴシップなのかを常に問う
中間発表に向けて
講座の中で、何をしていきたいのかを考えて、何をフィードバックしてもらいたいかを考えてやってみます。
まずは具体的な言葉を見つけようと思いました。
まとめ
会社さんやアプリの事を書けないので、あまり踏み込んで書けませんが、いつも頭の片隅にどういう風にアプローチしようか？という、いつも考える習慣がついたのはいいなと思います。来週は中間発表です！
余談
実はこの記事でブログの記事が100記事に到達しました！今まで2日に1回ペースで書いていたのですが、これからは自分が書きたいときや、読んでみたい記事を発注して納品いただいたタイミングとかで更新できればと思います。
週1は更新できるようにやってみようと思いますー。これからもよろしくお願いします。
