毎週10個以上の施策を実現するための主体的開発チーム作り

超高速プロダクト改善に必要な価値の高い施策を作り続ける活動は、プロダクトオーナーだけでやっているとすぐにボトルネックになるので、開発チーム全員でできるようにした話を事例を交えながら話します。

はじめまして。Ubie DiscoveryにてAI受診相談ユビーのプロダクトマネージャーをやっている敷地(@shikichee)です。

AI受診相談ユビーの開発では、エンジニアが4人、デザイナーが1人のチームで毎日リリースしており、細かい改善も含めると週に10回以上、年間600回のペースでリリースをしています。(※サービスはアプリではなく、Webのみ)

みなさん超高速にプロダクト改善していますか？

超高速ってどのくらい？って思われるかもしれませんが、今回は毎週リリースしているかどうか、と置きたいと思います。

プロダクトの初期フェーズにおいて、仮説を立て検証しながらの高速開発は必須です。しかし、往々にしてこのような課題が立ちはだかります。

仮説検証を回していくフェーズにもかかわらず、大きな案件を数ヶ月かけてマネージャーに確認を取りながらリリースし、結果としてユーザーに価値を与えたのかどうか分からない事態はよく起きると思います

今回は、いかにこういった事態を避けて、超高速なプロダクト改善できる環境づくりにするかを話します。

事件発生・・！いつの間にかプロダクトオーナーがボトルネックに

