情報処理技術者試験☆合格への道

ライフワークとしての資格取得ブログ presented by Pman






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

にほんブログ村 資格ブログ 国家試験へ にほんブログ村 資格ブログ IT系資格へ
 にほんブログ村 資格ブログへ
 ブログの殿堂
資格・スキルアップ Ranking  ナレコム おけいこブログランキング

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

SEO対策・SEOとは
IT  資格  ブログ
受験  日記  合格  論文


最近の記事


リンク集




自己紹介など

    くつろぐ

  • ニックネーム:Pman
  • プロフィール:
     情報処理サービス会社に勤務。主に金融業のソフトウェア開発、システム運用・保守を担当。メインフレームからオープン系まで広く浅く経験。資格取得はライフワークとなりつつある。
    保有資格
    システム監査技術者
    プロジェクトマネージャ
    アプリケーションエンジニア
    テクニカルエンジニア(システム管理)
    ネットワークスペシャリスト
    情報処理技術者(一種、二種)
    電気通信主任技術者(第一種伝送交換)
    工事担任者(デジタル第1種)


  •  質問、要望、感想、応援などは
     下のメールフォームから、直接
     私あてに送ることができます。


     当ブログはリンクフリーですが、
     リンクした場合は、メール又は
     コメントで知らせていただくと
     ありがたいです。

メールフォーム

名前:
メール:
件名:
本文:

広告エリア2












スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

AN 再チャレンジ

 受験の申込みは済んだ。あとは黙々とやるしかない。

情報処理教科書 システムアナリスト 2007年度版情報処理教科書 システムアナリスト 2007年度版
(2007/04/10)
島本 栄光

商品詳細を見る

 本屋で現物を見て、これに決めた。おなじみの「情報処理教科書」シリーズである。演習を中心とした実戦的な内容が決め手となったわけだが、念のために言っておくと、この本は午後1と午後2の学習用になる。午前問題はまったく載っていないので、購入を考えている方はその点に注意されたい。
 このシリーズは、試験区分によって著者が異なるので、本の構成もだいぶ異なっている。シスアナの本書は、なんと論文対策を午後1対策の前にもってくるという大胆な構成となっている。著者によると、午後1と午後2では、そもそも求められるスキルが違うというのだ。午後1は業務知識をベースとしたコンサル的な能力、午後2はスキル標準をベースとしたアナリストとしての能力、が試される。したがって、午後2よりもむしろ午後1のほうが難しい、と主張している。この説に、私は軽い衝撃を受けた。
 けれども、難しいと言われる午後1だからこそ、私はどちらかというと早いうちから手をつけておきたいと思う。昨年のAN試験で無惨な結果だった午後1を何とかしないことには、どうにもならない。私の場合、午後1を何とかしてクリアし午後2の論文勝負に持ち込めばひょっとして・・という思いはある。

 ちなみに、昨年使ったシステムアナリスト過去問題&分析〈2005年版〉も参考に見ると思う。翔泳社と経林書房とで解答がちがうこともあるだろうが、それはそれで非常に興味深い。
スポンサーサイト

7.情報化コンサルテーション

 7-1 情報システムにおける総合的コンサルテーション
  711 ユーザ部門が主体で実施する業務改革が実現されている
  712 ユーザ部門の業務課題がシステムソリューションにより解決される

 7-2 IT利用に関するコンサルテーション
  721 ユーザ部門のメンバに対するIT導入の指導が適切である
  722 経営者、CIO、メンバに対しeビジネス実施の助言が適切である
  723 問題解決の手段として最適なITが選定され機能している

コメント:
 コンサルタントという言葉は広い意味で使われているが、ここで言うのはいわゆるITコンサルを指す。7-1の業務改革はIT利用を前提としたものと捉えていいだろう。アナリストは、システム化計画を立案するだけでなく、計画が実現できるようにユーザ部門へ助言をする役割を担っている。こうしてみると、システムアナリストは開発・運用側の立場でありながら、利用者側とも密接な関わりをもつと言えよう。上級シスアドとの統合が検討されているのもそのためである。

 以上、スキル標準の中のスキル基準から「達成指標」を題材にまとめてみた。これを骨組みとして進めていこう。もう一度、以下にアクティビティをおさらい。やはり中心となるのは、2、3、4あたりだろう。
  1.経営事業戦略立案への助言
  2.情報戦略の立案
  3.情報システム構想の立案
  4.システム計画の立案

  5.情報システム開発プロジェクト計画への支援
  6.システム評価
  7.情報化コンサルテーション

