初めて開発会社とやり取りする情シス1人目が検収で失敗しないための確認項目

「検収をお願いします」と開発会社から言われて、初めてその言葉を辞書で調べた、という情シス担当者は少なくありません。30〜100人規模の会社で初めて情シスの看板を持った人の多くは、開発の発注も検収も未経験のまま、目の前の画面を「なんとなく動いているから大丈夫そう」という感覚だけで確認し、サインをしてしまいます。

問題は、検収は一度完了させると後から取り消しが難しい手続きだという点です。検収完了は「この納品物を契約通りの内容として受け取りました」という法的な意思表示に近く、完了後に不具合が見つかっても、無条件に無償で直してもらえるとは限りません。だからこそ、検収という作業の重みを知らないまま感覚的に済ませてしまうことが、未経験の情シス担当者にとって最も危険な失敗になります。

検収で確認すべき項目そのもの(表示・データ整合性・権限・異常系・運用シナリオ)は検収で見るべきポイントと不具合対応の依頼方法に、検収の法的な位置づけは検収とは？発注者がやるべきテストに詳しくまとまっています。このガイドはその一歩手前、「検収という作業の重みを知らない人が、何を知らないまま失敗するか」という初心者特有のつまずきに焦点を当てます。

なぜ初めての検収は失敗しやすいのか

検収で失敗する人の多くは、技術力が足りないから失敗するのではありません。検収という行為が何を意味するのかを知らないまま、手続きとしてこなしてしまうことが失敗の根本原因です。具体的には、次の3つの誤解が典型的です。

1. 「動けば合格」だと思っている: 画面を開いてボタンを押し、エラーが出なければ「問題ない」と判断してしまう。しかし検収で見るべきは「動くかどうか」ではなく「発注時に合意した仕様通りに動くかどうか」です
2. 「サインしても後から直してもらえる」と思っている: 検収完了後の不具合修正は、契約不適合責任の範囲内であれば無償対応が期待できますが、範囲外(仕様通りに動いているが使い勝手が悪い、等)であれば有償対応になる可能性があります。この境界線を知らないまま検収を終えると、後から「これは無償で直る」と思っていたものが有償だと判明し、トラブルになります
3. 「検収期限に間に合わせることが最優先」だと思っている: 開発会社から「今週中に検収をお願いします」と言われると、内容の確認より期限厳守を優先してしまいがちです。しかし拙速な検収は、後から見つかる不具合のリスクを増やすだけで、結果的に双方の手間を増やします

この3つの誤解は、いずれも「検収とは何か」を正しく理解していれば防げるものです。次の見出しから、検収の法的な意味と、初心者が具体的に踏むべき手順を順に整理します。

検収完了が意味すること: 「受け取りました」のサインの重さ

検収完了のサインは、単なる作業報告の確認ではなく、法律上「この目的物を契約内容通りのものとして受領した」という意思表示になります。この意思表示がなされた後に不具合が見つかった場合、開発会社側の責任(契約不適合責任)を追及できるかどうかは、民法上の規定と契約書の記載の両方によって決まります。

民法では、請負契約における担保責任(契約不適合責任)について、注文者が不適合を知った時から1年以内に請負人に通知しなければ、原則としてその権利を失うと定められています(民法第637条)。つまり、検収完了後に不具合を見つけたとしても、「気づいてから1年以内に通知する」という期限があり、この期限を過ぎると法律上の保護を受けられなくなる可能性があります。

さらに注意すべきは、この民法の規定は当事者間の合意(契約書)で変更できる任意規定だという点です。契約書に「検収完了後6ヶ月以内に発見した不具合に限り無償対応する」といった、民法の規定より短い期間が定められているケースもあります。検収を行う前に、自社が結んでいる契約書に契約不適合責任の期間がどう定められているかを確認しておくことが、検収の質を左右する前提知識になります。契約書の該当箇所が見当たらない、あるいは内容を覚えていない場合は、契約そのものを洗い出す作業が必要になります。詳しくはこちら→前任者が結んだ保守契約の中身が分からないまま運用している状態の点検方法

検収前にやること: 「何と比べて合格とするか」を先に決める

