これは何？
半年くらいかけて、プロデューサーの気持ちで案件が決まっていた状況から、
開発チームのプロダクトオーナーとしてKPIを見ながら意思決定できるように改善していった話。
前提
ビジネスサイドと開発サイドが組織としてしっかり分かれており、プロデューサーとプロダクトオーナーがコミュニケーションとりながら機能開発の優先度を決めている
ある日のこと
プロデューサー 「ここのUIをこのアプリみたいな感じにしたいんだよね。こうしたほうがユーザー的にも使いやすいし、CVRも上がると思うんだよね」
開発チーム 「確かにおっしゃる通りですね。バックログが詰まっているので、３スプリント後、３ヶ月後リリースならいけそうです」
プロデューサー「OK.それでいこう」
３ヶ月後
開発チーム 「リリースしました！」
プロデューサー 「お疲れ様。あれから他のアプリとかも見てみたんだけど、**やっぱり〜〜な機能もあったほうがユーザー的に便利じゃないかと思うんだよね。**ユーザーインタビューしていても手応えあるし。実際CVRも伸び悩んでるし、次は〜〜を作ろう」
開発チーム 「今回作ったものの仕様を大きく変更することになりますが、、、」
プロデューサー 「あの時の情報だとそれがベストだと思ったけど、３ヶ月間で色々ユーザーと話したり、色々な人の指摘とかも受けて、これをやるべきだと思うんだよね」
開発チーム 「はあ、、、（リリースしたばっかなのにな、、、）」
問題とアプローチ
事業サイドが強い組織だと、上記のようなことが結構あるかと思います。
エンジニアから見て、上記のようなプロデューサードリブン（要するにお気持ち）で案件が決まると、開発チームの納得感が醸成しにくく、「俺ら、やっていること社内外注じゃね？」と次第に疲弊していってしまいます。
これを**「プロダクトのKPIを民主化する」**というアプローチで解決していきます。
STEP1 プロデューサーに寄り添う
こういう現場に入るといきなり改革を始めてしまいがちですが、何より大事なのはまずプロデューサーに寄り添うというところです。
プロデューサーはエンジニアから見ると直感的に動いているように見えても、実際は細かく数字と向き合い、投資家や上司に対して資料を作成してレポートしています。
なのでプロデューサー単独だとデータを把握している場合が意外とあります。
ただプロデューサーは往々にしてKPIの数値はあくまでステークホルダーにレポートするためのもので、開発チームはそれほど関心がないという認識をしがちです。
なので、まずはKPIに興味があるという姿勢を出し、Excelで頑張ってレポート用のデータを作っていたのを、BIツールなど（例 re:dash,Looker,Domo）などを駆使して手間なく、見やすくすることから始めていきましょう。
そうすることでプロデューサーのレポートのコストも減り、「あっ、エンジニアもKPIに関心あるんだ」ということが伝わり、同じ目線に立って会話することに一歩近づきます。
STEP2 KPIを民主化し、息を吸うようにデータを見る
次にいよいよKPIを民主化していきます。
大きく２つ必要なことがあり
- データを誰でも低コストで見ることができる（ダッシュボードのデザインにはこだわるの大事）
- 誰でも議論を見れる、参加できる場を作る
が重要です。
個人的にアンチパターンだと思っているのがSQL書いて、slackなどに日時でデータを流して、「ほら、これで毎日モニタリングできているでしょう。」ということ、大体の場合、１週間くらいは面白がって見ますが、結局皆読み飛ばすようになります。
なぜかというと、そこには解釈がないから。データを見て、それが何を表すのか考えることは主体者が思っている以上に他のメンバーにとって負荷が高いものです。
なのでチームに広めていくときにはデータを見えるようにするだけではなく、必ず主体者が解釈を添えてレポートする会議体を設定しましょう。
最初は主体者の解釈を中心に議論していって、２〜３ヶ月くらいかけて生のデータから議論が生まれるように進めていきます。
まとめ
何かの機能を開発するときに、「ここのデータってどうなってるんだっけ？」、「リリース後にモニタリングする指標何だっけ？」という話題が自然に出てくれば勝ちです。
この問題の本質は意思決定する時にメンバー間の情報の非対称性が大きいということで、それにより納得感が損なわれるというものです。
同じ目線に立って納得感を持って進めるためには
- 背景の共有（お互い、何をしていて、何に困っているかの共有）
- 事実の共有（同じデータを見る）
- 思考プロセスの共有（データから得られた解釈を共有する）
の順に積み上げていくことが重要です。
最終的にはプロダクトの価値やビジョンをプロデューサーと開発チームが高次元で共有して開発を進めていくのが望ましいのですが、いきなりは難しいのでまずはKPIというプロトコルを通して、同じ目標を見据えるところから始めるのがおすすめです。
プロデューサードリブンな状況では、開発チームは「プロデューサーの気持ちでやることが変わる」と思っていますが、プロデューサー側は「エンジニアはユーザー、マーケットのことを何も分かっていない」と思っているものです。
まずはその状況を受け入れて、お互いに背景を共有して歩み寄り、同じ事実のもと、同じ目標を見ていくことで状況を改善していけると思います。