6.システム評価

 6-1 システム運用の評価
  611 システム管理者から提出される評価報告が正確に把握されている
  612 システム運用の課題およびニーズを分析し次期計画に反映できる

 6-2 業務運用の評価
  621 システム管理者から提出される評価報告が正確に把握されている
  622 業務運用面の課題改善提案を適切に取捨選択し、次期に反映できる

コメント:
 システム管理者がここで登場するとは意外だった。試験区分ではSM:テクニカルエンジニア(システム管理)に当たる。ANとSMの接点など想像もしていなかったが、運用の評価というからには関連があるわけだ。確かに、アナリストの守備範囲は企画、開発にとどまらず、運用、保守にまで及ぶので、むしろ当り前のことと捉えたほうがいいだろう。ただし、アナリストは運用の当事者ではなく、経営的な視点からシステム運用および業務運用を評価する立場であることに注意が必要。

5.情報システム開発プロジェクト計画への支援

 5-1 情報システム開発プロジェクト計画作成への支援
  511 情報システム構想およびシステム計画の考え方にかなっている

 5-2 情報システム開発プロジェクト計画承認への助言
  521 プロジェクト計画の承認者からの質問に的確に答えている

コメント:
 アナリストが立案した計画にのっとって個別の開発プロジェクトが計画され、運営されていく。したがってアナリストは、自分が策定した情報システム構想とシステム計画の内容が、その後のプロジェクト計画に漏れなく反映され具現化されているかを確認する必要がある。そして、適宜、関係者への支援や助言を行わなければならない。

4.システム計画の立案

 4-1 基本要件の実現性の検討
  411 情報システムに関する基本要件が正確に捉えられている
  412 情報システムの目的、期間、コスト等の基本方針が明確である
  413 基本要件が前提条件を満たし、実現可能性が検討されている

 4-2 開発スケジュールの大枠作成
  421 情報システムの基本要件に適合したサブシステムに分割されている
  422 サブシステムの開発優先順位が適切である
  423 サブシステムの単位スケジュールが基本方針に沿っている

 4-3 システム選定方針の策定
  431 システムの機能・構成要件および予算枠が明確にされている
  432 システム選定の調査範囲が明確にされている

 4-4 情報システム開発プロジェクト推進体制の策定
  441 要員、納期およびコスト等の制約が考慮されている
  442 要員数、役割分担およびユーザ部門の協力等が明確にされている

 4-5 システム移行に対する基本方針の明確化
  451 システム移行に関わる方針および基本的要件が明確にされている
  452 システム移行のための概略の計画が明確にされている

 4-6 システム運用と保守に対する基本方針の明確化
  461 方針およびスケジュール等の基本的要件が明確にされている
  462 障害に対する保守体制、保守内容の基本要件が明確にされている
  463 システム運用作業のための方針が明確にされている

 4-7 環境整備に対する基本方針の明確化
  471 システム大枠の使用期間と使用量の見積りが適切である

 4-8 教育・訓練に対する基本方針の明確化
  481 教育・訓練の目的および対象範囲等が明確にされている
  482 教育体制、設備・環境およびスケジュール等が明確にされている
  483 業務とシステムに関する教育スケジュール等が明確にされている

 4-9 品質に対する基本方針の明確化
  491 システムの品質に対する基本的な要件が明確にされている
  492 システムの品質保証体制に対する基本的な要件が明確にされている
  493 継続的品質改善対策が考慮されている

 4-A システム計画の作成と承認
  4A1 標準記述形式に準じてシステム計画書内容が文書化されている
  4A2 システム計画が技術、運用および経済性の面で評価をされている
  4A3 システム計画書が必要な関係者に配布され、承認が得られている

コメント:
 今回の「4.システム計画の立案」は「3.情報システム構想の立案」とならび、システムアナリスト業務の中心となる。立案すると言っても、ただ漠然と計画書を作るのではなく、その準備には相当な時間と労力をかける必要がある。特に、上記4-1から4-4あたりのタスクは極めて重要な要素を含んでいると思われる。まず基本要件が明確でなければ開発が進まないし、仮に進んだとしても結局は使われないシステムになる可能性が高い。サブシステム分割した場合は、開発優先順位をよく考えないといけない。経営戦略上、予算枠は明確にしなければならない。そして、何と言ってもユーザの協力が大切である。極端なことをいうと、ユーザの参画なくしてプロジェクトは成功しないと私は思っている。
 4-5以降のタスクも同じで、個々の要素について基本方針をはっきりさせること。ただし、開発、移行、運用、保守、環境、教育などは互いに関連しているうえ、技術やコストなどの制約による影響を受ける場合もある。例えば、適用する技術に制限があるため開発範囲を縮小するとか、段階的な移行を考えたが予算不足なので一括移行するなど、である。