未経験の情シス担当者が検収でつまずく最大の理由は、比較対象を持たずに画面だけを見て判断しようとすることです。検収とは、納品物を「何かと比較して」合格・不合格を判定する作業です。比較対象がなければ、判断基準は「なんとなく良さそう」という主観に頼るしかなくなります。

比較対象として使うべき資料は、主に次の3つです。

この3資料が手元に揃わない状態で検収に臨むのは、答えのない試験を受けるようなものです。もし資料が見当たらない場合、検収作業そのものより先に、資料の所在確認を優先してください。前任者からの引き継ぎが不十分で資料の在り処が分からない場合の調査手順は属人化していた社内システム、引き継いだら最初に何を調べるかで扱っています。

検収で最も見落とされる観点: 「合意した範囲外」への気づき方

検収チェックのポイント自体(表示確認・データ整合性・権限確認・異常系テスト・運用シナリオ)は既存のコラム記事に譲りますが、未経験者が特につまずくのは、こうした個別の確認項目そのものよりも、「これは合意した範囲に含まれているのか、含まれていないのか」の切り分けです。

たとえば、納品されたシステムを触っていて「ここはこうなっていてほしかった」と感じる箇所が見つかったとします。このとき、初心者が陥りやすいのは次の2つの極端な反応です。

• 反応A: 「仕様と違うから不具合だ」と決めつけて突き返す: しかし、そもそも要件定義書にその挙動が明記されていなければ、開発会社側からすれば「合意していない要望」であり、対応するなら追加費用が発生する話になります
• 反応B: 「まあ動いているからいいか」と流してしまう: しかし、それが実は要件定義書に明記されていた仕様だった場合、無償で直してもらえる不具合を見逃したことになります

この2つの反応のどちらに転ぶかは、要件定義書を確認したかどうかで決まります。気になる箇所を見つけたら、まず「これは要件定義書のどこに書かれているか(あるいは書かれていないか)」を確認する癖をつけることが、未経験者にとって最も重要な検収スキルです。要件定義書に明記がなく、かつ業務上どうしても必要な機能であれば、それは検収の合否とは別に「追加開発の依頼」として仕分けます。追加開発の頼み方については追加開発の頼み方: 小さな改修を安く早く進めるコツで扱っています。

ケースで考える: 3つの典型的な失敗パターン

未経験の情シス担当者が実際に踏みやすい失敗を、3つのケースとして整理します。

ケース1: 検収期限に追われて表面確認だけで終える

開発会社から「今週金曜までに検収をお願いします」と連絡が来て、木曜の夕方にようやく時間を取り、画面をひととおりクリックして「特に問題なさそうです」と返信してしまうケースです。この場合、業務で実際に使う頻度の低い機能(月末処理、年次更新など)のテストが漏れやすく、後になって「使う段階になって初めて不具合に気づく」という事態が起きます。

対策は単純で、検収期限は「余裕を持って前倒しで依頼する」よう、契約時または検収依頼を受けた時点で交渉することです。「検収には最低1週間必要です」と最初から伝えておけば、期限に追われて表面確認だけで終わる事態を防げます。すでに短い期限を提示されている場合は、「重要な機能から優先的に確認し、確認しきれない部分は期限後も継続して確認する」旨を先に伝え、記録に残しておくことをお勧めします。

ケース2: 不具合を見つけたが、開発会社に伝えるのを遠慮してしまう

「これは自分の使い方が間違っているだけかもしれない」「開発会社に失礼な指摘をしてしまうのではないか」という遠慮から、気づいた不具合を検収の場で伝えず、後になって「やっぱりおかしい」と言い出すケースです。これは、検収完了後に不具合を指摘することになり、前述した契約不適合責任の通知期限や、開発会社側の「なぜ検収時に言わなかったのか」という心証の悪化を招きます。

対策は、「間違っているかもしれない」と思った時点でメモに残し、検収完了前に一度全て開発会社にぶつけてみることです。仮に使い方の誤りだったとしても、それを確認する過程で操作方法を教えてもらえるという副次的なメリットもあります。不具合の伝え方・報告文の書き方は検収で見るべきポイントと不具合対応の依頼方法で詳しく扱われているので、遠慮なく使ってください。

