近頃、「スクラム開発」を取り入れるチームが増えてきたように思います。現在、サイボウズでも多くのチームがスクラム開発を実践しています。
最近普及してきたアジャイルソフトウェア開発手法のひとつです。言葉を耳にしたことがあるという方も多いのではないでしょうか。工程ごとに大きくフェーズがわかれている「ウォーターフォール」型の開発とは異なり、「アジャイル」型では、短期間で小さな開発と改善を反復しながらソフトウェアを開発していく方法です。
このスクラム開発はデザイナーにとっても無関係なものではありません。開発のプロセスが変わるということは、デザイナーの仕事もその変化に合わせて変えていく必要があるのです。そこで本連載では、「スクラム開発というプロセスに対してデザイナーがどう関わっていくべきか」についてお話していきたいと思います。
なおこの連載では、スクラム開発自体の詳細な解説は行いません。気になる方は、入門編として書籍『SCRUM BOOT CAMP THE BOOK』をぜひ読んでみてください。
本題に入るまえに、簡単に自己紹介をさせていただきます。
サイボウズでUX/UIデザイナーをしている樋田勇也（といだゆうや）と申します。サイボウズでは、「kintone」というクラウドサービスのプロダクトデザイン全般を担当しています。この連載では私が実際にスクラム開発に関わったときの実体験をもとにお伝えしていけたらと思っています。どうぞよろしくお願いします。
さて、初回となる今回は、デザイナーがスクラム開発に参加することにどのようなメリットがあるのかについて、お話していきます。
デザイナーの役割ってなんだろう
「デザイナーは開発チームの一員としてスプリントに参加するべき？ それともスプリントの外から関わるべき？」
「これまでと比べて期間がぐっと短くなったことでデザインを作りきれなくなってきた」
「最近エンジニアのチームがスクラム開発を始めたんだけど、デザイナーとしてどう関わったらいいかわからない」
最近、こんなデザイナーの声をよく耳にします。どうしてデザイナーは「スクラム開発」に戸惑うのでしょうか。
そのひとつの理由は、“デザイナー”の役割がはっきりと定義されていないことにあると思っています。プロダクトオーナーに近い立場で動くのがよいのか。開発チームの一員として関わるべきなのか。はたまたそれらとは違う立ち位置で動くべきか――。
『SCRUM BOOT CAMP THE BOOK』にもデザイナーと思われる人物が開発チームのひとりとして登場しますが、とくにエンジニアとは区別されていません。実際デザイナーの立場はさまざまで、エンジニアと近い役割を担うこともあれば、プロダクトオーナーのような立ち位置になることもあり、一概にこれ、と当てはめることは難しいでしょう。
では、スクラム開発におけるデザイナーの役割とは何でしょうか。ここで一度、スクラム開発とは何かを振り返ってみたいと思います。
Wikipediaにはこのように書いてあります。
「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」、「チームが自発的に組織だって行動することを可能にする」（出典：Wikipedia「スクラム (ソフトウェア開発)」より）
つまりこれによれば、デザイナーも柔軟かつ自発的に、共通のゴールに到達するための行動をすればいいということになります。
デザイナーの最大の武器は、言葉どおり、デザインできること。つまり情報を整理し、可視化できることにあります。この長所をスクラムのプロセスでどう活かせるかを考えることが、デザイナーの役割を見つけ出すヒントになりそうです。
デザイナーが参加することのメリット kintone開発チームの場合
ここで私が所属するkintone開発チームの例を紹介します。
メリット1：バックログの可視化
このチームにおけるデザイナーの仕事は、プロダクトオーナーのプロダクトバックログづくりを支援することから始まります。これはバックログができてスプリントに投入される前、つまりスプリントの外の仕事です。
基本的にkintone開発チームでのバックログは、その背景となるユースケースを示した「ユーザーストーリー」と、何を満たせば完成なのかを定義した「受け入れ条件」からなる、スプリント期間での開発チームへの要求事項を示したドキュメントです。スプリントの基点となるべきドキュメントなので、このバックログの質は非常に重要です。
デザイナーはバックログづくりを支援するため、プロダクトオーナーがバックログを考え始めた時から隣で一緒にプロトタイプを作ります。これは何かを検証するためというより、プロダクトオーナーが考えていることを具体化した青写真のようなものです。
デザイナーがそばで可視化することで、頭の中や文字情報だけでは気づけなかった考慮ポイントに気づくことができます。その結果、プロダクトオーナーはより正確に用件を検討することができ、バックログの取捨選択や優先順位づけなど、スプリントにバックログ投入するために必要なあらゆる判断を下すことができます。
