Zenn
💨

「うーん、いらない」を防ぐために。バックログを機能ベースからUXベースにするにインプットを変えていく

に公開
UX
スクラム
プロダクトバックログ
ユーザー体験
idea

前提

この記事の想定読者は
・2BのプロダクトやSaaSを開発していて
・内製開発している
・スクラムをしている
・でもうまく回っていない
開発現場のエンジニアを想定しています。

逆にSIerやSESや営業のいない2Cだとお役に立てないかと思います

スクラムにおけるバックログ

「うちはスクラム開発やってます」
そういうチームのバックログ（プロダクトバックログ）を見ると機能ベースで記述されている場合が多いです。
これは
・スクラムを始める前から機能ベースでやることリストを作っていたor開発予定を機能ベースで管理していた
・スクラムを導入した際にバックログ（プロダクトバックログ）という概念を導入したがその中身をどう記述すべきか分からなかった or 機能ベースからUXベースに変える意義が分からなかった
・そもそもスクラムガイドにUXベースでプロダクトバックログアイテム(PBI)を書けとは書いていない
という理由でおきがちです。

しかしスクラムにおけるバックログはUXベースで記述することを推奨されるケースが多いです。
その理由として推奨されるもののうち私は以下のものが推奨される理由だと考えています。
・計画の変化に強いから
・また当初計画していた機能を実装できた際、期待していたユーザーの体験を満たすことができるかを判断できるから
・プロダクトバックログアイテム(PBI)で何をすべきかの軸とゴールがブレにくいから
・機能自体は実装されているが目的としていた便益を達成できないケースを検出しやすいから

さらに付け加えればこの理由が自分的には一番大きいです。
・せっかく完成させた機能がユーザーに「うーん、いらない」と言われるのを防ぎやすいから

他の機能を後回しにして完成させたのにいざリリースしたらユーザーからいらないと言われると、じゃあこれは何のために作ったんだよ。これが必要だと言い出したのはなぜなんだ、誰が言い出したんだと言いたくなります。

バックログの機能ベースとUXベースの違い

こんな感じです。

文字数の関係で省略していますが、UXベースのPBIのユーザーシナリオはターゲットの人物やユーザーペルソナが何かをできることで何がしかの便益を得るこことができるよう記述するべきとする本が多いです。

UXベースのバックログにあって機能ベースにないもの

UXベースのプロダクトバックログアイテムには「"誰"が"何を"することで、"どのような利益"を得るか」が書いてあります。
機能ベースのプロダクトバックログアイテムにはどんなペルソナユーザーを狙っているか、どんな利益を得るかが書いていません。
この情報の欠落が「うーん、いらない」につながるのです。

バックログをUXベースで書くことに利益があるなら、なぜ多くのチームで機能ベースでバックログが書かれるのか。

そもそも多くのチームではなぜ機能ベースに固執するのでしょうか？
機能ベースで納品と開発費用の契約をコミットするSIerのようなスタイルです。
SaaSで行うには少々不向きに思えます。
多くのチームにおいて完成させて「うーん、いらない」とユーザーに言われることは怖くないのでしょうか？
あるいはプロダクトオーナーの企画力が百発百中でいらないと言われることはないのでしょうか？

そもそもバックログの中身は何によって決まるのでしょうか？
インプットは何になっているのでしょうか。
PBIの優先度づけはスクラムではプロダクトオーナーが決めることになっています。
ではなにをPBIとするかはどうやって決まるのでしょうか？
PBIチケットの起票自体はプロダクトオーナー以外でもできます。しかし問題となるのはチケットの中身を作る際に何をインプットとするのでしょうか？

リリース前であればプロダクトオーナーや経営陣が決めることもあるでしょう。
問題はリリース後です。

プロダクトバックログの中身が決まるまでの流れ

まずは開発チームを取り巻く環境を見てみましょう。
開発チームは組織の一部に過ぎず、実際のユーザーとのやり取りは営業が行います。

営業はフィードバックを拾ってきます。
・この機能があれば契約するのに（ARRの上昇の見込み）
・この機能がないと解約も考える（ARR減少のリスク）
・今あるこの機能が使いづらい（現状の課題）

そしてそのフィードバックをもとに、リスクと見込みを天秤にかけて有限の開発リソースを注ぎ込む対象を偉い人は選別し戦略を決めます。
戦略が決定されるとそれがプロダクトバックログに反映されるわけです。

つまりプロダクトバックログを決める前のインプットの時点で機能ベースで話が進んでいるわけです。
これがプロダクトバックログが機能ベースで作られる原因です。

解決のアンチパターン

機能ベースのプロダクトバックログをなんとかしてUXベースにしたい、と考える人もいます。
この問題を解決するためによくあるアンチパターンを書いていきます。

プロダクトオーナーなどが開発チームのプロダクトバックログに突っ込む段階で機能ベースからUXベース
に「変換」するやり方です。

なぜこのやり方がいけないのか？

理由は2つあります。
1つは社内の認識は機能ベースであるために経営陣によるスケジュールの変更やリリースの判断などが機能ベースで行われます。
せっかくUXベースで開発チーム内で扱っているにも関わらず、チーム外からの要求は機能ベースでくるわけです。
「面倒臭いから統一しよう（機能ベースの方に）」という意見が出るのも時間の問題です。

