新規プロダクトや新機能では、「要件が固まりきらないうちに開発を始めたい、あるいは始めざるを得ない」場面がよくあります。市場の反応を見ながら方向を決めたい、使ってみないと分からない——こうした状況で、無理に要件を固めて請負一括で発注すると、変更のたびに追加見積もりと手戻りが発生し、結果的に高くつきます。
要件が動くこと自体は、悪いことではありません。問題は、動く前提に合わない進め方を選ぶことです。この記事では、要件が固まらないまま開発を進める方法を、契約形態の選び方から優先度の回し方まで手順で解説します。契約形態の違いは開発の準委任契約と請負契約の違い、外部リソースの選び方全体は開発リソースが足りないときの外部活用ガイド、依頼前の準備は開発を外注する前の準備チェックリストもあわせてご覧ください。
なお筆者・馬込は、要件が動くプロダクト開発に、発注側・受託側の双方で関わってきました。本記事はその実務目線でまとめています。
結論：固めるのではなく「動く前提の進め方」に切り替える
要件が固まらないときの正解は、無理に固めることではなく、動く前提に合った進め方に切り替えることです。具体的には、①契約形態を動く前提に合わせる → ②優先度で開発を回す → ③変更を前提に扱う、の3つです。順に見ていきます。
手順1：契約形態を「動く前提」に合わせる
まず、契約形態を要件の状態に合わせます。要件が固い開発と動く開発では、向く契約が逆になります。
| 要件の状態 | 向く契約形態 | 理由 |
|---|---|---|
| ほぼ固まっている | 請負一括 | 総額を固定でき、抑えやすい |
| これから詰める／動く | 準委任（月額） | 変更を吸収でき、稼働ベースで進められる |
動く要件を請負一括にすると、変更のたびに追加見積もりが発生し、手戻りコストも積み上がります。動く前提なら、稼働ベースの準委任のほうが、費用の見通しが立てやすくなります。
手順2：優先度をつけて「決まったところから」進める
要件全体が固まるのを待つのではなく、決まっている部分・重要な部分から着手します。全部を決めてから作るのではなく、作りながら決めていく進め方です。
- 機能に優先度をつけ、重要かつ決まっているものから実装する
- 短い区切り（例：2週間）で成果を確認し、次の優先度を決める
- 使ってみて分かったことを、次の区切りの計画に反映する
この「区切って進め、都度優先度を見直す」やり方なら、要件が動いても、そのつど最も価値のある部分に手を向けられます。
手順3：変更を「例外」ではなく「前提」として扱う
要件が動く開発では、変更は例外ではなく前提です。変更を悪いことと捉えず、優先度の調整で吸収する仕組みを持ちます。
- 変更が出たら、優先度の見直しで取り込む（何かを後ろに回す）
- 「変更＝追加費用」ではなく「限られた稼働の中での入れ替え」と捉える
- 決めきれない部分は、決める期限だけ決めておく
変更を毎回の追加見積もりで処理すると、コストも心理的な負担も膨らみます。稼働の枠の中で優先度を入れ替える形にすると、変動を織り込みながら進められます。
手順4：発注側がやるべきことを決めておく
要件が動く前提で進めるとき、発注側の関わり方が成否を分けます。請負一括なら「決めて渡して待つ」で成立しますが、動く前提の進め方では、発注側が判断し続ける必要があります。ここを委託先任せにすると、優先度が決まらず開発が止まります。
発注側が担うのは、次の3つです。
| 発注側の役割 | 具体的に何をするか |
|---|---|
| 優先度を決める | 区切りごとに「次に何をやるか」を判断する |
| 早く見て、早く返す | 動くものを確認し、方向のズレを小さいうちに直す |
| 決める期限を守る | 保留にした事項を、決めた期限までに決める |
特に2つ目が効きます。動く前提の開発では、作ったものを見て初めて分かることが多い。早く見て早く返すほど、手戻りは小さくなります。逆に、レビューが1週間止まると、その間の開発はズレたまま進みます。
つまり、動く前提の進め方は「発注側がラクになる方法」ではありません。総額を固定する代わりに、判断の責任を持つやり方です。ここを理解して選べば強力ですが、丸投げのつもりで選ぶと、請負以上に混乱します。自社が優先度を決められるか——これが、この進め方を選べるかどうかの前提条件です。
よくある落とし穴
- 無理に固めて請負発注する：変更のたびに追加費用と手戻りが膨らみます。動く前提なら準委任を検討します。
- 全部決まるまで着手しない：機会を逃し、決めるための情報も得られません。決まったところから進めます。
- 変更を例外扱いする：都度の追加見積もりでコストが膨らみます。優先度の入れ替えで吸収します。
- 期限を決めずに保留する：いつまでも決まりません。決める期限だけは決めておきます。
- 丸投げのつもりで準委任を選ぶ：動く前提の進め方は、発注側が優先度を決め続ける前提です。任せきりだと請負以上に混乱します。
- レビューを溜める：確認が1週間止まれば、その間の開発はズレたまま進みます。早く見て、早く返すほど手戻りは小さくなります。
よくある質問
Q. 要件が固まらないと、費用の見通しが立たないのでは？ A. 総額は固定しにくいですが、準委任なら「月額×期間」で費用の見通しは立てられます。むしろ、動く要件を請負一括にするほうが、変更費で当初予算を超えやすく、見通しが崩れます。動く前提では稼働ベースのほうが読みやすいことが多いです。
Q. 準委任だと、際限なく費用がかかりませんか？ A. 優先度をつけ、区切りごとに成果を確認する運用なら、コントロールできます。毎回の区切りで「次に何をやるか」を決めるため、費用に対して何が進んだかが見えます。丸投げにせず、優先度の意思決定を発注側が持つことが前提です。
Q. アジャイルとは違うのですか？ A. 考え方は近く、「区切って進め、都度優先度を見直す」進め方はアジャイルの発想と重なります。用語にこだわる必要はなく、要件が動く前提なら、固定の総額発注より、優先度を回しながら進める形が向く、と捉えれば十分です。
要件が固まらないまま開発を進めるには、①契約形態を動く前提に合わせる ②優先度をつけて決まったところから進める ③変更を前提として優先度で吸収する、という進め方に切り替えます。固めることではなく、動く前提に合った進め方を選ぶことが、手戻りを抑える鍵です。
要件が動く開発の進め方や契約形態の相談は、無料相談（30分）からお問い合わせください。