こんにちは。@toi_toi_yです。
サイボウズという会社でkintoneというプロダクトのデザインをしてます。

自分は数年前、kintone開発チームがスクラム開発を始めた頃にkintone専任のデザイナーとしてチームにジョインしました。
それから様々な変化がありつつもずっとスクラム開発のなかでデザイナーをやってきました。

というわけで、デザイナーとスクラム開発の話を書きます。
サイボウズのスクラム開発については弊社スクラムマスターの資料をご覧ください。

https://speakerdeck.com/ama_ch

kintone開発チームのスクラム（2019年現在）

- スプリントは1週間
- 開発チームはPG×3〜4人のサブチームが4つある
- デザイナーは1人（+ チーム外のデザイナーが手伝ってくれてる）
- 開発はモブプログラミングで進める。デザイナーも適宜必要に応じて参加する

きっとこれからも色々変わっていくと思いますが、現在はざっくりこんな感じです。

デザイナーは何をするの？

自分が普段やっていることは以下の4つです

1. プロダクトオーナーとプロダクトバックログを作る
2. PBIに必要なデザインを実装できるように仕上げる
3. 開発チームのUI実装を支援する
4. その他色々

デザイナーは開発チーム（の中のサブチーム）には所属していません。
プロセスの各所でPOや開発チームの各サブチームと関わります。

プロダクトオーナーとプロダクトバックログを作る

個人的にスクラム開発でのデザイナーの大事な役割No.1だと思ってます。
スクラムなのでプロダクトバックログがないことには開発が始まらないし、プロダクトバックログのクオリティは開発スピードとその品質に大きく影響するため、ここでデザイナーが力を発揮することにはとても意味があります。

自分は要件にきちんとしたデザインが必要かどうかは関係なく、プロダクトオーナーの考える要件を一番最初に視覚化して具体化します。
いわゆるプロトタイピングというやつです。
これには直近で着手するような小さな要件のプロトタイピングもあれば、将来着手するかもしれない大きな要件の長期的なプロトタイピングもあります。

プロトタイピングによって見えなかった部分が具体的になることで、バックログの精度が上がります。
ちなみにプロトタイプは作って渡すのではなく、それをもとにプロダクトオーナーと一緒に検討したりします（その過程でデザインの詳細も検討されます。デザインは機能の一部）。

この段階で作るプロトタイプでは細部のクオリティに気を配りません。最低限リファインメントできる精度（開発チームがこのバックログで何を作るか理解でき、見積もりができる）に留めます。
プロトタイプの詳細度はバックログによって変わりますが、実際の画面とほぼ同じ動作をするような精度の高いものを作ることもありますし、時には雑に絵を書いて終わることもあります。

バックログに必要なデザインを実装できるようにする

プロダクトバックログがReadyになったら、スプリントに投下されるまでにデザインを詳細化します。
バックログができてからスプリントに投入されるまでの期間はまちまちなので、そこはうまいことやります。
できるだけ今後のスプリント計画の議論に参加して、先々の見通しを立てておくのがポイントです。
最近はモブプロでUIを実装するようになったので、詳細なデザインスペックの資料（デザインをめちゃくちゃ精緻化して実装に必要な数値を全て書き出すとか）は作らなくなりました。

開発チームのUI実装を支援する

プロダクトバックログがスプリントに投入されたら、必要に応じて開発にも関わっていきます。
まずは開発チームとプランニングを一緒に行って、UIに関わる確認事項や不確定要素について認識を合わせます。
ここでデザインの意図なども伝えることで、実装する際の設計に関する議論をスムーズにすることができます。意外とデザイナーしか持っていない情報が実装に役立つことも多いです。

UIを実装する時はモブプロで参加して一緒に実装を行います。
以前はSketchで作ったカンプから、Zeplinなどのサービスを通じて詳細なスペックを書き出し、それをもとに実装してもらう…というやり方をしていたのですが、モブプロで一緒に実装する方が手戻りも少なく精度が高い、ということで今のスタイルになっています（みんなで一緒にFigmaのデータを見たらいいんだよの精神）。
実装時に判明した問題についてもデザイナーがその場にいれば、デザイン上のトレードオフはすぐに判断ができます（必要に応じてプロダクトオーナーもモブに呼んで判断してもらうけど）。
こうしたプロセスのおかげで「カンプをちゃんと作っても実装でおかしくなっちゃうんだよ！」みたいな悩みは皆無になりました。

