検収で見るべきポイントと不具合対応の依頼方法

検収の日程が近づいてきた。仕様書と首っ引きで機能を一通り確認し、大きな問題はなさそうだ。ただ、いくつか気になる点が見つかった。ボタンを押すと画面がわずかに固まる、入力した金額が一覧画面では違う桁で表示される、特定の条件で一覧の並び順がおかしい。これらは「不合格にするほどの不具合」なのか、「指摘だけして合格にする」ものなのか。そして、これを開発会社にどう伝えれば、きちんと直してもらえるのか。ひとりで情シスや総務のIT担当を兼任していると、こうした判断を相談できる相手が社内にいないまま、検収期限だけが迫ってくることが少なくありません。

結論から言うと、検収の実務でつまずくポイントは大きく2つに集約されます。ひとつは「何を、どの粒度で確認すれば見落としを防げるか」という当日のチェックの具体性、もうひとつは「見つけた不具合を、開発会社が優先順位をつけて動けるようにどう書くか」という報告の技術です。検収という手続きそのものの法的な位置づけや、契約不適合責任といった制度面の話は、検収の基本を整理した別記事で解説しています。この記事では、その基本を踏まえたうえで、「実際に検収の場で何を見るか」「不具合をどう書けば開発会社に正しく伝わるか」という、より現場寄りの実務に絞って解説します。

この記事で分かること

検収の当日から、不具合を見つけた後の報告・追跡までを、実務の流れに沿って解説します。

• 検収の場で確認すべき、画面単位・データ単位の具体的なチェックポイント
• 見落としがちな「地味だが業務に影響する」確認項目
• 不具合を開発会社に伝えるときに、再現性のある報告文を書くための型
• 「不具合」と「認識のズレ（仕様の解釈違い）」を切り分ける考え方
• 開発会社から返ってきた回答への向き合い方と、優先順位のつけ方
• 修正後の再確認（再検収）で気をつけること

順番に見ていきましょう。

検収の実務チェックポイント:5つの視点で見る

検収で何を確認すべきかを考えるとき、「機能が動くかどうか」だけを見ていると、実際の運用で困る不具合を見逃しやすくなります。ここでは、実務でよく問題になる5つの視点に分けて整理します。

表示・入力まわりのチェックポイント

もっとも見つけやすく、同時にもっとも数が多くなりがちなのが、画面の表示・入力に関する不具合です。

• 一覧画面と詳細画面で、同じ項目の表示形式（桁区切り、小数点、日付の形式など）が揃っているか
• 必須項目を空欄のまま登録しようとしたとき、分かりやすいエラーメッセージが出るか（「エラーが発生しました」のような曖昧な表示になっていないか）
• 入力した文字数が多い場合に、画面のレイアウトが崩れないか（会社名や住所など、長くなりがちな項目で特に起きやすい）
• ボタンを連続で複数回クリックしたときに、データが二重に登録されないか
• ブラウザの「戻る」ボタンを使った場合の挙動が、業務上問題ないか

これらは一見すると些細に見えますが、実際に日常業務で毎日触れる画面であるほど、小さな使いにくさの積み重ねが現場のストレスや入力ミスにつながります。仕様書に明記されていない部分も多いため、「動くかどうか」だけでなく「使ってみてどう感じるか」を意識して確認することが重要です。

データの整合性:入力した値がどこまで正しく伝わるか

機能テストで個々の画面が単体で動いていても、データが複数の画面・帳票をまたいで扱われる場面で不整合が起きることがあります。

• ある画面で入力・修正したデータが、関連する他の画面（一覧、詳細、集計画面など）にも正しく反映されているか
• 帳票（請求書、納品書など）に出力した際、画面上の数値と一致しているか
• データを削除・無効化した場合、関連するデータ（履歴、集計値など）の扱いが仕様通りか
• CSVなどでデータをインポート・エクスポートする機能がある場合、CSVの文字コードや改行コードが原因で文字化けが起きないか

とくに、既存システムからのデータ移行を伴う開発では、移行後のデータに欠落や誤変換がないかを、件数の一致だけでなく、いくつかのレコードを抽出して内容まで突き合わせる形で確認することをおすすめします。件数が合っていても、個々のデータの中身が壊れているケースは珍しくありません。

権限・アクセス制御:役割ごとの見える範囲を確認する

複数の役割（一般社員、管理者、経理担当など）が使うシステムでは、権限設定の不具合が見過ごされやすい領域です。

