ユーザーストーリーとハンバーガー(おまけ)
前回のブログでは、ユーザーストーリーをよりアジャイル風に分解するための「ハンバーガーのひと口形式」について触れました。今回は、その一例として紹介したユーザーストーリーを、さらにハンバーガーひと口形式で分解してみましょう。
まず前回紹介したユーザーストーリーをもう一度見てみましょう。
営業担当者として、
顧客の会社名をiPhoneから入力して、代表者の名前を検索したい。
何故ならば、外回りで訪問寸前に再確認したいから。
ここでは、システムの開発がまだ始まったばかりで、必要な機能やアクセスなどは殆ど既存のものがない、という前提で話を進めます。
ではどこで分解するかですが、まず分かりやすいのは「外回りで」の部分を別のストーリーにすることでしょう。
会社の外から顧客データアクセスを可能にするには、恐らくセキュリティやインフラまで関わってきそうです。その部分がなくても、そのほかの機能はかなり使えるレベルまで完成できます。
「それではハンバーガーのひと口形式に背いてない?
そのひと口には大きな要素が欠けることになるのに?」
ご心配ありません。
要は、私達が食事をする時と同様に考えれば良いのです。
自然に食べているハンバーガーのひと口ひと口にはトマトが欠けていたり、ピクルスが2枚重なっていたりってありませんか?
それでも、それだけで極端に味が分からなかった!とは思いませんよね。
何故かというと、私たちの脳がきちんと前後の経験から調整してくれるからです。
食べ易い大きさでひと口ずつ食べ続けているうちに、私たちの脳はそこからの味覚や嗅覚を総合的に捉えて、
「このハンバーガーはこういう味」
という判断をしてくれるのです。
アジャイルにもこういう人間の脳の特性が生かされている、ということです。
ユーザーストーリーとして大切なのは、どれもが食べやすい大きさで、それなりにその全体の味が分かること。
そしてその実装が次々と何度も繰り返され、それを使ってみることによって、システムの全体像が開発側にもクライアント側にも把握しやすくなります。
こういう過程を経て、曖昧で抽象的なイメージでしかなかった「システム」が、段々と具体的な「役立つツール」として関係者全員の頭の中で形を成してくるのです。
これは、はっきり形として見えにくいソフト開発において、要求項目リストや解説図などを理解しただけでは起こらない、重要かつ必須な現象です。
ちょっと話が逸れましたが、1つだったユーザーストーリーはこんな風に2つのユーザーストーリーに分解できました。
- 営業担当者として、顧客の会社名をiPhoneから入力して、代表者の名前を検索したい。外回りに出る前に確認したいから。
- 営業担当者として、会社の外からも顧客の会社名をiPhoneから入力して、代表者の名前を検索したい。外回りの合間にできると効率が良いから。
でも読んでみると、一つ目のストーリがまだ大きそうですね。
やはりこれもあと一歩分解してみましょう。
入力項目が会社名、出力項目がそこの代表者の名前、と一見簡単そうですが、よく考えるとこのストーリーには幾つかの機能を必要としています。
- 会社名の追加
- 顧客名の追加
- 会社名と顧客名の関連性の追加(検索のため)
- 会社名を条件に顧客名の検索
- 検索結果の表示
こうしてみると、処理内容のCRUD面から分解するのが良さそうですよね。
そこでこれを新規データの作成・追加 (Create) 実装のストーリー、そして検索 (Retrieve)実装のストーリーに分け、合計3つのストーリーにしてみましょう。
- 営業担当者として、新規顧客の会社名と代表者の名前をiPhoneから入力して会社名を顧客リストに追加したい。次の訪問の際に検索したいから。
- 営業担当者として、顧客の会社名をiPhoneから入力して、代表者の名前を検索したい。外回りに出る前に再確認したいから。
- 営業担当者として、新規顧客の会社名と代表者名をiPhoneから会社の外からも追加・検索したい。外回りの合間にできると効率が良いから。(前の2と同じ内容)
ここまで細かくなってきたら、受け入れ条件も一緒に検討すると、サイズの調整がしやすいかも知れません。
ある程度サイズが揃ってきたのにまだ少し大き過ぎたり小さ過ぎたりしている場合、受け入れ条件を緩めたり追加したりすることでサイズ調整するというわけです。
例えばストーリー2は、これだけではサイズが小さ過ぎるかも知れません。そんな場合には、エンドユーザーが優先して欲しがっていた細かな機能を追加するのも効果的です。
もしエンドユーザーが、
「検索にはカタカナ入力でもひらがな入力でも可能」
という機能が欲しいのであれば、そしてそれを比較的簡単に実装できるのであれば、これを受け入れ条件として指定して使いやすさをアップしてはどうでしょう。
利便性をいち早くユーザーに実証できる、おいしいひと口が提供できます。
或いは開発者やテスト担当者にとって、またはエラーログにとって結構有益な機能を受け入れ条件として加えて実装する、という手段もあります。
たとえばストーリー2に、
「誰がいつ追加したか、というデータも一緒に表示する」
という受け入れ条件を追加することも考えられます。
簡単に小さな労力で実装できる内容で、かつ開発の、特に最初の頃デバッグを効果的に行うのに欲しい情報などは、実装する価値がありますよね。
そういう受け入れ条件を追加した場合は、エンドユーザーにもそのように説明しておきます。
のちに表示を隠したり、テストモードの時だけデータを抽出する、など適切な変更をすれば良いのですから。
実際あったことですが、同チームの開発者が自分で効率良くデータを入力するために、ある機能を実装し、リビューで「ついでに」見せたらステークホルダーにもクライエントにも大人気でした。チームだけでなくエンドユーザーも入力にはほとんどその機能の方を使い始めたほどです。その機能は言うまでもなく最終システムに正式に採用されました。
また話が逸れましたが(ごめんなさい)、上のような分け方であれば、それぞれのストーリーが完成した時点でクライアントにデモを行ってフィードバックがもらえますし、場合によってはそれぞれの時点でリリースして実際に使ってもらうこともできます。
これがハンバーガーひと口形式に分解されたユーザーストーリーの大きな利点です。
ここで注意ポイントをひとつ:
「これちょっとサイズ大きいかも。分解した方が良いかな?」
と思った時、
「でもこのままでも頑張れば終わるよね」
と思いたくなるエンジニアさん、言いたくなるPOさんへ。
これ要注意です。
大きそうだと思ったら、まず分解するほうが断然ベター(Better)です。
これにはちゃんと根拠がありますが、読者の方からの関心があるようなら別のブログのトピックとして扱いますね。
実際のビジネス要件やシステム定義をどのようにハンバーガーひと口形式で分解するかは、練習するうちに見えてきますが、最初の頃は戸惑うところがあるかも知れません。
そういう時は経験者に相談して、幾つか実際に書いたものを分析・更新してもらうのがオススメです。弊社でも「User Story Teller (ユーザーストーリーの語り手)シリーズ」のサービスを通して、皆さんが実際に書いたユーザーストーリーの分析や書き直し、目の付け方、などのハンズオン指導を提供しています。
以前ご紹介したアジャイルひよこの定例会にも参加をお勧めします。プロのアジャイルコーチやコンサルタントが「にわとり」として参加されることが多く、まだ「ひよこ」の参加者ですでにアジャイルコーチを受けたことのある方にも会えたりしますよ。
