開発する機能の優先順位を決める方法｜5件の要望を評価する記入例
目次
要望を並べて点数を付けても、最後に「結局どれを作るか」で議論が止まることがあります。開発の優先順位を決めるには、目標、根拠、使える工数をそろえ、選ばなかった理由まで残す必要があります。
この記事では、同じ5件の要望を評価表に記入し、着手する2件、追加確認する1件、別案で対応する1件、今期見送る1件まで判断します。顧客、発言、社数、工数、日付はBtoB SaaSの架空例です。Akoreの機能や実績ではありません。 フレームワークは、この判断を補う道具として後半に紹介します。
- 比較前に目標と期間、使える総工数をそろえる
- 同じ5件を根拠・工数・依存関係で評価し、着手と見送りを決める
- 判断理由と再検討条件、次の回答日を残す。点数順だけで確定しない
まず今回の目標と工数を決める
架空の月次集計・承認業務SaaSで、次の1か月に何を進めるかを検討します。目標は「既存顧客の月次転記と、それに伴う承認の遅れを減らす」です。新規顧客の獲得も候補に含めますが、今月の目標へどの程度寄与するかを同じ基準で比較します。
使える総工数は1.5人月と仮定し、そのうち0.5人月は不具合や調査などへの余裕として確保します。要望の実装に割り当てるのは1人月です。工数はPM・デザイン・開発・テストを含むチーム全体の見積もりとし、同じ単位にそろえます。この配分や数値は、どのチームにも適用する基準ではありません。
セキュリティ事故や法令・契約上の必須対応がある場合は、通常の要望と分けて確認します。この例では、そのような必須対応はない前提です。SSOが必須かは顧客の審査条件を確認してから判断します。
同じ5件を記入済み評価表で比較する
記入済み評価表をダウンロード（CSV・架空例5件・登録不要）CSVには判断理由、回答担当、次の回答日も入っています。UTF-8（BOM付き）・カンマ区切りで、表計算ソフトへインポートして使えます。以下の表は比較部分の抜粋です。横にスクロールできます。
| ID・要望 | 目標への寄与 | 根拠・確度 | 総工数（人月） | 依存・注意点 |
|---|---|---|---|---|
| FR-001・CSV出力 | 高 | 既存3社の月次転記を確認 | 0.5 | 出力する列と権限を確認 |
| FR-002・SSO | 未確定 | 見込み1社の申告。審査条件・契約確度は未確認 | 3（粗い仮見積もり） | 認証方式・審査条件の確認 |
| FR-003・承認待ち通知 | 高 | 既存4社で承認の持ち越しを確認 | 0.5 | 既存通知基盤を利用。時刻と対象者を確認 |
| FR-004・専用Excel帳票 | 中 | 既存1社の月次転記を確認 | 2 | 取引先書式の維持が必要 |
| FR-005・画面の配色 | 低 | 既存1社の希望。業務上の支障は未確認 | 0.5 | アクセシビリティ確認 |
ここで「高」は目標に含まれる作業を直接減らす候補、「中」は目的は合うが特定の書式など個別の条件がある候補、「低」は今回の目標に結びつく困り事がまだない候補です。SSOは導入前の審査を通す話で、今回の目標への寄与を確認できていません。一般にSSOの価値が低いと決めているわけではありません。
社数は同じ顧客からの複数の連絡を重複して数えず、課題を確認した顧客数として扱います。この例の数字は説明用ですが、実際の表には商談記録や問い合わせへの参照を付け、申告・観察・推測を分けてください。受付時の原文と背景をそろえる方法は営業・CS向けの受付フォームと記入例にあります。
CSV出力と承認待ち通知を選ぶ
FR-001とFR-003を着手候補に選びます。目標への寄与が高く、課題の確認ができており、0.5人月ずつで実装枠の1人月に収まるためです。0.5人月の余裕も残ります。
ただし、見積もりが成立する範囲に絞ることが条件です。CSVは対象列を限定し、通知は既存通知基盤を使って対象者と時刻を限定する前提です。これらの確認で工数が増えたら、2件とも進める計画を固定せず、片方に絞るか範囲をさらに見直します。回答日までに実装完了を約束する段階ではありません。
| ID | 判断 | 理由・次の行動 | 次の回答日 |
|---|---|---|---|
| FR-001 | 着手候補 | 対象列を限定。FR-004への代替としても検証 | 10/9・CS担当A |
| FR-002 | 追加確認 | 審査条件と契約確度、横展開の可能性を確認して再評価 | 10/12・営業担当B |
| FR-003 | 着手候補 | 対象者と時刻を限定。通知設定・権限を確認 | 10/9・CS担当C |
| FR-004 | 別案で対応 | 専用帳票は見送り、CSVで転記を減らせるか確認 | 10/12・営業担当D |
| FR-005 | 今期見送り | 今回の目標から外れる。業務上の必要性が確認できたら再評価 | 10/9・CS担当E |
FR-004はFR-001と同じ月次転記の課題に関係するため、専用帳票を2人月かけて作る前にCSVで目的を満たせるか確認します。CSVが取引先の書式をそのまま出せるとは約束できません。代替案で作業がどこまで減るかを顧客と確かめる必要があります。
FR-002は「今期見送り」と決めず、まず確認を続けます。導入の必須条件で、他の見込み顧客にも共通すると判明すれば、来月以降の目標と工数を見直す材料になります。確認がないまま売上見込みだけを評価表へ入れても、確度は上がりません。
FR-005は0.5人月と小さくても、今回の目標につながる困り事を確認できていないので見送ります。小さい要望をすべて採用すると、優先するはずの目標に工数が残りません。再検討条件は「業務上の必要性や購買の必須条件が確認できたとき」と残します。
判断理由を台帳へ戻し、回答担当へ渡す
評価表は判断した時点の比較を保存します。受付から回答までの台帳には、同じ5件を使う顧客要望の管理表テンプレートを用意しています。採用・追加確認・見送りを決めたら、受付台帳の状態と理由、次の回答日も更新してください。PMは判断を記入し、営業・CSは顧客に返した内容を記録する分担です。
「優先度が低い」だけでは、何が変われば再検討するか分かりません。目標、根拠、工数のどれが判断に効いたのかを書きます。担当者が変わったときにも同じ議論を初めから繰り返さずに済みます。返信の文章は機能要望への返信文例を参照してください。
フレームワークは比較したい問いに合わせて使う
上の例は、目標への寄与、根拠、工数を言葉で比べています。候補が増えて順位を説明しにくくなったら、フレームワークで比較する軸をそろえます。数字を入れる前に、どの問いへ答えたいかを決めてください。
| 手法 | 比較する問い | 使うときに確かめること |
|---|---|---|
| 価値と労力 | 価値に対して工数は見合うか | 価値が今回の目標に結びついているか |
| MoSCoW | 今回の範囲に何を含めるか | Mustを満たせないと本当に成立しないか |
| ICE | 影響・確度・容易さをどう比べるか | 全候補で同じ採点基準を使っているか |
| RICE | 一定期間の影響に対して工数は見合うか | 対象と期間、単位、推定根拠がそろっているか |
| Kano | 機能の有無が満足・不満へどう影響するか | 顧客への調査で分類を確かめているか |
価値と労力で実装枠に収まる候補を探す
FR-001とFR-003のように、目標への寄与が高く工数が小さい候補を見つけるために使えます。ただし、工数が小さいFR-005まで自動的に採用する手法ではありません。価値の判断理由を先にそろえます。
MoSCoWで今回の範囲を合意する
Agile Business Consortiumの説明では、Must、Should、Could、Won't have this timeで優先する範囲を分けます。Won'tは今回の期間に含めないという区分です。永久に実装しないと顧客へ伝える意味ではありません。
FR-002の「ないと導入できない」をMustへ入れる前に、審査条件を確認します。担当者が強く希望していることと、今回の計画に必須であることは分けてください。
ICEは採点の根拠を短くそろえる
ICEではImpact（影響）、Confidence（確度）、Ease（容易さ）を評価します。素早く比べられますが、確度を担当者の熱意で採点するとFR-002の未確認事項を隠してしまいます。使う場合は採点尺度と計算方法をチームで決め、各点数の根拠を併記してください。
RICEは期間と単位をそろえて使う
Intercomが公開したRICEは、Reach × Impact × Confidence ÷ Effortで比較します。人数やイベント数を一定期間で見積もり、Impactの尺度と確度、チーム全体の人月をそろえて使います。顧客数と利用者数を同じ表に混ぜると比較できません。
Intercomの原典も、依存関係や販売の必須条件がある場合には、低いスコアの候補を先に進める理由があると説明しています。この例では、使う人数や期間をまだそろえていないため、RICEの点数は作っていません。
Kanoモデルの分類は顧客に確かめる
Kanoモデルは、機能があるとき・ないときの満足や不満の違いを分類する考え方です。PMが「これは当たり前品質だ」と決めるだけでは、顧客の反応を確認したことになりません。審査の条件が未確認のFR-002を、分類名だけで必須機能として扱うことは避けてください。
表にない依存関係とリリースの間隔を確認する
着手前に、既存機能との依存、技術的負債の影響、リリースして顧客が使える範囲を確認します。目標が同じでも、前提の実装が増えれば工数や順番は変わります。変更が分かったら評価表に追記し、なぜ当初の判断を変えたかを残してください。
ここまで紹介したフレームワークは、いずれも施策を1件ずつ評価するものでした。ここからは少し余談として、アーコレを運営する私たち株式会社Covvyの実例を2つ紹介します。
ひとつは受託開発の現場での話です。あるプロジェクトで、顧客からの要求が大きく、正面から取り組むとリリースがおよそ1ヶ月止まる見通しになりました。要求そのものの優先度は高く、フレームワークで評価しても上位に来る案件です。しかし、その1件にリソースを寄せきると、その間のリリースはゼロになります。そこで私たちは、大きな要求と並行して、事業にインパクトがあり、かつすぐに実装できるものを選び直し、リリースの頻度を落とさないように計画を組み替えました。最初に紹介した「価値と労力」でいうクイックウィンを、大きな案件の合間に意図的に挟み込む形です。優先順位づけの対象は個々の機能でも、顧客やユーザーに届くのは「リリース」という束です。スコアの高い案件から順に消化する計画は、一見合理的に見えて、リリースの空白という見えないコストを含んでいます。
もうひとつは、アーコレ自身の開発です。アーコレは現在α版で、これからβ版を展開していく段階——本記事でいう「PMF前」の探索期にあたります。この段階では、売上や解約率といった事業指標はまだ優先順位の材料にできません。そこで私たちは「学びの速さ」を基準に置き、クイックウィンをα版ユーザーに素早く届けて、フィードバックをすぐに貰える状態を保つことを優先しています。大きな機能をじっくり作り込むより、小さく出して反応を確かめるサイクルを速く回すほうが、探索期には価値が大きいと判断しているためです。
どちらの例にも共通するのは、スコアで順位を決めたら、最後に「この順番で進めたとき、ユーザーに届く頻度はどうなるか」を確かめる、という一手間です。フレームワークの表の外側にあるこの確認を、私たちは優先順位づけの仕上げとして挟むようにしています。
声の強い要望を全体のなかで扱う方法は声の大きい顧客の要望を優先すると失敗する理由、要望を集めて整理する全体像は機能要望管理の基本で扱っています。ツールを検討する場合はCannyとProductboardの違いも参照してください。
よくある質問
件数が多い要望から作ればよいですか？
件数だけで決めず、今回の目標への寄与と課題の根拠、工数を比べます。同じ顧客からの複数の連絡を別の顧客として数えないよう、元の記録も確認してください。
確認が足りない要望は見送るべきですか？
追加確認と見送りは分けます。確認担当と次の回答日を決めて、不明な導入条件などを確かめてから再評価してください。
スコアが高ければ着手を約束してよいですか？
依存関係と実装範囲、総工数を確認してから着手を決めます。次の回答日は連絡する予定であり、実装が完了する期限ではありません。
まとめ
機能がある場合とない場合を対にして確かめる手順は、Kanoモデルの質問と分類で扱っています。
契約額と機能による効果を分けて判断する方法は、事業インパクトによる優先順位付けを参照してください。
判断が止まる場合は、受付・判断・回答の役割分担から、誰が何を決めるかを確認できます。
期限が迫る要望には、急ぎの顧客要望への対応手順で、影響と回避策を確かめる方法を紹介しています。
導入するツールを選ぶときは、要望管理ツールの比較方法で、同じ要望を受付から回答まで試す手順を確認できます。
Cannyからの移行を検討している場合は、Canny代替の選び方と移行の確認点を参照してください。
開発の優先順位は、目標と根拠、使える総工数をそろえて比較します。この架空例ではCSV出力と承認待ち通知を選び、SSOは追加確認、専用帳票は別案、配色は今期見送りとしました。選ばなかった理由と再検討条件も記録し、回答担当へ渡してください。
RICEの推定値を確かめる手順は、RICEスコアの使い方と限界で扱っています。
