こんにちは、ウォンテッドリーの Visit Growth Squad というプロダクトグロースチームでプロジェクトマネージャーをしている原剛士(@chloe463)です。この記事はWantedly Advent Calendar 2023の14日目の投稿です。前日の記事はデザインマネージャーの新免さんによる「デザインマネージャーの取り組みと挑戦」でした。

この記事では、私が所属するグロースチームの具体的な取り組みにフォーカスを当てながら、失敗を許容すること、そこから学ぶこと、チーム文化などについて触れていこうと思います。

Visit Growth Squad のグロースサイクル

Visit Growth Squad は職能混合型のチームで、プロダクトマネージャー、デザイナー、エンジニアから成ります。プロダクトマネージャーが施策案や機能の仕様のすべてを管理し、デザイナー・エンジニアがそれに沿って開発をするという進め方をとってはいません。チームメンバーの誰もがアイデアを出すことができますし、誰かが考えた機能仕様についてフィードバックを出すことができますし、それがウォンテッドリーの開発チームのメンバーとして求められる姿勢です。

Visit Growth Squad は1週間を1スプリントとしてスクラム開発をしています。月曜日にプランニングを行いそのスプリントでのゴールを設定します。金曜日にスプリントレビューを行い、プランニングで設定したゴールが達成されたかどうかを確認します。スプリント中は毎日シンクアップ (Daily Scrum) を行い、進捗共有や相談をしています。

施策を進める際は、チーム全体で1つのものを進めるわけではなく Visit Growth Squad 内で小チームを作って進めます。より詳細には、プロダクトマネージャー (施策オーナーと呼びます)、デザイナー、エンジニア(1人or2人)のような構成で、同じ時期に2つ〜3つ程度の施策の開発が並行して進みます。

施策案は前述の通り、プロダクトマネージャーでなくてもバックログに入れることができます。実際のところプロダクトマネージャーが行うことが多いですが、例えば Daily sync up の場で「この機能のこういうところ改善する施策やるのありじゃないですかね？」「こういう仮説をもっているので、どうにか進められないですかね？」という意見を出すことはよくあります。施策案が固まるとメンバーをアサインしてキックオフして開発をスタートします。キックオフしたあとは、アサインされた小チーム自身がマネジメントをします。私はプロジェクトマネージャーという立場で存在するものの、多くの場面において各メンバーそれぞれのタスクマネジメントにまかせている面が大きいです。もちろんメンバーが作成したタスク管理表をレビューしたり、Daily sync up での相談などでサポートしますが、基本的にはチームメンバーの自主性にまかせています。

ここまででだいぶ Visit Growth Squad がどういうふうに開発をしているか概要が伝えられたかと思います。

ABテストを使った UI 改善

Visit Growth Squad が行う改善の多くは UI 改善です。小さな機能や見た目の変更であっても、それが本当に効果があるものかどうかは分かりません。私たちチームメンバーが YES だったとしても、ユーザーは NO という可能性があります。よかれと思って入れた変更が、ユーザーの課題解決には繋がっていない、または体験を悪化させてしまっては意味がありません。それを避けるために Visit Growth Squad では基本的に機能の変更をする際には AB テストを実施しています。

AB テストではユーザーを2つのグループに分け、1つのグループにはこれまで通りの UI・機能を提供し、もう片方のグループには新規の UI・機能を提供します。現機能を提供するグループを Control 群、新規機能を提供するグループを Treatment 群と呼びます。数週間この状態を維持しユーザーの行動ログが溜まったあとで、それぞれのグループについての KPI を集計、比較します。この比較の結果 Treatment 群の方が KPI が良ければ新規UI・機能の適用範囲を全体に拡大します。改善が見られない、または Treatment 群の方で KPI が悪化してしまったとなれば、新規 UI・機能は取りやめになります。

コラム: 公正な AB テスト実施のためのノウハウ

AB テストではユーザーを2つのグループにランダムに割り当てます。この割り当てはユーザーIDや会社IDをもとにしてTreatmetかControlかに割り当てられますが、AB テストごとに異なります。つまり今実施しているABテストではTreatment群に属するが、次に実施するABテストではControl群になる可能性があるということです。これが固定だった場合に何が起こるかを考えてみます。たとえば Treatment 群に新しいもの好きなユーザーが偏っていた場合、任意の AB テストにおいて Treatment 群の KPI が改善するということになってしまいます。新しいもの好きが偏っていなかったとしても、短いスパンで新規の UI・機能が提供され続けていた場合、それに慣れたユーザー群はすぐそれらに適応して機能を使いこなし KPI が改善する可能性があります。これでは公正な AB テストが実施されているとは言えません。そのため社内の AB テスト割り当てライブラリではそれぞれの AB テストのキーと割り当てに使う ID (ユーザーIDや会社ID) ごとに結果が異なるようにしています。

同じユーザーでも AB テストごとに割り当てを変える

