概要
今回は UX 系の記事を書いていこうと思います。
デュアルトラック・アジャイルという開発手法についてですが、簡単に言うと、アジャイル開発に UX を取り入れるためにの手法です！
UX というと、ウォーターフォールの要件定義部分で、カスタマージャーニーマップやペルソナを作ったり… というのを想像しますが、アジャイル開発では、開発するものが不確実なものが多いので、毎スプリントその作業をできないものです。
ではどうやってアジャイル開発に UX を取り入れていけばいいんだ？ということで、下の 「LEAN UX」という本を読んで見ました。
この本に登場した、「デュアルトラック・アジャイル」について少し語っていこうかなと思います。
今後、自分が所属しているプロジェクトでも導入してみようかなと考えているので、経験談についてはまた後日記事にしてみようと思いいます。
今回は、「デュアルトラック・アジャイル」とはこういうもので、こんな事に気をつけていきましょう！という紹介になります。
デュアルトラック・アジャイルとは
デュアルトラック・アジャイルは、２つのバックログを管理することを推奨しています。
一つ目は、「ディスカバリ・バックログ」と呼ばれ、プロダクトやサービスの可能性のディカばり、実験の実施、ユーザーのインタラクションを通じて、どのアイディアがさらなる探求に値するか、そうでないかを検討する。と書かれていました。要するに、UXリサーチ、UXデザインをするということだと思います。
二つ目は、「デリバリー・バックログ」と呼ばれ、ディスカバリからデリバリーの段階に進んだアイディアのみを開発する。と書かれていました。これは、スクラムを組んだいるアジャイル開発でいうとプロダクトバックログに値することかなと思います。
下図のように、ディスカバリ・バックログで上がった項目のUXリサーチやUXデザインを行います。そこで、これは開発するべきだという結論に至ったものに関しては詳細を詰めて、デリバリーバックログに移動させて、次のスプリントで開発していきます。正確には、必ずしも次のスプリントで開発するのではなく、デリバリーバックログで優先順位順に開発を勧めていきます。
次に、下図のように、デリバリー・バックログに追加された項目の開発が終わったあとは、それで終わりではありません！次のスプリントで、実装した機能がどのように使われているかなどの調査を行います。一度で完全にいいものを作るというのではなく、何度もサイクルを回してユーザーからフィードバックを得て修正していくというのが前提なので、調査を行って更に修正が必要になってくることもあります。
デュアルトラック・アジャイルアンチパターン
ディスカバリ・チームとデリバリー・チームを分ける
下図のようにスクラムチームの中で、更にディスカバリ・チームとデリバリー・チームを分けるというアンチパターンに陥ることがあります。
これの何がだめなのかというと、ミニウォーターフォールの用になってしまい、ディスカバリの結果をドキュメントで共有することになってしまうからです。そうなるとアジャイルをやっている意味がないですよね…
解決策としては、できるだけ多くの人がディスカバリに参加することが大事です。エクストリームプログラミングにあるペアプロを実施してみてもいいかもしれないですね。
ディスカバリ方法に関する知識不足
デュアルトラック・アジャイルというのは、ディスカバリの段階で、各項目に対してどのようなアプローチを取るかということの判断ができたりアプローチの引き出しが多いことが前提になってきます。
そうしないと、一個のアプローチのみを使えるようになって、いつもそれを使ってしまうということにもなりかねません。別のアプローチを取るべきなのに、そのアプローチを知らないがためにそうなってしまいます。
そんなときは、たくさん勉強して事例を学ぶというのも大事ですが、身近にリサーチの専門家がいれば相談すると良いでしょう。
デリバリーで得た検証結果や証拠をディスカバリ・バックログにフィードバックしない
これは、自分もそうですが開発者によくありがちで、要望された機能を美く実装できて特にエラーもでていないからOKといってそれで満足してしまうことが原因です。
UX は一発で解答を得られるのではなく、実装して実際に使ってもらったフィードバックでどんどん改善されていきます。
その考え方を前提にスプリントを進めていけば問題もなくなることかなと思います。
まとめ
以上で、デュアルトラック・アジャイルの説明になります。
自分もまだ実践したわけではないですが、これから実践して開発者兼UXデザイナーを目指していきたいと思います！
コメント