平成23年度　問3　　システム開発におけるプロジェクト管理の監査について（論文集）,,,,,,,,,,, ,,,,,,,,,,, ,　今日、組織及び社会において情報システムや組込みシステムの重要性が高まるにつれ、システムに求められる品,,,,,,,,,, ,質、開発のコストや期間などに対する要求はますます厳しくなってきている。システム開発の一部を外部委託し、開,,,,,,,,,, ,発コストを低減する例も増えている。また、製品や機器の高機能化などと相まって、組込みシステムの開発作業は複,,,,,,,,,, ,雑になりつつある。,,,,,,,,,, ,　このような状況において、システム開発上のタスクや課題などを管理するプロジェクト管理はますます重要になって,,,,,,,,,, ,きている。プロジェクト管理が適時かつ適切に行われないと、開発コストの超過やスケジュールの遅延だけでなく、品,,,,,,,,,, ,質や性能が十分に確保されず、稼働後の大きなシステム障害や事故につながるおそれもある。,,,,,,,,,, ,　その一方で、開発するシステムの構成やアプリケーションの種類、開発のコストや期間などはプロジェクトごとに異,,,,,,,,,, ,なるので、プロジェクトにおいて想定されるリスクもそれぞれ異なる。したがって、システム開発におけるプロジェクト,,,,,,,,,, ,管理を監査する場合、規程やルールに準拠しているかどうかを確認するだけでは、プロジェクトごとに特有のリスク,,,,,,,,,, ,を低減するためのコントロールが機能しているかどうかを判断できないおそれがある。,,,,,,,,,, ,　システム監査人は、このような点を踏まえて、情報システムや組込みシステムの開発におけるプロジェクト管理の,,,,,,,,,, ,適切性を確かめるために、プロジェクトに特有のリスクに重点をおいた監査を行う必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが携わった情報システムや組込みシステムの概要と、そのシステム開発プロジェクトの特徴につい,,,,,,, ,,,,て、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アで述べたシステム開発のプロジェクト管理において、どのようなリスクを想定すべきか。プロジェクト,,,,,,, ,,,,の特徴を踏まえて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イで述べたリスクに対するプロジェクト管理の適切性について監査する場合、どのような監査手続が,,,,,,, ,,,,必要か。プロジェクト管理の内容と対応付けて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　情報システムや組込みシステムの重要性の高まりに伴って、システム開発におけるプロジェクト管理が失敗し,,,,,,,,, ,,た場合の影響はますます大きくなっている。また、開発手法の多様化やオフショア開発など、プロジェクト管理で,,,,,,,,, ,,対応すべき事項も増えてきている。,,,,,,,,, ,,　一方、プロジェクト管理の対象となるシステムの構成や開発の条件などは様々であるから、規程やルール通り,,,,,,,,, ,,にプロジェクト管理を行っているかどうかの準拠性の監査だけでは、プロジェクトに特有のリスクを低減するため,,,,,,,,, ,,のコントロールが機能しているかどうかを判断できないおそれがある。,,,,,,,,, ,,　本問では、情報システムや組込みシステムの開発プロジェクトにおける特徴と、プロジェクトに特有のリスクを踏,,,,,,,,, ,,まえて、プロジェクト管理の適切性を監査するための見識や能力を問う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　システム監査人には、高度化し多様化する情報技術を理解した上で、情報システムを監査する見識や能力が,,,,,,,,, ,,求められている。本年度もこうした視点から、幅広いテーマの問題を出題した。システム監査人には、発見した事,,,,,,,,, ,,実や監査意見を適切に記述するための表現力が求められるが、解答字数の下限ぎりぎりで十分に内容を表現で,,,,,,,,, ,,きない論述や、下限に満たない論述が目立った。今後、受験者の表現力の向上を期待したい。,,,,,,,,, ,,,,,,,,,,, ,,　問３（システム開発におけるプロジェクト管理の監査について）は、最も選択率が高かった。その理由は、プロジ,,,,,,,,, ,,ェクト管理という基本的なテーマであったからだと考えられる。情報システムのリスク、運用後のリスクについての,,,,,,,,, ,,論述や、プロジェクトマネージャまたはプロジェクトリーダの視点からの論述が見受けられた。設問イでは、QCD,,,,,,,,, ,,の切口での論述が多く、プロジェクトの特徴を踏まえた具体的な論述は少なかった。設問ウでは、監査のポイント,,,,,,,,, ,,だけを述べ、監査証拠を記述していない論述が目立った。また、設問で求めていない監査結果や改善提案など,,,,,,,,, ,,の論述も散見された。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　情報システムの概要及びプロジェクトの特徴,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　該当する情報システムは、電子部品を製造・販売するA社の原価管理システムである。A社では、月次決算の,,,,,,,,, ,,所要日数を6営業日から3営業日に短縮することをシステム化の目的とした原価管理システムの構築プロジェクト,,,,,,,,, ,,が立ち上がった。,,,,,,,,, ,,　原価管理システムの特性上、次の情報システムの特徴を挙げることができる。,,,,,,,,, ,,,,,,,,,,, ,,（１）システム間連携を行うシステムが多い,,,,,,,,, ,,,,,,,,,,, ,,,　具体的には、会計、購買管理、販売管理、在庫管理、生産管理などのシステムとシステム間連携を取る必,,,,,,,, ,,,要がある。,,,,,,,, ,,,,,,,,,,, ,,（２）月次決算と連携するための正確性が要求される,,,,,,,,, ,,,,,,,,,,, ,,,　バグの混入などによる品質の低下により、月次決算の正確性が損なわれ、月次決算の遅れなどの問題を引,,,,,,,, ,,,き起こす。したがって、正確性が要求されるシステムであるといえる。,,,,,,,, ,,,,,,,,,,, ,１．２　システム開発プロジェクトの特徴,,,,,,,,,, ,,,,,,,,,,, ,,　情報システムの特徴を踏まえると、次のプロジェクトの特徴を挙げることができる。,,,,,,,,, ,,,,,,,,,,, ,,（１）システム間連携テストの計画と実施が困難,,,,,,,,, ,,,,,,,,,,, ,,,　システム間連携が多いシステムでは、テスト環境を構築することも難しいなどの理由により、計画的なシステ,,,,,,,, ,,,ム間連携テストの計画の作成と的確なテストの実施が困難という特徴を挙げることができる。,,,,,,,, ,,,,,,,,,,, ,,（２）並行テスト期間の確保が必須,,,,,,,,, ,,,,,,,,,,, ,,,　正確性が要求されるという情報システムの特徴を踏まえると、現行システムと新システムの並行テスト期間,,,,,,,, ,,,を設けて、新システムの正確性を確認する必要がある。,,,,,,,, ,,,　以上の特徴を挙げることができる。,,,,,,,, ,,,,,,,,,,, ,第2章　プロジェクトの特徴を踏まえたリスク要因と想定すべきリスク,,,,,,,,,, ,２．１　プロジェクトの特徴を踏まえたリスク要因,,,,,,,,,, ,,,,,,,,,,, ,,　今回のシステム監査は、原価管理システムの構築プロジェクトにおいて、要件定義の終了後から外部設計の終,,,,,,,,, ,,了後までに改善勧告をするスケジュールである。A社のシステム監査部門のシステム監査人である私がチーフと,,,,,,,,, ,,なって、プロジェクトの特徴を踏まえたリスクマネジメントが実施されているか、プロジェクト管理の適切性について,,,,,,,,, ,,システム監査することになった。,,,,,,,,, ,,　そこで私は第三者の立場で、このプロジェクトのリスク分析を実施することにした。具体的なリスク対策を立てる,,,,,,,,, ,,必要がないことから、リスク分析は定量的リスク分析のみとした。主なリスク要因としては、次の二つがあった。,,,,,,,,, ,,,,,,,,,,, ,,（１）スケジュールに遅れが生じた場合に、システム間連携テストが十分にできない,,,,,,,,, ,,,,,,,,,,, ,,,　システム間連携テストの計画と実施が困難というプロジェクトの特徴を踏まえると、スケジュールに遅れが生,,,,,,,, ,,,じた場合に、システム間連携テストが十分にできないというリスク要因が考えられる。,,,,,,,, ,,,,,,,,,,, ,,（２）利用者部門の参画が不十分などの理由により、並行テスト期間中に十分な検証ができない,,,,,,,,, ,,,,,,,,,,, ,,,　並行テスト期間の確保が必須と言うプロジェクトの特徴を踏まえると、利用者部門の参画が不十分などの理,,,,,,,, ,,,由により、並行テスト期間中に十分な検証ができないというリスク要因が考えられる。,,,,,,,, ,,,,,,,,,,, ,２．２　想定すべきリスク,,,,,,,,,, ,,,,,,,,,,, ,,　リスク要因を踏まえ、定量的リスク分析を進めたところ、リスクの大きいことから、次の想定すべきリスクが判明,,,,,,,,, ,,した。,,,,,,,,, ,,,,,,,,,,, ,,（１）システム間連携に不整合が生じて、原価管理システムの月次処理が遅れるリスク,,,,,,,,, ,,,,,,,,,,, ,,,　スケジュールに遅れが生じた場合に、システム間連携テストが十分にできない。結果的にシステム間連携に,,,,,,,, ,,,不整合が生じ、月次決算が遅延するリスクを想定すべきと考えた。,,,,,,,, ,,,,,,,,,,, ,,（２）本稼働後にも重大なバグが残留して月次決算の正確性が損なわれるリスク,,,,,,,,, ,,,,,,,,,,, ,,,　利用者部門の参画が不十分などの理由により、並行テスト期間中に十分な検証ができない。その結果、本,,,,,,,, ,,,稼働後にも重大なバグが残留して月次決算の正確性が損なわれるリスクを想定すべきと考えた。,,,,,,,, ,,,,,,,,,,, ,第3章　プロジェクト管理の内容とプロジェクト管理の適切性の監査手続,,,,,,,,,, ,３．１　プロジェクト管理の内容,,,,,,,,,, ,,,,,,,,,,, ,,　予備調査を行った結果、リスク要因にかかわるプロジェクト管理の内容としては、次の通りである。,,,,,,,,, ,,　プロジェクトでは、進捗管理の手法としては、EVMを採用していた。そのため、スケジュールの遅延や予算超過,,,,,,,,, ,,については客観的に評価していることから、スケジュール遅延に関するリスクについては、顕在化を早めに検知,,,,,,,,, ,,する仕組みは構築、運用されていると考えることができる。,,,,,,,,, ,,　利用者部門の参画については、プロジェクト体制に利用者部門の要員も組み込まれていることから、予備調査,,,,,,,,, ,,段階では問題はないと考えることができる。,,,,,,,,, ,,,,,,,,,,, ,３．２　プロジェクト管理の適切性の監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　システム間連携に不整合が生じて、原価管理システムの月次処理が遅れるリスクに対してはEVMによる定量的,,,,,,,,, ,,でリアルタイム性の高い評価が有効に働いているかを確認する必要がある。そこで次の監査手続が必要である。,,,,,,,,, ,,,,,,,,,,, ,,（１）,,終了した要件定義段階でのEVMの評価結果とプロジェクトの実際の進捗を突合して、EVMの妥当性を評価,,,,,,, ,,,,する監査証拠を得る。,,,,,,, ,,,,　EVMでは、進捗を入力する際の基準があいまいであったり、雑であったりすると、SPIやSVの値の制度を,,,,,,, ,,,,確保できない。そのため、十分な精度があるかを確定事実と突き合わせて検証することが重要と考えた。,,,,,,, ,,,,そこで、要件定義の終了直前におけるSPIの値の動きに、帳尻合わせなどの不自然さがないことを確認し,,,,,,, ,,,,た。,,,,,,, ,,（２）,,プロジェクトの遅れの兆候を察知する方法をプロジェクトマネージャにヒアリングを行い、その結果を必要な,,,,,,, ,,,,手法を実施していることを示す監査証拠とする。,,,,,,, ,,,,　EVMによる定量的な評価は重要であるが、数値に表れた状態では手遅れという状況が考えられる。進捗,,,,,,, ,,,,の遅れの兆候を察知して、問題にならないうちに、対処することがスケジュールの遅れを予防には重要で,,,,,,, ,,,,ある。そこで、問題の兆候を察知する方法についてプロジェクトマネージャにヒアリングをして、必要な手法,,,,,,, ,,,,を実施しているかを確認した。,,,,,,, ,,,,,,,,,,, ,,（３）,,利用者部門の参画が重要な並行テスト期間中に、テストに参画する利用者部門の要員が確実にテスト資,,,,,,, ,,,,料を検証できるかを確認する。そのために、利用者部門の要員と直上監督者に作業期間、作業量、作業,,,,,,, ,,,,内容に関するヒアリングを行い、その結果を、利用者部門においてテスト資料の検証作業時間などについ,,,,,,, ,,,,て考慮されていることを示す監査証拠とする。,,,,,,, ,,,,　並行テスト期間中は、利用者部門の要員は、定常業務に加えて、検証作業を実施する必要がある。その,,,,,,, ,,,,準備が不足していると、並行テストが不十分な状況で終了することとなる。そこで利用者部門の要員におけ,,,,,,, ,,,,る準備の度合を確認する必要があると考えた。,,,,,,, ,,,,　以上がプロジェクト管理の適切性に関する監査手続である。　以上,,,,,,, ,,,,,,,,,,, 平成26年度　問1　パブリッククラウドサービスを利用する情報システムの導入に関する監査について,,,,,,,,,,, ,,,,,,,,,,, ,　今日、クラウド環境を利用する情報システムの導入事例が増えている。クラウド環境とは、サーバ仮想化、分散処,,,,,,,,,, ,理などの技術を組み合わせることによってシステム資源を効率よく利用する事ができるシステム環境のことである。,,,,,,,,,, ,クラウド環境を利用した情報システムの導入事例の中でも、インターネットを介して多数の利用者に共用のハードウ,,,,,,,,,, ,ェア資源、アプリケーションサービスなどを提供する、いわゆるパブリッククラウドサービスは、より低価格、短期間で,,,,,,,,,, ,の情報システムの導入を可能にしている。,,,,,,,,,, ,　一方で、パブリッククラウドサービスを利用する情報システムの導入に当たっては、クラウド環境に共通するリスク,,,,,,,,,, ,に加え、パブリッククラウドサービスによくみられる特徴に留意する必要がある。例えば、パブリッククラウドサービス,,,,,,,,,, ,を提供するベンダが、海外を含めて複数のデータセンタにサーバを保有している場合は、サービスを利用する側にと,,,,,,,,,, ,って、データがどこに存在するのかが分からないということも少なくない。また、パブリッククラウドサービスでは、サー,,,,,,,,,, ,ビスレベルをはじめとした契約条件を個別に締結するものではなく、あらかじめ定められた約款に基づいてサービス,,,,,,,,,, ,が提供されるものが多い。,,,,,,,,,, ,　このような状況において、システム監査人は、パブリッククラウドサービスを利用する情報システムの導入の適切,,,,,,,,,, ,性について確認する必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係する組織において導入した又は導入を検討している、パブリッククラウドサービスを利用する,,,,,,, ,,,,情報システムについて、その対象業務、パブリッククラウドサービスを利用する理由、及びそのパブリックク,,,,,,, ,,,,ラウドサービスの内容を800字以内で述べよ。,,,,,,, ,設問イ,,,設問アで述べた情報システムの導入に当たって留意すべきリスクについて、利用するパブリッククラウドサ,,,,,,, ,,,,ービス及び対象業務の特徴を踏まえて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イで述べたリスクについて、適切な対策が検討又は講じられているかどうかを確認するための監査手,,,,,,, ,,,,続を700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　今日、パブリッククラウドサービスを利用する情報システムの導入事例が増えている。その導入に当たっては、,,,,,,,,, ,,クラウド環境に共通のリスクに加え、パブリッククラウドサービスによくみられる特徴に留意する必要がある。低価,,,,,,,,, ,,格で容易に導入が可能なパブリッククラウドサービスは、利用部門が手軽に導入できることもあり、十分なリスク,,,,,,,,, ,,対策が行われていないケースも少なくない。,,,,,,,,, ,,　本問では、パブリッククラウドサービスを利用する情報システムの導入に際して、クラウド環境及びパブリックク,,,,,,,,, ,,ラウドサービスの特徴を踏まえて、システム監査人として、適切な監査を実施する能力があるかどうかを問う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問１（パブリッククラウドサービスを利用する情報システムの導入に関する監査について）は、一般的なデータセ,,,,,,,,, ,,ンタの外部委託のリスクと、その監査手続を論述している受験者が多かった。設問イでは、クラウド環境特有のリ,,,,,,,,, ,,スク及びパブリッククラウドサービスによくみられる特徴を踏まえたリスクの論述を求めているが、問題文に記述さ,,,,,,,,, ,,れている例だけを挙げている答案が目立った。また、設問ウでは、設問イで挙げたリスク対策について確認する,,,,,,,,, ,,監査手続の論述を求めているが、データセンタに対する往査など、パブリッククラウドサービスにおいては、一般,,,,,,,,, ,,的に実施が困難な監査手続を論述している受験者が散見された。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,１．パブリッククラウドサービスの対象業務、利用する理由及びそのサービス内容,,,,,,,,,, ,１．１　パブリッククラウドサービスの対象業務,,,,,,,,,, ,,,,,,,,,,, ,,　A法人は美術系の専門学校である。最近は、美術デザインだけでなく、アニメやWeb系の技術者の育成も行って,,,,,,,,, ,,いる。A法人では、従来PCサーバを利用した学校事務システムを自社で運用してきたが、システム改定に合わせ,,,,,,,,, ,,て、大手SIベンダB社が提供するパブリッククラウド型の学校事務システムに全面移行することとした。学校事務,,,,,,,,, ,,システムは、事務系システムとサービス系システムの２つのサブシステムからなり、事務系システムには学費関,,,,,,,,, ,,係、入試関係、証明書関係の業務が含まれる。サービス系システムには、履修情報管理、出欠情報管理、成績,,,,,,,,, ,,管理、学生への各種連絡などの業務が含まれる。,,,,,,,,, ,,,,,,,,,,, ,１．２　利用する理由,,,,,,,,,, ,,,,,,,,,,, ,,　従来使用していた学校事務システムは、元々オフコンで開発したシステムをPCサーバに移行したシステムであ,,,,,,,,, ,,り、ユーザインタフェースも使いにくいものとなっていた。また、最近は学生への連絡などもインターネットを活用,,,,,,,,, ,,する学校が増えており、学生サービスの観点からも業務の効率化の面からもインターネットの活用は避けて通れ,,,,,,,,, ,,ない課題となっていたが、従来のシステムでは対応が難しかった。,,,,,,,,, ,,,,,,,,,,, ,１．３　パブリッククラウドサービスの内容,,,,,,,,,, ,,,,,,,,,,, ,,　今回利用したのは、B社がクラウド上で提供している学校事務システムと、仮想デスクトップサービスである。仮,,,,,,,,, ,,想デスクトップサービスは、ユーザごとの仮想デスクトップをクラウドサーバ上に作成して、PC端末内にデータを,,,,,,,,, ,,残さない仕組みである。これにより個人情報等の機密情報の漏えいを防ぐことと情報共有を両立させることが、,,,,,,,,, ,,仮想デスクトップサービスを利用した理由の１つである。,,,,,,,,, ,,,,,,,,,,, ,２．システム導入に当たって留意すべきリスク,,,,,,,,,, ,２．１　機密情報が漏えいするリスク,,,,,,,,,, ,,,,,,,,,,, ,,　今回のパブリッククラウドサービスを利用するに際して、最も考慮したリスクは機密情報の漏洩リスクである。学,,,,,,,,, ,,校法人という事業の特性から、非常に多くの個人情報を扱う必要がある。もし、これらの情報が漏えいすることに,,,,,,,,, ,,なれば、学校法人の信頼性を大きく損なうことになる。,,,,,,,,, ,,　B社は大手のSIベンダであり、学校事務システムについても全国で60校以上の導入実績がある。その実績と企,,,,,,,,, ,,業としての信頼性を評価して、B社に委託することにしたわけであるが、そうだからと言ってリスクがないわけでは,,,,,,,,, ,,ない。特に最近B社も、データセンタの一部を海外に設置することも計画しており、本当に機密漏えいの可能性が,,,,,,,,, ,,ないと言えるかどうか検討する必要がある。,,,,,,,,, ,,,,,,,,,,, ,２．２　データ消失のリスク,,,,,,,,,, ,,,,,,,,,,, ,,　学校事務システムは、基本的にはほとんどの処理がコンピュータ上で行われているために、サーバ上のデータ,,,,,,,,, ,,が消失してしまうと、業務を継続することが不可能になり、学生にも多大な迷惑を掛けてしまうことになる。したが,,,,,,,,, ,,って、データの消失は絶対に防がなくてはいけない。,,,,,,,,, ,,　これに関しても基本的には、B社のクラウドシステムの運用環境や体制を信頼して、委託をしているわけである,,,,,,,,, ,,が、大手のサーバサービスでデータ消失を起こした例もあり、全面的に信頼してよいわけではない。本当にデータ,,,,,,,,, ,,消失の可能性がないと言えるかどうか、十分な検討が必要である。,,,,,,,,, ,,,,,,,,,,, ,２．３　サービスレベルが達成できないリスク,,,,,,,,,, ,,,,,,,,,,, ,,　新学校事務システムでは学生が直接インターネットを介して、各種の入力や照会を行う仕組みを取り入れてい,,,,,,,,, ,,る。したがって、システムが使えなくなると多くの学生が影響を受けてしまうことになる。また、障害が発生した場,,,,,,,,, ,,合にも、短時間で障害から回復され、事務に大きな影響が出ずに、学生にも大きな迷惑が掛からないことが必要,,,,,,,,, ,,である。さらに、新学期が始まった時期などは、多くの学生が履修登録を同時に行うことが予想され、多くのアク,,,,,,,,, ,,セスが集中しても、学生にとってストレスのないスピードでレスポンスが返って来る必要がある。,,,,,,,,, ,,　これらのサービスレベルに関しては、A法人の希望が全て通るわけではなく、B社が定めている利用各社共通の,,,,,,,,, ,,約款に従う必要がある。しかし、これではA法人の望むサービスレベルが達成できないリスクがあるので、これに,,,,,,,,, ,,関しても十分な検討が必要である。,,,,,,,,, ,,,,,,,,,,, ,３．適切な対策が検討又は講じられているかを確認するための監査手続,,,,,,,,,, ,３．１　機密情報漏洩リスクに関する監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　最初に、B社のサービスを選定するに際して、機密情報漏洩対策に関して、B社の対策や体制が十分であるか,,,,,,,,, ,,を、検討していたかどうかを確認する必要がある。具体的には、新システムの導入計画やシステム選定会議の,,,,,,,,, ,,議事録や補足資料から、どのような判断資料を元に検討が行われたか、また、その検討内容が十分であったか,,,,,,,,, ,,を確認する必要がある。,,,,,,,,, ,,　次に、B社のシステム内容や体制は変化していくと予想されるので、毎年定期的に機密保持の仕組みや体制に,,,,,,,,, ,,問題がないかどうかをチェックしていく必要がある。B社のような大手のSIベンダに対して、A法人が直接システム,,,,,,,,, ,,監査を行うことは現実的には不可能と考えられるので、B社のシステム監査結果の内容の一部を開示してもらい,,,,,,,,, ,,、それを元に判断を行うことになる。具体的には、B社とシステム監査結果の内容の一部を開示してもらう契約が,,,,,,,,, ,,結ばれているかどうか、B社との契約書を見て確認する。さらに、その結果をチェックする仕組みがA法人にある,,,,,,,,, ,,かどうかについて、A法人のシステム運用規約を見て確認する必要がある。,,,,,,,,, ,,,,,,,,,,, ,３．２　データ消失リスクに関する監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　データ消失リスクに関しても、基本的には機密情報漏洩リスクと同じように導入時と毎年のチェックが適切かを,,,,,,,,, ,,チェックすることになる。ただし、万が一データが消失してしまうと、その影響はA法人にとって甚大となるので、機,,,,,,,,, ,,密情報漏洩リスクに関して述べた対策に加えてデータのバックアップ状況に関する確認を追加で行う必要がある,,,,,,,,, ,,。具体的には、バックアップが定期的にとられていること、また、そのバックアップは国内のサーバのある拠点とは,,,,,,,,, ,,別の拠点で同時に被害にあう可能性がない場所に保管されていることを、B社に対するインタビューや提出資料,,,,,,,,, ,,から確認している必要がある。また、毎年のB社のシステム監査結果の中にバックアップの安全性に関する項目,,,,,,,,, ,,があるかどうかも、契約内容やB社に対するインタビューなどで確認する必要がある。,,,,,,,,, ,,,,,,,,,,, ,３．３　サービスレベル未達成リスクに関する監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　サービスレベルに関しては、最初にA法人としてどのようなサービスレベルが必要となるかが十分に検討されて,,,,,,,,, ,,いることを、新システムの導入計画やシステム選定会議の議事録や補足資料から確認する。,,,,,,,,, ,,　次にB社から提示されたサービスレベルが、A社が作成したサービスレベルと同等かそれを超えていることを確,,,,,,,,, ,,認していることを新システムの導入計画等で確認する。もし、B社から提示されたサービスレベルが不十分だった,,,,,,,,, ,,場合には、それを補う対策が取られているかも、新システムの導入計画やシステム選定会議の議事録や補足資,,,,,,,,, ,,料から確認する。,,,,,,,,, ,,　また、そのサービスレベルが継続的に達成できていることを確認することも必要である。具体的には、B社のサ,,,,,,,,, ,,ービスレベルの状況を測定する仕組みがあることをA社のシステム運用規約を見て確認する。また、その検討が,,,,,,,,, ,,実際に行われていることを毎年の運用報告で確認する。,,,,,,,,, ,,,,,,,,,,, 平成25年度　問3　ソフトウェアパッケージを利用した基幹系システムの再構築の監査について,,,,,,,,,,, ,,,,,,,,,,, ,　企業など（以下、ユーザ企業という）では、購買、製造、販売、財務などの基幹業務にかかわるシステム（以下、基,,,,,,,,,, ,幹系システムという）の再構築に当たって、ソフトウェアパッケージ（以下、パッケージという）を利用することがある。,,,,,,,,,, ,パッケージには、通常、標準化された業務プロセス、関連する規制などに対応したシステム機能が用意されているの,,,,,,,,,, ,で、短期間で再構築できるうえに、コストを削減することもできる。,,,,,,,,,, ,　その一方で、ユーザ企業の業務には固有の業務処理、例外処理があることから、パッケージに用意されている機,,,,,,,,,, ,能だけでは対応できないことが多い。このような場合、業務の一部を見直したり、パッケージベンダ又はSIベンダ（以,,,,,,,,,, ,下、ベンダ企業という）が機能を追加開発したりすることになる。しかし、追加開発が多くなると、コストの増加、稼働,,,,,,,,,, ,開始時期の遅れだけでなく、パッケージのバージョンアップ時に追加開発部分の対応が個別に必要になるなどのお,,,,,,,,,, ,それがある。,,,,,,,,,, ,　これらの問題に対するユーザ企業の重要な取り組みは、パッケージの機能が業務処理要件などをどの程度満たし,,,,,,,,,, ,ているか、ベンダ企業と協力して検証することである。また、追加開発部分も含めたシステムの運用・保守性などに,,,,,,,,,, ,も配慮して再構築する必要がある。,,,,,,,,,, ,　システム監査人は、このような点を踏まえて、パッケージを利用した基幹系システムの再構築におけるプロジェクト,,,,,,,,,, ,体制、パッケージ選定、契約、追加開発、運用・保守設計、テストなどが適切かどうかを確かめる必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係した基幹系システムの概要と、パッケージを利用して当該システムを再構築するメリット及び,,,,,,, ,,,,プロジェクト体制について、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アで述べた基幹系システムを再構築する際に、パッケージを再利用することでどのようなリスクが想定,,,,,,, ,,,,されるか。700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イで述べたリスクを踏まえて、パッケージを利用した基幹系システムの再構築の適切性を監査する場,,,,,,, ,,,,合、どのような監査手続が必要か。プロジェクト体制、パッケージ選定、契約、追加開発、運用・保守設計、,,,,,,, ,,,,テストの六つの観点から、700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　基幹系システムの再構築に当たっては、ソフトウェアパッケージを利用することで期間短縮、コスト削減などのメ,,,,,,,,, ,,リットが期待できる。しかし、基幹業務の独自性から、ソフトウェアパッケージが有する機能だけでは対応できず、,,,,,,,,, ,,業務の一部見直し、追加開発の必要性が生じることもある。追加開発が多くなると、コストの増加、稼働開始時期,,,,,,,,, ,,の遅れだけでなく、運用・保守の面で煩雑な個別対応が必要になることもある。,,,,,,,,, ,,　したがって、ユーザ企業とベンダ企業が協力してギャップ分析を行うとともに、追加開発部分を含めたシステム,,,,,,,,, ,,全体の運用・保守性なども踏まえて再構築する必要がある。,,,,,,,,, ,,　本問では、ソフトウェアパッケージの利用を前提とした基幹系システムの再構築について、その適切性を監査す,,,,,,,,, ,,るための見識や技能を問う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問３（ソフトウェアパッケージを利用した基幹系システムの再構築の監査について）は、多くの組織で検討あるい,,,,,,,,, ,,は実施しているテーマとして出題したが、設問ア及び設問イでは、パッケージの利用を前提とした再構築について,,,,,,,,, ,,の監査という出題趣旨とは関係なく、一般的な再構築のメリットやリスクについての論述が散見された。また、設,,,,,,,,, ,,問ウでは、再構築の適切性を監査する具体的な監査手続を求めているが、六つの観点からの監査項目だけを論,,,,,,,,, ,,述して監査証拠については述べていない論述や、監査実施結果についての論述が目立ち、監査手続を理解でき,,,,,,,,, ,,ていないと思われる受験者が多かった。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　基幹系システムの概要とパッケージ利用のメリット及びプロジェクト体制,,,,,,,,,, ,１．１　基幹系システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　電子部品を製造・販売するA社では、販売管理、購買管理、原価管理、在庫管理、会計管理などの基幹系シス,,,,,,,,, ,,テムをERPパッケージで再構築することが、A社経営陣により決定された。なお、工場系システムである、生産計,,,,,,,,, ,,画、生産管理について、従来通りのシステムとすることになった。これを受け、A社では基幹系システムの再構築,,,,,,,,, ,,プロジェクトが立ちあがった。私は基幹系システムの再構築の適切性をシステム監査する、A社のシステム監査,,,,,,,,, ,,部門のシステム監査人である。,,,,,,,,, ,,,,,,,,,,, ,１．２　パッケージを利用して当該システムを再構築するメリット,,,,,,,,,, ,,,,,,,,,,, ,,　A社では、システム保守費用の増大に起因するITコストの肥大化が問題となり、ITコストの削減が経営目標とし,,,,,,,,, ,,て掲げられた。これを受け、A社ではERPパッケージの導入が決定された。,,,,,,,,, ,,　第一のメリットとしては、基幹業務に関連する法規への充足のためのシステム保守費用を削減できることが挙,,,,,,,,, ,,げられた。さらに、従来通りの手法により、基幹系システムを再構築するとなると、システム間連携が複雑となり、,,,,,,,,, ,,システム開発期間が長いという問題があった。そこでERPパッケージを採用することで、第二のメリットとしては開,,,,,,,,, ,,発期間の短縮が挙げられた。,,,,,,,,, ,,,,,,,,,,, ,１．３　プロジェクト体制,,,,,,,,,, ,,,,,,,,,,, ,,　プロジェクト体制としては、プロジェクトマネージャ（以下、PMという）の下に、（１）関連する業務部門の要員で構,,,,,,,,, ,,成される業務チーム、（２）A社のシステム開発チーム、（３）ERPパッケージを提供するB社の要員で構成されるベ,,,,,,,,, ,,ンダチーム、という体制である。B社とは、すべての工程を準委任契約で業務を委託する契約とした。,,,,,,,,, ,,,,,,,,,,, ,第2章　パッケージ利用におけるリスク,,,,,,,,,, ,,,,,,,,,,, ,,　基幹系システムの再構築の適切性を監査するに当たり、リスクとリスク要因を次のように識別した。,,,,,,,,, ,,,,,,,,,,, ,,（１）標準化された業務プロセスを活用できないリスク,,,,,,,,, ,,,,,,,,,,, ,,,　標準化された業務プロセスを徹底して活用できないリスクにより、最終的に追加開発部分が肥大して、パッ,,,,,,,, ,,,ケージ導入のメリットを享受できない状況に陥る。リスク要因としては、プロジェクト体制にベンダ企業の要員,,,,,,,, ,,,が専任で入っていない、要員のスキルレベルが低い、が考えられる。,,,,,,,, ,,,,,,,,,,, ,,（２）フィットギャップ分析の結果のギャップが大きくなるリスク,,,,,,,,, ,,,,,,,,,,, ,,,　採用したパッケージを基に詳細なフィットギャップ分析を実施した結果、ギャップが想定した以上に大きいリス,,,,,,,, ,,,クがある。結果的に追加開発が肥大化する。リスク要因としては、パッケージ選定の際に、複数のパッケージ,,,,,,,, ,,,に対して、パイロット的なフィット＆ギャップ分析を実施していない、が考えられる。,,,,,,,, ,,,,,,,,,,, ,,（３）追加開発分のプログラムをA社側の都合で管理できないリスク,,,,,,,,, ,,,,,,,,,,, ,,,　追加開発したプログラムをA社側が自由に改造できないなどのリスクがある。リスク要因としては、追加開発,,,,,,,, ,,,したプログラムの著作権がA社側にあることを契約書に明記していない、が考えられる。,,,,,,,, ,,,,,,,,,,, ,,（４）優先順位の低い要件が盛り込まれるリスク,,,,,,,,, ,,,,,,,,,,, ,,,　ユーザから挙げられた要件が適切に検討されることがなく採用されるリスクがある。結果的に、追加開発分,,,,,,,, ,,,が肥大してしまう。リスク要因としては、追加開発について、開発を抑制する仕組みがない、あるいは、機能し,,,,,,,, ,,,ていない、が考えられる。,,,,,,,, ,,,,,,,,,,, ,,（５）保守性が低下して保守コストが増大するリスク,,,,,,,,, ,,,,,,,,,,, ,,,　本稼働後、パッケージのバージョンアップに工数がかかり、保守コストが想定した以上に増大するリスクがあ,,,,,,,, ,,,る。リスク要因としては、ERPパッケージのバージョンアップ時の保守性を考慮した追加開発をしていない、が,,,,,,,, ,,,考えられる。,,,,,,,, ,,,,,,,,,,, ,,（６）デグレードしてしまうリスク,,,,,,,,, ,,,,,,,,,,, ,,,　テストにおいて、追加開発分の機能テストを重視して、従来のパッケージが持つ機能に障害が発生するリス,,,,,,,, ,,,クがある。リスク要因としては、レグレッションテストを十分に実施していない、が考えられる。,,,,,,,, ,,,,,,,,,,, ,,　以上のリスクとリスク要因を踏まえて、次のような監査手続が効果的であると考えた。,,,,,,,,, ,,,,,,,,,,, ,第3章　監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　リスクやリスク要因を踏まえた監査手続は次の通りである。,,,,,,,,, ,,,,,,,,,,, ,,（１）プロジェクト体制の観点,,,,,,,,, ,,,,,,,,,,, ,,,　プロジェクト計画書を入手してプロジェクト体制を精査する。さらにPM及び各チームのリーダにベンダ企業の,,,,,,,, ,,,要員のスキルレベル、兼任か専任か、についてヒアリングを行う。その結果、ベンダ企業の要員のスキルレベ,,,,,,,, ,,,ルやプロジェクトへの参画の度合について妥当である、あるいは、妥当ではないことを示す監査証拠を得る。,,,,,,,, ,,,,,,,,,,, ,,（２）パッケージ選定の観点,,,,,,,,, ,,,,,,,,,,, ,,,　システム企画書にあるパッケージ選定に関する資料を入手する。その上で、複数のパッケージを評価した妥,,,,,,,, ,,,当な選択ではないことを示す監査証拠を得る。,,,,,,,, ,,,,,,,,,,, ,,（３）契約の観点,,,,,,,,, ,,,,,,,,,,, ,,,　A社とB社間での契約を入手して、契約内容を精査する。プログラムの著作権がA社側にあること、あるいは,,,,,,,, ,,,、B社側にあることを示す監査証拠を得る。,,,,,,,, ,,,,,,,,,,, ,,（４）追加開発の観点,,,,,,,,, ,,,,,,,,,,, ,,,　追加開発について、①標準の業務プロセスに業務をあわせる、②ギャップ部分について今後パッケージの,,,,,,,, ,,,機能追加の予定があるかを調査して対処している、③例外業務を廃止する、などの検討がされているかを、,,,,,,,, ,,,要件検討会議の議事録、ギャップの対処方法を明記した資料を入手して精査する。追加開発を抑える活動が,,,,,,,, ,,,妥当である。,,,,,,,, ,,,,,,,,,,, ,,（５）運用・保守設計の観点,,,,,,,,, ,,,,,,,,,,, ,,,　追加開発の設計書を入手して、PMやチームリーダにヒアリングを行い、ERPパッケージのバージョンアップ,,,,,,,, ,,,時の保守性を考慮した設計が行われている、あるいは、行われていない監査証拠を得る。,,,,,,,, ,,,,,,,,,,, ,,（６）テストの観点,,,,,,,,, ,,,,,,,,,,, ,,,　テスト計画書を入手して精査して、レグレッションテストを計画している、あるいは、していないことを示す監査,,,,,,,, ,,,証拠を得る。さらにテスト報告書を入手して、テスト計画書と突合して、レグレッションテストを計画して実施して,,,,,,,, ,,,いる、あるいは、していないことを示す監査証拠を得る。,,,,,,,, ,,,　以上がリスクを踏まえた監査手続である。　以上,,,,,,,, ,,,,,,,,,,, 平成23年度　問2　ベンダマネジメントの監査について,,,,,,,,,,, ,,,,,,,,,,, ,　今日、組織におけるIT利用の多用化に伴い、組織は機器やソフトウェア、及びシステムの保守や運用などの様々,,,,,,,,,, ,なサービスをベンダから調達するようになった。また、ASP、SaaSなどの普及によって、組織の各業務部門は情報シ,,,,,,,,,, ,ステム部門を介さずにサービスを利用することが容易になった。その結果、取引するベンダの数が増え、財務基盤,,,,,,,,,, ,や内部管理体制が弱いベンダと取引を行う可能性も高くなっている。,,,,,,,,,, ,　このような状況において、組織が利用するシステムやサービスの継続性、セキュリティ、品質を適切な水準に保つ,,,,,,,,,, ,ことが難しくなっている。また、ベンダ及びその製品・サービスの選定や契約が部門ごと、担当者ごとに行われると、,,,,,,,,,, ,調達費用が割高になる可能性もある。,,,,,,,,,, ,　これらの問題を解決するためには、ベンダマネジメントを組織横断的に行うことが有効である。例えば、組織共通,,,,,,,,,, ,の基準や手順に基づいて、ベンダ及びその製品・サービスの選定や契約のための評価及び導入後のモニタリングを,,,,,,,,,, ,行い、評価やモニタリングの結果を組織横断的な品質向上や経済的な調達につなげる取り組みなどが挙げられる。,,,,,,,,,, ,　システム監査人は、個々のベンダ及びその製品・サービスの調達や管理の監査に加えて、ベンダマネジメントの仕,,,,,,,,,, ,組みやその運用状況の監査を組織横断的な観点から行う必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係する組織の概要及びITにかかわるベンダマネジメントの状況について、800字以上で述べよ。,,,,,,, ,設問イ,,,設問アに関連して、組織横断的な観点からとらえたベンダマネジメントの問題点及びそれらの問題点から,,,,,,, ,,,,生じるリスクについて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問ア及び設問イに関連して、ベンダマネジメントの監査を組織横断的な観点から行う場合の監査手続に,,,,,,, ,,,,ついて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　今日、組織におけるIT利用の多用化に伴い、多くの組織がシステムの開発や運用などにかかわる製品やサー,,,,,,,,, ,,ビスを複数のベンダから調達している。,,,,,,,,, ,,　このような状況において、組織全体のシステムの品質や情報セキュリティなどを適切な水準に保つのが難しくな,,,,,,,,, ,,ってきている。したがって、ベンダ及びその製品・サービスの選定や契約のための評価、及び導入後のモニタリン,,,,,,,,, ,,グを組織横断的な基準や手順で行うとともに、その評価及びモニタリング結果を用いて、組織全体の調達や管理,,,,,,,,, ,,を効果的かつ経済的に行っていくためのベンダマネジメントが必要となる。,,,,,,,,, ,,　本問では、組織横断的な観点から行うベンダマネジメントの仕組みやその運用を監査するための知識や能力を,,,,,,,,, ,,問う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　システム監査人には、高度化し多様化する情報技術を理解した上で、情報システムを監査する見識や能力が,,,,,,,,, ,,求められている。本年度もこうした視点から、幅広いテーマの問題を出題した。システム監査人には、発見した事,,,,,,,,, ,,実や監査意見を適切に記述するための表現力が求められるが、解答字数の下限ぎりぎりで十分に内容を表現で,,,,,,,,, ,,きない論述や、下限に満たない論述が目立った。今後、受験者の表現力の向上を期待したい。,,,,,,,,, ,,,,,,,,,,, ,,　問２（ベンダマネジメントの監査について）では、組織横断的なベンダマネジメントについての問いであるにもか,,,,,,,,, ,,かわらず、個別の外部委託の管理についての論述が多かった。また、設問イでは、組織体制や管理の不備など,,,,,,,,, ,,のベンダマネジメントの問題点について問うているが、”管理するベンダが多い”、”コストが高くなっている”などの,,,,,,,,, ,,事象を挙げているだけの論述も目立った。設問ウの監査手続については、”インタビューを行う”、”文書を閲覧す,,,,,,,,, ,,る”などの簡易な論述が多く、より証拠能力を高めるための具体的な監査手続を記述している論述は非常に少な,,,,,,,,, ,,かった。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　S社の概要及びベンダマネジメントの状況,,,,,,,,,, ,１－１　S社の概要,,,,,,,,,, ,,,,,,,,,,, ,,　私が今回監査したS社は、情報システム開発を主な業務とするソフトウェア会社で、SEが所属するシステム部門,,,,,,,,, ,,が4部門とスタッフ部門からなり、スタッフ部門に情報システム部がある。,,,,,,,,, ,,　情報システム部は、全社共用及びスタッフ部門専用に使用する情報システムの企画、開発、運用及び保守を担,,,,,,,,, ,,当している。また、社内ネットワーク運用、社外ネットワーク接続管理、及び全社の情報セキュリティ管理も担当し,,,,,,,,, ,,ている。システム部門は、受注した顧客向けプロジェクトにおいて利用する情報システムを個別に運用している。,,,,,,,,, ,,,,,,,,,,, ,１－２　ベンダマネジメントの状況,,,,,,,,,, ,,,,,,,,,,, ,,（１）S社のIT企業戦略,,,,,,,,, ,,,,,,,,,,, ,,,　S社は、IT企業戦略として次の二つの方針を定めている。一つ目は、原価償却が必要なIT資産をできるだけ,,,,,,,, ,,,持たずに、顧客向け情報システム開発の原価を低減することである。二つ目は、常に最新の技術動向を習得,,,,,,,, ,,,することにより、技術スキルを向上して高い競争力を維持することである。,,,,,,,, ,,,,,,,,,,, ,,（２）ベンダマネジメントの現状,,,,,,,,, ,,,,,,,,,,, ,,,　S社は、IT企業戦略を受けてサーバ系機器を自社導入せずにIaaSの利用を前提として情報システムを利用,,,,,,,, ,,,している。さらに、新たに利用したいアプリケーションがある場合、積極的にSaaSを利用している。上記のよう,,,,,,,, ,,,なベンダの製品・サービスを利用する場合、S社は、委託先選定基準によりベンダ選定を行っている。また、,,,,,,,, ,,,委託先評価基準によりベンダを定期的に再評価している。ただし、各基準がソフトウェアの外部委託開発用の,,,,,,,, ,,,内容から改版を重ねた内容の基準となっていた。,,,,,,,, ,,,,,,,,,,, ,第2章　ベンダマネジメントの問題点及びリスク,,,,,,,,,, ,,,,,,,,,,, ,,　S社に関して、組織横断的な観点からとらえたベンダマネジメントの問題点及びそれらの問題点から生じるリス,,,,,,,,, ,,クについて述べる。,,,,,,,,, ,,,,,,,,,,, ,２－１　ベンダマネジメントの問題点,,,,,,,,,, ,,,,,,,,,,, ,,　S社には主に三つの問題点があった。,,,,,,,,, ,,,,,,,,,,, ,,（１）ベンダ管理基準の不備,,,,,,,,, ,,,,,,,,,,, ,,,　S社は、委託先選定基準と委託先評価基準の二つのベンダ管理基準に基づいてベンダを管理している。し,,,,,,,, ,,,かし、ベンダ管理基準の内容は、ソフトウェア開発委託が基本で、ベンダ利用形態の変化に対応しきれていな,,,,,,,, ,,,い。例えば、仮想マシンを利用したASP、SaaSなどの製品・サービス形態に適合していなかった。,,,,,,,, ,,,,,,,,,,, ,,（２）ベンダ選定に関する全社管理不足,,,,,,,,, ,,,,,,,,,,, ,,,　システム部門では、S社が受注した顧客向けプロジェクトの原価低減及び品質向上目的で、IaaSやグループ,,,,,,,, ,,,ウェアのSaaS等のベンダの製品・サービスを随時に利用している。採用に際しては、最新技術習得とプロジェ,,,,,,,, ,,,クト費用の低減の観点でプロジェクト責任者によって導入ベンダ候補を選定していることが多い。その結果、S,,,,,,,, ,,,社内には類似機能の製品・サービスが混在していた。,,,,,,,, ,,,,,,,,,,, ,,（３）ベンダに起因する不具合等の改善不足,,,,,,,,, ,,,,,,,,,,, ,,,　一部のシステム部門は、データ消失、システム停止及びサービス停止といったベンダの製品・サービス利用,,,,,,,, ,,,により発生した不具合を経験していた。しかし、その不具合情報と改善策が発生部門内又は発生プロジェクト,,,,,,,, ,,,内に留まっていた。,,,,,,,, ,,,,,,,,,,, ,２－２　２－１の問題点から生じるリスク,,,,,,,,,, ,,,,,,,,,,, ,,（１）ベンダ管理基準の不備から生じるリスク,,,,,,,,, ,,,,,,,,,,, ,,,　S社は、現状に合わない不備のあるベンダ管理基準によりベンダを選定していた。そのため、ベンダが仮想,,,,,,,, ,,,マシン等の設備でサービスを提供している場合のセキュリティリスク、性能保証等の規定が現状に合わず不,,,,,,,, ,,,備なベンダを選定する信頼性リスク及びセキュリティリスクがあった。また、規定に仮想マシン使用前提のコス,,,,,,,, ,,,ト評価比較項目がなく、コストリスクがあった。また、サービスを提供するベンダが倒産した場合の規定がなく,,,,,,,, ,,,継続性リスクがあった。,,,,,,,, ,,,,,,,,,,, ,,（２）類似機能の製品・サービス混在から生じるリスク,,,,,,,,, ,,,,,,,,,,, ,,,　システム部門が利用する製品・サービスでは、類似機能のグループウェアを複数使用していたため、調達費,,,,,,,, ,,,用に関するコストリスクがあった。,,,,,,,, ,,,,,,,,,,, ,,（３）不具合の再発防止不全から生じるリスク,,,,,,,,, ,,,,,,,,,,, ,,,　一部のシステム部門がベンダの製品・サービス利用で発生した不具合に関する情報及びその対処結果や,,,,,,,, ,,,改善策を、全社的に再発防止に結びつけていなかった。そのため、データ消失、システム停止及びサービス,,,,,,,, ,,,停止等の同様な不具合を他部門でも発生させる品質のリスク、及び継続性リスクがあった。,,,,,,,, ,,,,,,,,,,, ,第3章　ベンダマネジメントの監査を組織横断的な観点から行う場合の監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　監査人は、監査対象組織が持つ組織横断的なベンダマネジメントに関するコントロールの整備状況の有効性と,,,,,,,,, ,,運用状況の有効性の評価を行う。,,,,,,,,, ,,,,,,,,,,, ,３－１　ベンダマネジメントのコントロールの整備状況の有効性の評価,,,,,,,,,, ,,,,,,,,,,, ,,（１）ベンダマネジメントに関するリスクコントロールマトリックスの準備,,,,,,,,, ,,,,,,,,,,, ,,,　監査人は、まず監査対象組織の組織横断的な観点から行うベンダマネジメントに関して、リスク分析と対応,,,,,,,, ,,,するコントロールを事前に整理する。ベンダマネジメントを一つのプロセスとして、例えば、企画、ベンダ選定、,,,,,,,, ,,,経営決裁、契約、導入、運用管理、及び定期評価（利用継続、利用終了または乗り換え）といったベンダ利用,,,,,,,, ,,,のサブプロセスごとにリスクを洗い出し、リスクごとに想定されるコントロールを確認し、監査用のリスクコントロ,,,,,,,, ,,,ールマトリックスを作成する。,,,,,,,, ,,,,,,,,,,, ,,（２）監査対象組織のリスク分析の評価,,,,,,,,, ,,,,,,,,,,, ,,,　監査人は、準備したリスクコントロールマトリックスを使用して監査対象組織が認識しているリスクに不足が,,,,,,,, ,,,ないかを評価する。ベンダの財務基盤の脆弱性リスク、ベンダ内部管理体制の脆弱性リスクごとのIaaSやSaa,,,,,,,, ,,,Sのリスクが考慮されているか、ベンダ管理基準等の規定類により確認する。,,,,,,,, ,,,,,,,,,,, ,,（３）コントロールの整備状況の有効性の評価,,,,,,,,, ,,,,,,,,,,, ,,,　監査人は、リスクに対するコントロールが整備されているか及び内容がコントロールの目的を満たしているか,,,,,,,, ,,,確認する。例えば、ベンダ管理基準等の規定類において企画段階の比較調査検討項目、契約時に締結する,,,,,,,, ,,,SLAの必須項目、及び定期評価実施項目等を確認する。その際上記の規定項目等により組織全体で定めて,,,,,,,, ,,,いる情報セキュリティや個人情報保護の水準を満たし、費用の無駄を排除する等のコントロールの目的を満,,,,,,,, ,,,たしているか評価する。,,,,,,,, ,,,,,,,,,,, ,３－２　ベンダマネジメントのコントロールの運用状況の有効性の評価,,,,,,,,,, ,,,,,,,,,,, ,,（１）実際のベンダ利用事例の評価,,,,,,,,, ,,,,,,,,,,, ,,,　監査人は、監査対象組織が、ベンダ管理基準等に定めたコントロールを順守してベンダマネジメントを運用し,,,,,,,, ,,,ているか、実際のベンダの製品・サービス利用によって作成された起案書、契約書、SLA、及び定期評価報告,,,,,,,, ,,,書等により評価する。特に、類似したベンダの製品・サービスの利用がある場合は、採用決定時の比較選定,,,,,,,, ,,,内容を詳しく評価する。,,,,,,,, ,,,,,,,,,,, ,,（２）不具合発生等に関する評価,,,,,,,,, ,,,,,,,,,,, ,,,　監査人は、ベンダの製品・サービス利用において、データ消失、システム停止及びサービス停止等の不具合,,,,,,,, ,,,が実際に発生していた場合には、定めたコントロールの通りに不具合対処及び再発防止等が実施されている,,,,,,,, ,,,か、不具合対処及び再発防止等が実施されているか、不具合報告書等により評価する。　以上,,,,,,,, ,,,,,,,,,,, 平成22年度　問3　IT保守・運用コスト削減計画の監査について,,,,,,,,,,, ,,,,,,,,,,, ,　景気変動が激しく、国際競争が厳しい経営環境において、無駄なコストを減らして収益性を高めることは、組織にと,,,,,,,,,, ,って重要な経営課題の一つである。ITは、今日の経営に不可欠なものである一方で、そのコストは年々増加傾向に,,,,,,,,,, ,ある。組織が全社的にコストを抑制していく中で、ITコストについても削減に向けた適切な取り組みが必要になってい,,,,,,,,,, ,る。,,,,,,,,,, ,　ITコストは、ハードウェア、ネットワークなどのインフラ構築や業務システムの開発などの導入コストと、構築したシ,,,,,,,,,, ,ステムを維持するための保守・運用コストに分けられる。導入コストは当初だけ発生するのに対して、保守・運用コス,,,,,,,,,, ,トはその情報システムが廃棄されるまで継続的に発生する。したがって、ITコストの削減においては、保守・運用コス,,,,,,,,,, ,トをいかに削減するかが重要なポイントになる。,,,,,,,,,, ,　しかし、IT保守・運用コストの削減がシステム障害、情報漏洩、利用者の満足度低下、及びIT部門の技術力・管理,,,,,,,,,, ,能力の低下につながることがある。また、取組の結果、削減額や削減達成時間などの当初目標を達成できないこと,,,,,,,,,, ,もある。,,,,,,,,,, ,　システム監査人は、IT保守・運用コスト削減計画の策定・実行プロセスについて監査するだけでなく、削減によって,,,,,,,,,, ,生じるリスク、将来的な影響、目標達成の可能性など、削減計画の内容の妥当性についても監査する必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係した組織や業務におけるIT保守・運用コスト削減の取組の概要について、削減対象及び対象,,,,,,, ,,,,とされた理由を含め、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アに関連して、削減計画の内容の妥当性を監査する場合の監査項目について、監査項目とした理由,,,,,,, ,,,,を含め、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イに関連して、監査で発見された問題点とその改善案について、700字以上1400字以内で具体的に述,,,,,,, ,,,,べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　今日、多くの組織がITコストの削減に取り組んでいるが、コスト削減額ありきで、削減に伴うリスクや将来的な影,,,,,,,,, ,,響について十分な検討が行われていない場合もある。その結果、コスト削減がシステム障害、情報漏洩、IT部門,,,,,,,,, ,,の技術力・能力低下などにつながることも少なくない。したがって、ITコストの削減にかかわる監査では、削減目,,,,,,,,, ,,標の達成可能性、削減対象範囲や手法の適切性などの削減計画の実効性の評価に加え、削減計画の実施に,,,,,,,,, ,,伴って発生するセキュリティやサービスレベルの低下などのリスクについても評価することが必要である。,,,,,,,,, ,,　本問では、システム監査人として、ITコスト削減計画の実効性やリスクについて評価し、計画の実現に向けての,,,,,,,,, ,,問題点や改善案を提示するための知識や能力を有しているかを評価する。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　高度化・多様化する情報技術に対応できるシステム監査人を育成するという観点に基づいて、情報技術につい,,,,,,,,, ,,て広く深い理解を求めるテーマを出題した。そのため、各テーマについての実務経験を有していない受験者にと,,,,,,,,, ,,っては、難しい問題になったと思われる。,,,,,,,,, ,,　すべての問いにおいて、論述内容が一般的で具体的な記述まで至ってないものが多かった。,,,,,,,,, ,,,,,,,,,,, ,,　問３（IT保守・運用コスト削減計画の監査について）は、全社的なIT保守・運用コストの削減計画を対象にした論,,,,,,,,, ,,述と、個別システムの保守・運用コストの削減への取組を対象にした論述に分かれた。後者については、システ,,,,,,,,, ,,ム構築などにおける一般的な監査項目を記述している論述が目立った。また、削減計画の妥当性を評価するた,,,,,,,,, ,,めの監査項目として、削減計画を実施した場合のリスクを評価するための監査項目だけを挙げている論述が多く,,,,,,,,, ,,、削減額の実現可能性や削減の範囲・方法の妥当性を評価するための監査項目を挙げている論述は少なかっ,,,,,,,,, ,,た。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　IT保守・運用コスト削減の取組の概要,,,,,,,,,, ,,,,,,,,,,, ,,　情報サービス業のA社では、主要顧客の経営の悪化によって、1年間でITコストの削減20％の経営目標を決定,,,,,,,,, ,,した。そこでITコストを構成する導入コストと保守・運用コストのうち、継続的に発生する保守・運用コストの削減が,,,,,,,,, ,,ポイントになった。,,,,,,,,, ,,　A社では12のビジネス拠点ごとに、サービスデスクを設置して、ユーザへのITサービスを提供するローカルサー,,,,,,,,, ,,ビスデスクの形態を採用していた。これによって、ユーザ拠点に設置したサービスデスクが各拠点のユーザに対,,,,,,,,, ,,してサービスを提供することで、ビジネス拠点の特性に応じたサポートをオンサイトで実現していた。反面、分散し,,,,,,,,, ,,ているため保守・運用コスト面で問題となっていた。そこで削減対象の一つとして、サービスデスク費用を設定し,,,,,,,,, ,,てIT保守・運用コスト削減の取組を実施することになった。対象とした理由としては、保守・運用コストの70％を占,,,,,,,,, ,,め削減効果が大きいからである。削減目標としては他社の事例を参考にして30％削減を設定した。,,,,,,,,, ,,　取組方法は、ローカルサービスデスクから中央サービスデスクへ移行するサービスデスクの再編成である。1か,,,,,,,,, ,,所に集約した中央サービスデスクが複数のビジネス拠点に対してサービスを提供する。このリソースの集約によ,,,,,,,,, ,,って運用コストの削減が可能となる。ただし、ユーザの利便性が低下するため、テレビ電話によるサポートなど、,,,,,,,,, ,,ビジネス拠点の業務特性に応じた施策をIT保守・運用コスト削減計画に盛り込んでいた。,,,,,,,,, ,,　私は、A社のシステム監査部門の業務として、IT保守・運用コスト削減計画のうち、サービスデスク費用の削減,,,,,,,,, ,,について次のような監査項目を設定して監査手続を実施して、監査証拠を得て問題点を整理し改善策を提言し,,,,,,,,, ,,た。,,,,,,,,, ,,,,,,,,,,, ,第2章　削減計画の内容の妥当性を監査する場合の監査項目,,,,,,,,,, ,,,,,,,,,,, ,,　A社において、1年間でITコストの削減20％という経営目標を達成するために、計画から目標達成の評価まで、,,,,,,,,, ,,短期間で実施しなければならない。少なくとも、9か月間でプロジェクトを終了して評価期間に入る必要があると考,,,,,,,,, ,,えた。そこで、短期プロジェクトという点を踏まえて、削減計画の策定や実行のみならず、実行後のリスクに対する,,,,,,,,, ,,監査項目が、計画実施におけるリスク対策、計画実施の将来的な影響、目標達成までの妥当性を監査範囲とし,,,,,,,,, ,,て監査する必要がある。なぜならば、短期ゆえにリスク評価が甘く、大きなリスクを見逃すことがあるからである。,,,,,,,,, ,,そこで次の監査項目を設定した。,,,,,,,,, ,,,,,,,,,,, ,,①削減計画の策定プロセスに関する監査項目,,,,,,,,, ,,,,,,,,,,, ,,,　削減計画に盛り込んでいる目標額の達成によって、経営目標を達成できるか、という監査項目が重要である,,,,,,,, ,,,。監査項目とした理由は、削減目標を達成したとしても、経営目標が達成できないのでは、計画の意味がなく,,,,,,,, ,,,なる。そこで、経営目標の削減目標値と評価期間と、削減計画によって削減できる目標値と評価期間との整,,,,,,,, ,,,合性を、確認する必要がある。,,,,,,,, ,,,,,,,,,,, ,,②削減計画の実行プロセスに関する監査項目,,,,,,,,, ,,,,,,,,,,, ,,,　中央サービスデスクの業務委託先の選定において、委託費用のみならず、委託先の評価も削減計画には,,,,,,,, ,,,含めているか、という監査項目が重要であると考えた。監査項目とした理由は、コスト削減で金額重視になる,,,,,,,, ,,,傾向があるが、サービスデスクのサービスレベルの低下は、A社における生産性の低下に大きく影響すると考,,,,,,,, ,,,えたからである。,,,,,,,, ,,,,,,,,,,, ,,③削減計画を実施した場合のリスク対策に関する監査項目,,,,,,,,, ,,,,,,,,,,, ,,,　ローカルから中央ヘルプデスクを移行するために生じるサービスレベルの低下に対して、ビジネス拠点の特,,,,,,,, ,,,性を踏まえた改善策を削減計画では講じているか、という監査項目が重要である。監査項目とした理由は、コ,,,,,,,, ,,,スト削減に注力してしまうがゆえに、サービスレベルの低下を軽視する傾向があるからである。,,,,,,,, ,,,,,,,,,,, ,,④将来的な影響に関する監査項目,,,,,,,,, ,,,,,,,,,,, ,,,　サービスデスクに関わる技術的な蓄積を行う仕組みが削減計画に盛り込まれているか、という監査項目が,,,,,,,, ,,,重要である。監査項目とした理由は、中央サービスデスクをアウトソーシングすると自社にサービスデスクに,,,,,,,, ,,,かかわる技術を蓄積できず、IT部門の技術力の低下につながると考えたからである。,,,,,,,, ,,,,,,,,,,, ,,⑤目標達成の可能性に関する監査項目,,,,,,,,, ,,,,,,,,,,, ,,,　削減計画は計画の実施完了後に行われる評価フェーズまでに、実際の支払額の減少という形で効果が表,,,,,,,, ,,,面化するか、という監査項目が重要である。監査項目とした理由は、経営目標の達成として財務諸表に結果,,,,,,,, ,,,が現れなければならないと考えたからである。,,,,,,,, ,,,,,,,,,,, ,,　以上の監査項目を基に監査手続を設定して監査証拠を得て、監査証拠の評価の結果、次の問題点を発見する,,,,,,,,, ,,ことができた。,,,,,,,,, ,,,,,,,,,,, ,第3章　監査で発見した問題点と改善策,,,,,,,,,, ,,,,,,,,,,, ,,　削減計画を実施した場合のリスク対策に関する監査項目から発見した問題点は次の①であり、将来的な影響,,,,,,,,, ,,に関する監査項目から発見した問題点は次の②である。,,,,,,,,, ,,,,,,,,,,, ,,①,インシデント管理におけるITサービス復旧時間の悪化によるシステムの可用性の低下と利用者の満足度の低,,,,,,,, ,,,下,,,,,,,, ,,,,,,,,,,, ,,,　中央サービスデスクに集約するため、ビジネス拠点に特化したサポートが不足していた。そこでインシデント,,,,,,,, ,,,の発生時にサービスデスクへの通報から回避策の実施までに、時間がかかり、ITサービス復旧時間の悪化,,,,,,,, ,,,によってシステムの可用性が低下するという問題点があった。,,,,,,,, ,,,,,,,,,,, ,,②,サービスデスクのアウトソーシングに起因するIT部門の技術力の低下,,,,,,,, ,,,,,,,,,,, ,,,　サービスデスクのアウトソーシングを実施すると、A社のITサービス部門に関連する技術の蓄積がなくなると,,,,,,,, ,,,いう状況に陥りやすい。その結果、A社のIT部門の技術力が低下するという問題点があった。,,,,,,,, ,,,,,,,,,,, ,,　以上の問題点に対して次の改善策の提言を行った。,,,,,,,,, ,,　システムの可用性の低下と利用者の満足度の低下という問題点に対してテレビ電話の設置という改善策を提,,,,,,,,, ,,言した。,,,,,,,,, ,,　テレビ電話を利用できる共有携帯電話をビジネス拠点に設置して、インシデントが発生したときに、ヘルプデス,,,,,,,,, ,,クの要員が画像データを見ながら回避策を講じることができるように提言した。なぜならば、インシデントの状況を,,,,,,,,, ,,視覚的にも伝えることでビジネス拠点に特化したサポートを推進できると考えたからである。,,,,,,,,, ,,　IT部門の技術力の低下という問題点に対しては、サービスデスクで蓄積した技術をITサービス部門やユーザ部,,,,,,,,, ,,門で共有できるようにエンタープライズサーチの仕組みを導入するように提言した。これによって、アウトソーシン,,,,,,,,, ,,グ先、IT部門、ユーザ部門間で、技術やノウハウの共有化を推進し、それがユーザ間での相互啓発にもつながり,,,,,,,,, ,,、技術力の低下を予防できると考えたからである。　以上,,,,,,,,, ,,,,,,,,,,, 平成21年度　問3　企画・開発段階における情報システムの信頼性確保に関するシステム監査について,,,,,,,,,,, ,,,,,,,,,,, ,　組織が業務やサービス提供などをより効果的かつ効率よく行う上で、情報システムの果たす役割はますます広が,,,,,,,,,, ,ってきている。その結果、情報システムの不具合や障害による業務・サービスの停止や機能低下の影響度は大きく,,,,,,,,,, ,なり、社会問題にまで発展するおそれもある。このような状況から、情報システムに対する信頼性確保の要請が高ま,,,,,,,,,, ,っている。,,,,,,,,,, ,　企画・開発段階における情報システムの信頼性確保とは、情報システムが期待通りの機能やサービスを提供でき,,,,,,,,,, ,るように、設計・構築することをいう。そのためには、情報システムの不具合や障害などを未然に防止し、万が一、発,,,,,,,,,, ,生した場合にも影響範囲を最小限に抑えるためのハードウェアやアプリケーション、ネットワークなどのIT環境を構,,,,,,,,,, ,築することが重要となる。,,,,,,,,,, ,　また、情報システムに求められる信頼性の水準は、業務やサービス提供などの重要度、情報システムの不具合や,,,,,,,,,, ,障害による影響度などによって異なる。例えば、決裁システムと人事システムとでは、ディスク障害によって業務が,,,,,,,,,, ,中断した場合の影響度や範囲に違いがあるので、それぞれの対応策は異なってくる。,,,,,,,,,, ,　このような点を踏まえて、システム監査人は、企画・開発段階における情報システムの監査において、当該情報シ,,,,,,,,,, ,ステムの信頼性が確保されていることを確かめなければならない。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係した情報システムの概要と、業務やサービス提供において、当該情報システムに求められる,,,,,,, ,,,,信頼性について、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アで述べた情報システムの信頼性を確保するに当たり、企画・開発段階においてどのようなリスクと対,,,,,,, ,,,,応策を想定したか。関連する業務やサービス提供の重要度及び情報システムへの影響度を含め、700字,,,,,,, ,,,,以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イで想定したリスクと対応策に対して、どのような点に留意して監査すべきか。IT環境の特徴などを踏,,,,,,, ,,,,まえて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　情報システムに不具合や障害などが発生した場合における業務・サービスの停止や機能低下の影響度が大き,,,,,,,,, ,,くなっていることから、情報システムに対する信頼性確保の要請が高まっている。情報システムの信頼性確保に,,,,,,,,, ,,おいては、業務やサービス提供などの重要度、当該情報システムの不具合や障害による影響度などを考慮しな,,,,,,,,, ,,ければならない。,,,,,,,,, ,,　本問では、システム監査人として、IT環境の特徴を踏まえた情報システムの信頼性確保を確かめるため、リスク,,,,,,,,, ,,と対応策を想定しながら企画・開発段階における監査を実施する知識や能力があるかどうかを評価する。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　全体として、一般論を展開しただけの論述が目立った。出題趣旨から大きく外れたり、問題文を言い換えただけ,,,,,,,,, ,,だったりした論述は論外としても、設問の趣旨を十分に理解し、受験者自らの経験や考えを反映するように心掛,,,,,,,,, ,,けてもらいたい。また、論述内容の意味のない重複、不要な空行、専門用語の誤りなどがないように注意してもら,,,,,,,,, ,,いたい。,,,,,,,,, ,,,,,,,,,,, ,,　問３（企画・開発段階における情報システムの信頼性確保に関するシステム監査について）は、オーソドックスな,,,,,,,,, ,,テーマであることから最も選択率が高かった。しかし、運用段階における監査についての論述や、プロジェクト管,,,,,,,,, ,,理、個人情報漏洩対策についての論述など、設問の趣旨から外れた回答が目立った。設問イ、ウでは、設問アで,,,,,,,,, ,,述べた情報システムとの関係を踏まえずに、一般的な内容にとどまった論述が多かった。設問ウでは監査実施,,,,,,,,, ,,上の留意点についての論述を求めたが、監査手続だけの論述も多く見受けられた。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　情報システムの概要と求められた信頼性,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　ゲームソフトを制作・販売するA社では、ゲームソフトのパッケージングに標準小売価格の2割ほどのコストを掛,,,,,,,,, ,,けていた。そこでA社ではWebを利用したダウンロードによるゲームの販売を強化して、ゲームパッケージのコスト,,,,,,,,, ,,ダウンを図るWeb販売システムを再構築することにした。,,,,,,,,, ,,　ゲームソフトの販売については、業界トップクラスの競合他社がWeb上で販売展開をしている、ゲームの販売開,,,,,,,,, ,,始時にピークが来る、という業務の特徴があった。したがって、（１）競争力を確保するために頻繁に新サービスを,,,,,,,,, ,,リリースする、（２）新商品のリリース直後はアクセスが集中してネットワークやサーバの負荷が高い、というサー,,,,,,,,, ,,ビス提供の特徴があった。,,,,,,,,, ,,,,,,,,,,, ,１．２　情報システムに求められた信頼性,,,,,,,,,, ,,,,,,,,,,, ,,　A社の顧客には、ネットワーク上の掲示板などで情報を交換するために新製品の販売時に誰よりも早くゲーム,,,,,,,,, ,,を手に入れたいという願望がある。入手が遅れた場合、購買意欲が低下して販売機会を失いかねない。そこで新,,,,,,,,, ,,製品の販売時が特に重視され、次の三つが信頼性要件として定義された。,,,,,,,,, ,,,,,,,,,,, ,,,（１）,,ソフトウェアのバグによるアプリケーション障害が発生しないこと,,,,,, ,,,（２）,,アクセスが集中しても性能要件を満足すること,,,,,, ,,,（３）,,万が一、障害が発生しても縮退運転によってサービスを継続できること,,,,,, ,,,,,,,,,,, ,,　私はA社内部のシステム監査人の立場で、IT環境を踏まえて、Web販売システムにおけるリスクと、リスク対応,,,,,,,,, ,,策に対する監査の留意点について、次に述べる。,,,,,,,,, ,,,,,,,,,,, ,第2章　想定したリスクと対応策,,,,,,,,,, ,２．１　想定したリスク,,,,,,,,,, ,,,,,,,,,,, ,,　頻繁に新サービスをリリースするというサービス提供の特徴を踏まえると、ソフトウェアが頻繁に改変されるため,,,,,,,,, ,,バグが混入する可能性が高いという脆弱性がある。更に、新商品のリリース直後はサーバの負荷が高いという,,,,,,,,, ,,特徴を踏まえ、潜在化したバグがサーバの高負荷時に顕在化してソフトウェア障害が発生するというリスクを想,,,,,,,,, ,,定した。なぜならば、販売機会を失いかねないサービス提供の重要度が大きい、新商品販売時のアクセス集中,,,,,,,,, ,,の際に、バグが顕在化した場合、トランザクション障害が頻繁に発生する事態などが生じ、情報システムへの影,,,,,,,,, ,,響も大きいからである。,,,,,,,,, ,,,,,,,,,,, ,２．２　対応策,,,,,,,,,, ,,,,,,,,,,, ,,　リスクに対して次の対応策が有効であると私は考えた。,,,,,,,,, ,,,,,,,,,,, ,,（１）サーバ構成における負荷の平準化,,,,,,,,, ,,,,,,,,,,, ,,,　高負荷状態でしか顕在化しないバグについては、高負荷状態で機能テストを実施することが重要である。加,,,,,,,, ,,,えて、高負荷状態を回避する基盤設計が行われていることも重要である。なぜならば、バグは取り切ることは,,,,,,,, ,,,不可能であるが、それを顕在化する環境はコントロールできるからである。したがって、基盤設計において高,,,,,,,, ,,,負荷状態を回避するサーバ負荷の平準化が対応策として重要である。,,,,,,,, ,,,,,,,,,,, ,,（２）商品別の縮退運転が可能なアプリケーション設計,,,,,,,,, ,,,,,,,,,,, ,,,　情報システムに求められた信頼性を踏まえると、障害発生時に、新製品の販売に資源を集中してサービス,,,,,,,, ,,,を提供できる対応策も重要である。したがって、商品別の縮退運転が可能なアプリケーション設計も、対応策,,,,,,,, ,,,として有効であると考えた。,,,,,,,, ,,,,,,,,,,, ,,　以上の対応策について、監査の留意点を次に述べる。,,,,,,,,, ,,,,,,,,,,, ,第3章　監査の留意点,,,,,,,,,, ,,,,,,,,,,, ,,　有効性の高い監査手続を設定するためには、次のように、IT環境を踏まえた監査の留意点を設定することが重,,,,,,,,, ,,要である。,,,,,,,,, ,,,,,,,,,,, ,,（１）,,リスク分析や費用対効果に基づいた負荷分散構成を採用していること,,,,,,, ,,,,,,,,,,, ,,,　サーバ構成における負荷の平準化というIT環境の特徴を踏まえると、ピーク時を想定したサーバ構成を採用,,,,,,,, ,,,することが重要である。しかし、このようなアプローチは、一時的なアクセス集中に対応するためのコストがか,,,,,,,, ,,,さむため、費用対効果の面で不適切な場合がある。したがって、①リスク分析を行い費用対効果に基づいた,,,,,,,, ,,,サーバ構成を採用していること、②ブレードサーバの採用など、サーバ構成の動的な構成変更が可能な対応,,,,,,,, ,,,策を講じることで費用対効果の適正性を確保していること、を確認することが監査の留意点となる。,,,,,,,, ,,,,,,,,,,, ,,（２）,,縮退運転可能なアプリケーションのテスト設計が妥当であること,,,,,,, ,,,,,,,,,,, ,,,　商品別の縮退運転が可能なアプリケーション設計というIT環境の特徴を踏まえると、運用性を確認するため,,,,,,,, ,,,の上流工程におけるテスト設計が重要となる。具体的には、縮退運転を前提としたアプリケーションのテスト設,,,,,,,, ,,,計が重要である。,,,,,,,, ,,,　しかし、上流工程では、テスト設計が軽視される傾向があるため、上流工程における縮退運転のテスト設計,,,,,,,, ,,,の妥当性についての監査が重要になる。具体的には、上流工程で作成した縮退運転テストの要件とテスト使,,,,,,,, ,,,用を突合せして、テスト仕様を満足すれば要件を達成できるか、について精査することを、監査の留意点とし,,,,,,,, ,,,て挙げることができる。,,,,,,,, ,,,,,,,,,,, ,,　以上の監査の留意点を基に、監査手続をレビューすることで、より有効性の高い監査手続を設定することがで,,,,,,,,, ,,きる。,,,,,,,,, ,,,,,,,,,,, 平成29年度　問1　情報システムに関する内部不正対策の監査について,,,,,,,,,,, ,,,,,,,,,,, ,　近年、従業員などの内部不正による、情報システムを対象とした情報漏洩などが増えている。内部不正による損害,,,,,,,,,, ,には、情報漏えいなどに伴う直接的な損害に加え、組織の管理態勢の不備や従業員などのモラルの低さが露呈す,,,,,,,,,, ,るなど、組織の社会的信用の失墜がもたらす損害も無視できない。,,,,,,,,,, ,　内部不正の動機は、組織、上司、同僚などへの不満、金銭目的など、様々である。また、従業員などが不正を行え,,,,,,,,,, ,る環境や不正を正当化できる状況を組織が放置することも、内部不正を誘発する大きな要因になる。,,,,,,,,,, ,　情報システムに関する内部不正では、従業員などが業務を行うために有するアクセス権限を悪用して情報の不正,,,,,,,,,, ,窃取、改ざんが行われる場合が多く、外部の者や権限を有しない内部の者による不正アクセスよりも、その防止や,,,,,,,,,, ,発見が難しい。したがって、内部不正対策では、技術的対策に加え、組織的対策を適切に組み合わせることが重要,,,,,,,,,, ,になる。組織的対策には、例えば、規程の整備、労働環境の整備、内部不正が発生した際の対応手順の整備、規,,,,,,,,,, ,程・手順が遵守されるための各種施策の実施などがある。,,,,,,,,,, ,　システム監査では、内部不正を予防し、その被害を最小限に留めるための技術的対策だけでなく、組織的対策が,,,,,,,,,, ,適切に行われているかどうかを確かめる必要がある。また、監査を行うに当たっては、当該対策が法令などに準拠,,,,,,,,,, ,して行われているかどうかという観点も重要になる。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが携わった組織において、内部不正が発生した場合に重大な影響を及ぼす情報システムの概要と,,,,,,, ,,,,、その情報システムにおいて内部不正が発生した場合の影響について、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アに関連して、内部不正の技術的対策の実施状況を確認するための監査手続について、内部不正の,,,,,,, ,,,,特徴を踏まえた留意点を含めて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問アに関連して、内部不正の組織的対策の実施状況を確認するための監査手続について、内部不正の,,,,,,, ,,,,特徴を踏まえた留意点を含めて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　近年、内部不正による、情報システムを対象とした情報漏洩などが増えている。内部不正は、従業員などが業,,,,,,,,, ,,務を行うために有するアクセス権限を悪用して情報の不正窃取、改ざんが行われる場合が多いので、外部者や,,,,,,,,, ,,無権限者による不正アクセスよりもその防止や発見が難しい。したがって、内部不正対策では技術的対策だけで,,,,,,,,, ,,なく、業務効率、従業員教育などの組織的対策が必要となってくる。,,,,,,,,, ,,　本問は、システム監査人として、内部不正の特徴を十分に踏まえた上で、技術的対策と組織的対策の両方に,,,,,,,,, ,,ついて、組織が適切な対策を実施しているかどうかを確認するための監査手続を立案できる知識・能力を評価す,,,,,,,,, ,,る。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問１（情報システムに関する内部不正対策の監査について）は、設問イでは、アクセス権の限定、アクセスログ,,,,,,,,, ,,の取得など一般的な技術的対策について論述している解答は多かったが、権限を有する者による不正アクセス,,,,,,,,, ,,など、内部不正の特徴を踏まえた留意点を含めて論述できている解答は少なかった。設問ウでは、規程の整備、,,,,,,,,, ,,教育の実施といった組織的対策について論述している解答は多かったが、より一歩踏み込んで職務の分離など,,,,,,,,, ,,による内部統制の構築、従業員などに対する営業秘密となる情報の明示といった対策まで論述できている解答,,,,,,,,, ,,は少なかった。本問は、不正アクセスの発見、防御の方法が、外部からの不正アクセスとは異なる内部不正対策,,,,,,,,, ,,の監査の出題なので、解答に当たっては、内部不正の特徴を踏まえて論述してほしい。,,,,,,,,, ,,,,,,,,,,, ■論文事例①,,,,,,,,,,, ,,,,,,,,,,, ,第1章　情報システムの概要及び内部不正が発生した場合の影響,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　A社は製薬会社であり研究開発費の予算管理を支援するプロジェクト予算システム（以下、予算システムという）,,,,,,,,, ,,を運用している。予算システムはA社で開発され、研究開発プロジェクトで必要な物品・サービスの調達、及びプ,,,,,,,,, ,,ロジェクト別予算実績を管理している。,,,,,,,,, ,,　予算システムは、発注処理、受入・検収処理、及びプロジェクト別実績管理処理で構成されている。各処理の画,,,,,,,,, ,,面における操作履歴は、ログとして管理され、システムの利用者に確認などの資料として渡されている。,,,,,,,,, ,,　予算システムには、不正を予防する相互牽制のために、アクセスコントロールなどの技術的対策が講じられて,,,,,,,,, ,,いる。加えて、これら技術的対策と相互に機能する情報セキュリティ対策基準などの組織的対策が施されている,,,,,,,,, ,,。,,,,,,,,, ,,,,,,,,,,, ,１．２　内部不正が発生した場合の影響,,,,,,,,,, ,,,,,,,,,,, ,,　A社の研究開発費は売上の20％を占めるほど高額であるため、社員が架空発注を行うことで、現金をだまし取,,,,,,,,, ,,る詐欺行為などの内部不正が発生した場合、A社は多額の被害を受けるという影響がある。,,,,,,,,, ,,　さらに、詐欺行為の事実が新聞報道された場合、組織の管理体制の不備や社員のモラルの低さが社会に露呈,,,,,,,,, ,,する。そのため、内部不正が発生した場合、製薬会社としての社会的信用が失墜するという影響がある。,,,,,,,,, ,,　A社の監査室では、このような企業における被害は、個人情報漏洩事件を引き起こした企業の例を見ても大き,,,,,,,,, ,,いと判断した。そこで、予算システムのコントロールの有効性に関するシステム監査を実施することになった。私,,,,,,,,, ,,は、監査室のメンバとして、このシステム監査に加わった。,,,,,,,,, ,,,,,,,,,,, ,第2章　内部不正の技術的対策における監査手続,,,,,,,,,, ,２．１　内部不正の特徴を踏まえた留意点,,,,,,,,,, ,,,,,,,,,,, ,,　情報システムに関する内部不正では、業務の達成に必要なアクセス権限を悪用して不正を行うという特徴があ,,,,,,,,, ,,る。この特徴を踏まえると、職務の分離による相互牽制が機能しているか、という留意点を挙げることができる。,,,,,,,,, ,,,,,,,,,,, ,２．２　内部不正の技術的対策の実施状況を確認するための監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　研究開発費が売上の20％を占めるという点を踏まえ、システム監査を発注処理と検収処理に重点を置き実施,,,,,,,,, ,,することにした。,,,,,,,,, ,,,,,,,,,,, ,,（１）発注処理における職務の分離の技術的対策,,,,,,,,, ,,,,,,,,,,, ,,,　発注時に予算残高を超えた発注に対しては、部長の特別承認が必須という技術的対策が施されている。た,,,,,,,, ,,,だし、部長が不在の場合は、口頭指示により課長が行うこともあることが、予備調査の結果、判明している。そ,,,,,,,, ,,,こで、部長と課長における職務の分離による相互牽制が機能しているかを確認していること、及び予算超過時,,,,,,,, ,,,の発注処理の操作履歴を部長自ら確認していることを部長にヒアリングして確認するという監査手続を設定し,,,,,,,, ,,,た。,,,,,,,, ,,,　ただし、ヒアリングだけでは、有効性のある監査証拠を得ることができない。そこで私は、ヒアリング時の資料,,,,,,,, ,,,として、発注処理の操作履歴を入手して精査する監査手続をあわせることで、部長承認が必須となっているこ,,,,,,,, ,,,とを確認した。さらに、この資料を基に部長に直近の承認代行の状況をヒアリングすることにした。この監査手,,,,,,,, ,,,続により、部長による特別承認が必須という技術的対策の有効性、及び特別承認の履歴を部長が適切に事,,,,,,,, ,,,後確認していることを示す監査証拠を得た。,,,,,,,, ,,,,,,,,,,, ,,（２）受入・検収処理における職務の分離の技術的対策,,,,,,,,, ,,,,,,,,,,, ,,,　検収処理では、受入担当者と同じ担当者が検収できない、及び受入量を超える数量・金額の検収入力がで,,,,,,,, ,,,きないという技術的対策が施されている。そこで、受入担当と研修担当の職務の分離による相互牽制が機能,,,,,,,, ,,,しているかを確認するために、受入処理と、検収処理の操作ログを精査するという技術的対策が機能している,,,,,,,, ,,,ことを示す監査証拠を得る。,,,,,,,, ,,,　さらに、研修業務を実査して、受入担当者と同じ研修担当者ではエラーとなること、受入量を超える検収はエ,,,,,,,, ,,,ラーとなることを確認する監査手続を適用した。これにより、受入量を超える検収入力ができないという技術的,,,,,,,, ,,,対策が機能している監査証拠を得た。,,,,,,,, ,,,　以上が内部不正の特徴を踏まえた留意点を考慮した技術的対策に関する監査手続である。,,,,,,,, ,,,,,,,,,,, ,第3章　内部不正の組織的対策における監査手続,,,,,,,,,, ,３．１　内部不正の特徴を踏まえた留意点,,,,,,,,,, ,,,,,,,,,,, ,,　内部不正の特徴としては、内部不正を行う者（以下、加害者という）に表面的には悪意があるとは思えないとい,,,,,,,,, ,,う点を挙げることができる。したがって、上司であれ同僚であれ、他人のパスワードを聞かない旨が情報セキュリ,,,,,,,,, ,,ティ基準などに明文化されているかという点に留意する必要がある。どのような理由であれ、パスワードを聞かな,,,,,,,,, ,,い、教えないという企業風土を育てるためには組織的対策が必要である。,,,,,,,,, ,,,,,,,,,,, ,３．２　内部不正の組織的対策の実施状況を確認するための監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　パスワードを徹底的に秘密にして他人にもパスワードを聞かない企業風土が重要であるという留意点を踏まえ,,,,,,,,, ,,、組織的対策の実施状況を確認するため、次の監査手続を設定した。,,,,,,,,, ,,,,,,,,,,, ,,（１）情報セキュリティ基準の閲覧,,,,,,,,, ,,,,,,,,,,, ,,,　情報セキュリティ基準を閲覧して、パスワードの規定において、業務目的であっても、パスワードを他人に聞,,,,,,,, ,,,かない旨が明文化されていることを確認するという監査手続を設定した。これによりパスワードの漏えいを規,,,,,,,, ,,,定類への明文化により組織的に抑えていることを示す監査証拠を得た。,,,,,,,, ,,,　ただし、監査を行うに当たって、当該対策が法令に準拠して行われているかという点も重要である。例えば、,,,,,,,, ,,,「業務その他正当な理由による場合を除いて、他人の識別符号を提供する行為を禁止」という、不正アクセス,,,,,,,, ,,,禁止法が平成24年に改正された内容に準拠する必要がある。具体的には、「業務その他正当な理由による場,,,,,,,, ,,,合を除く」旨が情報セキュリティ基準に規定されていても、法令には準拠していると判断できる。実際、情報セ,,,,,,,, ,,,キュリティ基準には「業務その他正当な理由による場合を除く」旨の基準があるが、問題なしとした。,,,,,,,, ,,,,,,,,,,, ,,（２）パスワードの聞き出しの実査,,,,,,,,, ,,,,,,,,,,, ,,,　組織的対策によって、パスワードを聞かない、教えないという企業風土が根付いていることを確認するため,,,,,,,, ,,,に、実際にコンピュータの操作を行う旨を説明して、現場の担当者に、パスワードを聞き出すという実査を監査,,,,,,,, ,,,手続として設定した。これにより、安易にパスワードを他者に教えないことを示す監査証拠を得た。,,,,,,,, ,,,,,,,,,,, ,,（３）パスワード管理における機密性にかかわる実査,,,,,,,,, ,,,,,,,,,,, ,,,　実際にパスワードを聞き出すという監査手続を実施後、現場の担当者に実際にコンピュータ操作を依頼して,,,,,,,, ,,,ログインしてもらい、その際、パスワードが秘密に管理されていることを確認する監査手続を設定した。これに,,,,,,,, ,,,より、パスワードを紙に書かないなど、パスワードが秘密に管理されている監査証拠を得た。,,,,,,,, ,,,,,,,,,,, ,,　以上が内部不正の特徴を踏まえた留意点を考慮した組織的対策に関する監査手続である。,,,,,,,,, ,,,,,,,,,,, 平成28年度　問2　情報システムの設計・開発段階における品質管理に関する監査について,,,,,,,,,,, ,,,,,,,,,,, ,　情報技術の進展に伴い、企業などでは、戦略的な新規サービスの提供、業務の効率向上などに情報システムを積,,,,,,,,,, ,極的に利活用している。また、情報システムはネットワーク化されており、不具合が発生するとその影響は組織内に,,,,,,,,,, ,とどまらず、取引先、さらには国民生活にまで及ぶ恐れがある。したがって、本番稼働前の設計・開発段階において,,,,,,,,,, ,、業務の要件を満たしているか、プログラムに誤りはないかなど、品質が十分に確保されているかどうかを監査して,,,,,,,,,, ,おくことが重要である。,,,,,,,,,, ,　情報システムに求められる品質は、関係するサービスまたは業務の要件によって、その内容及びレベルは異なっ,,,,,,,,,, ,てくる。一方で、品質は、設計・開発段階における各工程を通じて、順次、組み込まれていくものである。したがって、,,,,,,,,,, ,設計・開発段階における情報システムの監査において、品質の確保状況を評価するには、一つの工程を対象とする,,,,,,,,,, ,だけでは不十分である。また、システム監査人が、設計書、テスト報告書などの内容を精査して、品質の確保状況を,,,,,,,,,, ,直接、評価することも難しい。,,,,,,,,,, ,　これらの点を踏まえて、システム監査人は、設計・開発段階における品質管理に関わる体制、プロセスなどが適切,,,,,,,,,, ,かどうかを確かめることで、求められる品質が確保されているかどうかを評価する必要がある。更に、レビュー、テス,,,,,,,,,, ,トなどの実施において、品質が確保されているかどうかを測る客観的な指標が設定され、評価されていることを確か,,,,,,,,,, ,めることも有効である。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係する情報システムの概要と、当該情報システムにおいて重要と考えられる品質の内容、及び,,,,,,, ,,,,その品質が確保されない場合のサービスまたは業務への影響について、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アで述べた品質について、設計・開発段階で品質が確保されなくなる要因、及び品質を確保するため,,,,,,, ,,,,に必要なコントロールを、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イで述べたコントロールを踏まえて、設計・開発段階における品質管理の適切性を確認する監査手続,,,,,,, ,,,,について、監査証拠及び確認すべきポイントを含め、700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　企業などで利活用している情報システムにおける品質が確保されていないと、不具合が生じた場合の影響は当,,,,,,,,, ,,該組織だけではなく、顧客や取引先、さらには国民生活にまで及ぶ可能性がある。したがって、設計・開発段階に,,,,,,,,, ,,おける各工程を通じて品質が確保されるようにコントロールすることが重要になる。しかし、システム監査人が品,,,,,,,,, ,,質を直接、確かめることは難しい。そこで、システム監査人は、設計・開発段階における品質管理の適切性を確,,,,,,,,, ,,かめることで、重要な品質が確保されているかどうかを評価する必要がある。,,,,,,,,, ,,　本問では、システム監査人として、情報システムの設計・開発段階における品質が確保されているかどうかを監,,,,,,,,, ,,査するための知識・能力があるかどうかを問う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問２（情報システムの設計・開発段階における品質管理に関する監査について）は、設問イでは、設計・開発段,,,,,,,,, ,,階において、どのような品質を確保すべきなのかを工程ごとに整理して論述できている解答は少なかった。設問,,,,,,,,, ,,ウでは、”品質管理”と”品質”を混同して論述している解答、設問イとの関連がなく一般論で論述している解答、,,,,,,,,, ,,そもそも監査手続になっていない解答が多かった。問題文の趣旨と設問で求められていることを正しく理解した上,,,,,,,,, ,,で、論述してほしい。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　情報システムと品質,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　対象となるシステムは、保険会社A社におけるSFAシステムである。A社では、顧客との対面サービスを充実さ,,,,,,,,, ,,せることで、顧客満足度を上げ、A社内における業務効率の改善を目指し、SFAシステムを構築することになった,,,,,,,,, ,,。SFAシステムはタブレット端末を用いて、販売員が顧客と接するため、営業部の意向を取り入れた、使いやすい,,,,,,,,, ,,ユーザインタフェースをもつシステムを構築することが、システムの成否にかかわっていた。,,,,,,,,, ,,,,,,,,,,, ,１．２　当該システムにおいて重要と考えられる品質,,,,,,,,,, ,,,,,,,,,,, ,,　当該システムにおいては、ユーザインタフェースに関わる品質を重視するため、外部設計における評価指標とし,,,,,,,,, ,,てエラー摘出率、レビュー時間を設定し、評価目標としては、それらの上限値及び下限値を設定して、その間に収,,,,,,,,, ,,まることで品質を確保する必要があると考えた。ただし、外部設計だけでは不十分であるために、その前工程で,,,,,,,,, ,,のエラーの混入を考慮して、要件定義工程も、同様の評価指標を設定して、評価目標値を適切に設定する必要,,,,,,,,, ,,があると考えた。,,,,,,,,, ,,,,,,,,,,, ,１．３　その品質が確保されない場合の業務への影響,,,,,,,,,, ,,,,,,,,,,, ,,　エラー摘出が不十分であるために、当該システムにエラーが残留したり、レビュー時間が目標値を逸脱したこと,,,,,,,,, ,,を放置したりすると、顧客との対面販売において、不都合が生じて販売業務自体をストップするという事態が生じ,,,,,,,,, ,,る。最悪の場合、顧客からの信頼を失い顧客離れが生じることになる。,,,,,,,,, ,,　私はA社のシステム監査室のシステム監査人として、外部設計終盤において、次に述べる監査を実施した。,,,,,,,,, ,,,,,,,,,,, ,第2章　品質に関わるリスク,,,,,,,,,, ,２．１　設計・開発段階で品質が確保されなくなる要因,,,,,,,,,, ,,,,,,,,,,, ,,　当該システムでは、要件定義工程終盤においてPMが交代となり、外部設計において新PMがプロジェクト管理,,,,,,,,, ,,を実施することになっていた。そのため、次に挙げる、品質が確保されなくなる要因があった。,,,,,,,,, ,,,,,,,,,,, ,,①品質管理のための体制が不適切,,,,,,,,, ,,,,,,,,,,, ,,,　プロジェクトにおけるチームは３チームあり、チームリーダからPMに、評価指標の値などの品質に関する報,,,,,,,, ,,,告を行う体制が、新PMであるために不適切であるという要因があった。,,,,,,,, ,,,,,,,,,,, ,,②品質管理プロセスが不適切,,,,,,,,, ,,,,,,,,,,, ,,,　品質管理の体制が適切であっても、新PMの下、品質管理プロセスが不適切であるという要因があった。,,,,,,,, ,,,,,,,,,,, ,,　以上の要因を踏まえて、次のコントロールが必要であると考えた。,,,,,,,,, ,,,,,,,,,,, ,２．２　品質を確保するために必要なコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　品質が確保されなくなる要因を踏まえると、次のコントロールが必要であると考えた。,,,,,,,,, ,,,,,,,,,,, ,,①,品質管理を支えるプロジェクト体制がシステム開発標準において規定されている。及び、該当規程を順守して,,,,,,,, ,,,プロジェクト体制が構築される。,,,,,,,, ,,,,,,,,,,, ,,,　品質管理のための体制が不適切という要因については、システム開発標準を順守して、設計・開発チームと,,,,,,,, ,,,は別に、プロジェクト管理チームをプロジェクト体制に組み込むなどのコントロールが必要である。,,,,,,,, ,,,,,,,,,,, ,,②,品質管理に必要なプロセスがシステム開発標準で規定されている。及び該当規程を順守して品質管理プロセ,,,,,,,, ,,,スが構築、運用される。,,,,,,,, ,,,,,,,,,,, ,,,　品質管理プロセスが不適切という要因については、品質管理に関する問題点が、正確かつ迅速にPMに届き,,,,,,,, ,,,、PMによる迅速な意思決定を支援することが重要である。したがって、品質管理のプロセスが規定され、遵守,,,,,,,, ,,,される必要がある。,,,,,,,, ,,,,,,,,,,, ,,　以上のコントロールを踏まえて、次に述べる監査手続を適用した。,,,,,,,,, ,,,,,,,,,,, ,第3章　監査手続,,,,,,,,,, ,３．１　品質管理の適切性を確認する監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　リスクを踏まえて、次のような監査要点を設定して、監査手続を適用した。,,,,,,,,, ,,,,,,,,,,, ,,①プロジェクト体制は適切か,,,,,,,,, ,,,,,,,,,,, ,,,　この監査要点について、システム開発標準を閲覧して、プロジェクト体制に関する規定を確認した。さらに、,,,,,,,, ,,,プロジェクト体制図、プロジェクトメンバの役割分担を入手して、システム開発標準の規定を順守して、プロジェ,,,,,,,, ,,,クト体制を構築していること、PMの業務を支援するプロジェクト管理チームが存在していることに関する監査証,,,,,,,, ,,,拠を得た。,,,,,,,, ,,,　ここで確認すべきポイントは、プロジェクト管理チームの活動状況である。PMを十分に支援している必要が,,,,,,,, ,,,ある。そこで、プロジェクト管理チームから品質管理に関するアウトプットを入手して、品質管理チームのメンバ,,,,,,,, ,,,にヒアリングを行い、PMの品質管理業務を支援している監査証拠を得た。,,,,,,,, ,,,,,,,,,,, ,,②品質管理プロセスは適切か,,,,,,,,, ,,,,,,,,,,, ,,,　この監査要点については、実際の品質管理会議の議事録を入手して、品質管理のための評価指標が適切,,,,,,,, ,,,に評価されていることを精査した。外部設計のみならず、前工程の要件定義においても、評価指標が評価され,,,,,,,, ,,,ていることである。品質管理会議の議事録を基に、品質管理のための評価指標が適切に設定され、評価され,,,,,,,, ,,,ていることを示す監査証拠を得た。,,,,,,,, ,,,　ここで確認すべきポイントは、摘出したエラーを分析し、前工程までさかのぼった品質の再評価などの必要,,,,,,,, ,,,性を判定して、品質保証をしているかという点である。なぜならば、前工程にさかのぼることは、エラーの増幅,,,,,,,, ,,,作用の面から重要であり、前工程のエラーを見逃すことは、後工程における開発の手戻りを誘発させると考え,,,,,,,, ,,,たからである。そこで私は、PMにインタビューをして、前工程にさかのぼって品質の再レビューを行った実績を,,,,,,,, ,,,確認し、再レビュー報告書を入手して、品質管理の適切性を示す監査証拠を得た。　以上,,,,,,,, ,,,,,,,,,,, 平成29年度　問1　情報システムに関する内部不正対策の監査について,,,,,,,,,,, ,,,,,,,,,,, ,　近年、従業員などの内部不正による、情報システムを対象とした情報漏洩などが増えている。内部不正による損害,,,,,,,,,, ,には、情報漏えいなどに伴う直接的な損害に加え、組織の管理態勢の不備や従業員などのモラルの低さが露呈す,,,,,,,,,, ,るなど、組織の社会的信用の失墜がもたらす損害も無視できない。,,,,,,,,,, ,　内部不正の動機は、組織、上司、同僚などへの不満、金銭目的など、様々である。また、従業員などが不正を行え,,,,,,,,,, ,る環境や不正を正当化できる状況を組織が放置することも、内部不正を誘発する大きな要因になる。,,,,,,,,,, ,　情報システムに関する内部不正では、従業員などが業務を行うために有するアクセス権限を悪用して情報の不正,,,,,,,,,, ,窃取、改ざんが行われる場合が多く、外部の者や権限を有しない内部の者による不正アクセスよりも、その防止や,,,,,,,,,, ,発見が難しい。したがって、内部不正対策では、技術的対策に加え、組織的対策を適切に組み合わせることが重要,,,,,,,,,, ,になる。組織的対策には、例えば、規程の整備、労働環境の整備、内部不正が発生した際の対応手順の整備、規,,,,,,,,,, ,程・手順が遵守されるための各種施策の実施などがある。,,,,,,,,,, ,　システム監査では、内部不正を予防し、その被害を最小限に留めるための技術的対策だけでなく、組織的対策が,,,,,,,,,, ,適切に行われているかどうかを確かめる必要がある。また、監査を行うに当たっては、当該対策が法令などに準拠,,,,,,,,,, ,して行われているかどうかという観点も重要になる。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが携わった組織において、内部不正が発生した場合に重大な影響を及ぼす情報システムの概要と,,,,,,, ,,,,、その情報システムにおいて内部不正が発生した場合の影響について、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アに関連して、内部不正の技術的対策の実施状況を確認するための監査手続について、内部不正の,,,,,,, ,,,,特徴を踏まえた留意点を含めて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問アに関連して、内部不正の組織的対策の実施状況を確認するための監査手続について、内部不正の,,,,,,, ,,,,特徴を踏まえた留意点を含めて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　近年、内部不正による、情報システムを対象とした情報漏洩などが増えている。内部不正は、従業員などが業,,,,,,,,, ,,務を行うために有するアクセス権限を悪用して情報の不正窃取、改ざんが行われる場合が多いので、外部者や,,,,,,,,, ,,無権限者による不正アクセスよりもその防止や発見が難しい。したがって、内部不正対策では技術的対策だけで,,,,,,,,, ,,なく、業務効率、従業員教育などの組織的対策が必要となってくる。,,,,,,,,, ,,　本問は、システム監査人として、内部不正の特徴を十分に踏まえた上で、技術的対策と組織的対策の両方に,,,,,,,,, ,,ついて、組織が適切な対策を実施しているかどうかを確認するための監査手続を立案できる知識・能力を評価す,,,,,,,,, ,,る。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問１（情報システムに関する内部不正対策の監査について）は、設問イでは、アクセス権の限定、アクセスログ,,,,,,,,, ,,の取得など一般的な技術的対策について論述している解答は多かったが、権限を有する者による不正アクセス,,,,,,,,, ,,など、内部不正の特徴を踏まえた留意点を含めて論述できている解答は少なかった。設問ウでは、規程の整備、,,,,,,,,, ,,教育の実施といった組織的対策について論述している解答は多かったが、より一歩踏み込んで職務の分離など,,,,,,,,, ,,による内部統制の構築、従業員などに対する営業秘密となる情報の明示といった対策まで論述できている解答,,,,,,,,, ,,は少なかった。本問は、不正アクセスの発見、防御の方法が、外部からの不正アクセスとは異なる内部不正対策,,,,,,,,, ,,の監査の出題なので、解答に当たっては、内部不正の特徴を踏まえて論述してほしい。,,,,,,,,, ,,,,,,,,,,, ■論文事例②,,,,,,,,,,, ,,,,,,,,,,, ,１．情報システムの概要と内部不正が発生した場合の影響,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　A社は全国に数十店舗の電気店を展開する家電量販店である。A社は、会員カードの利用に力を入れており、,,,,,,,,, ,,購入時に会員カードを提示すると購入価格の10％のポイントを付けている。これらの店舗での販売は、POSシス,,,,,,,,, ,,テムで処理されており、ポイント処理などがあるために、各店舗のPOS端末はシステム・センタのサーバにリアル,,,,,,,,, ,,タイムで接続されている。また、Webシステムによるネット販売のHPには、基本的に店舗で扱っているすべての商,,,,,,,,, ,,品を表示し、価格も店舗と同じにしている。また、ポイントも店舗販売とネット販売では共通化しているので、商品,,,,,,,,, ,,マスタ、顧客マスタ等は両方のシステムで共用している。,,,,,,,,, ,,,,,,,,,,, ,１．２　内部不正が発生した場合の影響,,,,,,,,,, ,,,,,,,,,,, ,,　内部不正に関して、A社が最も気を付けているのが、個人情報の漏えいである。社員が顧客情報をダウンロー,,,,,,,,, ,,ドして、ライバル会社や名簿業者に販売してしまうことが考えられる。このような事態が発生してしまうと、A社の顧,,,,,,,,, ,,客からの信頼は大きく揺らぐことになり、売上の大幅なダウンや、損害賠償による損失の発生は避けられない。,,,,,,,,, ,,　また、もう一つ内部不正としてA社が気を付けていることは、納入業者と仕入れ担当者が癒着して、キックバック,,,,,,,,, ,,を受け取るようなことである。このような事態が発生すると、対外的な信用が落ちると同時に、キックバックが上乗,,,,,,,,, ,,せされた高い仕入れを受け入れることにより、利益が減少することになる。,,,,,,,,, ,,,,,,,,,,, ,２．技術的対策の実施状況を確認するための監査手続,,,,,,,,,, ,２．１　内部不正の特徴を踏まえた留意点とコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　社員による顧客の個人情報漏洩に関しては、一般社員のIDでは顧客データベースの1件ずつの参照はできる,,,,,,,,, ,,がダウンロードやコピー等は一切できないように設定しているので、一般社員による大量な個人情報の漏えいが,,,,,,,,, ,,発生する可能性はあまりないと考えられる。したがって、主にシステム担当者による不正な個人情報の漏えいに,,,,,,,,, ,,焦点を当てて述べる。,,,,,,,,, ,,　システム担当者は運用担当者と開発担当者に大きく分かれる。開発担当者は、通常はサーバルームへの入室,,,,,,,,, ,,が認められておらず、サーバルームの端末を利用できるIDも割り当てられていない。ただし、トラブル対応等のた,,,,,,,,, ,,めにサーバルームへの入室が認められる場合がある。その場合、開発担当者には一時的なIDが運用責任者か,,,,,,,,, ,,ら割り当てられ、利用が終わるとそのIDは使用できないようにしている。また、サーバルーム内での操作は全てロ,,,,,,,,, ,,グに記録されているので、運用責任者はそのログの内容をチェックして、不正な操作が行われないかチェックする,,,,,,,,, ,,ことになっている。,,,,,,,,, ,,　運用担当者は、日々の運用のために、サーバルームへの入室、及びサーバルーム内の端末を利用するために,,,,,,,,, ,,IDも与えられている。したがって、不正な操作を行って個人情報を漏えいできる可能性は一番高い。そこで、運用,,,,,,,,, ,,担当者の操作ログは全てログ分析ソフトで分析され、分析レポートが出力されている。,,,,,,,,, ,,　仕入れ担当者による不正な取引に関しては、通常のログのチェック等では不正な取引を見つけるのは難しいの,,,,,,,,, ,,で、外部のフォレンジックサービスを利用している。これは、社員のメールや各種の取引データを解析して、不正,,,,,,,,, ,,取引を発見するサービスである。,,,,,,,,, ,,,,,,,,,,, ,２．２　技術的対策の実施状況確認のための監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　開発担当者による不正な個人情報の漏えいに関しては、開発担当者に与えられた一時的なIDが確実に利用後,,,,,,,,, ,,削除されていることを、アクセス権の設定ログを見て確認する。また、操作後に運用責任者が開発担当者の操作,,,,,,,,, ,,ログを確認していることを、保管されている操作ログの確認記録を見て確認する。また、運用責任者にインタビュ,,,,,,,,, ,,ーして適切な観点でチェックが行われていることを確認する。,,,,,,,,, ,,　運用担当者による不正な個人情報の漏えいに関しては、ログ分析レポートが運用責任者により確実にチェック,,,,,,,,, ,,されていることをログ分析レポートの確認記録を見て確認する。また、実際のログを見て個人情報データベース,,,,,,,,, ,,のコピーなどが行われている場合には、そのコピーが不正なものでないことを運用担当者が操作記録と突き合わ,,,,,,,,, ,,せて確認していることもログ分析レポートの確認記録を見て確認する。,,,,,,,,, ,,　仕入れ担当者による不正な取引に関しては、フォレンジックサービスによるレポート（フォレンジック・レポート）が,,,,,,,,, ,,確実に内部監査責任者によってチェックされていることをフォレンジック・レポートの確認記録をみて確認する。ま,,,,,,,,, ,,た、不正が疑われるレポート項目に関しては、必要な調査が行われていることを、調査記録を閲覧することにより,,,,,,,,, ,,確認する。,,,,,,,,, ,,,,,,,,,,, ,３．組織的対策の実施状況を確認するための監査手続,,,,,,,,,, ,３．１　内部不正の特徴を踏まえた留意点とコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　社員による顧客の個人情報漏洩に関しては、まず、社員がこれらの不正を起こさないような気持にさせることが,,,,,,,,, ,,重要である。そのためには規定の整備を行う必要がある。具体的には、個人情報保護規定を整備し、個人情報,,,,,,,,, ,,の漏えいを防ぐためのログチェックなどの対策をとることを規定することが必要である。個人情報保護規定には、,,,,,,,,, ,,情報漏洩などが発生したときの対応手順についても規定しておく必要がある。また、就業規則に個人情報の漏え,,,,,,,,, ,,い等が懲戒免職の対象となることも規定する。次に、社員に対する教育を行い、これらの規定の内容を社員に周,,,,,,,,, ,,知するとともに、過去の個人情報の漏えい事故において犯人が不正競争防止法や個人情報保護法によって処,,,,,,,,, ,,罰されていることも周知する。これによって、各社員が個人情報の漏えいに関して十分に留意するとともに、これ,,,,,,,,, ,,らの行為が処罰の対象になることをしっかり認識するようにする。,,,,,,,,, ,,　仕入れ担当者による不正な取引に関しては、就業規則に不正取引が懲戒免職に当たることを明記することが,,,,,,,,, ,,必要である。次に仕入れ担当者に対する教育を行い、これらの規定の内容を社員に周知するとともに、取引先か,,,,,,,,, ,,らの過度な接待を受けることも好ましくないことを徹底する。また、会社としてフォレンジックサービスによるチェッ,,,,,,,,, ,,クを行っていることも知らせ、このような行為が発見される可能性が高いことも周知する。ただし、このフォレンジッ,,,,,,,,, ,,クサービスの詳細な内容は対策を取ることを防ぐために知らせないこととする。,,,,,,,,, ,,,,,,,,,,, ,３．２　組織的対策の実施状況確認のための監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　社員による不正な個人情報の漏えいに関しては、まず個人情報保護規定を確認して、個人情報の漏えいなど,,,,,,,,, ,,を防ぐための定期的なログチェックや情報漏洩などが発生したときの対応手順などが規定されていることを確認,,,,,,,,, ,,する。また、就業規則を確認して、個人情報の漏えい等が懲戒免職の対象となることが規定されていることを確,,,,,,,,, ,,認する。次に、社員に対する教育が行われていることを教育資料を見て確認する。また、その教育内容をその時,,,,,,,,, ,,の教育資料を見て確認し、規程の内容が伝えられていることや個人情報の漏えいが処罰の対象となっていること,,,,,,,,, ,,が伝えられていることを確認する。,,,,,,,,, ,,　仕入れ担当者による不正な取引に関しては、就業規則を確認し、不正取引が懲戒免職に当たることが明記され,,,,,,,,, ,,ていることを確認する。次に仕入れ担当者に対する教育が行われていることを教育記録を見て確認する。また、,,,,,,,,, ,,その教育内容をその時の教育資料を見て確認し、就業規則の内容が伝えられていることやフォレンジックサービ,,,,,,,,, ,,スを利用することにより、不正取引のチェックが行われていることが伝えられていることを確認する。　以上,,,,,,,,, ,,,,,,,,,,, 平成28年度　問2　情報システムの設計・開発段階における品質管理に関する監査について,,,,,,,,,,, ,,,,,,,,,,, ,　情報技術の進展に伴い、企業などでは、戦略的な新規サービスの提供、業務の効率向上などに情報システムを積,,,,,,,,,, ,極的に利活用している。また、情報システムはネットワーク化されており、不具合が発生するとその影響は組織内に,,,,,,,,,, ,とどまらず、取引先、さらには国民生活にまで及ぶ恐れがある。したがって、本番稼働前の設計・開発段階において,,,,,,,,,, ,、業務の要件を満たしているか、プログラムに誤りはないかなど、品質が十分に確保されているかどうかを監査して,,,,,,,,,, ,おくことが重要である。,,,,,,,,,, ,　情報システムに求められる品質は、関係するサービスまたは業務の要件によって、その内容及びレベルは異なっ,,,,,,,,,, ,てくる。一方で、品質は、設計・開発段階における各工程を通じて、順次、組み込まれていくものである。したがって、,,,,,,,,,, ,設計・開発段階における情報システムの監査において、品質の確保状況を評価するには、一つの工程を対象とする,,,,,,,,,, ,だけでは不十分である。また、システム監査人が、設計書、テスト報告書などの内容を精査して、品質の確保状況を,,,,,,,,,, ,直接、評価することも難しい。,,,,,,,,,, ,　これらの点を踏まえて、システム監査人は、設計・開発段階における品質管理に関わる体制、プロセスなどが適切,,,,,,,,,, ,かどうかを確かめることで、求められる品質が確保されているかどうかを評価する必要がある。更に、レビュー、テス,,,,,,,,,, ,トなどの実施において、品質が確保されているかどうかを測る客観的な指標が設定され、評価されていることを確か,,,,,,,,,, ,めることも有効である。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係する情報システムの概要と、当該情報システムにおいて重要と考えられる品質の内容、及び,,,,,,, ,,,,その品質が確保されない場合のサービスまたは業務への影響について、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アで述べた品質について、設計・開発段階で品質が確保されなくなる要因、及び品質を確保するため,,,,,,, ,,,,に必要なコントロールを、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イで述べたコントロールを踏まえて、設計・開発段階における品質管理の適切性を確認する監査手続,,,,,,, ,,,,について、監査証拠及び確認すべきポイントを含め、700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　企業などで利活用している情報システムにおける品質が確保されていないと、不具合が生じた場合の影響は当,,,,,,,,, ,,該組織だけではなく、顧客や取引先、さらには国民生活にまで及ぶ可能性がある。したがって、設計・開発段階に,,,,,,,,, ,,おける各工程を通じて品質が確保されるようにコントロールすることが重要になる。しかし、システム監査人が品,,,,,,,,, ,,質を直接、確かめることは難しい。そこで、システム監査人は、設計・開発段階における品質管理の適切性を確,,,,,,,,, ,,かめることで、重要な品質が確保されているかどうかを評価する必要がある。,,,,,,,,, ,,　本問では、システム監査人として、情報システムの設計・開発段階における品質が確保されているかどうかを監,,,,,,,,, ,,査するための知識・能力があるかどうかを問う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問２（情報システムの設計・開発段階における品質管理に関する監査について）は、設問イでは、設計・開発段,,,,,,,,, ,,階において、どのような品質を確保すべきなのかを工程ごとに整理して論述できている解答は少なかった。設問,,,,,,,,, ,,ウでは、”品質管理”と”品質”を混同して論述している解答、設問イとの関連がなく一般論で論述している解答、,,,,,,,,, ,,そもそも監査手続になっていない解答が多かった。問題文の趣旨と設問で求められていることを正しく理解した上,,,,,,,,, ,,で、論述してほしい。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,１．情報システムの概要と品質が確保されない場合の業務への影響,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　B社は大手生命保険会社である。保険商品の種類や契約数の増加に伴い、保険金支払いの可否判断を行う支,,,,,,,,, ,,払査定業務や付随する書類量も増加する一方であったが、従来のシステムでは、保険金支払い業務量増大へ,,,,,,,,, ,,の対処ができないことは明らかであった。また、監督官庁から支払い漏れをなくすよう指導があり、保険金支払い,,,,,,,,, ,,査定での判断誤りを抑止するために、支払査定業務の自動化範囲拡大の要望も提出されていた。そこでK社は、,,,,,,,,, ,,支払業務の効率化と精度向上を目指し、既存システムを全面再構築し、新規に支払い業務システムを構築した。,,,,,,,,, ,,その目的は、次の三つである。,,,,,,,,, ,,,・,支払査定の精度向上（支払漏れ、誤りの抑止）,,,,,,, ,,,・,支払査定の負荷軽減とスピードアップ,,,,,,, ,,,・,支払査定資料の電子化,,,,,,, ,,,,,,,,,,, ,１．２　重要と考えられる品質の内容、及びその品質が確保されない場合の業務への影響,,,,,,,,,, ,,,,,,,,,,, ,,　支払業務システムで最も重要と考えられる品質内容は支払金額を絶対に間違えないということである。保険金,,,,,,,,, ,,の支払額の算出に不具合がある場合は、受取人が不利益を被るだけでなく、その事実が公になった場合には、B,,,,,,,,, ,,社の社会的信用を損なうことにもなる。,,,,,,,,, ,,　また、支払査定の負荷軽減とスピードアップを確実に実現することも強く求められた。特に従来多くの紙の書類,,,,,,,,, ,,で処理していた業務をイメージ処理して、業務を大幅にスピードアップさせることが期待されている。これが実現で,,,,,,,,, ,,きないと保険金支払い業務量増大へ対処できず、結果として顧客への支払いが遅れてしまい、顧客にも多大な,,,,,,,,, ,,迷惑を掛けることになる。,,,,,,,,, ,,,,,,,,,,, ,２．設計・開発段階で品質が確保されなくなる要因、及び品質を確保するために必要なコントロール,,,,,,,,,, ,２．１　設計段階で品質が確保されなくなる要因と必要なコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　設計段階で最も懸念されたことは、従来の紙による処理を、イメージを直接端末から扱う処理に変更して、本当,,,,,,,,, ,,に業務効率が上がるのかという点である。机上の計画では確かに紙をコピーしたりする手間が省け、業務効率が,,,,,,,,, ,,向上するはずであったが、システムの使い勝手が悪いと、かえって従来の処理よりも効率が悪くなるおそれもあっ,,,,,,,,, ,,た。これを解決するために、このイメージ処理に完しては、プロトタイプを事前に作成し、これを使用して処理を行,,,,,,,,, ,,ってみて、本当に効率が上がることを確認してから、設計作業を進めるようにした。,,,,,,,,, ,,,,,,,,,,, ,２．２　開発段階で品質が確保されなくなる要因と必要なコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　開発段階では、あらゆる条件の組合せを確実にテストして、どんな場合にも支払金額を間違えるようなことがな,,,,,,,,, ,,いようにしている必要がある。このテストが不十分だと、品質が確保できずに、顧客に迷惑を掛けることになる。こ,,,,,,,,, ,,のためのコントロールとして、シナリオによるテストケースの作成を行った。業務機能の確認のため、業務シナリ,,,,,,,,, ,,オを作成し、シナリオごとにテスト仕様書とテストデータ入力シートを作成し、支払業務システムに入力して稼働結,,,,,,,,, ,,果を確認した。このシナリオの作成に際しては、実際に支払業務を担当しているベテランの担当者に参加してもら,,,,,,,,, ,,い、シナリオに漏れが発生しないようにした。テストケースの作成に際しては、設定した品質目標（テストケース設,,,,,,,,, ,,定密度）をクリアしていることを確認した。,,,,,,,,, ,,　また、システムテストの最後に、旧システムの3カ月分の処理データを使用して、これを新システムのテストデー,,,,,,,,, ,,タに加工して、新システムに流してみて、支払金額が一致していることを確認するテストを行った。,,,,,,,,, ,,　実際のシステムテスト完了時には、モジュールごとの品質目標（障害発生密度）を全モジュールクリアしている,,,,,,,,, ,,ことを確認し、下回っているモジュールがあった場合には、根本的な問題が発生していないか確認し、必要な対,,,,,,,,, ,,応策をとることにした。,,,,,,,,, ,,,,,,,,,,, ,３．品質管理の適切性を確認する監査手続,,,,,,,,,, ,３．１　設計段階における監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　設計段階においては、プロトタイプによる検証が適切に行われていることを確認する必要がある。プロトタイプに,,,,,,,,, ,,よる検証報告書を閲覧し、イメージ処理に関しては最初から最後までの一連の流れが確認できるプロトタイプに,,,,,,,,, ,,なっていることを確認する。また、このプロトタイプの検証に、実際に業務を行っている担当者が参画していること,,,,,,,,, ,,を確認し、その担当者の評価で、従来よりも業務効率が向上するというコメントがあるかどうかを確認する。,,,,,,,,, ,,,,,,,,,,, ,３．２　開発段階における監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　シナリオによるテストケースが適切に作成されていることを確認するために、シナリオの作成に携わった支払業,,,,,,,,, ,,務を担当しているベテランの担当者にインタビューして、実際に想定されるすべてのケースについて、テストケー,,,,,,,,, ,,スを作成していることを確認する。また、同時にテストケースの項目数を数えて、テストケース密度が基準を満た,,,,,,,,, ,,しているかどうかを確認した。,,,,,,,,, ,,　次に、過去データによるテストが適切に実施されているかを確認するために、テスト報告書を閲覧して、旧シス,,,,,,,,, ,,テムの過去3カ月の処理データを使用したテストが実施されていることを確認する。,,,,,,,,, ,,　また、モジュールごとに品質目標がクリアされていることを確認するために、テスト報告書を閲覧して、品質目標,,,,,,,,, ,,である障害発生密度が正常範囲を逸脱しているものがないかを確認する。また、障害発生密度が正常範囲を超,,,,,,,,, ,,えているものがあった場合には、適切な対応策が取られていることを課題管理表を見て確認する。　以上,,,,,,,,, ,,,,,,,,,,, 平成27年度　問1　ソフトウェアの脆弱性対策の監査について,,,,,,,,,,, ,,,,,,,,,,, ,　近年、ソフトウェアの脆弱性、すなわち、ソフトウェアの製品及びアプリケーションプログラムにおけるセキュリティ上,,,,,,,,,, ,の欠陥を悪用した不正アクセスが増えている。ソフトウェア製品とは、アプリケーションプログラムの開発及び稼働、,,,,,,,,,, ,並びに情報システムの運用管理のために必要なオペレーションシステム、ミドルウェアなどをいう。,,,,,,,,,, ,　ソフトウェアの脆弱性によっては、それを放置しておくと、アクセス権限のない利用者が情報を閲覧できるなど、アク,,,,,,,,,, ,セス権限を越えた操作が可能になる場合もある。例えば、改ざんなどを行ったり、情報システムの利用者に、本来は,,,,,,,,,, ,見えてはいけない情報が見えてしまったりする。,,,,,,,,,, ,　ソフトウェアの脆弱性対策では、開発段階で、ソフトウェア製品及びアプリケーションプログラムの脆弱性の発生を,,,,,,,,,, ,防止するとともに、テスト段階で脆弱性がないことを確認する。しかし、テスト段階で全ての脆弱性を発見し、取り除く,,,,,,,,,, ,ことは難しい。また、ソフトウェアのバージョンアップの際に新たな脆弱性が生じる可能性もある。したがって、運用・,,,,,,,,,, ,保守段階でも継続的に脆弱性の有無を確認し、適切な対応を実施していくことが必要になる。,,,,,,,,,, ,　システム監査人は、ソフトウェアの脆弱性を原因とした情報セキュリティ被害を防止するために、ソフトウェアの脆,,,,,,,,,, ,弱性対策が適切に行われるためのコントロールが有効に機能しているかを確認する必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが携わった情報システムの概要、及びその情報システムにおけるソフトウェアの脆弱性によって生じ,,,,,,, ,,,,るリスクについて、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アに関連して、ソフトウェアの脆弱性対策について、開発、テスト、及び運用・保守のそれぞれの段階,,,,,,, ,,,,において必要なコントロールを、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イで述べたコントロールの有効性を確認するための監査手続について、確認すべき監査証拠を含め,,,,,,, ,,,,て700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　情報システムの高度化、複雑化に伴い、ソフトウェア製品及びアプリケーションプログラムに脆弱性が発生する,,,,,,,,, ,,可能性が高くなっている。脆弱性の発生防止、発見、対応には多大な労力を要することから、その対策の実施に,,,,,,,,, ,,漏れが発生する可能性もある。したがって、脆弱性対策が漏れなく、かつ、適切に実施されるためのコントロール,,,,,,,,, ,,が整備されているか、また、それらが適切に運用されているかを監査によって確認することが重要である。,,,,,,,,, ,,　本問では、システム監査人として、脆弱性対策の監査を適切に実施するための知識、経験を有しているかを問,,,,,,,,, ,,う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問１（ソフトウェアの脆弱性対策の監査について）は、アクセス権管理、ウイルス対策などの一般的なセキュリテ,,,,,,,,, ,,ィ対策の論述に終始している解答が散見された。また、脆弱性の発生防止、発見、対応のためのコントロールに,,,,,,,,, ,,ついて、コントロールの具体的な内容が論述されていない解答も散見された。問題文に記述されている脆弱性対,,,,,,,,, ,,策の定義を踏まえて解答する必要があることを理解してほしい。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　情報システム及びリスク,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　A社は、ディジタル機器の開発及び受託開発を行う、従業員400名の企業である。昨今、ソフトウェアの脆弱性が,,,,,,,,, ,,報告されていることを受け、A社の親会社のX社で、A社の開発するシステムについて、開発、テスト、運用・保守,,,,,,,,, ,,段階のそれぞれでシステム監査を実施することになった。私は、X社のシステム監査室のシステム監査人である,,,,,,,,, ,,。,,,,,,,,, ,,　対象となる情報システムは、A社が受託開発している、自然食品を扱うB社において稼働するWeb受注システム,,,,,,,,, ,,（以下、システムという）である。このシステムはB社の顧客情報を扱うシステムのため、情報システムの特徴とし,,,,,,,,, ,,ては、機密性が重視されるという点を挙げることができる。,,,,,,,,, ,,,,,,,,,,, ,１．２　脆弱性によって生じるリスク,,,,,,,,,, ,,,,,,,,,,, ,,　当該システムのプログラミング工程に入った直後に、予備調査を行った。その結果、システムはC言語を使って,,,,,,,,, ,,開発していることが判明した。言語の特性上、特に、バッファオーバーフロー脆弱性（以下、BOF脆弱性という）が,,,,,,,,, ,,組みこまれやすいというリスク要因があることが判明した。したがって、以下は、BOF脆弱性を中心に論じる。,,,,,,,,, ,,　予備調査の結果、リスク要因を踏まえると、開発段階では、脆弱性を組みこむリスク、テスト段階では、脆弱性,,,,,,,,, ,,を見逃すリスク、運用・保守段階では、脆弱性への対応が遅延するリスク、及び、保守によって、新たな脆弱性が,,,,,,,,, ,,盛り込まれるリスクがあると考えた。,,,,,,,,, ,,　私は、各段階において、次に述べるコントロールが必要であると考えた。,,,,,,,,, ,,,,,,,,,,, ,第2章　ソフトウェア脆弱性対策,,,,,,,,,, ,２．１　開発段階におけるコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　脆弱性を組みこむリスクについては、次のコントロールが必要と考える。,,,,,,,,, ,,,①,開発標準に脆弱性を組みこまないための留意点や、コーディング規則を明記する。,,,,,,, ,,,②,開発段階では、成果物について、開発標準に従って開発者が設計及び製造を行っているかをレビューする,,,,,,, ,,,,。,,,,,,, ,,,,,,,,,,, ,２．２　テスト段階におけるコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　脆弱性を見逃すリスクについては、人間によるチェックでは限界があるので、ソフトウェアツールを活用する必要,,,,,,,,, ,,がある。したがって、ソフトウェアツールを使って脆弱性を効率的かつ効果的に洗い出すというコントロールが必,,,,,,,,, ,,要である。,,,,,,,,, ,,　なお、ソフトウェアツールについては、通常の利用では想定しないデータを入力し、その応答から脆弱性を探す,,,,,,,,, ,,ファジング検査を行うツールを利用して脆弱性を洗い出すことが可能となる。,,,,,,,,, ,,,,,,,,,,, ,２．３　運用・保守段階におけるコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　脆弱性への対応が遅延するリスクについては、脆弱性が発見された場合、迅速に顧客修正プログラムを展開,,,,,,,,, ,,する手順をあらかじめ用意する、というコントロールが必要である。修正プログラムを迅速かつ正確に展開するこ,,,,,,,,, ,,とで、脆弱性に起因する被害を最小限に抑えることが重要である。,,,,,,,,, ,,　保守によって、新たな脆弱性が盛り込まれるリスクについては、定期的に情報セキュリティの専門家によるペネ,,,,,,,,, ,,トレーションテストを実施する、というコントロールが必要である。情報システムの環境は日々変化するため、専門,,,,,,,,, ,,化による客観的な評価が情報セキュリティの強度を維持するためには必要である。,,,,,,,,, ,,　以上のコントロールを踏まえ、次の監査手続を策定した。,,,,,,,,, ,,,,,,,,,,, ,第3章　監査手続,,,,,,,,,, ,３．１　開発段階における監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　開発段階における二つのコントロールに基づいて”開発標準において脆弱性に関する記述が適切で、開発標準,,,,,,,,, ,,に基づいてコーディング及びレビューを行っているか”という監査要点とした。,,,,,,,,, ,,　監査手続としては、開発標準を精査して、開発言語ごとに脆弱性に関する留意点やサンプルコーディングがあ,,,,,,,,, ,,るかを確認して、開発標準において脆弱性に関する考慮が適切であることを示す監査証拠を得る。さらに、監査,,,,,,,,, ,,手続として、プログラム設計におけるレビュー報告書を精査して、脆弱性に関するレビューが適切であることを示,,,,,,,,, ,,す監査証拠を得る。,,,,,,,,, ,,,,,,,,,,, ,３．２　テスト段階における監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　監査の時点がプログラミング工程である点を踏まえ、テスト段階における監査については、脆弱性を摘出するツ,,,,,,,,, ,,ールに関するマニュアル整備や、テスト手順が開発標準に盛り込まれているか、という監査要点とした。,,,,,,,,, ,,　監査手続としては、ツールのマニュアルを基に、開発者にヒアリングを行い、マニュアルの内容の適切性、及び,,,,,,,,, ,,開発者における内容の理解度の適切性を示す監査証拠を得る。,,,,,,,,, ,,　なお、監査の時点がテスト工程に入った場合は、テスト報告書を閲覧して、ツールが適切に使われて脆弱性が,,,,,,,,, ,,摘出されていることを示す監査証拠を得ることができると考える。,,,,,,,,, ,,,,,,,,,,, ,３．３　運用・保守段階における監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　監査の時点が運用・保守段階に入った場合、前述の二つのコントロールを踏まえ、定期的に専門家によるペネ,,,,,,,,, ,,トレーションテストが実施され、迅速に顧客に修正プログラムが提供されているか、という監査要点とする。,,,,,,,,, ,,　監査手続としては、保守報告書を精査して保守の頻度に応じた、専門化によるペネトレーションテストが実施さ,,,,,,,,, ,,れていることを確認し、ペネトレーションテストが保守の頻度に応じて適切に実施されていることを示す監査証拠,,,,,,,,, ,,を得る。なお、ペネトレーションテストが実施されていない場合は、保守の頻度などに応じて実施する旨を改善勧,,,,,,,,, ,,告とする準備をする。,,,,,,,,, ,,　さらに、監査手続として、ペネトレーションテストなどによって、脆弱性が検出された場合の対応手順書、及び、,,,,,,,,, ,,修正プログラムのリリースに関する報告書を精査して、脆弱性が適切な手順で顧客に迅速にリリースされること,,,,,,,,, ,,を示す監査証拠を得る。,,,,,,,,, ,,　以上が各段階における監査手続である。　以上,,,,,,,,, ,,,,,,,,,,, 平成27年度　問1　ソフトウェアの脆弱性対策の監査について,,,,,,,,,,, ,,,,,,,,,,, ,　近年、ソフトウェアの脆弱性、すなわち、ソフトウェアの製品及びアプリケーションプログラムにおけるセキュリティ上,,,,,,,,,, ,の欠陥を悪用した不正アクセスが増えている。ソフトウェア製品とは、アプリケーションプログラムの開発及び稼働、,,,,,,,,,, ,並びに情報システムの運用管理のために必要なオペレーションシステム、ミドルウェアなどをいう。,,,,,,,,,, ,　ソフトウェアの脆弱性によっては、それを放置しておくと、アクセス権限のない利用者が情報を閲覧できるなど、アク,,,,,,,,,, ,セス権限を越えた操作が可能になる場合もある。例えば、改ざんなどを行ったり、情報システムの利用者に、本来は,,,,,,,,,, ,見えてはいけない情報が見えてしまったりする。,,,,,,,,,, ,　ソフトウェアの脆弱性対策では、開発段階で、ソフトウェア製品及びアプリケーションプログラムの脆弱性の発生を,,,,,,,,,, ,防止するとともに、テスト段階で脆弱性がないことを確認する。しかし、テスト段階で全ての脆弱性を発見し、取り除く,,,,,,,,,, ,ことは難しい。また、ソフトウェアのバージョンアップの際に新たな脆弱性が生じる可能性もある。したがって、運用・,,,,,,,,,, ,保守段階でも継続的に脆弱性の有無を確認し、適切な対応を実施していくことが必要になる。,,,,,,,,,, ,　システム監査人は、ソフトウェアの脆弱性を原因とした情報セキュリティ被害を防止するために、ソフトウェアの脆,,,,,,,,,, ,弱性対策が適切に行われるためのコントロールが有効に機能しているかを確認する必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが携わった情報システムの概要、及びその情報システムにおけるソフトウェアの脆弱性によって生じ,,,,,,, ,,,,るリスクについて、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アに関連して、ソフトウェアの脆弱性対策について、開発、テスト、及び運用・保守のそれぞれの段階,,,,,,, ,,,,において必要なコントロールを、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イで述べたコントロールの有効性を確認するための監査手続について、確認すべき監査証拠を含め,,,,,,, ,,,,て700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　情報システムの高度化、複雑化に伴い、ソフトウェア製品及びアプリケーションプログラムに脆弱性が発生する,,,,,,,,, ,,可能性が高くなっている。脆弱性の発生防止、発見、対応には多大な労力を要することから、その対策の実施に,,,,,,,,, ,,漏れが発生する可能性もある。したがって、脆弱性対策が漏れなく、かつ、適切に実施されるためのコントロール,,,,,,,,, ,,が整備されているか、また、それらが適切に運用されているかを監査によって確認することが重要である。,,,,,,,,, ,,　本問では、システム監査人として、脆弱性対策の監査を適切に実施するための知識、経験を有しているかを問,,,,,,,,, ,,う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問１（ソフトウェアの脆弱性対策の監査について）は、アクセス権管理、ウイルス対策などの一般的なセキュリテ,,,,,,,,, ,,ィ対策の論述に終始している解答が散見された。また、脆弱性の発生防止、発見、対応のためのコントロールに,,,,,,,,, ,,ついて、コントロールの具体的な内容が論述されていない解答も散見された。問題文に記述されている脆弱性対,,,,,,,,, ,,策の定義を踏まえて解答する必要があることを理解してほしい。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,１．情報システムの概要とソフトウェアの脆弱性によって生じるリスク,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　A社は中堅生命保険会社である。A社は営業支援システムを再構築することになり、プロジェクトがスタートした,,,,,,,,, ,,。営業支援システムとは、生命保険を販売する営業職員が営業活動で利用するシステムであり、中心となる機能,,,,,,,,, ,,としては、生命保険販売時に提示する契約概要書の作成機能である。それ以外に営業所長等の管理職が配下,,,,,,,,, ,,の営業職員の活動状況を把握するための活動管理機能を有している。従来のシステムは、ホストコンピュータを,,,,,,,,, ,,使用していたが、今回の改訂ではPCサーバを利用したWebシステムに変更し、営業員はWebが使える環境であ,,,,,,,,, ,,れば、どこからでもシステムが利用できるようになる。,,,,,,,,, ,,,,,,,,,,, ,１．２　ソフトウェアの脆弱性によって生じるリスク,,,,,,,,,, ,,,,,,,,,,, ,,　営業支援システムは、営業所で使用する場合もあるが、客先にタブレットを持参して、そこで使用する場合もあ,,,,,,,,, ,,る。この処理を行う際には、顧客の個人情報を扱う事も多く、これらのデータが万一流出するようなことがあると、,,,,,,,,, ,,顧客企業に迷惑をかけるだけでなく、A社の信用も大きく揺らいでしまうことになる。特に今回のシステムはWebシ,,,,,,,,, ,,ステムでインターネット環境でも使用されるため、Weシステムの脆弱性を悪用した不正アクセスの攻撃を受けるこ,,,,,,,,, ,,とによって、個人情報の漏えいなどが発生すると、損害賠償等でA社が多大な損害を被る可能性があった。また、,,,,,,,,, ,,不正アクセス等により、ハードディスクの内容が改ざんされたり、削除されてしまうようなことがあれば、間違った,,,,,,,,, ,,処理が行われたり、システムが停止して、業務が出来なくなり、顧客に多大な迷惑を掛けてしまう可能性もある。,,,,,,,,, ,,,,,,,,,,, ,２．開発、テスト、及び運用・保守において必要なコントロール,,,,,,,,,, ,２．１　開発において必要なコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　開発段階で最初に行わなければならないことは、使用するOSやミドルウェアに存在する脆弱性を、マニュアル,,,,,,,,, ,,を参照したり、開発元に問い合わせたりして、各種のパッチなどでその脆弱性をカバーする対策が取られている,,,,,,,,, ,,ことを確認することである。この結果、脆弱性が不十分であった場合には、そのミドルウェアは使用しないで、別,,,,,,,,, ,,のものを使用することも検討することとする。,,,,,,,,, ,,　次に行わなければならないことは、開発時に脆弱性をもたらす危ないコーディングや、危ないモジュールの使用,,,,,,,,, ,,を避けることである。これらは、A社においても開発ガイドとチェックリストが整備されている。各開発者はプロジェ,,,,,,,,, ,,クトに参加した時点で、開発ガイドを読むことが義務付けられており、どのようなコーディングを行ってはいけない,,,,,,,,, ,,か、危ないモジュールを使用するときの留意点を理解した上で開発を行うことが義務付けられている。また、開発,,,,,,,,, ,,が完了した際のレビューにおいては、チェックリストを使用して、開発ガイドに反することが行われていないかをチ,,,,,,,,, ,,ェックすることになっている。,,,,,,,,, ,,,,,,,,,,, ,２．２　テストにおいて必要なコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　テスト段階で行わなければならないことは、開発が完了したシステムについて、脆弱性検査ツールを走らせて、,,,,,,,,, ,,新システムに脆弱性が残っていないことを確認することである。この結果は、テスト報告書にも記載するルールに,,,,,,,,, ,,なっている。,,,,,,,,, ,,,,,,,,,,, ,２．３　運用・保守において必要なコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　運用・保守段階においてまず重要なことは、最初にOSやミドルウェアに対するセキュリティ・パッチが必ず適用さ,,,,,,,,, ,,れるルールになっており、そのルールに従って確実に適用されていることである。,,,,,,,,, ,,　次に、A社では毎年1回外部の業者に、セキュリティ診断を依頼することになっており、その診断で発見された脆,,,,,,,,, ,,弱性に対して、適切な対応をとることが義務付けられている。,,,,,,,,, ,,,,,,,,,,, ,３．コントロールの有効性を確認するための監査手続,,,,,,,,,, ,３．１　開発に係るコントロールの監査,,,,,,,,,, ,,,,,,,,,,, ,,　開発段階では、最初に使用するOSやミドルウェアに存在する脆弱性が確認されていなければならない。これを,,,,,,,,, ,,確認するために、開発開始時に作成されているはずの脆弱性調査結果を確認して、脆弱性調査が行われている,,,,,,,,, ,,ことを確認する。また、この調査結果において重大な脆弱性の問題が存在した場合には、使用するミドルウェアを,,,,,,,,, ,,変更するなどの対策が取られていることも確認する。,,,,,,,,, ,,　次に、開発時に危ないコーディングや、危ないモジュールの使用を避けるために、開発ガイドの内容が開発者,,,,,,,,, ,,に十分に理解されていることを確認する必要がある。このために、何人かの開発者に開発ガイドに書かれている,,,,,,,,, ,,内容を質問して、正しく理解しているかどうかを確認する。,,,,,,,,, ,,　さらに、開発完了時のレビュー時に使用したチェックリスト確認票を見て、確かにチェックリストに従ってレビュー,,,,,,,,, ,,が行われていることを確認する。また、そこで不備な点があれば、レビュー記録にその事実が記載されており、か,,,,,,,,, ,,つ、課題管理表を見てその課題が記録され、必要な対応が取られていることを確認する。,,,,,,,,, ,,,,,,,,,,, ,３．２　テストに係るコントロールの監査,,,,,,,,,, ,,,,,,,,,,, ,,　テスト段階では脆弱性検査ツールによる検査が行われている必要がある。このために、テスト報告書を確認し、,,,,,,,,, ,,脆弱性検査ツールを使用したテストが行われていることを確認する。また、テスト報告書でツールの使用により脆,,,,,,,,, ,,弱性が発見されていた場合には、その対策が実施されていることをテスト報告書で確認する。,,,,,,,,, ,,,,,,,,,,, ,３．３　運用・保守に係るコントロールの監査,,,,,,,,,, ,,,,,,,,,,, ,,　運用・保守段階では、OSやミドルウェアに対するセキュリティ・パッチが確実に適用される必要がある。これを確,,,,,,,,, ,,認するために、運用・保守マニュアルを確認し、セキュリティ・パッチを定期的に適用するルールになっていること,,,,,,,,, ,,を確認する。また、運用記録を確認して、実際にセキュリティ・パッチが適用されていることを確認する。,,,,,,,,, ,,　次に、年1回のセキュリティ診断が実施されていることを確認する必要がある。このために、専門家のチェック記,,,,,,,,, ,,録を確認し、確かに診断が行われていることを確認する。また、その記録で発見された脆弱性については、適切,,,,,,,,, ,,な対応が取られていることを担当者にインタビューして確認する。また、その対応策が実際に実施されていること,,,,,,,,, ,,を、運用記録や保守記録などによって確認する。　以上,,,,,,,,, ,,,,,,,,,,, 平成26年度　問2　情報システムの可用性確保及び障害対応に関する監査について,,,,,,,,,,, ,,,,,,,,,,, ,　企業などが提供するサービス、業務などにおいて、情報システムの用途が広がり、情報システムに障害が発生し,,,,,,,,,, ,た場合の影響はますます大きくなっている。その一方で、ハードウェアの老朽化、システム構成の複雑化などによっ,,,,,,,,,, ,て、障害を防ぐことがより困難になっている。このような状況において、障害の発生を想定した情報システムの可用,,,,,,,,,, ,性確保、及び情報システムに障害が発生した場合の対応が、重要な監査テーマの一つになっている。,,,,,,,,,, ,　情報システムの可用性を確保するためには、例えば、情報システムを構成する機器の一部に不具合が発生しても,,,,,,,,,, ,、システム全体への影響を回避できる対策を講じておくなどのコントロールが重要になる。また、情報システムに障,,,,,,,,,, ,害が発生した場合のサービス、業務への影響を最小限に抑えるために、障害を早期に発見するためのコントロール,,,,,,,,,, ,を組み込み、迅速に対応できるように準備しておくことも必要になる。,,,,,,,,,, ,　情報システムに障害が発生した場合には、障害の原因を分析して応急対策を講じるとともに、再発防止策を策定し,,,,,,,,,, ,、実施しなければならない。また、サービス、業務に与える障害の影響度合いに応じて、適時に関係者に連絡・報告,,,,,,,,,, ,する必要もある。,,,,,,,,,, ,　このような点を踏まえて、システム監査人は、可用性確保のためのコントロールだけではなく、障害の対応を適時,,,,,,,,,, ,かつ適切に行うためのコントロールも含めて確認する必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係している情報システムの概要と、これまでに発生した又は発生を想定している障害の内容及,,,,,,, ,,,,び障害発生時のサービス、業務への影響について、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アで述べた情報システムにおいて、可用性確保のためのコントロール及び障害対応のためのコントロ,,,,,,, ,,,,ールについて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問ア及び設問イを踏まえて、可用性確保及び障害対応の適切性を監査するための手続きについて、そ,,,,,,, ,,,,れぞれ確認すべき具体的なポイントを含め、700字以上1400字以内で述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　情報システムの用途の広がりに伴い、情報システムに障害が発生した場合の影響がますます大きくなる一方で,,,,,,,,, ,,、システム障害を完全に排除することは難しい。したがって、情報システムの可用性を高めるためのコントロール,,,,,,,,, ,,だけではなく、障害を早期に発見し、復旧するためのコントロールも合わせて整備しておく必要がある。,,,,,,,,, ,,さらに、発生したシステム障害の原因調査、応急対策、再発防止策を実施するとともに、関係者への連絡及び報,,,,,,,,, ,,告を適時に行わなければならない。,,,,,,,,, ,,　本問では、情報システムの可用性確保及び障害対応に関する監査を実施するに当たり、システム監査人として,,,,,,,,, ,,、リスクとコントロール、監査手続を設定するために必要となる見識や技能があるかどうかを問う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問２（情報システムの可用性確保及び障害対応に関する監査について）は、多くの情報システムに該当する基,,,,,,,,, ,,本的なテーマである。設問アでは、障害発生時の業務への影響について、具体性のある論述をしている解答は,,,,,,,,, ,,少なかった。設問イでは、ほとんどの受験者が可用性確保と障害対応のコントロールについて何らかの論述をし,,,,,,,,, ,,ていた。しかし、早期発見のコントロールについて論述できている受験者は少なく、問題文をよく読まないまま解,,,,,,,,, ,,答している受験者が多かったように思われる。設問ウでは、どのような監査証拠を入手し、具体的に何を確認す,,,,,,,,, ,,るかまで論述できている受験者は少なかった。情報システムに関わるリスクとコントロール、監査の手続きの関係,,,,,,,,, ,,をしっかりと理解してほしい。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　情報システムの概要及び発生した障害,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　A社は事務用品の製造・販売会社であり、A社のコンピュータセンタでは、販売管理、購買管理、在庫管理、食材,,,,,,,,, ,,管理、原価管理、会計などの基幹システムを稼働させている。基幹システムは昼間のオンライン処理や夜間のバ,,,,,,,,, ,,ッチ処理で構成されている。基幹システムの重要なマスタファイルの一つに端末属性管理テーブルがある。,,,,,,,,, ,,,,,,,,,,, ,１．２　発生した障害の内容及びサービス、業務への影響,,,,,,,,,, ,,,,,,,,,,, ,,　A社の端末の増設に伴い、端末属性管理テーブルの定義変更が必要となった。A社のITサービス部門の要員が,,,,,,,,, ,,メンテナンスを行ったところ障害が発生した。エラーメッセージを確認したところ、磁気ディスク障害であることが判,,,,,,,,, ,,明した。,,,,,,,,, ,,　端末管理テーブルは、ミラーリングされている磁気ディスク装置に格納されている。障害が発生した以前から、,,,,,,,,, ,,磁気ディスク装置に障害があり、二重化されていない状況で運用されていることが判明した。後でヒアリングを行,,,,,,,,, ,,った結果、磁気ディスク装置の修理については、障害が発生した日の翌週にある三連休後に二重化を再開する,,,,,,,,, ,,予定であった。,,,,,,,,, ,,　A社では、開発用サーバに接続されている磁気ディスク装置を本番のサーバに接続し、必要なデータをリストア,,,,,,,,, ,,し、再処理することでITサービスを復旧した。復旧作業によって、ITサービスへの影響としては、オンラインによるI,,,,,,,,, ,,Tサービスの開始が2時間遅れた。,,,,,,,,, ,,　業務への影響としては、ユーザ部門から”ITサービスが使えない。障害発生の連絡も来ていない。どうなってい,,,,,,,,, ,,るのか”というクレームがITサービス部門に向けられた。結果的にA社の基幹業務は2時間遅れで開始するという,,,,,,,,, ,,影響があった。,,,,,,,,, ,,,,,,,,,,, ,第2章　コントロール,,,,,,,,,, ,２．１　可用性確保のためのコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　可用性を確保するためには、障害の兆候を監視して、予防的な対策を迅速に講じることが重要である。そのた,,,,,,,,, ,,めには、以下のコントロールが効果的である。,,,,,,,,, ,,,,,,,,,,, ,,（１）,,ハードウェアごとに重要度を設定して、重要度に応じた障害監視策を講じる,,,,,,, ,,,,,,,,,,, ,,,　ハードウェアに重要度を設定し、可用性への影響の高いハードウェアに応じた障害監視策を講じることが重,,,,,,,, ,,,要であると考える。なぜならば、すべてのハードウェアを監視することは、費用対効果の面で合理的ではない,,,,,,,, ,,,からである。,,,,,,,, ,,,,,,,,,,, ,,（２）,,ハードウェア障害が発生する兆候を検知したら、ハードウェアの特徴を踏まえた規定時間内に臨時保守を,,,,,,, ,,,,行う,,,,,,, ,,,,,,,,,,, ,,,　設問アで述べた障害では、ハードウェア障害が表面化する兆候があったにもかかわらず対応を先送りしてい,,,,,,,, ,,,た。このような状況を再発させないために、兆候を検知してから対応するまでの時間を規定して、問題の兆候,,,,,,,, ,,,への対応を先送りしないための仕組みが必要であると考えた。,,,,,,,, ,,,,,,,,,,, ,２．２　障害対応のためのコントロール,,,,,,,,,, ,,,,,,,,,,, ,,　障害が発生した場合、業務やサービスに与える障害度合に応じた対応が重要である。対応としては、次に述べ,,,,,,,,, ,,るように、ITサービス部門内でのエスカレーションと利用者部門へのアナウンスの二通りがある。,,,,,,,,, ,,,,,,,,,,, ,,（１）,,障害が発生した場合、業務やサービスに与える影響度合いに応じた障害影響度を設定して、障害影響度,,,,,,, ,,,,に応じたエスカレーションを行う,,,,,,, ,,,,,,,,,,, ,,,　障害影響度の大きい障害が発生したにも関わらず、ITサービス部門の長に報告されていない状況では、IT,,,,,,,, ,,,サービスの迅速な復旧は難しい。しかし、軽微な障害でも報告されるようでは、問題がある。したがって、障害,,,,,,,, ,,,影響度に応じたエスカレーションを実施することが重要であると考えた。,,,,,,,, ,,,,,,,,,,, ,,（２）,,障害が発生した場合は、規定時間内に、障害により影響を受ける利用者部門にITサービスの状況につい,,,,,,, ,,,,て連絡し、さらに一定時間ごとに復旧状況を連絡する,,,,,,, ,,,,,,,,,,, ,,,　ITサービスに依存する業務を行う利用者部門では、ITサービスが停止すると業務が停止することになる。し,,,,,,,, ,,,たがって、障害が発生した場合は、適宜、利用者部門に復旧状況を提供することが重要であると考えた。なぜ,,,,,,,, ,,,ならば、復旧にかかる時間を利用者部門が知ることで、利用者部門の顧客への対応が適切にとれるからであ,,,,,,,, ,,,る。,,,,,,,, ,,,　さらに、ITサービスが復旧した場合、利用者部門に復旧の確認をもらうことも重要であると考えた。,,,,,,,, ,,,　以上が必要と考える、主なコントロールである。,,,,,,,, ,,,,,,,,,,, ,第3章,,,,,,,,,, ,３．１　可用性確保の適切性を監査するための手続き,,,,,,,,,, ,,,,,,,,,,, ,,　前述の障害に対する抜本的な対策が終了した段階で、A社のシステム監査部門に勤務する私はシステム監査,,,,,,,,, ,,人の立場で、可用性確保と障害対応の適切性をシステム監査することになった。,,,,,,,,, ,,　以下は、可用性確保の適切性を監査するための手続きである。,,,,,,,,, ,,,,,,,,,,, ,,（１）,,システム構成図を入手して、ITサービスマネージャにヒアリングを行い、重要なハードウェアへの障害監視,,,,,,, ,,,,策の内容を確認する。,,,,,,, ,,,,,,,,,,, ,,,　確認すべきポイントは次の二つである。,,,,,,,, ,,,,,,,,,,, ,,,①,重要なハードウェアに対して網羅的に障害監視策が講じられていることである。重要にもかかわらず、障害,,,,,,, ,,,,監視されていないハードウェアがないことを確認する。,,,,,,, ,,,②,検知にかかる所要時間が適切であるかということである。監視間隔が長いと検知に時間がかかり、対策が,,,,,,, ,,,,後手に回ることがあるからである。,,,,,,, ,,,,,,,,,,, ,,（２）,,監視中に障害の兆候を検知した場合、その兆候に応じた対応策を検討する、あるいは、対策を講じる手続,,,,,,, ,,,,きが明文化されている規定類や障害対応マニュアルを入手して精査する。,,,,,,, ,,,,,,,,,,, ,,,　確認すべきポイントとしては、兆候に応じた各種の対応策が妥当な網羅率で網羅されていることを確認す,,,,,,,, ,,,る、を挙げることができる。,,,,,,,, ,,,,,,,,,,, ,,　以上のように、予防や検知の観点から監査することが効果的である。,,,,,,,,, ,,,,,,,,,,, ,３．２　障害対応の適切性を監査するための手続き,,,,,,,,,, ,,,,,,,,,,, ,,　障害対応では利用者の観点から監査するための手続きを検討する。SLAを締結している場合、そのサービスレ,,,,,,,,, ,,ベルを達成する観点で、手続きを適用することも重要であると考える。,,,,,,,,, ,,,,,,,,,,, ,,（１）,,発生した障害に設定する障害影響度について記載されている手順書を入手して精査する。,,,,,,, ,,,,,,,,,,, ,,,　確認すべきポイントは、①障害影響度が、月末などの繁忙期を考慮して妥当であること、②影響度に応じた,,,,,,,, ,,,エスカレーションの記載が妥当であること、である。,,,,,,,, ,,,,,,,,,,, ,,（２）,,障害の発生状況や復旧状況を利用者部門に通知することを記す手順書を入手して精査する。障害報告書,,,,,,, ,,,,を入手して、該当する利用者部門にヒアリングを行う。,,,,,,, ,,,,,,,,,,, ,,,　確認すべきポイントは、①障害を利用者にアナウンスする担当者が専任で割り当てられているか、②利用者,,,,,,,, ,,,部門は、障害のアナウンスについて満足しているか、③SLAに障害のアナウンスについてサービスレベルを設,,,,,,,, ,,,定している場合は該当する目標値を達成しているかである。,,,,,,,, ,,,,,,,,,,, ,,　以上が障害対応の適切性を監査するための手続きである。　以上,,,,,,,,, ,,,,,,,,,,, 平成25年度　問1　システム運用業務の集約に関する監査について,,,,,,,,,,, ,,,,,,,,,,, ,　これまで、多くの組織では、アプリケーションシステムごとにサーバを設置し、その単位で個別にシステム運用業務,,,,,,,,,, ,を行ってきた。その場合、データのバックアップ、セキュリティパッチの適用、障害監視などの業務が、システムごとに,,,,,,,,,, ,異なる頻度・手順で行われることが多く、システム間で整合が取れていなかったり、本来共通化できるはずの業務が,,,,,,,,,, ,重複したりしていた。,,,,,,,,,, ,　近年は、これらのシステム運用業務を集約する組織が増えてきている。例えば、仮想化技術を活用してサーバを,,,,,,,,,, ,統合する際に、併せてシステム運用業務を集約する場合などである。サーバの統合は、多くの組織にとってシステム,,,,,,,,,, ,資源の有効活用、省スペース、省電力などの直接的なメリットだけでなく、システム運用業務を見直す契機をもたら,,,,,,,,,, ,している。,,,,,,,,,, ,　システム運用業務を集約し、システム運用手順を標準化することによって、業務の品質改善・効率向上に取り組み,,,,,,,,,, ,やすくなる。さらに、運用要員の削減などによってコストを適正化することも可能になる。ただし、業務手順の見直し,,,,,,,,,, ,方法に問題があったり、過度に集約しすぎたりすると、必要な手順が漏れたり、特定要員に付加が集中したりするな,,,,,,,,,, ,どの懸念もある。,,,,,,,,,, ,　システム監査人は、このような点を踏まえ、システム運用業務の集約によって期待していた効果が得られているか,,,,,,,,,, ,など、システム運用業務の集約の適切性を評価する必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係する組織で実施または検討されているシステム運用業務の集約に関する概要を、集約前と,,,,,,, ,,,,集約後の違いを踏まえて、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アに関連して、システム運用業務を集約する場合の留意点について、システム運用手順、システム運,,,,,,, ,,,,用体制などの観点を踏まえて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イに関連して、システム運用業務の集約の適切性を監査するための手続きを、700字以上1400字以内,,,,,,, ,,,,で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　仮想化技術を用いてサーバ統合を図る組織が増えている。しかし、サーバを統合するだけで、システム運用業,,,,,,,,, ,,務の集約を行わなければ、運用コストの削減につながるわけではない。,,,,,,,,, ,,　システム監査人は、業務の品質改善、業務の効率向上、コストの適正化といったシステム運用業務集約のメリ,,,,,,,,, ,,ットだけではなく、システム運用業務の集約に伴って生じる可能性のあるリスクを適切に把握できなければならな,,,,,,,,, ,,い。,,,,,,,,, ,,　本問では、システム運用業務集約のメリット及びリスクを踏まえた上で、監査人としてシステム運用業務の集約,,,,,,,,, ,,の適切性を監査するための知識と技能を問う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問１（システム運用業務の集約に関する監査について）では、仮想化技術を活用したサーバ統合を主題にした,,,,,,,,, ,,論述が多く見られた。しかし、設問ア及び設問イは、サーバ統合の技術的な実現方法ではなく、システム運用業,,,,,,,,, ,,務の集約に関する概要や留意点を問う問題であったため、出題趣旨に合わない解答が目立った。設問ウは監,,,,,,,,, ,,査手続を問う問題であったが、監査で確認すべき項目だけが述べられている場合が多く、どのような手段、方法,,,,,,,,, ,,によって確認すべきかの具体的な手続きが論述できている解答は少なかった。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,１－１　システム運用業務の集約の概要,,,,,,,,,, ,,,,,,,,,,, ,,　私の勤務するC社は電子機器の製造業で、本社工場を含めて国内7か所に生産拠点を有する。2年前のシステ,,,,,,,,, ,,ム統合までは、生産管理や経理、電子メールなどの全社システムを除いて、多くのアプリケーションシステムが拠,,,,,,,,, ,,点ごとに導入及び運用されていた。,,,,,,,,, ,,　システム統合の目的は、運用の品質向上とコスト削減である。統合では、一部のファイルサーバを除くアプリケ,,,,,,,,, ,,ーションサーバとストレージを本社工場に移設し、仮想化技術を活用して、152台の物理サーバを40台に集約した,,,,,,,,, ,,。同時に、ディザスタリカバリシステム（以下、DRシステムと書く）を別の拠点に構築した。,,,,,,,,, ,,　システムの統合に伴って、システム運用業務の集約を実施した。その概要を次に述べる。,,,,,,,,, ,,,,,,,,,,, ,,（１）運用の自動化,,,,,,,,, ,,,,,,,,,,, ,,,　集約前は、手作業のオペレーションが多く、人的ミスに起因する障害の割合が高かった。集約後は、運用基,,,,,,,, ,,,盤の統一を契機にツールを積極導入することで、オペレーションの自動化を推進して、障害の低減を目指し,,,,,,,, ,,,た。,,,,,,,, ,,,,,,,,,,, ,,（２）運用の標準化,,,,,,,,, ,,,,,,,,,,, ,,,　集約前は、全社システムを除くシステムの運用は拠点の裁量に任され、個々の規定に基づいて運用されて,,,,,,,, ,,,いた。集約後は、ルールや手順を標準化することによって運用品質のばらつきをなくし、特にさまざまなオペレ,,,,,,,, ,,,ーションが属人的な作業になっているという課題を解決する狙いがあった。,,,,,,,, ,,,,,,,,,,, ,,（３）運用体制,,,,,,,,, ,,,,,,,,,,, ,,,　集約前は、拠点ごとに運用チームが配置されていた。集約後は、本社工場とDRシステムの2か所に配置さ,,,,,,,, ,,,れる。要員の集約によって、運用コストの削減を目指した。,,,,,,,, ,,,,,,,,,,, ,２－１　システム運用業務を集約する場合の留意点,,,,,,,,,, ,,,,,,,,,,, ,,　運用業務の集約における留意点としては、集約の狙い通りの効果が達成できるか、あるいは集約による新たな,,,,,,,,, ,,リスクが発生しないかなどをチェックする必要がある。運用手順と運用体制の観点を踏まえた留意点を以下に3つ,,,,,,,,, ,,述べる。,,,,,,,,, ,,,,,,,,,,, ,,（１）自動化と標準化に起因する障害発生リスク,,,,,,,,, ,,,,,,,,,,, ,,,　集約の概要で述べたように、オペレーションの自動化は、業務の効率化とともに人的ミスによる障害の低減,,,,,,,, ,,,を狙いとしている。しかし、当社の障害履歴を分析したところ、オペレーションを自動化したことによって障害が,,,,,,,, ,,,発生した事案が見られた。例えば、サーバの定期リブート作業では、サーバごとに異なる細かなパラメタの設,,,,,,,, ,,,定作業が必要である。この事案では、自動化によって必要な設定作業がスキップされたことが直接の原因とな,,,,,,,, ,,,っていた。,,,,,,,, ,,,　また、標準化によっても個々に必要な作業が除外されるリスクがある。オペレーションの標準化と自動化で,,,,,,,, ,,,は、十分な検証が必要であると考える。,,,,,,,, ,,,,,,,,,,, ,,（２）サービスデスクの品質低下リスク,,,,,,,,, ,,,,,,,,,,, ,,,　サービスデスク業務に従事する要員は、効率稼働という目標を達成するために、本社工場への異動後に全,,,,,,,, ,,,拠点のアプリケーションを担当する。そのため、集約前と比較して、アプリケーションに関する幅広い知識が求,,,,,,,, ,,,められる。また、従来は拠点では解決できない問合せを本社工場のサービスデスクにエスカレーションするケ,,,,,,,, ,,,ースが多く見られた。集約後は、一時回答率の向上という品質目標の達成のためにも、要員はこれまでより高,,,,,,,, ,,,いレベルの対応が求められる。業務を支援する仕組みや要員教育の施策がないと、サービスデスクの品質向,,,,,,,, ,,,上が達成できず、逆に低下するリスクがあると考える。,,,,,,,, ,,,,,,,,,,, ,,（３）拠点における現地対応力の低下リスク,,,,,,,,, ,,,,,,,,,,, ,,,　集約前は、運用要員が各拠点に配置されていた。そのため、例えばパソコンの不具合や操作指導などにお,,,,,,,, ,,,いて、必要な場合には要員がエンドユーザのいる現場に行って直接対応することができた。集約後は、エンド,,,,,,,, ,,,ユーザのサポートは、本社工場からのリモート対応になる。そのため、特に端末にかかわる対応に遅れが生じ,,,,,,,, ,,,たり、エンドユーザの満足度が低下したりするリスクがあると考える。,,,,,,,, ,,,,,,,,,,, ,３－１　システム運用業務の集約の適切性を監査するための手続,,,,,,,,,, ,,,,,,,,,,, ,,　前項の３つの留意点を対象に、集約の適切性を監査するための手続きを以下に述べる。,,,,,,,,, ,,,,,,,,,,, ,,（１）自動化と標準化に起因する障害発生リスク,,,,,,,,, ,,,,,,,,,,, ,,,　次の監査項目を設定する。,,,,,,,, ,,,,,,,,,,, ,,,①,自動化や標準化、システム環境の移行などによって、従来のオペレーション手順から変更になる作業が管,,,,,,, ,,,,理されているか,,,,,,, ,,,②,作業手順の変更の妥当性のレビュー、事前及び事後の検証や評価方法は適切か,,,,,,, ,,,③,集約によって運用品質や効率の向上の目標が達成されているか,,,,,,, ,,,,,,,,,,, ,,,　監査は、予備調査においてヒアリングを実施し、管理方法や評価方法、記録簿の名称といったコントロー,,,,,,,, ,,,ル内容を把握する。本調査では、該当するドキュメントを閲覧して、自動化と標準化が適切に進められている,,,,,,,, ,,,こと、目標の達成度を確認する。,,,,,,,, ,,,,,,,,,,, ,,（２）サービスデスクの品質低下リスク,,,,,,,,, ,,,,,,,,,,, ,,,　次の監査項目を設定する。,,,,,,,, ,,,,,,,,,,, ,,,①,サービスデスクの要員の業務を支援の仕組みや教育が適切に計画、実施されているか,,,,,,, ,,,②,サービスデスクの品質向上が目標を達成しているか,,,,,,, ,,,,,,,,,,, ,,,　監査は、サービスデスクのリーダへのヒアリングとメンバへのアンケートを実施して、課題と解決のための施,,,,,,,, ,,,策内容を確認する。アンケートの結果に基づき、メンバへのヒアリングを実施して、施策の妥当性を評価する。,,,,,,,, ,,,品質目標に関しては、サービスデスクの対応レポートを閲覧して、一次回答率をはじめとするサービス指標と,,,,,,,, ,,,エンドユーザの声を確認する。,,,,,,,, ,,,,,,,,,,, ,,（３）拠点における現地対応力の低下リスク,,,,,,,,, ,,,,,,,,,,, ,,,　次の監査項目を設定する。,,,,,,,, ,,,,,,,,,,, ,,,①,エンドユーザのリモートサポートに関して、インシデント対応のサービスレベルの低下がないか,,,,,,, ,,,②,エンドユーザのリモートサポートに関して、エンドユーザの満足度低下がないか,,,,,,, ,,,,,,,,,,, ,,,　監査は、インシデントレポートのサマリを閲覧して、集約前と集約後のインシデント対応のサービスレベルを,,,,,,,, ,,,比較する。さらに、サービスデスクの対応レポートを閲覧して、エンドユーザの声を確認するとともに、拠点の,,,,,,,, ,,,エンドユーザにアンケートを実施する。　以上,,,,,,,, ,,,,,,,,,,, 平成25年度　問2　要件定義の適切性に関するシステム監査について,,,,,,,,,,, ,,,,,,,,,,, ,　システムを正常に稼働させ、期待通りの効果を得るには、システム開発において、業務機能を対象とする機能要,,,,,,,,,, ,件と、性能、セキュリティなどの非機能要件を適切に定義し、システムに組み込むことが必要である。適切な要件定,,,,,,,,,, ,義が行われなかったり、要件が適切にシステムに組み込まれなかったりすると、プロジェクトの失敗及びトラブルが,,,,,,,,,, ,生じる可能性が高くなる。,,,,,,,,,, ,　要件定義を適切に行うためには、システム開発のプロジェクト体制及び開発手法に合わせた要件定義の役割分担,,,,,,,,,, ,、方法、文書化などが必要となる。例えば、システム開発を外部に委託するプロジェクト体制では、要件定義委おけ,,,,,,,,,, ,るシステム部門と利用部門との役割分担だけでなく、外部委託先との役割分担も明確にしておかなければならない,,,,,,,,,, ,。また、ウォータフォール型の開発手法を用いる場合と、プロトタイピング手法を用いる場合とでは、要件定義の方法,,,,,,,,,, ,、作成すべき文書などが異なってくる。,,,,,,,,,, ,　システム監査人は、システム開発プロジェクトの失敗及びトラブルを防止するために、システム開発のプロジェクト,,,,,,,,,, ,体制及び開発手法を踏まえた上で、要件定義の役割分担、方法、文書化状況などが適切かどうかを確認する必要,,,,,,,,,, ,がある。また、要件定義の適切性を監査するための手続きは、要件定義工程だけでなく、システム開発の企画、プロ,,,,,,,,,, ,ジェクト体制の決定、設計、テストの各工程においても実施する必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係したシステム開発の概要について、システム開発のプロジェクト体制及び開発手法、並びに,,,,,,, ,,,,要件定義の役割分担、方法、文書化状況などを含め、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アのシステム開発において、適切な要件定義が行われなかったり、要件が適切にシステムに組み込,,,,,,, ,,,,まれなかったりした場合に、生じる可能性のあるプロジェクトの失敗及びトラブルについて、その原因を含,,,,,,, ,,,,めて700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イに関連して、要件定義の適切性について監査を実施する場合、システム開発の企画、プロジェクト,,,,,,, ,,,,体制の決定、要件定義、設計、テストの五つの工程でそれぞれ実施すべき監査手続を700字以上1400字,,,,,,, ,,,,以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　システム開発の中止、大幅な遅延、大幅な予算超過、期待効果の未達成などのプロジェクトの失敗、及び大規,,,,,,,,, ,,模障害、外部委託先との訴訟などのトラブルの要因の一つとして、要件定義の失敗が挙げられる。,,,,,,,,, ,,　システム監査人は、要件定義とそのシステムへの組込みについて、システム開発の体制や手法にあった適切,,,,,,,,, ,,な役割分担、方法、文書化などが行われているかを確認することによって、要件定義の失敗によるプロジェクトの,,,,,,,,, ,,失敗やトラブルの防止に貢献することができる。,,,,,,,,, ,,　本問では、システム監査人がシステム開発の各工程において適切な監査手続を実施できる能力があるかを問,,,,,,,,, ,,う。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問２（要件定義の適切性に関するシステム監査について）は、身近なテーマであるので、設問イ及び設問ウにつ,,,,,,,,, ,,いては、多くの受験者が一通りの論述はできていた。しかし、一般的かつ抽象的な論述に留まっている解答が散,,,,,,,,, ,,見された。設問イでは、プロジェクトの失敗の原因となる要件定義の問題点について論述を求めているが、”要員,,,,,,,,, ,,の能力不足”などの表面的な原因に留まり、なぜ適切な要員体制が確立されなかったのかといった根本問題ま,,,,,,,,, ,,で言及している論述は少なかった。また、設問ウの要件定義の適切性を監査する手続きについては、”要件定義,,,,,,,,, ,,書に要件が網羅されているかを確認する”などの一般的には現実的でない監査手続の論述が目立った。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　システム開発の概要,,,,,,,,,, ,１．１　プロジェクト体制及び開発手法,,,,,,,,,, ,,,,,,,,,,, ,,　電子部品を製造・販売するA社では、月次決算を現在の6営業日から4営業日に短縮することを目的に、原価管,,,,,,,,, ,,理システムの再構築を行った。当該プロジェクトでは、要件定義及び導入を準委任契約、外部設計から総合テ,,,,,,,,, ,,ストまでを請負契約でB社に委託した。,,,,,,,,, ,,　プロジェクト体制としては、A社のプロジェクトオーナの下で、A社では委託側プロジェクトマネージャ（以下、委託,,,,,,,,, ,,側PMという）、B社では受託側PMがあった。さらに、A社の委託側PMの下に原価管理部のユーザ部門チーム、A,,,,,,,,, ,,社のシステム開発部チームがあり、B社では、受託側PMの下に二つの開発チームがあった。,,,,,,,,, ,,　開発手法は、ウォータフォール型を採用していた。,,,,,,,,, ,,,,,,,,,,, ,１．２　要件定義の役割分担、方法、文書化の状況,,,,,,,,,, ,,,,,,,,,,, ,,　ウォータフォール型に合わせた要件定義の役割分担としては、A社側のユーザ部門チームが作成した機能要件,,,,,,,,, ,,をB社の開発チームが、機能要件と非機能要件を要件を要件定義書としてまとめる、という方法を採用した。,,,,,,,,, ,,　要件定義の方法は、A社のシステム開発チーム及びユーザ部門チームと、B社の開発チームの要員で構成され,,,,,,,,, ,,る要件検討会を週2回の割合で開催して、そこで決まった要件をユーザ部門チームがまとめ、それを開発チーム,,,,,,,,, ,,に渡していた。開発チームでは、類似システムの機能要件を基に、機能要件の漏れや誤りがないことを確認しな,,,,,,,,, ,,がら要件定義書にまとめていた。非機能要件については、B社の持つ非機能要件のひな形を利用した。,,,,,,,,, ,,　文書化の状況については、A社のシステム開発チームで要件定義書のレビューを逐次実施して、問題があれば,,,,,,,,, ,,要件定義検討会で検討するという管理施策を採用していたため、要件定義段階では問題のない品質レベルで,,,,,,,,, ,,あった。,,,,,,,,, ,,,,,,,,,,, ,第2章　生じる可能性のあるプロジェクトの失敗及びトラブル,,,,,,,,,, ,２．１　生じる可能性のあるプロジェクトの失敗及びトラブル,,,,,,,,,, ,,,,,,,,,,, ,,　私はA社システム監査部門のシステム監査人の立場で、当該プロジェクトの要件定義の適切性を監査するにあ,,,,,,,,, ,,たって、次に述べる各工程について、生じるプロジェクトの失敗やトラブルを挙げることとした。,,,,,,,,, ,,,,,,,,,,, ,２．２　システム開発の企画工程,,,,,,,,,, ,,,,,,,,,,, ,,　システム開発プロジェクトではプロジェクトの途中で委託側の予算不足となり、プロジェクトが中断されるケース,,,,,,,,, ,,がある。原因としては、要件の優先順位付けや承認体制が不十分で、要件定義において要件が膨張してしまい、,,,,,,,,, ,,システム開発規模が想定以上になることが考えられる。システム企画段階において、ある程度の要件の膨張を,,,,,,,,, ,,考慮した予算を委託側で確保していないことも、システム企画段階にある原因として考えられる。,,,,,,,,, ,,,,,,,,,,, ,２．３　プロジェクト体制の決定工程,,,,,,,,,, ,,,,,,,,,,, ,,　要件定義において、主体はユーザ部門である。ユーザ部門の従来の業務が忙しいなどの理由によって、ユー,,,,,,,,, ,,ザ部門の参画が疎かになると、要件定義のスケジュール遅延を招くことになる。プロジェクト体制の決定工程に,,,,,,,,, ,,ある原因としては、ユーザの参画意識の低さや、ユーザ部門の業務の繁忙期を考慮していない要件定義の役割,,,,,,,,, ,,分担やシステム開発スケジュールなどが考えられる。,,,,,,,,, ,,,,,,,,,,, ,２．４　要件定義工程,,,,,,,,,, ,,,,,,,,,,, ,,　機能要件を十分に盛り込んでも、性能面での非機能要件が疎かになると、業務効率の低下などの問題が総合,,,,,,,,, ,,テストで表面化してトラブルとなる。要件定義工程の原因としては、要件定義においてシステムの特徴を踏まえた,,,,,,,,, ,,非機能要件を盛り込んでいないなど文書化の方法に関する点を挙げることができる。,,,,,,,,, ,,　要件定義では、要件が膨張してしまい、要件定義のスケジュール遅延やシステム開発規模の増大が考えられ,,,,,,,,, ,,る。原因としては、要件の優先順位付けや承認体制が不十分という点を挙げることができる。,,,,,,,,, ,,,,,,,,,,, ,２．５　設計工程,,,,,,,,,, ,,,,,,,,,,, ,,　ウォータフォール型では要件の漏れや誤りによって、開発の手戻りが発生してしまうトラブルが考えられる。原,,,,,,,,, ,,因としては要件定義書のレビュー体制の不備などが考えられる。,,,,,,,,, ,,,,,,,,,,, ,２．６　テスト工程,,,,,,,,,, ,,,,,,,,,,, ,,　要件の漏れがあり、総合テスト段階に入って、要件が不足しているなどのトラブルが考えられる。原因としては,,,,,,,,, ,,要件定義書のレビュー体制の不備などが考えられる。,,,,,,,,, ,,,,,,,,,,, ,,　以上のトラブルを想定して、次に監査手続を述べる。,,,,,,,,, ,,,,,,,,,,, ,第3章　予見定義の適切性についての監査手続,,,,,,,,,, ,３．１　要件定義の監査の適切性についての監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　要件定義の適切性について、次の工程毎に実施する監査手続を述べる。,,,,,,,,, ,,,,,,,,,,, ,３．２　システム開発の企画工程,,,,,,,,,, ,,,,,,,,,,, ,,　要件の膨張を考慮した予算を確保していない原因によるシステム開発プロジェクトの中断については、システ,,,,,,,,, ,,ム企画書を入手して、委託側PMに予算の試算方法についてヒアリングを行い、十分な予算を確保している、ある,,,,,,,,, ,,いは確保していないことを示す監査証拠を得る。,,,,,,,,, ,,,,,,,,,,, ,３．３　プロジェクト体制の決定工程,,,,,,,,,, ,,,,,,,,,,, ,,　ユーザの参画意識の低さやユーザ部門の業務の繁忙期を考慮していないシステム開発スケジュールが原因と,,,,,,,,, ,,なる要件定義の進捗遅れについては、プロジェクト計画書を入手してプロジェクト体制や要件定義の役割分担を,,,,,,,,, ,,確認する。さらに、ユーザ部門の要員にヒアリングを行い参画意識の向上についての委託側PMからのアプロー,,,,,,,,, ,,チの有無やユーザ業務の繁忙期を意識した要件定義の役割分担やスケジュールになっていることを確認する。,,,,,,,,, ,,ユーザが要件定義に参画しやすい環境づくりをしている、あるいは、していないことを示す監査証拠を得る。,,,,,,,,, ,,,,,,,,,,, ,３．４　要件定義工程,,,,,,,,,, ,,,,,,,,,,, ,,　要件定義においてシステムの特徴を踏まえた非機能要件を盛り込んでいないことが原因のトラブルについては,,,,,,,,, ,,、非機能要件のひな型などを入手して、要件定義書にある非機能要件と突合して、システムの特徴を踏まえた非,,,,,,,,, ,,機能要件が設定されている、あるいは、されていないことを示す文書化の状況に関する監査証拠を得る。,,,,,,,,, ,,　要件の優先順位付けや承認体制が不十分であることが原因で生じるトラブルについては、要件の優先順位付,,,,,,,,, ,,けや承認体制に関する手順書、要件検討会の議事録を入手して内容を精査し、要件の膨張を抑える効果的な仕,,,,,,,,, ,,組みであること、効果的ではない仕組みであることを示す監査証拠を得る。,,,,,,,,, ,,,,,,,,,,, ,３．５　設計工程,,,,,,,,,, ,,,,,,,,,,, ,,　ウォータフォール型では要件の漏れや誤りによって、開発の手戻りが発生してしまうトラブルが考えられる、原,,,,,,,,, ,,因としては要件定義書のレビュー体制の不備などが考えられる。,,,,,,,,, ,,　設計工程の進捗管理資料を精査して、開発の手戻りが発生している、あるいは、発生していないことを示す監,,,,,,,,, ,,査証拠を得る。開発の手戻りが発生している場合は、作業を行った要員のヒアリングを行い、要件の漏れや誤り,,,,,,,,, ,,の原因を示す監査証拠を得る。,,,,,,,,, ,,,,,,,,,,, ,３．６　テスト工程,,,,,,,,,, ,,,,,,,,,,, ,,　テスト計画書、テスト実施報告書を入手して、要件定義書にある要件と突合し、要件の漏れや誤りがない、ある,,,,,,,,, ,,いは、あることを示す監査証拠を得る。要件の漏れや誤りがあった場合は、必要に応じて前述の要件定義で述べ,,,,,,,,, ,,た監査手続を実施する。,,,,,,,,, ,,,,,,,,,,, ,　以上が要件定義の適切性についての監査手続である。　以上,,,,,,,,,, ,,,,,,,,,,, 平成24年度　問2　システムの日常的な保守に関する監査について,,,,,,,,,,, ,,,,,,,,,,, ,　稼働中の情報システムや組込みシステムでは、関連する業務内容の変更、システム稼働環境の変更、システム不,,,,,,,,,, ,具合への対応などの目的で、マスタファイルの更新、システム設定ファイルの変更、プログラムの軽微な修正など、,,,,,,,,,, ,日常的な保守が必要になる。これらの保守は、業務の大幅な見直しに伴うシステム変更のような大規模な保守に比,,,,,,,,,, ,べて、短期間で対応しなければならない場合が多い。,,,,,,,,,, ,　例えば、新商品を発売したり、商品の売価を改訂したりする場合は、当該商品の発売や売価改訂のタイミングに合,,,,,,,,,, ,わせて、商品マスタファイルを変更する必要がある。また、プログラムやシステム設定ファイルなどの不備が原因で,,,,,,,,,, ,システム障害が発生した場合は、速やかに当該プログラムやシステム設定ファイルなどを修正して、システムを復旧,,,,,,,,,, ,しなければならない。,,,,,,,,,, ,　一方で、これらの日常的な保守は、当該システムの開発に携わっていない保守要員が行ったり、外部に委託したり,,,,,,,,,, ,することも多い。また、システムの利用部門がマスタファイルへの追加や変更を行う場合もある。もし、誤った変更や,,,,,,,,,, ,修正が行われると、その影響はシステムの誤作動や処理遅延に留まらず、システムの停止などに至ることもある。,,,,,,,,,, ,　システム監査人は、このような状況を踏まえて、情報システムや組込みシステムの日常的な保守が適切に行われ,,,,,,,,,, ,ているかどうかを確認する必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係した情報システム又は組込みシステムの概要と、当該システムの日常的な保守の体制及び,,,,,,, ,,,,方法について、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アで述べたシステムの日常的な保守において、どのようなリスクが想定され、また、そのリスクはどの,,,,,,, ,,,,ような要因から生じるか。700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イで述べたリスクが生じる要因を踏まえて、当該システムの日常的な保守の適切性を監査する場合、,,,,,,, ,,,,どのような監査要点を設定するか。監査証拠と対応付けて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　情報システムや組込みシステムは、業務内容の変更、システム稼働環境の変化やシステム障害の問題解決の,,,,,,,,, ,,ために、プログラム、マスタファイル、設定ファイルなどを短期間で修正しなければならない場合が多い。しかし、,,,,,,,,, ,,システムの前提条件や上限値などの制約条件を考慮せずに修正してしまうなど、日常的な保守に対する安易な,,,,,,,,, ,,対応は、システム全体にまで影響を及ぼす恐れがある。,,,,,,,,, ,,　本問では、情報システムや組込みシステムの日常的な保守に関わるリスクを評価し、正しく保守が行われてい,,,,,,,,, ,,るかどうかを監査するための見識や能力について評価する。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問２（システムの日常的な保守に関する監査について）は、システム保守という基本的かつ一般的なテーマであ,,,,,,,,, ,,ったことから、最も選択率が高かった。問題文をよく読めば、短期間あるいは緊急で対応しなければならない保守,,,,,,,,, ,,についての出題だとわかるはずであるが、システム開発に準じた保守やシステム運用など、題意とあっていない,,,,,,,,, ,,論述が多く見受けられた。設問イでは、想定されるリスクに対する要因が不十分な論述が多く、情報セキュリティ,,,,,,,,, ,,の観点からの論述も散見された。設問ウでは、監査要点や監査証拠に関する論述が不十分な受験者が目立っ,,,,,,,,, ,,た。また、システム管理者の立場での論述や、設問では求めていない監査結果や改善提案などの論述も散見さ,,,,,,,,, ,,れた。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　情報システムの概要及び日常的な保守の体制及び方法,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　該当する情報システムは電子部品を製造・販売するA社の購買管理システムである。A社の購買管理システム,,,,,,,,, ,,は購買管理、資材在庫管理、生産計画などのサブシステムで構成されている。A社はグローバル企業であるため,,,,,,,,, ,,、原材料、中間製品などの資材はグローバルに在庫情報が管理されている。そのためA社の米国本社の情報シ,,,,,,,,, ,,ステム戦略に基づき、各国で稼働する購買管理システムが一律に保守されるという情報システムの特徴がある。,,,,,,,,, ,,　なお、各国で稼働している購買管理システムは、ERPパッケージを使用しているケースや、A社のように独自に,,,,,,,,, ,,システム開発をしているケースもある。,,,,,,,,, ,,,,,,,,,,, ,１．２　日常的な保守の体制及び方法,,,,,,,,,, ,,,,,,,,,,, ,,　日常的な保守については、次の二つのケースがある。,,,,,,,,, ,,,,,,,,,,, ,,（１）,,情報システム戦略に基づいた保守,,,,,,, ,,,,,,,,,,, ,,,　新たにグローバルにシステム間連携を行うビジネス拠点が増えた場合などは、これに該当する。この場合、,,,,,,,, ,,,システム保守担当者が保守要望書を作成する。,,,,,,,, ,,,,,,,,,,, ,,（２）利用者部門の要望による保守,,,,,,,,, ,,,,,,,,,,, ,,,　購買管理システムの業務内容の変更により、保守が発生するケースがこれに該当する。この場合、利用者,,,,,,,, ,,,部門のマネージャが保守要望書を作成し、システム保守担当者が保守に必要な工数や期間を見積もる。,,,,,,,, ,,,　保守要望書が作成された場合、保守体制として、システム保守担当者及びその上司、ユーザ部門の担当,,,,,,,, ,,,者から構成される購買管理システム保守会議を開催する。,,,,,,,, ,,,　方法としては、保守要望書の内容に基づいた費用対効果のレビューや、保守期日の妥当性の確認を行い、,,,,,,,, ,,,保守の可否を決定する。,,,,,,,, ,,,,,,,,,,, ,第2章　想定したリスク及びリスク要因,,,,,,,,,, ,２．１　想定したリスク,,,,,,,,,, ,,,,,,,,,,, ,,　A社のシステム監査部門は、A社の米国本社のシステム監査部門が作成した監査スケジュールに従って、A社,,,,,,,,, ,,で稼働する購買管理システムの日常的な保守の適切性を監査することになった。私はA社のシステム監査部門,,,,,,,,, ,,のシステム監査人である。,,,,,,,,, ,,　想定したリスクとしては、次の項目を挙げることができる。,,,,,,,,, ,,,,,,,,,,, ,,（１）デグレードのリスク,,,,,,,,, ,,,,,,,,,,, ,,,　保守内容については問題がないが、以前稼働していた機能が使えないというデグレードのリスクがあると考,,,,,,,, ,,,えた。,,,,,,,, ,,,,,,,,,,, ,,（２）性能劣化のリスク,,,,,,,,, ,,,,,,,,,,, ,,,　テスト環境では機能的には問題がないが、本番環境にリリースした状態では、性能が劣化してしまうリスクが,,,,,,,, ,,,あると考えた。,,,,,,,, ,,,,,,,,,,, ,,（３）システム間連携におけるシステム不整合のリスク,,,,,,,,, ,,,,,,,,,,, ,,,　システム間連携がグローバルに行われているため、A社では問題がないが、他国のビジネス拠点で稼働す,,,,,,,, ,,,るシステムに不整合が発生するリスクがあると考えた。,,,,,,,, ,,,,,,,,,,, ,,　購買管理システムについて、以上のリスクがあると考えた。,,,,,,,,, ,,,,,,,,,,, ,２．２　リスク要因,,,,,,,,,, ,,,,,,,,,,, ,,　日常的な保守におけるリスクを踏まえ、次のリスク要因があると考えた。,,,,,,,,, ,,　デグレードのリスクのリスク要因は次の通りである。,,,,,,,,, ,,,,,,,,,,, ,,（１）,,レグレッションテストを含めた保守に関する手順がわかりやすく文書化されていない。,,,,,,, ,,（２）,,レグレッションテスト用のデータが整備されていない。,,,,,,, ,,,,,,,,,,, ,,　性能劣化のリスクのリスク要因は次のとおりである。,,,,,,,,, ,,,,,,,,,,, ,,（３）,,保守要望書において性能目標に関する配慮がない。あるいは、あっても妥当ではない。性能劣化が想定で,,,,,,, ,,,,きる場合、本番環境を配慮した状態で性能テストを実施していない。,,,,,,, ,,,,,,,,,,, ,,　システム連携におけるシステム不整合のリスクのリスク要因は次の通りである。,,,,,,,,, ,,,,,,,,,,, ,,（４）,,保守要望書においてシステム間連携におけるシステム不整合への配慮をしていない。あるいは、あっても,,,,,,, ,,,,妥当ではない。,,,,,,, ,,,,,,,,,,, ,,　リスクを踏まえ、以上のリスク要因があると考えた。,,,,,,,,, ,,,,,,,,,,, ,第３種　リスク要因を踏まえた監査要点,,,,,,,,,, ,３．１　リスク要因を踏まえた監査要点と監査証拠,,,,,,,,,, ,,,,,,,,,,, ,,　レグレッションテストに関するリスク要因を踏まえると、次の監査要点を挙げることができる。,,,,,,,,, ,,,,,,,,,,, ,,（１）,,レグレッションテストを含めた保守に関する手順書がわかりやすくメンテナンスされているか。,,,,,,, ,,,,,,,,,,, ,,,　監査証拠としては、手順書及び手順書の保守履歴を得る。さらに、手順書を基に保守要員にヒアリングを行,,,,,,,, ,,,い、手順書が最新であり、分かりやすいことを示す監査証拠を得る。,,,,,,,, ,,,,,,,,,,, ,,（２）,,レグレッションテストに必要なテストデータを保守の度に整備しているか。,,,,,,, ,,,,,,,,,,, ,,,　監査証拠としては、保守要望書、保守対象のプログラムリスト、プログラムに対応したレグレッションテスト用,,,,,,,, ,,,のテストデータ一覧を得る。これらを保守要望書に対応したプログラムから、レグレッションテスト用のテストデ,,,,,,,, ,,,ータが最新に整備されている、あるいはされていないことを示す証拠とする。,,,,,,,, ,,,,,,,,,,, ,,　性能劣化に関するリスク要因を踏まえると、次の監査要点を挙げることができる。,,,,,,,,, ,,,,,,,,,,, ,,（３）,,保守要望書において性能目標に関する配慮があるか。性能劣化が想定できる場合、本番環境を配慮した,,,,,,, ,,,,状態で性能テストを実施しているか。,,,,,,, ,,,,,,,,,,, ,,,　保守要望書と当該保守に関連する性能テスト結果を監査証拠とする。保守要望書において性能劣化が想定,,,,,,,, ,,,できた場合、適切に性能テストを実施している、あるいは、されていないことを示す証拠とする。,,,,,,,, ,,,,,,,,,,, ,,　システム連携におけるシステム不整合のリスク要因を踏まえると、次の監査要点を挙げることができる。,,,,,,,,, ,,,,,,,,,,, ,,（４）,,保守要望書においてシステム間連携に関する配慮があるか。システム不整合が想定できる場合、システ,,,,,,, ,,,,ム間連携のデータを検証する計画を立案して実施しているか。,,,,,,, ,,,,,,,,,,, ,,,　保守要望書と、当該保守に関連するシステム間連携用のデータの検証結果を監査証拠とする。保守要望書,,,,,,,, ,,,においてシステム不整合が想定できた場合、適切にシステム間連携データを検証している、あるいは、してい,,,,,,,, ,,,ないことを示す証拠とする。,,,,,,,, ,,,,,,,,,,, ,,（５）,,保守要望書に記載された内容が妥当か。,,,,,,, ,,,,,,,,,,, ,,,　保守要望書に、性能劣化を想定する必要はないと記載されている場合であっても、実際には性能劣化が発,,,,,,,, ,,,生しているケースなどが考えられる。そこで、A社のサービスデスクのインシデント受付一覧と保守要望書とを,,,,,,,, ,,,突合せして、保守要望書において想定外のインシデントが発生していないことを確認して、保守要望書の記載,,,,,,,, ,,,内容の正確性を示す監査証拠とする。,,,,,,,, ,,,,,,,,,,, ,,　以上が、日常的な保守への監査の要点である。　以上,,,,,,,,, ,,,,,,,,,,, 平成24年度　問3　情報システムの冗長化対策とシステム復旧手順に関する監査について,,,,,,,,,,, ,,,,,,,,,,, ,　今日、社会に広く浸透している情報システムが自然災害、停電、システム障害などによって停止すれば、企業活動,,,,,,,,,, ,などに深刻な影響を及ぼしかねない。このことから、情報システムの冗長化対策及びシステム復旧手順の重要性に,,,,,,,,,, ,対する意識が、企業をはじめ社会全体で高まっている。,,,,,,,,,, ,　企業などでは、データセンタなどの拠点・施設、ハードウェア、ネットワーク、電源などの冗長化によって、情報シス,,,,,,,,,, ,テムの安定稼働を図っている。また、情報システムが停止した場合の復旧手順を定めて、停止時間をできる限り短く,,,,,,,,,, ,抑えることにも努めている。,,,,,,,,,, ,　システム復旧手順は、停止した情報システムを確実かつ迅速に復旧させるものでなければならない。そのために,,,,,,,,,, ,は、一度策定したシステム復旧手順を、状況の変化に応じて見直したり、システム復旧手順のテスト・訓練を定期的,,,,,,,,,, ,に行ったりして、継続的に改善していくことが重要である。,,,,,,,,,, ,　このような状況を踏まえると、システム監査においては、システム復旧手順が文書化されていることの形式的な確,,,,,,,,,, ,認だけでは不十分である。,,,,,,,,,, ,　システム監査人は、情報システムに適用された冗長化対策の妥当性を確認したり、システム復旧手順の内容、テ,,,,,,,,,, ,スト・訓練の実施状況などを確認したりすることによって、システム復旧手順がシステム停止時間の短縮に十分に寄,,,,,,,,,, ,与するものであるかどうかを評価する必要がある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係する組織の情報システムの概要を述べ、その冗長化対策及びシステム復旧手順策定の背,,,,,,, ,,,,景や必要性について、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アに関連して、当該情報システムの冗長化対策の検討過程において、どのような対策又は対策の組,,,,,,, ,,,,合せが比較され、採用されたか。想定される脅威が顕在化する可能性、顕在化した場合の影響度及び対,,,,,,, ,,,,策の経済合理性を踏まえて、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問アで述べたシステム復旧手順の実効性を監査する場合の監査手続を、設問イを踏まえて、700字以上,,,,,,, ,,,,1400字以内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　企業などにおいては、自然災害などの不測の事態によって、情報システムが停止してしまうと、業務が停止し、,,,,,,,,, ,,その結果として、収益の減少、顧客満足度の低下、社会的信頼の低下などの影響を招きかねない。したがって、,,,,,,,,, ,,このような影響を最小限にとどめるため、ハードウェアなどを冗長化して、情報システムが停止しにくい構成を築,,,,,,,,, ,,いたり、万一、情報システムが停止した場合でも、短時間で復旧できるようにシステム復旧手順を策定する必要,,,,,,,,, ,,がある。,,,,,,,,, ,,　本問では、情報システムの冗長化対策の適切性とシステム復旧手順の実効性を監査するための知識や能力を,,,,,,,,, ,,評価する。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　問３（情報システムの冗長化対策とシステム復旧手順における監査について）は、昨今、多くの組織で検討され,,,,,,,,, ,,ているテーマであり、勤務先などにおいて、関連する業務を実際に経験した受験者が多かったようである。しかし,,,,,,,,, ,,、設問イにおいて、問題で求めている内容を十分に論述できている答案は少なかった。情報システムの冗長化対,,,,,,,,, ,,策の検討過程における対策を比較した論述ではなく、単純に現在どのような冗長化対策が適用されているかを,,,,,,,,, ,,説明しただけの論述や、冗長化対策の経済合理性に全く触れていない論述など、出題の趣旨に合致していない,,,,,,,,, ,,論述が散見された。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　情報システムの概要及び冗長化対策及びシステム復旧手順策定の背景と必要性,,,,,,,,,, ,１．１　情報システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　該当する情報システムは、電子部品を製造・販売するA社における基幹システムである。A社では基幹業務を、,,,,,,,,, ,,ERPパッケージを採用して支援している。基幹システムは、販売業務、在庫管理業務、購買管理業務、資材管理,,,,,,,,, ,,業務、会計業務を支援している。なお、生産計画や生産管理については、A社の製造工場で稼働しているシステ,,,,,,,,, ,,ムで支援している。,,,,,,,,, ,,　該当する基幹システムは東京本社にあるコンピュータセンタに設置している仮想サーバ上で稼働している。A社,,,,,,,,, ,,において、東京本社に次いで規模の大きいビジネス拠点としては、大阪支店がある。,,,,,,,,, ,,,,,,,,,,, ,１．２　冗長化対策,,,,,,,,,, ,,,,,,,,,,, ,,　基幹システムの稼働開始時は、停電やシステム障害を対象とした冗長化対策が採られていた。,,,,,,,,, ,,　停電については、無停電電源装置や自家発電装置が設置されている。システム障害については、仮想サーバ,,,,,,,,, ,,のホットスワップによる二重化対策、磁気ディスク装置の三重化、ネットワーク経路の二重化、重要なネットワーク,,,,,,,,, ,,機器の二重化などの対策が施されていた。,,,,,,,,, ,,,,,,,,,,, ,１．３　システム復旧手順策定の背景と必要性,,,,,,,,,, ,,,,,,,,,,, ,,　東日本大震災を契機に、自然災害によるコンピュータセンタの機能停止による長期的なITサービスの停止がA,,,,,,,,, ,,社の経営陣において、経営課題として挙げられた。経営課題を受け、経営陣によるシステム復旧手順の見直しが,,,,,,,,, ,,指示された。これが背景である。,,,,,,,,, ,,　広域災害が発生した場合、現状では基幹システムのRTOは3日以内、RPOは1日以内と設定されていた。経営,,,,,,,,, ,,陣は、RTO及びRPOを1日以内とするように指示をした。これによりシステム復旧手順策定が必要となった。,,,,,,,,, ,,,,,,,,,,, ,第2章　情報システムの冗長化対策,,,,,,,,,, ,２．１　冗長化対策の検討過程,,,,,,,,,, ,,,,,,,,,,, ,,　経営陣が設定した目標を達成するために、システム復旧手順策定委員会が設置された。私はA社のシステム,,,,,,,,, ,,監査部門のシステム監査人であるが、策定委員会のメンバとして招集され策定作業に加わった。,,,,,,,,, ,,　自然災害などの広域災害に対応した冗長化対策を検討する場合、費用対効果を検討して、合理的な対策を実,,,,,,,,, ,,施する必要がある。そこで私は、定量的リスク分析を行い、リスクマネジメントを実施することとした。,,,,,,,,, ,,　最初に検討した事項は、広域災害の発生によって東京本社のコンピュータセンタが使えない場合の代替処理施,,,,,,,,, ,,設について、次の二つの案を検討した。,,,,,,,,, ,,,,,,,,,,, ,,,（１）,,代替処理施設を提供するサービス業者と契約する。,,,,,, ,,,（２）,,大阪支店にコンピュータセンタを新たに設置する。,,,,,, ,,,,,,,,,,, ,,　次に代替処理を行うコンピュータに、本番データを反映させる方法について、次の三つの案を検討した。,,,,,,,,, ,,,,,,,,,,, ,,,（１）,,DBMSの機能を活用し本番データベースの更新と、代替処理用のデータベースの更新を同期させる。,,,,,, ,,,（２）,,DBMSの機能を活用し本番データベースを非同期で更新する。,,,,,, ,,,（３）,,磁気ディスク装置の機能を用いて、ある時点でのデータベースの状態を、ネットワークを経由して代替,,,,,, ,,,,,処理に設置されたコンピュータに送る。,,,,,, ,,,,,,,,,,, ,,　以上の案を基に次のようにリスク対策を決定した。,,,,,,,,, ,,,,,,,,,,, ,２．２　脅威が顕在化する可能性、顕在化した場合の影響度及び対策の合理性を踏まえて採用された対策,,,,,,,,,, ,,,,,,,,,,, ,,　脅威が顕在化する可能性としては、広域災害となる自然災害が発生する可能性としては、通常のシステム障,,,,,,,,, ,,害に比べて低い。そのため、発生確率を大きめにするなどの配慮をしないとリスクが小さくなり、リスク対策の,,,,,,,,, ,,必要性がなくなる。したがって、脅威が顕在化する可能性として10年に1度とすることにした。,,,,,,,,, ,,　以上の考えを基に、定量的リスク分析を行い、リスク値を金額で算出することにした。次に冗長化対策に必要な,,,,,,,,, ,,費用を算出して、年間のリスク対策費用の合計が、リスク値以内になるようにして対策の合理性を確保しながら、,,,,,,,,, ,,リスク対策を採用することとした。,,,,,,,,, ,,　リスク対策費用の制約を踏まえて、現在使用している開発用仮想サーバを大阪支店に移設して代替処理コンピ,,,,,,,,, ,,ュータとし、磁気ディスク装置の機能を用いて、ある時点でのデータベースの状態を、ネットワークを経由して代替,,,,,,,,, ,,処理に設置されたコンピュータに送る方法を採用することになった。,,,,,,,,, ,,,,,,,,,,, ,第3章　システム復旧手順の実効性の監査,,,,,,,,,, ,３．１　監査する場合の監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　今回は策定員会のメンバであることから、私自身が実際に監査する可能性は低いが、監査する場合は次のよう,,,,,,,,, ,,に考える。,,,,,,,,, ,,,,,,,,,,, ,,（１）,,代替処理用コンピュータが基幹システムのサービスを提供するために十分な性能があるかを、本番システ,,,,,,, ,,,,ムと代替処理システムの両方のシステム構成図を入手して精査する。両者に処理性能が同等である、ある,,,,,,, ,,,,いは、同等でない監査証拠を得る。,,,,,,, ,,,,,,,,,,, ,,,,　大阪支店に現在使用している開発用仮想サーバを移設して代替処理コンピュータとしている点を踏まえ,,,,,,, ,,,,ると、処理性能が同等か、同等でない場合は縮退運転を考慮しているかが監査の要点となる。,,,,,,, ,,,,,,,,,,, ,,（２）,,冗長化対策の検討資料及びシステム復旧手順を入手して精査し、設定されたRTOやRPOを達成するため,,,,,,, ,,,,の合理的な対策が検討され選択されていることの監査証拠を得る。,,,,,,, ,,,,,,,,,,, ,,,,　定量的リスク分析が行われて、リスク値とリスク対策費用が合理的であるか、設定されたRTOやRPOを達,,,,,,, ,,,,成するために過剰な対策になっていないか、が監査の要点となる。,,,,,,, ,,,,,,,,,,, ,,（３）,,システム復旧手順の訓練計画や訓練結果を入手して精査し、定期的、あるいは、必要に応じて、訓練が実,,,,,,, ,,,,施されていること、RTO、RPOを達成できることを定期的に確認していることの監査証拠を得る。,,,,,,, ,,,,,,,,,,, ,,,,　東京本社と大阪支社の両方にコンピュータセンタが設置されている点を踏まえると、大規模な訓練となる,,,,,,, ,,,,。そのためには、適切な訓練計画を作成して、訓練結果をレビューして、継続的な改善に結びつけている,,,,,,, ,,,,か、新システムのリリースや大規模なシステムの改修に合わせてシステム復旧手順をテストしているか、,,,,,,, ,,,,が監査の要点となる。,,,,,,, ,,,,,,,,,,, ,,（４）,,策定されたシステム復旧手順が経営陣から承認されたものである証拠を入手して監査証拠とする。,,,,,,, ,,,,,,,,,,, ,,,,　自然災害が発生してシステム復旧手順を実施に移した場合、利用者部門から不平や不満がでることが,,,,,,, ,,,,想定できる。そのような状況下で実効性のあるシステム復旧手順にするためには、経営陣の承認を得てい,,,,,,, ,,,,る手順であることをアピールすることが効果的である。したがって、妥当なシステム復旧手順であることを,,,,,,, ,,,,証明するためにシステム復旧手順が経営陣から承認を得ているか、という監査の要点を挙げることができ,,,,,,, ,,,,る。,,,,,,, ,,,,,,,,,,, ,,　以上がシステム復旧手順の実効性を監査する場合の監査手続である。　以上,,,,,,,,, ,,,,,,,,,,, 平成22年度　問1　情報システム又は組込みシステムに対するシステムテストの監査について,,,,,,,,,,, ,,,,,,,,,,, ,　ITの進展に伴い、情報システムの役割はますます大きくなり、影響範囲も広がっている。例えば、生産システム、受,,,,,,,,,, ,発注システムなどの基幹系情報システムに不具合があると、自組織だけではなく、取引先などの業務にも影響が及,,,,,,,,,, ,ぶおそれがある。,,,,,,,,,, ,　また、産業機器、家電製品などは、機器や製品を制御するための組込みシステムが搭載されており、高機能化し,,,,,,,,,, ,ている。このような状況で、例えば、自動車やエレベータなどの機器の組込みシステムに不具合が発生すると、社会,,,,,,,,,, ,生活に影響が及ぶだけでなく、人命を脅かすような深刻な事態を招くおそれもある。,,,,,,,,,, ,　したがって、情報システム又は組込みシステムの稼働前に、システムが要件通りに機能するか十分に検証し、品,,,,,,,,,, ,質や性能を確保しなければならない。特に、稼働時、利用時の様々な状況を想定し、不具合を事前に見つけ出すテ,,,,,,,,,, ,スト工程（以下、システムテストという）は、システムの安全性を確保する上で重要な位置づけとなる。,,,,,,,,,, ,　システム監査人は、このような点を踏まえて、情報システム又は組込みシステムについてシステムテストが適切に,,,,,,,,,, ,行われ、品質や性能が確保されていることを確かめなければならない。また、既に稼働している情報システム又は,,,,,,,,,, ,利用している組込みシステムについても、十分な品質や性能が確保されていることを確かめるために、開発段階で,,,,,,,,,, ,実施したシステムテストの内容をさかのぼって確認する場合もある。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係した情報システム又は組込みシステムの概要と、そのシステムの不具合が業務・社会に及,,,,,,, ,,,,ぼす影響について、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アで述べた情報システム又は組込みシステムに対するシステムテストの内容について、700字以上14,,,,,,, ,,,,00字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問イで述べたシステムテストの適切性を確かめるために必要な監査手続について、700字以上1400字以,,,,,,, ,,,,内で具体的に述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　情報システムの役割の広がりや組込みシステムの普及に伴い、システムにはますます高い品質や性能の確保,,,,,,,,, ,,が求められている。システムの不具合は、組織内業務にとどまらず、社会生活にまで影響を及ぼす場合もある。,,,,,,,,, ,,したがって、システムの稼働時、利用時の様々な状況を想定して、不具合を事前に見つけ出すシステムテストは,,,,,,,,, ,,、重要な工程となる。,,,,,,,,, ,,　本問では、情報システム又は組込みシステムの役割や影響を踏まえた上で、システムの品質や性能が確保さ,,,,,,,,, ,,れていることを確かめるために必要なシステムテストの内容を理解し、その適切性を監査するための見識や技能,,,,,,,,, ,,について評価する。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　高度化・多様化する情報技術に対応できるシステム監査人を育成するという観点に基づいて、情報技術につい,,,,,,,,, ,,て広く深い理解を求めるテーマを出題した。そのため、各テーマについての実務経験を有していない受験者にと,,,,,,,,, ,,っては、難しい問題になったと思われる。,,,,,,,,, ,,　全ての問いにおいて、論述内容が一般的で具体的な記述まで至っていないものが多かった。,,,,,,,,, ,,　問１（情報システム又は組込みシステムに対するシステムテストの監査について）は、システム開発段階の基本,,,,,,,,, ,,的なテーマであることから、選択率が最も高かった。情報システムを対象にした論述が多かったが、組込みシステ,,,,,,,,, ,,ムを対象にした論述も見受けられた。設問イ、ウは、単体テスト、結合テストなどを含めたテスト工程全体や、テス,,,,,,,,, ,,トの実施手順についてなど、システムテストの位置付けや具体的な内容を理解できていない論述が目立った。ま,,,,,,,,, ,,た、設問ウでは監査の実施手順や、監査ポイントだけで、監査証拠について触れていない論述が散見された。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,１．システムの概要とシステムの不具合が業務・社会に及ぼす影響,,,,,,,,,, ,１．１　システムの概要,,,,,,,,,, ,,,,,,,,,,, ,,　A地方銀行は、従来ホストコンピュータを使用して、基幹オンラインシステムを稼働してきたが、システムコストの,,,,,,,,, ,,大幅な削減を目的として、オープン系システムによる全面的なオンラインシステムの更改を進めることとなった。こ,,,,,,,,, ,,の更改に当たっては、B社の銀行向けパッケージを使用したが、A行独自の改訂をかなり行った。,,,,,,,,, ,,　信頼性などの面で、オープン系システムで本当に基幹システムが稼働できるかという慎重な意見も行内に多く,,,,,,,,, ,,あったこともあり、開発期間は3年間、システムテスト期間もほぼ半年とり、かなり慎重に移行を進めた。,,,,,,,,, ,,,,,,,,,,, ,１．２　システムの不具合が業務・社会に及ぼす影響,,,,,,,,,, ,,,,,,,,,,, ,,　当行に限らず、銀行のシステムには高い信頼性が求められる。ハードウェアの障害等で、システムが使用でき,,,,,,,,, ,,ないことになると、多くの顧客に迷惑が掛かるだけでなく、場合によっては法人の決済ができないなど、法人の経,,,,,,,,, ,,営にも影響を与えてしまう事態も想定される。また、それによりマスコミ等の報道があると、銀行自体の信頼性も,,,,,,,,, ,,大きく傷つけてしまうことになる。,,,,,,,,, ,,　更に気を付けなければいけないことは、ソフトウェアの障害である。もし、万が一、ソフトウェアの不具合で金額,,,,,,,,, ,,を間違えるようなことがあれば、顧客の信頼を大きく損ねるだけでなく、金融庁の行政処分などを受ける可能性も,,,,,,,,, ,,ある。最悪、取引停止などの処分を受ければ、当行の存続にもかかわる事態にもなりかねない。,,,,,,,,, ,,　本システムにおいても、これらの事態を想定し、ハードウェアの障害については、3分以内で復旧できるバックア,,,,,,,,, ,,ップ体制を取ると同時に、ソフトウェアの不具合を残さない体制の整備が求められた。,,,,,,,,, ,,,,,,,,,,, ,２．システムテストの内容,,,,,,,,,, ,,,,,,,,,,, ,,　非常に高い信頼性が求められるシステムなので、システムテストについても万全の準備と体制で臨むことが求,,,,,,,,, ,,められた。具体的には、システムテストを、追加・修正した部分の機能テスト、非機能要件のテスト、業務全般の,,,,,,,,, ,,網羅テストの三つに分け、それぞれのテストチームごとにこれらのテストを実施することとした。,,,,,,,,, ,,,,,,,,,,, ,２．１　追加・修正した部分の機能テスト,,,,,,,,,, ,,,,,,,,,,, ,,　このシステムテストは、機能の追加・修正要件に基づくテストである。このテストでは、追加・修正に関する要求,,,,,,,,, ,,仕様書に基づいて、テスト仕様書を作成した。この際に、テストカバレッジの基準を仕様書1ページ当たり10以上,,,,,,,,, ,,のテスト項目として、必ずこの基準を守るように徹底した。また、パッケージの修正による周辺部分への影響を考,,,,,,,,, ,,慮し、このテスト項目のほかに、関連部分への影響テストも実施することとした。これに関しては、モジュール単位,,,,,,,,, ,,に修正・追加部分のテスト項目の半分以上の数のテスト項目を設定することを基準とした。この関連部分のテスト,,,,,,,,, ,,項目の設定については、B社のパッケージ開発に携わったSEの協力を仰ぎ、修正によって影響を受けそうな箇所,,,,,,,,, ,,を指摘してもらい、その箇所を中心にテストを行った。,,,,,,,,, ,,,,,,,,,,, ,２．２　非機能部分のテスト,,,,,,,,,, ,,,,,,,,,,, ,,　今回の開発については、機能部分と非機能部分で要求仕様書を分けて作成しており、このテストは非機能部分,,,,,,,,, ,,の要求仕様書を使用して、テスト仕様書を作成した。非機能部分の要求仕様書には、次のような項目が記載され,,,,,,,,, ,,ていた。,,,,,,,,, ,,,①,他システムとのインタフェース仕様,,,,,,, ,,,②,運用仕様,,,,,,, ,,,③,性能仕様,,,,,,, ,,,④,プライバシー仕様,,,,,,, ,,,⑤,セキュリティ仕様,,,,,,, ,,,⑥,障害・回復仕様,,,,,,, ,,　基本的には、これらの仕様書に基づいてテスト仕様書を作成したが、次の点については特に注意した。,,,,,,,,, ,,,（１）,,性能仕様については、決められた処理性能が出るかどうかのテストの他に、それ以上のトランザクショ,,,,,, ,,,,,ンが発生した場合にも処理は遅くなるが、システムがハングアップするようなことがないことを確認した。,,,,,, ,,,（２）,,セキュリティ仕様に関しては、外部のセキュリティ専門業者によるセキュリティテストも同時に実行するよ,,,,,, ,,,,,うにした。,,,,,, ,,,,,,,,,,, ,２．３　網羅テスト,,,,,,,,,, ,,,,,,,,,,, ,,　このテストでは、修正項目とは関係なく、新システムの機能を一通りテストした。このテストは、テスト担当者のオ,,,,,,,,, ,,ペレーションによるテストと、過去のトランザクションログを使ったテストの両方を実施した。,,,,,,,,, ,,　テスト担当者によるテストでは、オペレーションマニュアルに沿って、テスト仕様書を作成した。この際に過去の,,,,,,,,, ,,システムの更改時に使用したテストケースなども参考にした。過去のトランザクションを使用したテストは、実際の,,,,,,,,, ,,特定の支店のトランザクションログを使用して、それを新しいシステムのフォーマットに変換して新システムに渡す,,,,,,,,, ,,ことによってテストを行った。,,,,,,,,, ,,,,,,,,,,, ,３．システムテストの適切性を確かめるための監査手続,,,,,,,,,, ,３．１　追加・修正した部分の機能テスト,,,,,,,,,, ,,,,,,,,,,, ,,　追加・修正した部分の機能テストの適切性を確かめるための監査手続としては、最初に追加・修正に関する要,,,,,,,,, ,,求仕様書への準拠性を確認した。具体的には、テスト仕様書と要求仕様書の内容を突き合わせて、要求仕様書,,,,,,,,, ,,の内容が網羅されていることを確認した。,,,,,,,,, ,,　次に、テスト項目数の妥当性を確認した。この確認のために、先ずテストカバレッジの基準の妥当性を確認した,,,,,,,,, ,,。この確認のために、外部のテストカバレッジ基準を調査したが、そのほとんどがファンクション・ポイント対比の,,,,,,,,, ,,基準となっていた。そこで、今回のシステムの追加・修正分のファンクション・ポイントを計算し、それとページ数の,,,,,,,,, ,,比率を使ってファンクション・ポイント換算のテストカバレッジの比較を行い妥当性のチェックを行った。この際に,,,,,,,,, ,,、システムの重要性を考慮し、外部の基準の1.5倍をクリアしていることを確認した。次に実際のテスト仕様書のテ,,,,,,,,, ,,スト項目数がこの基準をクリアしていることをテスト仕様書のテスト項目を集計して確認した。,,,,,,,,, ,,　関連部分への影響テストに関しては、全ての追加・修正項目について関連部分の影響テストが設定されている,,,,,,,,, ,,ことをテスト仕様書で確認した。また、同時にテスト項目数がテストカバレッジ基準を満たしていることも確認した。,,,,,,,,, ,,,,,,,,,,, ,３．２　非機能部分のテスト,,,,,,,,,, ,,,,,,,,,,, ,,　非機能部分の適切性を確かめるための監査手続としては、最初に非機能部分の要求仕様書とテスト仕様書の,,,,,,,,, ,,突合せを行った。具体的には、テスト仕様書と要求仕様書の内容を突き合わせて、漏れがないことを確認した。,,,,,,,,, ,,　また、性能やセキュリティなどの信頼性に深くかかわる部分については、更にその内容についてもその適切性,,,,,,,,, ,,について検証を行った。性能に関しては、テストで一定時間に発生させるトランザクションの数が、過去に発生し,,,,,,,,, ,,た最大のトランザクション数を上回っていることを確認した。また、想定以上のトランザクションを発生させたときの,,,,,,,,, ,,テスト結果の内容も検証し、その時のシステムの状況が詳しく記述されていることを確認し、確かにシステムのハ,,,,,,,,, ,,ングアップが発生しないことが検証されていることを確認した。,,,,,,,,, ,,　また、セキュリティのテストに関しては、外部のセキュリティ業者のテスト内容の資料を取り寄せ、その内容を最,,,,,,,,, ,,近のセキュリティ事故と照らして、それらの事故が発生しないことを確認できているかを確認した。,,,,,,,,, ,,,,,,,,,,, ,３．３　網羅テスト,,,,,,,,,, ,,,,,,,,,,, ,,　網羅テストの適切性を確かめるための監査手続としては、最初にオペレーションマニュアルとテスト仕様書の内,,,,,,,,, ,,容を突き合わせて、内容に漏れがないことを確認した。また、同時にオペレーションマニュアルに記載されていな,,,,,,,,, ,,い操作がないことをオペレーション担当者にヒアリングして確認した。,,,,,,,,, ,,　また、過去のトランザクションを使用したテストについては、そのトランザクションを取得した期間が月末などの特,,,,,,,,, ,,殊な処理が含まれる期間であることも確認した。,,,,,,,,, ,,,,,,,,,,, 平成21年度　問1　シンクライアント環境のシステム監査について,,,,,,,,,,, ,,,,,,,,,,, ,　近年、シンクライアントを導入する組織が増えている。これまで、PCには、ハードディスクが搭載され、端末本体に,,,,,,,,,, ,データを格納するのが一般的であった。しかし、ノートPCの紛失や盗難によって、格納されているデータが外部に流,,,,,,,,,, ,出する事件が相次いだこともあり、情報セキュリティ対策の一つとして、シンクライアントが注目されるようになった。,,,,,,,,,, ,　シンクライアントを導入すると、利用者のデータはすべてサーバ上で集中管理されることになる。最近では、ハード,,,,,,,,,, ,ディスクが搭載された既存のPCでも、疑似的にシンクライアント環境を構築できる技術が開発され、以前に比べてシ,,,,,,,,,, ,ンクライアントへの移行が容易になっている。,,,,,,,,,, ,　しかし、シンクライアント環境においては、データの保管や通信負荷、勤務形態などに関して、特有のリスクがある,,,,,,,,,, ,。そのため、組織は、シンクライアントを導入する前にリスクを明確にし、十分な対策を講じる必要がある。,,,,,,,,,, ,　このような状況を踏まえ、システム監査人は、シンクライアント環境においてリスクが十分に低減されているかどう,,,,,,,,,, ,かを監査しなければならない。,,,,,,,,,, ,,,,,,,,,,, ,設問ア,,,あなたが関係する組織において、シンクライアントを導入している場合、又は導入を検討している場合、そ,,,,,,, ,,,,の目的及び期待する効果を、800字以内で述べよ。,,,,,,, ,設問イ,,,設問アに関連して、シンクライアント環境にかかわるリスクを、700字以上1400字以内で具体的に述べよ。,,,,,,, ,設問ウ,,,設問ア及び設問イに関連して、シンクライアント環境におけるリスク対策によって、想定するリスクが十分に,,,,,,, ,,,,低減されているかどうかについて監査する場合に必要な監査手続きを、700字以上1400字以内で具体的に,,,,,,, ,,,,述べよ。,,,,,,, ,,,,,,,,,,, ■解説,,,,,,,,,,, ,,,,,,,,,,, ,■出題趣旨,,,,,,,,,, ,,,,,,,,,,, ,,　近年、情報漏洩防止の観点からシンクライアントが注目されている。既に多くの組織がシンクライアントを採用し,,,,,,,,, ,,、一定の成果が表れている。情報セキュリティ対策の一環としてシンクライアントを導入する企業が多いが、この,,,,,,,,, ,,ほかに勤務形態の多様化、事業継続管理への適用、消費電力削減による二酸化炭素排出量削減など、様々な,,,,,,,,, ,,効果が得られている。しかし、これまでのIT環境からシンクライアント環境に移行する場合には、特有のリスクが,,,,,,,,, ,,伴う。,,,,,,,,, ,,　本問では、システム監査人として、シンクライアントに関する技術的な知識を踏まえて、業務や勤務形態などに,,,,,,,,, ,,対する効果とリスクを理解した上で、監査を実施する知識や能力があるかどうかを評価する。,,,,,,,,, ,,,,,,,,,,, ,■採点講評,,,,,,,,,, ,,,,,,,,,,, ,,　全体として、一般論を展開しただけの論述が目立った。出題趣旨から大きく外れたり、問題文を言い換えただけ,,,,,,,,, ,,であったりした論述は論外としても、設問の趣旨を十分に理解し、受験者自らの経験や考えを反映するように心,,,,,,,,, ,,掛けてもらいたい。また、論述内容の意味のない重複、不要な空行、専門用語の誤りなどがないように注意して,,,,,,,,, ,,もらいたい。,,,,,,,,, ,,　問１（シンクライアント環境のシステム監査について）は、最も選択率が低かった。本問の選択者の多くは、シン,,,,,,,,, ,,クライアントの導入、又はその検討に携わった経験を持つと考えられる。設問ア及びイについては、自らの経験を,,,,,,,,, ,,踏まえた具体的な内容の論述が多く見られた。しかし、設問ウで監査手続を適切に論述している解答は非常に,,,,,,,,, ,,少なかった。監査の観点や監査手順だけ、又はリスク対策だけの論述、監査について何も触れていない論述な,,,,,,,,, ,,どが散見された。,,,,,,,,, ,,,,,,,,,,, ■論文事例,,,,,,,,,,, ,,,,,,,,,,, ,第1章　シンクライアント導入の目的及び期待する効果,,,,,,,,,, ,,,,,,,,,,, ,,　論述の対象は電子遊戯機器を製造・販売するA社のシンクライアント環境である。A社では、営業員の使用する,,,,,,,,, ,,ノートPCに関して、次の2点が課題となっていた。,,,,,,,,, ,,,,,,,,,,, ,,,（１）,,バックアップの取得作業による営業員の生産性低下,,,,,, ,,,（２）,,営業員の使用するノートPCの紛失・盗難による格納されているデータの外部流出,,,,,, ,,,,,,,,,,, ,,　そこで、ノートPCに関する運用性の向上と情報セキュリティの向上を目的にシンクライアントの導入を行った。な,,,,,,,,, ,,お、A社の営業員は所属によっては在宅勤務の勤務形態をとっている者もいる。この点がシンクライアント環境に,,,,,,,,, ,,おけるリスク対策の考慮点となった。,,,,,,,,, ,,　シンクライアント導入について期待する効果は次の通りであった。,,,,,,,,, ,,,,,,,,,,, ,,（１）営業員の生産性向上,,,,,,,,, ,,,,,,,,,,, ,,,　データの保管の観点から、バックアップの一元管理を行うことで、営業員をバックアップ作業から解放して営,,,,,,,, ,,,業員の生産性の向上を図る。シンクライアントではユーザデータを集中管理しているという特徴がある。,,,,,,,, ,,,,,,,,,,, ,,（２）セキュリティの向上,,,,,,,,, ,,,,,,,,,,, ,,,　勤務形態の観点から、在宅勤務におけるセキュリティの向上を図りユーザデータの外部流出の機会を減ら,,,,,,,, ,,,す。プライバシ保護の観点から、在宅勤務環境の管理は難しいという特徴がある。,,,,,,,, ,,,,,,,,,,, ,,　私はA社内部のシステム監査人の立場で、シンクライアント環境におけるリスクと、リスクに対するコントロール,,,,,,,,, ,,の監査において特に有効性の高い監査手続について述べる。,,,,,,,,, ,,,,,,,,,,, ,第2章　シンクライアント環境に関わるリスク,,,,,,,,,, ,,,,,,,,,,, ,,　シンクライアント環境における特徴から、そこには次のリスクが高いことが分かる。,,,,,,,,, ,,,,,,,,,,, ,,（１）ディスク障害によるユーザデータへのアクセス困難,,,,,,,,, ,,,,,,,,,,, ,,,　データの保管の観点から、ユーザデータが集中管理されているという特徴を踏まえると、ユーザデータという,,,,,,,, ,,,情報資産は、脆弱性として、データが集中して保管されている、脅威として、ディスク障害という点をもつ。これ,,,,,,,, ,,,らが結び付くことで、ディスク障害によって大量のユーザデータがアクセス困難になるというリスクがあることが,,,,,,,, ,,,分かる。RAID技術の採用によって、ディスクの信頼性は向上したが、RAIDの種類によっては、ディスク障害時,,,,,,,, ,,,に応当性の低下が発生するからである。,,,,,,,, ,,,　このリスクについては、バックアップを適切なタイミングで採取し、更にリストアのテストを実施することによっ,,,,,,,, ,,,てバックアップ有効性を常時確保し、ディスク障害時の復旧時間が許容範囲内に収まることを確実にする,,,,,,,, ,,,コントロールが有効である。,,,,,,,, ,,,,,,,,,,, ,,（２）在宅勤務者のユーザデータの改ざんや消失,,,,,,,,, ,,,,,,,,,,, ,,,　勤務形態の観点から、在宅勤務の環境の管理は難しいという特徴を踏まえると、ユーザデータという情報資,,,,,,,, ,,,産は、脆弱性としては在宅勤務の環境であるため使用方法などが漏れやすい、脅威としては在宅勤務の環境,,,,,,,, ,,,における故意あるいは無知による第三者の利用という点をもつ。その結果、ユーザデータの改ざんや消失とい,,,,,,,, ,,,うリスクがあることが分かる。,,,,,,,, ,,,　このリスクについては、在宅勤務の環境についてアンケート調査を行い、問題点については、定期的に情報,,,,,,,, ,,,セキュリティ教育をユーザに実施して、情報セキュリティインシデントを予防するというコントロールが有効であ,,,,,,,, ,,,る。なぜならば、会社は情報セキュリティに厳しいという意識をユーザにもたせることが、情報セキュリティにお,,,,,,,, ,,,ける人的対策の基本だからである。,,,,,,,, ,,,,,,,,,,, ,,　以上のリスクに対するコントロールを監査するために、私は次のように考えて有効性の高い監査手続を設定し,,,,,,,,, ,,た。,,,,,,,,, ,,,,,,,,,,, ,第3章　シンクライアント環境における監査手続,,,,,,,,,, ,,,,,,,,,,, ,,　リスクが十分に低減されているかを確認するという監査の目的を設定した上で、コントロールに対して有効性の,,,,,,,,, ,,高い監査手続について次に述べる。,,,,,,,,, ,,,,,,,,,,, ,,（１）リストアテスト報告書のレビュー,,,,,,,,, ,,,,,,,,,,, ,,,　データの保管の観点から、データのバックアップ方法や保管が適切で、バックアップの有効性が確保されて,,,,,,,, ,,,いるかという監査要点を設定した。,,,,,,,, ,,,　監査手続としては、ユーザデータの集中という特徴を踏まえると、バックアップの有効性を特に重視する必要,,,,,,,, ,,,があるが、客観的にそれを確認することは難しい。なぜならば、リストアのテストは失敗すると本番環境を破壊,,,,,,,, ,,,する可能性があるためテストを敬遠するからである。そこで、バックアップのリストアテストの報告書をレビュー,,,,,,,, ,,,する、過去のリストア作業の履歴を作業報告書などでレビューするなどの工夫が必要である。,,,,,,,, ,,,　過去のリストア作業履歴の作業報告書が少ない場合は注意が必要である。なぜならば、最新の環境におけ,,,,,,,, ,,,るバックアップが有効でない可能性があるからである。直近の作業報告書の精査が重要である。,,,,,,,, ,,,,,,,,,,, ,,（２）アンケートによるセキュリティ対策の実施状況確認,,,,,,,,, ,,,,,,,,,,, ,,,　勤務形態の観点から、監査要点として、シンクライアントの利用環境において予防的なセキュリティ対策が有,,,,,,,, ,,,効に働いているか、を設定した。,,,,,,,, ,,,　監査手続としては、在宅勤務の環境の管理は難しいという特徴を踏まえると、シンクライアント環境への現地,,,,,,,, ,,,調査法の適用は困難である。さらにサンプリング法を適用しても、セキュリティで重要となる網羅性を確保でき,,,,,,,, ,,,ない。そこで、メールを利用して、予備調査において在宅勤務者にアンケート調査を行い、セキュリティ教育の,,,,,,,, ,,,受講状況の確認やセキュリティ対策の実施状況の確認を行う工夫が必要である。,,,,,,,, ,,,　アンケート調査法を適用する際には自由に意見を書いてもらうアンケート項目が重要となる。なぜならば、書,,,,,,,, ,,,かれた内容からセキュリティインシデントの兆候やセキュリティの課題を発見できることがあるからである。,,,,,,,, ,,,,,,,,,,, ,,　以上がA社のシンクライアントの導入目的や期待する効果を踏まえて、私が設定した監査手続である。　以上,,,,,,,,,