3.情報システム構想の立案

 3-1 対象業務システム課題の定義
  311 情報戦略指針の記載事項が正確に把握されている
  312 対象業務の流れと情報が情報システムの視点から整理されている
  313 対象業務における業務上の課題が適切に分析されている
  314 情報システム化により解決すべき課題が文書化されている

 3-2 対象業務システムの分析
  321 開発/改善/改革対象に関わる現情報システムが把握されている
  322 機能とデータが再構築に活用できるように文書化されている
  323 システム障害による影響が分析され、対策レベルが設定されている

 3-3 適用情報技術の調査
  331 情報技術動向の調査方針(具体的な調査項目など)が明確である
  332 調査結果に基づいて、新業務への適用可能性が検討されている
  333 検討結果が文書化されている

 3-4 業務モデルの作成
  341 関連する業務機能の再構成およびモデル化が適切に行われている
  342 適用情報技術と対象業務機能が対比され、整合性がとれている
  343 主要な変更点および業務実施上の具体的課題が整理されている
  344 変更点および業務実施上の具体的課題が文書化されている

 3-5 システム方式の策定(システムアーキテクチャ)
  351 情報システムの主要機能が明確にされている
  352 主要機能を実現するための情報と処理が明確にされている
  353 主要機能を実現するシステムアーキテクチャが明確にされている
  354 データベースとネットワークの一覧および構成が明確にされている
  355 パッケージソフト導入および外部資源の利用の検討も行われている
  356 主要機能とシステムアーキテクチャ等について文書化されている

 3-6 費用とシステム投資効果の予測
  361 情報システムによる定量的・定性的効果が適切に予測されている
  362 開発・運用・保守に関する期間・体制・工数の予測が妥当である
  363 情報システム実現のための費用見積りが妥当なものである
  364 情報システムの費用対効果が考慮されている
  365 費用とシステム投資効果が文書化されている

 3-7 情報戦略との検証
  371 情報戦略指針の記載事項が正確に把握されている
  372 システムアーキテクチャによる情報戦略の実現性が検討されている
  373 検証結果が整理されている

 3-8 情報システム構想の作成と承認
  381 企業が採用している標準記述形式に準じて文書化されている
  382 情報システム構想企画書が必要な関係者に配布されている

コメント:
 前回を「戦略」とすれば、今回は「戦術」に近いものと考えられる。いろいろと書いてみたが、詰まるところ上記の372に行きつく。この項目は長かったので縮めたが、スキル基準の原文では「業務モデルとシステムアーキテクチャによる企業目標、経営戦略および情報戦略の実現性が検討されていること」となっている。ここがもっとも肝心だと思う。要するに、情報システムが目的を達成するものか否かを十分に検討することが大切というわけだ。業務上の課題、技術の適用可能性、主要機能の明確性、費用対効果など、いろいろな面から検討しなければならない。そして最後は、情報システム構想企画書をまとめ上げ、経営層からの承認を得る必要がある。

2.情報戦略の立案

 2-1 業務環境の調査・分析(経営環境)
  211 外部環境が正確に捉えられている
  212 外部環境の分析結果と企業目標の関係が文書化されている
  213 情報が継続的に収集されている

 2-2 現行業務の調査・分析
  221 内部環境が正確に捉えられている
  222 業務上の課題が分析・抽出され、文書化されている
  223 業界内における管理面と業務面の評価が行われ、文書化されている

 2-3 情報システムの調査・分析
  231 目的、機能、規模、コスト、保守運用が正確に捉えられている
  232 情報システムの課題が的確に捉えられ、文書化されている
  233 業界内における平均技術水準が把握されている

 2-4 情報技術動向の調査・分析
  241 情報技術動向が網羅的かつ総括的に捉えられている
  242 経営・情報戦略に適用できるIT利用方法が文書化されている
  243 情報が網羅的に収集されている

 2-5 基本戦略の策定
  251 開発/改善/改革対象が適切に識別され優先順位付けされている
  252 企業目的に対する開発/改善/改革対象の貢献度検証が適切である
  253 企業目標を達成するための中長期計画が策定されている
  254 開発/改善/改革対象を実現するため資源獲得の算段が適切である
  255 経営要求および資源獲得から優先付けの選択基準が設定されている
  256 開発/改善/改革対象が文書化されている

 2-6 業務の新全体像と投資対象の選定
  261 業務機能と業務組織に関して最上位レベルでモデル化されている
  262 新全体像と現情報システムのギャップが把握されている
  263 新全体像の中から情報システム対象が選定されている
  264 適正な情報システム投資対象が選定され、目標が策定されている

 2-7 情報戦略の作成と承認および推進体制の提案
  271 標準記述形式に準じて情報戦略指針が文書化されている
  272 情報戦略指針が必要な関係者に配布され、承認が得られている
  273 情報システム部門の推進体制が適切に提案されている