2020年10月にAI受診相談ユビーのプロダクトオーナーとなり、最初の数ヶ月は、目標設定やダッシュボードの作成など基本的なことを行って改善していきました。(前回、ブログに書いたのでどうぞ）

スクラム開発を導入しており、以下のようなスケジュールで毎週開発しています。図では、スクラムの説明を省略するため、各専門用語を言い換えています。

公開から半年という仮説検証を高速に繰り返す必要があるフェーズな一方で、プロダクトオーナーの自分を中心に施策を出していたため、すぐに自分がボトルネックになってしまいました。

施策の出す量に限界があり、価値の低い細かい改善施策をやってしまったり、出した機能の検証ができていないという事態が多発していました。

1人に依存しない、開発メンバー全員から施策が出る環境づくりが必要だと考え、以下の3つを行いました。

1. ユーザーの示唆を徹底的に共有する環境づくり

プロダクトオーナーとして、ユーザーインタビューやログの分析から日々情報を収集していました。得た情報を元に意思決定し施策を作っていたのですが、そこでの背景情報が言語化されていないため、チーム内で情報の差が生まれてしまっていました。
その結果、施策を考えるための前提情報が揃っておらず、施策を全員で出せない問題が生じていました。

データだけでなく示唆を共有する
基本的な数値が一覧化されたダッシュボードは作っていました。しかし、日々増えるデータは膨大な量になっており、そこから何かを学びとる作業はあまりできていませんでした。

みなさんのslackでも、毎日botが数値を流しているのにもかかわらず、議論が生まれないのは多々あると思います。

毎日、データを分析して日々気づいた示唆を逐一共有していきました。

この時重要なのは、データを単純に共有するだけでなく、そのデータに対してどういう判断をしたか、示唆があったかを共有する点です。

開発チームは忙しいため一瞬データを見ても、そこで終わってしまいがちです。もう一歩踏み込んで、市場からの学びの共有により新しい議論が生まれるようになっていきました。

ログのモニタリングまでを施策完成の定義に
最初は、手作業で自分がSQL書いて施策の効果検証していました。しかし、徐々に間に合わなくなり、リリースした機能をすべて検証しきれない事態が起きました。また、ダッシュボードが壊れたり、ログが取れていなかったりする事態も発生していました。ログは、取れていないのに気づいた時には大体遅いです。

そこで毎回の施策のリリースごとに必ずログが送信され、モニタリングされるまでを各施策の完成の定義にしました。

結果、施策リリース後の次の日にはすぐに数値とそこからの示唆が共有されるようになっていきました。

また、施策出しと詳細を詰める会の最初に直近の数値と示唆の共有をしたり、リリース施策の振り返りの際にも実際数値がどうだったかの共有を行うようにしています。

仮にslackの情報を見落としていたとしても、会議での共有によって学びが共有される仕組みにしています。

2. 施策を出しやすくする環境づくり

施策を出すハードルを極限まで下げる
施策チケットのフォーマットが、大量のチェックボックスになっていき重厚になっていく現象は、よくあると思います。

一見チェックボックスなどのフォーマット化はコミュニケーションを効率化していくように見えますが、同時に施策を考えるハードルを上げていきます。まずは、極限までフォーマットを簡素化していきました。

起案時点では中身が埋まっていなくてもOKとしています。

そしてさらにハードルを下げるため、施策をアイディアレベルでも随時書き込めるようなslackチャンネルを作りました。

今では、日々メンバーの気付きをとりあえず書く場となっています。施策を出すハードルが高いと、いいアイディアを思いついたとしてもめんどくさいから後にしようとなり、すぐに忘れてしまいます。そういった事態が防げるようになりました。

現在では、7つの他のチームにこの施策出しチャンネルが導入されています。

アイディアを出しっぱなしで放置しない

アイディアが出しっぱなしで放置されてると、「どうせ採用されないから考えても無駄」という思考が発生し、チャンネルは過疎っていきます。

なので、施策の詳細を詰める会の前に、アイディアすべてに目を通し施策を整理したり、全員でアイディアを眺めたりしています。

アイディアを発散させる場を作ったら、同時に収束させる場の設定により、次のアイディアを考えるモチベーションを生みます。

施策を出すハードルを下げ、アイディアを拾う場の設定により、施策の量の確保ができ、施策の量が足りない状況から脱出ができました。

3. 施策をやるかどうかの判断基準を明確に

施策の量は確保できたものの、目標や直近フォーカスしている課題から離れたアイディアも多く、発散してしまう新たな課題が出てきます。

直近注力するポイントの共有
OKRやプロダクトの長期目標の設定により3ヶ月〜半年のスパンで目指していくところは共有できていたものの、直近何に注力して改善していくのかが不透明でした。

そこで、施策の詳細を詰める会の1〜2日前に直近注力するポイントを共有するようにしました。

上の例では、期初にはどの方向性で行くか決まってなかったため施策を幅広く募集し、期末には再来訪につながるような大胆なアイディアを募集しています。

すべての施策のやらない理由を共有する
何に注力しているかと同時に、なぜ他の施策をやらないかを議論するのは重要です。「自分の考えたアイディアはなぜ採用されないんだろう？」となってしまうからです。

施策の詳細を詰める会議にて、時間の許す限り各施策のやらない理由をあげていきました。大体は、以下の3つの理由です。

たとえば、「〇〇機能の改善」という施策があった際に、「〇〇機能はユーザーの利用率が数％しかいないので、今はまだやらない。」といった具合でやらない理由を共有します。

「数％しか使っているユーザーはいないいのかー。先に〇〇機能の認知が必要だね。」となり、共有されていなかった知識が言語化され、次の施策立案に活かされていきます。

すぐにやらない理由に答えられるように、すべての機能の利用率などの基本的な情報は頭に入れておくとスムーズです。

これらの直近の注力ポイントの共有と、各施策のやらない理由の共有によって施策のアイディアの方向性が合い、より本質的な施策の起案がされるようになっていきました。

結果

各施策がリリースされた次の日には考察がチーム内で始まり、そこから次の施策が生まれていく好循環が生まれています。結果、プロダクトオーナーの自分はどんどん楽になっていき、よりユーザーニーズを拾うための活動に時間を割けるようになっていきました。

リリース回数も2.5倍になり、毎日施策をリリースし、そこから学習して次につなげるチームになってきたのを実感しています。

まとめ

今回は、開発メンバー全員から施策を出すための環境づくりの話をしました。

今後も、プロダクト改善の話で共有できる事例ができたら、記事をアップしていきたいと思います。

高速にプロダクト開発の仮説検証をしたい方へ
Ubie Discoveryでは、あらゆる職種で積極的に採用行っています。一緒にプロダクト開発をしていきたいと思われた方は、ぜひ採用サイトをご覧ください。オンライン会社説明会やカジュアル面談をやっています。