＊本コラムは、技術評論社「Software Design」2021年3月号に寄稿したコラムを掲載しています。

前回は、いかに価値あるサービスや課題解決を具体的に創出するかについて書きました。今回はその実践編として、具体的なイメージのあるサービス・価値をどのような形で実現するか、言い換えるとどのようにプロダクトバックログを作っていくか、について解説したいと思います。

プロダクトバックログを作るまでの道のり

今回の目的は、プロダクトバックログはどのようにして作られるかをお伝えすることです。前回定義したサービスイメージから、どのような道のりを経て、プロダクトバックログに到達するのか、について述べていきます。
ここで、前回の検討を一度おさらいしておきたいと思います。

ここからは、上記の検討内容を「インセプションデッキ」という枠組みによってチームで共有し、「ユーザーストーリーマッピング」「プロトタイピング」という手法によってサービスイメージを具現化することで、プロダクトバックログを作っていくこととします。

インセプションデッキ

前回はどんなサービスにすると良さそうか、ということをいくつかの観点で検討したわけですが、それらの検討内容は散在していて、一覧できるようにはなっていません。
まだ記憶も新しいときには問題ありませんが、サービス開発が始まり、それぞれのメンバーがそれぞれの役割をこなしだすと、徐々に認識がずれてきたり、「言った・言わない」の議論が始まったり、といったことが起こります。

そこで、まずは今後のよりどころとなる「インセプションデッキ」というものを作ります。インセプションデッキは、ThoughtWorks社の方が考案されたもので、「我われはなぜここにいるのか」「やらないことリストを作る」「夜も眠れなくなるような問題は何だろう」などといった10項目からなっています。これらの項目をもとに取り組みのよりどころを整理するのは、今回の目的にはぴったりです。

すでに、前回に検討したものも多くあり、それをベースに取りまとめることでインセプションデッキを完成させることができます。

ただし、気をつけてほしいことが1つだけあります。それは、このインセプションデッキで最も重要なのは、「ステークホルダ、オーナー、開発メンバーが合意したか・思いが共有できたかどうか」ということです。それができていない、きれいにまとまっただけのインセプションデッキには意味がありませんし、逆を言えば、プロジェクトキックオフなど似たようなことを行っているチームで、上記のような内容が合意されていれば十分ということです。

今回は誌面の都合に加えて、検討しているサービスが単純であることも鑑みて、インセプションデッキの策定については割愛します。インセプションデッキのテンプレートはWeb上にたくさんありますから、参考にしてもらえればと思います。

ユーザーストーリーマッピングとプロトタイピング

インセプションデッキの形でサービスイメージが固まったところで、そのサービスイメージを具現化、つまり、プロダクトバックログにしていきます。 まずは「ユーザーストーリー」を記述していきます。ユーザーストーリーとは、簡単に言えばサービスを実現する際に必要な要求のことです。システムの話ではなく、このサービスのステークホルダが、サービスを利用する理由とゴールを説明するもので、次のようなテンプレートをよく使います。

最初のうちは、粒度の異なるユーザーストーリーやシステムに関するタスクが混ざったりしますが、ちょっとした作成のコツをつかんで慣れればできると思います。

今回のお題では、数は少ないですが、ざっと次のようなものを考えてみました。

さて、ここからが重要です。このユーザーストーリーの集合でサービスが構成されるわけですが、アジャイルの考え方にのっとり、ユーザーストーリーに対して、リリースの優先順位をつける必要があります。ユーザーストーリーが20～30程度であれば、何が大事で、何が大事でないのかを考えて、優先順位をコントロールできるかもしれません。しかし、アイテムが100～200を超えるようになってくると、抜け漏れや重複なども発生して、カオスな状態になるのではないかと思います。
つまり、ある程度以上の規模のサービスだと、ユーザーストーリーを単に並べて優先順位を決めていくというやり方には無理があり、そこには、何らかのしくみを持ち込む必要があります。
そこで、リリースの優先順位を決めるしくみとして、ユーザーストーリーマッピングとプロトタイピングを利用します。
この優先順位のつけ方にはこれという手順が決まっているわけではありませんが、筆者が書くときのやり方について、各手順を解説します（図1）。
ユーザーストーリーマッピングとは、ユーザーストーリーを「時間」×「優先順位」で配置するものです。

図1　ユーザーストーリーマッピングのテンプレート

1．時系列順にアイテムを配置する

2．ユーザーストーリーをマッピングする

