スクラム開発におけるデザイナーの役割 − 経験からの学びとアイデア

こんにちは！Experience DesignチームでUI/UXデザイナーをしている澁川です。今回は規定通りにきっちり進行する正統派のスクラム開発にデザイナーとしてはじめて参加した経験から得た学びとアイデアを共有します。

スクラム開発でのデザイナーの関わり方と役割

スクラム開発について説明をすると長くなってしまうので、ここでは省かせていただきます。
また、アバナードでの取り組みについては「Be Agile - ビジネスの変化に対応するために」で紹介されています。

アバナードではScrum.orgとパートナーシップを提携しており、スクラムをベースとした独自の開発フレームワークを持っています。このDigital Innovation Studioでもアジャイルでの開発を基本としており、いくつかのプロジェクトがスクラムで行われています。

スクラム開発ではデザイナーの役割が厳密に定義されていません。

スクラム開発の手法を一部取り入れたプロジェクトの経験は何度かあったので、開始当初はなんとかなるだろうと気軽に考えていましたが、いざ動き出してみるとスクラムのフレームワークの中でどう立ち回ればいいのかわからず心が折れそうになりました。
そして調べるほど世界中のデザイナーがいかにこの問題について同じように悩み、解決策を模索してきたかを知りました。

用意された正解がなく自分なりに見つける必要があることがわかったので、私がまず行ったのはシンプルに「デザイナーが果たすべき役割」を考え、サイトマップの作成やワイヤーフレームへの落とし込みなどやるべきことの実施でした。
そして振り返りのイベントであるレトロスペクティブの場でうまくいかなかった点を共有してチームで解決策を検討する、という方法で自分がうまく機能する場所を探し調整しました。
結果的に3スプリントほどかけて次のような立ち位置を確立できました。

■ 開発チームに属さない

デザイナーは全体像を見据えて一貫したユーザー体験を検討する必要があり、スプリントで必要な一部機能からデザインを着手するのは難しいです。

最初のスプリントでは開発チームの一員として同時に作業をスタートしたため、スプリントに対応するデザインとしてどこまで含めるべきか、作成したデザインをどのタイミングで開発チームに連携すればいいのかという点で悩みました。

また、デザイナーを開発チームに含めてしまうと後続スプリントの見積もり時間が正しく出なくなるという問題もあり、以降はデザイナーは開発チームに属さず動くことになりました。

これによりスプリントの枠に収まらずにデザイン検討ができるようになって非常に動きやすくなりました。

なお進行中に「デュアルトラックアジャイル」という近しい（ですがより高度な）開発手法があると知りました。次にまたスクラム開発で進行するプロジェクトに携わる機会があれば実施を検討したいと思っています。

■ プロダクトオーナーと開発チームの橋渡しをする

開発チームに属さずプロダクトオーナーの近くで動くことになり、抱えている課題を解決するために最適なUX/UIを可視化できる形で提案、検討するといったデザイナー本来の役割が果たしやすくなりました。

しかし同時に限られた時間で最大限の価値を生むために、開発の実現性を開発チームに確認しながらデザインすることも重視しました。

他にも先行して確認した仕様を整理して開発チームに共有するなど、開発がスムーズに進むようにサポートするのがスクラムにおけるデザイナーの重要な役目だと考えています。

なお、個別に動くことで開発チームとの連携ミスや認識齟齬が発生してしまったことがありましたが、デイリースクラムの後に毎日デザイン確認の時間を確保してもらったことで共有や質問が容易になり非常にありがたかったです。

よりスムーズに進行するためのアイデア

プロダクトオーナーと開発チームの橋渡し役として動いている中で、スクラム開発を円滑にすすめるには何よりもコミュニケーションが大事だと実感しました。
そして適宜適切なコミュニケーションをするためにチャットやコールといったツール面だけではなく意識面の整備も必要だと思いました。

そこでここからは「こうすればもっとうまくいくのでは」というアイデアを共有します。

■ チーム全員が共通認識を持つ

今回のプロジェクトではクライアントがプロダクトオーナーでした。
「自社/顧客の課題を解決するためのプロダクトを開発する」という目的は同じですが、状況によってはワンチームではなく発注側と受注側として関係が相対してしまうこともありました。

「仲良しこよし」を目指す必要はないですが、力関係がないオープンでフラットなコミュニケーションによって問題の発生を未然に防ぐこと、早期発見して影響を最小限にすることはスピード感が必要なスクラム開発に不可欠です。

では仲間意識を高めるにはどうすればいいでしょうか。

考えていた際に思い出したのは中高時代の体育祭です。
私の学校は学年対抗戦だったのでチームメンバーは250人ほどいましたが、仲の良さや関係性の深さは関係なく、250人がまさに一致団結していました。
なぜ大きな集団が団結できたのかを考えると、「優勝」という明確な同じ目標を全員で共有していたためだと思い至りました。
優勝できたのかできなかったのか、結果はさっぱり思い出せませんが、普段から仲の良い友だちだけではなく一度も同じクラスになったことのない同級生とも一緒になって優勝を目指して熱狂したことや、チームに貢献するために苦手な早起きをして朝早く学校でみんなと練習した記憶は強く残っています（自他ともに認めるかなりの運動音痴なので必死でした笑）。

これをスクラムチームに置き換えた際、共通認識として何を目標にするかというと「自社/顧客の課題解決」です。

体育祭の優勝ほどわかりやすく単純な目標ではないので、「なんのためにそれを作るのか」という目的、「なぜその機能が必要なのか」という背景を全員で解像度高く共有する必要がありますが、これによりメンバー全員が同じ方向を向くことができ、ワンチームとして機能していくと思います。

■ そのためにワークショップを取り入れる

目的や背景について細部まで認識を合わせるには個別に資料を読み込むよりも全員が同じ場に参加して会話する方が効率的です。

また、最初に共通認識として全体像を作ることで開発の優先順位付けや必要機能の洗い出し、そしてデザインが容易になります。

その解決策として計画段階や検証時にはワークショップを活用することが有効ではないかと考えています。

ワークショップについては「ワークショップがビジネスの現場にもたらす効果」で詳しく紹介されていますが、

・体験の共有・一体感の醸成
・能動的な参加
・高い創発性
・速いスピード

といった利点はどれもスクラム開発には効果的で、さらに同時にチームビルディングができればコミュニケーションもより促進されるのではないでしょうか。

おわりに

明確に役割が定まっていないということはデザイナーやデザイナーを組み込むことのできる会社ならではの強みや特色を発揮する余地でもあると思います。

同じように悩んでいる、またはこれからスクラム開発に参加するデザイナーの方や、スクラム開発にデザイナーを入れようと検討しているスクラムチームの方々にとって少しでも参考になれば幸いです。

■ ご紹介した関連記事