もう1つはプロダクトオーナーが行なっていることはリバースエンジニアリングであり、プロダクトオーナーが「変換」したUXベースのプロダクトバックログアイテムはユーザーの意見に基づいていないからです。
「ユーザーの生の意見→営業がまとめた意見（機能ベース）」という1回の変換のせいで情報が落ち、ユーザーが本来訴える意見を拾えていないことが問題です。
なのに「ユーザーの生の意見→営業がまとめた意見（機能ベース）→プロダクトオーナーがUXベースに変換したプロダクトバックログアイテム」という2回の変換を挟んでさらに情報を落とすのは本末転倒といえます。
せっかくプロダクトバックログを完成させてもユーザーに「うーん、いらない」と言われるなら機能ベースでもUXベースでもかわりありません。

私の提案するパターン

営業先から営業がフィードバック情報を持ち帰る際に、機能ベースではなくUXベースのプロダクトバックログアイテムを作れるレベルの情報を持ち帰るようにします。
こうすることで余計な変換を発生させず、ユーザーから得た情報を取り落とさないようにします。

このアプローチの問題点

SaaSの営業は営業の専門家ではありますが、UXベースでPBIチケットを作れるようユーザーの意見をヒアリングするスキルには長けていません。
またそれができるようになるまで育てるにも時間がかかります。
素人がヒアリングした結果をもとにPBIチケットを作るのでは情報が落ちるため、UXベースから機能ベースに変換する時と同様の問題が発生するでしょう。

そこで優先度の高いPBIチケットについてはUXベースのPBIチケットを作れるようヒアリングスキルのあるメンバーも同席させた会議体を1つ挟んでみてはどうでしょうか。

そもそもなぜ営業のヒアリングが問題になったのか

今までのSaaSでは営業がヒアリングした内容が機能ベースでも問題ありませんでした。
なぜでしょう？

問題となっているのは「おそらくユーザーはこれが欲しいのだろう」という推測に基づいて作られたPBIチケットを完了までもっていき、機能を完成させたにも関わらずユーザーが「うーん、いらない」と言うことです。
資金とリソースと時間を突っ込んだにも関わらず価値が得られなかったわけです。
今までは「うーん、いらない」とは言われなかったのはなぜでしょうか？

およそ3つの原因が考えられます。

「あれもこれも足りない」プロダクトでは「うーん、いらない」と言われることは少ない

若いプロダクトの場合競合に比べて足りない機能が多すぎる場合です。
バイクで言えばブレーキもサドルもエンジンもない。これキックボードですよね？というようなプロダクトならブレーキやサドルやエンジンをつけても「うーん、いらない」と言われることは少ないでしょう。

しかし機能が揃ってくると「それをつけられても使わないんだけど……」という機能が増えてきます。

対象ユーザーが変化し、バックログのインプットが営業が持ち帰るヒアリング情報に偏った

近年のSaaSが主に訴求する対象の変化です。
大規模法人、いわゆるエンプラが主な訴求対象となりました。

個人やSMBが主なユーザーだった頃は、ユーザー側の担当者のフットワークは軽く、ヒアリングを申し出れば1万文字を超える長文を送りつけてきたり自社オフィスまで出向いてざっくばらんな話を聞かせてくれました。
しかしエンプラ企業、つまり社員数1万人以上の大企業の管理職ともなればそうはいきません。
特に大企業の管理職ともなればカレンダーのスケジュールは埋まりまくり。
そう簡単に会ってもくれません。

対象となる業務が複雑化し、社内有識者の理解が追いつかなくなった

エンプラ企業が主な訴求対象となったことが影響しています。
エンプラ企業の社内業務フローは複雑で、複数部署や複数職種が絡んだりもします。

クラウド会計SaaSで例えていえば、昔は仕訳を切るため取引の登録の話だけしていればよかったのに、今は取引先の登録や反社チェック。請求書の発行や売掛金管理、ERPに絡んだ他諸々。
そういったことまで考えないといけません。

さらに企業独自の業務ルールでxx企画課がデータ分析のための機能を要求したり、内部監査のチェック機能が必要だったり、マネージャー向けにリッチな分析機能が必要になったりします。

この複雑なユースケースをカバーする機能を開発することは開発を複雑に、そして大規模にします。
それはすなわち伝言ゲームの途中で「うーん、いらない」が生まれやすくなります。

機能1つあたりの開発コストが大きくなった

昔は機能1つあたりの開発コストは少なく、1ヶ月にいくつも機能をリリースすることができました。
しかし例えばマネージャー向けの部下の動きや数字を管理するダッシュボード機能とレポート機能を作れと言われるとそれだけでチームのリソースを1ヶ月以上占有することも珍しくはありません。
するとリリースできる機能の数は限られます。
限られたリリースの1つが「うーん、いらない」と言われれば影響は甚大であり真剣に考えたくもなります。
逆に言えば今まではリリースの1つや2つは「うーん、いらない」と言われていましたがリリースの数が多かった頃は問題にはならなかったのでしょう。

まとめ

せっかく開発した機能をリリースしてもユーザーから「うーん、いらない」と言われることはスタートアップにとってはダメージが大きいです。
なんのリターンもなくコストが出ていきます。それはすなわち企業の残りライフポイントを削り落とし、競合に出遅れる「一回休み」を意味するからです。

「うーん、いらない」を回避するためにUXベースのバックログを作りたくなります。
しかしそのためにはフィードバックを機能ベースからUXベースに変える必要があります。
それはすなわちプロダクトに次に加えるものを、営業もUXベースで考える必要があり、そのために新たな学習や「よそもの」を受け入れることが必要になります。

難しいかもしれません。いえ間違いなく難しいでしょう。
しかしそれだけの価値があると私は考えています。

Discussion