ケース3: 検収サインの意味を理解しないまま押印・返送してしまう

検収完了書に押印・サインを求められた際、それが何を意味するかを深く考えずに「求められたから」という理由で応じてしまうケースです。前述の通り、検収完了は法的な意思表示であり、一度完了させると契約不適合責任の期間がそこから起算されます。

対策は、サインをする前に「これは何に対する合意なのか」を必ず一呼吸置いて確認することです。分からなければ、その場でサインせず持ち帰り、社内の上司や、必要であれば顧問弁護士に相談してから対応しても構いません。検収期限があるからといって、内容を理解しないまま拙速にサインする必要はありません。

検収で不具合が見つかったときの初動

検収中に不具合を見つけた場合、未経験者ほど「どう伝えればいいか分からず、結局伝え方に悩んで時間だけが過ぎる」という状態に陥りがちです。最低限、次の4点を含めて開発会社に伝えれば、初動としては十分です。

• 何をしたら(操作手順)
• 何が起きたか(実際の挙動、エラーメッセージがあれば全文)
• 何を期待していたか(要件定義書のどの記載を根拠にしているか)
• いつ気づいたか(検収期限との関係を明確にするため)

この4点を箇条書きでまとめてメールで送るだけで、開発会社側も対応の優先順位をつけやすくなります。口頭だけで伝えて記録を残さないと、後から「言った言わない」の水掛け論になりかねません。この記録の重要性は、開発会社との連絡体制全般にも通じる話です。詳しくはこちら→開発会社との定例が回らない。兼任情シスが最低限維持すべき連絡体制

検収を「一度きりのイベント」にしない

検収は、システムが納品された瞬間の一度きりのイベントとして捉えられがちですが、実際には運用を始めてからも「隠れた不具合」が見つかることがあります。検収完了時点では気づかなかった不具合が、実際の業務で使い始めてから発覚するケースは珍しくありません。

このとき重要なのが、検収完了後に見つかった不具合が「無償修正の対象になるか、有償の追加対応になるか」の切り分けです。この切り分けは、リリース後しばらく経ってからの話になるため、検収そのものというより運用フェーズの話題になります。詳しくはこちら→リリース後の不具合、無償対応と有償対応の境界線

また、検収が完了し、プロジェクトが完了した段階で、開発会社から受け取っておくべきものが他にもあります。ソースコード、設計書、各種アカウントなど、検収の合否とは別に確認すべき納品物のチェックリストは納品完了時に受け取るべきもの一覧（ソースコード・設計書・アカウント）にまとめられています。検収に気を取られて、これらの受け取りを忘れてしまう担当者も少なくないため、あわせて確認することをお勧めします。

開発手法の違いによる検収タイミングの違い

もう1つ、未経験者が意外と知らずにつまずくのが、開発の進め方によって検収のタイミングや粒度が変わるという点です。「検収」と一括りに呼んでいても、契約の形態によって実際の運用は異なります。

• ウォーターフォール型(一括請負)の場合: 要件定義・設計・実装・テストという工程を順番に進め、最後にまとめて成果物一式を検収します。検収の対象範囲が広く、一度に確認すべき項目も多くなる傾向があります
• アジャイル型(準委任契約が多い)の場合: 短い期間(1〜4週間程度)ごとに機能を区切って開発し、その都度動くものを確認していきます。この場合、厳密な意味での「検収」という手続きが存在しないこともあり、代わりに各スプリントの成果物を都度レビューする形が一般的です

自社の契約がどちらの形態に近いかによって、検収に臨む姿勢も変わってきます。ウォーターフォール型であれば、このガイドで扱った「一度きりの重い確認作業」としての検収に丁寧に向き合う必要があります。アジャイル型であれば、検収という1回のイベントよりも、日々の確認の積み重ねが重要になります。請負契約と準委任契約の違いについては請負契約・準委任契約の用語集ページ、および請負契約と準委任契約の違い:システム開発の契約形態はどちらを選ぶべきかで詳しく解説されています。自社の契約形態がどちらか分からない場合は、契約書の該当条項を確認する前に、まずこの記事で契約類型そのものの違いを把握しておくと、検収に臨む姿勢を適切に調整できます。

