見出し画像

スクラム開発でのデザイナーの働き方と心がけ

🙋‍♀️ このnoteはこんな人におすすめ

・スクラムっていまいちなんだかわかってないデザイナー
・スクラム体制をとっているチームに配属されたデザイナー
・明日からスクラムで開発するよ!って言われたデザイナー

***

こんにちは。
業務用アプリのデザイナーをしているまいまい(@rotr9) です。

私のチームではスクラム開発をしています。スクラムについて定義された本はたくさんあれど、その中でデザイナーがどう動くかは定義されていないことが多いですよね?

曲がりなりにも1年間、スクラムの中のデザイナーとして働いてきて、「これがあるべき姿なのかな?」と思える型ができてきたので、今日はそんな実例を紹介したいと思います。

スクラム開発とは

スクラムはアジャイル開発手法の一つで、
先に要件を全て定義してから開発を行うウォーターフォール型とは異なり、
実情にあわせて要件ややり方を柔軟に変更していくスタイルです。

スクラムの特徴
①スプリントという一定の期間毎に動くソフトウェアを作る
 ②要求はプロダクトバックログという優先順位付けされた一覧表に保管される
③各スプリントにおいてその時点での優先順位の高いバックログ項目を基本に、開発チームがスプリント内で開発できる目標を設定する
④スプリント毎にバックログへの項目の追加や優先順位付け、動くソフトウェアの評価はプロダクトオーナーという役割の人が行う

引用:https://www.ogis-ri.co.jp/column/agile/agilescrum01.html

スクラムの全容については、The Scrum Guideなどをご参照ください。

弊チームのスクラム開発は

・ 1週間スプリント
・ 開発1〜2チーム
・ PO、デザイナー各1名

で行っています。

スクラム下のデザイナーの動き方

スクラム下でのデザイナーの主な仕事は、
プロダクトオーナーと協業して、
開発チームに卸すプロダクトバックログアイテムを生産すること
です。

機能の大小によって多少の差はありますが、以下のようなフローで行っています。

1. 開発優先順位を決める
2. ユーザーストーリーマッピングを行う
3. プロトタイプを作る
4. プロトタイプを用いてユーザビリティテストを行う
5. エピックを作成し、デザインを仕上げる
6. リファインメントにかける

※ PO:プロダクトオーナー、D:デザイナー、T:開発チーム

1. (PO)開発優先順位を決める

プロダクトオーナーがビジネス要件か開発リソースを勘案し、
次にどの機能のプロダクトバックログアイテム(PBI)を作成するかを決めます。

2. (PO&D&T)ユーザーストーリーマッピングを行う

PBIを作りこむ前に、ユーザーストーリーマッピング(USM)をチーム全員で行います。全員で行うことで、全員で行うことで、、ユーザー理解が進みます。USMはオンライン付箋のMuralを使って行うことが多いです。

情報が足りなくてUSMを行えない場合は、事前にユーザーインタビューを企画し、ユーザーの業務の解像度を高めます。USM中に疑問点が出てきた場合も、同様にユーザーインタビューを企画します。

3. (D)プロトタイプを作る

USMをもとに、情報を整理し、必要であればオブジェクトの洗い出しやモデリングを行い、ワイヤーフレームやペーパープロトタイプを作成します。

実際に目に見えるものを作るとアラが見えるようになるので、POとすり合わせ、修正を行います。

4. (PO&D)プロトタイプを用いてユーザビリティテストを行う

3でできたプロトタイプの精度を高めるために、ユーザービリティテストを行います。ユーザービリティテストを行います。実際の業務がこのプロトタイプで回るか実際の業務がこのプロトタイプで回るか設計に使いづらい点はないかを検証します。

5. (PO)epicを作成する+(D)デザインを仕上げる

プロトタイプの筋が良さそうであれば、それをもとにPOはepicの作成を始めます。同時にデザイナーはデザインに落とし込んでいきます。

POの書いたPBIと、デザイナーの作ったデザインが揃えば
一旦のお仕事は終了です。

6. (PO&D)リファインメントにかける

準備できたPBIは、リファインメントという形で開発チームに共有され、開発目線も入れてレビューが行われます。

修正があれば修正し、なければポイント見積もりされ開発チームに卸されます。


上記の流れで特に重要なのは、2〜4のプロセスです。
「ユーザー理解」と、「機能の可視化」はデザイナー主導で行っています。

心がけていること

上記のようなスクラムのフローの中で、心がけていることは3つです

1.デザイナーは瞬発力よく可視化する
2.デザイナーはPOの片腕
3.デザイナーはデザインに責任をもつ

1.デザイナーは瞬発力よく可視化する
PBLの品質は開発スピードに直結します。全員の認識が揃い、早い段階で問題を発見できるように、瞬発力よくものごとを可視化することがデザイナーには求められます。

USMを作るのはもちろん、業務フロー図を作ったり、手書きのプロトタイプを作ったりします。

2.デザイナーはPOの片腕
デザイナーはPOの考えを整理し、具現化し、形作っていく役目があります。デザイナーはいわばPOの片腕です。

そのためにはPOの考えが理解できる土台を作っておく必要があります。
具体的にやったことは、以下の3つです。

・スクラムについて知る
・POの仕事について知る
・会計について知る

スクラムや、POの仕事について知るために「INSPIRED」「ジョブ理論」「エッセンシャルスクラム」あたりは読んでおくことをおすすめします。


3.デザイナーはデザインに責任をもつ
当然ですが、デザイナーはプロダクトのデザインに責任があります。
デザインからみた正解、開発からみた正解、ビジネスからみた正解はそれぞれ違います。

それらを総合的に判断するのはPOの役目なので、
臆せずにデザインの正解を打ち出していきましょう。

かくいう私も「ものわかりのいいデザイナー」の顔をしてしまっていた時期がありました。ビジネス要件や開発要件を鑑みた上でBランクのデザインを作るのは簡単だし、余計な波風を立てずに済みます。

けれど、デザインで課題を解決できるのはデザイナーだけです。
ユーザーの本質の課どれだけ寄り添えるかを意識すべきです。

さいごに

スクラムはどんどん仕組みをアップデートしていく開発スタイルなので、
デザイナーも柔軟に変わっていく必要があると思っています。

・うちはこうしてるよ!
・もっとこうしたほうがいいよ!
・この本読んだほうがいいよ!
などあれば、お気軽にコメントかメッセージをいただけると嬉しいです。


読んでくださりありがとうございます🙇‍♂️ よければサポートよりTwitterでのシェアをお願いします!)