Monoxer開発現場でビジョンを優先した意思決定の例
最後に、現場の声とプロダクトビジョンを照らし合わせた結果、「プロダクトビジョンを優先する」という判断を行った事例を2つ、簡潔にご紹介します。
ケース1：「記憶度100%のハードルを下げてほしい」
Monoxerでは、学習の定着度を「記憶度」という指標で示し、100%になると「記憶できた」と判定します。この仕様に対して、「100%の基準を緩和する設定がほしい」という要望が多数寄せられました。
背景には、
- 「一度正解した問題を繰り返すのは無駄に感じる」
- 「学習が苦手な子に成功体験を積ませたい」
といった切実な声があります。
しかし、もしこの要望に応えてしまえば、ユーザー自身が「記憶の質」をコントロールできてしまい、Monoxerが提供する「本質的な記憶定着」という価値が揺らいでしまいます。さらに、記憶の質に一貫性がなくなることは、Monoxerが掲げる「記憶のプラットフォーム」という長期的なビジョンの実現を阻害しかねません。
そこで私たちは、機能変更ではなく、「記憶度100%の意味や価値をどう伝え、納得してもらうか」というコミュニケーション戦略を選びました。
ケース2：出題ロジックへの要望
Monoxerは、登録された学習内容から最適な問題を自動生成・出題する仕組みを持っています。ユーザーはただ解き進めるだけで、効率的に記憶を定着させることができます。
この根幹ロジックに対しても、
- 「もっとランダムに出してほしい」
- 「自分の好みの出題方式にしてほしい」
といったリクエストが寄せられます。
もちろん、これらに応える選択肢もあり得たでしょう。しかしMonoxerは「どんな学習スタイルにも対応する万能ツール」を目指しているのではありません。
ユーザーの声は開発の大きなヒントになりますが、モノグサのビジョンである「記憶をもっと容易に、より日常にすること」のために必要な「最も効率的に記憶が定着する体験」の提供は私たちが責任を持つべき領域です。そのため、個別要望に合わせてロジックを変えるのではなく、ビジョンを軸に改善を重ねています。
最後に
いかがでしたでしょうか。今回は、ビジョン主導のプロダクトが「現場の声」とどう向き合うか、そのバランスについてご紹介しました。
ここでお伝えしたのは完成形ではなく、私たち自身が日々試行錯誤しているプロセスの一部です。この記事が、同じようにプロダクトマネジメントに取り組む皆さまの振り返りや気づきのきっかけになれば幸いです。
次回は、モノグサのプロダクトマネージャーメンバーから「デザイナーとプロダクトマネージャーの境界線（仮）」というテーマでお届けします。ぜひご期待ください。
