スクラムプロジェクトでの「意図を伝える方法」を考えてみる
はじめに
先日までスクラムプロジェクトに携わっていましたが、参画当初は<b>作りたいものは一緒なはずなのにいざ出来上がるとPOやステークホルダーから「ここはこうしてほしかった」「ここはこうなるとは思わなかった」みたいに言われる</b>ことが多かったように思います。
今になって考えてみると、お互いに上手く意図を伝えることができてなかったように思います。
今は意図を伝えられる手段を身に付けたので当初よりは格段にお互いの認識がずれないまま開発を行えています。
スクラムやアジャイル的な開発に慣れているチームは当たり前にやっていることだとは思いますが、画面デザインや仕様を固めながら開発を進めていくことにお慣れていなかった私みたいな人もいると思うので、スクラムじゃなくてもすぐに実践できることを整理して記事にしてみます。
なぜ認識がずれるのか
スクラムチームにおいて、POと開発チームは「同じものを作り、同じものを実現する」ことを目標としていると思います。
では、なぜ認識がずれるのかというと<b>ロールが違う</b>からです。
POは何を実現したいかを考えているし、開発チームはどうやって実現するかを無意識的に考えているはずです。
<b>同じものについて話し合っているのに考えていることが違う</b>ので、会話の中ですり合わせられない部分が発生し、認識がずれたままになってしまいます。
そこで、異なるロールを持つメンバーが認識を合わせつための方法を何点か紹介します。
文章で伝える
5W1Hを持ったユーザーストーリー
スクラムプロジェクトであれば、まず思い浮かぶのがユーザーストーリーだと思います。
ユーザーストーリー | 例とテンプレート | Atlassian
↑の説明では、
ユーザーストーリーは、「ペルソナ + ニーズ + 目的」としてよく表される開発タスクです。
とありますが、一般的には
- 誰が
- どんな目的のために
- 何をしたい
といったことが記述されます。
このフォーマットに則って
「<b>営業マン</b>が<b>商談で使用する</b>ために<b>物件情報を閲覧</b>したい」
といったユーザーストーリーを作成しても良いですが、POと開発者がさらに共通認識を持つためには<b>5W1H</b>を意識すると良いです。
「<b>営業マン</b>が<b>日中</b>、<b>営業所内で</b>の<b>商談で使用する</b>ために<b>iPadを使用</b>して<b>クライアントと一緒に物件情報を閲覧</b>したい」
といった内容のユーザーストーリーにすることで、
- 営業所内でクライアントと一緒に閲覧するのであれば営業マンが説明したい項目の文字は大きくした方がいい
- iPadを使用して閲覧するので物件画像はフリックでのスライダー表示ができるといい
- PC、スマートフォンでの表示調整は優先度を下げることができる
など、認識合わせの材料にもなりますし、優先順位の判断基準を作ることもできます。
プロジェクトの形式上ユーザーストーリーを作成しない場合でも、5W1Hを意識すると意図を伝える助けになります。
イメージで伝える
ペーパープロトタイピング
イメージで伝えると言っても、方法が何種類かあります。
新規サービスを立ち上げる時は、「ペーパープロトタイピング」がよく使われると思います。
読んで字の如くですが、紙とペンを使って表示したい画面や挙動を表現することで意図を伝えます。
先述したユーザーストーリーはこういう場面でも活きてきます。
5W1Hを図で表現してすり合わせることができると、文字だけで意図を伝え合っていた時の数倍はお互いの認識が合います。
最終的に表示される画面を想像してすり合わせるので当然といえば当然ですが・・
キャプチャ
昨今はリモートワークが主流となっておりチームで集まってペーパープロトタイピングをする環境も機会も少なくなっていると思います。
そんな時は画面イメージをサクッと作るか簡単な挙動を実装してしまってキャプチャで認識合わせをしてしまいます。
画面イメージは主にdraw.ioを使って作成しています。
draw.ioがモックアップとか作成するのに便利だった件 - Qiita
文字の大きさや色などはこの時点で大体すり合わせられます。
ちなみに私が一番強力だと思っているのは<b>実際の挙動をGifで連携</b>することです。
具体的な方法はこちらで紹介しています。
WindowsでGifキャプチャを作成できる「ScreenToGif」がめちゃくちゃ便利
最終的な画面イメージをそのまま見せられるのでフィードバックももらいやすいです。
最後に
意図を伝える方法を整理してみましたが、いざ方法を整理してみると<b>意図を伝えることも手段で、目的は意図を反映したシステムを作ること</b>であることがわかりました。
POは<b>開発者へ意図を伝えることによってシステム上で何を表現して欲しいのか</b>、開発者は<b>POは何を表現して欲しくて意図を伝えているのか</b>を常に考えることが重要なんだなと思いました。
Discussion