ユーザーの立場でものづくりをするために必要な立ち回り：スクラムチームでどう動く？
こんにちは、tsugumiです。
タイミーに入社して2度目の年末を迎えます。
….ということで、約1年半ほど経ち（=プロダクトデザイナー歴）、プロダクトデザイナーという職能の解像度が上がってきたので、言語化してみようと思います。
また、この記事はTimee Product Advent Calendar 2024の19日目の記事です。
前提情報として、私のこれまでの経歴について気になった方は、ぜひ以下の記事もご覧ください。
ビジネス視点を重要視する
まず、私自身のデザイナーとしてのスタンスを起点に考えてみます。
組織にはさまざまな職能の人間がおり、さまざまな視点を得意とする人間が集まることで、より多角的にものごとを捉えられると考えています。
そんな中、私自身は特にユーザー視点のスペシャリストである（常にそうあるべきだ）と考えています。
「どこまでもユーザーの味方であり、ユーザーの立場でものづくりをする」というスタンスです。
しかし、そのものづくりはユーザー視点だけでは持続しません。
ビジネスとして成り立たなければ、立ち行かなくなってしまいます。
ユーザーが気に入って喜んで使っている最中、突然そのサービスが終了する…なんてことは体験としても避けたいですよね。
会社の成功、より成長している状態を維持し、さらにはその業界においてトップを走り続けることで、そのスタンスでいられる可能性がより高まると言えます。
つまり、「どこまでもユーザーの味方であり、ユーザーの立場でものづくりをする」ためには、ビジネス視点がより一層必要であるということです。
ただ、現在の会社の規模を考えると、自分の働きと会社の成功に少し距離を感じるので、もう少し現場にズームして考えてみる必要がありそうです。
タイミーでは、ワンプロダクトに対して複数の開発チームが構成されています。
中でも私が属している開発チームは、働き手と事業者のマッチング体験にフォーカスしたチームです。
このチームが、どれだけ会社に貢献しているかが重要である と言えるでしょう。
自分の働きと所属するチームの成功（会社への貢献）であれば、距離が近いので考えやすくなりました。
では、チームが成功し続けるために、どのようなアプローチが必要か 考えてみます。
私が所属している開発チームは、アジャイル開発を行うチームであり、
スクラムのフレームワークを実践しています。
スクラムチームはプロダクトオーナー、スクラムマスター、開発者（デザイナーやエンジニアなど）の三つのロールで構成されます。
中でもプロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を、最⼤化することの結果に責任を持つとされています。
参考資料：
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
とすると、チームが成功し続けるためには、いかにプロダクトオーナーをサポートするかが重要という切り口で考えることもできると思うのです。
プロダクトオーナーをどのようにサポートできるか、より大きな成功に向けたアシストができるか を、考え行動することがチームの成功につながり、結果的にユーザーの立場でのものづくりにつながると言えそうです。
ビジネス視点を重要視したアプローチ
では、実際にプロダクトオーナーをどのようにサポートできるか、より大きな成功に向けたアシストができるかを、以下に書き出してみました。
プロダクトオーナーと共に戦略を練る
ビジネス課題にユーザーにとって理想的な体験を接続することで、より大きな価値提供を可能にする
プロダクトオーナーの戦略をより早い段階で具体的な体験に落とし込むことで、チームのコミュニケーションを加速させる
仮説や問いを立てることでプロダクトオーナーの脳内を理解し、どこが曖昧なのかを特定することで戦略を研ぐ
プロダクトオーナーの視野を広げ、戦略の幅を広げる
チームのスプリント内での生産性やクオリティ向上のための改善に積極的に取り組むことで、開発時の選択肢を増やす
UXリサーチなどを状況に応じて提案し率先して行う。
ユーザーの理想的な体験をビジネスに接続することが難しくても、まずはユーザー視点を共有し対話をするプロトタイプなどの形でアイディアを発散することで考えを深めたり、新しい発想を与える
チームの意思決定を助ける
日頃のリサーチ活動を通して得た学びや発見をもとに、チームとの共通認識を作り、開発者全員がプロダクトオーナーと共に中長期的な計画について考えられる状態にすることで、プロダクトオーナーへの依存度や意思決定時の労力（時間など）を軽減させる
ソリューションのコンセプトをビジュアライズしチームの理解を得やすい状態を作り、プロダクトオーナーがコミュニケーションをとりやすい状態にする（チーム外のコミュニケーションに対しても有効）
プロダクトゴールのその先を、プロダクトオーナーとともに具体化することで、未来の顧客価値を発掘し、チームの優先順位の指標とする。そうすることで、短期的なインパクトが見込みにくい長期的に取り組むべき課題に対しても、チームメンバー個人の価値観ではなくチームの価値観になることで、優先順位づけが可能になる
プロダクトオーナーへのサポートという切り口であるものの、「ユーザー目線」をプロダクトに注入しているようにも見えませんか？
デザイナーがユーザー視点の専門家だとするならば、プロダクトオーナーはビジネス視点の専門家と言えるでしょう。
しかし、視点は分担するものではなく、どちらの視点も理解しなければ、対等に会話することはできません。
特に、事業会社においてビジネス起点の取り組みが増えることは、必然であると言えます。
だからこそ、ビジネス視点とユーザー視点を接続するためには、分担ではなくデザイナーがどちらも理解する必要があるのです。
そうして、プロダクトオーナーの戦略や思想を言語化、見える化をする中で、共に最善を考え、そのビジョンや計画を具体化することが「ユーザーの立場でのものづくり」につながるのではないでしょうか。
スクラムチームに適応する際の課題と解決策
プロダクトオーナーに対して具体的にどのような貢献が可能かがわかったものの、うまくいかないこともあります。
私の場合は、やりたくてもできないという状態に陥ってしまいました。
その原因は、スクラムチームへの適応がうまくいっていないからであると考えました。
スクラムには一定の開発期間（サイクル）があり、これをスプリントと呼びます。
タイミーのスクラムチームはこのスプリントの期間を1週間にしているケースが多いため、1週間で機能開発を行いユーザーの手に届けています。
そのため、実装に必要な時間を考えると1日〜2日程度で開発に必要なUIデザインを行います。
その他ミーティングや、エンジニアとのコミュニケーションを踏まえると、実際は1日程度になることもあります。
私はこの1年半、スクラムのサイクルに適応しようとする中で、以下の課題を感じていました。
スピードだけではなく、UI品質の担保と向上をどうやったら目指せるか
どの様な機能開発を行うべきか…と言った、体験を設計するための探索や仮説検証の活動を、どうすれば断続的に続けられるのか
「特別困っているわけではないが、もっとより良い体験にできる」といった体験改善に、どのように取り組めば良いのか
上から順に、課題の詳細と解決策について書いていこうと思います。
スピードだけではなく、UI品質の担保と向上を目指すには
私自身は、モバイルアプリや顧客が操作をする管理画面といった開発経験がほぼない状態でタイミーに転職したため、UI品質の担保と向上に課題がありました。
そこで「UIデザインレビュー」を積極的に利用しています。
「UIデザインレビュー」はプロダクトデザイングループが、UI品質の担保と向上のために取り組んでいる一つのコミュニケーション形式です。
タイミーでは、開発チーム専任のデザイナーは基本的に1名のみなので、他のプロダクトデザイナーに相談する良い機会になっています。
ある程度形になったUIに対してFeedbackをもらうことはもちろんですが、1週間というスプリントに対応するためにも、構想段階から会話し、視野を広げておくことが有効だと考えています。
UI品質の担保と向上を目指しながらスピードも上げていく必要があるので、一人で考えすぎないことがポイントです。
そうすることで、より多くの検討が可能になり、より適切なUIの採用が可能になるのです。
体験を設計するための探索や、仮説検証の活動を断続的に行うには
スピードを追求しながら品質向上も目指せるようになりました。
しかし、これだけではまだ不十分です。
UIを考えるにあたって重要な、体験面のプロセスが抜け落ちているからです。
加えて、プロダクトオーナーの戦略や思想を言語化、見える化をする中で、共に最善を考え、そのビジョンや計画を具体化するためのアプローチも取れていません。
これが2つ目の課題（どのような機能開発を行うべきか…といった、体験を設計するための探索や仮説検証の活動を、どうすれば断続的に続けられるのか）です。
イメージしやすいように実際のリサーチの実例を挙げます。
例えば、開発の優先順位の意思決定のために、ユーザビリティテストを行ったことがあります。
その結果、本質的な課題が明らかになり、よりユーザーにとって大きな価値提供につながる改善策を見つけることができました。
その内容をチームの計画に反映したのです。
（詳細が気になる方は是非、以下の記事を読んでみてください）
このようなリサーチからUIデザインまでを、1週間というスプリントの中で行うことは可能でしょうか？
先ほど、実装に必要な時間を考えると1日〜2日程度で開発に必要なUIデザインを行うと書きました。
つまり1日〜2日程度でリサーチからUIデザインまでを行うということです。
不可能ですよね？
さらに、スクラムは短期間で開発を繰り返し学びを得ていくことで、複雑な問題へ適応することに特化したフレームワークです。
故に状況は日々変化し適応することが求められ、その度に必要な意思決定を迫られます。
UXリサーチに一定期間を費やしてから開発…という流れは思想に反していると感じます。
これらのことから、UIデザインの瞬発力はもちろんですが、UXの観点においても瞬発力が求められると言えるでしょう。
つまり、瞬発力を磨くための活動が求められており、そのためにはスプリントに関連する取り組みに注力するだけでは足りず、日々パラレルに動いておく必要があるのです。
しかし、スクラムである以上はチーム全員で、スプリントで定めたゴールの達成に向けて動く必要があり、スプリントに直接的な関連性が低い活動は行い難い体制でもあります。
これにより、やるべきだと考えているのに身動きが取れない！という状況に陥っていました。
そこで、まずは開発者として自分（デザイナー）の行動指針を言語化し、チームに共有することで少しでも理解を得られれば、より活動しやすくなると考えました。
このnoteも、その一環だったりします。
その上で、作業時間の確保など、現実的な問題に対して向き合っていきます。
タイミーの開発チームには、PMM（プロダクトマーケティングマネージャー）が基本的についています。
PMMとの連携を強化することで、自分一人で行うよりもより多くの情報や手法の選択肢を得ることができるでしょう。
分担が可能であれば、その分、自分の手も空きます。
理想に向けた体験改善に取り組むには
断続的なリサーチ活動も行えるようになってきました。
しかし、リサーチ活動から得た学びをもとに理想像を描き出せたとしても、理想に向けて一つずつ順に取り組めるかというと、そうではありません。
これが3つ目の課題（「特別困っているわけではないが、もっとより良い体験にできる」といった体験改善に、どのように取り組めば良いのか）です。
「特別困っているわけではないが、もっとより良い体験にできる」といった体験改善を、スクラムチームで取り組むことに、個人的に難しさを感じています。
もちろんチームの目標にもよりますが、ビジネスへの短期〜中期的な貢献という文脈では、自分自身その優先度を下げざるを得ないと感じることが多々ありました。
理由は大きく2つあると考えています。
理想像を満たすためのアイディア（改修や、追加機能など）が大きくなってしまい、開発単位として扱いにくい
よりビジネスインパクトの大きなテーマや緊急性の高い課題から扱うことが多く（日々、変化することもあり）、「困っているわけではなさそうだけど、本当はこうなったらもっと良いよね….」という温度感では優先順位が上がってこない
これに対しては、以下の3つのアプローチが有効かもしれません。
⑴ スクラムチーム外でプロジェクト化する
例えば、プロダクトデザイングループでの取り組みにしてしまえば、開発のサイクルや優先順位に捉われず「どうすればよりユーザーが満足する体験を提供できるか？」といった理想から考えた試作品を作成できるようになります。
そうして試作品を貯めておけば、より有効なタイミングで開発チームに提案できるようになります。
⑵ アイディアを、松→竹→梅 の順に削ぎ落として、最低限の改善を見つける
梅を考えたら案外すぐできることがわかり、サクッとやってしまおうという雰囲気になることもあります。
なにより、リスクを減らし複雑な問題へ適応しやすくなる（スクラムチームでも扱いやすい開発サイズになる）ため、梅の積み重ねで少しずつ理想に向けて進めます。
⑶ プロダクトゴールよりも先のビジョンを明確にする
理想とする体験に対して開発者がオーナーシップを持った状態になれば、体験改善の優先順位に対して、最適な意思決定を全員で行えるようになると考えています。
そのためにも、普段からユーザーの解像度といった情報の非対称性を失くす取り組みが求められています。
例えば、デザイナーがリサーチした結果を他の開発者にただ共有するのではなく、ワークショップを企画し共に結論を出したり、一緒にインサイトを見つけ出すといった工夫が考えられます。
先ほど「有効かもしれません」と書きました。
実は、これらは今日までの経験から考え出したアクションであり、まさに来年から取り組んでいこうと考えているアプローチだからです。
実際にできるのか….結果うまくいくのかはわかりません。
結果に関わらず、新しい学びを得られたら、またnoteに書いてみたいと思います。
まとめ
「どこまでもユーザーの味方であり、ユーザーの立場でものづくりをする」ためにはビジネス視点がより一層必要であり、プロダクトオーナーをどのようにサポートできるか、より大きな成功に向けたアシストができるか を、考え行動することが求められているとも言える
具体的なプロダクトオーナーへのアプローチは以下が考えられる
プロダクトオーナーと共に戦略を練る
プロダクトオーナーの視野を広げ、戦略の幅を広げる
チームの意思決定を助ける
スクラムチームの中で上記アプローチを取ろうとすると、以下の難しい面があった
スクラムである以上はチーム全員でスプリントで定めたゴールの達成に向けて動く必要があり、スプリントに直接的な関連性が低い活動は行い難い
「特別困っているわけではないが、もっとより良い体験にできる」といった体験改善をスクラムチームで取り組むことに、個人的に難しさを感じる
そこで来年は以下のトライをしていこう
スクラムチーム外でプロジェクト化する
アイディアを、松→竹→梅 の順に削ぎ落として、最低限の改善を見つける
プロダクトゴールよりも先のビジョンを明確にする
ここまで読んでくださり、ありがとうございました。
来年も頑張ります！それでは、お疲れさまでした。