「認知を優先するか、作り込みを優先するか」と書かれた画像

この記事は、freee Developers Advent Calendar 2024 5日目の記事です。

こんにちは。現在プロダクトマネージャー兼ソフトウェアエンジニアとしてfreee人事労務の開発を行っている金山（id: tepppei）です。先日わたしが投稿した記事（「機能を削る」以外のスコープの絞り方）に引き続き、今回も現在わたしが取り組んでいる「勤怠モニター機能」の開発の中で考えたことを発信します。

本記事の趣旨

新機能のリリース後の次の一手として、認知を優先するか作り込みを優先するかの選択は難しい問題です。
どちらを優先すべきかは、その機能がユーザーに受け入れられることにどれだけ確信があるかに依存すると考えられます。
今回は認知より作り込みを優先するという判断を行い、実践してみて良かった点・難しかった点を一事例として発信します。

「渇望→認知」戦略

ある新機能の最初のリリースを終えた後の次の一手として、大きく2通りの方針が考えられます。

想定ユーザーの大部分がそもそもリリースに気づいていないので、気づいてもらえるような認知施策を打つ
まずは、リリースに気づいてくれた少ないユーザーの反応を見ながら、必要に応じて追加開発を行う

もちろんどちらが正解なのかは状況によって大きく異なると思いますが、意思を持って戦略を選択することは重要だと思います。今回、わたしは後者の戦略を選択しました。

この選択をするにあたって、書籍「Hacking Growth」を参考にしました。同書には以下の一文が書かれています。

あらゆるグロース施策はプロダクトがマストハブとして渇望されるようになったあとで実施しなければならない

前後の文脈も含めて要約すると、

新規プロダクトをローンチした直後に派手なマーケティングをかけるのは悪手である。まずは限られたユーザーでも良いので、そのプロダクトが渇望されるよう注力するのが先である。

という主張です。

また、この主張の根拠としては以下の2点が挙げられています。

理由1: 使えない段階で認知を増やすことは、認知を増やすために投じたコストが無駄になるリスクがある。
理由2: 中途半端な状態で多くのユーザーが機能を目にしてしまうと、自分たちには使えないと判断してしまい、再度訪問してくれなくなるリスクがある。

現在わたしが取り組んでいる勤怠モニター機能は新規プロダクトではなく既存プロダクトの1機能なので、同書の想定する状況とは異なります。しかしながら、考え方として応用できそうだと感じました。

なぜなら、勤怠モニター機能は「労務担当者が従業員の勤怠不備を一覧し、その流れで従業員に修正依頼を出す」という、従来の機能とは異なる新しい体験を作りにいく性質の機能だからです。探索フェーズで行ったユーザーインタビューを通じて機能の価値に自信を持っているものの、実際に使えるレベルに達しているかどうかの不確実性は依然として高いと判断しました。

渇望→認知の順で注力するので、以下ではこれを「渇望→認知」戦略と呼ぶことにします。

何をしたか

ここでは、「渇望→認知」戦略を取ると決めたことを踏まえて、実際に何をしたのかを整理します。

指標への反映

数値目標を決める上で、「渇望→認知」戦略を強く意識しました。例えば、単に「全ユーザーに占める勤怠モニター機能の利用率X%以上」のような目標を置いた場合、これを達成するためのアプローチとして「認知を高める」「リピート率を高める」という2つの要素に分解でき、どちらを高めても目標は達成できます。今回は「認知を後回しにする」という戦略なので、認知を高めても目標達成できないような指標が望ましいです。

そこで、今回は以下を指標として定義しました。

勤怠モニター機能を認知しているユーザー*1のうち、渇望ユーザー*2の割合が30%以上

「勤怠モニターを認知しているユーザー」を分母とすることにより、認知を高めても目標達成に寄与しない指標になっています。

施策の優先順位への反映

バックログを「認知に効く施策」と「渇望に効く施策」に分類した上で、「認知に効く施策」を後回しにしました。

