デザイナーとスクラム

この記事は[レコチョク Advent Calendar 2021](https://qiita.com/advent-calendar/2021/recochoku)の8日目の記事となります。


はじめまして！アイドルとアカペラが大好きな岡です。
株式会社レコチョクで、WebやアプリのUI/UXを担当しています。


今回、既存サービスのフルリニューアルにスクラムが導入されて、デザイナーとして参加しました。
そこで自分が行っていることと初めてスクラムに参加した感想について書こうと思います。

私が感じた内容が中心にはなりますが、すでにスクラムを導入しているデザイナーの方はもちろん、今後スクラムを取り入れようとしている方の何かの参考になれば幸いです。

## スクラムとは
まずはじめに、すでにご存じの方も多いとは思いますが、簡単にスクラムの紹介をしようと思います。
スクラムとは、アジャイル開発の代表的な手法の1つです。
「チームでの仕事を円滑に進めるためのフレームワーク」などと紹介されることが多いです。

![Scrum.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2298495/36377f22-f905-d217-5d82-d4dafb00d2b7.jpeg)



「スクラム」と聞くと、大体こんな感じのイメージをする人も多いのではないでしょうか？そのイメージ通り、ラグビーの「スクラム」が語源になっています。
ラグビーに限らずですが、スポーツではチームの連携が大切ですよね。また、メンバーそれぞれポジションや役割が決められています。同様に、スクラムの特徴のひとつに「チームワークの重視」が挙げられ、メンバーごとに役割が与えられます。

### 役割
メンバーの役割は以下の3つであり、原則兼任はなく、全員がどこかに属することになります。

- プロダクトオーナー(以下PO)
開発チームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持ち、方向性の意思決定などを行う。
- 開発者
開発者は開発チームの⼀員であり、POの意向に沿って開発を進める。開発の進め方は自由。
- スクラムマスター
全体の調整役として、POや開発チームが抱える課題の解決に取り組む。スクラムチームと組織において、円滑に進むような支援をする。

### 進め方
1. POが、開発が必要な機能に優先順位をつけて記述する「プロダクトバックログ(以下バックログ)」を作成
1. 各スプリントにおいて、優先順位が高い項目から開発チームが1スプリント内での目標を設定する
1. 1スプリントごとに、開発チームが動くソフトウェアを作成しPOが評価する

スプリントとは短い一定サイクルのことです。一般的に1スプリントは1週間〜4週間で、今回は「1スプリント＝1週間」で行いました。1スプリントの中で1〜3を行い、それを繰り返して開発を進めていきます。



## デザイナーとしてやっていること
デザイナーのスクラムへの関わり方はそれぞれだと思いますが、私が普段やっていることは、主に以下の4つです。

1.  POが作成したバックログを他の開発チームのメンバーより先に確認
1.  バックログの内容を踏まえてワイヤーフレームを作成
1.  詳細なデザイン検討・UI作成
1.  開発チームの実装サポート

場合によって、デザイナーは開発チームには所属しないという考え方もあるようですが、今回は所属する方針で進めています。
しかしPOとの確認作業なども多くあるため、完全に開発チーム内だけに閉じず、臨機応変に立場を変えながら動く形となっています。

###  1.POが作成したバックログを他の開発チームのメンバーより先に確認
開発チームが開発に入る前のバックログを数スプリント先まで先に確認し、内容をPOとすり合わせるということを行っています。この段階では、画面として必要な機能の抜け漏れが発生しないよう心がけています。
デザインイメージが存在しないことによる開発全体の遅れを防ぐために、基本的にデザイナーは数スプリント先まで進んでおく場合が多いようです。

### 2.バックログの内容を踏まえてワイヤーフレームを作成
POとすり合わせた内容をもとに、画面単位でデザインに起こします。ワイヤーフレームレベルのものです。ワイヤーフレームの作成後はPOに共有し、POが考えるユーザーストーリーと相違がないかの確認を行います。場合によっては、各画面での動きや画面遷移について一緒に検討したりもします。

この段階では、1画面をしっかり作り込むより、複数画面の土台を作るイメージです。ですので、この時点では高いクオリティを目指すよりも、スピード感をもって画面のイメージを作っていくことが大切だと考えています。

### 3.詳細なデザイン検討・UI作成
続いて、ワイヤーフレームの段階では考慮しきれなかった、細かい箇所のデザインを確定していきます。プロトタイプレベルにしていく感覚です。主に、配色やフォント、各アクション(画面タップ、スライドなど)を実行した際に画面としてどのような動きになるかなどをこの段階で検討しています。

その他には、イレギュラーパターン(エラー表示や0件表示)の洗い出しやデザインも、必要に応じて行っています。この段階で「開発チームがバックログとプロトタイプを見てどのようなものを作るかの理解が可能である」レベルのクオリティになることを意識しています。

ここまでは、POとの確認作業やすり合わせがメインです。

### 4.開発チームの実装サポート
いよいよ開発に入ります。ここからは開発チームの一員として、デイリースクラムや様々な話し合いの場にも参加します。主にUIに関わる確認事項をこちらから投げかけることもあれば、開発を進めるにあたっての不明点を質問されることもあります。
実装上で問題が見つかった場合、デザイン的な内容であれば私が判断し、仕様に関わる内容はPOに伝える、という流れで進めています。

## 4つの他に行ったこと
基本的には上記の4つですが、「ダイアログやエラーなどの文言作成」や「App StoreとGoogle Play ストア用の画像作成」なども行いました。
デザイナーは関われる範囲が広いため、決まったタスクだけこなしている場合のほうが少ないのではないでしょうか。後述しますが、私は開発の中で生まれる追加タスクの中で、自分ができそうなことは積極的に引き受けるようにしています。

## ぶつかった壁
ここまで、自分がやっていることを書き出してみましたが、当然うまくいかないこともたくさんありました。
今回、デザイナーという立場で初めてスクラムに参加してみて、困ったことや悩んだことは大きく以下の3つです。

- デザイナーとしての自分の立ち位置がはっきりとわからなかった
- スクラムの過程ではデザインの「完成」がない
- 作成したデザインが変更される場合も多くある

### デザイナーとしての自分の立ち位置がはっきりとわからなかった
最初にぶつかったのは、「自分の役割がはっきりとはわからない」という感覚でした。私と同じように「デザイナーとしてどのようにスクラムに関わるべきか」悩む人も多いと思います。その理由のひとつに「デザイナーとしての役割が明確に定義されていない」ことがあると思いました。開発チームの一員となってよいのか。よりPOに近い立場で動く方がよいのか。

実際にスクラムにおいてデザイナーは、エンジニアと近い役割になることもあれば、POのような立ち位置に立つこともあるようで、これといった正解はありません。

ここで私は、スクラムとは「チームでの仕事を円滑に進めるためのフレームワーク」であることを思い出しました。
つまり、デザイナーも明確な立ち位置というものはあまり意識する必要はなく、チーム開発が円滑が進むための行動をすればよいということになります。
それから私は、自分ができそうなことや得意なことにはできる限り積極的に関わっていくようになりました。

### スクラムの過程ではデザインの「完成」がない
2つ目に感じた難しさは「完成」がないということです。私が入社以来関わってきたプロジェクトでは、ある程度のクオリティのデザインを「完成」として、原則「変更はない」状態で開発チームに渡すという流れで進めていました。
しかしスクラムでは1スプリントごとに、より良いプロダクトのために軌道修正をし、変化をさせていくという考え方が当たり前になります。
この点に関しては正直私も慣れていませんが、「完成」という形にこだわるのではなく、より良いデザインにしていくための「改善」を常に続けていく意識が必要だと思います。

### 作成したデザインが変更される場合も多くある
2つ目の内容に関連しますが、仕様の変更が発生した場合などに「確定」だと思っていたものも変更になる可能性が十分にあります。開発したものの実際の挙動を見て、想定していたデザインと違うものに修正するという経験をしたことがある方も多いのではないでしょうか。
ですので、手戻りや無駄な作業が発生することを防ぐために「作り込みすぎない」ことが大切だと思いました。

## まとめ
ここまで振り返ってみると「デザイナーはスクラムに向かないのではないか？」と思われるかもしれませんが、そんなことはないと思います。
バックログの精度を上げられたり、実装のイメージをする際の手助けをできたり、UI実装の精度を上げられたりなど、デザイナーがプロセス全体に関わると、開発を円滑に進めるためのきっかけをいくつも作ることができるからです。

しかしそのためには、「デザイン」という領域内に閉じず、状況に応じてPOとも開発チームとも細かくコミュニケーションをとることが大切だと学びました。

とはいえ、デザイナーとしてのスキルを最大限に発揮できる関わり方については、まだまだ模索中です。
そこでまずは、バックログの精度のさらなる向上のために「バックログの作成から積極的にPOと話し合い、関わっていく」ということから試していきたいと思っています。
その他にも、自分はこうやるとうまくいったよ！という知見がある方はぜひ教えていただけると嬉しいです！


以上、新卒3年目のデザイナーが初めてスクラムに参加したお話でした。
最後まで読んでいただきありがとうございました！

明日の[レコチョク Advent Calendar 2021](https://qiita.com/advent-calendar/2021/recochoku) は9日目「今年度上半期で感動した学びBest3」です。お楽しみに！

## 参考記事
[【解説】スクラムとアジャイルの違い](https://www.learningtree.co.jp/blog/news/%E3%80%90%E8%A7%A3%E8%AA%AC%E3%80%91%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%81%A8%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%81%AE%E9%81%95%E3%81%84/)

[なぜデザイナーもスクラム開発に関わるべきか 参加するメリットをサイボウズのデザイナーが解説](https://creatorzine.jp/article/detail/583)

[スクラムガイド](https://scrumguides.org/download.html)

この記事はレコチョクのエンジニアブログの記事を転載したものとなります。

https://techblog.recochoku.jp/7961