製品バックログの導入

成果が明確になったら、チームは連携し、成果を生み出すのに役立つ製品アイデアについて戦術的に検討できるようになります。そのために実行できる最初の実際的なステップは、製品バックログの導入です。

作業では、多くの製品チームが単一の Jira バックログを使用し、機能リクエスト、大小さまざまな機会、タスクとサブタスク、バグと緊急課題、製品の次の方向性のアイデアなど、すべてを取得している現状を目にします。

どこでも同じ悩みが聞かれました。チケットのリストが増え続けてバックログを管理しきれず、処理に苦慮しているというのです。こうしたバックログが、戦術的な変更から大規模な新規投資に至るあらゆるレベルで、優先順位付けに対応しない状態で、未整理のまま大量に積み上がっていました。

そのためチームでこれらの議論をスプレッドシートに移したものの、四半期ごとに同じことを繰り返すに終わりました。インサイトは失われ、意思決定は記録されず、時間に追われて直感や多数派の意見に基づいてリソースが配分されました。

このような課題への対応策として、日常的な作業のデリバリー バックログとは別に、成果を中心に構築した専用の製品バックログを使用することをお勧めします。

製品バックログとは

製品バックログは、アイデアを創出して優先順位付けし、ロードマップに共有して成果とゴールに結び付ける場となります。すべての製品アイデア、インサイト、機会、ソリューションがまとめられ、製品チームがこれを管理します。これは実行する特定のタスクを計画するのではなく、投資対象とその理由を議論する場になります。このバックログに会社全体の関係者を招待すれば、優先順位やロードマップについてコラボレーションし、進行中の製品イニシアチブの進捗状況概要について討論できます。

製品バックログを、会社全体のコラボレーターと共有できる製品チームの本拠地と考えてください。これは、漠然としたアイデアから完全に形成された機会まで、追跡したいすべてのものを置き、ナレッジや顧客からのフィードバック、全体的な目的の変化に基づいて、時間をかけて練り上げるための専用のスペースです。

製品バックログとデリバリー バックログの違い

製品バックログはデリバリー バックログとは別のもので、それぞれに特定の目的があります。

デリバリー バックログは、デリバリー作業の管理、デリバリー計画の策定、および進捗状況の追跡に使用します。ここにはコミットメントのデリバリー方法に関する作業の内訳 (エピック、ストーリー、タスク、サブタスク) が含まれ、エンジニアリング チームが所有します。チーム全体がここに集まって、順序付けや依存関係、キャパシティ、技術的なマイルストーンなど、デリバリーに関する懸念事項について一緒に話し合います。

当然、製品バックログとデリバリー バックログは密接に関連しています。デリバリー バックログの作業が製品バックログのアイデアへと発展し、それらのアイデア自体が求められる成果に関連付けられます。これにより、リーダー、マネージャー、開発者は、ディスカバリーとデリバリーのサイクルを繰り返す中で、チームがどのように成果の実現に向けて作業を進めているかを俯瞰的に把握できます。

製品バックログとは異なり、デリバリー バックログのすべての項目は、最終的に完了することを意図した具体的な計画となります。対照的に、製品バックログは、アイデア出しやブレーンストーミング、計画のためのものになります。製品アイデアのすべてが優先事項となってロードマップへの採用に至るわけではありませんが、それで問題ありません。

製品の全体像に関する懸念をデリバリー計画と追跡から切り離すと、チームがより効果的に優先順位付けし、作業を成果につなげられます。目的を限定することで、バックログが制御不能にならないようにするのです。

製品バックログのメリット

製品とデリバリーに別々のバックログを使用することには多くのメリットがあります。

• 製品チームにとって、実現可能性や定義を気にすることなく、入手可能なデータとともに、潜在的なアイデアについて安心して議論できる場となります。

• 製品に関する議論が 1 か所にまとめられるため、チームは何十ものスプレッドシートを検索する必要なく、長期的にナレッジを蓄積できます。

• 信頼できる情報源が共有され、製品の優先事項に関する共通の理解が生まれます。これは、意思決定が直感や影響力の強い顧客や関係者の意見に左右されるという、製品チームが一般的に直面する問題への対抗策となります。

• 全社の全員が共有スペースに集まり、優先順位付けの議論に透明性が生まれます。これにより、関係者や顧客対応チームと連携する際の摩擦が大幅に軽減されます。

• デリバリー作業に関連付けられることでロードマップに現状が反映され、デリバリーの制約が考慮されることで現実的なものになります。

製品バックログを整理する方法

アイデア、機会、問題、解決策: 製品チームは製品バックログに何を含めるかを決める必要があります。チームが優先しようとしていることを含めるようにし、製品への投資と優先度についてのチームの考え方を反映させるようにします。

製品チームにとって、製品バックログの内容や、アイデアを分類して優先順位付けするための構造を管理することは非常に重要です。管理しないと、バックログが、本来避けようとしていたような混乱に陥る危険があります。

