ユーザー価値向上を目指すaskenのプロダクトチームの活動

こんにちは。コンシューマ事業部副部長兼EMの村上です。2023年5月に入社しまして入社8ヶ月目にしてaskenテックブログ初投稿になります！私の経歴などはこちらをご覧ください。現在はあすけんの価値を高めるため、プロダクト開発組織のマネジメントを行っています。先日、VPoEの安西からプロダクト開発組織を変えた話をポストさせていただきました。私からは、プロダクトチームが具体的にどのような活動をしているかを紹介させていただきます。

プロダクトチームの目指す姿

プロダクトの成功には、ユーザー価値、事業成果(売上、利益)、この二つを両立する必要があります。特にプロダクトチームはユーザー価値を高めることが主な目的になります。しかし、何がユーザーにとって価値があるのかは、正確にはわかりません。わからないので、仮説検証のプロセスを回し実験を重ねていく必要があります。そのため、プロダクトチームには、ユーザ価値の仮説を立てること、仮説を短期間で小さくリリースして検証すること、この二つが特に重要になります。

現状

あすけんサービスを担当するコンシューマ事業部では、目的別に複数のプロダクトチームが独立して活動しています。今回はその中で、プロダクト価値の向上を目的としたチームのうち1チームについてご紹介します。

チームの構成

プロダクトを提供するために必要なメンバーをできる限り揃えたクロスファンクショナルな構成にしています。異なる職能のメンバー、専門家によるコラボレーションの効果を高めることなどが目的です。

プロダクトマネージャー
Androidエンジニア
iOSエンジニア
バックエンドエンジニア

働き方

ユーザー価値を高めていくには、不確実性に向き合い、チームで学習し続ける必要があります。前述の通り、ユーザ価値の仮説を立て、素早くリリースして検証する必要あります。スプリントは、1週間のスプリントで、スプリント内では施策仮説を立てること、デリバリー、結果検証を行っています。プロダクトマネージャー、エンジニアとそれぞれ役割はありますが、バックログは共有してあり必要に応じてフォローしたり協業したりしています。

ユーザ価値の仮説を立てる

プロダクトマネージャーが中心で、ユーザ価値の探索、具体的に追加する機能の検討を行います。ユーザー価値の探索は、データによる定量分析、顧客満足度調査、アンケート、ユーザーインタビューなどによる定性分析で得た情報を活用し、ターゲットユーザーとそのペイン、ゲインを分析します。その後、具体的に追加、改善する機能を決定しています。機能の検討にはエンジニアも検討に参加します。
素早くリリースして検証する

素早くリリースするには、短期間で小さく開発する必要があり、開発プロセスはスクラムを採用しています。毎スプリントリリースできる状況にはなっておりませんが、1スプリントで動くものを作って検証する、というサイクルは回せるようになってます。
- スプリント期間は1週間
- バックログアイテムの完成の定義は結合テストまで、そこまでできたらスプリントレビューで挙動を確認する
- リリースして意味のある単位までインクリメントが貯まったらリリースする
- リリースサイクルは施策のサイズに依存し、1〜4スプリントくらいかけてリリースしている ( 2スプリントでのリリースが多い）
- リリース後の検証は毎週金曜日に実施
- 定量、定性の分析を行い、新たなユーザ価値の検討を始める
- 必要に応じてA/Bテストを実施してリリースした価値を採用するかの判断をする

チームが自律して理想を目指すために工夫した点

最初からここまで出来ていたわけではなく、かつては大きな機能追加をウォーターフォールのように工程でわけで3ヶ月かけて実装する、その期間はリリースゼロ、振り返りによる改善もなし、みたいな状態でした。そのような状態からでも、現在のようにユーザ価値に向き合うチームに進化することができました。チームに前向きなメンバーが多かったことも大きいですが、実現するために工夫した点もあるので紹介します。

大きな変更を行うためには、トップダウンでプロセスだけ変更するのでは難しく、チーム全員が自力で理想を目指してる状態を作ることが重要でした。そのために、目指すチーム像の共通認識を作ること、変更のハードルを下げることが重要だと考えました。変更へのハードルを下げためには、理想の状態までのステップを設計して改善すること、経験学習のサイクルを短くすることを実践しました。

実践したこと

目指すチーム像の共通認識を作る
- 前述の理想の状態を目指すことを共通認識にする
- スクラムのやり方で迷う時はスクラムガイドに立ち戻る
- プロダクトマネージャー、エンジニアの最低限の役割の定義（場合によっては見直す）
変更のハードルを下げる
- 一度に理想像までいかず、ゴールへのステップを設計し段階的に改善し手応えを得る
  - ステップの例
    - バックログアイテムが工程ごとに区切られていてもいいので、1スプリント単位で計画を立てて振り返るリズムになれる
    - バックログアイテムをユーザーストーリー形式にして、1スプリントで動くものが出来上がる
    - 毎スプリントデモで出来上がったものの検証ができる
- 経験学習のサイクルを短くし、失敗してもすぐ改善できるようにした
  - 最初はきつくても1週間スプリントを維持
  - やってみてうまくいかなかったら来週見直す、という空気ができた

直近発生した問題とその対策

常に順調に進んでいたわけではなく、様々な問題にもいくつか直面しました。その中から直近で発生した問題と対策について紹介します。ユーザ価値の仮説を立てること、素早くリリースして検証するを並行して実行していた結果、どちらのフェーズでも重要な役割を果たしていたプロダクトマネージャーにタスクが集中し、ボトルネックになることが多くなりました。チームで振り返りをした結果、プロダクトマネージャーのタスク量的に両方に専念することが不可能であることがわかり、プロダクトマネージャーには、ユーザー価値の仮説に注力してもらう方がこのチームとして動きやすいという結論に至りました。その状態を作るために、リリースして検証するフェーズにおいて、エンジニアがメインで活動するよう役割を整理し直しました。特に、プロダクトマネージャーの負担になっていたバックログアイテムの詳細化をエンジニアの役割に変えたことで、プロダクトマネージャーはユーザ価値の仮説を立てる活動に専念できるようになり、安定して価値を届けられるようになりました。

バックログアイテム詳細化の役割分担

プロダクトマネージャーの役割
- エピックレベルの大きなバックログアイテムの作成
- 最終的な仕様の意思決定
- バックログアイテムの優先順位を決める
エンジニアの役割
- バックログアイテムの分解、詳細化を推進する

今回のは一例ですが、このような感じで問題が発生、振り返りで問題提起、原因分析、対策実施、というサイクルが周り、自分達の理想の姿に近づいていってます。

理想の状態を目指す試みはまだまだ続く

以上のように、askenはユーザ価値を向上できる組織へと進化を続けています。バックログリファインメントの時間短縮、ユーザ価値の探索の効率化、テストプロセスの整備など、特にスピード面の課題が見えてきていますが、経験学習を繰り返して一つずつ解決していきたいと考えています。まだまだ人数も足りていません。是非一緒にやっていただける仲間を増やしたいです。ご興味があれば是非お気軽にご連絡ください。