Season -No.225 朝活「As a user, I don’t want to, WYSIWYGPT」をダラダラ読む回

00:04

はい、4月30日日曜日ですね。

僕は朝9時13分になってしまいました。

はい、えー、4月の終わりというところで、

なんか、僕昨日京都に出て、えー、

今日、本当に言いますけど、なんか、

東京は晴れてたんですけど、

昨日は、僕京都で雨だったんですよね。

悪い天候にくっついていた感じですけど。

はい、おはようございます。

めめめのきーすかとくわはらです。

ではでは、えー、本日も朝活始めていきたいなと思います。

えー、本日はですけども、

ちょっとすいません、昨日、おととい3日かな?

3日連続で、

朝活をちょっとサボってしまって、

大変に申し訳ないんですね。

はい、今日からまた頑張っていきたいと思いますが、

えっと、えー、

今日はですね、まず技術的な記事を探してたんですけど、

気になったのは技術じゃないこの記事になってしまいますが、

えー、

アザユーザーアイドルウォンツーという記事を、

今日はちょっと読んでいこうかなと思っております。

なんか、平たく言うと、なんか、ユーザーストーリーについての視点を

逆転すると面白いんじゃないの?

みたいなところの記事だったらしいので、

まあ、その辺を読んでみようと思っています。

はい、じゃあ早速いきましょう。

タスク志向のユーザーストーリーというのは、

価値とコストを混同してしまうため、

製品の決定を誤らせることになります。

しかし、このようなユーザーストーリーを

より大きく考えるためのツールである

逆ユーザーストーリーに

変えることは結構簡単です。

1997年に発明されて以来、

ユーザーストーリーはどこにでもあるものになりました。

Xとして私はZができるように

Yが欲しいというようなシンプルな

フォーマットは数えきれないほどの

ソフトウェアチームが顧客に提供する

価値に集中し続けるのにすごく役立っています。

はい、理論上はというところですね。

理論上は役に立っているけれど、

現実としてどうなのというところですね。

はい、で、スクラムのマニュアルや

アジャイルコーチというのは、

何十年もの間、プロダクトオーナーに

この形式を叩き込み、

ユーザーストーリーとチケットがほぼ

同義語になってしまったことです。

うーん、そうなんや。

自分たちの仕事をスクラムプロセスに

キープするあまり、チームはユーザーストーリーが

何を成功するためのものだったか

というのを見失ってしまいました。

ユーザーストーリーは、ユーザーとして

利益を得るために目標を達成したい

というところまで、

ユーザーとして

ツールを使うためにタスクをこなすようにしたい

などなどみたいな感じですね。

ページを見ることができるようにボタンをクリックしたいとか、

限定特典を受け取れるように

Eメールを入力したいとか、

フォームホゲホゲの

5行目を入力するために

フォームホゲホゲに記入したいとか

そうざっと

さえも

完全に欠着していることがあります。

本来の目的が

崩壊してきている感じが

あるというところですかね。

本当は

製品を使いたいとは

全く思わない。

理想的なユーザーエクスペリエンスは

何もせずにゴールに到達することです。

オリジナルのユーザーストーリーの形式は

ゴールに純粋に焦点を当てることで

このことを思い出させてくれました。

タスク志向のユーザーストーリーは

ゴールを作業に置き換えています。

03:00

利益を得ることなく全てのマイナス面を解決します。

幸いなことに

簡単に解決することができます。

ストーリーを反転させればいいんです。

ここからが本題に入ります。

次の章ですけど

本題の章1つ目は

What's so bad about tasks?

タスクの何がそんな悪いのか?

というところですね。

では行きましょうか。

元のユーザーストーリーのフォーマットで

最も重要なことは

ユーザーが喜んでお金を払うことかもしれない

という利益を逸脱しているということです。

逸脱?失礼。

外説しているということですね。

製品チームは

そのベネフィットを提供する方法と

そのコスト、ユーザーが直面することになる

製品の複雑さの増加に対処するコストなど

というのを含めたコストですね。

単なるお金じゃないということです。

などのコストを自由に考えることが

一応できます。

タスクやツール、機能はメリットではありません。

タスクをこなしたり

ツールを使ったりすることは

ユーザーが目的を達成するために支払わなければならない

