どうも。プロダクトオーナーを普段やってるのですが、業務の何割かを占める、改善といいますか、エンハンスメントについて書きたいと思います。
前提として私のプロダクトはB2B2Cで、とある施設に導入いただき、そこのスタッフの方と一般のユーザーがアプリを利用してやり取りをするようなゆるめの業務システムです。エンジニア10名程度の小さめチームで、ゲーム・エンタメや基幹システムとは少し違うと思います。また、日々の改善なので新規企画とも違います。
○○機能を××してほしいです。
お客様や現場担当者からこのような要望を日々よくいただきます。その要望の中からチームのリソースを用いて最良の投資対効果を出すのがぼくの仕事なのですが、ご要望を頂いてチームに落とすまでプロダクトオーナーとして自ら行っている質問を言語化してみたいと思います。
■Clarify（クラリファイ・明確化・深掘り）
1.なんでそれがほしいと思ったの？
→たいていの場合、チームに寄せられる要望はすでに実現手段まで考えていただいていることが多いです。
例）「アプリのグローバルメニューに、AA機能を追加してください。」
しかしながら、多くの場合で実現手段を考えるのはその道で食ってきてる我々のほうがよく知っているはずです。なので、実現手段を思いついた「理由」を深掘りするようにしましょう。
→「なぜAA機能を追加したいの？」→「よく使うからです」→「え、なんでその機能を頻繁に使ってるんですか」→「うちはXXだから、AA機能でZZしてるんです」→「いやーそれ確かにそういう使い方もできますけど、それだったらBB機能にCC用意したほうが嬉しかったりします？」→「たしかに！そのほうが最高ですね」みたいな事がよくあります。
背景にある課題や行動は、利用者のほうがプロであることも多いので、そこは利用者の行動を尊重しつつ、解決手段は作りてのプロが考えるというわけです。
■Volume（ボリューム・量・頻度）
次に、要望の真意がわかったら、同じような要望を持っている人がどの程度いるか考えます。ここはあくまで仮説ベースになりますが、ごくごく一部のユーザーのために全体の改善が滞ったりするとあまり良くないので（ときには必要ですが）量や頻度を見極めます。投資対効果の効果の量です。
2.それを希望している人はどれくらいいるの？
→まずその機能を使っているユーザの人数や割合をみます。できればデータで見ましょう。ヒアリングベースだと人間の肌感は意外とあてにならないことが多いからです。Analyticsなどで該当機能のPVをみたりデータベースの件数をとったりします。
→そして、その上で当該機能に要望を持っているユーザが何割くらいいるかを、こちらはヒアリングベースでアタリをつけます。
3.その行動をする頻度はどれくらい？
→1日3回使う機能が10%良くなる方が、1年に1回しか使わない機能が200%良くなるよりも嬉しいものです。また逆に、高頻度なものは下記の副作用にも慎重になる必要があります。
■Return（リターン・目標到達・効果）
投資対効果のうち効果の「質・方向性」です。
4.それを満たすことで我々の目指す世界に近づく？
→プロジェクトのビジョンや存在意義があるはずです。我々はXXを通して○○を支援し、ZZな社会を実現します！みたいなやつです。それと照らし合わせて方向性がずれていないかを考えます。
あまりいい例えが見つかりませんが、暗算力を向上するという存在意義があるのに、計算ドリルに電卓機能をつけてくれという要望は方向性がずれているといえるでしょう。
5.それを満たすことでビジネス成果が出る？
→リソースは有限なので、安定して長期に渡りこのプロジェクトが運営できるだけのビジネス成果を出す必要があります。それは会員登録数だったり、売上だったり。直接ではなくても「ユーザー満足度が高まることで解約数が減る」などとビジネス成果にどうつながるかは意識しましょう。
■Method（メソッド・手段）
では、やったほうが良さそうだ。となったらどう実現するかを考えます。ここはエンジニアさんに相談したりします。投資対効果の「投資」を最小化する方法を考えます。なんでもかんでも死ぬほど残業して解決するのはスマートではありません。
6.システム開発でしか解決できない？
→顧客がほしいのは1/4インチの穴が開けられるドリルではなく、1/4インチの穴である。というのは名言ですが、意外とマニュアルを整備するとか、シールを貼るとかQuick Fixのほうが実用性が高い場合があります。
7.どのような実装方法が考えられる？
→松竹梅で考えます。毎日使う機能であれば松案、あまり使わない機能だったり、ほしいと思っている割合がそこまで高くない改善なら梅案など使い分けます。
■Quality（クオリティ・品質）
作る方法がざっくり決まったら、念のため再検証します。本当にそれで良いんだっけ？と一度振り返りを行いましょう。UIUXデザイナーさんやマーケ担当にも場合によっては確認します。
8.改修したことによる副作用はない？
→そこに機能追加することで、初心者が迷うのでは？学習しなければいけないことが増えるのでは？構造が変わることによってマーケの計測値がブレるのでは？「出来ること」が増えることにより「やらなければいけないこと」が増えてしまうのではないか？保守性が下がって今後の開発がスローダウンするのではないか？
→さらに、あちらを立てればこちらが立たず、という改修もあると思います。だからといって管理画面で好きな方法を選べるようにしようなどと安易に逃げると、管理画面でお好みの設定を選ばないと使いづらい玄人向けシステムになってしまいます。
9.それは「あたり前品質」を満たしていない？
→ここまでで投資対効果が見えてきました。しかしながら投資対効果が低くても加点した方がいいものに「当たり前品質」を満たしているかがあります。ユーザーさんの期待値によって異なるのですが、これを満たしていないものは計測しにくいダメージをプロジェクトに与えていることが多いので、納得の行くロジックが思い浮かばなくても経験上加点するようにしています。
→たとえば0.1%のユーザーに致命的ではないエラー画面が出てしまう。投資対効果でいうとあまり高くないので、本来は「1年以内に直します」が妥当だったとしたら、加点して「３ヶ月以内に直します」に格上げすると言った具合です。
■そして最後に
10.今までの話を総合して、投資対効果の度合いは他の課題と比べてどう？
ここまででだいたい投資対効果が見えてくるので、今までに積み上がっている作業タスクとくらべて優先度付がなされ、チームに落とされます。
（ボーナス！）11.とは言えたまにはウェットな判断も
個人的には、チームメンバーとの関係性とか日本的なウェットさも好きなのでたまに判断を捻じ曲げます。
もってくる営業さんの熱意に負けて要望をえこひいきしたり、この要望をやるのはこのエンジニアで、彼の現在の興味とも合致するから優先度あげちゃっていいやといった、やりすぎると良くないけど適度（10%以下くらい）にそういう「余裕」も入れたいなと。
だって、あくまで仮説だしどこまでいっても完璧な判断はないから、チームが楽しく働けるほうが総合的にいい仕事できる気がするんよね。
ブコメなどでツッコミお待ちしております。
