この記事の要約
開発途中の追加要望を、不具合・仕様変更・追加開発の違いから整理。Ouverの実例とともに、発注側が費用・納期・対応範囲を確認する5つの手順、変更依頼の書き方、よくある質問を紹介します。
開発中の画面を見て、『この項目も欲しい』『思っていた動きと違う』と気づくことはあります。そのときは、合意した内容との違いと、変更による影響を整理してから対応を決めましょう。気になる点をすべて不具合として扱ったり、その場で追加を頼んだりすると、費用や納期の認識がずれやすくなります。
この記事では、発注側が開発会社と話すときの切り分け方と、変更を判断する手順を紹介します。
1 不具合か追加要望かは合意した内容と照らして考える
不具合の切り分けでは、まず『決めた条件で、期待する結果になるか』を確認します。例えば『承認前の申請は本人が取り消せる』と合意しているのに取り消せなければ、不具合の可能性があります。原因は調査して確かめます。
仕様変更は、決めた動きや条件を変えることです。『承認後も取り消せるようにする』なら、当初の範囲との差分を確認します。追加開発は、新しい機能などを作る作業を指し、仕様変更に伴って必要になる場合もあります。三つが必ず別々に分類できるわけではありません。これらの申請例は、説明用の仮の例です。
まだ実装していない機能や、仕様の解釈がそろっていない点もあります。判断できないものは『要確認』として残し、仕様書、画面案、議事録、承認済みの変更内容を見比べます。記載が見つからないという理由だけで、直ちに追加費用が必要と結論づけないことも大切です。
2 Ouverの保守引き継ぎ事例 不具合修正とデザイン刷新
Ouverが保守を引き継いだマーケティング計測SaaSでは、購入などの成果が正しく計測されない問題がありました。成果は料金請求の根拠になるため、原因を調べて修正し、正しく数えられることを確認しました。同じ案件では、見た目を改善したいという要望を受けてデザインも刷新しています。
これは開発後の保守・改修事例ですが、『本来の動きを回復する対応』と『新たな希望を反映する対応』を分けて考える参考になります。ただし、不具合修正か改善要望かという分類だけで、有償・無償が決まるわけではありません。費用負担は合意した範囲や契約条件と照らして確認します。公開事例の詳しい経緯は、次の記事で紹介しています。
事例他社開発システムの保守引き継ぎ事例｜成果計測の不具合修正とデザイン刷新
また、厚生労働省が紹介する三菱ケミカルシステム株式会社の取組では、合意した範囲の外にある変更について見積もりを見直しています。変更を受けるかだけでなく、何を基準に判断するかを共有することが重要です。厚生労働省「問題解決の勘所7」
3 Ouverでは対応範囲と影響を確認して進めます
Ouverは開発中の進捗を共有し、確認事項や新しい要望が出たときは、対応範囲と進め方を相談します。費用や日程に影響する変更は、前提を確かめて判断します。確認の時期や方法は、案件の規模や進め方に合わせます。全体の工程はシステム開発の流れで紹介しています。
4 追加要望を判断する五つの手順
手順1 変えたい理由と困る場面を伝える
『一覧に列を追加したい』だけでなく、『締め日に担当者別の未処理件数を確認したい』と、目的を伝えます。要望した形以外にも、既存の検索や帳票で対応できるかもしれません。誰が、いつ、どのくらい困るのかを添えると、優先順位を決めやすくなります。
手順2 当初の範囲との差分をそろえる
現在の仕様、期待する状態、変えたい箇所を並べます。開発途中のデモなら、その時点で完成している機能も確認しましょう。不具合と思われる点は、再現手順、期待した結果、実際の結果を記録します。分類の結論が出ていなくても、事実の共有は先に進められます。
複数の部署から要望が出る場合は、窓口でまとめ、同じ目的の依頼を整理します。『必須』『できれば』という言葉だけでなく、対応しない場合に止まる仕事や、当面の代替手段を書き添えましょう。関係者の声の大きさだけで順番が決まるのを避けられます。
手順3 費用と納期以外の影響も聞く
画面の変更だけで済むか、データ、権限、外部連携、既存のテストにも手を入れるかを確認します。見積もりには調査・修正・再テストの範囲、前提、未確定事項を示してもらいましょう。発注側が追加で準備するデータや、確認に必要な日数も日程に含めます。発注前に見積もりを比較するときの確認点は、次の記事を参考にしてください。
コラムシステム開発の見積もりの見方：見積書で確かめる項目と、2社以上を比べるときのそろえ方
手順4 今回対応するかを責任者が決める
業務が止まる問題と、あると便利な改善では優先度が違います。今回実施する、別の機能と入れ替える、次回に回すなどの案を比べます。ただし、入れ替えれば必ず費用が増えないとは限りません。すでに終えた作業や再設計への影響も確認し、予算と期限を判断できる人が承認します。
手順5 決定と確認方法を記録する
変更内容、対応範囲、金額、日程、承認者、完了の確認方法を残します。更新した仕様に版や日付を付けると、どの内容が最新か分かります。口頭で相談した段階と、着手を承認した段階も区別しましょう。変更後は対象の動作を確かめ、関連する操作に影響がないか開発会社と確認します。
保留にした要望にも、理由と次に見直す時期を残します。対応しないと決めたのか、調査待ちなのかを区別しておけば、同じ相談を繰り返さずに済みます。
5 相談時に使える変更依頼の書き方
変更依頼は、一件ごとに次の内容をそろえると話し合いやすくなります。
- 対象の画面や業務、現在の動き、希望する状態
- 変更したい理由、業務への影響、希望時期とその理由
- 関連する仕様や議事録、確認・承認する担当者
発注側で技術的な原因や実装方法まで決める必要はありません。説明用の画面を添える場合は、個人情報や機密情報を伏せ、共有する相手に必要な範囲にとどめます。
説明用の仮の記入例：現状は「未処理件数を手で数える」、希望は「担当者別に一覧で確認」、理由は「締め日の確認を減らす」。次の締め日前を希望し、影響を確かめたうえで責任者が対応を判断します。
追加要望の整理から相談したい方へ
『修正なのか追加なのか整理できない』『納期を守るために何を優先すべきか迷う』ときは、現在の状況と困っている点をお聞かせください。初回相談は無料です。詳しい調査が必要な場合は、範囲と費用を確認してから進めます。
出典確認日：2026年11月6日。事例と説明用の仮の例を区別して記載しています。
よくある質問
不具合の修正は必ず無料ですか？
一律には判断できません。原因、合意した仕様、契約の対象や期間などを確認します。『不具合』という呼び方だけで費用負担を決めないようにしましょう。
仕様書にない要望はすべて追加開発ですか？
そうとは限りません。他の資料や合意の経緯も確認し、記載漏れか、新しい要望か、認識の違いかを整理します。
小さな画面変更でも見積もりは必要ですか？
まず影響を確認します。表示上は小さくても、データ処理やテストに広く関係する場合があります。費用が発生する条件も合わせて確認してください。
急ぎの変更は先に作業を頼んでよいですか？
緊急性を伝えたうえで、調査と修正の範囲、承認者、費用の扱いを先にそろえます。確定できない場合も、どこまで着手してよいか記録します。
アジャイル開発なら何度でも変更できますか？
変更を織り込む進め方でも、予算や作業量の制約はあります。優先順位と今回の対象を調整し、契約に沿って判断します。