• 一般権限のアカウントでログインした場合、管理者専用の機能や画面にアクセスできてしまわないか
• 自分が担当していないデータ（他部署の情報など）が、権限のないアカウントから閲覧・編集できてしまわないか
• URLを直接入力した場合に、権限チェックを迂回してアクセスできてしまわないか
• 退職者・異動者のアカウントを無効化した際、想定通りにログインできなくなるか

権限まわりの不具合は、通常の操作フローでは気づきにくく、かつ発覚したときの影響（情報漏えいなど）が大きいという特徴があります。複数の権限パターンを想定しているシステムであれば、それぞれの権限のアカウントを実際に用意して、一つずつログインしながら確認する時間を検収期間の中に確保しておくことが望ましい進め方です。

異常系・境界値:わざと「困らせる」操作をしてみる

正常な操作だけを確認して「問題なし」と判断すると、実際の運用で想定外の操作をしたときに不具合が表面化することがあります。

• 数値項目に、極端に大きい値・小さい値（マイナス値、0、桁数の上限を超える値）を入力したらどうなるか
• 必須ではない項目をすべて空欄にしたまま登録できるか、その場合の表示は正しいか
• 同じ内容を素早く連続して登録・更新した場合に、データが重複しないか
• 通信が不安定な状況（Wi-Fiを一時的に切るなど）で操作した場合、データが中途半端な状態で保存されてしまわないか

こうした「わざと困らせる」操作は、仕様書に明記されていないことが多いため、確認するかどうかは発注者側の意識に委ねられます。すべてを網羅する必要はありませんが、業務上とくに重要なデータ（金額、在庫数など）を扱う画面だけでも、境界値の確認を優先的に行っておくと安心です。

運用シナリオ:月末・期末にしか動かない処理を忘れない

検収のタイミングが月の途中であることが多いため、月末・期末・年度末にしか動作しない処理は、検収の場で確認し忘れやすい項目です。

• 締め処理、月次集計、年次更新などの処理は、実際に日付を変更したテスト環境で動作確認できるか（開発会社にテスト用の環境や手順を確認する）
• 締め処理の後、データの修正ができなくなる（ロックされる）仕様であれば、その挙動が意図通りか
• 祝日・年末年始などの特殊な営業日設定が絡む処理がある場合、正しく機能するか

これらの処理は、本番運用が始まってから初めて動くまで気づかれないことが多く、いざ月末になって初めて不具合が発覚すると、業務への影響が大きくなりがちです。検収の段階で、開発会社にテスト環境での日付変更確認ができないか、あらかじめ相談しておくことをおすすめします。

検収期間の途中で「これは確認できていない」と気づいた項目があれば、抱え込まずに早めに開発会社へ相談することが大切です。テスト用の環境や日付変更の手順を用意してもらえれば、本来は月末まで確認できない処理も、検収期間の中で確認できる場合があります。

不具合報告の書き方:再現性のある報告文の型

検収の場で不具合を見つけたら、次に重要になるのが「どう伝えるか」です。同じ不具合であっても、報告の書き方次第で、開発会社側の対応スピードや精度は大きく変わります。ここでは、実務でよく使われる報告文の型を紹介します。

不具合報告に最低限含めたい要素は、次の5つです。

1. 発生日時: いつ気づいたか
2. 操作手順: どの画面で、どのような操作をしたか（再現手順）
3. 期待していた結果: 本来どうなるはずだったか（仕様書の該当箇所があれば併記）
4. 実際に起きた結果: 実際には何が表示・発生したか
5. 影響範囲・重要度: 業務にどの程度の影響があるか、自分なりの見立て

これらを箇条書きで整理するだけでも、口頭やチャットの一言で「なんか変です」と伝えるより、格段に伝わりやすい報告になります。

悪い報告例と良い報告例を比べる

具体的な違いを見てみましょう。

悪い報告例

見積書の画面がおかしいです。金額が合っていない気がします。確認お願いします。

この報告文には、どの画面で、どんな操作をしたときに、何と何を比較して「合っていない」と判断したのかが書かれていません。開発会社側は、まず「どの見積書のことか」「何と何を比較したのか」を確認するところから始めなければならず、それだけで数往復のやり取りが発生してしまいます。

良い報告例

発生日時: 2026年8月12日 14:30頃

操作手順: 見積書一覧画面から「見積No.1023」を開き、PDF出力ボタンを押下