バックログを管理するには、外部の関係者には項目を直接作成したり編集したりする権限を付与せず、事前に定義された方法で投稿のみができるような形で招待するようにします。たとえば、これらのコラボレーターはコメントの追加、アイデアへの投票、機能をリクエストした顧客へのタグ付けなどができるようにします。

製品バックログを構築するフレームワークとして、boulder (大岩)、rock (岩)、pebble (小石) そして long (長)、medium (中)、short (短) リストの 2 つが推奨されます。製品バックログは、これら 3 つのバケットとこれらのアクティビティを中心に整理することをお勧めします。

Jira Product Discovery では、適切なアイデアが表示されるように特定のビューを構成し、どのフィールド (選択、評価) を表示して議論に役立て、コラボレーション (インサイト、投票、コメント、反応) を促すかを選択します。

boulder、rock、pebble

多くの製品チームでは、「アイデア」が唯一のオブジェクト タイプになります。しかし、バックログには、大胆な新しい挑戦から製品の小さい改良まで、さまざまな形、サイズ、粒度のレベルの項目を含められます。

バックログは次の 3 つのカテゴリの項目で構成することが一般的です。

• boulder: 大規模な投資 (戦略的機会、大胆な新しい挑戦)

• rock: 中規模の投資 (成果につながる製品の大幅な改良)

• pebble: 小規模な投資 (軽微なスタイルのバグや UX の課題の修正など)

製品バックログにこれらのための別々の領域を作成し、それぞれに予算とロードマップのスペースを確保して、3 つの間で投資のバランスをとることが最善です。特に pebble は、そのように意図しないと優先順位付けが難しくなります。大胆な新しい挑戦は刺激的ですが、軽微な問題がユーザー エクスペリエンスに深刻な悪影響を及ぼすこともあります。

このフレームワークの詳細については、アイデアのセクションをご覧ください。

long リスト、medium リスト、short リスト

製品バックログを構成するもう 1 つのシンプルで実用的な方法を、Jira Product Discovery のアーリー アダプターである Brent Johnston が提唱しています。Johnston は、製品作業とは常に long リスト、medium リスト、short リストの 3 つのバケットで作業し続けることであると説明しました。

製品チームは、全社の関係者のコラボレーションを促しながら、製品バックログのアイデアを long から medium、そして short リストへと移動します。

• long リストには、実現可能性が不確かなアイデア、問題、機会、解決策など、すべてを含めます。このリストには 200 以上のアイデアを含められます。

  • 製品チームは、市場、戦略的および運用上の懸念、顧客とビジネスのニーズに関する知識を生かし、この長いリストをキュレーションして medium リストにします。

• medium リストには、優先する可能性のある事項、つまりチームが投資するに値する妥当で魅力的な機会を選択して含めます。long リストの 200 のアイデアのうち、10-20 件が medium リストに到達します。

  • 戦略的に重要で、顧客との話し合いの中で頻繁に出てくる、またはユーザーに歓迎される可能性が非常に高いため、挑戦する価値がありそうなアイデアがこれに該当します。通常、社内のさまざまな関係者からの意見を取り入れてこれらを優先順位付けし、short リストにまとめる必要があります。

    • 詳細については、優先順位付けをご覧ください。

• short リストは基本的に製品ロードマップ、つまり製品チームがさらに探求することを決定したアイデアです。これらのタスクで、機会、問題、または解決策を実行に移して、製品エクスペリエンスの創出または既存のエクスペリエンスの改善に着手します。

  • チームはこのリストを定期的にレビューし、わかったことを反映して最新の状態に保ちます。これは、会社の他のメンバーから定期的なアップデートを最も期待されるリストとなります。

    • 詳細については、ロードマップをご覧ください。

Jira Product Discovery の製品バックログを作成する方法

Jira Product Discovery は、製品チームがアイデアを収集し、それに対するコラボレーションと優先順位付けができる場所として作成されました。Jira Product Discovery では、「ディスカバリー プロジェクト」と呼ばれる、1 つまたは複数の製品バックログを作成できます。

一般的には、日常的に一緒に作業する人を同じプロジェクトで配置することが最善です (分隊、または複数の分隊など)。しかし、Jira Product Discovery の顧客が、1 つのプロジェクトを使って複数のチームや製品をホストするケースがよくあります。そのようなチーム間で高度なコラボレーションが要求される場合に、これが特に役立ちます。

その方法については、次のデモをご覧ください。

Jira Product Discovery Premium プランを使用すると、複数のプロジェクトのアイデアを示し、組織の製品計画の全体像を伝えるビューを作成することで、複数のプロジェクトのアイデアを 1 か所で視覚化できます。

次のステップ

このハンドブックの後半では、製品バックログを次の目的で使用する方法について詳しく説明します。

• 発案からデリバリーまで、アイデアを取り入れる

• アイデアを検証するために、フィードバック チャンネルを設定してインサイトを収集する

• 影響を与える可能性のあるアイデアを優先する

• チームと関係者が心から協力できるロードマップを作成する

Jira Product Discovery やその他の製品を使用して、Jira Product Discovery チームでこれを行う方法の例を示します。