検収を経験した後に残しておくべき記録

初めての検収を乗り切った後、次に同じような検収の機会が来たとき(追加開発の納品時、システムのバージョンアップ時など)に備えて、今回の経験を記録に残しておくことをお勧めします。特別な書式は不要で、次の3点をメモとして残しておくだけで十分です。

1. 今回、確認すべきだったのに見落としていた点: 検収完了後に気づいた不具合や、確認が甘かったと感じた箇所を振り返ります
2. 開発会社とのやり取りで役立った聞き方・伝え方: 「この聞き方をしたらスムーズに回答が返ってきた」という経験があれば、次回への備忘としてメモします
3. 社内の誰に相談すると助かったか: 現場担当者、経理、経営層など、実際に相談して役立った相手を記録しておくと、次回の相談先選びで迷わずに済みます

この記録は、自分自身が次に検収を行うときの助けになるだけでなく、将来的に情シス担当者が交代する際の引き継ぎ資料としても機能します。属人化を避けるという観点からも、検収の経験は個人の記憶に留めず、簡単なメモとして残す習慣をつけておくとよいでしょう。

初めての検収で使える最低限のチェックリスト

ここまでの内容を、初めて検収に臨む担当者がその場で使える最低限のリストとして整理します。

• [ ] 要件定義書・見積書・契約書(検収条項)の3点が手元に揃っているか
• [ ] 検収期限は妥当か。足りなければ延長を交渉したか
• [ ] 気になった挙動は全て要件定義書と照合したか(合意範囲内か外か)
• [ ] 不具合と感じた点は、検収完了前に全て開発会社に伝えたか
• [ ] 不具合の報告は「操作手順・実際の挙動・期待していた内容・気づいた日時」の4点を含めて記録に残したか
• [ ] 検収完了のサインが何を意味するか理解した上で押印・返送したか
• [ ] 検収完了後、契約不適合責任の通知期限(契約書に記載があればその期間、なければ民法の原則)を把握したか

このリストは、検収という言葉の意味を初めて知ったばかりの担当者でも、上から順に埋めていけば最低限の抜け漏れを防げるように設計しています。完璧な検収を初回から目指す必要はありません。まずはこのリストを満たすことから始めてください。

検収を1人で抱え込まない: 誰に相談すればよいか

情シス1人目という立場は、社内に検収の経験者がいないことを意味します。そのため「分からないことがあっても聞ける相手が社内にいない」という孤立した状態で検収に臨むことになりがちです。しかし、検収は情シス担当者が単独で完結させなければならない業務ではありません。相談できる相手を、社内・社外の両方で洗い出しておくと、判断に迷ったときの負担が大きく下がります。

社内で相談できる相手としては、次のような候補が考えられます。

• 実際にそのシステムを使う現場の担当者: 機能面の使い勝手や、業務フローと合っているかどうかは、情シス担当者よりも現場の方が正確に判断できることが多くあります。検収を情シス担当者だけで完結させず、現場の担当者に実際に触ってもらう時間を設けることは、非常に有効な対策です
• 経理・法務(契約書の内容確認): 契約書の検収条項や契約不適合責任の期間について疑問がある場合、経理や法務の担当者(あるいは顧問弁護士・顧問税理士)に確認できないか探ってみます。中小企業では法務専任者がいないことも多いですが、顧問契約している専門家がいれば、契約書のチェックだけでも相談する価値があります
• 経営層: 検収の可否判断が経営に影響する規模の契約であれば、最終的な判断は経営層と共有すべきです。「自分の一存で検収完了のサインをしてよいのか」を、契約前にあらかじめ確認しておくと安心です

社外で相談できる相手としては、同じ「なび」シリーズの他メディアの読者コミュニティのような横のつながりがなくても、IPAの「情報システム・モデル取引・契約書」のような公的な資料を参照するだけでも、検収の一般的な進め方についての土台知識を補うことができます。専門家に依頼するほどではないが、一般論を確認したいという場合には、こうした公開資料への目通しをお勧めします。

検収の合否判断に迷ったときの「持ち帰り」という選択肢