本節の冒頭で挙げたユーザーストーリーを、実際にマッピングしていきます（図2）。このとき、新たに思いついた別のユーザーストーリーがあれば、それも追加します。
上には必須のサービス（どうしても必要だと思うもの）、下へ行くにしたがってオプションのサービス（あったらいいなと思うもの）を配置し、この状態で、ユーザーストーリーの粒度を見直します。大き過ぎるものは分割、小さ過ぎるものは統合などしますが、このあたりは後述します。

図2　例題のユーザーストーリーマッピング

3．プロトタイピングでサービスイメージをクリアにする

ここで、主要なユーザーストーリーに対して、サービス利用イメージを策定します（図3）。ユーザーはITシステムの場合、何らかの画面（今回のサービスではスマートフォンの画面）を通してサービスを利用します。そこで、サービスを手触りある形（リアリティのある形）にするために、プロトタイプを作ります。そうすることで、サービスをより具体的なものとして感じとることができ、（次に述べますが）どの順序でリリースしていくべきか、をより具体的に検討できます。

ここで、注意点が2つあります。
1つめは、ユーザーストーリー1つに対して、画面が1つできるわけではないことです。1つの画面が複数のユーザーストーリーをカバーすることはあります。
2つめは、このプロトタイプはUI設計ではない、ということです。これは、サービスイメージを共有するものですので、サービスのコアとなる部分が表現されているようにします。ゆえに、単にUI設計をするのではなく、ペーパープロトタイピング（紙に手書きで画面イメージを作ること）もお勧めです。

図3　プロトタイプを追記したもの

4．リリースの順序を考える

プロダクトバックログの作成

ようやく、プロダクトバックログ（アイテム）の作成ですが、この時点ではある程度のことは終わっています。プロダクトバックログは、先ほどのユーザーストーリーマッピングのユーザーストーリーをもとに作りますし、優先度もリリースラインをもとに考えることができます。
ただ、ユーザーストーリーは、ユーザーの願いや困りごとの解決策が書かれているだけですので、ユーザーストーリーがバックログアイテムとして成立するような内容を追記していく必要があります。
ユーザーストーリーに下記の項目を追記し、バックログアイテムにしていきます。ここから先は、付加する項目も増えていきますので、ふせんではなくExcelや専用ツールで管理するようにします。

完了の定義

一般的には、品質の確保に関して定義されます。個別のストーリーというよりは、ストーリー全体を通じて、定義される内容であることも多いです。 たとえば「すべてのユニットテストをパスしている」「機能テストに合格している」などが該当します。

受け入れ基準

簡単に言えば、「このバックログをデモするときにどのような内容にするか？」「何をテストすればよいか？」を考え、そこから受け入れの基準を考えます。内容によっては非機能部分なども対象になります。

ストーリーポイント

このアイテムのストーリーポイントを見積もります。プランニングポーカーなどを使って、相対的に見積もりを行います。完了の定義が緩いと、この見積もりは当然ずれてしまいますので、注意しましょう。

このアイテムができると、何が実現されるのか？

ユーザーストーリーはふせんに書かれていますが、このタイミングでこのユーザーストーリーに書かれた内容が起こると何が実現できるか、なぜ実現するのか、実現後どうなるのかをしっかり記載しておきます。

リリースライン

ユーザーストーリーマッピングにおけるリリースラインは、リリースする単位を表したものです。MVPをまずリリースとし、その内容がユーザーにとって価値があるかどうかを評価・判断し、その次に、ユーザー価値が付加される最小の部分をリリース、評価・判断するということを繰り返します。
それぞれのバックログアイテムが、どのリリースラインに設定されるかを明示します。

優先順位

前述のリリースライン自体はリリースの単位に順序をつけていますが、その中身であるプロダクトバックログのアイテムについての優先順位には言及していません。実際に、バックログアイテムとするためにバックログアイテム自体に優先順位をつけることが必要になります。

◆　◆　◆

ここまで検討できれば、開発初期のプロダクトバックログ（表1）がほぼ完成です（誌面の関係上、すべての項目は記載していません）。つまり、ようやくサービス開発に入っていくための準備ができた、ということになります。
本連載を読んでいるような開発者の方であれば問題ないのですが、そうでない場合には開発者（バックログを実現する人、一般的には開発チームの開発者）に協力を仰ぎ、一緒に検討を行いましょう。開発者の視点なしではプロダクトバックログは完成しません。

そのほか、プロダクトバックログについての注意事項

ユーザーストーリー、プロダクトバックログについて、ここまでで触れられなかった内容をいくつか列挙しておきます。