ソフト開発監査チェックリスト（１２）検収条件管理技術
要件管理チェックリストの５つ目は検収条件です
この記事では、ソフト開発監査に使う監査チェックリストの個々の項目についての紹介をしていきます。監査チェックリストは①開発プロセス ②要件管理 ③テスト ④設計と実装 に分かれていて、この記事では②要件管理の中の構成管理の個々の項目について紹介します。（チェックリストそのものは ソフト監査実務・チェックリストその８：開発技術・要件管理（管理全般）の記事に載っていますので、そちらをご覧下さい）
検収条件ではプロセス品質とプロダクト品質を確認する納品物の有無をチェックします
ソフトの開発を他社に委託した場合、委託した開発の成果物として何が納入されるでしょうか？ 設計書、ソースコード、実行プログラムは直接的な成果物ですので、これらの納品が忘れられる事は少ないとおもいます。では、納品されたソフトの品質を保証する資料はどんな物が納品されるでしょうか？ 検査結果の報告書だけでしょうか？ XXX件のテストを行い全て合格でした、という報告書だけでソフトの品質の良し悪しを判断できるでしょうか？ なかなか難しいと思います。
ソフトの品質がそもそも判定がし難いものです。だからこそ、自社のソフトのリリース判定では、プロダクトの品質とプロセスの品質の両面について、様々な観点で情報を集めて、品質が良いか悪いかを判定しています。ですので、開発委託先から成果物としてソフトを納品してもらう時にも、そのソフトの品質を確認できる情報を一緒に納品してもらい、それらを見て十分な品質のソフトウに仕上がっているかどうかを判定する必要があります
。納品されたソフトの品質の良し悪しの判定が、成果物としてのソフトの検収です。正しく検収を行うための情報が入手できるように、要求仕様書に検収条件に関する記述が具体的に書かれている事が大切です。検収条件に関するチェック項目では、このような観点で確認をします。 それでは、項目番号は IN- で始まる4件について見ていきましょう。
【項目番号：IN-01】
ソフトウエア開発業務のどの範囲を委託していたかにもよりますが、普通は実行プログラムがソフトウエア開発業務の最終の成果物になります。開発元の我々が最終ユーザに対して品質を保証しなければならないのも、この実行プログラムの品質、つまりはプロダクト品質です。ですので、開発業務を委託した委託先からの納品物には、この実行プログラムの品質を確認するための資料が含まれている事が必要です。実行プログラムの品質の確認というと難しそうに聞こえますが、要するに十分な質と量のテストをして、潜在するバグを十分に洗い出して、見つけたバグは全部修正したか？という事が確認できれば良いのです。 その様な資料が納品物に含まれているかという点に注意して確認します。
【項目番号：IN-02】
最も大切なのは実行プログラムそのものの品質、つまりはプロダクト品質なのですが、良いプロダクト品質を達成するには良いプロセス品質が必要な事もまた事実です。いきあたりばったりでソフト開発をしても、良い品質のソフトはできません。そのような考え方から、開発委託先のソフト開発のプロセスまで踏み込んで良いソフトを開発する活動を進めるのなら、要求仕様書の成果物としてもプロセス品質の状況を確認できる情報が入っている必要性があります。そのような視点で、要求仕様書の内容を確認していきます。
【項目番号：IN-03】
プロダクト品質を確認する情報としてテストが大切な事はIN-01項にも書いてあります。この IN-01項目の内容は、最終的なテスト結果に関する情報を主体に書いてあります。ソフト開発の後半、特にデバッグフェーズに入ってからのバグの検出と修正の工程は、実はソフトのプロダクト品質を高めるために非常に大切な工程です。
この工程で、見つかったバグをどのように管理しているか、バグ管理の全ての情報を開発委託元の当社と共有してもらう事で、バグの検出と修正が正しくおなわれているのか（言い換えれば、まだまだバグが残っているのに納期が来たから打ち切られたりしていないか）を確認する事ができます。そのためには、要求仕様書にはバグ情報の当社との共有の方法について記述されている必要があります。 そのような観点で、要求仕様書を確認します。
【項目番号：IN-04】
開発委託先でも色々な種類のテストを実施して、潜在バグを見つけて修正するデバッグ工程が進みます。それらの、開発委託先の社内テストで見つかったバグの情報の中でも、既に修正されたバグの情報というのは通常は提供されません。リリースされるソフトではそのバグは既に修正されているので、バグが無いのと同じであり、無いバグについては報告しなくても良いでしょう、という考えです。
この考え事態は間違ってはいません。しかし、どの機能で多くのバグが見つかったのかという情報は、実はどの機能の品質が悪いのかを示唆するので、とても有益な情報です。そのような情報が必要な場合には、要求仕様書に明確に書いておく必要があるので、そのような観点で確認します。
検収条件の次は開発管理です
検収条件の確認の次は開発管理についての確認項目について、次の記事で紹介します。