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

10月に稼働する業務システムでは、9月に受入テストを置き、検収書に押印してから本番へ進みます。そして稼働から2週間ほど経つと、テストでは出なかった不具合が必ず出てきます。そのとき無償で直るのか追加費用になるのかは、検収より前の段階でほとんど決まっています。現場でよく起きる4つの失敗を挙げます。

毎日動く処理だけを流し、月末の締めを通さないまま検収しました

受入テストは稼働直前に置かれるため、確保できる期間は1〜2週間ほどです。その中で自然に発生するのは、受注入力や出荷指示のような毎日動く処理に偏ります。月末の締め、請求書の発行、返品や値引きの処理は、テスト期間中にたまたま発生しなければ一度も流れません。

不具合は、件数の多い処理よりも条件が重なる処理で出ます。防ぐには、テスト期間に自然発生しない処理を先に書き出し、データを手で作って流します。

受入テストで、手で作って流す処理
□ 月末締めから請求書の発行まで
□ 返品・値引き・赤伝の入力
□ 取引先の締め日が月中で変わったときの再計算
□ 前月分の伝票を当月に修正したときの数字
□ 年1回しか動かない処理（決算・年度更新・料率の改定）

テスト期間そのものが足りないと感じたら、稼働日から逆算した工程の組み方を先に見直したほうが早く済みます。

あわせて読みたい来年4月稼働の業務システムが8月着手でギリギリな理由｜要件・期間・法改正の整理

検収書に日付だけを書き、何を確かめたのかを残しませんでした

検収書が「納品物を受領しました」の一行だけで終わっている例は珍しくありません。この状態だと、稼働後に不具合が出たときに「テストで確認済みのはずでは」という話になり、確認していない証拠を注文者側が出せなくなります。

防ぎ方は単純で、テスト項目とその結果を一覧にして検収書に添えます。未実施の項目は空欄にせず「未実施」と書いて残します。不具合の報告も、口頭やメール本文ではなく形式をそろえます。

不具合の報告に必ず書く6項目
1. 発生した日時と操作した画面
2. 入力したデータ（実データの伝票番号）
3. 期待した結果
4. 実際に出た結果
5. 根拠（仕様書のページ番号、または合意した議事録の日付）
6. 同じ手順で再現するかどうか

「不具合」なのか「言っていなかった仕様」なのかで揉めました

無償で直る範囲は、感覚ではなく仕様書の記載で決まります。仕様書に書いてあるとおりに動かなければ契約不適合であり、仕様書にない動きを新たに求めるなら追加開発です。口頭や打ち合わせの場だけで伝えた要望は、議事録に残っていなければ後から根拠になりません。

確認する項目	無償で直る場合	有償になる場合
請求金額	仕様書の計算式どおりに計算していない場合	仕様書にない取引先別の掛率を足す場合
帳票の項目	合意したレイアウトと項目が違う場合	稼働後に必要だと気づいた項目を加える場合
画面のエラー	通常の入力値で処理が止まる場合	想定外の桁数を新たに受け付けさせる場合
処理の速さ	契約書に応答時間の定めがあり超えている場合	応答時間の取り決めがない場合

稼働から数か月が過ぎると、この線引きは保守契約の範囲の話に移ります。どこまでが保守費に含まれるのかも、同じ時期に読み合わせておくと後で困りません。

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

契約書の期限が6か月で切れ、年1回の処理が期限の外に出ました

民法（e-Gov法令検索）の第637条では、請負の目的物に契約不適合があった場合、注文者がそれを知った時から1年以内に通知しなければ、修補や損害賠償を求められなくなると定められています。ただしこの規定は任意規定で、契約書に別の定めがあればそちらが優先します。実際の開発契約では「検収後6か月」のように短く書かれていることがよくあります。

10月稼働で6か月なら、期限は翌年3月末です。決算処理や年度更新のように年1回しか動かない機能は、期限の直前かその外側で初めて実行されます。契約書の該当条項を稼働前に読み、年次処理が期限内に収まるかを確認してください。収まらないなら、その機能だけ期間を延ばすか、テスト時に前倒しで流します。契約書と成果物の所在を確認する視点も、この段階で一緒に見ておくと無駄がありません。

えらびの道は、卸売の受発注・請求や介護のシフト管理などの業務システムをオーダーメイドで開発しています。開発時には、テスト項目と結果を一覧で残し、月末締めや年次処理を含めた受入テストの計画をご一緒に作ります。データの可視化やレポートの自動化まで含めて、小さく作って動かしながら育てる進め方をとっているため、稼働後に見つかった不足も切り分けたうえで対応します。既存システムの検収前に、何を確かめておくべきかの整理だけでもご相談いただけます。

受入テストから検収までを、えらびの道でお手伝いできること

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

受入テストの項目づくりから、御社の業務に合わせてお手伝いします。月末の締めから請求書の発行まで、返品や値引き、赤伝の入力といった、テスト期間中に自然発生しない処理を洗い出し、データを手で作って流す手順を一緒に組み立てます。検収書に添えるテスト結果の一覧や、不具合報告の形式づくりもご相談いただけます。

進め方は、全部を一度に置き換えません。止まると困る1業務から動かし、残りは様子を見ながら移すので、受入テストで確かめる範囲も一度に膨らみません。打ち合わせから開発まで同じ人間が担当しますので、仕様書に何を書いたかの経緯が消えずに残ります。

お手元の仕様書や契約書を見ながら、確かめておく処理と、契約不適合責任の期限が業務に合っているかを整理するところからで構いません。オンラインで30分、費用はかかりません。えらびの道までお気軽にご相談ください。

よくある質問

検収書に押印したあとでも、不具合は無償で直してもらえますか？

仕様書どおりに動かないものであれば、検収後でも契約不適合として無償の修補を求められます。押印は不具合の免責ではありません。ただし通知の期限があるため、見つけた時点で記録に残る形で開発会社へ伝えてください。

受入テストはどのくらいの期間を見ておけばよいですか？

期間の長さよりも、締め処理を1回通せるかどうかで考えてください。月末締めから請求書の発行までを実データで流すなら、最低でも1か月分の日程が必要です。年次処理はデータを手で作り、テスト中に前倒しで流します。

契約不適合責任の期限は契約書で短くできますか？

短くできます。民法の1年という定めは任意規定のため、契約書に「検収後6か月」などと書かれていればそちらが優先します。契約前に条項を確認し、年1回しか動かない機能が期限内に実行されるかを見てください。