こんにちは、コインチェック株式会社のデザイナー兼プロダクトマネージャー中川です。
2024年7月よりデザイングループのリーダーを担当しています。
当社では現在、様々な部署でスクラムを取り入れたプロダクト開発が行われており、デザイングループもスクラムチームと協業する方法を模索し、実践することが求められています。
この記事では、私が直近の３ヶ月で実践してきた、デザイナーがスクラムチームとご機嫌に付き合うための環境づくりについてご紹介します。

なぜ環境づくりが必要だった？

私がリーダーに就任した時、デザイナーがスクラムチームと本格的に協業し始めてから約半年が経過していました。ちょうど、スクラムチームとデザイナーの働き方に関する課題が各所で議論されはじめ、以下のような課題が顕在化していました。

デザインがスプリントの障害に

当初からスクラムチームには担当デザイナーがアサインされていましたが、デザインタスクはバックログ達成に向け必要な場合にのみ、プロダクトオーナーや開発者から個別に依頼されていました。
デザインタスクはスクラムチームのスプリントバックログに含まれず、デザイン組織のタスクとして切り離されており、他プロジェクトとの間で優先度が衝突する状態も発生していました。
その結果、デザインスケジュールとスプリントのタイムボックスの足並みが揃わず、開発者に手待ち時間が生じていました。

デザイナーが上流工程から遠ざかり、短期的な施策が増加

デザイン依頼が開発直前になると、ユーザー体験やプロダクトの一貫性を考慮した施策が不足し、目先の問題や短期的な成長への視点に偏りがちでした。
デザインの検討時点で、前後の体験の繋がりや根本的な改善点を見つけた場合でも、既にスプリントバックログに組み込まれた施策が優先されます。
そのため、まずは目の前のデザインを要求通りに仕上げることが求められ、デザイナーが上流部分に積極的に関わることが難しくなっていました。

要求整理や仕様検討の手戻りが発生

UIの作成に着手すると、要求が不十分であったり、仕様の検討が不足している部分が浮き彫りになり、作成したデザインの調整や手戻りが頻繁に発生しました。こういった状況が重なると、作業時間がどんどんずれていき、計画どおりに進まなくなります。
デザイナーが要求定義に関わっていなかったり、ワイヤーフレームなどで情報設計や導線設計を全体的に整理せずにUI作成を行う状況が発生したことが要因と言えます。

デザイングループとして取り組んだこと

上述した課題はスクラムチームと一緒に働くデザイナーの中には、同じような経験をされている方もいるのではないでしょうか？
スクラムではプロダクトオーナー、スクラムマスター、開発者という3つの役割が定義されていますが、デザイナーの働き方や役割については明確な定義がされていません。そのため、各デザイナーやデザイン組織がスクラムチームとどのように働くべきかを柔軟に考え、模索することが重要です。
私たちのデザイングループでは、デザイナーがスクラムチームと積極的に関われる環境を作るため、以下のような取り組みを行いました。

デザイナーの役割を定義する

はじめに、スクラム開発の中でデザインが価値を発揮できる部分を考え、デザイナーの2つの役割を定義しました。

1. スプリントバックログの作成、インクリメント（成果物）の作成

1つ目は開発者としてスプリントバックログの作成とインクリメントの作成の役割。
成果物であるプロダクトの具体的なUIを通して、プロダクトのユーザー体験の維持・向上や世界観の統一など全体的なデザイン品質に最終的な責任を持ちます。
この役割はUXの5階層における表層・骨格に位置づけられ、ビジュアルデザイン、UXライティングなどのスキルが活かされます。

2. プロダクトオーナーの支援、プロダクトバックログの作成

2つ目はプロダクトオーナーの支援者としてのプロダクトバックログを作成する役割。
プロダクトビジョンやアイデアの見える化をユーザーストーリーの作成やプロトタイプの作成を通して行い、スクラムチームが取り組むべきプロダクトバックログの明確化に責任を持ちます。
UXの5階層における、要件・構造・骨格の部分に相当するもので、デザイナーが持つUXリサーチやUXデザイン、IA（インフォメーションアーキテクチャ）のスキルを活かしチームに貢献します。

スクラムチームとの協業当初、デザイナーは主に１つ目の役割でしか関われていませんでしたが、実際はデザインがスクラム内で貢献できるフェーズや機会はもっとたくさんあることを認識することができました。

デザイナー独自の目標をチームの現状に合わせて設定する

