ユーザーストーリーと制服
先日「アジャイルひよこ」の集まりでユーザーストーリーについて短いお話をさせて頂きました。初歩的な内容ですが、分かりやすいと比較的好評だったのでここで共有したいと思います。
今回は3つ挙げたポイントの第1点、ユーザーストーリーと制服について。
ドラマや映画でありますよね。悪者が警察官とかガードマンの制服を着てどこかへ忍び込み、犯罪を犯す、というくだり。
ですが、
「警察官の制服を着たらその影響で悪者が急に改心した」
という流れは殆どありません。
どんな制服を着ていようが、それによって着ている人の中身が変わるなんて、普通では起こりえないですから。
「そんなの当たり前でしょ?」
と思っているあなた。
もしかして、その当たり前を忘れてユーザーストーリーを書いたり受け入れたりしていませんか?
ユーザーストーリーもやっぱり、制服を着せるだけではダメなんです。
ここで制服と呼んでいるのは、あの有名なユーザーストーリーのフォーマットのことです。
<誰:ユーザーの役割>として
<何かの機能>が欲しい
何故なら、<理由>だからだ
このフォーマットという制服に収めただけでは、中身がユーザーストーリーになっているとは限りません。
制服だけ着せている極端な例を見てみましょう。
プロマネとして、
開発するシステムの詳細定義が欲しい。
何故なら、クライアントに説明するのに必要だから。
立派にユーザーストーリーの制服を着ていますが、中身はどうでしょう?
これって要するに、ウオーターフォール式の詳細要件定義をプロマネ用に書いてくれ、という内容じゃないですか?😰
これではアジャイル精神とは正反対の内容で、ユーザーストーリーにはなっていませんよね。
ユーザーストーリーを上手く書くのはかなり大変で、アジャイルを結構経験した人ですら簡単には出来ないことです。
ましてやまだ経験の浅い方々は、ちょっと油断すると、
「このフォーマットになっていればユーザーストーリーになっている」
という錯覚に陥りやすいので要注意。
では制服の中身を充実させるには、どうすればいいのでしょう?
まずは制服、つまりフォーマットが持つ意味をしっかりと一歩掘り下げて考えてみることです。
ユーザーの役割 | どのエンドユーザー、ビジネスユーザーに役立つことか |
何かの機能 | どんなビジネス機能を支援するのか |
欲しい理由 | それによってどんなビジネス効果があるのか |
具体的に、制服を着ただけのユーザーストーリーを、一歩掘り下げて書き直して見ましょう。
制服を着ただけの例:
支社のシステムとして、
毎日朝1時に前日のトランザクションを1つのファイルにまとめて本社のサーバーへ転送したい。
何故なら、本社での集計プログラムに入力するから。
これにはあれこれ問題点がありますよね。
- 「支社のシステム」という役割のエンドユーザーは存在しない。
- 本社サーバーへのファイル転送がどんなビジネス機能を支援するのか述べていない。
- 集計プログラムに入力することはビジネス効果を説明したことにはならない。
つまりこれでは、構築するシステムの機能を説明しているだけで、どのエンドユーザーの仕事の内容とどう関係あるか、どんなニーズがあって何を解決したいのか、については触れていないのです。
このような書き方は、特に既存のウオーターフォール式のシステム定義やユースケースからユーザーストーリーへと書き直す場合によく起こります。すでに定義したシステムがユーザーにとって価値がある、という大前提に基づいているので、知らないうちに中身を吟味せずに制服だけ着せてしまうわけです。
上記の例を一歩掘り下げて考えてみると、実はこういうユーザーストーリーへと書き直すべきなのかも知れません。
書き直した例:
本社の会計部担当として、
毎朝6時までには支社の前日のトランザクションをすべて入手したい。
その日に本社としての集計に使うから。
これではっきりしたのは、ユーザーが欲しいのは、
「その日の仕事が始まる前に、前日の会計データを支社から入手すること」
だということです。
本社サーバーへひとつのファイルとして転送される云々は、あくまでも欲しいデータを入手する手段であって、このユーザーが重視していた機能とは言えません。
さらに、本当に把握すべきなのは「毎朝6時までに」というビジネス要求であり、システム設計として決めた「毎日朝1時」ではないことにも注目しましょう。
ユーザーストーリーは、システム設計を別のフォーマットに落としたものではありません。
制服を着せるだけでなく、内容の吟味と分析をお忘れなく。
これからはユーザーストーリーを書いたり受け取ったりする機会には、まず考えてみましょう。
「これって本当にユーザーストーリー?それとも制服を着せただけの偽物?」
それでもなかなか上達しない、あるいはもっと効率的に上達したい、と思う方は、直接経験者から指導を受けてみては?
弊社でも「User Story Teller (ユーザーストーリーの語り手)シリーズ」と名付けたサービスを通して、皆さんが実際に書いたユーザーストーリーの分析や書き直し、目の付け方、などのハンズオン指導を提供しています。
上記のアジャイルひよこの定例会に参加するのもお勧めです。プロのアジャイルコーチやコンサルタントが「にわとり」として参加されることが多いので、ニーズにぴったりの経験者に巡り会えるかも知れません。
次のブログは「ユーザーストーリーと氷山」についてです。お楽しみに。