また、AB テスト時には検証したい UI・機能以外の変更が紛れないように注意します。複数の変更が同時に入った場合にどの変更が効果があったのかが分析しにくくなります。検証事項以外の前提条件をすべて合わせた上で AB テストを行い、その UI・機能の変更があったからこそ KPI が改善したのだと自信を持って言える状況を作ります。

前提条件を揃え、テストしたい箇所だけが差分となるように

AB テスト分析と学習サイクル

AB テスト時には最初に計測する KPI を定義してきます。またそれが計測できるようなログも仕込み取りこぼしがないようにします。AB テストの内容や影響を受けるユーザー数にもよりますが、Wantedly のユーザー規模であればほとんどの場合、2週間程度で統計的に信頼できる計測ができるようになります。AB テストの結果自体は評価する KPI が決まっていればすぐに知ることができます。大切なのはその後の分析です。（ログを集計し数値を出すというタスクと、その数値を分析するというフェーズは明確に分けて考えています。）特に AB テストの結果、Treatment 群での KPI が悪化しているというときの分析が非常に大切です。

結果が良かった場合は我々が持っていた仮説が正しく、改善がユーザーに受け入れられたということで非常に良いことです。逆に失敗してしまった場合、そのUI・機能は本機能として全適用されないためそれ以上深追いしても意味のないように思います。また、アイデアがうまくいかなかったということは心理的にもネガティブに働いてしまうため、他の案を試したい気持ちも分かります。しかしながら、この失敗を深掘ってユーザー課題への理解を深めるということが次の成功への糧になります。我々が考えてた仮説がどう間違っていたのかを深掘って考えることで、次の施策案へつなげることも出来ます。

さらに失敗したということは、その筋での改善策はあまり意味がないということが分かるということでもあります。たくさん枝葉が分かれていく改善策の中で、失敗した枝葉の先はもう探らなくてもよいということが分かります。競技プログラミングの文脈でいうところの「枝刈り」のようなことができると、無駄な作業をすることがなくなり、別の枝葉へより効果的にリソースを投下できるようになります。小さく早くたくさん失敗するというのはグロースする上で非常に効果的だと考えています。

より詳細なテスト方法やグロースサイクルの話はデータサイエンティストの合田さんが書いた「ウォンテッドリーにおける推薦システム開発の流れ」という記事で詳しく解説されています。推薦システムとタイトルに入っていますが、推薦システムに詳しくなくても重要なエッセンスは読み取れるかと思いますので、一度読んでみてください。私は特に最後の方にある「取り敢えずやってみる」は「考えなしにやる」ではない という節が好きです。

こころがけ

失敗をしっかりと振り返ることがユーザー理解や他施策へのアイデア、効果的な改善策へとつながるということはなんとなくご理解いただけるかと思います。とは言っても失敗というのはネガティブですし、失敗すると評価が下がったり、誰かに責められたりするのでは？という心理になってしまうかもしれません。ウォンテッドリーでは失敗を強く責められることはありません。それよりはそこからなにかを学び次に活かせればよいという考えを持っています。

これは個人的に意識していることですが、各施策についての集計結果や分析結果が共有されたときに、なるべく「この施策は失敗だったね」とは言わないようにしています。逆に「これでまた一つ賢くなれましたね」とか「ユーザーが抱える課題への理解が深まりましたね」と言うようにしています。

サービスのグロースというのは不確実性が高いものです。ある意味で、当たるも八卦当たらぬも八卦です。もちろんチームとして世に出す施策は根拠を持って作っていますし、それらが全て当たってほしいとは思います。しかし良し悪しの答えを出すのは僕らではなく使ってくれるユーザーです。自分たちが良いと思った機能も、実際出してみたら全然ウケなかったということはよくあります。そういうことが続くと本当に自分たちがやっていることが正しいのか？という不安に駆られてしまいます。ですが、その施策がうまくいかなかったということは、その仮説は合っていなかった、ユーザーが抱えている課題ではなかった、ということが分かるということです。つまり僕たちは別の仮説を考える必要がある、別の側面から考える必要が分かるということです。

何かしらアクションが起こせるということは、何も知らないという状況よりはかなり進歩しています。プロダクトが抱える問題を減らし、ユーザーが抱える課題の解消をするために前進できたことは価値があることです。それを失敗という言葉で片付けてしまうのは非常にもったいないです。しっかりと振り返ってさらにチームにとって価値あるのあるものにしていきましょう。

まとめ

Visit Growth Squad の取り組みについて紹介しました。グロースサイクルの過程で経験する失敗の受け入れ方や、失敗を許容するチーム文化についても紹介しました。失敗は次の成功のための糧です。うまくいかなかった、で済ませるのではなく振り返り・深掘りをして次へ活かせるようにしましょう。

最後に、ウォンテッドリーではサービスグロースをするエンジニアを募集しています。今すぐの転職意欲がない場合でもカジュアル面談を実施することはできます。ここで紹介したようなチーム文化に興味がある方、自分でアイデアを出しながらサービス改善したいぞという方はぜひカジュアル面談に来てください！