期待していた結果: 一覧画面に表示されている合計金額（税込110,000円）と同じ金額がPDFに表示される

実際の結果: PDFに表示された合計金額が108,000円になっており、一覧画面の表示と一致しない

影響範囲: この見積書をもとにお客様へ請求する予定のため、金額の相違は早急に確認が必要

このように具体的な手順と数値を示すことで、開発会社側は同じ操作を再現しながら原因を調査でき、やり取りの往復が大幅に減ります。とくに「期待していた結果」を明記することは重要です。開発会社側が「これは仕様通りの動作です」と回答してきた場合でも、発注者側が何を根拠に「期待」していたかが分かれば、それが仕様書の記載に基づく主張なのか、単なる思い込みだったのかを、双方ですぐに確認できます。

再現手順が書けない不具合への対処

一度しか発生しておらず、再現手順がはっきりしない不具合に遭遇することもあります。この場合は、無理に手順を作文せず、次のような情報だけでも書き残しておくことをおすすめします。

• 発生した日時と、その前後に行っていた操作（覚えている範囲で）
• 表示されたエラーメッセージがあれば、画面のスクリーンショット
• 使用していたブラウザ・端末の種類
• 同じ操作を後から試して、再現するかどうかの結果（再現しなかった場合もその旨を伝える）

再現しない不具合は開発会社側でも原因の特定が難しく、対応の優先順位が下がりがちです。ただし、記録を残しておくことで、後日同じ不具合が別の場面で再発した際に、「以前にも似た事象があった」という手がかりになります。一度きりだからと報告せずに流してしまうと、この手がかりが失われてしまう点に注意してください。

報告手段はメール・チャット・課題管理ツールのどれがよいか

不具合報告をどの手段で行うかによっても、記録の残りやすさや対応のスピードが変わります。開発会社によって使用しているツールは異なりますが、一般的な特徴を整理しておきます。

課題管理ツールが使われているプロジェクトであれば、不具合ごとにチケットを起票し、ステータスを追う形が最も抜け漏れを防ぎやすい方法です。一方、チャットでの気軽なやり取りが中心のプロジェクトでは、指摘した不具合の一覧を自分側でも別途スプレッドシートなどにまとめておき、対応状況を発注者側で追跡できるようにしておくことをおすすめします。開発会社の管理に完全に依存してしまうと、「言ったはずの指摘が、いつの間にか宙に浮いていた」という事態が起きやすくなります。

• 検収期間の開始時点で、不具合報告にどの手段を使うかを開発会社とあらかじめ合意しておく
• チャットで報告した場合でも、指摘事項の一覧は自社側でも別途記録しておく
• 「対応済み」という報告を受けたら、実際に自分でも動作を確認してからチェックを付ける（開発会社側の「対応済み」の報告だけを信用して確認を省略しない）

複数人で検収する場合の役割分担と情報共有

検収を情シス担当者ひとりだけで抱え込まず、現場の利用予定者や他部署の担当者にも協力を仰ぐ場合、役割分担と情報共有の仕組みを事前に決めておくと、確認の抜け漏れや報告の重複を防げます。

• 担当領域を分ける: 「経理担当者は請求書まわりの画面を、営業担当者は顧客管理の画面を確認する」のように、業務知識が必要な領域は、その業務に詳しい担当者に確認を割り振ります
• 報告の窓口を一本化する: 複数人がそれぞれ個別に開発会社へ不具合を報告すると、開発会社側でも整理がつかなくなります。情シス担当者が窓口となり、各担当者から上がってきた指摘を取りまとめてから開発会社に報告する体制が望ましい進め方です
• 共有の粒度をそろえる: 「なんとなく使いにくい」という感想と、「この操作をするとエラーが出る」という具体的な不具合報告が混在すると、開発会社への報告時に整理し直す手間が増えます。協力を依頼する際に、前述した5要素（発生日時・操作手順・期待結果・実際の結果・影響範囲）のフォーマットをあらかじめ共有しておくと、集約作業が楽になります

複数人での検収は、確認の網羅性が上がる一方で、情報が分散しやすいという弱点もあります。簡単なテンプレート（表計算ソフトのシートなど）を用意し、「誰が」「いつ」「何を確認して」「どんな結果だったか」を1つの場所に集約する仕組みを、検収を始める前に作っておくことをおすすめします。この仕組みがあれば、検収後に経営層へ結果を報告する際にも、そのまま資料として使い回せます。

「不具合」と「認識のズレ」を切り分ける

