システム監査技術者 2017年 午後1 問02

　C社は、全国に営業展開している金融機関X社のシステム開発及び運用を担う子会社である。ここ数年、開発中のシステムにおいて、本番稼働前のユーザ受入テスト時に不具合が発生し、本番リリースに影響を及ぼす事態が発生している。そこで、X社の監査部が、C社におけるシステム開発の品質管理の適切性を監査することになった。 　 〔C社における品質管理の状況〕 　C社には、五つの開発部、運用部、企画部、品質管理部及び間接部門がある。 　品質管理部は、システムの設計（基本設計、詳細設計）、製造（コーディング、単体テスト）及びテスト（結合テスト、システムテスト、ユーザ受入テスト）の各工程において、品質管理基準、及びシステム開発で使用する各種の標準・規約の維持管理と、品質管理状況のモニタリングを行っている。 　各開発部では、プロジェクトごとに、プロジェクトマネージャ（PM）が品質管理基準に従って各工程の品質管理を行っている。 　 〔品質管理基準の概要〕 　監査部は、予備調査としてC社の品質管理基準について確認した。品質管理基準では、次のことが定められている。 (1) PMは、品質管理部が所管する標準・規約に従って開発を行い、各工程の品質評価を行う。品質管理部が所管する標準・規約は、表1のとおりである。 (2) PMは、品質評価結果について、次のような点を品質管理部に報告する。 　・設計工程におけるレビュー密度、指摘密度などの実績値 　・テスト工程におけるテスト密度、欠陥密度などの実績値 　・各工程で、実績値が指標値の上下20％の範囲を超えた場合の理由及び品質向上策 　なお、ここでいう“密度”とは、例えば、指摘密度については、指摘項目数を設計書ページ数で除した数値を表している。 (3) プロジェクトが中規模（10人月以上50人月未満）又は大規模（50人月以上）の場合は、品質管理部の主導で工程完了判定会議を開催する。一方、小規模（10人月未満）の場合は、品質管理部が書面で品質評価結果を審査し、工程完了判定会議は省略される。実績値が指標値の上下20%の範囲を超えた場合は、品質管理部が審査することによって、次工程への着手が認められる。 (4) プロジェクトでは、各設計工程の完了前に設計レビューを実施する。レビュー実施時間は、設計書のページ数に応じて目標が設けられている。レビューの実施結果は、レビュー記録表に記載される。 (5) 製造工程では、プログラム作成者とは別の担当者がソースコードのインスペクションを実施して、インスペクション記録表にその結果が記載される。 (6) テスト工程では、発見された不具合とその解決状況が不具合管理表に記録される。 (7) 開発中及び本番稼働後に発生した障害などの不具合については、根本原因分析を実施して再発防止を図る。根本原因分析では、障害の根本原因を分析し、対策を立案・実施し、各開発部への横展開を行う。 (8) 品質管理部は、年に1回、各プロジェクトから報告された品質評価の実績値を集計する。実績値が指標値と掛け離れている場合は、実績値の妥当性を評価して指標値を更新し、新たな指標値を各開発部に通知する。

　監査部は、本調査として、品質管理基準の運用状況を確認した。詳細設計工程及びシステムテスト工程の完了判定に関する確認結果は、次のとおりである。 　 〔詳細設計工程の完了判定に関する確認〕 (1) 昨年度に完了した50件のプロジェクトの適用状況について 　50件のプロジェクトのうち、中規模以上は21件、小規模は29件であった。中規模以上の21件のうち、詳細設計工程の指摘密度が指標値の上下20%の範囲内のものは19件であった。その中から3件をサンプリングして、レビュー記録表の内容と工程完了判定会議への提出資料とを照合して確認した結果、3件ともレビュー指摘件数に差異が見られた。PMに確認したところ、次のような回答があった。 　“詳細設計を担当したのが新人であったことから、教育も兼ねて全ての指摘をレビュー記録表に記載させたので、レビュー指摘件数が多くなった。このうち、単純ミスや標準に合致しない記述の修正指摘などは、重要性が低いと考え、品質管理部への報告書では除外した。” 　この回答を受けて、監査部は、レビュー指摘件数のカウント方法について品質管理部に問い合わせ、確認した。 (2) 指摘密度が指標値の上下20%の範囲外であった2件について 　工程完了判定会議の議事録を査閲したところ、2件とも、指摘密度は指標値の半分以下であった。その理由として、PMからの報告書には、“過去に開発したシステムで参考にできる機能が多く、設計書も流用できるものが多い”という記載があった。監査部は、品質管理部に確認し、工程完了の判定は妥当であると判断した。 (3) 昨年度の工程完了判定会議の記録、及びレビュー記録表について 　本番稼働後の障害発生が増加していることから、昨年度の中規模以上のプロジェクトにおける工程完了判定会議の記録21件を、全て調査した。その結果、詳細設計工程で作成することになっているドキュメントは全て作成され、品質評価結果の報告書についてもPM及び品質管理部の承認印があった。 　次に、(1)で抽出した3件のレビュー記録表を一覧表にして比較・検討することにした。そのために、表計算ソフトを使用して、レビューアごとの指摘区分別の指摘項目数をカウントした。 　なお、指摘区分とは、指摘の内容について、単純ミス、機能要件の理解不足、機能漏れなどに分類したものである。 　レビュー記録表には、レビュー実施日時、レビュー対象ドキュメント、ページ数、ドキュメント作成者、レビューア、レビュー観点、指摘区分、発生原因が記載されている。 　 〔システムテスト工程の完了判定に関する確認〕 　監査部は、X社ユーザ部門のT課長にユーザ受入テストの問題点についてヒアリングを行った。その結果、T課長からは、“本来はC社のシステムテストで発見されるべき不具合が、ユーザ受入テストで発見されることがある。C社でのテストケースが不足しているのではないか”という回答があった。 　そこで、監査部がシステムテスト工程の完了判定会議の記録を確認したところ、不具合が解決すればシステムテスト工程が完了したとみなし、承認されていた。監査部は、完了判定基準の項目が不十分な可能性があると考え、品質管理部にヒアリングを行った。