🗽

「開発」はユーザーからフィードバックを得るための手段であって目的ではないよって何度も言いたい

2023/06/15に公開

ポエム

ポエムです。

概要

私たちが「ユーザーはこれがほしいだろう」と考えているものはだいたいズレているので、小さく作って早くフィードバックをもらうのが効率的です。
「いきなり自動車を作るのではなく、まずスケボーを作ってリリースしてみよう」というやつです。
「開発」はユーザーからフィードバックを得るための手段であって、本来の目的である「ユーザーが何に価値を感じるのか・感じないのかという学びを得ること」を置き去りにしてはいけないよという主張をつらつら書いてます。

目的のない開発になっていないか

事業立ち上げ期の「開発」は、以下２つの仮説を検証するために行うものです。

この機能にユーザーは価値を感じてくれるだろう、という仮説
ユーザーの感じる価値は、事業が継続できるくらいの利益に変換できるだろう、という仮説

これらの仮説が間違っていた場合、

誰も使わない機能に工数を使う
使ってくれる人はいるけどお金にならない

といったことが起こります。

これらの仮説が暗黙的なプロジェクトは無為な開発をすることが多いと感じたので、アンチパターンとしてまとめたいと思います。

アンチパターン

仮説がない

そんな馬鹿なと思うかもしれませんが、意外とよくあります。

誰が = ペルソナ・ジョブ
なぜその機能に価値を感じるのか = 価値仮説

の２つが言語化されておらず、ステークホルダーの間でズレがあるため、誰にも刺さらない折衷案的な機能を開発したり、その開発が成功か失敗かも分からずうやむやになります。

「誰がこの機能を使うのだろう、、？」とみんな疑問に思いながらも粛々と開発は進んでいきます。

エンジニアに共有されていないだけかもしれないので、プロダクトオーナー(PO)に問い合わせてみるのが第一歩です。
ただし注意しなければならないのは、POやプロダクトマネージャー(PdM)に質問するとそれっぽい答えは返ってくることです。
何度か質問してみて、返答が一貫しているか確認してみましょう。
聞くたびに仮説が変わる場合は、仮説を言語化してチームに周知し変更できないようにすると良いでしょう。

仮説の評価指標がない

指標がないため、機能のリリース後に仮説が正しかったのか評価できなくなります。
「なんとなくリリースできてよかったね、まあユーザーが喜んでるかは知らんけど」という状態です。

つらいのは、失敗とも言い切れないところです。
止める判断ができないので、開発リソースを注ぎ続けることになります。

開発以外の手段を検討していない

開発の目的は「誰がなぜ使うのか、お金になるのか」を検証することなので、他に楽な方法があるなら開発する必要はないです。

ユーザーインタビューする
人力でプログラムの代わりをする
Google Formやyoutubeといった既製品を組み合わせる

などなど、仮説を検証する手段は無数にあります。
「そもそもこの開発必要ですか？」はslackのリマインダーで毎日送ってもいいくらい大事だと思います。

開発するときに完璧を求めすぎる

仮説を検証するために最低限必要な機能(MVP)が適切ではない場合がよくあります。

お金を払ってでもその機能を使いたいユーザーであれば

少しデザインがダサい
誤字がある
機能が足りない(フォローできるけどフォロー解除できないとか)

としても使います。
砂漠で喉が渇いている人は、「コーラじゃなきゃ飲みたくない！」とは言わないですよね。

むしろ完璧な状態でリリースすることは価値仮説の検証に悪影響です。
さほどニーズがないユーザーでも使ってくれるようになるので。(ただしお金は払わない)

まとめ

仮説を言語化しよう
仮説を定量評価しよう
仮説を検証するためのミニマムな手段を考えよう
もし開発するとしてもスコープを最小限にしよう

説明しやすさのためにアンチパターンを書き出しましたが、逆に言うと仮説設計がしっかりしているチームはとても働きやすいです。
「仮説を検証するために最適な方法は何か？」をみんなで議論し、どうしても必要なものだけ実装します。
実装後ユーザーに刺さらなくても素早く損切りしてコードのメンテが不要になります。

仮説のチェックシート

ペルソナ
- 誰がその機能を使いますか？
価値仮説
- ユーザーはなぜその機能を使いたいと思うのですか？
アウトカム
- 仮説が正しいと判断できる計測可能な指標はなんですか？
- その指標がいつまでにどの程度の数値であれば成功ですか？
その他
- そもそも開発しなくても仮説を検証する手段はありますか？
- その開発スコープはミニマムですか？