未経験の担当者が最も陥りやすい罠の1つが、「その場で即答しなければならない」という思い込みです。開発会社の担当者を目の前にして、あるいはオンライン会議の最中に検収の合否を尋ねられると、つい「大丈夫だと思います」と即答してしまいがちですが、これは避けるべき対応です。

検収の合否判断は、その場で即断する必要はありません。「確認した上で、〇日までに回答します」と伝え、持ち帰って社内で確認する時間を確保することは、何ら失礼な対応ではなく、むしろ責任ある担当者としての当然の振る舞いです。開発会社側も、拙速な検収によって後からトラブルになるより、時間をかけてでも正確な検収をしてもらうほうを望んでいることがほとんどです。

持ち帰りを選んだ場合、次の点に注意してください。

1. 持ち帰る期間を明確に伝える: 「少し時間をください」ではなく「〇月〇日までに回答します」と具体的な期限を示します。これにより、開発会社側もスケジュールを立てやすくなります
2. 持ち帰った理由を簡単に伝える: 「社内の現場担当者に確認する必要があるため」など、一言添えるだけで、開発会社側の不信感を防げます
3. 期限内に必ず回答する: 持ち帰ったまま連絡を忘れると、開発会社との信頼関係を損ないます。カレンダーに回答期限を登録しておくなど、忘れない工夫をしておきましょう

検収と請求・支払いのタイミングの関係

未経験の担当者が見落としがちなもう1つの点は、検収完了と代金の支払いが連動しているケースが多いという事実です。多くの契約では、「検収完了をもって請求書を発行し、その後〇日以内に支払う」という流れになっています。つまり、検収を先延ばしにすることは、開発会社への支払いも先延ばしにすることを意味し、開発会社側の資金繰りに影響を与える可能性があります。

このため、「内容に不安があるから」といって検収を無期限に先延ばしにすることは望ましくありません。前述の「持ち帰り」も、あくまで数日〜1週間程度の期限を区切った一時的な保留であるべきで、理由なく長期間放置することは、開発会社との関係を損なう行為になり得ます。検収に時間がかかりそうな場合は、その旨と見込み期間を早めに開発会社に伝え、支払いスケジュールについても認識をすり合わせておくことが望ましい対応です。

部分検収という選択肢: 全部か何もないかで判断しない

未経験の担当者は、「検収は合格か不合格かの二択」だと思い込みがちですが、実際には「一部は合格、一部は継続確認」という部分検収も現実的な選択肢です。たとえば、10の機能のうち8つは問題なく確認できたが、残り2つは業務上の繁忙期でまだ十分にテストできていない、という状況はよくあります。

このとき、全体の検収を保留にして開発会社への支払いを丸ごと止めてしまうよりも、「問題のない8機能については検収完了とし、残り2機能については〇月〇日までに追加で確認する」という形で部分的に区切ったほうが、双方にとって現実的な進め方になることがあります。ただし、この部分検収を行う場合は、後から「どこまでが検収済みでどこからが未検収か」が曖昧にならないよう、対象範囲を書面(メールでも可)で明確に残しておくことが不可欠です。口頭だけで「大体は大丈夫です」と伝えてしまうと、後になって全体が検収完了したものとして扱われてしまうリスクがあります。

部分検収を持ちかける際は、契約書に部分検収に関する規定があるかどうかも確認しておくとよいでしょう。規定がない場合は、開発会社との個別の合意として扱うことになるため、なおさら書面での確認が重要になります。

まとめ: 検収の失敗は「知らなかったこと」がほとんど

初めての検収で起きる失敗の多くは、技術的な理解不足よりも、「検収とは何を意味する行為なのか」を知らないまま手続きとして流してしまうことに起因します。今回整理した3つの誤解(動けば合格・後から直してもらえる・期限厳守が最優先)を頭に入れておくだけでも、検収の質は大きく変わります。

検収は一度きりの試験ではなく、その後の運用や契約不適合責任の起算点にも関わる重要な手続きです。分からないことがあれば、その場で開発会社に質問することを恐れず、必要な資料が揃っていない場合は無理に検収を進めないという判断も持っておいてください。自社の状況を客観的に把握したい場合はひとり情シス危険度診断も活用できます。