「社内の調整がまだ終わっていないのに、年度内に動き出したい」「連携先の仕様が先方から出てこない」。システム開発では、すべてが決まってから発注できるケースのほうがまれです。
「開発を始める時点でまだ決まっていないことがあるのですが、そのまま発注して大丈夫でしょうか？」
先に結論をお伝えします。「決まっていないこと」があっても発注はできます。ただし、何が決まっていないのかを書き出して、「いつ・誰が・どうやって決めるか」まで合意してから始めることが条件です。未確定のまま一括で金額を固めてしまうと、後から追加費用や納期の遅れで揉めやすくなります。
この記事では、未確定事項の洗い出し方、契約を分けて進める考え方、そのまま使える管理表のひな形、開発会社への質問例を解説します。
なぜ「決まっていないまま」だと揉めやすいのか
見積もりは「決まっていること」を前提に作られる
開発会社は、聞いた内容をもとに作業量を見積もります。決まっていないことは、①含めずに見積もる、②「こうなるだろう」と仮定を置いて見積もる、のどちらかになります。後から実際の内容が仮定と違ったとき、その差額が追加費用や納期延長として表面化します。
双方が「相手が決めてくれる」と思いがち
発注者は「プロの開発会社が決めてくれる」と考え、開発会社は「業務のことは発注者が決めてくれる」と考えている。この食い違いがあると、決まっていない項目が誰のものでもないまま放置されます。
決めるのが遅れるほど、作り直しが大きくなる
画面が完成してから「やっぱりこの項目も必要」となるより、設計の段階で決まっているほうが、手戻りの量は小さくて済みます。
未確定事項は3種類に分けて考える
「決まっていないこと」と一口に言っても、性質が違います。種類によって対応が変わります。
| 種類 | 例 | 対応の基本 |
|---|---|---|
| ① 発注者側の社内で決まっていない | 承認フローの最終形、部署間の業務ルール、予算の確定 | 発注者が決める。期限を切って社内で決着をつける |
| ② 外部の事情で決まっていない | 連携先システムの仕様、法改正への対応、取引先の要望 | 決まる時期を確認し、決まるまでの間の仮置きを合意する |
| ③ やってみないと分からない | 既存データの品質、AIの精度、新しい技術の相性 | 小さく試して確かめる工程を先に置く |
①は発注者の責任で決めるものです。IPA（情報処理推進機構）も、要件を定義する責任は発注者側にあるという考え方を示しています。
📰 出典：IPA（情報処理推進機構）「ユーザのための要件定義ガイド 第2版」
②と③は、発注者が頑張っても今すぐ決められないものです。ここを「分からないまま一括で請け負ってもらう」のではなく、分からない部分を分けて扱うのがコツです。
進め方：未確定事項を抱えたまま安全に始める5ステップ
ステップ1：決まっていないことを全部書き出す
まずは種類を問わず、思いつく限り書き出します。「まだ決まっていない」と分かること自体が、開発会社にとって大切な情報です。完璧でなくて構いません。
ステップ2：「決める人・決める期限・決まらない場合の仮置き」を付ける
各項目に3つの情報を付けます。
- 決める人：誰が最終判断をするのか（会社名ではなく役職・担当まで）
- 決める期限：いつまでに決まれば、スケジュールに影響しないか
- 仮置き：期限までに決まらなかった場合、いったんどうするか（例：「承認は1段階で作り、後から増やせる設計にする」）
ステップ3：影響の大きさで並べ替える
未確定事項のうち、費用・期間に大きく影響するものから順に決めていきます。画面の文言のように、後から直しやすいものは後回しでかまいません。
ステップ4：契約を「分けて」進める
未確定事項が多いときは、最初から全体を一括で契約しない進め方が有効です。経済産業省の「情報システム・モデル取引・契約書」では、システム開発を段階に分け、上流工程（要件定義など）と開発以降を別の契約として結ぶ「多段階契約」の考え方が示されています。
イメージは次のとおりです（あくまで一般的な考え方で、実際の契約形態は案件ごとに開発会社と相談してください）。
- まず要件定義・設計だけを依頼する：作るものを固める段階。この時点で費用と期間の精度が上がる
- 固まった内容で開発の見積もりをもらう：未確定事項が減った状態での見積もりなので、ブレが小さい
- 開発以降を契約する：1の結果に納得できなければ、ここで見直したり他社と比べたりもできる
「最初に総額が分からないと社内の稟議が通らない」という場合は、後述のとおり、概算の幅と、その幅が確定する時期を教えてもらう方法があります。
ステップ5：決まった内容と変更の扱いを文書に残す
未確定だった項目が決まったら、メールや議事録で残し、双方が確認します。「その決定が費用や期間に影響するか」も一緒に確認しておくと、後から「聞いていない」となるのを防げます。変更の扱いについては、次の記事も参考にしてください。
詳しくは次の記事で解説しています。
そのまま使える「未確定事項の管理表」ひな形
| No | 未確定の内容 | 種類（①社内／②外部／③試さないと不明） | 決める人 | 決める期限 | 仮置き（決まらない場合） | 費用・期間への影響 | 状況 |
|---|---|---|---|---|---|---|---|
| 1 | （例）承認ルートの段数 | ① | 総務部長 | ◯月◯日 | 1段階で作り、増やせる設計にする | 小 | 検討中 |
| 2 | （例）連携先システムのデータ項目 | ② | 先方担当（窓口：情シス） | ◯月◯日 | 現行CSVの項目で作る | 大 | 回答待ち |
| 3 | （例）既存データの品質 | ③ | 開発会社＋現場担当 | 要件定義の中で | サンプル100件で先に確認する | 大 | 未着手 |
この表を開発会社と共有し、定例の打ち合わせのたびに見直します。「誰が・いつまでに」が見えるだけで、決まらないまま放置されることが大きく減ります。
やりがちな失敗
- 未確定事項を伝えずに「確定している前提」で見積もってもらう：安く見えても、後から差額が出ます。隠さずに伝えるほうが結果的に安全です
- 「後で相談」の一言で済ませる：誰が・いつまでに決めるのかがないと、期限が過ぎても誰も動きません
- 決まらないまま一括の固定金額で契約する：開発会社側も、リスク分の余裕を上乗せせざるを得なくなります。双方にとって不利になりがちです
- 外部の事情を確認せずに放置する：連携先の仕様が決まる時期を聞いていないと、スケジュール全体が止まります
発注者がやることチェックリスト
- ☐ 決まっていないことを、思いつく限り書き出した
- ☐ 各項目を「社内／外部／試さないと不明」の3種類に分けた
- ☐ 項目ごとに、決める人・期限・仮置きを決めた
- ☐ 費用・期間への影響が大きい項目を、先に決める順番にした
- ☐ 最初の契約を要件定義・設計だけにできるか、開発会社に相談した
- ☐ 総額の概算に幅があることを、社内の関係者に伝えた
- ☐ 決まった内容は、メールや議事録で双方が確認する運用にした
開発会社への質問例
- 「まだ決まっていない項目が◯件あります。この中で、費用や納期に特に影響するのはどれですか？」
- 「見積もりには、どんな前提（仮定）を置いていますか？その前提が変わったとき、費用はどう変わりますか？」
- 「要件定義・設計だけを先に依頼して、その後に開発を判断する進め方はできますか？」
- 「連携先の仕様が決まらない場合、いったんどういう形で作り進められますか？」
- 「決まっていない項目が決まった時点で、見積もりを見直してもらえますか？その手順を教えてください」
まとめ：「決まっていないこと」を隠さず、分けて進める
仕様が固まっていなくても、発注はできます。大切なのは次の3点です。
- 決まっていないことを書き出し、決める人・期限・仮置きまで合意する
- 未確定事項が多いときは、要件定義と開発を分けて契約することを検討する
- 決まった内容は文書に残し、費用・期間への影響も確認する
「まだ決まっていない」と正直に伝えることは、弱みではなく、開発会社が適切な提案をするための大切な情報です。まずは管理表のひな形を埋めるところから始めてみてください。
あわせて読みたい関連記事
