4月に受験したシステム監査技術者試験に合格しました!

「システム監査」って、システムを構築する立場から見ると、
数百の質問項目やチェックリストをもとに
どう見ても中間業務にしか見えないアンケート記入を要求する
「ウザイ」輩って印象を持っていましたが(笑)、
まあ、そういう視点から見ても優れたシステムを作らなければならないわけで、
その勉学のために、受けてみたのです。

論文は、9種類くらい事前に作成しておいて、それをベースに提出しました。
だいたい同じようなテーマの質問を選択して。

以下、ご参考のために自分の用意していた論文の一例を掲載します。
(恥ずかしいですが(#^.^#)

情報化投資効果の評価の監査について

試験問題年度/番号:2004年模試
作成年月日:2008/04/14 23:01〜

=========================================
1. 情報システムの概要と、経営/情報戦略
=========================================
1.1 情報システムの概要
 私はSI企業に所属するシステム監査人である。
大手都市銀行A行のシステム企画部は、次期市場証券基盤システムの構築を予定していた。
この基盤構築プロジェクトは、従来A行で用いられてきた開発技法を大幅に刷新し、
開発ステップ数の短縮が見込まれる最先端のオブジェクト指向開発技法を
開発フレームワークとして提供すること、加えて、システムごとに多種多様の
ベンダ製品より構成された統一性に欠けたインフラ基盤を、今後数年間に
わたって統合していく行内共通のインフラ基盤の設計・構築がミッションである。
当該プロジェクトの完了後、順次、各市場証券系システムの、
その標準システム基盤への移行が開始される。
 この標準システム基盤の信頼性・可用性・安全性に対する要求として、
障害発生時に復旧可能であることだけでなく、将来的なオンライン取引主体の
ビジネスプロセスも見据え、24時間・365日無停止で稼動するシステムでありたい、
という非常に高度な要件がA行経営新より要求されていた。そのため、地震・大災害や
テロ発生時のコンティンジェンシープランの一環としても、堅牢な災害対策システムの構築が求められた。
 企画部の、標準システム基盤の災害対策要件としては、以下が挙げられた。

(1)災害発生時の遠隔地サイトに高速に切替え、業務の継続が可能であること
(2)本番サイトから遠隔地(災対サイト)へのデータ転送が必要となるが、
本番サイトのオンライン処理への影響を最小限に抑えた同期処理であること。
(3)しかし非同期のデータ転送により、災害サイトに転送されていないデータ(以下、グレーデータ)が発生し、
災害発生後、ロールフォワードが不可能であったり、その時間がかかりすぎることがないこと。

1.2 経営/情報戦略
 経営陣の新標準システム基盤の目標は以下である。
(1)信頼性、可用性、安全性全てに優れるシステムを構築し、企業イメージを高め顧客の信頼を失わないこと。
(2)同時に開発・運用コストを削減できる効率的なシステムであること。
 銀行システムは市民インフラの一つであり、サービスの停止により、
顧客企業の倒産なども現実あるため、非常にクリティカルなシステム基盤が要求された。

=========================================
2. 情報システム投資効果の評価
=========================================
2.1 導入前の評価方法
 システム設計は、ベンダ兼SI事業を営むB社に委託された。また、A行はサイトライセンス契約を締結し、
C社のDBMSを使用し、そこに顧客情報、取引データなど重要なデータを格納している。
 遠隔地へデータ同期を行う方法としては、C社のDBMSの遠隔地データ転送機能を利用する方法と、
B社のハードウェア・ストレージの遠隔地データ転送機能を利用する方法が案が上がった。
しかし、ストレージの機能を利用する場合には、光ファイバ回線を敷設費用と、
高額なストレージ装置の購入費用、及びデータ転送量に応じて加算されるライセンス、
保守維持費用が必要となる。また、DBMSの同期機能は安価に利用できるが、
オンライン処理の遅延にダイレクトに影響する。単独案ではシステムの目標を達成不可能である。
 そのため、
(1)ミドルウェアであるDBMSの機能により、コミット済  
みのデータファイルのみ災対サイトへ非同期転送し、  
オンライン処理への影響を抑える
(2)リアルタイムのオンライントランザクションの更新  
ログの領域のみをストレージ機能で遠隔地同期転送  
する
という併用案がB社より提案された。オンライントランザクションへの負荷を
力最小限に抑えつつ、グレーデータ発生も防ぎ、かつデータ転送量を局所化し
保守維持費用も抑えられる。
 ストレージ同期機能の採用は、回線敷設費用だけでも数億の出費が予想されため、
代替案との比較検討が密に実施された。その評価のため、以下が評価基準とされた。
(1)オンライン処理への影響度
 併用案は各方式に比べオンライン処理に影響がないことを評価するため、
実機検証を実施し、TPS、スループットなどの数値を計測、比較する。
(2)グレーデータ発生比率
 各方式で様々なケースの障害発生をシミュレーションし、グレーデータの発生数を比較する。
(3)運用操作の容易性
 各方式別に運用管理が必要な項目を整理し、効率的な手順で同期処理が可能であるか比較する。
(4)災害発生時の切替・切戻手順の容易性
 各方式別に実機検証を行い、切替・切戻手順のステップ数、切替処理時間を計測する。
(5)費用対効果
 上記を総合的に評価したうえでの費用対効果を考慮し、最適な方法を選択する。
 実機検証は十分なテストケースとスケジュールを確保して行われ、
その結果プロジェクトは併用案を採用し、A行経営陣からも承認を受けた。
併用案はオンライン処理への影響度も格段に低く、切替作業時間も2分程度であった。

2.2 導入後の評価方法
 構築プロジェクトの完了後、各市場証券系システムの共通基盤への移行が開始される。
実際の業務の本番稼動開始後、導入前に行った評価基準それぞれの評価を継続的に行う必要がある。

(1)オンライン処理への影響度
 オンライン処理において処理速度低下が発生していないか、定期的に統計情報を収集し分析、評価する。
(2)グレーデータ発生比率
 随時正しくデータが遠隔地に同期されているかをDBMSとストレージ装置の転送ログで確認する。
(3)運用操作の容易性
 同期処理が運用管理において随時適切にチェックされるようになっているか確認する。
(4)災害発生時の切替・切戻手順の容易性
 災害を想定した訓練で、容易な操作が可能か確認する。
(5)費用対効果・安全に運用されているか?
 上記の適切性と実運用で発生した運用費用を照合して、費用対効果を評価する。

2.3 評価の監査の必要性
 多額の投資を行った堅牢なシステム基盤であることを客観的に評価することが必要となり、
移行開始前に利害関係の比較的少ない当社がシステム監査を担当することとなった。
各評価項目の判断が適切であり、結果として今回の情報化投資が無駄ではなく、
経営戦略、情報戦略に適合したシステムであることを保証することが、今回の監査目的である。

=========================================
3. 投資効果の評価の適切性の監査
=========================================
3.1 監査のポイント
 監査のポイントとしては以下とした。
(1)経営戦略への適合性
 新システムがA行の経営戦略、情報戦略に適合しているか? 具体的には、
経営トップが期待しているサービスレベルの範囲内での適切な設計と適切なコストを考慮しているか?
(2)コンティンジェンシープランとしての適切性
 リスクを網羅的に洗い出し、切替・切戻対策を考えているか? 
役割分担等が明確化されており、手順にも実現性があるか?
(3)システムとしての適切性
 システム全体として、可用性を確保する安全性の高いシステムになっており、
データ同期処理は本当にオンライン処理への影響がないか?
(4)運用基盤と運用体制の効率性
 データは確実に遠隔地同期されているか? 切替手順、切戻し手順が確立し、
テストが行われているか? トラブル等での運用コストは嵩んでいないか?

3.2 監査手続に関する留意点。
 それぞれの監査ポイントに関して以下を留意した。
(1)経営戦略への妥当性
 この点は何よりもまず、経営陣が経営戦略においてサービスレベルを明確化しているか
確認することが重要である。極端な話、経営陣が「半日の停止は認める」という
サービスレベルの意識であるのに、システム部門が勝手にそれ以上のサービスレベルを
設定していたのでは本末転倒である。このため長中期経営計画書を閲覧した。
そしてシステム基本設計書を査閲し、システムが目標とするサービスレベルが経営陣の
目標と合致していることを確認した。月次進捗報告会議の議事録を閲覧し、
経営陣とプロジェクトのサービスレベルの意識に温度差がないことを確認した。
(2)コンティンジェンシープランとしての適切性
 上記のサービスレベル要件に従って、災害時に最低限の切替時間を想定した設計が
システム災害対策設計で行われているか査閲した。リスク分析が網羅的に行われているか、
災害時の連絡体制を、災害対策設計書と、災害対応マニュアルを閲覧し確認した。
特にマルチベンダによるサポートのため責任分界点は明確であるかがはっきりと決まってる必要がある。
この点も災害対策設計での復旧シナリオに記述され、適切な責任分担が行われていることを確認した。
(3)システムとしての適切性
 緊急時のみならず、さまざまな障害に対する対策を行っているかも重要である。
プロジェクトはITILに則ったCFIA表を作成していたので、それを査閲し、各構成要素の二重化、
バックアップ、リカバリがシステムとして保証されていることを確認した。また、
処理に失敗した場合のフォローアップ手順等は明確であるか、運用マニュアル等を査閲し、確認した。
(4)運用基盤と運用体制の効率性
 マニュアルの整備、手順の整備、定期的な切替・切戻しテストが実施されているかを、
運用マニュアル、運用手順書、災害対策訓練実施記録で確認した。トラブル等での運用コストに
ついては運用記録、経理担当者へのインタビューにより確認した。

「私はSI企業に所属するシステム監査人である」
↑あくまでフィクションです(笑)が、昨年携わったBCP設計において
の実体験を盛り込みつつ作成しました。