コメント:
 さすがに1項目につき30字まで許すと黒い文字がぎっしりと並び、見ただけで拒絶してしまいそうだが、ところどころに色をつけると少しはマシになる。今回ここはポイントかと思われる部分に色をつけてみた。以上をまとめると「業務上およびシステム上の課題を分析しつつ技術動向を網羅的かつ総括的に捉え、貢献度検証や資源獲得の算段が適切な情報戦略の策定ならびに投資対象の選定を行う」のがアナリストの仕事といえる。かなり強引にまとめたが、骨組みはそういうことと捉えていいだろう。なお、戦略と戦術のちがいを整理しておく。
 【戦略】企業目標・ビジョンを実現するため、何に着目するか(What)
 【戦術】戦略実現のため、どのように取り組むか(How)

1.経営事業戦略立案への助言

 1-1 経営要求の確認
  111 経営方針が正確に捉えられている
  112 企業目標が正確に捉えられている
  113 中・長期構想が正確に捉えられている
  114 対象領域(事業ドメイン)が正確に捉えられている

 1-2 ビジネスモデル立案への助言
  121 新しいビジネスモデルにより革新的な事業領域が明確にされている
  122 情報戦略と情報資源配分の面から適切に助言されている
  123 経営環境の変化およびIT革命による影響が明確に説明されている

 1-3 ビジネスプロセスレベルでの理解
  131 ビジネスモデルがビジネスプロセスレベルで正確に捉えられている 

コメント:
 経営戦略立案への助言などと言うと、それこそ最高責任者(CIO)とか取締役などの経営トップに対する提案になるだろうが、アナリストがどこまで発言力をもつのかは、個人または企業によって異なってくる。但しそういった現実の世界はともかく、共通的なシスアナの観点として「ビジネス」があることを忘れてはいけない。
 ところで、スキル基準の勉強について。PMのときは15字以内の短い言葉としたが、ANでは30字以内とした。理由は、15字では短くて意味がよく伝わらない場合があるから、である。

スキル基準(AN) タスク一覧

1.経営事業戦略立案への助言

 1-1 経営要求の確認
 1-2 ビジネスモデル立案への助言
 1-3 ビジネスプロセスレベルでの理解

2.情報戦略の立案

 2-1 業務環境の調査・分析(経営環境)
 2-2 現行業務の調査・分析
 2-3 情報システムの調査・分析
 2-4 情報技術動向の調査・分析
 2-5 基本戦略の策定
 2-6 業務の新全体像と投資対象の選定
 2-7 情報戦略の作成と承認および推進体制の提案

3.情報システム構想の立案

 3-1 対象業務システム課題の定義
 3-2 対象業務システムの分析
 3-3 適用情報技術の調査
 3-4 業務モデルの作成
 3-5 システム方式の策定(システムアーキテクチャ)
 3-6 費用とシステム投資効果の予測
 3-7 情報戦略との検証
 3-8 情報システム構想の作成と承認

4.システム計画の立案

 4-1 基本要件の実現性の検討
 4-2 開発スケジュールの大枠作成
 4-3 システム選定方針の策定
 4-4 情報システム開発プロジェクト推進体制の策定
 4-5 システム移行に対する基本方針の明確化
 4-6 システム運用と保守に対する基本方針の明確化
 4-7 環境整備に対する基本方針の明確化
 4-8 教育・訓練に対する基本方針の明確化
 4-9 品質に対する基本方針の明確化
 4-A システム計画の作成と承認

5.情報システム開発プロジェクト計画への支援

 5-1 情報システム開発プロジェクト計画作成への支援
 5-2 情報システム開発プロジェクト計画承認への助言

6.システム評価

 6-1 システム運用の評価
 6-2 業務運用の評価