その他色々

その他自分が得意なことでチームのためになることであればなんでもやります。この間はAppStoreとGoogle PlayStoreにだす画像を80枚ぐらい作ってました。
（なんでもかんでもやるってわけではない。重要度とライフワークバランスに基づく優先順位があります）

スクラム開発に適応したデザイナーって？

3年間やってきた感覚としては以下のことが意識できるデザイナーです。

- 完成にこだわらない
- 素早く作って素早く捨てられる
- デザイナーという職能に閉じない

完成にこだわらない

不確かな将来のために常に軌道修正していくプロセスがアジャイルなので、完成という状態にこだわらない姿勢が必要です。

スクラムのようなアジャイルのプロセスではデザインが完成するということがありません。一度理想の状態を定義しても、スプリントを回す間に変化していくのが普通になります。

ウォータフォールのプロセスのようにこれで完成！ やりきった！ という状態がないので、完璧を追求したいデザイナーには正直辛いかもしれません。
デザインは永遠に完成しない、でも改善のループはずっと続く。そんな感じです。

素早く作って素早く捨てられる

スクラム開発（というか多分アジャイル全般）だと作ったデザインを捨てていく場面も多くなります。デザインカンプを作ったとしても、実装コストや実際の挙動をみて柔軟に修正を入れていくので、結果的に当初とは全然違うデザインになることもよくあります。

なので、これだ！と決めて作り込みすぎると無駄が増えます（カンプに引きづられて実装のコストも増える）。先を見据えつつ、作りすぎない意識をしないとスクラムのスピード感でデザインしていくことが難しくなります。
実装してみてやっぱり違う、となったら次のスプリントでやり直すこともよくあります。

デザイナーという職能に閉じない

スクラム開発ではデザイナーは「デザイナー」という肩書のもとでデザインの番人になるよりも、プロセス全体の中でデザイナーとして持つスキルを活かしきるほうが活躍できる実感があります。

私はデザイナーだからデザインをすることが仕事であって、それ以外のプロセスには関わらない（関われない）、という考え方はとてもウォーターフォール的でアジャイルのプロセスとは相性が悪いからです。
なので自分は要件が実装されてユーザーに届くまで、自分がスキルを生かして貢献できそうなところのあらゆる場所に首を突っ込みます。

最近ちらほら「自分はデザイナーだけど開発の中で色々やっていて自分が何者かよくわからなくなってきた…」というお悩みを聞くことがあります。
もしそれが押し付けられたタスクではなく、自分が必要だと思ってやっていることならば、実はアジャイルのプロセスに適応した状態なのではないかと思います。

デザイナーが自分の領域に閉じていられないというのはある意味デザイナーとして成長しやすい環境とも言えそうです。デザインという自分の専門分野を中心に周辺のプロセスにも関わっていくことで、いわゆるT字型の成長が期待できるからです。

スクラム開発にデザイナーは必要だと思う

デザイナーがプロセス全体でスキルを発揮することで、バックログの精度が格段に向上できたり、間違ったものを作るリスクを軽減できたり、実装時の設計を手助けできたり、UI実装の精度をあげられたり...
デザイナーのスキルで開発プロセスを最適化できる可能性が色々あります。

まだ見ぬ機能を一番最初に視覚化できるデザイナーのスキルはスクラム開発にとってはとても大事なんじゃないかと思ってます。

まだまだデザイナーがスクラム開発のチームで価値を発揮する方法は知見が少なく自分も試行錯誤を続けています。
もし、自分はこうやってやってるよ！という知見のある方はぜひシェアしてくれると嬉しいです。

以上、自分なりのデザイナーとスクラム開発のお話でした。
今週もスプリントまわしていくぞー。

追記 2020 / 01 / 27
スクラムとデザイナーに関する記事を書きました！
全3回で連載予定です。