コネヒト開発者ブログ

コネヒト開発者ブログ

新機能を「作る前」にやったこと —— 価値仮説を最小コストで検証したプロセスと学び

みなさんこんにちは。CTOのたかぱい(@takapy0210)です。

ママリアプリには「サークル機能」という、同じ月齢や妊娠フェーズ、興味関心などでユーザーさんたちがチャット形式でコミュニケーションできる機能があります。

この機能は2025年の春過ぎにリリースし約1年経過しました。利用ユーザーさんや投稿数も順調に伸びてきています。

サークルへの投稿数推移。YoYで4倍程度成長している

この機能を開発したのは、既存のQ&A機能だけでは満たしきれないユーザーニーズがあると考えたからです。

既存のQ&A機能は、悩みを言語化し具体的な回答を得るにはとても適した体験だと思います。
一方で、妊娠・出産・子育ての時期には「明確な質問」になる前の不安や、同じ境遇の人と気軽に話したい気持ちもあるかなと思います。

サークル機能では、そうしたニーズに対して同じ境遇の人と気軽につながり、継続的にコミュニケーションできる体験を作ることを目指しました。

本記事では、この機能をリリースするにあたり

  • なぜこの機能が必要だと考えたのか
  • いきなり作らず、どう検証したのか
  • リリース時の機能として何を大事にしたのか
  • そこからどんな学びがあったのか

などについてお話ししようと思います。


目次


TL;DR

いろいろ振り返って記事を書いていたらそこそこのボリュームになってしまったので、時間がない方向けに一連のプロセスで得た学びを先にまとめておきます。

「機能」ではなく「満たしたい体験」から考える

作りたかったのは、同じ境遇の人と気軽に話せる場所であり、ユーザーが「ここに自分の居場所がある」と感じられる体験でした。そのため、この体験の実現から逆算して機能を考えていきました。

作らずに価値検証できる方法を考える

価値仮説を検証できるなら、必ずしも0からプロダクトを作る必要はありません。すでにあるサービスを組み合わせることで、最初から大きな開発投資をせずにユーザーの反応を確認することはできるので、どうすれば作らず(or最小限の開発で)検証できるか?を徹底的に考えました。

検証前にシナリオを決めておく

検証結果を見てから「これは良いのか悪いのか」を考えると判断がブレやすくなるため、事前に「何が起きたら成功と見るか」「何が起きたら失敗と見るか」「その場合に何を疑うか」を言語化しておきました。

「何を作って」「何を作らないか」の認識合わせを行う

作りたい機能はたくさんあると思いますが、「満たしたい体験」を実現できる最小限の機能だけを作ることを考え、なるべく早くユーザーに届けることを意識しました。そのために「何を作らないか」も言語化し、それをメンバー同士で認識を合わせることで、チームメンバー全員が作るべきものを具体でイメージできる状況を作りました。


以降、本編となりますので、詳しく知りたい方はぜひお読みください!

背景

ママリは、妊活・妊娠・出産・子育てに関する悩みを、ユーザー同士で相談できるコミュニティサービスです。これまでのママリではQ&A形式の投稿を通じて、多くのユーザーさんにご利用いただいてきました。

Q&A形式の投稿

このQ&A形式には向き不向きがあると考えています。

「困っていることを質問し、回答を得る」体験には向いていると感じる一方で、以下のような体験はQ&Aだけでは作りにくいと感じていました。

  • 同じ妊娠週数・月齢の人と日々の不安を話したい
  • 0歳児を育てている人同士で、今日あったことを気軽に共有したい
  • 不妊治療や発達支援など、身近な人には話しづらいテーマについて安心して話したい
  • 地域や生活環境が近い人と、リアルな情報交換をしたい
  • 明確な質問ではないけれど、誰かに聞いてほしい

これらのことから、質問と回答の場だけではなく、同じ境遇の人とコミュニケーションが取れる場所と、そこへの所属体験が必要なのでは?と考えました。

妊娠・出産・子育ての時期には、同じ境遇の人とリアルで出会うこと自体が簡単ではありません。出会えたとしても、親しくなるには時間がかかります。

だからこそ、ママリの中に「自分と近い人がいる」「ここなら話してもよさそう」と思える場を作ることには意味があるのではないか。
また、SNSの普及によって自己表現の機会が増える一方、他者との比較や自分をよく見せることへの疲れも生まれています。加えて、核家族化やコロナ禍を経て人とのつながりが希薄になるなかで、誰かに認められること以上に、「自分のことをわかってくれる人とつながりたい」という社会的欲求を満たす場へのニーズが高まっているのではないか、という仮説もありました。

