見出し画像

入社して9ヶ月目にしたこと。

Tommyです。

この記事は、株式会社BesoのUIUXデザイナー 9ヶ月目となる2022年12月にしたことをまとめています。

9ヶ月目の2022年12月のキーワードは、大きく3つが挙げられます。

・課題探索のリサーチ
・質的なデータの整理
・ディスカバリーバックログの作成


課題探索のリサーチに出かける

前回の記事で、新機能開発で消費税に着目する、と書きました。
グループ内の税理士にヒアリングし、消費税が絡む業務の中でどのようなことを課題に思っているのか、書き出していたのですが、Besoという税理士事務所は、税理士界隈の中ではわりと特殊な感じもあります。

そこで、他の税理士事務所ではどのような課題があるのか、オンラインによるインタビューでヒアリングを重ねました。

CEO・COO・エニジニアの協力を経て、知り合いの税理士に繋いでいただき、10名の先生にヒアリングを行いました。

Beso以外の税理士へのヒアリングで意識していたこと
・他の税理士にも当てはまる課題か
・実は税理士によく当てはまるが見落としている課題はないか

ヒアリングした結果としては、おおよそ既に出ていた内容と似たような課題が見受けられました。

ところで、ヒアリングを行ってみて思ったのは、どれぐらいの人数まで聞けばいい?という点です。

今振り返ってみて思うのは、以下のようなことを事前に整理しておくことが必要だったなと思います。(当時もしておけよ、という感じですが)

  • 話を聞いて明らかにしたいことは何か、ゴール設定を明確にする

  • プロジェクトの期限や機能リリース予定日から逆算して探索のリサーチに取れる時間がどれぐらいかを確認する

次に実施する際は、Goodpatch さんのブログ記事も参考にしたいと思っています。


質的なデータの整理

課題探索のリサーチでヒアリングを重ねていくと、聞いた話の内容が貯まっていきます。聞いた内容自体は、Notion にズラズラーっと書いているのですが、これを分析しやすいようにするにはどうすればいいか、この点もリサーチをしながら考えていました。

Notion のように議事録的に聞いたことを書いていると、単一のインタビュー内容自体は見返せるのですが、そういえば 別の Bさんはどのようなこと言っていたっけ?というように複数の内容を並べてみたい時は無理が生じます。

聞いた話の内容から、「実はこうだったんだね」を見つけたいよなと思っていたので、当時の筆者は、FigJamにそれぞれのインタビュー内容からこういう事実があるぞ、という要素を切り出し、ペチペチと付箋っぽいやつを置いていくことにしました。

付箋っぽいやつを置いていく際に、少しでも「実は」な要素を見つけかれることを期待し、FigJamのテンプレートとして公開されていたAtomic research のフレームワークを利用しました。

ちなみに、Atomic researchとは、
・ユーザーの声を集める施作
・施作から得られた「こんなことわかりましたわ」という事実
・事実からこんなことが言えそうという洞察(インサイト)
・だから、こういう風にしよう、という結果
のつながりをきっちりわかるようにしておこうというフレームワーク

かなと個人的に思っています。

リサーチ1回やって終わり、ではなく、タグなどつけて引っ張り出しやすくしておき、そういえばあの時のリサーチでも似たような事実あったな、
ということは…こんなことが言えそうだ といった洞察を得やすくするものでもあるかと思います。

英文ですが、参考になりそうな記事を貼っております。

さてまあ、FigJamで公開されていたテンプレを用いて、インタビューで聞いた内容は整理してみることにしました。

ディスカバリーバックログの作成

さすがに1週間のスプリント内では完結しないものもある

新機能開発の話が始まっていた一方で、リリース済みの機能の改修の話も実は走っていました。それも細々したものというよりは、ガラッと変更するような内容です。

Besoでは、開発のプロダクトバックログで1週間単位のスプリント期間に合うサイズのタスクに切り分けられていました。細かい内容であれば、1週間以内でデザイナーが検討する内容→エンジニアによる実際の実装、まで持っていけるので、プロダクトバックログでタスクの管理もできます。しかし、ガラッと仕様が変わるような内容はもはや1週間で済まない大きな内容です。

デザインスプリントの経験から、デザインチームのタスクもスプリント期間に区切って決めるとやりやすいことを学んでいたので、Lean UXの本を参考にしながら、Notionでディスカバリーバックログなるものを作成しました。

プロダクトバックログとディスカバリーバックログは分けない方がいいという話もありますが、今回 Besoでは分けてみました。
(NotionのDBを使っている手前、アイテム多すぎると読み込みが遅いといったこともあったのと、エンジニアもリサーチ段階から巻き込んでいたので、一旦分けてもいいか、と判断しました)

ディスカバリーバックログの中身

作成したディスカバリーバックログは、リサーチから実装手前のUIデザインに至るまでのデザインチームでアクションが必要なことを登録し、管理できるようにしたものです。

UX5段階モデルの考え方をベースに、戦略・要件・構造・骨格・表層とステータス分類し、各ステータス段階で行う内容を書いておくようにしました。

管理対象にしたのは、新機能開発プロジェクト・大幅な機能改修プロジェクトです。

このバックログを運用してみて、以下の点が良かったです。

  • 各自が持っているタスク量がわかり、調整もできる

  • プロジェクト自体の進捗がどのステータスまで来ているかわかる

1週間のスプリントの振り返りでもエンジニアやPdMに話を共有しやすかった記憶があります。

さて、6年従事したメーカーの海外営業をやめて、未経験ながらデザイナーとしてスタートアップに飛び込んだ2022年。
目まぐるしく色々と動く日々のなかで、プロダクトの機能開発をガシガシと進めていく下地を整えて年末を迎えるのでした。


最後までお読みいただき、ありがとうございました!


参考:今回の記事の内容に関連するもの

入社して7ヶ月目にしたこと。
入社して6ヶ月目にしたこと。
入社して5ヶ月目にしたこと。
入社して4ヶ月目にしたこと。
入社して3ヶ月目にしたこと。
入社して2ヶ月目にしたこと。
入社して1ヶ月目にしたこと。

この記事が気に入ったらサポートをしてみませんか?