うちのスクラムチームとデザイナーの関わり方

どうも @shutooike です。スクラムチームでPOをしています。

今回はスクラムのコミュニティの飲み会でも結構盛り上がるスクラムチームとデザイナーの関わり方について、うちのチームのやり方をつらつら書いてみます。

チーム体制の変遷

1. スクラムチームとデザイナーチーム分離型

チームの取り組むタスクが不具合修正や機能改善中心であまりデザインを必要としない時期は、必要に応じて都度デザイナーチームに依頼する形を取っていました。

リソースの兼ね合いや取り組むタスクの性質上この進め方は最適だったと思う反面、同じチームではないので相互理解が浅く、互いの意図が伝わらないなどコミュニケーションの問題が発生することがありました。

2. POからデザイナーに依頼型

チームの開発が新機能中心になってからは、デザイナーがチームに専属する形になりました。

「次のスプリントまでにこういうデザインが必要なのでお願いします」とPOから依頼し、デザイナーは開発者が行うスプリントとは別軸で動きます。

デザイナーはスクラムチームの一員ではありつつ、どのロールにも当てはまらないふわっとした存在でした。

3. デザイナー開発者ロール型

こちらは検討はしましたが、やらなかったです。

きっかけはデザイナーが「自分だけスプリントゴールを追えておらずチームとしての一体感がない」と話してくれたことでした。

デザイナーの役割について改めて考えた結果、デザイナーの仕事はデリバリーではなくディスカバリーにあり、デリバリーの責任者である開発者としてチームに無理やり組み込んでもスプリントゴールが分散してしまうという結論に至りました。

4. デザイナーとPOはニコイチ(現在)

3の検討した結果、改めてデザイナーとPOの仕事はディスカバリーだという共通認識を持てました。

すると、今までの2の進め方はデザイナーがデザインを受託するような形になっていて、ディスカバリーにオーナーシップを持てていないことに気がつきました。

そこで現在はデザイナーとPOはセットでディスカバリーを進めていこうとしています。

スクラムイベント

現在は以下に落ち着きました。

  • スプリントプランニング: PO, 開発者, SM, デザイナー
  • デイリースクラム: 開発者, SM
  • スプリントレビュー: PO, 開発者, SM, デザイナー
  • レトロスペクティブ: PO, 開発者, SM, デザイナー

POとデザイナーが担うディスカバリーの仕事はデイリースクラムのような定期の場は持たずに、必要な時にすぐ話すスタイルをとっています。


またうちのチームでは上記のイベント以外に、デザインレビューというMTGが行われています。

これはスプリントレビューで細かいデザインの指摘をせずに済むようにという目的で、いつの間にかスプリントレビューの前日にデザイナーとフロントエンド開発者で開催されていたMTGなのですが、実際手戻りが激減しているのでとてもいい取り組みです。

デザイナーが困っていたこと

レトロスペクティブの話題が開発者メインになってしまう

チームの大半は開発者かつPOの僕も開発者出身なので、開発者のトピックは毎度白熱します。

その時デザイナーは蚊帳の外となってしまい、別の作業をしていることも多々ありました。

この状況に対してはチームでは

  • 飛び交う言葉は開発用語だったとしても、上手くいっていない原因はコミュニケーションやプロセスに起因するものが多い
    • これはPOとデザイナー間や、開発者とデザイナー間でも活かせる
  • デザイナーという立場からチーム内で起きた問題を捉えて、プロセスの改善などを検討する

という結論になりました。

レトロスペクティブでデザイナーが書くことがない

ふりかえりのネタを探すためにデイリースクラムに参加するという事象が発生していたこともありました。

開発者と同じようなふりかえりを出す必要はなく、デザイナーとしてやったことやチームとの関わりの中で出てきた良かったこと悪かったことについて、ふりかえったらいいですよという話になりました。

おわりに

特にオチはないです。

正解はないので色んなチームの話が聞いてみたいです!