ja.wikipedia.org

これがサークル機能の原点です。

なぜチャット形式にこだわったのか

サークル機能のUI

サークル機能で作りたかったのは、単なる情報流通ではなく、今、同じ場所(コミュニティ)に誰かがいて、気軽にコミュニケーションできる体験です。

フィード型やQ&A型のUIでは、投稿は「誰かに読まれるもの」として見えやすくなります。
そのため、投稿する側には「ちゃんと書かなければ」「わかりやすくまとめなければ」という心理的ハードルが少なからず生まれると思います。

一方で、チャット形式はもう少しカジュアルな形で投稿できるのでは?と考えました。

  • 心理的に思ったことをそのまま書きやすい
  • 会話が流れていくので、完璧な文章でなくてもよい
  • 誰かの発言にすぐ反応できる
  • 場に参加している感覚が生まれやすい

この「気軽さ」と「場にいる感覚」が、サークル機能で大事にしたい体験でした。

既存のQ&Aが「悩みを相談して答えを得る場所」だとすると、サークルが目指したのは「同じ境遇の人と、日々のことを気軽に話せる場所」であり、この違いを作るためにチャット形式にこだわりました。

機能開発する前に行える価値検証

とはいえ、いきなりママリ本体に新しいコミュニティ(投稿)機能を作るのは大きな投資です。(今であればCoding Agentなどを用いることで"作る"コストは当時と比較してかなり下がっていると思いますが)

プロダクト開発では、作ること自体が目的化してしまい「その機能が本当に課題解決につながるのか」を十分に検証しないまま開発が進んでしまうことがあります。
このような、いわゆるビルドトラップに陥らないためには最初から完成形の機能を作り込むのではなく、まずは価値仮説を小さく検証することが重要です。

今回で言えば、検証したかったのは「チャット形式の機能を作れるか」ではなく、「同じ境遇の人と気軽に話せる場所に、ユーザーさんが価値を感じるのか」でした。

そこでまず、LINEのオープンチャットを使って検証しました。
オープンチャットに複数のチャットルーム(≒サークル)を作成し、ママリアプリ本体にはサークル一覧への導線を置き、そこからオープンチャットに遷移してもらう形にしました。

当時のワイヤーフレーム

この方法を取ったのは、実装コストを抑えながら「趣味趣向や生活状況が似ているユーザー同士で気軽にコミュニケーションできる場が求められているのか?」を確認するのに最適だと考えたためです。(ちなみに他のHowとしては、Discordを使うなどがありました)

この時の検証では、主に以下をモニタリングしていきました。

  • そもそも「サークル」という導線に反応するか
  • オープンチャットに参加するだけの興味があるか
  • 参加後に実際の会話が生まれるか
  • どのテーマのチャットルームが盛り上がるか
  • 外部サービス(ここでいうところのLINE)ではなく、ママリ本体に入れる意味があるか

検証時は、妊活中、妊娠中、0歳児・1歳児・2歳児、地域系など、複数のテーマでチャットルームを用意しました。

ちなみにこのオープンチャットでの検証は、朝会のときにみんなでLINEを開き、投稿数や投稿UU数を確認していくという、かなり泥くさい分析を行っていました(懐かしい)

泥くさい集計の様子

検証前に「起こりうるシナリオ」を決めておく

検証プロセスで意識していたのは、結果が出てから解釈を考えるのではなく、事前にシナリオを考えておくことです。

たとえば、以下のような状態を検証前に想定しておきました。

  • サークル一覧がクリックされない
    • そもそも認知されていない可能性がある
  • サークル一覧は見られるが、LINEオープンチャットに参加されない
    • LINEに遷移するハードルや、参加したいテーマがない可能性がある
  • 参加者はいるが、会話が生まれない
    • 興味はあるが、発話ハードルが高い可能性がある
  • 会話が荒れてしまう
    • 安心安全や運営の仕組みが必要になる

事前に「何が起きたら、何を疑うか」を決めておくと、検証結果を見た後の議論がしやすくなります。

このような機能検証では、数字そのものよりも数字をどう解釈するかが重要だなと思っているので、検証前のシナリオ設計はとても大事だと感じました。

検証で見えたこと

