「作り始めてから、要望が止まらなくなった」
業務アプリの開発でよくあるのが、着手後に要望が積み上がっていく現象です。 最初は「日報を入力できればいい」だったはずが、 気づけば承認機能・集計グラフ・通知・スマホ対応まで話が広がっている。
困るのは、その一つひとつが理不尽な要望ではないことです。 どれも現場から見れば当然必要に見えます。 だから断りづらく、断らないまま積み上がり、納期と費用だけが膨らんでいきます。
📌 よくある展開
- 画面を見た人から「ついでにこれも」が次々と出てくる
- 途中から別部署が加わり、その部署ぶんの要望が追加される
- 「今入れておかないと二度と作れない」という空気で膨らむ
- 公開が延び続け、最初に必要だった機能すら使われないまま数か月が過ぎる
- 予算超過の説明ができず、企画そのものが止まる
要件が増えるのは、担当者のせいではない
要件が膨らむ原因は「詰めが甘かったから」だと思われがちですが、実際は違います。 人は、形のないものについて正確に要望を語れません。 画面を見て初めて「これだと足りない」と気づくのは自然なことで、 どれだけ丁寧にヒアリングしても、着手前に100%を出し切ることはできません。
発生源はおおむね3つに分かれます。①使う本人が後から気づくもの、 ②途中で参加した別部署が持ち込むもの、③「せっかくだから」と善意で足されるもの。 ①は必要な追加、②③は範囲外の追加であることが多く、 この2つを区別できないまま全部受け入れることが、膨張の正体です。
①だけを今回に入れ、②③は次回に回す。この線引きがあるかどうかで結果が変わる
断るのではなく、置き場所を用意する
要望を拒否しようとすると人間関係が悪くなり、結局は押し切られます。 有効なのは「受け取ったうえで、今回やるかどうかを分ける仕組み」を先に作っておくことです。
最初に「今回作らないもの」を書き出す
要件定義では作るものばかり書きますが、同じ紙に作らないものも明記してください。 「今回は承認機能は入れない」「スマホ対応は次回」と書いてあれば、 後から出た要望を機械的に判定でき、その場の空気で決まらなくなります。
要望リストを1つ作り、必ずそこに書く
出た要望はすべて受け取り、リストに追記します。 「却下」ではなく「リストに入りました」と返せるのが重要で、 言った側も無視されたと感じません。 そのうえで、今回入れるかどうかは別のタイミングで決めます。
関係者を最初に確定させる
途中から別部署が参加すると、範囲そのものが変わります。 対象の業務と部署を最初に決め、後から加わる場合は別プロジェクトとして扱うと決めておいてください。 これだけで、膨張の大きな一因が消えます。
「運用で回せないか」を必ず一度検討する
要望の中には、機能を作らなくても運用ルールで解決できるものが混ざっています。 月1回しか発生しない例外処理を自動化するより、手作業のまま残したほうが安いこともあります。 作る前に「頻度は？」と聞くのが効きます。
公開日を先に決めて動かさない
期限がないと、要望はいくらでも入ります。 公開日を固定し、そこに入る量だけ作ると決めれば、 自然と優先順位の議論になります。 「全部入れてから公開」ではなく「決めた日に、入る分だけ公開」に切り替えてください。
💡 一番効くのは「1」と「5」
5つのうち、費用も手間もかからず効果が大きいのは ①作らないものを書く ⑤公開日を固定するの2つです。 どちらも決めるだけで実行でき、要望が出たときの判断が一気に軽くなります。
受ける・回す・やらないを分ける4分類
出てきた要望は、次の4つのどれかに振り分けます。 その場で決めず、週に一度まとめて判断すると冷静に分類できます。
| 分類 | 当てはまるもの | 扱い |
|---|---|---|
| 今回入れる | これがないと業務が回らない／毎日発生する | ◎ 範囲に追加し、他を削る |
| 次回に回す | あると便利だが、なくても運用できる | ◎ 要望リストに記録して公開後に検討 |
| 運用で回す | 月に数回しか起きない例外処理 | △ 手順書を作って人が対応 |
| やらない | 対象業務の外／別部署の要望 | × 理由を記録して閉じる |
📌 「今回入れる」を選んだら、必ず何かを外す
追加を認めるときは、同じ量だけ別のものを次回に回すのが鉄則です。 足すだけを続けると、納期は必ず崩れます。 「入れてもいいが、代わりにこれを外します」と提示すると、 要望を出した側も本当に必要かを考えてくれます。
要望が出たときの判断4ステップ
リストに書く
可否を答えない
確認する
優先度が変わる
振り分ける
運用／やらない
全員に返す
蒸し返しを防ぐ
📌 ステップ4を省くと同じ要望が何度も出る
判断した結果を伝えないと、要望を出した人は「無視された」と受け取り、 別のタイミングで再び持ち出します。 「次回に回します」「今回は運用で対応します」と理由つきで返すだけで、 同じ議論の繰り返しがなくなります。
なんとなく受けた場合と、仕組みで分けた場合
- 公開日が何度も延び、現場の期待が冷めていく
- 費用が想定を超え、追加予算の説明に時間が取られる
- 使わない機能が増え、画面が複雑になって定着しない
- 「言ったのに入っていない」という不満が後から出る
- 公開日が動かず、まず使い始められる
- 要望が消えずに残るので、次の改修計画がそのまま作れる
- 本当に必要な機能だけが入り、画面がシンプルに保たれる
- 判断の理由が共有され、同じ議論を繰り返さない
要件が増えること自体は失敗ではありません。むしろ、 使う人が真剣に考えている証拠です。 問題は、それを受け止める置き場所と判断の基準がないこと。 リスト・4分類・固定した公開日の3つを用意するだけで、開発は驚くほど進みやすくなります。
範囲を決めるところから一緒にやります
「何を最初に作るか」で迷っている段階が、いちばん相談に向いています。
SHISAKUBAが業務を整理して初期範囲を提案し、最短1週間で試作品をご用意します。