例えば、当初は「既存の一覧画面を勤怠モニター画面で置き換える」という施策を漠然とバックログの上の方に積んでいました。既存画面を今回開発する新規画面で置き換えることができれば、既存画面を使っていたユーザーがそのまま新規画面を認知してくれるので、利用率は大きく向上することが考えられます。しかしこれは「認知に効く施策」と分類できるため、今回の戦略に照らして優先度を大きく下げました。

何が良かったか

今回の戦略を採用して、良かったと感じた点を3つ挙げます。

良かった点1: 早期に見落としに気づけた

リリース後、この機能に対してアクセスログがあるユーザーに対してインタビューを行ったところ、比較的重要な機能の見落としに気づくことができました。

大々的に認知施策を打つ前の段階に新機能に気づいて実際に試してくださるユーザーは新機能への洞察が深く、開発者が気付かなかった鋭いご意見をくださる傾向にあると考えられます。ただし、こうした層は他の多くのユーザーと比べて考え方が異なる部分もある（具体的には、機能の分かりやすさより機能の自由度を求める傾向にある、など）ので、その補正はPdMとして気をつける必要がありそうです。

良かった点2: 開発リソースを集約できた

意思を持って「認知に効く施策」を後回しにすることで、「渇望に効く施策」に十分な開発リソースを投下することができました。

例えば、先ほど挙げた「既存の一覧画面を勤怠モニター画面で置き換える」施策は、既存画面との互換性を考えながら開発する必要があるため数ヶ月かかることが予想されました。これを後回しにすることで、この数ヶ月を「渇望に効く施策」に充てることができました。

良かった点3: Not for meなユーザーを最小限にとどめられた

これはリリース後だいぶ時間が経ってからのユーザーインタビューでわかったことですが、「リリース直後にすぐ勤怠モニター機能を確認したけれど、ぱっと見てよくわからなかったので、その後二度とこの機能を見に行くことはなかった」という趣旨のことをおっしゃっているユーザーが複数いらっしゃいました。

たしかに、リリース直後は「どのように初見のユーザーに使い方を理解してもらうか」というところまで作り込めていませんでした。リリースからしばらく経った今は、使い方を理解していただくための工夫を凝らしているのですが、リリース直後の印象で離脱してしまったユーザーに対しては時すでに遅しです。

もし、リリース直後の段階で大きく認知施策を打っていたら、こうしたユーザーが急増し、その後改善を繰り返しても意味がない状態に陥っていたかもしれません。

何が難しかったか

実際にやってみて難しかった点を2つ挙げます。

難しかった点1: 指標の定義・活用が難しい

まず、指標を定めるにあたって、リリース直後に「渇望されている状態」をうまく定義するのが難しいと感じました。

前述のように、勤怠モニター機能を通算5日以上訪問したユーザーがいる事業所を「渇望事業所」と暫定的に定義しました。正直、この程度で「渇望」と呼ぶには物足りなく感じます。しかしながら、機能リリース直後においては「3ヶ月連続で訪問したユーザー」のような定義をすることができないため、先行指標としてこのような指標を採用しました。

また、「どこまでいけば渇望フェーズから認知フェーズに切り替えていいのか？」の判断も難しいと感じました。前述のように、今回は数値目標を「渇望ユーザーの割合が30%以上」と置きましたが、この30%という数字に明確な根拠があるわけではありませんでした。この目標値が変われば、当然渇望フェーズから認知フェーズに切り替えるべきタイミングも変わってきます。

難しかった点2: ある程度認知がないとデータが取れない

最初に機能をリリースした直後は、完全に「渇望→認知」戦略に振り切っていたため、認知のための施策をほとんど行いませんでした。その結果、機能へのアクセスが想像以上に少なく、ユーザーの反応を見て次の打ち手を考えられるデータ量ではありませんでした。そのため、完全に「渇望→認知」戦略に振り切るのではなく、費用対効果が良く広すぎない範囲で適度に認知も促す方向に方針転換しました。