◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 検収は納品物が事前に定めた合格条件を満たすかを確認する工程で、現場で使われ続けるかを判定する工程ではない
- 合格条件は契約書本文とは別の検収仕様書などに書かれ、不合格にできるのは条件を満たしていないと合理的に判断できる場合に限られる
- 検収期間内に不合格を通知しなければ合格が確定するため、期間から確認の段取りを逆算する
- 中間検収・分割検収という多段階の検収を使えば最終検収の前に試用の機会を置けるが、その合格基準は発注者と受注者で合意して書き下ろす必要がある
- 定着の確認は検収とは別枠で、見るもの・見る時期・引き取る担当の三つを決めて進める
目次

検収に合格させても現場で使われなくなるのではという不安
納品物の一覧を開き、テスト項目を上から確認していく。
画面は仕様書どおりに動き、帳票も想定した形で出てくる。
それでも検収印を押す手が止まるのは、この合格判定が半年後の現場まで保証してくれるわけではないと、どこかで分かっているからです。
結論から言えば、検収は納品物が事前に定めた合格条件を満たしているかを確認する工程であり、現場で使われ続けるかどうかを判定する工程ではありません1。
だからこそ検収の合格条件は仕様適合に絞り、定着の見込みは中間検収や分割検収といった多段階の検収の枠組み、あるいは検収とは別枠の確認期間の側で扱います。
判断と確認を分けて置くことが、合否を止めずに定着の心配へ手を打つ順序になります。
検収作業そのものは、手順としてはっきりしています。
納品物を受け取り、仕様書と突き合わせ、動作を確認し、合否を通知する。
やるべきことは明確なのに落ち着かないとしたら、それは手順が分からないからではなく、手順の外側にある心配が処理されないまま残っているからです。
以前に導入した別の仕組みが数か月後には使われなくなっていた、という経験があると、この感覚はなおさら強くなります。
この不安を分解すると、性質の違う二つの問いが重なっていることが分かります。
一つは「届いた納品物は、約束したとおりのものか」という問い。
もう一つは「この仕組みは、現場で使われ続けるか」という問いです。
前者は納品の時点で答えが出ます。
判断の材料は仕様書と納品物そのものであり、話し相手はベンダーです。
後者の答えが出るのはこれから先で、判断の材料は実際に誰がどれだけ使ったかという記録であり、相手は自社の現場になります。
この二つを一つの判断に混ぜると、どちらも中途半端になります。
「現場が使いにくいと言い出すかもしれない」という予感を理由に合否の判断を保留すれば、検収が終わらず、支払いも次の工程も止まります。
かといって合否だけを機械的に済ませて手続きを閉じると、数か月後に本当に使われなくなったとき、何がいつからおかしかったのかをたどる手がかりが残りません。
検収の場で決められることと決められないことの境目が曖昧なまま、不安だけが持ち越される状態です。
そこで順序を入れ替えます。
先に「検収という工程では何をどこまで決められるのか」を確定させ、そこに乗らないものは別の器へ移す。
この切り分けができると、検収の合否は迷わず出せるようになり、定着の心配は「合格か不合格か」という粗い二択ではなく、時期と担当を決めて手を入れられる課題に変わります。
まずは、検収で確認すべき範囲がどこまでなのかを押さえるところからです。
検収で確認すべき範囲はどこまでか
検収仕様書に何を書くか
検収の合格条件は、契約書の本文ではなく、それとは別に作成する検収仕様書などに記載されることが多いとされています1。
契約書を開いて「検収に合格したときに報酬を支払う」という条文を見つけても、そこには合格の中身が書かれていないのが普通だということです。
つまり、いま自分が何をものさしにして合否を判断することになっているのかは、契約書一式のどこに合格条件が書かれているかを特定しないと分かりません。
これは受託開発型のシステム導入契約についての一般的な整理であり、実際には個別契約で交わした検収仕様書の記載が優先します。
この構造には理由があります。
合格条件は対象や内容によって違うため、契約書本文に書き込める粒度では合否を判定できないのです。
受発注の当事者が、その案件に限った条件を別紙として詰める。
裏を返せば、詰め方が甘い検収仕様書を受け取ってしまうと、検収の場で判断できる材料が手元にないことになります。
たとえば合格条件が「システムが正常に動作すること」とだけ書かれていた場合を考えてみます。
正常の中身を書いていないので、誰が判定しても同じ答えになる状態が作れません。
ベンダーは動いていると言い、現場は使えないと言い、導入担当者はその間で合否を決められない。
合格条件として役に立つのは、どのデータを入れて、どの画面で、何が表示されたら合格なのかまで書かれているものです。
この粒度まで書き下ろすのは手間ですが、判定に立ち会う人が増えるほど効いてきます。
合否判定は誰がどう行うか
発注者は、事前に定めた合格条件に照らして検収を行わなければならないとされています1。
検収の場で新しい条件を持ち出して判定することはできない、という意味です。
判定の作業は、目の前の納品物を見て良し悪しを感じ取ることではなく、あらかじめ用意されたものさしを一つずつ当てていくことになります。
もう一つ押さえておきたいのが期間の扱いです。
検収期間内に、発注者が受注者に対して不合格の通知を発しなければ、自動的に検収合格となります1。
何も言わずに期間が過ぎれば合格が確定するということですから、期間の長さは「その日数のあいだに、合格条件を全部当てきれるか」で決まります。
現場の担当者に実際のデータで触ってもらう予定があるなら、その日程が期間の内側に収まっているかを先に見ておく必要があります。
すでに契約済みで期間を動かせないなら、逆にその日数から確認の段取りを組み立てることになります。
判定を誰がやるかも、感覚ではなく条件の書き方で決まります。
導入担当者が一人で全項目を当てるのか、現場の作業者に操作してもらった結果を判定材料にするのか。
後者を想定しているなら、合格条件の側に「現場の担当者が既存の手順書を見ずに登録作業を完了できること」といった形で書かれていなければ、現場を巻き込んだ結果を合否に反映させる根拠がありません。
現場の声を検収に届かせたいのであれば、声を集める工夫より先に、条件として書いてあるかどうかを確認する方が近道です。
検収の合否と現場の定着がなぜ別の話になるのか
ここまでで、検収の判断材料は事前に定めた合格条件に限られることを見てきました。
この性質は、不合格を出す側にも同じように働きます。
発注者が納品物を検収不合格にできるのは、納品物が合格条件を満たしていないと合理的に判断できる場合に限られます1。
合格条件に書かれていないことを持ち出して不合格にすることはできない、ということです。
この一点が、冒頭の不安に対する答えの骨格になります。
「現場が使いにくいと言っている」「このままでは定着しない気がする」という懸念は、それが合格条件として書かれていない限り、不合格の理由にはなりません。
検収という制度が、そもそも仕様適合の確認に範囲を限定して設計されているからです。
受注者の側から見れば当然で、事前に示された条件に向けて作ったものを、後から出てきた別の基準で不合格にされるなら、そもそも請けられません。
そして定着の側は、納品物の出来だけで決まりません。
同じ仕組みでも、既存のやり方と比べてどちらが早いか、分からないときに聞ける相手が近くにいるか、使わなくても仕事が回ってしまう抜け道が残っているかで、使われ方は変わります。
これらは納品の時点では確かめようがなく、仕様書に書ける形にもなっていません。
検収の合格が定着を保証しないのは、ベンダーの仕事が不十分だからではなく、両者が見ている時点も材料も違うからです。
| 観点 | 検収の合否 | 定着の確認 |
|---|---|---|
| 判断する時点 | 納品を受けた時点 | 使い始めてからの期間 |
| 判断の材料 | 事前に定めた合格条件と納品物 | 実際の利用の記録と現場からの声 |
| 向き合う相手 | 受注者(ベンダー) | 自社の現場と運用 |
| 出せる結論 | 合格か不合格か | どこに手を入れるか |
一つ断っておくと、ここまでの整理は、検収の対象範囲が仕様適合に限定されているという契約実務の事実から導いた筋道です。
検収に合格した仕組みが実際にどれくらいの割合で使われなくなるのか、その原因が何に集中しているのかを示す調査を根拠にしているわけではありません。
ですから「検収に合格すると使われなくなる」という因果を主張しているのではなく、「検収の合否という手続きは、定着を見る役目を負っていない」という範囲の話として受け取ってください。
役目を負っていない工程に役目を期待していたことが、あの落ち着かなさの正体でした。
検収条件に段階や確認期間を組み込む設計はできるか
中間検収・分割検収・最終検収の違い
では、検収の側から定着に近づく手立ては何もないのかというと、そうではありません。
検収は必ず一回きりというわけではなく、開発工程が複雑な場合には、中間検収・分割検収・最終検収という多段階の検収を行うこともあります1。
合否を出す機会を複数持てるなら、納品物を全部受け取ってから初めて現場に触れてもらう、という進め方以外の選択肢が出てきます。
このうち分割検収は、受注制作のソフトウェア取引において、一つのソフトウェア開発プロジェクトをいくつかの作業ごとのフェーズに分けて契約を締結し、フェーズごとに検収を行うことを指します2。
フェーズの分け方には二通りあり、設計段階の完了・開発段階の完了などで区分する時系列的な分割と、購買システムの完了・経理システムの完了などで区分する物的な分割があります2。
前者は工程の進み具合で区切る考え方、後者は対象の範囲で区切る考え方です。
この二つの分け方は、定着の心配に対して効き方が違います。
対象で区切る分割なら、現場の業務のうち一部だけを先に区切って受け取り、そこだけ実際に使ってもらうことができます。
使われるかどうかの手応えを、残りを受け取る前に得られるわけです。
工程で区切る分割なら、設計が完了した段階で、想定されている操作の流れと現場の実際の作業順序の食い違いを見つけられます。
作り込まれた後に「この順番では回らない」と分かるより、手当ての幅は広く残ります。
試用確認フェーズを設けるときの合意事項
ここから先は、確認できた実務の枠組みを踏まえた提案になります。
多段階の検収を使えるなら、最終検収の前に、現場が実際のデータで一定期間使う段階を置き、その段階の合格条件を検収仕様書に書き込む、という設計ができます。
定着そのものを検収の合否に載せるのではなく、定着を見るための機会を検収プロセスの中に位置づける、という考え方です。
ただし注意が要ります。
何をもって「現場で使えている」とみなすのかという基準は、今回参照した資料の中には示されていません。
多段階の検収という枠組みが存在することと、その段階での合格基準が決まっていることは別です。
基準は発注者と受注者が個別に合意して、検収仕様書に書き下ろすほかありません。
ここを詰めずに「現場の評価が良好であること」とだけ書いてしまうと、判定できない条件を抱えたまま日数が過ぎ、先に触れたとおり期間の経過で合格が確定します1。
合意しておきたいのは、実務的には次のような点です。
誰が何日間、どのデータを使って触るのか。
その結果をどう記録し、何が起きたら条件を満たしていないと判断するのか。
満たしていないと判断した場合、受注者は何をどこまで直すのか。
分割検収はフェーズごとに契約を締結する形を取るものですから2、この段階を入れるなら発注の時点で決めておく必要があります。
すでに契約が結ばれていて、いまから段階を増やせない場合もあります。
その場合は無理に検収の中へ押し込まず、検収は当初の合格条件で閉じたうえで、定着の確認を別枠の取り組みとして設計する方が現実的です。
次の契約や次の導入のときに、この段階を最初から入れられるよう、今回の検収で困ったことを記録に残しておくと材料になります。
食品業界のDX推進状況を踏まえた現場条件の扱い方
検収仕様書に現場の条件を書き込むという話になると、そもそも自社の現場条件をどう言語化すればよいのかという問題が出てきます。
その前に、食品の事業者がどんな状況でこの種の導入に向き合っているかを一つだけ見ておきます。
食品製造業の従事者339人を対象に2021年6月に実施された意識調査では、DXに「現在取り組んでいる」と答えた人は全体の13.6%でした3。
1割強という水準です。
この数字から読み取れるのは、社内に「前にも似た導入を経験した人」がいない状態で進んでいる事業者が多いだろう、ということです。
同じ調査で挙げられた課題の上位は、推進できる人材の不足、予算の確保・制約、知識やノウハウの不足でした3。
どれも、導入を決めるかどうかの話というより、入れた後に人手と時間をかけて面倒を見続けられるかに関わる項目です。
人と予算とノウハウが薄いところでは、検収後に教育の場を作ったり、現場の声を吸い上げる経路を整えたりする作業に着手しにくいと考えられます。
これは調査が直接測った結果ではなく、挙がった課題の並びから読み取れる見方です。
この調査の性格も押さえておきます。
実施したのは食品工場向けのソリューションを提供している企業で、回答者は食品製造業の従事者ですが、職種や役職の内訳は公表されていません3。
そして、交代制勤務で同じ端末を複数の班が使うことや、機械操作に慣れていない作業者が多いことが、システムの利用継続にどう効くかまでは、この調査からは読み取れません。
ですから「食品の現場だから定着しにくい」という一般化には使えませんし、使う必要もありません。
検収仕様書に書くべきなのは、業界の傾向ではなく、自社で確認できる事実の方だからです。
1日のうち端末を操作できる時間帯が限られているなら、その時間帯に処理が終わる必要があるという条件になります。
手袋をしたまま操作する場面があるなら、その状態で入力が完了できることが条件になります。
班ごとに担当者が入れ替わるなら、引き継ぎの途中でも前の班の入力内容が分かることが条件になります。
いずれも現場に行けば確認できる事実で、合格条件の形に書き下ろせるものです。
逆に、業界全体の傾向を根拠にして条件を立てようとすると、ベンダーと共有できる具体性が出ません。
調査の数字は、自社の状況が特殊なのかどうかを見積もるための背景として持っておき、検収の判断材料は自社の現場で取ってくる。
この役割分担にしておくと、限られた人手と時間をどこに使うかも決めやすくなります。
検収と定着確認を分けて進める実務の流れ
ここまでの内容をまとめて、実際の進め方に落とします。
順序としては、まず検収を仕様適合の確認として閉じます。
合格条件を特定し、条件に照らして判定し、期間内に結果を通知する。
定着への心配は、この判定の中には入れません。
入れられないからというより、入れると判定できなくなるからです。
そのうえで、定着の確認を別枠で設計します。
決めることは、何を見るか、いつ見るか、見つかったものを誰が引き取るか、の三つです。
順に見ていきます。
何を見るかについては、後から数えられるものを選びます。
利用の記録、たとえば誰がどれだけ登録作業を行ったかは、実際に記録として残っていれば数えられます。
ここで注意したいのは、システムの中にデータが溜まることと、その利用状況を一覧で取り出せる機能があることは別だという点です。
検収の段階で、何がどこまで記録として取り出せるのかを確認しておくと、後から数えようとして取り出せないという事態を避けられます。
取り出せないなら、現場からのフィードバックを受け付ける窓口を一つ決めて、そこに来た件数と内容を自分で記録する形にします。
いつ見るかは、検収の直後と、現場が一通り回してみた後の二点を置くのが扱いやすい形です。
直後は、そもそも使い始められているかの確認になります。
その先は、繁忙の波がある事業なら忙しい時期を避けて、通常の業務量のときの様子を見る方が実態に近い材料が取れます。
期間の長さそのものより、いつ見るかを先に決めて予定に入れておくことが効きます。
決めていないと、検収が終わった安堵とともに、確認の機会が後ろへずれていきます。
誰が引き取るかは、実は一番抜けやすいところです。
現場から「この画面の入力が面倒だ」という声が出たとして、それが納品物を直す話なのか、自社の運用手順を変える話なのかで、動く人が変わります。
前者ならベンダーの保守の範囲に入るのかを契約で確認する必要があり、後者なら現場の手順書を誰が書き直すのかを決める必要があります。
ここを決めずに声だけ集めると、記録は増えるのに何も変わらない状態になり、次からは声も出なくなります。
この二段階の進め方は、確認できた検収の仕組みを踏まえた編集上の整理であって、契約で決まっている手順ではありません。
実施するには、少なくとも定着確認の時期にベンダー側が何をするのかについて、受注者との合意が要ります。
それでも、検収の合否を予定どおり確定させることは、定着を諦めることではありません。
定着の話を合格か不合格かという粗い二択から外して、時期と担当を決めて手を入れられる課題に置き直す、というだけのことです。
検収印を押す前の落ち着かなさは、この置き直しができた時点で、やることリストに変わります。
あとは、手元の検収仕様書と自社の現場に当てはめていく作業になります。
検収の合格条件をどこまで仕様適合に絞り、どこからを別枠の確認に回すかは、手元の検収仕様書の書きぶりと、現場で誰が何分触れるかという条件が分からないと決められません。
検収仕様書の該当箇所と、現場の確認に使える日数を共有いただければ、いまの条件で判定できる項目とできない項目の線引きを一緒に整理できます。無料相談で要件を整理する
食品製造業がDX推進で直面する主な課題(回答割合)
順位は公表された調査に依ります3。
公表された調査に依る順序
- 推進できる人材不足 37.4%
- 予算の確保・制約 34.3%
- 知識・ノウハウの不足 34.3%
同じ項目でも、導入を決める段階で効くものと、入れた後に面倒を見続ける段階で効くものとに読み分けると、検収後の確認をどこまで自前で回せるかの見当がつきます。
要点の整理
| 軸 | 基準 |
|---|---|
| 検収の合否 | 契約書本文とは別の検収仕様書に書かれた合格条件を満たすか1 |
| 不合格の可否 | 合格条件を満たしていないと合理的に判断できる場合に限られる1 |
| 検収期間 | 期間内に不合格を通知しなければ合格が確定する1 |
| 段階の設計 | 時系列か対象かでフェーズを区切り、発注の時点で合意しておく2 |
| 現場条件 | 業界の傾向ではなく、自社で確認できる事実を合格条件の形にする |
| 定着の確認 | 検収とは別枠で、見るもの・見る時期・引き取る担当を決める |
定着の確認を別枠で回すには、何が利用の記録として取り出せるのかと、出てきた声を誰が引き取るのかを、納品物と自社の体制の両方から見ておく必要があります。 納品物から取り出せる記録の範囲と、確認の時期・担当の置き方について、自社の状況に沿った形をご相談いただけます。
よくある質問
検収に不合格を出せる期限はどれくらいに設定するのが一般的か
日数の相場を示す資料は確認していないため、ここでは決め方の考え方をお伝えします。
押さえておきたいのは、検収期間内に発注者が受注者へ不合格の通知を発しなければ、自動的に検収合格となるという点です1。
黙っていれば合格が確定する仕組みですから、期間は「その日数で合格条件を全部当てきれるか」から逆算することになります。
現場の担当者に実際のデータで操作してもらう予定があるなら、その日程が期間の内側に収まっているかを先に見てください。
すでに契約済みで期間を動かせない場合は、その日数に合わせて確認の段取りを組み、判定が間に合わない項目があるなら早い段階でベンダーへ相談しておくのが現実的です。
検収仕様書には具体的にどのような項目を書けばよいか
資料から確認できるのは、合格条件が契約書本文とは別の検収仕様書などに記載されることが多く、発注者は事前に定めたその条件に照らして検収を行う、という点です1。
項目の雛形が決まっているわけではないので、ここから先は考え方になります。
基準は「立ち会う人が代わっても同じ答えになるか」です。
どのデータを入れ、どの画面で、何が表示されたら合格なのかまで書かれていれば判定できます。
反対に「正常に動作すること」といった書き方では、その場で解釈が割れます。
現場に操作してもらった結果を合否に反映させたいなら、判定者と判定方法も条件の側に書いておかないと、集めた声を合否の根拠にできません。
検収後にバグが見つかった場合はどう扱われるか
検収の合否は事前に定めた合格条件に照らして判断されるものなので1、検収を終えた後の不具合をどう扱うかは、検収の条項ではなく契約書の別の条項で定められているのが通常です。
今回参照した資料はその条項の中身までは扱っていないため、具体的な責任の範囲や期間については、自社の契約書の該当箇所を確認してください。
実務として検収の段階でできるのは、後から話をしやすくする準備です。
合格判定に使った検収仕様書の版、確認した項目と結果、確認しきれなかった項目を記録に残しておくと、後で見つかった不具合が「条件に含まれていたのに満たされていなかったもの」なのか「条件の外にあったもの」なのかを切り分けられます。
段階検収を導入するには発注時に何を決めておく必要があるか
分割検収は、一つのソフトウェア開発プロジェクトをいくつかの作業ごとのフェーズに分けて契約を締結し、フェーズごとに検収を行う形を取ります2。
契約の単位そのものが分かれるので、フェーズの切り方は発注の時点で決めておく必要があります。
切り方には、設計段階の完了・開発段階の完了などで区分する時系列的な分割と、購買システムの完了・経理システムの完了などで区分する物的な分割があります2。
現場で使われるかを早めに確かめたいなら対象で区切る形が、操作の流れと実際の作業順序の食い違いを早く見つけたいなら工程で区切る形が向きます。
そのうえで、各フェーズの合格条件と検収期間、その段階で不合格とした場合に受注者が何をするのかを、条件として書き下ろしておくことになります。
- 1 出典:ベリーベスト法律事務所「IT業界における検収とは?合格条件・期間・報酬の取り扱いなどを解説」(確認日2026年)
- 2 出典:EY Japan有限責任監査法人 用語集「分割検収」(確認日2026年)
- 3 出典:富士電機株式会社「食品製造業におけるDXに関する意識調査」(2021年)
画像の出典元
- office, boardroom, meeting, table, boardroom meeting, office meeting, business meeting, office, boardroom, boardroom, meeting, meeting, meeting, meeting, meeting, office meeting, business meeting, business meeting, business meeting/Jo_Johnston on Pixabay