オープンチャットでの検証は、参加者数だけを見ると当初の目標には届きませんでした。
一方で、参加した人の発話量は想定を超えていました。

たとえば2歳児ママのチャットルームでは投稿割合は60%を超えており、これはママリのQ&Aにおける投稿割合と比較したときに、かなり高い値でした。このような数値から、チャット形式のほうが投稿ハードルは低いのでは?という手応えを感じることができました。(ここでの投稿割合 = 投稿総数 / WAUと定義)

また、ユーザーから「こういうサークルがほしい」という要望もかなり集まりました。これは、ユーザーがサークルという概念を理解してくれている兆しでもありました。

このような検証を通じて、サークルには一定のニーズがありそうだと考えました。

ユーザーインタビューで確認したこと

オープンチャットでの検証プロセスにおいて、ユーザーインタビューも実施しました。インタビューで知りたかったのは、サークルが「ママリ本体にあるべき体験」なのかどうかでした。「便利だったか?」だけなら、外部サービスのままでも成立してしまうからです。

具体的に確認したのは、以下のような点です。

  • オープンチャットで何がよかったか
  • 逆に使いづらかった点は何か
  • ママリ本体にこの機能があったらどう使うか
  • Q&Aとサークルで、使い分けのイメージができるか
  • どんなテーマのサークルがほしいか
  • 継続して使いたい理由・使わなくなる理由は何か etc...

オープンチャットで盛り上がったからといって、そのままママリに入れるべきとは限りません。
外部サービスだから話しやすい可能性もありますし、ママリ本体に入ることで期待値が変わる可能性もあります。

だからこそ、「ママリの中にあるサークル」として自然かどうかを、定性的にも確認していきました。

開発していくにあたり何を大事にしたか

オープンチャットでの価値検証やユーザーインタビューを通して、検証開始時に定義した「機能開発に値するボーダーライン」を超えたので、この時点で本格的な開発計画を立てていきました。

ここで大事にしたのは、機能をたくさん入れることではありません。
ユーザーが「同じ境遇の人がいる場所に参加し、気軽に話し、反応に気づき、また戻ってきたくなる」体験を成立させることです。

僕はMVPよりMVE(Minimum Valuable Experience)という考え方を大事にしています。

ehandbook.com

そのため、「どんな機能を」よりも「どんな体験を」を重視し、以下のような思想で開発計画を立てていきました。

まずは“場に参加する”体験を作る

ユーザーが「このテーマなら自分に関係がある」「ここに入って会話してみたい」と思えることや、「参加したときに他のユーザーが会話している」状態を作ることは、ユーザー体験に直接関係してきます。

そのため、最初からユーザーが自由にサークルを作れる形にはせず、運営側である程度テーマを用意し、どのテーマに需要があるのかを見ながら、サークルの粒度を育てていく方針にしました。

投稿のハードルを下げる

リリース時点では「見やすい文章の投稿」よりも「思ったことをすぐ話せる」体験を優先しました。Q&Aとは違い、必ずしも質問として整理されていなくても良く、雑談や共感が自然に生まれる場を目指しました。

反応に気づけるようにする

コミュニティは投稿して終わりではなく、誰かが反応してくれて、それにユーザーが気づけることも重要です。

ただし、最初からすべての投稿を通知するとノイズになる可能性があるため、リリース時は、最低限「自分への返信に気づける」ことを重視しました。

安心して使える状態を最低限担保する

妊娠・出産・子育てに関する話題は、センシティブな内容を含むことがあります。

だからこそ、サークルでは気軽さだけでなく、安心して使えることも大事だと考え、投稿削除、ブロック、通報、退会ユーザーの扱いなど、細かな仕様もコミュニティ体験の一部として整理しました。

まとめ

ママリのサークル機能は、既存のQ&A体験だけでは満たしきれなかった「同じ境遇の人と気軽に、継続的につながる」体験を作るために始まりました。

新機能開発では、つい「何を作るか」に目が向きがちです。しかし本当に大事なのは、

  • どんな体験を作りたいのか
  • その体験にユーザーのニーズがあるのか
  • 何を最初に学べればよいのか
  • 何を作らないと決めるのか

を一つずつ明らかにしていくことだと考えています。

サークル機能の開発は、ママリにとって新しいコミュニケーション体験への挑戦でもありました。

リリースから1年経過し、徐々にユーザー数やコミュニケーション数も増えてきているので、今後もより良い体験をユーザーさんに提供できるように尽力していきます!