機能の優先順位を決める会議の進め方｜議題と議事録のテンプレート
目次
機能の優先順位を決める会議では、最初に「今回どの範囲を決めるか」をそろえ、候補を同じ条件で比べ、決定・保留・次の確認を記録します。全員の希望を一度に並べるだけでは、話が広がり、誰が何を進めるかが曖昧になります。
この記事では、会議の準備と進行、議事録のテンプレートを紹介します。候補の採点や比較方法は、開発する機能の優先順位を決める方法に分けています。
- 今回の目標・対象期間・使える工数・決める人を事前にそろえます。
- 候補ごとに、根拠と未確認点を分けて話します。
- 決定だけでなく、保留の理由・確認担当・再検討条件まで残します。
事前資料は、同じ項目で比較できる形にする
会議の目的は「たまった要望を見る」より、「次の期間に詳しく検討する候補を選ぶ」「着手可能な範囲を決める」のように書きます。調査を始める判断と、実装を始める判断は異なります。
参加者に共有する資料には、少なくとも次の項目をそろえます。情報がない欄は空欄で流さず、未確認と記載します。
| 事前にそろえる項目 | 確認する内容 |
|---|---|
| 今回の目標 | どの利用者の、どの作業を改善したいか |
| 対象期間と工数の枠 | いつまでの判断か。保守などを含め何に使える枠か |
| 候補と根拠 | 要望ID、困っている場面、原記録への参照 |
| 実現性と依存関係 | 調査・設計・検証を含む見積もり、先に必要な作業 |
| 未確認点 | 判断が変わりそうな不明点と、確かめる方法 |
| 会議で決めること | 調査、着手、保留、見送りなど、今回の判断範囲 |
候補の説明量にも差をつけすぎないようにします。営業が詳しく説明した要望と、短い一文だけの要望を、準備の差を無視して比べないためです。
決める人と、判断材料を出す人を分ける
進行役は議題と時間を管理し、判断を担う人は合意した権限の範囲で決定します。営業・CSは顧客の背景を、開発担当は見積もりや依存関係を補います。一人が兼任しても、役割の違いは明確にします。
たとえば、開発のフレームワークであるScrumを採用する場合、Scrum Guideでは、改善に必要な作業を順序付けて並べるプロダクトバックログの管理にプロダクトオーナーが責任を持ちます。ただし、この記事の会議をScrumの公式イベントや、スプリントで取り組む内容を決める会議の代わりとして定めるものではありません。実際の権限と進め方は、自社の開発体制に合わせて確認してください。
誰が判断するかが決まっていない場合は、先に受付・判断・回答の役割分担を整理します。進行役が勝手に結論を決めたり、参加者の多数決だけで責任を曖昧にしたりしないようにします。
議題は、前提・比較・決定の順にする
以下は45分の会議を想定した本記事の進行例です。標準時間や、必ず45分で決まることを示すものではありません。候補数や論点に合わせて調整します。
| 目安 | 議題 | 終了時に残すこと |
|---|---|---|
| 0〜5分 | 目標・工数・判断範囲の確認 | 今回変えない比較条件 |
| 5〜15分 | 候補の根拠と未確認点の確認 | 比較できる候補と、確認が必要な候補 |
| 15〜30分 | 効果・工数・依存関係の比較 | 意見が分かれる前提と、その影響 |
| 30〜40分 | 決定・保留・見送りの整理 | 各候補の扱いと理由 |
| 40〜45分 | 担当・次の確認・伝達の確認 | 会議後に誰が何を更新するか |
点数を使う場合も、点数の違いだけを争わないようにします。「対象顧客の数が違う想定になっている」「見積もりにテストを含めていない」と分かれば、まず前提をそろえます。RICEスコアも、数字の根拠が分からなければ、比較を助ける材料になりません。
決定と保留を残す議事録テンプレート
議事録には話した順番を全部書くより、後から判断を再現できる情報を残します。次の表は一つの候補につき複製して使える形です。
| 項目 | 記入欄 |
|---|---|
| 会議日・判断を担う人 | ［日付／役割・氏名］ |
| 今回の目標・比較条件 | ［対象期間／工数の枠／目的］ |
| 候補ID・名称 | ［元の要望と対応するID／短い名称］ |
| 決定 | ［調査・設計を進める／実装へ着手する／保留する／今回は見送る］ |
| 決定の理由 | ［今回の目標との関係と、確かめた根拠］ |
| 残る不明点 | ［未確認事項／判断への影響］ |
| 次の作業・担当 | ［具体的な作業／担当者］ |
| 確認する時点・再検討条件 | ［次に見る日／判断を変える条件］ |
| 更新・連絡する先 | ［台帳／開発記録／顧客への回答など］ |
記入例：決めきれない候補も、次の作業へ進める
次は、架空の申請管理ツールの改善会議です。目標は「月末の集計作業で、手作業の確認を減らすこと」。工数などの数値は置かず、候補の扱いの違いを示します。
| 候補 | 会議で決めた扱い | 理由と次の作業 |
|---|---|---|
| A：集計条件を保存する | 詳細設計へ進める | 同じ条件を繰り返し入力する記録がある。開発担当が権限ごとの動作と工数を確認し、実装への着手可否は次回判断 |
| B：承認通知を増やす | 追加調査まで保留 | 見落としの原因が通知数か確認手順か未確認。CSが対象者の直近の作業を確認 |
| C：一覧の色を変える | 今回は見送る | 今回の集計目標との関係を確認できていない。元の要望は残し、業務への影響が分かれば再検討 |
Aを「採用」とだけ書くと、そのまま実装してよいと伝わるかもしれません。この例では、決めたのは詳細設計に進むことです。公開日を決めたわけではありません。
Bは「保留」の一語で終わらせず、確認内容と担当を置きます。Cも不要と断定せず、今回の見送り理由と再検討条件を残します。
会議後は、記録と回答を更新する
会議が終わったら、議事録だけでなく、元の要望台帳や開発側の記録にも決定を反映します。同じ候補の状態が別々の場所で異なると、次の会議で再び確認が必要になります。
顧客へ伝える担当者は、今回決まった範囲を確認してから回答します。「調査を進める」「実装を決めた」「公開済み」は別の状態です。表現に迷う場合は、機能要望への返信文例を参照してください。
次の会議では、前回の保留項目から確認すると、調べた結果が判断に使われたかを追えます。まずは次の議事録に、保留理由・担当・再検討条件の3欄を追加してみてください。
