システム開発の検収条件はどう決める？納品物と確かめ方を発注前にそろえる

検収・納品・受入条件を、発注前の問いに分ける

「納品された」と「必要な内容を確かめて受け取れる」は、同じ説明ではありません。まず、何の状態を話しているかをそろえます。

納品物

今回の依頼で、相手から受け取るものです。動く仕組み、変更したデータ、項目の説明資料など、具体的な名前と範囲を確認します。「一式」の内訳は提案ごとに尋ねます。

納品

対象のものを、決めた形で相手へ渡すことです。ファイルや利用先が届いたことと、必要な内容を確かめ終えたことを分けます。

検収

ここでは、納品物を合意した条件に照らし、受け取る判断をするための確認として説明します。何をもって手続きが完了し、どんな効果が生じるかは、実際の契約で確かめます。

受入条件・確認条件

誰が、何を用いて、どの状態を確かめるかを示す条件です。本文では、発注前に相手とそろえる候補を考えます。候補を書いた段階を、合意済みや試験済みとは扱いません。

ISTQBのテスト基礎シラバスは、受入基準を関係者が受け入れるための条件として説明し、明確で曖昧さのない記述を重視しています。本記事では、この考え方を発注前の質問へ応用します。テストの条件を整理しただけで、個別契約の検収手続きや支払条件まで決まるわけではありません。

受け取るものと、実際に使う仕事を対応させる

IT発注担当は、提案書の納品物名をそのまま一覧にする前に、業務責任者へ「何の仕事を続けるための更新か」を聞きます。この架空例では、業務担当が既存の一件を開き、変更後に必要な項目を確かめる場面を考えます。項目名や実データの値は、まだ決まっていません。

動くものと、説明する資料を分ける

変更したデータベースを受け取ることと、項目の意味を説明する資料を受け取ることは、確かめる内容が違います。動くものでは、対象の一件を開けるか、合意した項目を確認できるかを見ます。説明資料では、項目の意味や、元の一件との対応を説明できるかを見ます。資料が読めることを、実際の動作の合格へ置き換えません。

逆に、画面が一度表示されたことだけで、説明資料までそろったと判断しません。何を渡す提案なのか、受け取る場所や形式、対象に含む範囲を相手へ尋ねます。コード、設定、データの受渡し、操作説明なども案件によって必要なものが異なるため、記事に挙げた例を、そのまま契約の必須一覧にはしません。

「同じ仕事の比較」と「範囲がそろった状態」を分ける

二つの提案がどちらもデータベース更新を対象にしていても、納品物の内訳まで一致するとは限りません。後の架空例では、一方は変更したデータベースと項目の説明資料に触れ、もう一方は「更新一式」とだけ書いています。説明資料を含むかは、後者へ確認が必要です。

比較するときは、発注側が必要とする仕事と、各提案が含むものを対応させます。分からない部分を勝手に足して同じ範囲に見せず、相手の回答を得てから、比較する条件をそろえてください。

版・始めの状態・操作・期待する状態をそろえる

「使えること」「問題がないこと」だけでは、確認する人が同じ判断へたどり着けません。業務担当が何を開き、どのように確かめ、何が見えれば期待に合うかを、一つの仕事で説明します。

どの版を受け取り、何を始めの状態にするか

納品候補を区別する版の名前と、確認に使う資料の版を結びます。「最新版」という呼び方だけでは、後から別のものに入れ替わったときに追いにくくなります。誰がどの時点の候補を提示し、確認する人がどこで開くかまで、相手の回答でそろえます。

確認用の一件や利用権限、必要な資料を、誰が用意するかも聞きます。この例では「既存の一件を開く」という場面までが候補で、具体的な一件、項目、画面、確認環境は未固定です。実案件では利用してよい情報を選び、対象を取り違えない説明を添えます。

操作や資料と、期待する状態を対にする

例えば、「業務担当が既存の一件を開く」という確認方法なら、その一件のどの項目を見て、何の資料と照らすかを続けて書きます。表示された内容と元の一件の対応を説明できるか、という期待を、実際の項目と業務例で相手に具体化してもらいます。単に画面が開くことと、必要な情報が対応することは別です。

通常の場面だけでなく、情報が足りないときや、権限のない人が開こうとしたときなど、自社の仕事で問題になる場面を質問の候補にします。どの場面が今回の範囲に入るかを相談し、未実施の操作を成功した記録として残さないようにします。

確認する人・期間・不一致の返し方を決める

条件を書いても、それを確認できる人と時間がなければ、納品後に判断が止まります。発注前に、業務の内容を見る人、技術的な説明を受ける人、最終的に受け取る判断をする人を相談します。

確かめる役割と、判断できる権限を分ける

業務担当は、普段の一件と必要な項目の対応を説明できるかを確かめます。IT発注担当は、納品候補と資料の版、回答や未回答をまとめ、技術的な疑問を開発者へつなぎます。業務責任者は、必要な仕事に照らして残る問題を読み、社内で誰がどこまで判断できるかを確認します。一人が兼ねる場合も、確認した内容を分けて残します。

この役割分担は相談の考え方です。架空例で候補者が書かれていても、実際の担当が決まった、相手が了承した、という事実にはなりません。実案件では不在時の連絡先も含め、双方がその方法で進められるかを確かめます。

期間は、開始条件と終わり方を一緒に聞く

「納品後に確認する」だけでなく、何が届けば確認を始められるか、いつまでに何を返すかを聞きます。候補の版、資料、権限などが足りないときの連絡と、期間の扱いも相談します。日数だけを先に置くと、確認できる状態でないまま期限の話だけが進むことがあります。

