全部同時にはこなせない、という前提から始める
サービスを公開してユーザーがつき始めると、思っていたより早く「要望」が届きます。DMで届く一言、フォームに書かれた長文、口頭で言われた一言のフィードバック。ありがたい反面、数が増えてくると「どれから手をつけるべきか」で手が止まってしまう瞬間が来ます。
ここで陥りやすいのが、届いた順に着手する、あるいは声の大きい人の要望を優先してしまうパターンです。どちらも一見公平に見えて、実は判断を放棄しているのと同じです。自己資金で開発を回している個人開発者にとって、1つの機能追加にかけられる時間とお金は有限です。だからこそ、要望を「全部やる前提のToDoリスト」ではなく「選ぶための候補リスト」として扱う必要があります。
この記事では、複数の要望を前にしたときに使える、3つの軸での優先順位のつけ方を整理します。
軸1：要望の頻度を数える
まず確認したいのは、その要望が「何人から」「何回」出ているかです。1人が熱心に主張している要望と、複数の別々のユーザーが独立に同じことを言っている要望では、後者のほうが優先度が高いと考えるのが基本です。
要望を集める仕組みがまだない場合は、フォーム・DM・アプリ内アンケートなど声を集める手段の選び方を参考に、まず「要望が自然に集まって、後から数えられる状態」を作ることが先決です。感覚だけで「よく言われている気がする」と判断すると、直近で強く印象に残った意見に引っ張られやすくなります。
頻度を見るときの簡単な整理法は次のとおりです。
- 3人以上が独立に言っている → 優先度高。仕様として一般化できないか検討する
- 1〜2人だが具体的な業務課題が背景にある → 保留。同種の要望が今後増えるか様子を見る
- 1人からの一度きりの要望 → 保留、または個別対応で済ませられないか検討する
特に専門職スピンオフ型や店舗・地域事業者DX型のように、既存の顧客・同業者とのつながりを持って始めた方は、声の届きやすい特定の1人の要望が実は業界全体の代表意見であることも珍しくありません。頻度だけでなく「この人の背後に同じ悩みを持つ人が何人いそうか」まで想像してみると、数字だけでは見えない優先度が見えてきます。
軸2：実装コストを実感値で見積もる
次に見るべきは「どれだけの労力で作れるか」です。ここで重要なのは、精緻な工数計算をしようとしないことです。個人開発の段階で必要なのは、次の3段階程度のざっくりした感覚で十分です。
| コスト感 | 目安 | 対応方針 |
|---|---|---|
| 小 | 数時間〜1日で形になる | 頻度が低くても着手候補にしてよい |
| 中 | 数日〜1週間かかる | 頻度・事業方向性との整合を必ず確認してから着手 |
| 大 | 設計から見直しが必要 | 単独の要望では動かず、他の要望と合わせて検討する |
「小さくて頻度も高い」要望は迷わず着手してよい領域です。逆に「コストは大きいが要望した人は1人だけ」という組み合わせは、多くの場合は保留が妥当です。AIコーディングツールを使って試作を作っている段階であれば、AIの回答をそのまま信じて実装する前に、確認すべきことにあるように、コストの見積もり自体をAIに丸投げせず、自分の手で一度触ってから感覚を掴んでおくと判断がぶれにくくなります。
軸3：事業の方向性との整合を確認する
頻度とコストだけで判断すると、見落としがちな軸があります。それは「その機能が、自分がこのサービスで目指している方向と合っているか」です。
要望の中には、頻度が高くコストも低いのに、実装すると事業の軸がぼやけてしまうものがあります。たとえば、特定の業務を効率化するために作ったツールに「他の業務も一括管理できるようにしてほしい」という要望が来たとします。頻度が高くても、それが「専門特化したツール」という当初の強みを薄めるなら、慎重に判断する必要があります。
逆に、要望の頻度自体は低くても、自分が当初思い描いていた将来像に沿っている機能であれば、優先度を上げる判断もあり得ます。ここで基準になるのが「あれもこれも」で機能が増えすぎるのを防ぐ考え方です。要望に応え続けること自体が目的化すると、気づけば誰のためのサービスか分からなくなってしまいます。
3つの軸を並べると、判断の全体像はこう整理できます。
- 頻度が高く、コストが低く、方向性にも合う → 最優先で着手
- 頻度は高いが方向性とズレる、またはコストが大きい → 一度保留し、代替案(小さく試せる形)がないか検討する
- 頻度が低く、方向性とも関係が薄い → 記録だけ残して着手しない
この判断を一度の思いつきで終わらせず、都度同じ軸で振り返れるようにしておくことが、要望に振り回されずに開発を続けるコツです。
詳細な進め方はコラムへ
この記事では優先順位をつけるための3つの軸を紹介しましたが、実際の運用に落とし込むには、もう少し具体的な検討が必要になる場面が出てきます。
たとえば、優先順位をつけた後の実務的な進め方については 公開後の機能追加、優先順位をどう決めるか で、要望が積み重なって収拾がつかなくなる前の防ぎ方については 「あれもこれも」で機能が増えすぎるのを防ぐ考え方 で、それぞれより深く扱っています。また、要望を集める仕組みそのものをまだ作っていない場合は、フォーム・DM・アプリ内アンケート、声を集める手段の選び方 を先に読んでおくと、この記事の「頻度を数える」という前提が整いやすくなります。
要望への対応は、公開後のサービス運営でもっとも判断の連続を求められる場面のひとつです。焦って全部に応えようとせず、自分の判断軸を持って一つずつ選んでいく姿勢を大切にしてください。