未経験者にAgileを教えた話　第4話　ユーザーストーリー

前回までのあらすじ：
レクチャーを終えてフィードバックを集めていた私。次回以降のレクチャーもステップバイステップで少しずつAgileとは何ぞやを伝えようと思っていたが、上司からのプレッシャーがあったことで急遽内容を変更してユーザーストーリーについてのレクチャーをすることになった。

振り返り

第2回のレクチャーは初回のレクチャーの宿題のリキャップから始めた。

前回のワークショップでは、顧客が要求したものと全然違うアウトプットが出てしまったプロジェクトが多いようだったが、宿題で出した「どうすればもっと確度が高くなったのだろう？」という問いかけには主に3つの提案があったことを紹介した。

・伝言ゲームをやめればいい
・要求が曖昧だったからそれをはっきりさせればいい
・より短いスパンで要求元と正しい方向に進んでいるか確認すればいい

「全て正解です、しかし・・・」と続けた。

顧客が本当に欲しかったもの

次に前回のワークショップにおける、とあるプロジェクトの要求と成果物を紹介した。

要求：金600万円　銀行振込

だったのだが、成果物にはテーブルの絵。

これだけだとただの笑い話だが、重要なのはここから。

全然違うアウトプットだが、もしこの顧客が600万円の高級なテーブルを買いたいと思っていたら、これは顧客の要望を満たしている。もし借金取りに追われていたら、現金じゃないとまずい。

「顧客が何を要求しているのかはもちろん大切ですが、なぜ顧客はそれを要求したのかはもっと大切です。」

と言ってユーザーストーリーのフォーマットであるWho/What/Whyを紹介した。

WhatだけでなくWhoとWhyを含めることがユーザーストーリーの肝であり、それは誰にとってベネフィットがあるのか、そして何より重要ななぜそれが必要なのかということを明確にするためだ、と。

例えばこんな感じ：
高校生の顧客として、EC購入代金をコンビニで支払いたい。クレジットカードを持っていないからだ。

ついでにWhyの重要性を熱弁

ユーザーストーリーの話をするついでにWhyの重要性を語ってみたが、一番食いつきがよかったのは前職時代の実例を挙げたことだった。

ある日、ビジネス部門の人がやってきて唐突にこう言いました。
「Facebookログインの機能が必要です。」

いろんな人に怒られそうなので詳細は割愛するが、実際は結構生々しい話をした。

理由を確認したところ、要求元のビジネス部門の人だけではなく現場の人達を含めた複数部門へのヒアリングが必要でした。
ヒアリングの結果、本当の課題はログインではなく会員登録だったということ、その中でも特に住所の入力に時間がかかることだと判明しました。

Facebookから住所情報は取得できないため、もともとのFacebookログインという要求が、根底にあった課題の解決に一切役立たない。教科書のような話だが、実話。

こうして2度目のレクチャーを終えた。

エピックは？

もともと上司からは「ストーリーやエピック」というリクエストがあったが、エピックまで触れる余裕がなかったので敢えて外した。

「めちゃくちゃ大きいストーリーは、もう少し細かくブレイクダウンする必要があります」とだけ述べた。その時に、大小様々なサイズの小石の写真を見せた。

上司から「あの石の写真はエピックのこと？」と聞かれたのでYesと答えたら、彼は満足した様子だった。これで表面上は上司からのリクエストにこたえたことになる。

しかし結局次のレクチャーはエピックについて話すのがいいかなと思いつつある。エピックをどうブレイクダウンするのか、からのMVPの話がストーリーとして美しいかなと思い始めたのが理由である。