データ査収と検証とは

査収とは、よく確かめて受け取ること。すなわち、電子メールの添付機能やファイル共有サービス、CD-R等の媒体でファイルを受け取ったとき、正しくファイルを受け取ったか、またファイルの名称と中身が一致するか、バージョンに誤りはないかなどを確かめることを意味する。検証とは、そのデータファイルの内容・構造が要件を満たすことを確認することを指す。

もっと詳しく！

大まかな流れ

納品物が納品されてから査収に至るまでの具体的プロセスは納品物により異なるが、「納品」→『受領』→『検証』→『合格』→『査収』、というのが大まかな流れとなる。「　」は作業者（＝受託者）、『　』は委託者の作業をあらわす。

『検証』の結果、納品物が合格とならなかった場合には、『不合格』→『修正依頼』→「修正」→「再納品」→『受領』→…（以下、上と同じ）というプロセスが、査収までの間に挟まることになる。このプロセスは、検証の結果が合格となるまで、何度か繰り返される可能性がある。

データの受領

「納品」→『受領』ステップで、「…ご査収のほど、よろしくお願い申し上げます。」という文句で締めくくられたメールに、なにやら圧縮されたファイルが添付されているのを見ただけで「確認しました。ありがとうございます。」という返信を出すのは絶対NG。まずは(1)圧縮ファイルは問題なく解凍できるか、(2)開いたファイルに異常はないか、(3)納品ファイルの数・名称・データ形式等が、納品書（メール）に記載されたものと一致しているか、ということを確認する必要がある。
これをクリアし、必要な納品ファイルがそろっていることを確かめた上で、『検証』ステップに進むことができる。ファイルが破損していたり、納品物の点数が足りないといった場合には、再納品を依頼する。

検証から査収まで

『検証』ステップでは、業務委託の段階で要求した仕様を納品データが満たしているか、ということを確認することになる。委託するプロジェクトの規模の大小に関わらず、作業を委託する段階で、依頼内容を文書化して保存しておけば、検証段階でチェックすべき項目のリストも作りやすく、スムーズな査収に繋げることができる。口頭や電話で依頼した内容も、文書化して残しておくという習慣は重要である。

『検証』の結果、納品物が要求した仕様を満たしていない場合には、納品物を差し戻して修正を依頼する。再納品データの検証時に留意すべき点は、「修正を実施した際に、なんらかのミスや予期せぬ影響によって、修正箇所とは別の箇所で、先祖がえりや処理エラーなどの不具合が出る」という可能性があるということである。すべてを最初からチェックしなおす必要があるのか、追加修正箇所のみのチェックで大丈夫なのか、修正方法や納品物の生成方法によっても条件が異なってくるので、一定レベルで修正にかかる工程の理解は必要である。

もうちょっと具体的に

タグ付データ(XMLなど)の場合、どのような要素をどのタグに割り当てたか、そのタグがデータ内でどの程度使用されたか、といったデータ仕様書・報告書を確認する。データ修正の場合は、前回納品データの仕様書と比較して、極端にタグ等の数量が増減していないか、変化があった場合それは追加修正指示内容からみて妥当なものか、という観点でチェックする。テキスト系データの場合、機械的な差分ファイル(diffファイルとも)の取得も容易なので、修正前/修正後のデータを比較し、データが正しく修正されているかどうかを確認する。

電子書籍フォーマットなど、オーサリング/ビルド処理を経た生成データについては、上記のような「変更されているのはここだけです！」という単純明快な差分取得は困難であり、ひと通りの動作検証(ビューワ検証)は必要になる。
もう一つ、ビルド系納品物については供されるデバイス・OSに様々さまざまなバリエーションがあり、「すべての環境で完璧に動作する」という条件では、制作も検証も現実的には無理である。『検証』対象とする環境条件またはモデルデバイスを一定の範囲で指定し、それを『査収』条件と事前に取り決めておくことが重要である。

最後に

紙の封筒を開けて中身を確認することとは異なり、電子ファイルのやり取りでは「ダウンロード時にファイルが破損してしまった」「自分のPCにインストールされているソフトでは開くことができない形式のファイルだった」等々、「納品ファイルを開いて見る」という最初のステップだけでも想定外のトラブルに見舞われることがままある。けれど、査収の判断は最終校了と同様に大きな責任を伴うもの。あとから「あの時、ちゃんと確認していれば…」と後悔しないですむように、トラブルがあってもめげることなく、十分な検証を実施した上で査収の判断をするよう心がけよう。

［永田 健児／株式会社ディジタルアシスト／20160210］