こんにちは、さおり(@iropon30)です。
この記事では、私が受講している実際のプロダクトで学ぶB2B UIデザイン [Uzabase B2B SaaS Business CDO]×[1on1] を通して学んだことや感じたことなどをまとめていけたらなと思います。
今回ははじめての課題提出、2回目の1on1です。
はじめての1on1、今日の課題については前回の記事でもかいていますが、今回も振り返りながら書いていこうと思います。
この受けた感想のブログを書く理由は、学んだことを自分の中で言葉に置き換えたいと思ったからです。
なので、一緒に学ぼ！というより、自分の備忘録的な感じで書いております。
課題をしてみてどうだったか？
難しかった。普段あまり考えないことをしていたので、時間がかかるし普段も考えたりしています。（仕事しろよ！という感じですが、仕事の合間に考えてます。）
やはり普段から考える訓練をしたほうがいいなと思いました。でもB2Bビジネスってどう訓練するんだろうか…今度質問してみます。
- プロダクトの会社資料や各種インタビューを読み、FigJamで関係性をまとめる
- アプリにログインして、使ってみる
- アプリを構成する「画面」と「部品」をスクリーンショットしてFigmaで分類する
- 上記のフローを通して、ビジネスインタビュー・ユーザーインタビューで質問したいことをメモする
この出た「課題」ですが、トモさんも同じ課題をします。トモさんのアウトプットを見て質問したり、気づくことがとても多いです。
では、早速課題で感じたこと学んだことをアウトプットします。
プロダクトの会社資料や各種インタビューを読み、FigJamで関係性をまとめる
実際のプロダクトの会社名は出せないので内容だけ。前回の1on1でビジネス資料（採用ピッチ資料だと思いました）とこれまでこたえてきたインタビュー記事などを共有いただきました。あとは今回リニューアルするプロダクトのテスト環境へのログインもできるようにしていただきました。
共有していただいたもの、他に自分で調べたものから、企業さんと顧客の関係性をFigJamでまとめる課題でした。
実際に手を動かしてみると、目的を見失ってしまう
課題に入る前は「企業さんのプロダクトを良い方向に導くリニューアル提案をする」そのために企業さんのことやプロダクトの事を考え、知っていくという目的だ！と思っていても、手を動かし始めると「関係性をまとめる」ことを目的にしてしまっていることに、フィードバックで気づきます。
なんで作業に入ると目的を見誤ってしまうんだろうかと考え、これからは作業に入る前に（課題・実務ともに）目的を考え、文字にして残して作業に入ろうと思いました。
「※美しくまとめる必要は全くないです。そこに時間をかけないでください。 」と注意書きがされていましたが、トモさんのまとめたものは美しく、内容が頭にすんなり入ってきました。美しくまとめる必要はないけれども、目的を最大化するための美しさは必要だと感じました。
アウトプット内容で圧倒的差を感じて、ほんとうにまだまだだなと。感想を求められたんですけど、目的思考やアウトプットの差がありすぎてもう…と言うと、「人は差がわからないと埋めようとはしない。」と言われ、たしかに差がわかると、差をどうやって埋めようと考える自分がいました。圧倒的差に気付かせてくれるというのも、またひとつの学びだと思いました。
アプリにログインして、使ってみる
これはすぐできました。テスト環境なので好き勝手使ってみました。
でも気になるところ。これは…現場で使われているのか？使われていないんじゃと思いました。
そしてその気持は、課題を進めればすすめるほどそう思っていくのであります。
アプリを構成する「画面」と「部品」をスクリーンショットしてFigmaで分類する
ほぼ初Figmaでしたが、あまり抵抗なく使えました。（よかった…これからも授業受けれる）
こちらの課題の目的は「プロダクト理解」と「Figmaに慣れる」というのもありますが、こちらの課題でも差を感じることになります。
私は「画面」も「部品」も抜け漏れがありました。やっているときは「ここもスクショしなきゃ！」と思っていたのに忘れちゃいました。今回は「今あるプロダクト」なので違うかもですが、必要な画面を洗い出して、あらかじめ定義しておくことは大切だと感じました。人間の記憶なんて抜け落ちますもんね。
そして、一番差を感じたのは「何のためにするか」をもっと違う目線から俯瞰されていたことです。
例えば今回の課題の目的は「プロダクト理解」と「Figmaに慣れる」ではありますが、もっと大きな目的としては「このプロダクトをより良いものにリニューアルする」ということ。そしてこの部品の分類には改善案を論理的に考えやすくし（オブジェクト指向）、副産物（？）として実装もしやすくするメリットがあります。
トモさんは「部品」を改善案を考えやすく分類されていて、私はとりあえず分類しましたという感じがにじみ出ていて。「そうですよね、これ開発しやすくするための練習でもあるんですよね」って感想で述べました。
「僕は目的主義だから〜」と話されていたけれども、どうしたらきちんと切り分けることができるのか…自分にあったやり方を見つけないと、見つけたいと思いました。
上記のフローを通して、ビジネスインタビュー・ユーザーインタビューで質問したいことをメモする
実はこのプログラム、実際の「ビジネスインタビュー」と「ユーザーインタビュー」を行います。（この記事を書いている今、もうインタビューを終えているのですが、その感想はまた今度。）上記のフローを通してインタビューで質問したいことを洗い出しました。洗い出したと言うより、調べながら聞きたいこと、疑問に思ったものをペタペタメモした感じでした。
「インタビューの質問を考える」は次の課題のフローなので、その足がかりのための課題のように感じました。
次の課題とその説明
- リサーチボードをつくろう
- ビジネスインタビューとユーザーインタビュー、それぞれの「Research Question」を考えましょう！
- それぞれのRQに対して、Key Questionを３つずつ考えましょう！
- Key Questionをそれぞれ、5W3Hで深ぼる質問を考えましょう！
リサーチボード
これはトモさんが例を見せてくれましたが、今回の課題の「関係性を考える」で調べたもの、読んだものを「見える化」することだ！と思ったので、すぐに飲み込めました。
「Research Question」と「Key Question」
トモさんがあげてくださった、採用の場合の例。「Research Question」と「Key Question」私はどちらも「相手に質問するもの」だと思っていて。でも採用の例の「Research Question」が相手にする質問じゃないよね？なぜ？（でもこんなこと聞いていいのだろうか？）意を決して質問してみます。
「「Research Question」も相手に質問するんですか？そしてその深堀りがKey Questionですか？位置づけがわからなくて…」
トモさんも悩まれてましたが、ハッとした感じで「RQって、リサーチ後に自分たちが回答するための問いだよ」と言われすーっと入ってきました。
今思うと、例の内容が、例）プロダクトのリニューアル、「RQ：プロダクトに必要な機能は？」とかだとこの質問しなかったなぁと。プロダクトのリニューアルなら、「必要な機能は？」って相手にも質問してしまうよな…と想像してしまいそうですし。
というかまず、リサーチする時に「Research Question」と「Key Question」にわけるということを考えたことがなかった。本は色々買ってみているが、なかなか一歩が出ずに読んでなかった。その本とトモさんにおすすめされた本を読んでみようと思います。
この返答を受けて、リサーチインタビューが必要なことで、どんな時に必要なのかということが少しつかめた気がして。積んでた本を読みたくなったので、自分としても大きな収穫です。
定型的なヒアリングシートってどうなの？
この1on1を受けて、定型的なヒアリングシートは必要なのだろうかと考えました。ヒアリングシートという、顧客に対して似たような質問をするシートは必要なのだろうかということを、自分で時間をとって考えたいと思いました。
どこかで考えてブログを書こう…
受け身だった、反省。まとめと次に向けて
トモさんに「この1on1が終わったあとにどうなっていたいか？」そして最後に「1年後どうなっていたいか？」などを投げかけられました。
この質問を考えていると、私の気持ち的に1on1をすることが目的になっている感じがあって。目的はプロダクトのリニューアルで、そのリニューアルは何のためにあるのかを紐解いていくこと。あわせて、私がどうなりたいのか？をきちんと考え1on1に臨む姿勢が大事だと感じました。
課題を出してもらって、課題をやってで終わってはいけなくて。自分の想像していたなりたい姿に近づくために質問したり、考えたりすることも時間としてとらないといけないなと思いました。
もっと主体的に考えて臨みたいなと。次から気をつけます。
