お知らせ
お知らせ
CLOSE

やらないことを決めると未来が見える!「迷わない」組織になるためのマルチプロダ クト戦略(全1記事)

マルチプロダクト運用における機能の重複に悩む方へ 開発の迷いを消した「やらないこと」の言語化 [1/2]

【3行要約】
・プロダクト数が増えると機能の重複や役割分担の曖昧さが生じ、開発チームの判断に迷いが生まれることもあります。
・ヤプリの小野田氏は「Yappli Value Compass」プロジェクトを通じて、「やらないこと」を明確にする発想転換で問題を解決。
・ マルチプロダクト環境での混乱を避けるには、各プロダクトの「やらないこと」を言語化し、責務の境界を明確にすることが効果的です。

やらないことを決めると未来が見える

小野田奈生氏:みなさまこんにちは。株式会社ヤプリの小野田と申します。「pmconf 2025」での登壇機会をいただき大変光栄です。

本日は「やらないことを決めると未来が見える!『迷わない』組織になるためのマルチプロダクト戦略」というテーマでお話しさせていただきます。プロダクトマネージャーのみなさまにとって、日々の意思決定のヒントになれば幸いです。

まず簡単に自己紹介をさせていただきます。私、小野田奈生は株式会社ヤプリでプロダクトマネージャーを務めております。キャリアとしては、新卒で3年ほどSIerにてシステムエンジニアをやっておりました。

ヤプリには2021年に入社しまして、そのタイミングでプロダクトマネージャーに転身したので、プロダクトマネージャー歴としては約4年ほどになります。ヤプリにおいては、プラットフォームとして成長するためのエンハンス領域におけるプロダクトマネジメントにずっと携わっております。

提供している3つのアプリ

続きまして、簡単に会社とサービスの紹介をいたします。株式会社ヤプリは2013年に創業した、ノーコードのアプリ開発を可能にした国内初の上場企業となっております。実は3支社あるんですけども、大阪支社については本会場のグランフロント大阪の隣のタワーにオフィスがございまして、大変縁を感じております。

そんなヤプリですが、「デジタルを簡単に、社会を便利に 〜Mobile Tech for All〜」というミッションを掲げている会社になっております。

それらのミッションを実現するべく、主に3つのプロダクトを提供しております。1つ目がノーコードモバイルアプリのプラットフォームである「Yappli」。2つ目がアプリを中心とした顧客管理、ポイント管理といったCRM、顧客管理施策を実現する「Yappli CRM」。そして最後に、Web構築をAIとノーコードで行うことができる「Yappli WebX」の3つがございます。

ヤプリのサービスは、非常に多くの業界のお客さまに、さまざまな業務でご利用いただいております。一般的にはアパレルとか飲食とかのお客さまのマーケティング利用みたいなところが強いかもしれないんですけども、学校の学生さん向けの情報アプリとか、BtoB営業の代理店向け、あとは従業員向けのアプリとか、利用目的はかなり多岐にわたっております。

今回せっかくなので、消費者向けに公開されているYappli系のアプリのアイコンをずらっと並べてみました。せっかくなので聞いてみたいんですけども、この中で「このアプリインストールしてるよ」っていうものがある方は、ぜひ手を挙げてほしいです。

おうおう、2~3割ぐらいですかね。ここには載ってないものもあるんですけど、事例とかがぜひ気になったら見ていただけるとうれしいです。このようなかたちで今は900アプリほどに導入いただいている状況になってます。

プロダクト責務の指針を作ることになった背景

ここから本題にいきたいと思います。本日お話ししたいのが、私たちが作成した「Yappli Value Compass」というプロダクト責務の指針についてです。この指針は現場の課題感からボトムアップで考案しまして、最終的に、やらないことを明確にすることでプロダクトのらしさが言語化されて、開発現場の迷いが消えたという成果を上げております。

このプロセスをみなさまに共有していきたいと思います。今後、プロダクト拡大を検討している組織とか、プロダクトマネージャーのみなさんの気づきになったらうれしいなと思います。

まず、なぜこの指針を作る必要があったのか。その背景からお話ししていきます。こちらをお話しするために、ヤプリにおけるプロダクトの変遷についてお伝えしていきます。

初めはノーコードアプリプラットフォームのYappliのみの、シングルプロダクト時代とも言える時代でした。これが創業当初から2020年ぐらいまでの話です。

2021年にCRMが立ち上がりましたが、システムとして連携はできるものの、UXとか戦略とかといった部分でのマルチプロダクトが強く意識されていたわけではなくて、今振り返ると、複数のシングルプロダクト時代と言えるような時代だったんじゃないかなと思っております。

そして2025年にYappli WebXがローンチされまして、コンパウンド戦略を本格的に目指す、真のマルチプロダクト時代を迎えたと言えるんじゃないかなと思っております。

シングルプロダクト→マルチプロダクトへの移行で発生した課題

そして本日話すのが、複数のシングルプロダクト時代から、マルチプロダクト時代へ移行していく際のお話になっております。プロダクトが増えていく中で、この時期の我々はとある課題を抱えておりました。

