まえふり
弊社の場合、受託開発の際、発注者にユーザーストーリーを書いてもらっています(または一緒に作成します)。一口にユーザーストーリーと言っても、人によって定義がぐちゃぐちゃなので、大変です。
できる限り、過不足ない状態を意識して作成しています。この過不足なくというのがポイントです。大概の場合、発注者がユーザーストーリーを書くと、過剰がちになります(正直読んでられないぐらい長文になる)。また、プログラマーが書くと、不足がちになります。まぁ、この手の物は過不足なく、ちょうどいい塩梅にするのがポイントです(バランスよくするっていうのは簡単なんですよね)。
そんな時には、フォーマットがあればいいよねということで、弊社で使っているフォーマットを紹介したいと思います。
ユーザーストーリーとは
そもそもユーザーストーリーとはどんな言葉なのか。定番ですが、Wikipediaで見てみましょう。
User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management.
ユーザーストーリーは、ソフトウェアの機能定義や開発マネージメントを容易にする、アジャイルソフトウェア開発方法論です。
ニュアンス的には上みたいな感じだと思います。
「アジャイルソフトウェア開発」という言葉がでてきます。あぁ、アジャイルか!それなら、永和システムマネジメントかソニックガーデンあたりの人(Rubyのすごい人)がなにか言及していないかなということで、早速調べてみます。
すると、永和のアジャイル事業部のページに書いてありました。
ユーザーストーリーはユーザーが実現したいことやユーザーにとって価値があることを簡潔にまとめた文章です。
ちなみに、永和では、ユーザーストーリーは開発者が書くみたいですね。あとPivotal Trackerというツールを使っているみたいですね。
ということで、ユーザーストーリーという言葉は、「アジャイル開発」とかの言葉っぽいですね。つまり、ソフトウェア開発を円滑に進めるための方法論って感じでしょうか。なので、エンジニア(プログラマー)系の人が使っている言葉なのでしょう。エンジニアにとっての機能定義の話なら、なるほどと思ったのですが、やはり言葉というものは一人歩きするものです。大体の場合、プログラムを書かない側の人がエンジニアが使っている言葉を使い出すと、言葉の意味が歪曲されていきます(あるあるですね)。
プロダクト構築の視点
そこで、プロダクトデザイナーとか、スタートアップのファウンダーとかはなんか言ってないかなと思って調べてみました。おそらくここら辺の人は、機能定義という話を飛び越えて、その製品がそもそもうまくいくのか、商業的に成功するのかについても言及しているはずです。
動機・背景について考えるジョブストーリーとは？ プロダクト構築の新たな手法 | L’OREM [ローレム]
上の記事はいい感じに難しいですね。機能定義の話が、プロダクト構築の話になります。まぁ、最初に問題点を指摘しているのでご愛嬌という感じですかね。最初の、Wikipediaとは「言葉のスコープ」が違うということに注意してほしいのです。言葉が対象とする範囲の大きさが違うのです。たしかに、コアは同じでしょう。しかし、どの範囲まで想定しているのかという範囲が違います。エンジニアの機能定義の話と、プロダクト構築の話は、間違いなくスコープが違います。
まえふりで言いたかったこと
- この手の、人によってスコープが違う言葉には気をつけよう
- スコープの違いがコミュニケーションの齟齬につながるから
- コミュニケーションの齟齬は、期待値の違いになるから
- その期待値の違いでだいたいケンカになるから
弊社のフォーマット
弊社の場合は、プロダクトデザインまで踏み込みます。むしろ、それぐらい大きなスコープでユーザーストーリーを扱います。多少曖昧でもOKということです。ユーザーストーリーからチケットを作成することは困難でも問題ありません。それぐらい粒度の大きなものでも問題ありません。開発の場合(特にPivotal Trackerにチケットを登録する場合)は、粒度調整がキーポイントだと思います。チケットの粒度にするのはちょっと難しいのでここでは棚上げします。
チケットにしないとかいいながら、チケットとか書いてあるじゃないかというツッコミもあるかと思います。正直、粒度荒くてそのままチケットとしては使えないのですが、粒度を調整するためにサブチケット(サブタスク)にしていけば使えないこともないと思います。
解説
- –1– が、–2– をできるようにする。
- –3– という課題があり、
- これが(2が)できるようになることで、–4– になるからだ。
このフォーマットで書いた時の、読み取り方が以下です。
Who => What 形式
- だれが、なにをできるようにするのか? が明確になっていること
- また、WhoについてはPersona(ペルソナ)、Role(役割)が明確になっていること
これが一番大切だと思います。なにができるようになるソフトウェアなのか明確にしましょう。
What => Why 形式
- なにをやるのか? なぜやるのか? の関係が明確になっていること
Whyの部分は、曖昧になりがちなのであまり気にせず、書ける部分だけ書けばいいかなと思います。
Problem => Solution 形式
- どんな課題があり、どう解決するのか? の関係が明確になっていること
- どう解決するのか? が機能定義(Function)になっていること
これも明記するのちょっと難しいですね。Hipchatの課題を明確にして、Slackは産まれたわけではないと思いますし。とはいえ、できる限り課題を記述するのも重要です。ここで書いた課題が、PRメッセージになることもあります(email is dead みたいな..)
Customer Value
- 顧客価値が明確になっていること
これは(a)の次に大切です。そのソフトウェアを使うことで、最終的にどんな価値を獲得できるのかは大切です。
Tickets Format
- 粒度が荒い状態でもタスク形式(〜をできるようにする)になっていること
上でも書きましたが、粒度的にタスクにはならないと思います。
要求定義/要件定義/機能定義
- それぞれの役割を網羅していること
要求とか要件とか機能とか、言われてみればそうかなぐらいの感じかなと思います。
まとめ
- と(d)が明確になるように記述しましょう
- それ以外は、できれば読み取れるようにしましょう
具体例
飲食店の研修システムを構築した際の例です。
