開発が始まってからの仕様変更はどこから追加費用になるのか｜秋稼働の業務システムで議事録と変更管理の線引きを決める

夏に着手して秋に動かす業務システムでは、要件を固めた後も仕様の話が出続けます。そのときに困るのが、「これは最初から入っていたはずですか、それとも追加ですか」という線引きです。ここを曖昧にしたまま進むと、稼働の直前に金額とスケジュールの両方で揉めます。以下は、実際にご相談をいただく場面で繰り返し起きている失敗です。

打ち合わせで決めたつもりの仕様が、議事録では「検討」のままになっていました

議事録が発言の記録になっていて、決定の記録になっていないときに起きます。「〜という意見が出ました」「〜も考えられます」と並んでいるだけの議事録は、読み返しても、どれが決まったことでどれが宿題なのかが分かりません。2か月後に「あのとき決めましたよね」と言い合っても、証拠になる行がありません。

防ぐには、議事録を発言順ではなく「決定」「保留」「変更」の3つに分けて書きます。決定には決めた人と日付を、保留には期限と担当を書きます。次の打ち合わせの冒頭で決定事項だけを読み上げると、認識のずれがその場で見つかります。

【決定】2026-08-20 受注入力の単価は得意先マスタから自動表示します
　決めた人: 営業部長 / 開発PM　影響: 見積もりの範囲内で対応します

【保留】2026-08-20 直送分の送料をどこに持つかは決まっていません
　期限: 2026-08-27まで　担当: 物流課

【変更】2026-08-20 出荷指示書にロット番号を追加したい依頼が出ました
　→ 変更依頼票 CR-004 として起票し、金額と納期は別途回答します

「項目を1つ増やすだけ」の依頼が、帳票と検索と権限にまで届いていました

依頼する側には画面しか見えないので、作業量の差が想像できないために起きます。画面上は1項目でも、実装ではテーブルの定義、入力チェック、一覧の検索条件、印刷する帳票、既存データへの初期値の埋め込み、権限の設定、そしてテストのやり直しまで波及します。「たったこれだけで数十万円ですか」という反応は、この見えなさから生まれます。

防ぐには、見積もりの回答を「項目追加 一式」で出さないことです。どこに何日かかるかを行で分けると、依頼した側も納得しやすくなり、「帳票への反映は稼働後でよい」といった削り方が見つかります。稼働後に回した分がどの費用に含まれるのかは、保守費の対価の範囲とあわせて先に確認しておくと安全です。

あわせて読みたい毎年払っている業務システムの保守費は何の対価なのか｜障害対応・法改正対応・追加改修の線引きを下期の予算前に確認する

現場の担当者が開発者へ直接依頼し、決裁を通らないまま作業が進んでいました

テストの段階に入ると、現場の担当者と開発者がチャットで直接つながります。「ここ、こう直せますか」と言われれば、開発側も善意で応じます。小さな対応が積み上がった結果、月末に「これは追加費用です」と言われて驚くか、開発側が無償で吸収し続けて後半の品質が落ちるか、どちらかになります。

防ぐには、依頼の入口を1つにします。窓口を決めて、そこを通らない依頼には着手しないと双方で合意します。窓口を通した依頼は、金額がゼロでも記録に残します。無償で対応した件数と工数が見えていると、後から「サービスしすぎた」「言えば何でもやってくれる」という誤解が育ちません。

テスト中に出た指摘を、全部「不具合」として無償で直すよう求めてしまいました

受入テストで出る指摘には、3つの種類が混ざります。仕様どおりに動いていないもの、仕様どおりだが使いにくいもの、そもそも決めていなかったものです。これを1枚の一覧に並べると、全部が無償修正の対象に見えてしまいます。

防ぐには、指摘票に「仕様書のどこに反しているか」を書く欄を作ります。この欄が埋まらない指摘は、不具合ではなく変更依頼として扱います。検収の後に出てきた場合の扱いは検収後の不具合が無償で直る範囲で切り分けが変わるため、テスト開始前に確認しておく必要があります。

あわせて読みたい検収したあとに見つかった不具合は無償で直るのか｜秋に稼働する業務システムの受入テストで確かめる範囲と、契約不適合責任の期限

追加費用になる線引きは、着手前に決めて文章にしておきます

線引きは、揉めてから決めると必ず感情の話になります。設計に入る前に、次のような表を1枚作って合意しておきます。

