魅力的なプロダクトバックログで開発を楽しく! このエントリをはてなブックマークに登録

2014年07月15日

irohirokiirohiroki

どんな開発プロセスでも製品やサービスを作るときは何からの形で要件をまとめると思います。KRAYが採用しているアジャイルソフトウェア開発フレームワーク『スクラム』では、製品やサービスの要件リストをプロダクトバックログと呼びます。実はこのプロダクトバックログ、その書き方や運用の仕方で開発のモチベーションが大きく違ってきます。書き方一つで、開発チームにとってもプロダクトオーナーにとっても見るのが楽しみな資料になりうるのです。

今回は、見るのが楽しみになる魅力的なプロダクトバックログを作るコツについてお話しします。

プロダクトオーナーから見たプロダクトバックログ

最初にプロダクトバックログのライフサイクルについて簡単におさらいします。

開発が決まったら、プロダクトオーナーは製品のビジョンを実現するために必要な機能などをユーザーストーリーと呼ばれる文章で表現し、プロダクトバックログに追加していきます。製品のビジョンを正しく表せていれば、この作業はプロダクトオーナー以外の人がやっても問題ありません。

プロダクトバックログに含まれる項目をプロダクトバックログアイテムと呼びますが、全てのプロダクトバックログアイテムは優先順位順に並べなければいけないというルールがあります。この優先順位をつけるのはプロダクトオーナーであり、他の人が決めることはできません。優先順位を付け終わるとプロダクトバックログは完成です。

完成と言っても、そのまま保管するという意味ではありません。プロダクトバックログは活発に更新されていくものです。今は便利なオンラインツールが普及していますので、プロダクトバックログもオンラインで作成し、開発の進捗を一緒に管理するのも一般的です。開発チームは優先順位の高いものから開発を始め、着手したアイテムには「開発中」、開発が終わって実現されたものには「完了」のしるしを付けます。

新しく見つかった要件や問題の修正など、リソースを必要とするものは随時プロダクトバックログに加えられます。そして優先順位を付けられ、時には既存のどのアイテムより優先になることもあります。

このように、プロダクトバックログは常に開発の状況と道筋を反映し続けます。

さて、以上のように運用された理想的なプロダクトバックログがプロダクトオーナーにとってどのように見えるか考えてみましょう。まとめると次のようになるはずです。

  • 製品のビジョンが全て表されている
  • その中でも優先順位の高いものが上に集まっている
  • 優先順位の高いものから開発が進み、完了になっていく

いかがでしょうか?自分が製品の価値に責任をもつプロダクトオーナーだったら、こんなに見ていて楽しいものはないはずです。このように、本来プロダクトオーナーにとってプロダクトバックログは非常に魅力的なツールなのです。

開発チームから見たプロダクトバックログ

開発チームにとってプロダクトバックログは、自分たちとプロダクトオーナーを繋ぐ接点になります。

直近(1〜2スプリント先)に着手しそうなアイテムについて、開発チームはプロダクトオーナーから内容を聞き、理解しておかなければなりません。逆にプロダクトオーナーは開発チームが納得するまで質問に答える責任があります。こうすることでプロダクトバックログの上の方にあるアイテムは開発チームにとって理解できる、迷いなく開発に入れる項目になります。

また、上の方にあるということは優先順位が高い、プロダクトオーナーがより強く欲しているものであり、実装する価値が保証されているアイテムです。プロダクトバックログの上から着手している限り、役に立つかどうかわからない、気の滅入るような機能を実装してしまうことはないのです。

さらに、プロダクトバックログがあることで開発チームは無理な労働を強いられる可能性も減ります。なぜなら、ある程度の時間を要する仕事については必ずプロダクトバックログに登録し、優先順位を設定しなければならないからです。開発チームの時間をどう使うかはプロダクトオーナーの責任であり、関係者だからといってプロダクトバックログにないことを開発チームに無理やりやらせることはできないのです。

開発チームから見たプロダクトバックログについてまとめると次のようになります。

  • 内容の分かる要件が直近の仕事として並んでいる
  • 上から着手することで自分の仕事の価値が保証される
  • 割り込み作業から守ってくれる

このように、プロダクトバックログは開発チームにとっても快適な、メリットの多いツールだと言えます。

魅力的にするには?

ここまでプロダクトバックログの魅力について語ってきましたが、残念ながら勝手に魅力的になるわけではありません。ここからは見るのが楽しみになるプロダクトバックログづくりのコツについて説明します。

