システム監査のノート

• S社：保険会社の情報システム子会社
  • ハード・ミドル、多岐にわたる運用と保守を実施
• 親会社からの費用削減を求められ要員を減らした

　　　　　　　　↓

• 要員の少なさが課題となる
• 保守起因の障害が頻発するようになる。

⇒　Ｓ社保守業務の品質確保状況を監査することとなった

[親会社]<----(調整)---->[Ｓ社]---(PJ管理)--->[外部ベンダ]
                      ・システム企画　　　　　・プログラム開発
                      ・要件定義
　　　　　　　　　　　　　｜
　　　　　　　　　　　　　｜
　　　　　　　　　　　　　＋−−−[Ｓ社開発支援Ｔ]
                                     ・開発標準
                                     ・開発/保守ツール ⇒　保守に伴う影響調査ツールがある

システム開発に携わったメンバがシステムによっては一人もいない場合がある

システム一覧
保守業務の作業標準/ツール
保守作業マニュアル	共通のマニュアルもあるが、システムごとに作成されているケースが多い
障害報告レポート	同一原因によるシステム障害が何度も発生している
設計書類	仕様書の一部が存在しないもの、設計書が最新化されていないもの、が多くみられる
引き継ぎ規程	網羅性自体には問題なし

この調査状況からＲＣＭを検討する

No.	(観点)	(想定リスク)	(コントロール)
1	影響範囲の調査面	・ドキュメントが不十分＝システムの最新状態が把握しにくい ・ドキュメントベースの調査では調査漏れを起こす	・調査用ツールでドキュメントの不備を補う ・リバースツールでソースコードから設計書を作成、不足を補う ・保守用のドキュメントを順次整備

• 影響範囲の調査報告書を査閲
  • 調査目的により範囲が違う＝指定する関連ライブラリが違うので、都度ライブラリを指定している

　　　　　　　　　　　　　　　　　　　　　　　↓

⇒　ライブラリの指定範囲に漏れや誤りがないことを別の担当者がチェックしているか、を確認する

---

No.	(観点)	(想定リスク)	(コントロール)
2	テストの実施対象の範囲	テスト範囲が不十分で不具合が残存している可能性がある	・修正箇所のテストだけでなく、修正プログラムの後続のプログラムのテストも実施する
3	障害時の対応	報告書を作成するも、障害情報を共有せず再発させる	・同様の現象による障害が発生する恐れがないか、全システムに対し調査する ・予防措置が可能なプログラムは修正する

• 障害原因と当該プログラムの対応結果のみ記載がされている。　⇒　記載項目が足りないので項目を追加すべき

障害の発生原因に応じた「他システムへの展開要否」と「展開を実施した結果」を追加する

つまり、
該当システム特有のものか、それとも他システムでもあり得ることなのかという考慮がされているか
ということがわかるようにすべき

---

No.	(観点)	(想定リスク)	(コントロール)
4	開発システムの保守担当への引き継ぎ	引き継ぎドキュメントが不十分で保守業務時にシステム状況を把握できない	・引き継ぎ規程に定めたドキュメントを作成し、保守担当者に引き渡す。 ・ドキュメント作成に必要な工数を開発時に確保する

「サンプリング」と「ヒアリング（インタビュー）」を実施する。

いくつかのドキュメントについて、引き継ぎ済のドキュメントの網羅性をチェック　（引き継ぎ規程に定められたものがそろっているか）

引き継ぎ時のドキュメントの内容確認のポイントをおさえているかを
保守作業で必要な情報がドキュメント記載内容内に網羅されていることチェックしているか