変更の内容	契約の範囲内で直す場合	追加費用になる場合
画面の項目	要件定義書にある項目が実装されていない場合	要件定義書になかった項目を足す場合
帳票のレイアウト	決めた項目が印字されていない場合	承認後にレイアウトを作り直す場合
計算のルール	仕様書の計算式と結果が合わない場合	計算式そのものを変える場合
業務の流れ	承認の順番が仕様どおりに動かない場合	承認の段数を増やす場合
移行するデータ	移行対象と決めた範囲が入っていない場合	対象の期間や項目を後から広げる場合

そのうえで、変更の依頼は口頭やチャットではなく1枚の票に落とします。票には金額だけでなく、納期への影響を必ず書きます。同じ作業でも、設計中なら数日で吸収できるものが、結合テストの開始後には倍近くかかります。秋や翌春の稼働から逆算した日程を横に置いて判断してください。

変更依頼票 CR-004
起票日: 2026-08-25　依頼元: 出荷課
内容: 出荷指示書にロット番号を印字したいという依頼です
理由: 手書きで追記しており、転記ミスが月に数件出ています
影響範囲: 出荷指示テーブル / 印刷レイアウト / 出荷実績の検索条件
見積もり: 3.5人日（回答日 2026-08-28）
納期影響: 結合テストの開始を2日後ろへ動かします
判定: 採用 / 次期へ回す / 見送り  ← 発注側が選んで返します
回答期限: 2026-09-01

えらびの道は、卸売の受発注・請求、出張販売の管理、介護のシフト管理などの業務システムをオーダーメイドで開発しています。小さく作って動かしながら育てる進め方をとっているため、開発の途中で仕様の話が出ることを前提に、決定と保留を分けた記録と、変更依頼ごとの工数の内訳をお出ししています。データの可視化やレポートの自動化、機械学習による予測やリアルタイムなデータ収集基盤まで対応していますが、規模にかかわらず記録の残し方は同じです。すでに他社と進んでいる案件について、線引きの表や依頼票の形を社内で整えたいという段階からのご相談も承っています。

仕様変更と追加費用の線引きを、えらびの道でお手伝いできること

合同会社えらびの道は、中小企業向けのシステム受託開発と、データ活用・DXの支援を行っています。卸売の受発注や請求、介護のシフト管理、出張販売の管理、ECや決済、業務データを集めて予測に使う基盤まで、実際に作って動かしてきました。開発中に出てくる仕様の話をどう扱うかは、案件の現場で毎回向き合っているところです。

議事録と変更管理の形づくりから、御社の案件に合わせてお手伝いします。決定と保留と変更を分けて残す書式、変更依頼票の起票と回答の流れ、受注入力や出荷指示書の項目追加を一式ではなく行で分けて見積もる出し方まで、一緒に整えます。受入テストの指摘票に、仕様書のどこに反しているかを書く欄を設けるところからでも構いません。

進め方は、全部を一度に置き換えません。止まると困る1業務から動かし、残りは様子を見ながら移すので、一度に決める仕様の量が減り、変更の話も小さく収まります。打ち合わせから開発まで同じ人間が担当しますので、何をどの回に決めたかの経緯が消えずに残ります。

お手元の議事録や見積書を見ながら、どこまでが範囲でどこからが追加なのかを整理するところからで構いません。オンラインで30分、費用はかかりません。えらびの道までお気軽にご相談ください。

よくある質問

開発の途中で仕様を変えると、必ず追加費用がかかりますか？

必ずではありません。要件定義書に書かれた内容が実装されていない場合は、契約の範囲内で直します。追加費用になるのは、いったん決めた内容を後から変える場合と、決めていなかった機能を足す場合です。判断の基準は、仕様書に書かれているかどうかになります。

議事録は発注側と開発会社のどちらが書くべきですか？

開発会社が書き、発注側が内容を確認して返す形が実務的です。書いた側は自分の理解を文章として残し、確認した側はそことの食い違いを指摘できます。確認の返事が3営業日以内に来ない場合は合意とみなす、という運用まで決めておくと止まりません。

変更を依頼すると納期はどのくらい延びますか？

作業量よりも、いつ依頼したかで変わります。設計中であれば数日で吸収できる変更も、結合テストの開始後はテストのやり直しが加わり、同じ作業量で倍近くかかることがあります。金額の回答をもらうときは、納期への影響も同じ票の中で確認してください。