不具合報告でしばしば起きるのが、発注者側が「不具合」だと思っていたものが、実は「仕様書に記載のない、期待と異なる動き」だったというケースです。この2つは対応の性質がまったく異なるため、報告する前に切り分けておくことをおすすめします。

見分け方としては、まず仕様書・要件定義書・過去のやり取り（メールや議事録）の中に、期待していた動作についての記載がないかを確認します。記載があれば「不具合」として報告し、記載がなければ「これは今回の仕様に含まれていましたか」という確認から入るのが実務上の進め方です。

• 報告する前に、仕様書の該当箇所を自分でも探しておく（見つかれば報告文に該当ページ・条文番号を添える）
• 記載が見つからない場合は、「不具合の指摘」ではなく「確認・相談」のトーンで伝える（開発会社側の心証も変わります）
• 「これくらい当然やってくれるはず」という思い込みで断定的に報告すると、記載がなかった場合に話がこじれやすくなります

仕様変更や追加要望の扱い、それに伴う追加費用の考え方について詳しく知りたい方は、この点を専門に解説した記事もあわせてご覧ください。検収の場面は、まさにこの「仕様の範囲」を巡るやり取りが集中的に発生するタイミングでもあります。

開発会社からの回答をどう受け止めるか

不具合を報告すると、開発会社からは主に次の3パターンの回答が返ってきます。それぞれへの向き合い方を整理します。

• 「不具合と認め、修正します」という回答: 修正の完了予定日を確認し、記録しておきます。優先度の高い不具合であれば、あわせて代替の運用方法（暫定的な回避策）がないかも確認しておくと、修正完了までの間の業務影響を抑えられます
• 「仕様通りの動作です」という回答: 前述の通り、仕様書のどの記載に基づく動作かを確認します。根拠となる記載が示された場合は、それが自社の理解と食い違っていた原因（要件定義の段階での認識合わせ不足など）を振り返る材料にします
• 「調査中で、原因が特定できていません」という回答: いつまでに調査結果を報告してもらえるか、期限を確認しておきます。調査が長引く場合は、業務への影響度に応じて、エスカレーション（現場の担当者間のやり取りでは進まない場合に、双方の上位者を交えて対応を進めること）を検討するタイミングの目安にもなります

いずれの回答であっても、口頭やチャットでのやり取りだけで終わらせず、最終的な結論（修正する・しない、対応時期）をメールなど残る形で確認しておくことが重要です。検収期間が終わった後になって「言った・言わない」の水掛け論にならないための、もっとも基本的な備えになります。

複数の不具合に優先順位をつける

検収で複数の不具合が見つかった場合、すべてを同じ重要度で扱うと、開発会社側の対応も分散してしまい、本当に急ぐべき修正が後回しになることがあります。

• 最優先: 業務が止まる、データが消える・壊れる、金額計算が間違っているなど、実害に直結する不具合
• 優先: 業務は継続できるが、頻繁に発生し現場の負担になる不具合（毎回手動で回避操作が必要になる、など）
• 低優先: 表示崩れ、文言の誤字など、業務への実害が小さい不具合

報告する際に、この優先順位を自分なりに付けたうえで開発会社に伝えると、限られた検収期間の中で、開発会社側も対応の順番を組み立てやすくなります。すべてを「至急」として報告してしまうと、かえってどれが本当に急ぐべきものか伝わりにくくなる点に注意してください。

優先順位の判断に迷う場合は、「この不具合が直らないまま本番稼働したら、来週の業務にどんな支障が出るか」を具体的に想像してみると整理しやすくなります。支障が想像しにくいものは、低優先に分類して差し支えないことが多いです。

修正後の再確認(再検収)で気をつけること

指摘した不具合が修正され、再度納品を受けたら、修正箇所の確認だけで終わらせず、次の点も併せて確認することをおすすめします。

• 指摘した箇所が、報告した通りの手順で本当に直っているか: 開発会社側の修正確認だけでなく、発注者側でも同じ手順を再現して確認します
• 修正によって、他の機能に影響が出ていないか（デグレードの確認）: とくに、共通で使われている処理（計算ロジック、権限チェックなど）を修正した場合は、関係のなさそうな別の画面も念のため触っておくと安心です
• 前回の検収時に確認済みだった項目が、今回も変わらず動作しているか: 全項目を再テストする必要はありませんが、主要な機能だけでも簡単に再確認しておくと、思わぬ副作用に気づきやすくなります

