プロダクト開発で「意見」と「事実」を行き来する

みなさんこんにちは。@ryuzeeです。

社会人であれば新人の頃から「意見と事実は分けろ」と散々言われたと思うのでいまさらの話ですが、プロダクト開発においてもこれはとても重要なのでいま一度まとめておきたいと思います。

まずは言葉の定義を合わせましょう。DXとかアジャイルとか生産性とかでよくわからんことになるのは、言葉の定義が合っていないがゆえなので、同じことが起きないようにします。この文章では、意見と事実を次のように定義します。

意見:主観的なもの、もしくは、客観っぽく見えても証拠による裏付けが足りないもの
事実:客観的な内容を持ち、入手可能な証拠で十分に裏付けられているもの

「意見」の後半部分が重要です。「サインアップの離脱率が高いのは入力項目が多すぎるからだ」のように、客観的に聞こえる発言でも、裏付けが取れていなければ意見に過ぎません。言い方を変えると「もっともらしく聞こえるけど、それはあなたの意見ですよね？」ってやつです。

今回はプロダクト開発の話にフォーカスするので、1つ軸を追加しましょう。それが「問題」と「解決策」です。プロダクト開発は、突き詰めると「問題を理解する活動」と「解決策を考えて実現する活動」の繰り返しです。

「意見」「事実」と「問題」「解決策」の4象限

「意見」「事実」と「問題」「解決策」の2軸を組み合わせると、以下のような4象限ができます。「意見」「事実」と「問題」「解決策」の4象限それぞれの領域について順番に見ていきましょう。

左上: 問題 x 事実（問題の事実）

この象限は観察された事実を表します。「アンケートの満足度が40%」とか「サインアップの画面の離脱率が80%」とか「解約に関する問い合わせが月50件」のような数字や、「ユーザーインタビューで5人中4人が『どこを押せばいいかわからない』と言った」みたいな定性的な観察結果のように、実際に起きていることそのものです。大小さまざまな問題があると思いますが、いずれも入手可能な証拠の裏付けが必要です。

ここがすべての出発点になります（にもかかわらず、ここを飛ばしてプロダクト開発を進める組織が多すぎる。あとで触れます）。

左下: 問題 x 意見（仮説）

この象限は仮説が来るところです。「サインアップの離脱率が高いのは、入力項目が多すぎるからではないか？」のような事実を踏まえた解釈です。事実から導出しているとはいえ、あくまで解釈なので正しいかどうかはわかりません。

ここで重要なのは「これは意見だ」という認識を揃えておくことです。「サインアップの離脱率が高いのは、入力項目が多いからである」のように事実っぽく扱ってしまうと、何も検証せずに項目を減らす実装に進むことになりかねません。

右下: 解決策 x 意見（選択肢）

この象限は仮説に対して、どう対応するかの選択肢を表します。

サインアップの例で言えば、「入力項目を5つに減らす」「入力のステップを分割する」「自動入力にする」といったものです。単なる意見であり、「これが効くはず」という妄想です。妄想なので外れることも当然あります。

右上: 解決策 x 事実（計測した結果）

開発してデプロイして、実際にユーザーに使われた結果を示します。「入力項目を減らしたら離脱率が20%改善した」とか「変わらなかった」とか「10%悪化した」とか「リリース後にインタビューしたら『前より迷わなくなった』という声が複数出てきた」とかです。これで新しい事実が手に入るので、左上に戻ります。同じテーマで事実が少しづつ変化しながらループすることもあれば、別のテーマに移ることもありますが、プロダクト開発では日々このループを繰り返します。

よくある失敗

ありがちな失敗は、「問題 x 事実」をすっ飛ばし、さらに「問題 x 意見」も飛ばして、いきなり右下の「解決策 x 意見」から始めることです。つまり、何の事実にも、何の仮説にも紐づいていない、誰かが思いついた機能がそのまま実装されます（チームの外から持ち込まれることもよくあります。チームは「何のためにこれを作るのだろう？」と疑問に持ちつつ、言ってもムダだと思って作ります）。会社のプロダクトでこれが起こっているなら、典型的なフィーチャーファクトリーです。

もう1つよくある失敗が、右上の「解決策 x 事実」まで行かないケースです。つまり「リリースしました！」でおしまいってやつです。ループが回らず、「問題 x 事実」が変化したかもわからず、仮説が更新されることもありません。やることが多すぎる組織や期日までにリリースすることが評価軸になっている組織なんかで起こりがちです。

右から左への「逆流」は危険

たまに見かける危険なパターンが、先に解決策を決めて、あとから問題（左上や左下）を~~でっち上げる~~設定するやつです。順序としては以下のようになります。

偉い人なり誰かが「◯◯を作ろう」と言い出す（解決策 x 意見）
PdMが「その問題を明文化しといて」と頼まれたり、もしくは通常のプロセスに乗せようとしたりする
インタビューやデータを漁って、その解決策を正当化する「問題」を後付けで作る
「ユーザーの声で確認しました」「データで裏付けがあります」みたいな体裁を整える
作ってリリースする

これは逆流です。表面的にはループの順番を守っているように他の人たちからは見えますが、実際はそうではありません。これがダメな理由は大きくは3つあります。

1. 事実の選び方にバイアスがかかる

解決策ありきで事実を探すと、その解決策を支持する事実だけが集まります。反証になる事実は無視するか、「それは例外ですね」みたいに扱います。

2. 仮説が機能しない

本来、仮説というのは「外れる可能性があるもの」です。外れたら別の打ち手を試します。でも、あとづけの場合、仮説は「すでに決まっている答えを言い換えたもの」になります。「入力項目を減らすべきじゃないか?」ではなくて「入力項目を減らすべきだ」が最初にあって、その理由をひねり出している状態です。他の選択肢を選びようがありません。