デザイナーはスクラムの中でどう生きるか？と正面から向き合ってみた
こんにちは！freeeでデジタルのプロダクトデザイナーをやっているryotakeです。最近はポケモンSleep引退で取り戻したはずの人生がポケポケに吸い取られています。
さて、2024年の自身の仕事を振り返ると、スクラムチームひいては開発生産性、ビジネスに対してデザイナーとしてどう貢献するかを模索し続けた1年でした。
というのも、複数のスクラムチームを掛け持ちし広く浅くデザインに責任を持つ立場から打って変わって1つのスクラムチームにがっつりとコミットする立場に変わってきたからです。
今回は、その中で模索してきたデザイナーとしての開発、あるいはプロダクトへの貢献の仕方を振り返りつつ書きます。結論、デザイナーやビジネスアナリスト（以下BA）の帽子を被り分ける「開発者」としてチームに貢献しているよという話です。
ちなみにこの記事はfreee Developers Advent Calendar 2024の15日目です。
スクラムチームへの関わり方のジレンマ
これまでの経験の中で、デザインという工程が開発全体の工程から独立してしまうことや、それが原因で認識ずれによるタイムロスや無駄なものを作ってしまうリスクが生じることに課題感を持っていました。
その課題感への対処として、
作り方の前に作るべきものを定義すること
デザインの工程を透明化し開発プロセスの一部とすること
を意識して活動してきました。これらは過去noteに書いています。
こういった動きに手応えを感じつつも、スクラムチームを掛け持ちし広く浅く関わっていく当時のスタイルには限界ともどかしさを感じていました。しかし一方で、組織の生産性としてはそのスタイルのほうがデザイナーとしての貢献度は高いのかな？という気持ちもありました。
なぜなら、毎スプリントで価値あるインクリメントを作成する責任を持つチームの中で、その一部分でしかないデザインを作る「だけ」の自分は1つのチームに狭く深く入り込むよりその一部分を複数担ったほうが組織の生産性としては高いのか？と思う部分もあったからです。
そんなことを考えていた初夏ごろ、ちょうど新規プロダクトを立ち上げるスクラムチームの1つにほぼ専念できる形でアサインされました。さらにこのチームではアジャイル開発にしっかり取り組もうということで外部のアジャイルコーチにも参与してもらうことになり、自身のジレンマに答えを出すまたとないチャンスがやってきました。
「開発者」としての考え方の転換
まず一番最初の転換点は自身は「デザイナー」ではなく「デザインという役割を担う開発者」というマインドです。
今回のチームはプロダクトオーナーを担うプロダクトマネージャーとプロダクトデザイナーが1人ずつに対してエンジニア・QAが15人いる構成 かつ 初めましてなメンバーも多い状況だったので、やはり無意識的に遠慮というか主導を任せるという面がありました。
実際、アジャイルコーチのyohさんからも「ryotakeさんは意識的か無意識的かわからないけど、エンジニア的にはどうですか？と線を引いて遠慮してるように見えることがあるよ」という指摘ももらっていました。
これまで散々デザインをデザイナーだけで抱え込まないぞ！という信条でやってきましたが、それでも開発全体の話となると逆に尻込みしている自分に気づきました。
そんな状況で「デザイナー」としてどう貢献していくかをアジャイルコーチや詳しい方に相談した時に言っていた「スクラムガイドの元ではデザイナーも等しく開発者でしかないよ」に終始するんだなということを知りました。
スクラムでは「開発者」という言葉を使っているが、開発者以外を排除しているのではなく、単純化のために使用しているだけである。スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。
この原則に対してコードを書く人なのか、デザインデータを作る人なのか、そんなことに差はないということです。
もちろんこれまでスクラムガイドや関連書籍を読んだりはしたことがありましたが、どことなく間接的な知識として捉えていたことに気づき、改めて「開発者」として責任を果たすべくスクラムやアジャイル開発と向き合いながら実践していくことになります。
アジャイルな「ビジネスアナリスト」という役割
そうして日々活動する中で具体的に担える役割として見えてきたのが、チームの中で「ビジネスアナリスト」という役割を担うことでスクラムの柱の1つである「透明性」を保つことです。
ビジネスアナリストとは、以下のように定義されています。
企業や組織、さらには顧客にとって本当に価値のあるもの、必要とされていることをステークホルダー（利害関係者）と一緒にその目的の背景からしっかりと掘り起こし、明確化していく一連の活動を担う役割
ざっくり言うと「要求に関する活動を主導する役割」です。アジャイル開発の中での具体的な活動としては、要求を分析してユーザーストーリーの作成を支援したりします。
元々去年のnoteに書いたような「まず何を作るか認識揃える」といった活動の延長線上にある役割で、「まず何を作るべきかを分析して明確化する」役割とも言えます。
これを改善するためにBAという帽子を被り、エピックに対して要求を分析する活動を主導して適切にユーザーストーリーに分割しそれぞれ透明性の高い中身の記述をしていくことで状況の改善を試みました。
具体的には、ビジネス要求に基づきユーザー要求をドメインモデルやユースケースモデルを用いたモデリングを通して分析していき、ユースケース記述の形で機能要求を受け入れ基準に記載するという手順を踏んでいます。（ざっくり）
こういった活動は幸い効果が出てきていて、プロダクトバックログやアイテムの透明性が向上しチームの誰がみてもわかりやすい状態になり検査のスピードが上がったりフィードバックを受けやすくなった他、先にQAがテストケースをかける形になってきたりするようになりました。
チームのクロスファンクショナルを向上させる
上記の活動を経て、エピックに対してきちんと要求を分析しストーリーの透明性を高める活動はチームの標準的なプロセスとして根付いてきました。
ここで新たに生じた問題が、標準的なプロセスではあるができる人が１人だけなのでボトルネックになってきたことです。実際、ユーザーストーリーの作成が遅れたり次のスプリントの用意ができなかったりしました。
スクラムでは不確実性に対処するためにクロスファンクショナルなチームを基盤としています。単一障害点となりかけていたこの問題を、できる人を増やす（＝チームのクロスファンクショナルを向上させる）ことでボトルネックの解消を目指すべくいくつかの取り組みを始めています。
取り組み① モブワーク
アジャイルコーチに開催してもらったモブプログラミングワークショップを経て、モブワークの高い学習効率を学びました。
それを応用して、分析のモデリングを行う際は自分以外のメンバーにドライバーを担ってもらいモブモデリングとして行うことでBAの役割を広げようとしています。
参考：
取り組み② Ready状態の定義
役割を担える人が増えても、それをいつ誰が着手したらいいのかはお見合いになったり本来の要求からずれたりします。その対策として、「どんな状態になればに進んでいいのか？」の定義をチームで進めています。具体的には以下の3つです。
エピックのReady（ストーリー分割の準備完了）
ストーリーのReady（実装の準備完了）
スプリントプランニングのReady（数スプリント先のストーリーの準備完了）
エピックのビジネス要求がどれぐらいPOの中で固まっていればストーリー分割を始めていいのかを決め、分割したストーリーは実装開始するためにどのように記述されているべきかを定めています。
また、「数スプリント先までのストーリーは常にできている状態にしたいよね」というチームの理想を実現するために、「いつ、どれくらい先までのストーリーがReadyになっているべきか？」のチェックポイントとしてスプリントプランニングのReadyも定義しています。
これによって、チームとして透明性の高いプロダクトバックログを維持し安定してインクリメントを作成できる状態を維持しようとしています。
参考：
まとめ
以上、「デザイナー」としてスクラムチームへの関わり方に悩み、最終的に「開発者」としてデザイナーやビジネスアナリストの帽子を被り分けながらスクラムチームに貢献する形を見出した、という話でした。
振り返ると最初は迷いに迷っていたスクラムチームが透明性、検査、適応の3本柱を学びながら実現できるようになってきているし、自分も「開発者」の1人として日々活動できている実感があります。
冒頭の、結局デザイナーはスクラムチームを広く浅く掛け持つのか狭く深く専任するのがいいのか？の答えは結局組織や事業、あるいは当事者の状況に寄るんだろうなと思いつつ、じゃあ専任したら価値を発揮できるのか？と言う部分にはある程度できると言える形というかマインドが見えてきた2024年だったなという所感です。
今回は自身が所属するスクラムチームの適応、自己管理の結果担ったBAという役割を書きましたが、これまた違うチームになれば違う役割を担うことに
なるかもしれません。
また、「正面から」ということでスクラムガイドに照らし合わせながら「開発者」あるいは役割として「デザイナー」「ビジネスアナリスト」を客観的に区別して明確にしてきましたが、主観的に振り返るとこれまでずっとプロダクトデザイナーとしてやってきたこととなんら変わりません。
要求を分析してモデルやユーザーストーリーを作成したりしている時もfigmaを使っている時も、今デジタルプロダクトをデザインしてるな〜という感覚は変わりません。
そう思うとやはり大事なのは「スクラムガイドの元ではデザイナーも等しく開発者でしかない」というマインドの部分で、スクラムチームの一員として適応していくことなんだろうなと思います。
まったく、プロダクト開発は難しくて楽しいですね。また2025年も頑張っていきたいと思います！