「初回は小さく作る」と合意したのに、打ち合わせのたびに機能が増える。そんなときは、優先順位の数字を付ける前に、今回どの業務を終えられるようにするかを決めます。
この記事は、初回リリースの範囲を調整する企画・開発担当者向けです。架空の備品貸出サービスを例に、対象外にした仕事の扱いまで整理します。表の判断や期限は記事の作例で、どのチームにも当てはまる基準ではありません。
機能数ではなく、完結する仕事を選ぶ
GOV.UKはロードマップについて、目指す成果だけでなく、何をしないかも伝えるものと説明しています。Developing a roadmap
この作例の目的は「総務担当が、貸出中の備品と返却予定を一覧から確認できること」です。社員が自分で予約する機能まで含めると、承認や取り消しの仕組みも必要になります。まずは総務が既存の窓口で依頼を受け、貸出・返却を記録する範囲を候補にします。
ここで「返却処理は次回」とすると、貸出中の一覧が更新されません。見栄えのする登録画面だけ完成しても、目的の仕事は続けられないのです。小さくするなら、貸出対象を一部の備品に絞り、貸出から返却までを通します。
対象外には、理由と当面の扱いを書く
| 要望 | 初回の判断 | 理由と当面の扱い |
|---|---|---|
| 総務による貸出・返却の記録 | 対象 | 貸出中の備品を把握するために必要 |
| 社員が自分で予約 | 対象外 | 初回は総務窓口を継続。受付担当と受付時間を案内 |
| 未返却の自動通知 | 保留 | 総務が一覧を毎営業日確認できるか、試行で確かめる |
| 貸出履歴の分析グラフ | 対象外 | 初回の運用判断には使わない。利用目的が出たら再検討 |
| 既存の貸出中データを移す | 対象 | 空の一覧から始めると実物の貸出状況と食い違う |
「保留」と「対象外」も分けます。保留は判断材料が足りない状態です。この例なら通知の判断担当を総務責任者、確認時点を試行終了時とし、手作業での確認漏れや所要時間を材料にします。対象外は、今の範囲では実装しないという判断です。将来の実装を約束する言葉ではありません。
全部が最優先になったときの聞き方
GOV.UKのユーザーストーリーの説明は、利用者・必要なこと・目的を記述するよう求めています。Writing user stories
これを範囲の相談に使うなら、要望ごとに「なくすと誰の何が止まるか」を聞きます。「便利になる」だけで同列に並べず、次の順で判断材料を集めます。
- その機能がないと、今回約束した仕事が終わらないか。
- 既存の運用で代替できるか。誰が、どれだけ引き受けるか。
- 他の機能を動かす前提になっているか。
- 判断の根拠は、実際の利用記録か、まだ仮説か。
これは点数を自動計算する方式ではありません。たとえば利用者が少なくても、台帳への不正な変更を防ぐ権限確認を「頻度が低いから」と外す判断はできません。目的を果たすための制約と、便利さを増す要望を区別します。
減らした結果、別の担当に負荷を渡していないか
「自動通知を作らない」なら確認作業は残ります。総務がその作業を引き受けられない場合、通知を必須に戻すか、対象部署をさらに絞るなど、範囲を組み直します。開発工数だけ減っても、運用できなければ初回リリースは成立しません。
また、対象外の機能を画面に残して「準備中」と表示すると、利用者には提供予定に見えることがあります。案内文も範囲の合意と揃えます。
次の打ち合わせに持っていくもの
要望一覧の隣に「今回の成果／判断／理由／代替運用の担当／再検討する条件」の5列を追加してください。まず一つの業務を、開始から終了までこの表でたどります。対象外にした工程で止まったら、その箇所が再調整の候補です。
目的自体がまだ曖昧なら要件定義の始め方、決めた範囲が完成したかを確認する段階では受け入れ条件の書き方へ進めます。