チームをいつの間にかプロダクト志向にするプロダクトディスカバリー

この記事はツクリンク株式会社のアドベントカレンダー14日目の記事です。

はじめに

こんにちは。ツクリンク株式会社でエンジニアをやっとります、ikarikomanです。

私が所属する開発チームでは数ヶ月前にプロダクトディスカバリーをチームに導入するトライアルを始めました。
この記事では、なぜプロダクトディスカバリーをチームに取り入れたのか、どうやって行っているのかを解説します。

プロダクトディスカバリーとは？

プロダクトディスカバリーとは、ユーザーリサーチや仮説検証などを繰り返し、プロダクトの「何を作るべきか（What）」の方針を決めるための活動です。

対して、プロダクトデリバリーは設計や実装を通して「どう作るか（How）」を具体化し、ユーザーに価値を届けるための活動です。

※あくまで個人の見解です

開発チームの状況

私が所属するチームではグロース施策の実装や既存機能の改善を通じて、ユーザーの体験を向上させることをミッションとしています。

メンバーはエンジニア2名、QAエンジニア1名、デザイナー1名、プロダクトオーナー1名の計5名です。開発手法としてはアジャイル開発（スクラム）を実践しており、現在は2週間のスプリント単位で機能開発に取り組んでいます。

※アドベントカレンダー10日目の記事で詳しいチームの紹介をしてるのでよかったらみてください！

感じていた課題

元の開発体制では、施策立案までのディスカバリー活動をチーム外で実施しており、決まった施策がチームに降ってくる構造でした。
チームは降ってくる施策をリファインメントし、Howを固めてデリバリーのみを行う形です。

従来の手法でも問題なく機能のデリバリーはできていたのですが、スプリントを繰り返す内に下記の課題を感じるようになってきました。

コンテキストの理解不足

リファインメントなどで施策の背景（Why）は共有されていましたが、そこに至るまでのディスカバリー活動に参加していないため、どうしても人から聞いた話の域を出ない状態でした。 施策の背景を理解していても、実感を持って自分ごと化するまでには至っていないなぁ...と感じていました。

フィードバックループが存在しない

デリバリー中心の開発になることで、チームが施策の成果（アウトカム）を気にする機会が少なくなっていました。 効果測定は実施されているものの、ディスカバリー活動がチームで実施されてないが故に、効果測定で結果から得た学びを次に活かしづらい状態でした。そのため、開発者からすると成果物(アウトプット)重視にならざるをえない状態になっていました。

これらの課題を解決し、チーム全員で顧客に向き合う体制でユーザーへの価値をチームで創出するために、プロダクトディスカバリーの活動をチームの開発プロセスに取り入れることにしました。

導入までにやったこと

プロダクトディスカバリーの定義や実践方法は、組織やチームによって様々な解釈があると思います。この記事で紹介するのは、あくまで私たちのチームでの一例として受け止めていただければと思います。

事前準備

社内に前例がない取り組みだったため、まずはトライアルとしてスタートさせることにしました。 開始にあたって準備したことは、大きく以下の3点です。

社内のディスカバリー活動の棚卸し

PdMやリサーチャーにヒアリングを行い、組織として現状どのようなディスカバリー活動が行われているかを明らかにしました。

チーム内での「ディスカバリー」の定義

棚卸しした内容を元に、チームとしてのディスカバリー活動を素早い仮説検証を行い、解決すべき課題を探索することとし、活動のサイクルを下記で定義しました。

• 課題の発見
  • 課題の発見のために必要なリサーチを実施する
    • 例）データ分析やユーザーインタビュー
• 仮説の作成
  • インサイトリストや定量分析の結果や学びから仮説を作成する
• 検証方法の定義
  • 仮説の検証方法を定義する
    • 例）MVPの作成やABテストなど
• 検証作業
  • 実際の検証作業を実施し、検証結果をまとめる
• 結果から得た学びの共有・次のアクションの決定
  • 検証結果をスプリントレビューなどで共有し、次のアクションを決める

実践方針の作成

棚卸しの結果を踏まえ、まずは現在PdMが行っているディスカバリー業務をチーム活動として組み込むという方針を立てました。 また、ディスカバリーの目的がブレないよう、チームで作った施策をロードマップに追加することを具体的なトライアルのゴールとして設定しました。

スクラムイベントへの組み込み

当初はディスカバリー専用のMTGを通常のスクラムイベントとは別途設ける形でトライしたのですが、通常の開発サイクルから分離してしまったことで、ディスカバリーの話題を含めてプランニングで計画を立てることが難しく、チームが混乱してしまっていました...
そのため、既存のスクラムイベントにディスカバリーの議題を同列に組み込む形にシフトしました。 結果として、現在はデリバリーとディスカバリーが並走するデュアルトラック・アジャイルのような状態で運用しています。

デイリースクラム

開発タスクの進捗確認と同時に、決定したディスカバリーのスプリントゴールについても進捗や懸念を共有する形にしています。

プランニング

デリバリーと同様に、次のスプリントで検証すべきディスカバリーのゴールをスプリントゴールとして設定し、ディスカバリー、デリバリー両方を考慮したプランニングを実施しています。

※ゴールの一例ですが、「xxxページへの流入経路、xxx機能の使い方に関して、検証するデータと検証方法を定義して実際にデータを抽出する」といった具体的なゴールを都度設定しています。

スプリントレビュー

開発成果物のデモと同じ場で、ディスカバリー活動の結果（検証結果や得られた学び）を共有し、チーム全体で議論を行う形にしています。

導入後のチームの変化

ディスカバリー活動を組み込んだことにより、自然と顧客に対する分析や抱えている課題の共有が行われるようになりました。 自分たちで一次情報（データやユーザーの声）に触れることで、プロダクトや顧客に対する解像度が高まっていると感じていますし、チームメンバーからも意識してプロダクト志向になるんじゃなくて、勝手にプロダクト志向になってるとの声が上がっています。

また、仮説や課題を定義するときや、解決策を考える際に、エンジニア、QA、デザイナーといった多角的な視点からの意見が出るようになりました。 実際にエンジニアから発案された解決策が施策の方針として採用されるケースも出てきており、職能を超えた議論ができている状態です。

今後について

ディスカバリーを導入してチームの意識は変わりましたが、まだチームのディスカバリーから生まれた施策をユーザーに価値として届けられてはいない状況です。

まず一つディスカバリーを通して施策を作成し、チームで仮説を立て、作り、結果を検証するというサイクルを完走させることが直近の目標です。

デリバリーとディスカバリーのバランスやフィードバックループの策定など、やるべき課題は山積みですが、試行錯誤しながらチーム全員で顧客に向き合う体制でユーザーへの価値を自ら創出するチームを創っていきたいと思います。