26
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

その機能、本当に必要?潜在ニーズに響く「最速MVP」の絞り込みTips

Last updated at Posted at 2025-12-06

RUNTEQ Advent Calendar 2025 の7日目を担当します、なつのじです。
RUNTEQ72期生としてプログラミングを学びつつ、SaaS業界でプロダクトマネージャー(以下PdM)をしています。

この記事は、これからエンジニアとしてプロダクト開発の世界へ飛び込む方々、そして現場でPdMと協働する機会がある方々になにか共有できることはないかと思い、自分なりにノウハウを整理し、学びを深めるために書いてみました。

PdMの思考プロセスを共有することで、現場で開発を進める皆さんが、プロダクトの意図を理解しながら、より円滑に業務を進める一助となれば幸いです。

【読者の皆さまへ】
本記事で紹介するノウハウは、私が特定の講習や資格に基づいたものではなく、これまでの実務経験の中で確立した実践知となります。プロダクトマネジメントにおける一つの考え方、アプローチとしてご参考ください。

以前、私は個人でアプリを開発した時のMVP意識について、noteにまとめました。

では、チームでプロダクトを開発する現場では、PdMはこのMVPの絞り込みをどのように進化させ、開発チームへ依頼する機能を決めているのでしょうか?

今回のテーマは、多くの要望が入り混じる現場でPdMが、「最小限の実行可能なプロダクト(MVP)」を見つけるための、実践ノウハウの共有です。

まず最初に謝っておくのですが、最小(Minimum)を語る記事なのに、話したいことがつらつら書いていたら文章はMaximum Viable Productになってしまいました:joy:! お時間があれば最後までお付き合いいただけると嬉しいです。

PdMが目指すのは、表面的な要望(How)を実装することではなく、その裏にある潜在的な課題(Why)を解決し、最小の労力で市場に必要とされるプロダクトを創り上げることです。

PdMが「作るもの」を大胆に絞り込む思考のステップを見ていきましょう:eyes:


:bulb: 第1章:どのターゲットに対してどのようなサービスを提供するか?

今回考える題材として、私たちが作ろうとしているサービスは、多くの人が直面する「家計簿の利用が続かない」という課題を解決するための家計簿アプリであるとします。

  • 選定した題材:「挫折しない!シンプルな家計簿アプリ」

加えて、会社から与えられた大枠のターゲット課題は以下の通りであるとします。

会社が定めたターゲット課題:
「手動入力が面倒で家計簿が続かない人が多いため、入力を自動化できる便利な家計簿アプリが必要である」

この大枠に対し、「誰」の「どんな潜在的ニーズ」に答える機能をMVPとして実装すれば、最短で最大の価値を創れるか検討を進めていきましょう。


:busts_in_silhouette: 第2章:具体的な「誰」の課題を最優先で解決するか?

機能の絞り込みは、「誰の課題を解決しないか」を決めることから始まります。MVP開発では、リソースが限られているため、最重要ペルソナを一人に絞り込むことが不可欠です。

最重要ペルソナ A:「節約の最初の一歩を踏み出したい社会人」

私たちが最初に救うべきは、複雑な機能よりも「継続と習慣化」を求める人になります。

項目 詳細
状況 毎月の支出は把握したいが、レシートを見ながらの入力作業が億劫で、いつも途中で挫折してしまう
真の課題 「複雑な作業から解放され、とにかく記録を『継続』することを習慣化したい」と「自分が何にお金を使っているか、全体像をパッと把握したい」

🔪 あえて切り捨てるペルソナ(今回は MVP 対象外)

資産運用や詳細な予算シミュレーションを求める人、ビジネス経費を管理したい人など、最重要ペルソナ A 以外の課題は現時点では切り捨てます。彼らの課題は、MVPが市場で成功した後のロードマップに回します。
PdMにとって何をやるべきかを決めることはとても大事ですが、それ以上に何をやらないかを決めることが最も大事です。


:speaking_head: 第3章:要望の裏側を深掘りする「Whyの探求」

PdMの重要な仕事の一つは、ユーザーから提示された「機能要望(How)」をそのまま鵜呑みにせず、その裏にある「真の課題(Why)」を深掘りすることです。

PdMとユーザーの対話イメージ

ステップ 役割 発言(思考) 掘り下げポイント
1. 要望提示 :girl: :ユーザー 「ぜひ銀行口座の自動連携機能を付けて欲しいです」 ユーザーは解決策(How)を提示している。
2. まず感謝 :cat:なつのじ 「貴重なご意見ありがとうございます!ぜひ参考にさせてください」 ユーザーのアイデアを尊重する。
3. Whyの深掘り :cat:なつのじ 「なぜ銀行口座の連携が必要だと思ったのか、その理由をもう少し詳しく教えていただけますか?」 解決策の背景にある動機を聞く。
4. 現状の管理方法の確認 :girl: :ユーザー 「自分で入力するのが面倒で、数日経つと何に使ったか思い出せないんです。だから自動で記録したいです」 課題の発生源が「記録の漏れ」と「記憶の負荷」にあることが判明。
5. 真の課題を問う :cat:なつのじ 「なるほど。では、その『記録が漏れること』が、あなたにとってどんな困りごとが起きるのでしょうか? 問題点(Pain Point)を具体的に問い、「お金の全体像が見えない不安」という感情的な課題に迫る。