まず思い出していただきたいのは、ユーザーストーリーを書くときの要点を表すINVESTです。これは以下の頭文字を取ったものになっています。

  • Independent(独立している
  • Negotiable(交渉可能
  • Valuable(価値がある
  • Estimable(見積り可能
  • Sized right / Small(適切な大きさ
  • Testable(テスト可能

これらの要点をおさえられれば、経験上、問題の8割程度は解決できます。よくある問題と解決方法を簡単に紹介します。

Independent / Sized right

プロダクトオーナーだけでプロダクトバックログを作ると違反しやすいのがIndependentとSized rightです。つまり、巨大で渾然一体になったユーザーストーリーを作ってしまいやすいのです。

このようなユーザーストーリーは結果的にEstimableとTestableを犯していることも多いので、解決の際にはまずこの4点のうち分かりやすい視点で分解していけば良いと思います。ユーザーストーリーはValuableやTestableが成り立つ範囲で小さい方がうまくいきます

IndependentやSized rightの問題は、開発チームが見るとすぐに気づきます(何から始めればよいのか読み取れないので)。ですので開発チームのメンバーは気づいたらプロダクトオーナーに教えてあげてください。また、プロダクトオーナーはユーザーストーリーを書いたときにまずこの2つをチェックすると良いと思います。

Estimable / Testable

EstimableとTestableの侵害は、慣れたプロダクトオーナーでないと気づくのが難しい問題です。内容に曖昧な点があるとか、具体性に欠けるときによく起こります。

これも開発チームの方がよく気づくので、スプリント開始までに会話をして解決しましょう。幸い、IndependentやSized rightの問題よりも解決しやすいことが多いものです。

Negotiable

交渉可能なユーザーストーリーとはどういうものでしょうか。それは、機能の結果や得られるものは明確にしながら、デザインや実現方法には幅を持たせたものです。例えばUIのアニメーションや応答時間まで細かく指定してしまうと交渉の余地がなくなり、本当に必要な機能が他にあるにも関わらずアニメーションの実現等に時間を使ってしまうことも起こりえます。

本当にそういったディテールにビジネス価値がある場合は、そのディテールだけを独立したユーザーストーリーに切り離し、優先順位をつけるとよいでしょう。

Valuable

価値があること。これはユーザーストーリーにとって最も大切な点です。

プロダクトオーナーがユーザーストーリーを作る場合、主観的な想像で価値があると思ったことが実際には全くビジネス価値がなかった、ということがしばしば起こります。これを解決するには検証プロセスが必要ですが、本ブログエントリの範疇ではないので省略します。

開発チームがスクラムを導入し、プロダクトオーナーに代わってプロダクトバックログの作成している場合も、ビジネス価値のないユーザーストーリーを書いてしまうことが非常によくあります。開発チームは実際の作業を思い浮かべることができるので、その作業一つ一つをユーザーストーリーにしてしまいがちなのです。例えば仕様書の作成はその組織のルールでは必要なのかもしれませんが、恐らくエンドユーザーには何の価値もないでしょう。結果的にプロダクトオーナーが見ても退屈なアイテムの羅列になってしまいます。

単独ではビジネス価値がないけれども必要な作業は、価値を生み出す作業とひとまとめにしましょう。そうすればプロダクトバックログの魅力が戻ってきます。

見た目の問題

魅力的なプロダクトバックログは中身が重要です。しかし、プロダクトバックログはプロダクトオーナーと開発チームの両方が更新してお互いに見てもらうものなので、見た時の印象も同じくらい大切です。そこで、ユーザーストーリーの表現について幾つかコツをご紹介します。

欲しいものを書く

作業内容ではなく、欲しいもの、実現したいことを文章にすると魅力的になります。例えば次の文を見てください。

フィード画面のスクロール位置による次ページ読み込み処理を自動化する

これは魅力的に見えるでしょうか?読みやすいでしょうか?例えば下のように書き直したらどうでしょうか。

スクロールするだけでフィードの続きを読める

期待されているものを端的に表すと、魅力的かつ見やすくなります。

ラベルを使う

あるテーマを持った大きな要件が複数のユーザーストーリーを含んでいる場合、テーマを表すラベル(タグ)を作ることで同じ文言の繰り返しを避けましょう。例えば、次のリストを見てください。

写真投稿機能の追加 詳細ページで写真を投稿できる

写真投稿機能の追加 ユーザが自分の写真を削除できる

写真投稿機能の追加 管理者が写真を削除できる

全てのアイテムに「写真投稿機能の追加」と書かれており、冗長です。

プロダクトバックログの管理に使うツールによって違いますが、いわゆるラベルやタグといった仕組みを使い、簡潔に読みやすくしましょう。もしオンラインのスプレッドシートを使うなら、ラベル用の列を用意すればよいでしょう。実際の表示形式はツールによりますが、例えば下のようになれば成功です。

写真投稿 詳細ページで写真を投稿できる

写真投稿 ユーザが自分の写真を削除できる

写真投稿 管理者が写真を削除できる

この方が本当に望まれていることが分かりやすくなったと思います。

1画面に収める

製品やサービスで実現したいことを列挙し始めると膨大な量になることがありますが、関係者の関心が高いものは1画面で全て見られるように努力しましょう。関心が高いというのは、例えば直近2スプリント分とか、次のリリースまでの分、という具合です。

収まらない場合は、次のような方法で数を減らせないか見当してみてください。

  • 関連するユーザーストーリーをまとめる
  • 小さなユーザーストーリーを他のものの一部にする
  • 他のユーザーストーリーに依存するものを依存先に含める

1画面で見られるようにすることで、見やすさは確実に向上します。

プロダクトバックログのためのツール

プロダクトバックログの管理はこれでなければできないというものはありませんが、以下の条件を満たすものが良いでしょう。

  • 関係者全員がいつでも参照/更新できる
  • 更新がリアルタイムに反映される

KRAYで使っていてお勧めできるのはPivotal Trackerです。スクラムのスプリントや相対見積りの概念も組み込まれており、KRAYでは開発に欠かせないツールになっています。

まとめ

  • 理想的なプロダクトバックログはプロダクトオーナーにとっても開発チームにとっても魅力的
  • ユーザーストーリーはINVESTでチェック
  • 見た目にも気を配ってより魅力的に

魅力的なプロダクトバックログで開発を楽しくしましょう!

最後にお知らせです。KRAYに興味を持っていただけましたら、FacebookでKRAYの活動をお知らせしますので、下のいいね!を押してください。よろしくお願いします。

  1. メモからはじめる情報共有 DocBase 無料トライアルを開始
  2. DocBase 資料をダウンロード

「いいね!」で応援よろしくお願いします!

このエントリーに対するコメント

  1. コメントをどうぞ

    ishizima

    2014年07月17日, 12:32 PM

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)


トラックバック

we use!!Ruby on RailsAmazon Web Services

このページの先頭へ