🐭

プロダクトを成長させる段階的改善サイクル

なりたなりた

2025/09/22に公開

プロダクトの改善サイクルを回していくときに、小さく育てることにこだわって行動しています。
短期間で成果を出し、この取り組みが正しい方向に進んでいると示さねばならない状況でした。

新しく立ち上がった小規模チームだったため、最初の成功体験を通じて士気を高めることも求められていました。
では、限られた時間の中でどうやって確実に成功を積み上げていったのか。

最近まで行っていたことを踏まえ、自身の考えをまとめてみました。

 ファネル分析で課題を可視化する

改善の第一歩は、現状をデータで把握することです。

A画面からB画面への遷移フローをファネル分析してみると、画面遷移は一定数あるが、B画面でのアクションがほとんど進んでいないことがわかりました。
つまり、B画面に到達したユーザーは「その先で何をすればいいのか分からず、行動が止まっている」という状態です。この結果をチーム全員で共有したことで、 「B画面を活用してもらうこと」 が今回の改善の最優先課題であると明確になり、B画面までの間に補助機能を作ることにしました。

 いきなり作り込むのはリスクでしかない
課題が分かると、理想的な体験を一気に作り込みたくなるものです。

「これさえ作れば数字は上がるはずだ」という熱量がチームを包み込み、

一気に完成形を目指してしまうことはよくあります。
しかし、もし「あるべき姿」を最初からフルスケールで作り込んでしまうと、リリース後に次の問題が発生します。
数値が下がったとしても原因がどこにあるのか特定できない
文言が悪いのか？
ボタン配置が悪いのか？
情報量が多すぎるのか？

複数の要因が複雑に絡み合い、ABテストで切り分けるには膨大な時間と工数がかかる
もし最初から完成形を作ってリリースしていたら、クリック率が下がっても原因が特定できず、

チームは“何を直せばいいのか”で議論が停滞していたでしょう。

 ユーザ像と心理から、本質的課題を言語化する

そこで私たちは、すぐにUIや機能を作るのではなく、 まずはユーザ理解を深めることに時間を使いました 。いきなり手を動かしてしまうと、表面的な問題解決に終始してしまい、本質的な課題を見失いがちだからです。
そこで、A画面からB画面に遷移しているユーザーを代表するペルソナを設定し、

ユーザーの頭の中で起きている迷いやストレスを、チーム全員で言語化して共有しました。
（例）
「次に何をすればいいか分からない」
「説明文が多く、不安になる」
「入力項目が多く、途中でやめたくなる」
この心理を起点に行動上の課題を整理し、関連付けながら議論を進めました。

これにより、チーム内での課題認識が一気に強まったと感じています。

 施策を「育てる」という考え方
本質課題が明確になったところで、私たちはまず小さな施策をリリースしました。

それは完成形ではなく、仮説を検証するための最小限のプロトタイプです。
ここで大切にしたのは、施策を 「育てる」 という視点でした。

いきなりすべてを作り込むのではなく、ABテストを通じて少しずつ機能を成長させていく。

こうすることで、何が効いたのか、どの要素がボトルネックなのかを明確にしながら改善を進められます。

 小さく作り、早く回す改善サイクルは以下の流れで進めました。
仮説を小さく分解する
最小限の改修を実装する
ABテストを実施する
データを見て成功・撤退を決め、次の課題を提起する

 例：「ボタン文言が分かりづらくて離脱しているのでは？」

 例：「新たに項目追加し、ネガティブな反応がないか？」

このサイクルを高速で回すことで、スピードと品質を両立できました。

チームで会話するときも変更箇所が小さいため、何が問題かを議論しやすかったです。

また、「amazonのすごい会議」という本も参考にして 最短3日〜最長1週間 で全て判断していました。

 学びと気づき
 1. データで現状を可視化することが出発点ファネル分析で「何が起きているか」を明確にすることで、チーム全員が同じ課題感を持てた。

 2. 完成形をいきなり作らず、施策を育てる小さく始めることで、原因を分離しやすく、改善サイクルが高速化した。

 3. ABテストを前提に設計する感覚や好みではなく、データとユーザー視点で議論が進むようになった。

「いくら我々が議論しても答えを知ってるのはユーザだから、早くリリースしよう」を合言葉に、チームの意思決定もどんどん早くなっていきました。

 まとめもし最初から「あるべき姿」をフルスケールで作り込んでいたら、リリース後に数値が下がったとき、原因を特定できず改善が止まっていたはずです。私たちが成果を出せたのは、小さく作り、早く回すという姿勢で施策を少しずつ育てていったからでした。
プロダクトの改善は、最初から完璧を目指すものではなく、

ユーザー体験を育てていく長期的なプロセスであると実感しています。