修正のたびにこのサイクルを繰り返していると、当初想定していた検収期間を超過することがあります。指摘の往復が想定より多くなりそうだと感じた段階で、社内の関係者（上長など）に早めに状況を共有し、スケジュールへの影響について相談しておくことをおすすめします。

よくある失敗パターンと対策

最後に、検収の実務でありがちな失敗パターンを3つ紹介します。自社の進め方と照らし合わせて、当てはまるものがないか確認してみてください。

• 「動いているから大丈夫」で終わらせてしまう: 画面を一通りクリックして、エラーが出なければ合格にしてしまうパターンです。前述の5つの視点（表示・入力、データの整合性、権限、異常系、運用シナリオ）のうち、異常系と運用シナリオは意識しないと確認が漏れやすい領域です。チェックリストを使い、視点ごとに確認したかどうかを明示的にチェックすることで防げます
• 不具合報告が感想文になってしまう: 「なんか動きが変です」「使いにくいです」といった主観的な感想だけを伝え、開発会社側が再現できずに対応が止まってしまうパターンです。発生日時・操作手順・期待結果・実際の結果・影響範囲の5要素を、面倒でも毎回書く習慣をつけることが対策になります
• 検収期限に追われて確認を打ち切ってしまう: みなし検収の期限が迫り、確認が終わっていないのに「もう時間がないから」と合格にしてしまうパターンです。期限に間に合わないと分かった時点で、早めに開発会社へ延長を相談することが、この失敗を防ぐ唯一の方法です。相談すること自体を遠慮する必要はありません

これら3つのパターンに共通するのは、いずれも「時間や手間を惜しんだ結果、後になってより大きな手間（本番運用後の不具合対応、追加費用の交渉など）が発生する」という構造です。検収にかける時間は、その後の運用期間の長さを考えれば、決して大きな投資ではありません。

検収の実務チェックリスト（まとめ）

ここまでの内容を、検収当日にそのまま使えるチェックリストの形でまとめます。

• 一覧画面と詳細画面で、同じ項目の表示形式が揃っているか確認したか
• 必須項目の空欄・不正な値の入力に対して、分かりやすいエラーメッセージが出るか確認したか
• 入力したデータが、関連する他の画面・帳票にも正しく反映されているか確認したか
• 権限ごとに、見える範囲・操作できる範囲が仕様通りか、複数の権限パターンで確認したか
• 極端な値の入力や、連続操作といった異常系の挙動を確認したか
• 月末・期末など特定タイミングでしか動かない処理を、テスト環境で確認したか（または確認できないことを認識しているか）
• 見つけた不具合を、発生日時・操作手順・期待結果・実際の結果・影響範囲の5要素で報告文にまとめたか
• 「不具合」なのか「仕様書に記載のない認識のズレ」なのかを、報告前に自分なりに切り分けたか
• 複数の不具合がある場合、優先順位をつけて伝えたか
• 開発会社からの回答を、メールなど記録に残る形で確認したか
• 修正後の再確認で、指摘箇所だけでなく周辺機能への影響（デグレード）も確認したか

このチェックリストをそのまま使うだけでも、確認の抜け漏れをかなり減らせます。プロジェクトの規模や業務の重要度に応じて、自社の状況に合わせて項目を加除してご利用ください。

まとめ:検収は「具体的に見て、具体的に書く」ことですれ違いを防げる

検収の実務で起きるトラブルの多くは、確認の視点が「機能が動くかどうか」だけに偏っていたり、不具合の報告が曖昧で開発会社側に正確に伝わらなかったりすることから生まれます。表示・入力、データの整合性、権限、異常系、運用シナリオという5つの視点で具体的に確認し、見つけた不具合は発生日時・操作手順・期待結果・実際の結果・影響範囲の5要素で報告することで、開発会社とのやり取りの往復を大きく減らせます。

また、報告する前に「これは仕様書に記載された不具合なのか、それとも記載のない認識のズレなのか」を自分なりに切り分けておくことも重要です。この一手間が、検収期間中の不要な行き違いを防ぎ、双方が納得できる形で検収を完了させることにつながります。

検収そのものの法的な位置づけや、検収後に不具合が見つかった場合の契約不適合責任について基本から確認したい方は、関連記事もあわせてご覧ください。検収は一度きりの作業ではなく、その後の保守・運用フェーズへの橋渡しでもあります。丁寧な確認と記録が、長期的なシステム運用の安心感につながります。