コストの一つになります。

製品に機能を追加することは

そのコストを増加させるため

体験を劣化させることになります。

なるほどね。

一概に機能追加というのが便利になったり

ユーザーメリットになるかというと

実はそうではなく

むしろコストを増加させることも意味するので

体験を劣化させることになるよ

一概に全部そうだとは言わないですが

できることと

どういう恩恵を得るかというのもありますが

本質的には

コストを支払う量が増えるということですよね

ユーザーとしては

タスク志向のユーザーストーリーは

チームがこのようなトレードを行うのを

助けるのではなく

ユーザーにとっての価値の欠如を難解にすることで

トレードを難しくしています。

ユーザーとして私はホームに

記入したいと主張することで

ユーザーは製品に何かを与えてくれると

チームは錯覚してしまいます。

実際にそのような人がいなくても

ユーザーをホームに記入したい人と定義することで

コストが隠蔽されるんです。

このようなユーザーストーリーがあれば

全てのチケットは自己正当化できるようになります。

機能は増え

複雑さは増すばかりです。

ユーザーにとっての価値は脅落しますが

チームは常にユーザーが望むものを

作っていると自分に言い聞かせているため

それを理解することもできません。

しかしタスク志向の

ユーザーストーリーというのは

ユーザーを知るべきかというのを知っている限り

全く役に立たないというわけでもありません。

続いてのセクションです。

タスク志向についての

いろんな見方があるので

なかなか興味深いなと思っています。

続いてのセクションは

インバートザユーザーストーリーです。

ユーザーストーリーを反転させてみましょうという話です。

タスク志向のユーザーストーリーには

不正確なラベルに隠された

2つの有用な情報が含まれています。

ベネフィットと呼ばれるものは実際にはコストであり

ゴールと呼ばれるものは

解決策の仮説にしか過ぎないと言っています。

この情報を利用して

新しいタイプのユーザーストーリーを

作成することもできます。

タスク志向のユーザーストーリーをとりあえず例にとってみます。

ユーザーとしてはツールバーをカスタマイズして

06:00

ブラウジングを最適化したいものです。

というのが1つ例にとってみましょう。

私たちがコストを見ていることを認識した上で

そのコストを取り除く方法はないのか

というのをちょっと自問してみます。

そうすると

ユーザーとしてはツールバーをカスタマイズすることなく

ブラウジング体験を最適化したいのです。

まあそうだよね。

カスタマイズという選択肢は確かに与えて

できるようになったはいいですけど

別にそれは本質的には

コストを結局僕らが払わなきゃいけないので

本当はコストなくブラウジング体験を

最適化できるのはそれがベストですよね。

まあ言われればそうですよね。

なので機能追加というのは単なる

策の1つではあるけど

ベストではないということですよね。

落としどころとして機能を追加して

選択肢を与えることを

何もできないよりはまだできるほうがいい

というのがギリギリのところなんでしょうね。

考えると

本来の機能追加を本当にやりますかというのは

ビジネスインパクトがすごく大きくて

この観点は大事かもしれないですね。

はい、戻ります。

ユーザーが自分のツールバーを編集する負担を

負うことを当然と考えるのではなく

より良い、よりコストのかからない体験が

どのようなものかというのを考えることができるようになりました。

ツールバーのカスタマイズを

簡単にする代わりに

本当のメリットに直接飛びつくことができるようになります。

ユーザーは実際には仮説であることも浮き彫りにしています。

ユーザーは実際に

ブラウジング体験を最適化したいと

そもそも思っているのでしょうか?

どのような方法で?

そしてタスク士と志向のユーザーストーリーを書いているチームは

その仮説に縛られてしまいます。

確かにそもそも最適化したいかどうか

というのは

当てはまっていい話ではありますけど

ユーザーストーリーを反転させる準備をしたチームは

実際にそれを確かめることもできます。

ちなみにそういう

ユーザーストーリーは

09:00

ユーザーストーリーは

12:00

ユーザーストーリーは

15:00

ユーザーストーリーは

18:00

ユーザーストーリーは

21:00

ユーザーストーリーは

スター

エピソードをシェアする

メッセージを送信

Keeth Kiyohito Kuwahara

スター

コメント

こちらもおすすめ