次に、目標設定の方法を見直しました。
見直し前はスクラムチームが持つ目標をデザイナーが一緒に持つ形でしたが、ユーザーの利用率や口座開設数などデザインだけではコントロールできないことも多く、主体性が生まれにくい状況でした。
そのため、デザイナーはスクラム内でどのように活躍したいかを考え、それぞれのチームの現状に合わせた目標をデザイナー独自で設定するという形に変更。
例えば、ビジョンに対して具体的にやることが定まっていないチームでは、プロダクトオーナーの支援とプロダクトバックログ作成のためのプロセスを目標として設定（目標A）。逆に、ビジョンに対する仮説や施策案が比較的見えているチームであれば、スプリントバックログの作成と完了数を目標として設定しました（目標B）。
見直し後の目標では、デザインメンバーの各自の行動が直接的にスクラムチームの活動に繋がりやすくなり、デザイナーからチームへの働きかけが必然的に行われるようになりました。

会議体をデザインする

最後に、デザイナーがスクラムチームの一員として働きやすい環境を整えるため、会議体のデザインを行いました。
デザイナーがスクラムイベントへの参加だけでなく、定例会議やデザイングループのデイリーミーティングに参加することで、縦（スクラムチーム）と横（デザイナー間）の繋がりを相互に持ちながら働ける工夫をしています。

1. スクラムイベントへの参加

スクラムイベントはスクラムチーム内で検査と適応のための場です。スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといった各イベントはそれぞれ、目標設定、日々の進捗確認、成果物の評価、継続的な改善を促進します。
スクラムチームのベロシティの安定化や質の高いアウトプット提供のために、デザイナーも同じ空間で情報を共有することが効率的と言えます。
現状、デイリースクラムについては開発タスクとデザインタスクの粒度や時間軸が異なっていることから、デザイナーの参加は任意とし、別途、同期の時間を設けているチームがあるなど、例外もあります。スクラムチームごとの状況に合わせて柔軟に運用は変更しつつ、最終的にはデイリースクラムへの参加も他開発者と同様に必須にしていけるといいと考えています。

2. スクラムチーム内のデザイン定例会議（週1-2回 / 各30分）

スクラムチームに複数デザイナーがアサインされている場合、スクラムチームのデザイナー内でのタスク分担や作業進捗の確認、場合によってはその場でペアデザインを行うなど、フレキシブルな場として設定しています。

3. デザイングループのデイリーミーティング（週5日 / 30~50分）

スクラム活動とは別にデザイングループ全体でのデイリーミーティングの時間を設けています。
この時間ではスクラムという垣根を超えて、作成したデザインのレビューやデザイン原則/ガイドラインの整備、デザインシステムのアップデート、目標進捗の確認、ナレッジの共有を実施しています。
機能やプロダクト単位で分担されるスクラムチームではカバーしきれない横の連携を行うことで、デザインの一貫性担保や各所で発生する類似の議論や作業をまとめて効率化することができています。

3ヶ月後の今、どうなったか？

3ヶ月経過した現在、ビジョンや理想の具体化、デザイン作業の定量化など、スクラムにデザイナーが貢献するためのポジティブな取り組みやコミュニケーションがいくつか生まれています。

一方で、新たに見えてきた課題もあります。

目標設定については、バックログの作成粒度や定義が曖昧で、スクラムチームごとに解釈の余地が残る点があり、定量的な観測指標としての課題があります。
また、スプリントのタイムボックス内でのタスク消化に追われる状態は引き続き発生しており、場合によってはデザイナー自身も短期的な視点に集中せざるを得ない状況も発生しています。

今後はこれらの課題に対して、前述した2つの役割ごとの完成の定義を明確にしたり、2つ目の役割（プロダクトオーナーの支援、プロダクトバックログの作成）の実行プロセスを整理することでスプリントのタイムボックスに縛られない動き方を可能にしていきたいと考えています。

おわりに

この記事ではスクラムチームとデザイナーの関わり方を改善し、デザイナーが主体的にスクラムに関われるようになるための活動を紹介させていただきました。
活動を通してデザイナーがスクラムチームのメンバーとして、積極的にスクラムに関わる機会は増えましたが、デザインが活躍できる形はまだまだあると考えています。
今後も定期的な改善と振り返りを継続し、スクラムチームとデザイナーのご機嫌な関係を模索し続けたいと考えているので、こんなやり方おすすめだよ！うちはこうしてるよ！など、みなさんの実践経験からのヒントもあれば、教えていただけると嬉しいです。
この記事が、スクラム開発に携わる皆さんにとって少しでもお役に立てれば幸いです。
お読みいただいてありがとうございました。