スクラムチームのデザイナーを半年やってみて気づいたこと

こんにちは、こんばんは。Uniposプロダクトデザイナーのぱっち（@gokigen_patsuji）です。

こちらのnoteはUnipos株式会社アドベントカレンダー12日目の記事です。
週末をSplatoonのビッグランで溶かしてしまい、気がついたらこんな時間になってしまいました。

2022年4月からスクラムチームにジョインし、半年と少しが経ちました。やっと自分の言葉で伝えられるようになったので、スクラムチームで働くデザイナーとしてやっていること・約半年やってみての気づきをまとめてみようと思います。

本題の前に：開発チーム体制

Unipos社には機能開発チームが3つあり、各チームでバックログをもっています。（厳密には他にも開発チームがあるのですが、今回は割愛します。）
そして、私のチームのメンバー構成は次の通りです。

プロダクトオーナーとスクラムマスターがそれぞれ1人。デザイナーは私とトレーニーがペアでアサインされており2人で動いています。エンジニアはフロントエンドエンジニアメインですが、入退社やサーバーサイドのメンバーのジョインなどがあり1〜3人を推移しています。

本題の前に：チームで大切にしていること

チームでは「価値あるものを顧客に早く届ける」ことを大切にしています。
（どの会社、どのチームでも当たり前のことかもしれませんが、チーム活動の大上段にあるスローガンとして頻出するので改めて…。）

提供が早くても顧客が必要としていないものだったり、要求に足りないものでは結局使われないのでムダになってしまいます。また、求める以上の品質や機能を提供しても、必要以上にかけたコストや使われない機能はムダになります。

そうならないために。顧客やステークホルダーの要求を理解し、適切に価値のあるものを早く届けるために。半年を通して、キーになりそうだと感じた行動・考え方が3つあります。（相互に影響し合うように思います。）

1. 選択肢を増やす

2. リードタイムを短くする

3. チームみんなで顧客を知る

1.選択肢を増やす
新しい発見によって情報が増えたり時が過ぎて状況が変わったりすることで、何をどう作るべきかの最適解が変わっていきます。早々に1つに決めてしまうと、その案がダメになった時の転換コストが大きいです。決めたことをイチから考え直すのはメンタル的にも時間的にも辛いので減らしたいですね。

2.リードタイムを短くする
顧客やステークホルダーにぶつけてフィードバックをもらうことで初めて学習でき、確信を持てます。その試行回数を増やそうというものです。与えられた時間は全世界平等なので、リードタイムは短ければ短いほどいいですね。

3.チームみんなで顧客を知る
今の私のチーム規模だからできていることかもしれませんが…。又聞きではなく、自分で見て聞いて解釈したユーザー像があることで、目的・顧客に対して最適な意思決定を各職能領域からできると感じています。

ではこれら3つのことを実現するために、具体的に何をやっているか。

具体的にやっていることと気づき

特に良いと感じていることが3つあります。

• インタビュー同席と分析ワークショップ

• モブデザイン

• モブプログラミング

インタビュー同席と分析ワークショップ
以前はプロダクトオーナー・デザイナーで計画・実査・分析をして、結果まとめをそれ以外のメンバー（主にエンジニア）に共有することがほとんどでした。
今のチームでは、エンジニアもインタビューに同席し発話録をとったり、追加質問パートで参加しています。また、実査各回の振り返りも一緒に行ってインタビュースクリプトを修正したりします。

開発プロセスのかなり早い段階で、実装についても思考巡らせられるメンバーがいることの心強さといったらこの上ない…。同じ発話からでも、職能によって別の気づきが出てきます。インタビューや分析ワークで得た情報から仕様検討前に先回りして調査を行ったり、各職能の作業領域で参考にしたい情報をインタビューで追加質問したり。
チームが自信を持って価値提供できる、そのための意思決定に必要な情報をより集められるようになったと実感しています。

モブデザイン
デザイナー同士はもちろん、デザイナーとエンジニアでもモブデザイン（モブ仕様作成）をします。
デザインのフェーズをざっくり3つ（情報収集・発散・収束/意思決定）に分けて考えると…。
情報収集と発散のフェーズでは、情報と視点はできるだけ多くあってほしいです。いちデザイナーが思いつくアイデアはほんの一部です。エンジニア視点だからこそ気づける、より良いデザイン・実装方法もあります。選択肢を増やすために、「一人で考える」をしすぎないことが大切です。
会話の中で「こんな案どう？（提案）」「これはちょっとビミョー」といった発言があれば、背景にある意図や価値観を深ぼることを意識します。手段と目的のレイヤーを行き来して会話することで、認識のギャップに気づいたりより良いアイデアを思いついたりするように思います。
（実際にモブデザインをやってみて、従来だと決定までに2−3日かかっていたやりとりが、1時間のモブデザインで意思決定できたこともありました。リードタイム短くて最高！）

他方、収束/意思決定のフェーズでは「デザイナーとしてこのアイデア・デザインに誇りをもてるか？」という問いを自分に投げかけます。
モブで決めることは、自分で意思をもたないことと同義ではないですよね。自分が自信をもって顧客に届けられるよう、一人でじっくり考える時間も大切にします。

モブプログラミング
こちらも、エンジニア同士だけでなくエンジニアとデザイナーのモブプログラミングを行います。
デザインの読み解きや、見逃しがちな細かい指定なども一緒に確認しながら実装していきます。テスト中、大量のイシューとともにデザインが伝わらなかった事実が発覚… なんてことがなくなります。イシューを生まなければイシューを立てて直して閉じる時間が不要になります。なんてハッピー！
私のチームでは、ざっくり動くものができた状態でインタラクションやスタイルを確認するところからモブする進め方に落ち着いています。

さいごに

最後までお読みいただきありがとうございます。
デザイナーの役割とは、自分でリサーチをしたり仕様やデザインを考えることではなく、顧客の課題を解決する最適な方法を実現するために情報を集め、問いを立て、議論する場をリードする、またそのような場を支援することなのではと思うこの頃です。
チーム内外のリソースをフル活用して（あわよくばちょっと楽して）、価値あるものを早く顧客にお届けできれば嬉しいですね。

まだまだ精進するところはたくさんあるので、来年も、いや明日からもフルスロットルで頑張ろうと思います。

============================================
Uniposデザイナーチームではプロダクトを一緒に成長させてくれるプロダクトデザイナーを募集しています。
少しでも興味を持ってくださいましたら、ぜひ下のリンクからご連絡ください。