WhyとHowをつなぐプロダクトバックログを書こう
<この記事はコンセントリクス・カタリスト（以下「CC」）にプロダクトマネージャーとして新規入社したメンバー向けに書かれた社内ドキュメントを編集したものです>
プロダクトマネージャーの日々の業務のうち、実際のプロダクト開発に最も直接的に関わるのがプロダクトバックログの作成であると言えます。ビジネス要件・体験設計を元にプロダクトの要件を定義し、その後のUIデザイン・実装のフェーズにつないでいくための重要なステップです。
「使いたいを、カタチに」を目指すコンセントリクス・カタリストのプロダクト開発において、プロダクトバックログの作成はWhy(達成したいユーザー体験)とHow(UIデザイン・実装)をつなぐためのWhat(なにを作るか)を定義する作業であると言えます。
作成にあたる関係者も多い性質上、ビジネス・デザイン・エンジニアリングとプロダクトバックログの作成時に意識すべきことは多岐に渡ります。本稿では、プロダクトバックログ作成の際にCCのTech Leadである高松が考えていることをできる限り様々な角度から書いてみようと思います。
プロダクトバックログを作成、運用していくあなたの参考になれば幸いです。
体験のデザインからプロダクトへの変換
「使いたいを、カタチに」を実現するためにはユーザーの使いたいの設計 ＝ 体験のデザインを出発点にする必要があります。ここでは体験のデザインをどのようにプロダクト計画に変換していくかを見ていきましょう。
Whyを定義する体験設計、Whatを定義するプロダクトバックログ
Why > What > Howと詳細化を進めるステップのうち、Whyが体験設計、Whatがプロダクトバックログにあたります。この順番が前後してはいけません。
以下の図は2021年5月のセミナー「最先端のデジタルプロダクトの作り方」の中で「使いたい、をカタチにするための秘訣」として紹介したものの一つです。この図ではユーザーストーリー > 機能要件 > UIデザインの順でWhy > What > Howを詳細化するプロセスを示しています。
ここで避けるべきパターンとして紹介しているのが、アイデアから直接機能要件の検討に進むパターンです。「市場には○○という機能をもった製品がないから作ろう」とスタートし、どうやったらそれを作れるのか要件定義をする、というパターンがこれにあたります。この方法の問題点はなんでしょうか？
先のWhy > What > Howの詳細化の順で言えばこのプロセスではWhyが抜けています。市場にまだないから、がWhyであるとも言えるかもしれませんが、それが自社のプロダクトに必要な理由、まして自社のプロダクトのユーザーにとって必要な理由にはなりません。
アイデアから機能要件に直接進むWhyが抜けたプロセスを避けるべき最大の理由は「実際に作ったが使うユーザーがいなかった」という残念なケースを避けるためです。さらに言えばWhyが抜けているので、作成した機能が使われなかった理由を検証して学びをえることも難しくなります。プロダクトバックログを書き終え、アジャイル開発でBuild - Measure - Learnのプロセスを高速に回したとしても、振り返るべき出発点がなければ意味がありません。
我々が目指す「使いたいを、カタチに」の実現のためでいえば、Whyはユーザーの体験を実現するためとなり、そのためのインプットはユーザーストーリーである、ということになります。機能の定義に入る前に、ユーザーストーリーやペルソナ、コアバリューといった体験のデザインのアウトプットを読み解き、プロダクトバックログを作成する際にも何度でも立ち戻りましょう。
ユーザーストーリーの体裁を保てばよい、というものではない
CCで作成するプロダクトバックログの最初に書く項目はユーザーストーリーにしています。Whyにあたる体験のデザインを出発点とするためです。
しかし、世の中に存在する多くのプロダクトバックログにはユーザーストーリーが含まれているものの、ユーザーの体験を表すものになっていない場合も多いのが現状です。なぜでしょう？
「ユーザーストーリー フォーマット」のように検索するとたくさんの例が表示されます。代表的なものであれば以下のようなものでしょう。
{Who}が、{What}をできるようにする。{Why}という課題があり、{ToBe}になるからだ。
このフォーマット自体は大変優れています。かならずWhyが含まれていますし、Whoでペルソナを思い浮かべることもでき、Whatで実際に何を作るのかを簡潔に示すこともできます。問題はこのフォーマットの運用方法です。
例えばフォーマットにのっとって以下のようなECサイトの商品一覧のユーザーストーリーを書くことができます。
購入ユーザーが、商品を一覧で閲覧できるようにする。商品をまとめて見たいという課題があり、一覧で閲覧できるようになるからだ。
(実際ここまで直接的な例は珍しいですが)このユーザーストーリーはトートロジーです。フォーマットがユーザーストーリーであるだけで「商品一覧機能を作る」という事実が繰り返されているだけでWhyにあたる情報が欠けています。
こういったユーザーストーリーが書かれる背景にはプロダクトバックログを書く際に作る機能(What)のイメージを強く持ちすぎていることがあると考えられます。Why→Whatの順序が逆転し、What→Whyを定義してしまっている状態です。
ユーザーストーリーの体裁を保ちさえすれば、体験設計をスタートにしたプロダクトバックログが書けるわけではないことがわかりました。しかし、いくら体験のデザインからスタートする基本姿勢をもっていたとしても、多くの関係者のフィードバックを受け、スケジュールにも追われるプロダクト開発の中で、誰しもWhy→Whatの順番を逆転させてしまう可能性があります。
そういった時には深呼吸してプロダクトを超えてユーザーに視線を戻しましょう。ペルソナ・コアバリュー・ユーザーフローといった体験のデザインの成果物はそのきっかけを与えてくれます。また、一緒に働くUXデザイナーはユーザー視点に立つプロフェッショナルです、あなたをユーザーに再度向き直させてくれる助けをしてくれるでしょう。
体験のデザインが重要なのは分かる。でも、ビジネス成果の方が重要でしょう？
プロダクトをなぜ作るのか、に対する答えは色々と考えられますが「ビジネスゴールの達成のため」は「ユーザーの体験のため」と並ぶ外せない有力な理由となります。「使いたいを、カタチに」を目指すプロダクト開発であってももちろんビジネスゴールの達成が求められることは変わりません。ここでは体験のデザインとビジネス観点とのつながり、またそれをどうプロダクト計画につなげるかについて考えます。
体験のデザインとビジネスは併せて考える
以下の図は先のセミナーの中でのUXデザインパートのスライドです。「ユーザーが欲しがっているのはドリルではなく穴である」という有名なフレーズを題材にした内容で、このセミナー資料の中で個人的に最もお気に入りのスライドです。
「体験のデザインが重要なのは分かる。でも、ビジネス成果の方が重要でしょう？」というのは言葉には出さずとも、実は多くのプロダクトオーナーが心のうちに秘めている本音ではないでしょうか？「使いたいを、カタチに」を掲げるCCのメンバーならば持論を持って自分なりの答えをもっているとよいFAQだと思います。このスライドはその問いに対する一つの回答になり得ると思います。
ユーザー側とビジネス側の狙いはそれぞれ異なるが、両立する1つの解決策は存在する
体験のデザインとビジネスは並列して分離して考えるべき事項ではなく、よってどちらを優先すべきという順序も決められません。プロダクトバックログを書き、Whatを定義する段階では、欲張りですが双方を満たす解決策を探す姿勢が必要です。常にビジネス・ユーザー体験両方の価値を最大化する方法が見つかるとは限りませんが、決して諦めてはいけません。
違う言葉で言い換えてみる
「体験のデザインが重要なのは分かる。でも、ビジネス成果の方が重要でしょう？」のFAQの背景には、必ずしもユーザー体験がビジネス成果と直結しないイメージを持たれていることがあるでしょう。この問いに対して自分なりの回答を用意しつつも、時にはその問いを抱えた相手側の視点にたって言い換えてみるのも有効な手段だと感じます。
例えば私自身も含めてソフトウェアエンジニアは「課題・Issue」という言葉に特別、かつポジティブな感情を持っている傾向があると思います。ソースコードのホスティングサービスであるGitHubでは様々な規模のオープンソースソフトウェアが開発され、ソースコードの管理のみではなくソフトウェアを取り巻くコミュニティの要素も強く持っています。GitHubの主要な機能の一つは「Issue」で、ここにバグのレポートや改善の要望、新機能の提案が行われ、その後のソフトウェアの改善に役立てられます。時には深刻なIssueがあり議論が白熱するものもありますが、多くの場合Issueはソフトウェアをよりよく改善するための題材、として捉えられていると思います。Issue・課題はネガティブなものではなく、むしろ難しい課題・Issueを見つけるとどう解決してやろうか、と情熱を燃やすソフトウェアエンジニアも多いでしょう。
難しい課題を解くことに情熱を持つソフトウェアエンジニアに対しては「この体験によってユーザーのペインが解消される」よりも「このソリューションによってユーザーが抱える課題が解決される」という表現の方が魅力的に映るかもしれません。細かなニュアンスの違いから抜け落ちるものもあり、長期的には体験のデザインが共通言語になることを望みたいですが、まず最初の一歩としては上々ではないでしょうか。
「使いたいを、カタチに」のプロダクト開発でWhyであるユーザー体験は、あなたが対峙しているチームメンバー、クライアントにとっては違う言葉で言い表せるものかもしれません。異文化交流のつもりで時には相手の側にたち、相手の使う言葉に耳を傾けるのもよいかもしれません。
プロダクトをカタチにするためのより良いインプットになるには
ここまで体験のデザインやビジネスゴールなどプロダクトバックログのインプットになる事項との関連を見てきました。それとは逆にUIデザイン・開発やQA計画はプロダクトバックログを出発点として開始されます。ここではカタチにする段階でプロダクトバックログがより良いインプットになるためにはどうすべきか考えてみましょう。
適度な抽象度を保って書かれていること
Why > What > Howと詳細化していくプロセスで真ん中のWhatの定義にあたるのがプロダクトバックログです。その立ち位置上、過度に抽象的すぎてもカタチにする際のインプットとしては不十分ですし、詳細過ぎても作成に時間がかかるうえ、実際にデザイン・実装する際の自由度を下げ邪魔にすらなりえます。プロダクトバックログは適度な抽象度を保って書かれていることが重要です。
適切な、と言うは易しですが実際的にはそのラインの見極めが非常に難しいです。一番の近道は書いたプロダクトバックログを見せた際のデザイナー・エンジニア・QA担当者の反応・質問を受け止めて改善を続けることです。プロダクトバックログの意図と違うと感じるデザインや実装のアウトプットが出てくるのであればバックログが抽象的すぎ、「○○という他のソリューションの可能性もあるか？」という質問がたびたび出るようであればそのプロダクトバックログはチームにとって具体的すぎる可能性があるでしょう。
動くソフトウェア > プロダクトバックログ
ここまでプロダクトバックログにフォーカスしてその重要性に触れてきましたが、究極の質問としてプロダクトバックログと実際に開発されてリリースされたソフトウェアはどちらが重要でしょうか？ 当然実際に開発されてリリースされたソフトウェアです。
プロダクトバックログはプロダクト開発のための計画で、実際に動くソフトウェアを作ってユーザーに届けるための中間成果物に過ぎません。プロダクトバックログ自体の完成度はプロダクトの良し悪しには直接的に関係ないと言ってもよいでしょう。もし、プロダクトバックログ自体が独立して価値をもつものではないとすれば何のためのプロダクトバックログを作るのでしょうか？
プロダクト開発の目的はプロダクトをリリースし、ユーザーに価値を届けることでビジネスゴールを達成することで、そのための計画の一部がプロダクトバックログです。プロダクトバックログはプロダクトのWhatを定義することで、プロダクト開発に関わる関係者が同じゴールを目指して進めるためのコミュニケーションツールであると言えるのかもしれません。
まとめ
“WhyとHowをつなぐプロダクトバックログを書こう” というタイトルの本稿ですが、プロダクトバックログの作成についてのノウハウ、というよりもプロダクト計画の前後にある体験のデザイン・ビジネス・UIデザインや開発などとのつながりについて触れた内容になりました。それはプロダクトバックログが Why > What > How の流れのうちの真ん中にあることに起因していると言えるでしょう。
同時にプロダクトバックログ自体は中間成果物で、それ自体の完成度を追求しすぎないことも重要です。プロダクト開発に関わる関係者を同じゴールに導き、UIデザイン・開発のインプットとして機能していれば、良いプロダクトバックログが書けていると言えるでしょう。
CATでは、モットーである「使いたい、をカタチに」を実現することで社会をより豊かにしていく仲間を募集しています。ぜひ一緒に新しい「価値創出」をすべく、あなたのご経験を活かしてみませんか？詳しくは下記の採用ピッチ資料、もしくはWantedlyをご覧ください。