え、ユーザーストーリーなのにシステムがペルソナだって?それって誰のためのストーリー

2025年01月29日 水曜日


【この記事を書いた人】
北河 直樹

名古屋支社所属。新しい技術・怪しいデバイス・GISが好き。名古屋から影響力のある開発チームを作って発信していくのを目標としている

「え、ユーザーストーリーなのにシステムがペルソナだって?それって誰のためのストーリー」のイメージ

はじめに

三河からこんにちは。名古屋支社の北河です。先日参加したRSGTも終わり今年も無事始まっております。

RSGTで思い出しましたが、2日目のキーノート、「ユーザーストーリーマッピング」の筆者 Jeff Patton さんの プロダクトシンキングの話で出てきた「誰にとっての価値」と、少し前に社内で盛り上がった「ユーザーストーリーのユーザーは誰よ」っていう会話が頭によぎりました。

ということで、今回はユーザーストーリーのユーザーについて実際あったことを話していきたいと思います

ユーザーストーリーとは?

初めて聞く方もいると思いますので、簡単に説明しますね。

ユーザーストーリーとは、開発者視点ではなく顧客視点でどのような価値があるかを説明した短い文章です。

アジャイル開発では顧客が本当に欲しいモノを仮説と検証のサイクルを短期間で行っていきます。ここで大切なのは顧客が本当に欲しいモノです。よって顧客価値が書かれているユーザーストーリーとの相性がよく(当たり前)、アジャイル開発では良く使われる書き方です。

では、ユーザーストーリーは「いつ、どこで、誰が」始めたのでしょうか?

ユーザーストーリーという言葉は Kent Beck が アジャイル開発の一つの方法論である、XP(エクストリームプログラミング) の一環として取り上げていたのが起源のようです。

最初にこの言葉を使い出したのはKent Beckで、Extreme Programmingの一環として取り上げていた。
引用: ユーザーストーリー – Martin Fowler’s Bliki (ja)

そして馴染みのあるテンプレート「…として、…をしたい。なぜなら…だからだ」は Mike Cohn から広まりましたとあります。

実際にあった出来事

そんなユーザーストーリーですが、私が所属している 名古屋支社 技術4課 でのスクラムマスターの集まり、通称 スクラムマスターズ会でこんなやり取りがありました。

名古屋支社 技術4課 は 開発ベンダー

この話をする前に、技術4課がどういったことをしているかを知ってもらう必要があります。

所謂開発ベンダーで、案件毎にアジャイルチームが対応しているといった組織となります。

開発ベンダーのアジャイルチームって聞くと、なんちゃってアジャイルだったりして嫌な印象を持たれているかもしれませんが、過去のブログでも書いてあるとおり、様々コミュニティに参加したりアジャイルに真摯に向き合っていたりしています。

そんな組織だからこそ、チーム間の交流や情報共有はチームが成長するうえで非常に重要になってきます。それを加速させるのがスクラムマスターズ会です

スクラムマスターズ会とは

スクラムマスター同士が経験から学んだことや失敗したことを共有しチーム力を底上げする会です。

2019年4月より開始し、毎週各チームのスクラムマスターが集まってワイワイしています

毎週、何らかの学びや深く考えるテーマをチームに持ち帰えることで、チームが真剣にアジャイル に向き合うきっかけを与えている、そんな会です。

ユーザーストーリーのペルソナがシステム?

とあるチームから、相談がありました

基盤みたいなユーザーストーリーのペルソナってシステムになるのかな?でもそれって果たしてユーザーストーリーなの?ユーザーにシステムしか書けないってことは プロダクトオーナー との会話が足りないってことでは?

どういうことかというと、ユーザーが直接触れる箇所ではなく、システムから利用される箇所の場合、利用する側がシステムになるので、ペルソナがシステムになるのでは?でも違和感がありありなのでマスターズ会で聞いてみたといった感じです。

そもそも、そういうカットでプロダクトバックログアイテムを作るなよ!というご指摘はあるとは思いますが、ベンダーとして複数社が絡むようなプロジェクトとかに参加すると、どうしてもそういった状況に遭遇することがあります。「あるある~」と共感する方もいるかと思います。そうでない方はそういった場合を想像して読んでもらえればと思います。

人がストーリーの中心となる

冒頭でユーザーストーリーについて以下のように書きました。

ユーザーストーリーとは、開発者視点ではなく顧客視点でどのような価値があるかを説明した短い文章です

顧客視点となるので、人がストーリーの中心でなければなりません。システムが中心であれば、それは単なるシステム間のインターフェースで、顧客(ユーザー)に価値を届ける最終的なストーリーではありません。

例えば基盤を例にだすと、 “データを高速に処理できる基盤機能” が必要であっても、根本にあるのは “ユーザーがストレスなく○○を利用できる” といった最終価値になるはずです。

そういう会話すると、もしかしたらチームメンバーの誰かがこう言うかもしれません。

ユーザーが直接触らない場所なので、このプロダクトバックログアイテムに対する最終的なストーリーは見えないよ

ここがポイントだと思います。

自分たちが作っているモノが、最終的にどんな価値を生むのかを見えていないとストーリーは描けないかなーと。

もし見えてないのであれば、自分たちが作っているモノが最終的にどんな価値で届けれるようになるのかを理解するための行動をとりたいですね。

得た気づき

ユーザーストーリーのユーザーは人です。人を中心にストーリーを書くことで、顧客が本当に欲しいモノを仮説と検証が出来るようになります。

なので、システムがユーザーストーリーになってしまうのであれば、それはユーザーストーリーではなく、単なる機能要件や仕様だと思います。

そもそも、役割毎のチームなんでちゃんちゃらおかしいぜ!という意見もあると思いますが、そういったプロジェクトはどうしても多く存在します。「ちゃんちゃらおかしいぜ!」で切り捨てるのではなく、その制約の中でいかに工夫してやっていくかが大切だと思います。

がんばって工夫していきましょう!

おわりに

いかがだったでしょうか?

もし、ユーザーストーリーのペルソナがシステムになっているのであれば、一度最終的なストーリーを考えてみたらいかがでしょうか?

最後に宣伝となりますが、私が所属している名古屋支社開発チームは開発ベンダーでありながらアジャイルでお客様のビジネス拡大に貢献したい!と活動しています。最近はアジャイルに関する相談や意見交換する機会が増えています。リアルな話が出来ますので、興味がありましたら個人やIIJのXで良いので是非ご連絡ください!


執筆者X @nk_tamago ※意見は個人のものです

 

北河 直樹

2025年01月29日 水曜日

名古屋支社所属。新しい技術・怪しいデバイス・GISが好き。名古屋から影響力のある開発チームを作って発信していくのを目標としている

Related
関連記事