7.情報化コンサルテーション

 7-1 情報システムにおける総合的コンサルテーション
 7-2 IT利用に関するコンサルテーション

秋に向けて動き出す

 昨年のシステムアナリスト試験は、午前免除というアドバンテージを活かすことができず、午後1で惨敗した。精一杯の準備をして試験に臨んだつもりだったが、何かやり方をまちがえていたのだろう。もう1つ。昨年の秋試験は、本番での集中心が足りなかったと思う。午前パスでいきなり午後1という経験は今まで無かったので「いつもと勝手がちがう」という意識があったようだ。
 こうした経験をふまえ、2回目のANに向かってスタートする時期がやってきた。
 情報処理試験というのは、いろいろな区分に分かれているので、それぞれの試験区分ごとに異なる視点や思考で取り組むことになる。例えば、PMの場合はQCDとかPMBOKの観点から個別プロジェクトを運営及び管理していくのに対し、ANは情報戦略に基づく全体最適化の観点からシステム化計画の立案やプロジェクト支援を行う、といった具合である。
 しかし、内容が異なれば勉強のしかたが全く変わるのかと言えば、私はそうは思っていない。ある試験区分の勉強でうまくいった場合、それは他にも適用することが可能である。成功体験は次のステップへ進むための足場になるので、これを利用しない手はない。
 そこでまず、試験センターのスキル標準を読む。

【情報システム計画業務プロセス】
 1.経営事業戦略立案への助言
 2.情報戦略の立案
 3.情報システム構想の立案
 4.システム計画の立案
 5.情報システム開発プロジェクト計画への支援
 6.システム評価
 7.情報化コンサルテーション

 これら7つのアクティビティが、それぞれいくつかのタスクに分解されている。これからタスクごとの達成指標を1つ1つ書き出していき、補足的なキーワードやコメントを追加していこうと思う。

 夏はあっという間にすぎ、秋がやってきます。
 これから約100日。
 実りの秋に向かって、私といっしょに勉強してみませんか?

AU合格時の再現論文

平成19年度 春期 システム監査技術者

【午後2 問題文】

問1 システム監査におけるITの利用について

 システム監査における監査技法は、これまでは関係者に対するインタビューや資料の閲覧が中心であった。しかし、監査対象の拡大や複雑化に伴って、監査ソフトウェアやシステムのユーティリティ機能などのITを利用した監査技法(以下、IT監査技法という)が必要になってきている。
 例えば、サーバ管理の適切性について監査する場合、システム監査人は、サーバ管理者がサーバのOSのバージョンアップや利用者権限の更新などを適切に実施し、また、その適切性を定期的に検証しているかどうかを確かめる必要がある。数多くのサーバが複数の拠点で運用されているような環境においては、複数の管理者にインタビューを実施したり、資料を閲覧したりするよりも、IT監査技法を用いる方が効率が良い。また、IT監査技法を用いることによって、インタビューや資料の閲覧よりも証拠能力の高い監査証拠を入手することが可能になる。
 このような状況において、システム監査人は従来の監査技法に加えて、IT監査技法についても習熟しておく必要がある。一方、システム監査人は強力なアクセス権限をもつことになるので、監査ソフトウェアやシステムのユーティリティ機能の利用は監査目的の達成に限定される必要がある。
 上記に基づいて、設問ア~ウについてそれぞれ述べよ。

設問ア
 あなたが携わったシステム監査において、IT監査技法が有効と思われる事例について、監査対象の概要と監査目的を、800字以内で述べよ。
設問イ
 設問アに関連して、効率よく、効果的に監査目的を達成するためには、どのようなIT監査技法を用いるべきか。具体的な監査手続を述べよ。
設問ウ
 設問ア及び設問イに関連して、システム監査人がIT監査技法を用いる場合に、組織としてどのような点に留意すべきか。具体的に述べよ。


【再現論文 Pman wrote】

1.私が携わったシステム監査
1-1.監査対象の概要
 情報処理サービス企業に勤務する私は、金融系のシステム開発に携わる一方、外部の金融機関などからの依頼により、システム監査を不定期に実施している。
 A社は中堅の銀行であり、最近、新しいビジネスモデルとして、個人向けローン事業をA社Webサイトで公開し、インターネットによる融資の申込み受付を開始することになった。取り扱う対象業務には、住宅ローン、教育ローン、カードローンなどがあり、それらの業務を効率的に行うにはIT基盤の整備が不可欠である。つまり、Webサイトの構築だけでなく、バックで動く業務システムも含めた総合的な情報システムの構築が必要となる。今回A社から、新たなローン業務システムの開発段階における監査の依頼があり、監査チーム要員として私は参画することとなった。
