システム監査のノート

• C社：システム開発/運用子会社（親会社は某金融機関Ｘ社）

• 最近のトラブル
  • ユーザ受入れテスト時に不具合が多発　⇒　リリースに影響が出ている

⇒　親会社のＸ社がＣ社システム開発の品質の適切性を監査する

開発部、運用部、企画部、品質管理部、間接部門の５部門で構成

プロジェクトでは
（１）ＰＭが
システム設計（基本/詳細）、製造（コーディング/ＵＴ）、テスト（結合/システム/受け入れ）
の品質管理をする

• 品質管理は「品質管理基準」に基づいて実施

（２）品質管理部が

• 品質管理基準、規約の維持・管理
• 各フェーズのモニタリング

を実施している

• 設計フェーズ・・・レビュー密度、指摘密度を報告
• テスト・・・・・・テスト密度、欠陥密度を報告

　　　　　　↑
実績値が基準時上下２０％を超えたときはその理由と品質向上策をまとめる
⇒　その内容は品質管理部が審査している

• 中規模〜大規模　⇒　工程完了判定会議を実施する
• 小規模　⇒　品質管理部の書面審査（会議は省略）

• 工程完了前にレビュー
• 設計書のページ数に応じた目標時間
• レビュー記録表の記載

• ソースコードインスペクション＋記録表への記載

• 不具合と解決状況を不具合管理表に記載

• 根本分析をして、対策を立案・実施、横展開する

• 年１回、品質管理が集計を実施する
• 基準値と実績値がかい離している　⇒　実績値の妥当性チェックと基準値の更新

詳細設計の判定状況を調査。

• 案件数５０件
  • 21件：中規模以上
    • 2件：範囲オーバー
    • 19件：範囲内　←ここについてサンプリング調査を実施
  • 29件：小規模

３件サンプリングし
レビュー記録表と報告資料を突合せ
　　　↓
指摘件数の数値に差異有り
　　　↓
ＰＭへのインタビューを実施
「新人教育もかねてすべての指摘を記載。報告時は単純ミスや標準に合わないものは除外した」

　　　↑

この対応をしてよいのかどうか、除外が適切か不明　⇒　これではカウントが担当者によってムラがでてしまうリスクがでる

レビュー指摘件数のカウント方法について品質管理部に問い合わせる必要がある
カウントする指摘内容が明文化され、各開発部に周知されているか

ヒアリング結果＝過去の類似ＰＪの参考、流用が多かった。
　　　　　　　　　↓
これについて、実績値を基準判定外としている理由について、
品質管理部が承認しているので妥当といえる

• 中〜大規模案件全２１件をチェック
  • 設計工程のドキュメント
  • 報告書

⇒　いずれも全てＰＭ、品質管理部の承認があることを確認

• レビュアーによるレビュー観点のムラの有無、指摘区分の偏りがないかチェックする
  • 全件のレビュー記録表を一覧として比較検討する　←　比較検討なので全件チェックとする。

Ｘ社指摘内容
「Ｃ社システムテストじゃなくて、受入テストでバグが見つかる。テストケース足りないんじゃないか？」

「不具合は解決すればシステムテストは完了とみなす」と記録有り
　　　　↑
Ｘ社「判定基準項目が不足しているのではないか」

正しくは、
不具合の解決だけでなく、テスト密度などの指標の実績値が判定基準と合致しないと完了判定できない
でなければならない

つまり、監査としては

完了判定の際にテスト密度、欠陥密度についても確認して承認を行っているかチェックをする必要がある