デザイナーがスクラム開発とうまく付き合うには
株式会社トクバイでデザイナーをしている吉井 (@hrtk441) です。
ちょっと前にFigmaをつかったチーム開発の記事を書きましたが、今日はデザイナーとスクラム開発の付き合い方について書きたいと思います。
というのも僕自身それなりの期間、スクラムを採用する開発チームのなかでデザイナーとして働いてきました。
なんとなくですが僕の感覚として、スクラム開発はエンジニアなどの職種に関しては教科書的なものが多くある一方、デザイナーがどうそこのプロセスに入っていくかというのはあまり知見が共有されてない印象があります。
もちろんチームによって多種多様なやり方があり、うまく回っているところも多いと思うのですが、
・スプリントタスクをうまく消化しないといけない...
・開発スピードを止めるボトルネックになってはいけない...
こういった悩みは割とあるあるなんじゃないかと思います。
僕も最初はそんな思考に陥り、なんとか流れについていくだけで精一杯でした。
今はスクラム開発のチームからは少し離れているのですが、これまで試行錯誤してきたことについて、今後の自分や、同じ悩みを持つ誰かの役に立つかもしれないと思いメモ程度に公開してみます。
お読みいただけるなら
・自社サービス開発(アプリ)における事例です
・2週間で1スプリント(≒1アップデート)のサイクルとしていました
・チーム構成は多少入れ替わりや追加もありますが大体以下の通りです
・ディレクター 2名(PO含む)
・デザイナー 1名(僕)
・エンジニア 5名(Android 2, iOS2, サーバサイド1)
・完全な教科書通りというわけではなく、多少なりアレンジを加えたスクラムという感じです
・僕自身スクラムマスターでもなんでもないので微妙に間違った理解もあるかもしれませんがご容赦ください
あと、明確な定義をしていたかというとそうではないですが、デザイナーの役割として個人の意識では
・アイディアをスピーディーに具現化し、チーム内での共通認識を作る
・デザインアウトプットとユーザー体験に最終的な責任をもつ
上記のように置いていました。
では本題について早速見ていきましょう。
デザイナーがスクラム開発とうまく付き合うには
いきなりですが、一番初めにコツを一言でいうならばこれです。後手に回らない。これに尽きます(スクラム以外でもそうかもしれませんが)
僕自身、スクラム開発を導入していたチームに途中からジョインした立場ですが、当初はやりたい施策はもう固まっていて後はデザインができれば実装します、みたいな状態でした。(デザインができていないのにスプリントバックログに積まれていた)
思い返すと当時は全体のスピードを止めないために「わかりました、なんとかします」と言いながらも、エンジニアの手を止めてはいけない…この流れを壊してはいけない...という焦りにより結構しんどかったなあという記憶があります。
でもそれも結局は後手に回ってしまっていたからで、そうならないためにどうプロセスを変えてきたのか、という内容について学びを綴っていきます。
1. 全体の状況を見渡せるようになる
「〇〇の施策をやることになったのでデザインを作って欲しい」
前述の状態ですが、個人的にはこうなっている時点で厳しいです。
それをやる目的や、議論の経緯もある程度主体的に把握しておかないと
「あ、そうじゃなくて…」
「あ、そのパターンはもう考えたんですけど…」
「あ、そうなんですけどまずはここからやりたいと思っていて...」
みたいなコミュニケーションロスが往々にして発生します。
またそもそものアイディア自体が微妙でもそれが既にスプリントバックログに乗ってしまっていたりすると、
なんかもうとりあえずやらざるを得ないっぽいからやらねば...
みたいな空気に飲みこまれてしまいます。
もっと違う方法があるのでは、と考えようにも議論を重ねているうちにどんどん時間がなくなり、どんどん自分の首が締まってきます。
それを防ぐには、やや抽象的ですがチームやプロダクトを取り巻く状況を俯瞰しやすい状態に自分を置くことが大事です。
全部を細かく把握しようとすると逆に疲弊しますが、役割としてもただデザインを作るだけの人にはならない意識を持つのが大切だと思っています。
チームとしてどの方向を向いていて、どういう段階で何をやろうとしているのか、直近どういう動きがありそうなのかはMTGに呼んでもらう、インプットが欲しいと声をあげるなどで早い段階から全体像をしっかり掴んでおくべきだと思います。
2. ひとつ先のスプリントを見越して動く
僕たちの開発チームではスプリントバックログをひとつ先のものまで見る形で運用していました。
GitHub IssuesとProjectsを使ってカンバン運用しているのですが、それを隔週で、PO・テックリード・デザインリード(僕)の3名で整理整頓(リファインメント)していました。
ここでは、アイディア段階でまだ具体像が見えていないが優先度の高いIssueを「仕様・デザイン検討タスク」として1つ目のスプリントバックログに含めておきます。
そこで主に要件を詰め、2つ目のスプリントで精緻な工数見積りが可能な状態まで具体化しておくといった運用です(ここだけウォーターフォールっぽい形式かもしれません)
要件を詰める(≒アイディアを可視化する)のは基本的にはデザイナー・ディレクターが主体ですが、実際のデータを見ながらプロトタイプを進めたいときには少しエンジニアにも入ってもらったりしていました。
何をどう作るか、が曖昧にしか認識統一できていないと「詳細わかんないけどまあこれぐらいだろう」と想像で工数を見積もられてしまいます(そしてその通りに済むケースは多くない)
実際の経験としてもそういったケースが度々ありましたが、先にしっかり要件を固める手法にすることで、想像仕様による見積もりミスや、それにより変な制約がかかることはかなり減ったような気がしています。
またこの方法には他にも以下のようなメリットもありました。
・デザインをじゃじゃ〜んとお披露目されたエンジニアから「なんかすごいボリュームのやつきた...」と思われることがなくなる
・先行してエンジニアから技術的なアドバイスをもらう機会を作れる
・粒度が大きいIssueは「まずはここからやるとよさそう」というMVPに向けた議論を早めに始められる
・エンジニアの手を止めてはいけないというプレッシャーから解放され、焦って間に合わせのデザインを作ることがなくなる
事前にやることを決めておく、というのは当然のことかもしれませんが、しばらく同じチームで仕事をしているとなんとなくの雰囲気でも進めることもできてしまいます。
しかしなんとなくではなく、ちゃんとデザイン検討のプロセスを踏んだり計画を立てたりすることも必要です。
デザインドリブンでも、データドリブンでも、事前検討をちゃんと固める時間を持っておくことはとても大事だなと感じています。
3. こまめに確認する
デザインもできてるしもう後は実装を待つだけだ...というとそうではありません。
いざ実装が進んでくると「なんか思ってたんとちがう...」となったり「おおお、そのケース考えてなかった...」ということもしばしばです。(未然に防げるように網羅的なケース考慮はしますが、それでも起こるときは起こります...)
すると今度はその対応を考えたり、それが決まらないとリリースできない、という状態になってしまいます。
そこで僕たちのチームではそれを最小限に防ぐため、変更内容はPullRequest単位でテストビルドを配信し、デザイナーが変更点について実機確認するなどこまめなチェックを行っていました。
ほかには、具体的な話や進捗共有がしやすいよう、チーム全体での朝会はやらないようにしていました。
全体で話すと思いのほか話が散漫になったり、共有内容の粒度が大きくなって具体的な課題に気づけなかったりしたからです。
代わりに施策の担当者単位でミニチームを作り、そこでデイリーの朝会を行うようにしたり、ある程度モノができたらミニチームでテスト確認会を実施するなど、自立単位や確認単位をわりと細かくしていました。
ミニチームの朝会、テスト確認会ではバグの発見や改善など次にやるべきissueの洗い出し・その優先度づけを先行して行っていました。
それによりデザイナーとしても、思いもよらない対応に思いもよらないタイミングで時間を取られることが減ったと感じています。
4. やりにくいことはすぐに声をあげる
これまではスプリント最終日のレトロスペクティブで、この2週間何があったかを思い出しながらKPTを行っていました。ただ、なんとなくお分かりかと思いますが2週間何があったかを人間の頭で思い出すのはかなりしんどいです。
僕自身スプリント中にこうしたらよかったかもな〜とか、これKPTで話そうかな...とぼんやり思ったことがあっても、ちゃんとメモを取ってなかったりでレトロスペクティブまでに頭から揮発してしまうことがよくありました。
そこで、僕たちのチームではKPT botを使って何か思いついたときにSlack上で
P: ◯◯が☓☓で△△だった
とつぶやくとGoogleスプレッドシートにそのまま転記される仕組みを導入しました。
(参考: https://qiita.com/ohbarye/items/73e3ccdaa25b3cba8aa9)
良いプロダクトを生み出すため、チーム運営をより良くしていくにはProblemがたくさん出されるほうが健全です。カジュアルに意見を出せる環境を作ることにより、デザイナーとしてやりにくいところ、逆にエンジニアなど他職種からデザインに対する意見もサッと集約されるようになりました。
(勿論良いことがあったときにはKeepとして称賛しやすくもなりました)
レトロスペクティブではそれを振り返りつつ、次に繋がるより良い道筋をみんなで探ることでチーム運営の質がグッとあがったように思います。
実際ここまで述べてきた内容についても、このKPTを繰り返しながらチーム開発の在り方について、デザイナーの立場からも声を上げて改善を重ねてきた内容だったりします。
5. さいごに
スクラム開発のような短いイテレーションサイクルが続くと日々のタスクが小さな改善にとどまり、大きな課題感を意識しにくくなることがあります。そこはチーム全体でタスクをうまく分解しつつ、中期的なテーマに一歩ずつ取り組んでいく、ということも同時に意識しておきたいポイントです。
さらに僕自身も経験がありますが、デザイナーもスクラムをうまく回していくことだけが目的になり、そこだけに満足してしまいがちだったりします。
それも大事ではありますが、デザイナーとして新しい価値を自ら生み出していけるよう、自分の力量やスピードを見極めながら、新しいアイディアに取り組める余白を積極的に空けておく勇気も必要だなと思っています。
思ったより長くなってしまいましたが、こちらからは以上です。
この記事が気に入ったらサポートをしてみませんか？