はじめに
今回はモノグサでプロダクトマネージャーとして働いている廣川から寄稿いたします。デザイナー出身プロダクトマネージャーとしての忖度なしの葛藤と学びが、デザイナーとのコミュニケーションやコラボレーションに悩む方々の一助になれば幸いです。
改めてになりますが、弊社はEdTechスタートアップとして「記憶の定着」に特化したSaaS型学習サービス「Monoxer」を展開しています。このサービスは、学校、塾、企業をはじめとする多くの現場で活用され、記憶定着の支援とその可視化を通じて、学業成績の向上、資格取得、企業研修の効率化をサポートしています。また、昨年にリリースした幼児向け学習アプリ「Monoxer Junior」は、2025 CES Innovation Awardを受賞するなど、新規toCサービスの展開も進めています。
1人目デザイナーがプロダクトマネージャーに職種を変えた理由
私はこれまで約8年間、UI/UXデザイナーとしてキャリアを積み、現在はモノグサでプロダクトマネージャーとしてSaaSサービスの管理機能を担当しています。
新卒で入社したグッドパッチではクライアントワークを経験し、その後1人目デザイナーとしてモノグサに入社し、約5年間デザイン組織の立ち上げや採用に奔走してきました。プロダクトマネージャーへの転身を決めたのは、デザインチームが5名体制になった頃です。
当時の私は「プロダクトのユーザー体験（UX）向上を加速させたい」という強い想いを抱いていました。現場でデザインに向き合う中で、リソース配分の都合上、どうしても体験向上の優先順位が上がりにくい状況に歯がゆさを感じていたのです。
「自分が意思決定の責任を持つ立場（プロダクトマネージャー）に身を置くことで、この課題に直接メスを入れられるはずだ」。そんな野心を持って飛び込んだプロダクトマネージャーの世界。しかしそこで待っていたのは、デザイナー時代の「正解」が通用しない世界でした。
作りすぎない、応えすぎない。都市開発ゲームから学んだ優先順位の極意
デザイナー時代の私は、「1割でも不便を感じているユーザーがいるなら、その負債を解消すべきだ」と考えていました。不満や要望をいただくたびに申し訳なさを感じ、より多くの穴を埋め、マイナスの体験をなくしていくことが正義だと思っていたのです。サービス全体の体験の一貫性を担保するという観点でも、デザイナーが折れずに改善の重要性を主張し続けるべきだと信じていました。
しかし、プロダクトマネージャーとして事業全体を見渡したとき、その考えはあっさり揺らいだのです。
プロダクトマネージャーに転身した直後、私は趣味である都市・国家育成シミュレーションゲームから、ある学びを得ました。それは、「市民のニーズが出る前に施設を整備しすぎると、赤字で破綻する」ということです。逆に、強い不満が出たタイミングで適切な施設を提供すると、満足度は劇的に跳ね上がります。
プロダクト開発も同じでした。
リソースは有限です。その中で「この機能の価値を最大化するには？」を問いに据えると、デザイナーとプロダクトマネージャーの意見は時折食い違います。しかし一歩俯瞰して、「サービス全体で、ユーザーに届ける価値を最大化するにはどうしたらいいか？」を問いにすることで、MVPや優先順位の議論は格段に進めやすくなるはずです。
「多くのフィードバックが届いている」ということは、そこが「使われている（求められている）場所」である証拠です。デザイナー時代は極端に表現すると「不満＝悪」と捉えていましたが、今は「不満＝最も喜ばれるポイントを教えてくれるサイン」だと捉えています。
最初から作りすぎない、応えすぎない。小さくリリースして、ユーザーに求められているかを確認してから機能を育てていく。
優先順位とは誰かを切り捨てることではなく、「最も多くのユーザーに、最も喜んでもらえるタイミングで価値を届ける」ために存在する。この視点の切り替えが、私にとって最初の大きな変化でした。
「デザインの民主化」が開発スピードを最大化する
次に直面したのは、制作工程へのこだわりです。デザイナー出身の私は、「体験の一貫性を守るため、すべてのUI設計にデザイナーがゼロから関わるべきだ」という強い信念を持っていました。そしてその取り組みが、より良いサービス提供とビジネス成果に繋がると考えていたのです。
しかし、それが結果として開発のボトルネックを生んでいました。デザイナーのリソースが空くまで施策が止まり、結果的にリリース予定を2か月後ろに倒してしまったこともあります。これは本当にユーザーのためなのか？ ビジネスにポジティブな影響を及ぼしているのか？ 残念ながらNOと言わざるを得ません。
プロダクトマネージャーの立場になったことで、そのネガティブインパクトの大きさをありありと実感しました。特に学校や塾を顧客とする弊社の場合、夏休みにリリース予定だった機能が秋の文化祭シーズンにズレるだけで、「すみません！ 今忙しい時期なので……」と顧客に機能を利用いただけないことが出てきます。デザイナー時代は『いつ出しても便利なら良い』と思っていましたが、SaaSプロダクトマネージャーにとっては『顧客の業務サイクルに合わせること』自体がUXの重要な要素だと気づきました。
上記の経験もあり、プロダクトマネージャーの立場である現在は考え方を180度変えています。
関わる施策が増えれば増えるほど、コンテキストスイッチの負荷は上がり、デザイナーが持つ体験向上への強いこだわりが分散されます。それは会社にとってもユーザーにとっても望ましい状況ではありません。
UXやUIの設計はデザイナーが必ずしもゼロから取り組む必要はないのではないでしょうか？ プロダクトマネージャーやエンジニア、場合によってはQAが設計を始めることで、全職種がUXに関心を持ちやすくなったり、他職種でも活用しやすいデザインシステムの整備にチームが取り組む意義が増したりなど、デザイナーにとって嬉しい副次的効果もあります。
デザイナーが「全部自分でやる」という執着を捨て、チーム全体で体験を担保する仕組みを作る。それによって、デザイナーはより難易度の高い、本質的な体験設計に時間を割けるようになります。デザイナーの責任は「制作」にあるのではなく、「最適な布陣で価値を届けること」にあるのです。