それが、似たような機能が各プロダクトに存在し始める。また、それに伴って顧客の課題を解くのに、どのプロダクトで実現しようか悩むシーンが増えたといったものになります。

少し具体的に示すと、YappliにもYappli CRMにも、使い方によっては全部アンケート機能になりうるようなものが存在していたり、「セグメント絞り込みしたプッシュ通知の送信って、YappliもしくはYappli CRMのどっちから送れたほうがいいんだろう」みたいなところの迷いが発生したりしておりました。

このままだとお客さまにとっても使いづらいですし、開発者目線でもリソースの無駄遣いということになってしまうかと思います。

ここで課題の共感を深めたいところがございまして少し付け加えさせていただくと、もしかすると「なぜそんな複数の機能が」みたいに思う方もいるかもしれないので、そういった方向けの補足です。

Yappliのみのシングルプロダクト時代に間に合わせで作ったというか、そういうA機能が運用していたところYappli CRMが出現して、上位互換と言えるようなB機能が出てきて、じゃあそこから追加開発するってなった時に「ABのどっちを残すの?寄せていくの?」みたいな議論が頻繁に発生したというようなかたちになってます。

BtoBプロダクトとかだと「あるよね~」っていう課題であると信じているのですが(笑)。この場では全員がそういうわけじゃないかなと思うので、念のため補足させていただきました。

ということで、これらの課題を解決するべく、プロジェクトを立ち上げる運びとなりました。(スライドを示して)目的はこちらの2つですね。誰もが開発しやすくなるために、迷いを減らすためのルールを整えること。そしてプロダクトの責務を言語化すること。これらを掲げて「Yappli Value Compass」の制定を目指していきました。

まずは似ている機能の把握からスタート

ここまでプロジェクト発足の背景についてお話しいたしました。ここからは実際にどのように設計していったのか、やらないことを決めていったのかという部分についてお話ししていきます。

まず検討メンバーですが、プロダクトマネージャー、プロダクトオーナー、プロダクトデザイナーからなる検討チームを結成して取り組んでおります。プロダクトマネージャーに関しては、Yappliに詳しいメンバーとして自分が、もう1名はYappli CRMに詳しいメンバーが参加しているような状況になっています。

設計プロセスは、まず現状の可視化と棚卸しから着手いたしました。全プロダクトの約130機能を洗い出して、特に似ている機能を把握していくことに注力をしていきました。

ここのステップとしては、まずは役割として重複している部分がどの程度なのか、なぜ迷っているのかを特定したかったというところがあります。課題感からして、同じような機能が集まっているところに迷いの原因があると考えまして、まずはそこを明らかにするとこから始めようということで意図しております。

また、現在重複している部分だけではなく、重複予備群というような、今後重複する可能性がある箇所の洗い出しも意図していました。

2025年時点でYappliが約90機能、Yappli CRMが40機能ほど有していたので、まずは徹底的な棚卸し・洗い出しをしていきました。

そして、1度棚卸しした後は、似ている目的や機能を有しているものを大まかにグルーピングしていきました。

(スライドを示して)今のスライドではすごく簡略化されてスッキリしてるんですけれども、実際のFigmaはこんな感じで、右側のところも定義されているようでいないような感じなんですけど、手戻りしながらグルーピングしたり外したりみたいなところをやって、なんとかたどり着いたかたちになります。

グループ分けにより曖昧ゾーンが明らかに

そして2製品、約130機能を11グループに分割することができました。そうすると、だんだん曖昧ゾーン、真ん中の部分が明らかになってきました。少し具体例を示すと、もともと現場レベルで課題になっていたプッシュのセグメントあたりは、まさに曖昧だったことがわかってきました。

これ以外にもエンドユーザーへのインセンティブ付与の文脈で言うと、クーポンの部分が被ってるとか、あとはエンドユーザーのログイン認証とか、そもそもエンドユーザーのデータの取り扱いなど、かなり多くの曖昧ゾーンが明らかになってきました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
スピーカーフォローや記事のブックマークなど、便利な機能がご利用いただけます。

無料会員登録

すでに会員の方はこちらからログイン

または

名刺アプリ「Eightをご利用中の方は
こちらを読み込むだけで、すぐに記事が読めます!

スマホで読み込んで
ログインまたは登録作業をスキップ

名刺アプリ「Eight」をご利用中の方は

デジタル名刺で
ログインまたは会員登録

ボタンをタップするだけで

すぐに記事が読めます!

次ページ: プロダクトの価値の言語化に挑むが、議論が進まない状況に

関連タグ:

この記事のスピーカー

同じログの記事

この記事をブックマークすると、同じログの新着記事をマイページでお知らせします

コミュニティ情報

Brand Topics

Brand Topics

人気の記事

    新着イベント

      ログミーBusinessに
      記事掲載しませんか?

      イベント・インタビュー・対談 etc.

      “編集しない編集”で、
      スピーカーの「意図をそのまま」お届け!