1-2.監査目的
(1) 安全性の確認
 A社の新システムの監査にあたっては、Web上でのデータ送受信による個人情報の漏えいやシステムトラブルなどのリスクに対し、適切なコントロールが構築されていることを確認する必要がある。この点を客観的に点検・評価し改善勧告を行うことを監査目的とした。
(2) 信頼性の確認
 新システムが取り扱うデータは、個々の顧客のローン残高や利息金、口座情報などを含むため、安全性に加えてインテグリティの確保が重要となる。残高計算の結果が不正に出力されると、A社は金融機関としての信用を失うからである。こうしたリスクを回避するため、客観的に品質確認を行うことを監査目的とした。

2.IT監査技法とその監査手続(設問イ)
2-1.監視サーバの導入
 従来のシステム監査では、例えば入出力画面のハードコピーやアクセスログリストなどの監査証拠を入手し、目視や閲覧による確認が中心であった。しかし今回は、A社としては初めて本格的なWebシステムを構築することから、より確実に、安全性を評価するための監査を行わなければならない。
 そこで有効な手段として、監視サーバの導入が挙げられる。具体的には、監査ソフトウェアを組み込んだサーバをA社の開発環境に設置し、従来は監査人が目視していたアクセスログの確認を自動化する方法である。自動化のメリットは、正確かつ効率よく監査証拠を精査できる点にある。監査ソフトウェアに対して適用日時などの入力パラメータを与えるだけで、短期間のうちに成果が得られるであろう。さらに、監査対象が拡大あるいは複雑化した場合であっても、パラメータの変更やサーバの増強などにより対応できる。
2-2.並行シミュレーション法の適用
 データインテグリティの評価は、データベースの更新記録、あるいは、貸付金明細表や残高一覧表といった出力帳票により可能である。しかしA社の場合、ビジネスモデルの大幅な変更により開発規模が増大していたことから、効率性と網羅性を考慮した監査が必要である。
 ここで用いるべき監査技法に、並行シミュレーション法が挙げられる。監査手続としては、テスト工程において、A社の開発プログラムのほかに監査チームが用意した監査プログラムを動かし、これらの動作結果(金額などの数値)を検証ツールで比較・照合する。照合結果が不一致の場合は、原因を調べて問題を解決し再テストを行う。これにより証拠能力の高い監査証拠が得られ、効果的に監査目的を達成できると考えられる。

3.IT監査技法を用いる場合の留意点(設問ウ)
3-1.操作ミスの防止
 システム監査人は従来の監査技法に加えて、上述したIT監査技法について習熟する必要がある。その一方で留意すべき点は、監査実施時における操作ミスの防止である。例えば、監査ソフトウェアに誤ったパラメータを設定してしまうと、監査手続の妥当性が損なわれ、監査自体の品質が低下する。こうした単純なミスを防ぐためには、監査チーム内での複数人によるチェック行為を監査手順に組み込み、監査手続書に明記したうえで組織的なレビューを行うべきと考える。なお、レビュー結果は必ず文書として残すことが肝要である。
3-2.監査ソフトウェアの利用制限
 システム監査人は、監査対象となるA社の開発資源に対して強力なアクセス権限をもつことになる。したがって、監査ソフトウェアの利用は監査目的の達成に限定されるべきである。こうした利用制限については、個別監査計画書に盛り込み、監査責任者がレビューを行う。また、実際に目的外の利用が行われていないことを第三者がチェックすべきだろう。但しレビュー及びチェック結果は文書に残すこと。
3-3.開発プロジェクトとの調整
 並行シミュレーション法の適用については、A社と十分に事前調整する必要がある。なぜなら、サービス開始までの期間にはあまり余裕がないため、テスト工程の間に遅滞なく監査を実施しなければならないからである。また、監査によって問題が発見された場合、改善後の再テスト時の監査方法についても取り決める必要がある。例えば、再テストではどの範囲まで並行シミュレーション法を用いるか、といった点である。
 こうした点は、開発プロジェクトの計画段階で、監査計画との整合性を保つよう調整する必要がある。調整事項は、スケジュールのほか、IT監査技法の利用におけるハードウェア、ソフトウェア、ネットワーク、および人的資源を含めた経営資源全体へ及ぶことに留意すべきであろう。

以上

 | HOME |  ▲ page top


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。