「画面は出るがエラーで処理が完了しない」「動くが処理に30秒かかり業務に使えない」「動くがブラウザによっては表示が崩れる」——システム開発の検収段階では「動く・動かない」の判定で双方が対立するトラブルが頻発します。本記事では検収トラブルの典型5例を整理し、「動く」の定義を業務シナリオ・性能・データの3軸で書く方法、揉めた時の対処手順を経営者目線で解説します。
この記事の結論（3行）
- 「動く・動かない」の判定トラブルは、検収条件を「機能の動作」だけで書いている契約で多発する
- 検収条件は「業務シナリオ完遂」「性能基準」「データ品質」の3軸で定義すると判定が明確になる
- 検収拒否・支払い停止の前に「不適合項目のリスト化と修正計画の合意」を1段挟むと和解しやすい
なぜシステム開発の検収で「動く・動かない」が揉めるのか
検収段階でトラブルが起きる根本原因は、契約書に書かれた「動作」の定義と、業務側が想定する「動く」の意味が一致していないことです。判定が揉める背景は3つあります。
- 検収条件が「機能の動作確認」だけで書かれている
- 性能基準が定義されていない
- 既存データを使った検証が行われていない
この3つを契約段階で押さえておけば、検収判定の大半は明確化できます。逆に押さえずに進むと、リリース直前の段階で「動く・動かない」の解釈論争に1〜3か月を費やすことになります。
検収条件が「機能の動作確認」だけ
「画面が表示されること」「ボタンを押すと処理が完了すること」のように機能単位での確認条件が書かれていても、業務シナリオ全体が完遂できるかは分かりません。受注画面でデータを入れた後、在庫引当→出荷指示→請求書発行という業務シナリオを通して動かないと、業務側は「動かない」と判定します。
性能基準が定義されていない
処理にかかる時間（レスポンスタイム）、同時アクセスできるユーザー数、データ量上限などが契約書に書かれていないと、ベンダーは「機能は動作する」と主張でき、発注者は「業務で使えない」と主張する構図になります。性能基準は「主要画面は3秒以内に表示」「100名同時接続で性能劣化なし」のような数値で明文化が必要です。
既存データを使った検証が行われていない
ベンダー側のテストでは、テスト用に作った小規模なダミーデータで動作確認することが多いです。発注者の実データ（数年分の取引履歴、特殊な業種コードなど）を入れた瞬間に動かなくなるケースが珍しくありません。検収時に既存データを使った検証を必須にしておく必要があります。
検収トラブルの典型5例
実際に起きた検収トラブルの典型5例を整理します。
| 事例 | 発生原因 | 双方の主張 | 一般的な解決方法 | |---|---|---|---| | シナリオ完遂不可 | 機能間連携の動作不良 | 発注者「業務にならない」vs ベンダー「機能は動く」 | 業務シナリオ定義の再整理 | | 性能不足 | 処理速度・同時接続数の不足 | 発注者「業務速度に追いつかない」vs ベンダー「動作はする」 | 性能基準の追加合意と改修 | | データ不整合 | 既存データ移行後の動作不良 | 発注者「既存データで動かない」vs ベンダー「テストデータでは動く」 | データ修正と動作検証 | | ブラウザ互換 | 特定環境での表示崩れ | 発注者「業務PCで使えない」vs ベンダー「主要ブラウザは対応済み」 | 対応環境の追加合意 | | 帳票ズレ | 印刷時のレイアウト崩れ | 発注者「請求書として使えない」vs ベンダー「画面表示は正しい」 | 帳票仕様の再合意 |
5事例とも、契約書の検収条件に該当項目を入れておけば防げた論点ばかりです。発注前に検収条件の項目を整理したい経営者の方は、業務改善・システム見積もりAI適正診断で点検項目から始める流れがお勧めです。
事例1：シナリオ完遂不可
機能単位では動作するものの、業務シナリオを通すと途中でエラーが出る・処理が完了しないケースです。受注→在庫引当→出荷→請求の連携処理でデータが正しく流れない、複数画面を横断する処理で整合性が崩れるなど、機能間の連携不備で発生します。
事例2：性能不足
機能は動作するものの、処理速度が業務に耐えないケースです。「検索に20秒かかる」「データ表示に30秒かかる」「複数人同時アクセスで応答しなくなる」など、性能基準が契約書に無いと、ベンダー側に改修義務を負わせるのが難しくなります。
事例3：データ不整合
既存システムからデータ移行した瞬間に動作不良が出るケースです。文字コードの違い、特殊文字の扱い、日付フォーマットの差異、外部キー制約の不整合など、テスト用ダミーデータでは出ない問題がリアルデータでは多発します。
事例4：ブラウザ互換
業務PCで使っているブラウザ（古いバージョンのChrome、社内標準のEdgeなど）で表示崩れが発生するケースです。契約書で「主要ブラウザ対応」とだけ書かれていると、対応範囲を巡って解釈論争になります。
事例5：帳票ズレ
画面では正しく表示されるものの、印刷時のレイアウトが崩れて請求書・納品書として使えないケースです。フォントサイズ、行間隔、印刷余白の調整不足で発生します。実際の業務で印刷する用紙（A4・A5・伝票専用紙など）での確認が必須です。さらに帳票は取引先へ渡す書類でもあるため、レイアウトの精度を巡る要求が他の機能よりシビアになる傾向があります。検収段階で帳票専用の確認工程を組み込んでおくことが重要です。
なお5事例とも、検収段階で初めて発覚するのではなく、開発の中盤以降に動作する画面が出始めた時点で順次確認していけば、検収段階での対立を防げます。中間レビューを「動く画面で確認」する習慣が、検収トラブルの最大の予防策になります。
検収条件を3軸で定義する方法
「動く・動かない」の判定を明確化するには、検収条件を3軸で定義します。
軸1：業務シナリオ完遂
「機能の動作」ではなく「業務シナリオを通せること」を検収条件に書きます。具体的には、業務で使う典型シナリオを5〜10件選び、各シナリオの開始から終了までの操作手順をリスト化します。検収時は各シナリオを実際に通して、全て完遂できることを確認します。シナリオベースの検収は、機能間連携の問題を早期に発見できます。
軸2：性能基準
レスポンスタイム・同時接続数・データ量上限の3点を数値で明記します。例えば「主要画面のレスポンスタイムは3秒以内」「同時接続50ユーザーで性能劣化なし」「データ件数10万件で動作確認済み」のような形です。性能基準は業務側の実態を踏まえた数値設定が必要で、過剰な基準を設定すると見積もりが膨らみます。
軸3：データ品質
既存データを使った検証を検収条件に含めます。「過去3年分の実データを移行した状態で、主要シナリオが完遂可能」のような書き方です。データ移行時の文字化け・欠損・型エラーが発生していないこと、検索結果が想定通りに返ること、集計値が既存システムと一致することを確認します。検収条件を3軸で項目別に整理してから契約に進む流れをお勧めします。
3軸での定義を契約書に盛り込むだけで、検収段階での解釈論争は大きく減ります。発注金額にして数十万円規模の追加工数がかかる場合もありますが、検収トラブル発生時の損失と比較すれば、十分に元が取れる投資です。
検収拒否・支払い停止の前に取るべき手順
検収段階で「動かない」と判定したくなった時、いきなり検収拒否や支払い停止に進むのではなく、1段挟む手順をお勧めします。3ステップで進めます。
ステップ1：不適合項目をリスト化する
「動かない」を抽象的に主張するのではなく、不適合項目を1件ずつリスト化してください。各項目について「期待動作」「実際の動作」「再現手順」「業務影響」を明記します。リスト化された項目があれば、ベンダー側も対応範囲を判断できます。「全体的に動かない」という主張では、ベンダーは対応着手すらできません。
ステップ2：修正計画の合意
リストを元にベンダーと協議し、修正対象・修正期限・修正後の再検収方法を合意してください。修正不可項目がある場合は、その項目を契約範囲から外す代わりに対価の減額交渉に進みます。この段階での合意があれば、訴訟リスクが大きく下がります。
ステップ3：再検収と段階的支払い
修正完了後に再検収を実施し、合意した項目が全て解消されていれば検収完了とします。残金支払いは、再検収完了後に行う形が一般的です。再検収でも残課題が出る場合は、ステップ1から繰り返します。検収プロセス全体を診断する流れで点検しておくと、各段階の判断材料が揃いやすくなります。
経営者目線で考える「検収段階で経営者が出る場面」
ここからは経営の話です。検収段階のトラブルは、現場担当者だけでは解決が難しい局面が多くあります。経営者が出るべき場面は3つです。
第一に、不適合項目のリスト化を現場担当者が完成させた段階です。リストを元に「これは契約範囲内・範囲外・修正可能・修正不可」の判断を経営者が確認することで、現場担当者の判断にお墨付きを与えられます。現場担当者だけで判断させると、ベンダーとの関係性に配慮して甘い判定になりがちです。
第二に、ベンダー側との交渉が膠着した段階です。現場同士の交渉で進まない場合、経営者同士の対話で局面が動くことがあります。「経営者から経営者へ」のメッセージが、ベンダー側の本社判断を引き出すきっかけになることがあります。
第三に、支払い停止・契約解除を判断する段階です。これらは経営判断であり、現場担当者では決定できません。経営者が「続行・修正・解除」の判断を明確に下すことで、現場が次のアクションに動けます。判断を保留し続けると、現場が疲弊し、最終的に組織全体の判断力が落ちていきます。経営者が判断を下す際は、現場担当者から上がってきた不適合項目リストと、ベンダー側の修正提案を並べて比較することが基本です。リストが整理されていない段階で経営判断を求められても、的確な判断は難しいので、現場が前提資料を揃える時間を確保してください。
ぷらすわん実例：ある製造業A社の検収再合意
ぷらすわんが相談を受けたある製造業A社の事例をお伝えします。A社は受発注システムの検収段階で、ベンダーとの間で「動く・動かない」の対立が3か月続いていました。ベンダー側は「契約書記載の機能は全て実装済み」として残金400万円を請求し、A社側は「業務で使えない」として検収拒否・支払い停止を続けていました。
ぷらすわんが第三者として入り、3ステップで整理しました。第一に、不適合項目を業務シナリオベースでリスト化しました。結果として「シナリオ完遂不可が3件、性能不足が2件、データ不整合が4件」の計9件が明確化されました。第二に、9件のうち6件はベンダー側の無償修正対応、3件は仕様変更扱いで追加100万円で合意しました。第三に、修正完了後の再検収を1か月後に実施する計画を双方で合意しました。
結果として、追加100万円・2か月で検収完了し、A社は受発注システムを業務で使える状態で運用開始しました。訴訟に進んでいた場合、弁護士費用・時間的コストで合計500万円以上の負担が見込まれていた状況で、最小コストで着地できました。検収トラブルが見えてきた段階で、比較を依頼する流れで第三者の視点を入れると、和解の選択肢が広がります。
まとめ
システム開発の検収段階で起きる「動く・動かない」の判定トラブルは、契約書の検収条件を「機能の動作」だけで書いていると多発します。検収条件は「業務シナリオ完遂」「性能基準」「データ品質」の3軸で定義することで、判定が明確化できます。シナリオ完遂不可・性能不足・データ不整合・ブラウザ互換・帳票ズレの5つの典型事例は、いずれも3軸の定義で防げる論点です。
既にトラブルが起きている場合は、検収拒否・支払い停止の前に「不適合項目のリスト化と修正計画の合意」を1段挟んでください。この1段があるかどうかで、訴訟リスクと和解可能性は大きく変わります。検収段階は経営者の判断が直接効く局面でもあり、経営者が早い段階で関与する姿勢が、最終的な損失を抑える鍵になります。検収トラブルは発注プロセス全体の最終段階で表面化する問題なので、ここでの判断と動き方が次回の発注精度にも直結する論点です。