チーム開発の視点が変わる アジャイル開発の新常識 第4回 初めての新規サービス開発(実践編)

アジャイル/DevOps

2021.09.15

  

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

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

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

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

  • サービスの目的:「自分の家が防犯上望ましくない状態になっている」ことを防ぐ
  • 簡易ペルソナ:子供が1人おり、共働きの山田さん(44歳)。新しいものはそんなに得意じゃない
  • ジャーニーマップからの課題:山田さんが家を出たとき、通勤の途中で家の鍵をかけたかどうか、不安になってしまう
  • サービスの全体像:施錠されているかどうかが不安になっても、実際には鍵がかかっていることがほとんどであり、手軽に施錠状態が把握できるだけでも十分有用。ただし、万が一のことを考えて、施錠状態を関係者に共有できるとより価値が高まる可能性あり

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

インセプションデッキ

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

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

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

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

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

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

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

<Who>は<What>をしたい、<Why>という理由があるから(なぜなら〜だから)

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

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

  • (ユーザーは)本サービスに登録する
  • 鍵の状態を検出するハードウェアを登録する
  • 鍵の状態を共有する人たち(想定としては家族などの同居している人)を登録する
  • 複数のハードウェアを登録する
  • 今の鍵の状態を確認する
  • 鍵の状態を(勝手に)教えてくれる
  • 特定のグループからの鍵情報を受け取る
  • 鍵がかかっていないことを特定のグループに共有する

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

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

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

まずは、前回作ったジャーニーマップを参照しつつ、このサービスを簡易ペルソナで設定したユーザーがどういう流れで使っていくかをふせんに記述し、「やりたいことフロー」の領域に配置していきます 注1
今回のお題はインタラクションが多いものではないので非常に単純ではありますが、次のようなことがユーザーのやりたいことになると思われます。

  • 外出する人(簡易ペルソナで設定したユーザー)は、まずはサービス利用を開始したい
  • そのあと、ユーザーは(このサービスを使って)鍵の状態を知りたい
  • 鍵の状態を知ったあと、ユーザーは鍵の状態を関係する人に連絡したい(鍵を忘れていたら、その人が何かできるかもしれないため)

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

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

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




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

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

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

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




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

今回のサービスをどの単位でリリースしていくか、を検討します。まずは、絶対に必要なサービス、つまりMVP(Minimum Viable Product:顧客価値があり、利益を生み出せる最小限のもの)をリリースし、次いでオプションとしてリリースすべきもの、その次にリリースするもの、というようにリリースの順序(リリースライン)を検討します。当然、まだクリアになっていないユーザーストーリーもありますので、この段階ですべてのリリースを設定する必要がないのは、アジャイルの考えどおりです。
さて、今回のリリースラインですが、MVPを「鍵の状態を知る」こととし、次のように設定しました。

  • リリース1:MVPとして鍵の状態を取得する
  • リリース2:その鍵情報をほかの人と共有する
  • リリース3:複数のハードウェアを登録する

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

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

完了の定義

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

受け入れ基準

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

ストーリーポイント

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

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

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

リリースライン

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

優先順位

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

◆ ◆ ◆

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

表1 開発初期のプロダクトバックログ

優先
順位
ユーザーストーリー 受け入れ基準 ストーリーポイント
1 サービス未登録者は、サービスを利用開始するために、サービスの利用登録ができる ・ アプリ初回起動時に、[サービス登録]のボタンを表示すること
・ [サービス登録]ボタン押下後に、サービス利用規約を表示し、画面最下部に[同意]ボタンを表示すること
・ [同意] ボタンを押下後に、ニックネーム(全角10文字、半角20文字以内)を必須項目として入力できるフォームを表示すること
・ ニックネームを入力する画面に[ 登録] ボタンを表示し、[登録]ボタン押下後に、サービス利用登録完了画面を表示すること
3
2 サービス登録者は、あらかじめ登録した鍵の、現時点の施錠状態を確認できる ・ アプリを起動したら追加操作なしで施錠状態がわかること
・ 施錠状態は、文字ではなく直観的に伝わる画像で表現すること
・ 施錠状態は、「施錠」「開錠」「施錠状態取得中」の3パターンで定義すること
・施錠状態は、10秒以内にリアルタイムで取得して画面に反映すること
8
3 サービス登録者は、任意の鍵を施錠状態の確認対象としてサービスに登録できる 5
4 サービス登録者は、設定した日時に鍵が施錠されていない場合に通知を受け取ることができる 3

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

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

  • ユーザーストーリー、プロダクトバックログアイテムのサイズには気をつけてください
    一般的に、チームが数日で実現し得る程度のサイズにし、そうでない場合には分割・統合を検討します。
  • 「ユーザーストーリーのINVEST」を基準に考えてみましょう
    ユーザーストーリーの書き方のコツとして「INVEST」というものがあります。ここでは誌面の関係上説明はしませんが、ぜひ参考にしてみてください。
  • プロダクトバックログアイテムとして適切かどうかを確認してください
    たとえば、「書かれている内容が第三者に理解できない」「受け入れ条件や完了の定義がなされていない」「デモを行うことができそうにない」「優先順位がチームで合意できていない」などといった場合には、その内容をバックログとして組み込んではいけません。
  • タスク自体は残ります
    たとえば、環境の準備など、それ自体はユーザーにとっての価値はありませんが、必要なものです。これ自体はタスクとして認識し、バックログに組み入れてください。
  • 修飾する言葉に注意をしてください
    ユーザーストーリーやプロダクトバックログの中に、「しっかりと」「新しい」「難しい」「簡単な」「すごい」といった言葉が含まれると、どうにでも解釈できてしまいます。つい、こういう言葉を使ってしまいがちなのですが、ユーザーストーリーやプロダクトバックログを記載する際には、何らかの基準のもと判断ができるようにしてください。
    たとえば、「やさしい」であれば、「マニュアルなしで利用できる」などの説明が可能だと思われます。

最後に

前回、今回とプロダクトバックログの成り立ちを見てきました。誌面の都合で触れなかった部分や、さらっと流した部分もありますが、プロセスの概要は理解いただけたのではないかと思います。
前回・今回の内容は目新しいものではなく、先人の「よりよいプロダクトバックログを作る」ための知見を組み合わせてプロセスにしたものです。人によっては、多少の進め方の違いなどはなどにありますが、この流れでプロダクトバックログを作ることができると考えます。
しかし、実際にはうまくいくチームもあれば、そうならないチームも出てきます。この違いは「プロダクトバックログを作る」ということが「手法・ツールありきではないこと」に尽きます。前回・今回と書いたものはあくまで手法・ツールとその使い方です。手法・ツールは非常に重要ではありますが、その本質は「プロダクトバックログを作る」過程を通じて、実現しようとしているサービスをチームメンバが理解し、そのサービスの価値や目指すところ、具体的なサービスイメージを共有することなのです。
それができれば手法やツールは何でもよいのですが、先人が提供してくれた知見を使わない手はありません。これらを有効活用して、よりよいコミュニケーションを図り、価値の高いプロダクトバックログを作り出してほしいと思います。

※図は技術評論社の許諾を得て掲載しています。

  • 注1) 本来は、「ナラティブフロー」などの用語があるのですが、少し意訳しています。