以前関わっていたエンジニア10名程のスクラムチームで、デザインをエンジニア自身でやりつつ進めていくことをやってみたのですが、そこから分かった4つのアンチパターンを書きます。
- iOS/Androidのネイティブアプリをやっている
- デザイン=画面デザイン+画面仕様
- 使っているデザインツールはFigma
- デザインに関しては全員浅い経験
なお、最近のスクラムでデザインを取り入れるにあたって、デュアルトラックアジャイルのような手法（というか考え方？）が生まれつつあり、私自身がこの記事に書いたことに取り組んでいたときにはその存在を知りませんでした。なので、あくまで現場でもがいてみた記録として見ていただけると幸いです。
1. 片手間でデザインをやる
最初、エンジニアがデザインをスクラムの中でやることで、
- ちゃんと見積もりを付けてスプリントの中でうまいこと回せる
- エンジニア自身が考えた、実装しやすいデザインになる（かも）
と思っていました。
しかし実際には開発に追われる中でデザインをこなすことはなかなかに厳しく、特に全員が開発・デザイン両方をこなしていたので、デザインを片手間でやっている状況でした。
当然割ける時間が少ないので、細かい部分についての議論はなかなか出来ず、あくまで機能を実現するためのデザインの話にフォーカスしてしまいます。それはもちろん重要な事なのですが、全体的なデザインの統一感や細かい部分の使い勝手にまで議論の時間が回せず、良くないなと感じていました。また議論をしたとしても、結局全員デザインの経験が非常に浅いので、これが良い！っていう決定的な結論をくだせず、ずるずると議論が長引いて打ち切る事で仕様が決まるということがままありました。
片手間でデザインをやるのではなく、ちゃんと専任のデザインについて責任を持つ人が必要だな…と感じました。
2. デザインのタスクと、開発のタスクの見積もりを共通化する
スクラムのスプリントでタスクをこなすには、基本的には見積もりが必要だと思っています。エンジニアがデザインと開発両方を担うようにしていたため、見積もりを共通化していました。
開発には開発のリファレンスストーリーがあり、そこにストーリーポイントが付いています。デザインにはデザインのリファレンスストーリーがあり、そこにポイントがついています。
そこを共通化するには時間ベースで換算するしかありません。しかし、スクラム開発ではベロシティは変動します。つまり、開発のストーリーポイントが実際にどのくらい時間に換算できるかは常に変わっていきます。そこを常にデザインのポイントと同期しなければいけないわけですが、これはもうめちゃくちゃ面倒くさいですよね。
デザインのタスクに開発と同じ基準の見積もりを付けてスプリントに入れるのは個人的には良くない方法だと思っています。
3. PRのフローをなぞって、デザインのレビューもフローに落とし込もうとする
多くのソフトウェアエンジニアは、GitHubのPullRequestを用いた開発サイクルに慣れ親しんでいますよね。なので、デザインもそのフローに落とし込んでみようとしたのですが、罠がありました。
レビューがクッソ大変
Figmaを使っていたのですが、Figmaにはレビュー機能がありません。（最上位のプランならレビュー機能がありますが、めちゃくちゃ高いです）
ではどうしたかというと、Figma上でレビューのステータス（Approveしているか）を表示するコンポーネントを作って、変更箇所にぺたぺた貼り、Figma上で依頼を出してレビュー→コメント→修正→再レビューのサイクルを回していました。これが非常に大変でした。あるフィーチャーにまつわる画面を同時多発的に編集すると、どこをどういじったのかを理解するのがかなり難解になり、また仕様の部分のレビューも行っていたので、そこのやり取りも含めて兎に角コミュニケーションの手間が半端無い状況になっていました。
結果、フローはやめて皆で画面を見ながら会話でレビュー的なものを行うのが最も容易いという結論に至りました。
4. ガチガチにデザインを組もうとする
ソフトウェアエンジニアたるものコンポーネントの再利用性を意識して綺麗にFigmaの画面を組みたいですよね。Figmaの操作を理解してくると色々ガッチリ組みたくなるし、そのほうが後々プロトタイプとしても良いだろうという事で最初はガッチリやってました。
これは罠です。
綺麗に作ろうとすればするほどメンテのコストが跳ね上がっていき、途中で破綻するとそこで諦めるようになります。途中で諦めるのであれば、最初からそんなガッチリやらなくて良いわけです。Figmaもコンポーネントのインスタンスにコンポーネント入れ子にする事が出来なかったり、ソフトウェアエンジニア的な思考で階層構造を組む事が出来ないようになっています。
デザインの専任の人がいれば、徹底的にFigmaのデザインの組み方をリファクタリングして維持していけると思うのですが、最初にも述べた通り我々は片手間でやっていたのでその時間を捻出するのも難しく、そうそうに破綻してしまったのでした。
最後に
実はこの記事は前職の会社でのプロジェクトの話を書いたものです。今はもう離れてしまったので、その後チームでのデザインのフローがどうなったのかは全く知らないのですが、チームでもがいていた当時自分がどう考えていたかを整理するために記事を書きました。スクラム×デザインはまだまだフロンティアな領域だと思うので、またチャレンジする機会があればもがいてみようと思っています。ありがとうございました。