1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

1人でアジャイル開発やってみる(ユーザーストーリーマッピング編)

Posted at

前回はインセプションデッキをメインに行いました。
今回はユーザーストーリーマッピングの作成とペーパープロトタイピングを行っていきます。
スクリーンショット 2022-02-08 000212.gif

ユーザーストーリーマッピングとは

ユーザーストーリーマッピング(以下USM)とは、プロダクトに関するユーザの体験を時系列と優先度に沿ってマッピングしたものです。
「どんな機能を作るのか」ではなく、「ユーザにどんな体験を提供するのか」を考えるためのもので、UX(ユーザーエクスペリエンス)の向上を図ることができます。
また作成したUSMを元にプロダクトバックログの作成とリリース計画(どこまでを初回リリースに含めるか、など)を決めます。

USMを作ってみた

実際に作ったUSMが以下の通りです。
1行目の青い付箋はユーザーストーリーの大分類です。今回は「事前準備」「会議進行」「会議後」の3つに分けています。
2行目の黄色い付箋がユーザのメインアクションです
3行目以降がユーザの詳細なアクションです。ここに挙げた付箋がバックログになっていきます。このエリアは「MVP」と「Backlog」というエリアに分かれています。MVPはMinimum Viable Productの略でユーザに価値を提供するために最低限必要なものとなります。通常、MVPに上がっているものを初回リリースの対象とします。(今回の1人アジャイルではMVPが完成する前からリリースはしちゃいますが。)

なお以下の点は筆者の勝手な拡張ですので一般的なUSMとは異なります。
・付箋の色によって利用者を分けて表現しています。通常、利用者が異なる場合はUSMを別に作ります。その方が視点の異なるユーザ体験をより深堀できるからです。実際に今回作ったUSMは会議の進行者のユーザ体験に重きが置かれている感が少しあるかもしれません。
 ただ筆者はUSMを分けるとつながりがわからなくなるので1つのボードで表現しています。そしてボードがある程度できたら「次は会議参加者の視点で見直そう」といった形で頭を切り替えてみるようにしています。
・システム化の対象には赤いタグをつけています。その方が見やすいので。

無題.png

 ちなみに・・・。アイスブレイクの目的は会議参加者の気持ちをほぐすことなので、最も大事なのは会議進行者のユーザ体験ではなく、会議参加者のユーザ体験です。しかし会議参加者が利用する機能はほぼMVPに含まれません。これは会議参加者までサイトを開いて入力するような方式だとワイワイガヤガヤとしたアイスブレイクにならないと考えたからです。大事なのはUXであり、それはイコール提供する機能にはならないということですね。

ペーパープロトタイピングとは

 その名の通り、紙でプロトタイプを作成することです。Figmaなどのデザインツールを使うのと違って圧倒的に早い・安い・手軽なことがメリットです。数分で作って、数分で直すことができます。時間をかけていない分、ダメ出しもしやすいし受け入れやすいです。ただ所詮は紙なので十分なフィードバックを得られないこともあります。とは言えアジャイル開発ではスプリントごとに動くプロダクトを見ることができるので、要求の分析では過剰な作りこみは必要ないですし、ペーパーでやるのがちょうどいいと思います。
 なお注意が必要なのが画面のラフ画ではなく、「プロトタイピング」であるということです。「ユーザが使いたくなるプロダクトになっているか」「ユーザ体験はUSMで作ったものでいいのか」「バックログの優先順位はこうすべき」などフィードバックを得ることを目的としていることを念頭におかないと、UXではなく細かいUIの指摘になってしまうこともあります。

ペーパープロトタイピングしてみた

作ったのは以下の通りです。

####アイスブレイク一覧画面
 今回はリスト型ではなく、画面を4ブロックに分けて表示するような形式にしました。最初はリスト型にしたのですが、そうするとそのアイスブレイクの良し悪しを判断するために詳細ページが必要になるため操作が面倒になるのでこの形式にしました。
 またこのプロトを見たときに、事前に何も準備せずにこの画面を開いて、参加者と一緒に今日のアイスブレイクを何にするか決めてもいいかなと思いました。ただ今回のプロダクトは毎日の会議での利用をメインに考えているので5分程度のベストだと思います。そう考えるとみんなで決めるところまでは少なくとも現状はいいかなと思いました。ある程度プロダクトができてきたら、どのアイスブレイクにするか決めるところからやってみて感触を見るのもよさそうです。
スクリーンショット 2022-02-10 215744.gif

####アイスブレイクを行う画面(ジェスチャーしりとりゲーム)
 最低限のルール説明とお題を出せればよいかと思います。ただわくわく感はほしいのでお題はドラムロール的なので出したいですね。
 画面共有で行うことを考えると文字はかなり大きく表示したほうがよさそうです。そうすると情報量は極力削りたいです。やはり会議参加者がこのページを見て回答も入力するというは避けた方がよさそうですね。
スクリーンショット 2022-02-10 215805.gif

####アイスブレイクを行う画面(スポーツクイズ)
 利用をイメージしてみるとなんか淡々と進行されそうな気がします。4択になっているがよくなさそうですね。みんなに回答を聞いても「私はAかな」「Cっぽい気がします」程度の会話しか生まれない気がする。
 それよりは選択肢なしである程度考えるものにしたほうが会話が生まれそうな気がします。もしくは複数回答式のクイズ(例えば”山”がつく都道府県は?とか)にして会議参加者全員で全問正解を目指してもらうとかがよさそう。
スクリーンショット 2022-02-10 215824.gif

プロダクトバックログに転記する

USMとペーパープロトタイピングを通して上がったバックログは以下の通りです。
スクリーンショット 2022-02-10 232541.gif

終わりに

 今回はUSMとペーパープロトタイピングを行ってバックログの一覧を作成しました。USM、ペーパープロトタイピングに共通して言えることで作ることが目的ではなく、ユーザの体験を高めることが目的です。そしてその目的を達成するためには固い打ち合わせをするのではなく、ワイワイガヤガヤ、あーでもないこーでもないとみんなが発言し、みんなが楽しむのが不可欠です。ぜひ実践する際は気を付けてみてください。
 次回はSprint0ということで開発準備を行っていきます。バックログに上がっていなかったので技術調査、開発環境構築、完了の定義作成というバックログを追加しました。なお開発のバックログと準備作業は分けたかったので、準備作業のバックログは紫にしました。
image.png

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?