:mag: 深掘りでたどり着いた真の課題

対話の結果、最重要ペルソナAの真のニーズは、「高度な自動連携」という機能ではなく、「記録作業が極限まで楽になる」こと、そして「毎月の支出の傾向」を知り、「お金への不安を減らしたい」という感情的な価値だと判明しました。

MVPの核は、この「記録の負荷を最小化し、全体像を見せる」という潜在ニーズを解決する最小の機能に決定します。


:hourglass_flowing_sand: 第4章:機能を絞り込むことで「機会損失」を防ぐ

機能を絞り込むことは、単なる開発リソースの節約ではなく、ビジネス上の致命的な機会損失を防ぐという、PdMとして最も重要な役割を果たします。

タイミングを逃すことで機会損失をしてしまう

プロダクトには、市場で最も必要とされるタイミング」があります。

  • 例:確定申告サービスの場合
    確定申告は例年2月中旬から3月中旬にかけて行われます。もしあれもこれもとフル機能を目指した結果、リリースがこの時期に間に合わなかった場合、ユーザーは今年度利用することができず、丸一年間、利用機会を損失してしまいます。

家計簿アプリも同様に、「新年度が始まる4月」や「お正月明けの家計の見直し時期」に、ユーザーが「よし、家計簿をつけてみようかな」と決意する時期が市場に最も必要とされるタイミングです。ここで競合よりリリースが遅れると、ユーザーが他のアプリに流れてしまい、習慣化の機会を失うことになり、大きな痛手となってしまいます。

品質リスクと開発スピード

機能を絞り込むもう一つの重要な理由は、品質を確保し、開発スピードを維持することです。

  • 機能を作りすぎると、テストに要する時間が増加します
  • それにより、リリースが遅延するだけでなく、作り込んだ機能の複雑さが原因で、バグを発生させてしまうリスクも高まります

MVPは、この「機会損失」と「品質リスク」を回避し、市場で必要とされる最小の価値を、最も速く、安定した状態で提供するための戦略なのです。


:scissors: 第5章:MVP要件の「絞り込み」と「切り捨て」の実践

潜在ニーズとタイムラインの重要性がまとまったところで、MVPの機能要件を定義します。

解決すべき核となるニーズ

  • 「記録作業の負荷の最小化」と「支出の全体像の把握」

MVPに残す核となる機能

これらニーズを満たすための最小限の機能だけを実装します。

  1. レシートのOCR読み取り機能: 銀行連携のような複雑な機能ではなく、「撮影するだけ」という入力負荷が極めて低い方法に絞る(※最初のMVPとして、手動入力とレシート撮影のみに絞ります)
  2. 月間のシンプルなレポート: 「食費」「交通費」など、大まかな分類のグラフと総額だけを表示する
  3. 入力忘れ防止のリマインダー: 継続を促すために、記録が途切れたらプッシュ通知で促す機能

切り捨てる機能

  • 銀行・クレジットカードの自動連携機能
  • 資産運用や投資の管理機能
  • 予算シミュレーションや目標設定機能
  • 詳細なカテゴリ設定(カスタムカテゴリなど)

これらは、最重要ペルソナの最初の「継続」という課題解決には必須ではないため、MVPでは切り捨て、今後のロードマップへと回します。


:thumbsup: 終章:プロダクト開発における「共通言語」としてのMVP

PdMとエンジニアの共通言語

MVPの定義は、PdMの独りよがりではなく、開発チーム全体(エンジニア)の共通言語として機能します。判断軸が明確になることで、エンジニアの皆さんは迷うことなく、効率的に開発に集中できます。

チーム開発へ活きる考え方

このMVPの考え方は、一人でアプリ開発をする際にもそのまま適用できると思っています。

個人開発では、PdMとエンジニアの両方の役割を担い、「何を作るか」と「どう作るか」の全てを自分で判断します。

一方、チーム開発では、PdMが「何を作るか(MVPの絞り込み)」を設計し、エンジニアの皆さんが「どう作るか」の実現に集中できるよう、役割が分担されます。この役割分担があるからこそ、機能の実現性が高まり、一人では作れない大きなプロダクトを生み出すことが可能になります。

:rocket: 最後に:PdMの思考プロセスを共有することの意義

今回は、チーム開発におけるPdMのMVP絞り込みノウハウを共有しました。

PdMの思考プロセスを理解することは、皆さんが開発現場に入られた際、チーム開発をよりスムーズに進めるための助けになるかもしれません。

この記事が、皆さんの今後のキャリアにおいて、「そういえば昔誰かがこんなことを言っていたな〜」と思い出される機会があれば幸いです。
(MVPとかいいながら記事が長くなってしまって申し訳ないw)

最後まで読んでいただき、ありがとうございました。

まだまだRUNTEQ Advent Calendar 2025 は続きますので、これからもぜひ楽しみにしていただければと思います!
よい年末をお過ごしください!:santa::christmas_tree:

26
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
26
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?