今回の二つの案は、確認期間がどちらも未確認です。一般的な日数を埋めず、実際の契約先と社内の確認時間を照らして決めます。期限を過ぎた場合の扱い、支払いとの関係、法的な効果は、実際の原文を責任者や必要な専門家と確認してください。

一致しない箇所と、同じ条件で確かめ直す方法を残す

返す内容は「動かない」という一文だけにせず、納品候補の版、確認した一件、操作や参照資料、期待した状態と実際に分かった違いを結びます。誰がどの窓口へ知らせ、相手から何を再提示してもらい、誰が確かめ直すかを、発注前に相談します。

不一致への対応範囲や費用は、元の合意と契約で確認します。新しい要望を加えた場合と、合意した条件に合っていない場合を混ぜず、根拠となる資料を相手と確かめます。変更費用の決め方を先に整理する場合は、発注前の変更費用の確認方法も参照できます。

受け取るもの・確かめ方を、同じ項目で比べる

確認条件を書いた案には、版、確認者、資料、期待する状態、不一致の返し方の記述があります。「一式」の案では、それらは未確認です。ただし、記述のある方も、確認の期間、相手の了承、実際の結果と受け取る判断は未確認です。二つは別の架空の提案で、修正前後や実際の契約先の回答ではありません。

まず、受け取るものの内訳をそろえます。「一式」の中に項目説明の資料が入るかは、この例から分かりません。必要な資料と、どこまで説明してもらうかを両案へ尋ねます。次に、版、確かめる仕事、担当、資料、期待する状態、不一致の返し方へ同じ質問を返します。

記述があることと、条件が確定していることを分けます。条件が書かれた案でも、実際の契約先が了承し、原文にどう反映されたかの確認が必要です。一式の案で未記載の内容も、無料、対象外、無期限、検収済みとは読み替えません。

図で、納品物と確かめる仕事のつながりを追う

解説図を原寸で見る

この図を読んだ後の判断：納品物の名前だけで受け取る判断をせず、版、確かめる人と資料、期待する状態、不一致の返し方を質問にできます。IT発注担当は業務責任者と必要な条件をそろえ、相手の回答と契約原文を確認します。回答が得られた所から本文と図を同じ内容へ直し、残る不明点は未確定として残します。

回答が届いたら比較を直し、残る条件で保留する

相手から説明が届いたら、質問した納品物と業務の場面に答えているかを読みます。前の提案の資料と後の回答の期間を、根拠を区別せず組み合わせないよう、回答の版と参照先を結びます。ここからは、回答が得られた場合の見直し方で、架空例で実際に返答が届いた記録ではありません。

内訳と確認方法が分かったとき

必要な納品物と説明資料が含まれ、業務担当が確認できる方法になっているかを見ます。項目説明の資料だけの回答であれば、動く納品候補をどう確かめるかは別に聞きます。画面操作の回答だけであれば、必要な説明や記録の受渡しも確認します。

内容が具体化しても、そのまま採用を確定するのではなく、担当者が確認できるか、期間や不一致への対応がそろうか、契約原文と食い違わないかを読みます。そろった部分と残った判断を分けると、どの質問を続けるかが見えます。

期間や窓口が未回答のとき

確認できる期間や、不一致を返す相手が分からなければ、その点を未確定として残します。回答できる人と時期、決めるために必要な情報を尋ねます。返事がないことを、無期限で対応する約束や、自動的に受け取る許可へ変えません。

提案・契約原文・実際の確認結果を分ける

提案書に書かれた案、双方が合意した契約や仕様、実際に納品候補を確かめた記録は、答える問いが違います。案を作った段階では「こう確かめたい」、契約や仕様の確認では「何を引き受ける条件になったか」、実際の確認では「その版を何で確かめ、何が分かったか」を残します。

発注前は、納品物と確認条件をどの資料に置き、その資料が契約とどう結び付くかを相手に説明してもらいます。見積りの注記と仕様の記載が違う場合は、どちらを用いるかと、直す文面を確かめます。契約文の意味や支払時期、権利・責任について判断が必要なら、実際の原文で当事者の責任者や必要な専門家と確認します。

IPAのモデル取引・契約書の公開ページは、契約時に仕様やプロジェクト管理、検収方法などを双方で話し合う趣旨を説明しています。同時に、参照法規は公表時点の内容であると注意しています。本記事は、その対話を具体化する方法であり、モデルの条項を個別契約へ適用した判定ではありません。

すでに合意した条件を後から変更する場合は、旧条件と試験記録を組で残す方法で、以前の記録と次の条件を分けます。作成途中の要求資料への意見を集める段階なら、資料レビューの進め方を使い、資料を読んだ結果と動作を確かめた結果を区別します。

発注先へ聞く文面を、一つの納品物から作る

「検収条件を教えてください」とだけ伝えるより、対象の仕事と、どこまでが未確定かを添えます。次は、この架空例から作る質問の文面です。実際に送信した依頼や、合意した条件ではありません。

回答が得られたら、依頼文の対象・資料・期待する状態・担当をその回答に合わせて直します。比較表の未確認欄だけを埋めて終わらず、業務担当がその条件で確かめられるか、契約原文へ同じ内容が反映されているかを読み返します。

まとめ：何を、誰が、どう確かめるかを発注前にそろえる

発注前の検収条件は、「完成一式」という納品物名だけで決めません。受け取るものと版、確かめる仕事、資料や操作、期待する状態、担当、期間、不一致と再提示の方法を一組にし、提案と契約原文で対応を確かめます。

条件を書いた案も、実際の合意や検収結果ではありません。未記載を無料・対象外・無期限・検収済みと補わず、回答が得られた所を更新し、残る条件は確認先と次の質問を添えて保留します。