平成19年度 春期 システム監査技術者
【午後２ 問題文】
問１ システム監査におけるＩＴの利用について
システム監査における監査技法は、これまでは関係者に対するインタビューや資料の閲覧が中心であった。しかし、監査対象の拡大や複雑化に伴って、監査ソフトウェアやシステムのユーティリティ機能などのＩＴを利用した監査技法（以下、ＩＴ監査技法という）が必要になってきている。
例えば、サーバ管理の適切性について監査する場合、システム監査人は、サーバ管理者がサーバのＯＳのバージョンアップや利用者権限の更新などを適切に実施し、また、その適切性を定期的に検証しているかどうかを確かめる必要がある。数多くのサーバが複数の拠点で運用されているような環境においては、複数の管理者にインタビューを実施したり、資料を閲覧したりするよりも、ＩＴ監査技法を用いる方が効率が良い。また、ＩＴ監査技法を用いることによって、インタビューや資料の閲覧よりも証拠能力の高い監査証拠を入手することが可能になる。
このような状況において、システム監査人は従来の監査技法に加えて、ＩＴ監査技法についても習熟しておく必要がある。一方、システム監査人は強力なアクセス権限をもつことになるので、監査ソフトウェアやシステムのユーティリティ機能の利用は監査目的の達成に限定される必要がある。
上記に基づいて、設問ア〜ウについてそれぞれ述べよ。
設問ア
あなたが携わったシステム監査において、ＩＴ監査技法が有効と思われる事例について、監査対象の概要と監査目的を、800字以内で述べよ。
設問イ
設問アに関連して、効率よく、効果的に監査目的を達成するためには、どのようなＩＴ監査技法を用いるべきか。具体的な監査手続を述べよ。
設問ウ
設問ア及び設問イに関連して、システム監査人がＩＴ監査技法を用いる場合に、組織としてどのような点に留意すべきか。具体的に述べよ。
【再現論文 Pman wrote】
１．私が携わったシステム監査
１−１．監査対象の概要
情報処理サービス企業に勤務する私は、金融系のシステム開発に携わる一方、外部の金融機関などからの依頼により、システム監査を不定期に実施している。
Ａ社は中堅の銀行であり、最近、新しいビジネスモデルとして、個人向けローン事業をＡ社Webサイトで公開し、インターネットによる融資の申込み受付を開始することになった。取り扱う対象業務には、住宅ローン、教育ローン、カードローンなどがあり、それらの業務を効率的に行うにはＩＴ基盤の整備が不可欠である。つまり、Webサイトの構築だけでなく、バックで動く業務システムも含めた総合的な情報システムの構築が必要となる。今回Ａ社から、新たなローン業務システムの開発段階における監査の依頼があり、監査チーム要員として私は参画することとなった。
１−２．監査目的
(1) 安全性の確認
Ａ社の新システムの監査にあたっては、Web上でのデータ送受信による個人情報の漏えいやシステムトラブルなどのリスクに対し、適切なコントロールが構築されていることを確認する必要がある。この点を客観的に点検・評価し改善勧告を行うことを監査目的とした。
(2) 信頼性の確認
新システムが取り扱うデータは、個々の顧客のローン残高や利息金、口座情報などを含むため、安全性に加えてインテグリティの確保が重要となる。残高計算の結果が不正に出力されると、Ａ社は金融機関としての信用を失うからである。こうしたリスクを回避するため、客観的に品質確認を行うことを監査目的とした。
２．ＩＴ監査技法とその監査手続（設問イ）
２−１．監視サーバの導入
従来のシステム監査では、例えば入出力画面のハードコピーやアクセスログリストなどの監査証拠を入手し、目視や閲覧による確認が中心であった。しかし今回は、Ａ社としては初めて本格的なWebシステムを構築することから、より確実に、安全性を評価するための監査を行わなければならない。
そこで有効な手段として、監視サーバの導入が挙げられる。具体的には、監査ソフトウェアを組み込んだサーバをＡ社の開発環境に設置し、従来は監査人が目視していたアクセスログの確認を自動化する方法である。自動化のメリットは、正確かつ効率よく監査証拠を精査できる点にある。監査ソフトウェアに対して適用日時などの入力パラメータを与えるだけで、短期間のうちに成果が得られるであろう。さらに、監査対象が拡大あるいは複雑化した場合であっても、パラメータの変更やサーバの増強などにより対応できる。
２−２．並行シミュレーション法の適用
データインテグリティの評価は、データベースの更新記録、あるいは、貸付金明細表や残高一覧表といった出力帳票により可能である。しかしＡ社の場合、ビジネスモデルの大幅な変更により開発規模が増大していたことから、効率性と網羅性を考慮した監査が必要である。
ここで用いるべき監査技法に、並行シミュレーション法が挙げられる。監査手続としては、テスト工程において、Ａ社の開発プログラムのほかに監査チームが用意した監査プログラムを動かし、これらの動作結果（金額などの数値）を検証ツールで比較・照合する。照合結果が不一致の場合は、原因を調べて問題を解決し再テストを行う。これにより証拠能力の高い監査証拠が得られ、効果的に監査目的を達成できると考えられる。
３．ＩＴ監査技法を用いる場合の留意点（設問ウ）
３−１．操作ミスの防止
システム監査人は従来の監査技法に加えて、上述したＩＴ監査技法について習熟する必要がある。その一方で留意すべき点は、監査実施時における操作ミスの防止である。例えば、監査ソフトウェアに誤ったパラメータを設定してしまうと、監査手続の妥当性が損なわれ、監査自体の品質が低下する。こうした単純なミスを防ぐためには、監査チーム内での複数人によるチェック行為を監査手順に組み込み、監査手続書に明記したうえで組織的なレビューを行うべきと考える。なお、レビュー結果は必ず文書として残すことが肝要である。
３−２．監査ソフトウェアの利用制限
システム監査人は、監査対象となるＡ社の開発資源に対して強力なアクセス権限をもつことになる。したがって、監査ソフトウェアの利用は監査目的の達成に限定されるべきである。こうした利用制限については、個別監査計画書に盛り込み、監査責任者がレビューを行う。また、実際に目的外の利用が行われていないことを第三者がチェックすべきだろう。但しレビュー及びチェック結果は文書に残すこと。
３−３．開発プロジェクトとの調整
並行シミュレーション法の適用については、Ａ社と十分に事前調整する必要がある。なぜなら、サービス開始までの期間にはあまり余裕がないため、テスト工程の間に遅滞なく監査を実施しなければならないからである。また、監査によって問題が発見された場合、改善後の再テスト時の監査方法についても取り決める必要がある。例えば、再テストではどの範囲まで並行シミュレーション法を用いるか、といった点である。
こうした点は、開発プロジェクトの計画段階で、監査計画との整合性を保つよう調整する必要がある。調整事項は、スケジュールのほか、ＩＴ監査技法の利用におけるハードウェア、ソフトウェア、ネットワーク、および人的資源を含めた経営資源全体へ及ぶことに留意すべきであろう。
以上
平成17年度 秋期 プロジェクトマネージャ
【午後２ 問題文】
問１ プロジェクトにおける重要な関係者とのコミュニケーションについて
情報システムの開発を円滑に進めるため、プロジェクトマネージャには直接の管理下にあるメンバ以外に、プロジェクトの進行に応じてかかわりをもつプロジェクト関係者との十分なコミュニケーションが求められる。
プロジェクト関係者は、情報システムの利用部門、購買部門、ベンダなどの組織に所属している。これらのうち、例えば、プロジェクトに要員を参加させている部門の責任者、プロジェクト予算の承認者、問題解決を支援する技術部門の責任者などは重要な関係者として認識することが大切である。
重要な関係者とのコミュニケーションが不足していると、意思決定や支援が実際に必要になったとき、重要な関係者が状況を認識するのに時間がかかり、対応が遅れ、プロジェクトの進捗に影響することがある。このような事態を招かないように、日ごろからプロジェクトの進捗状況や問題点を積極的に説明するなどのコミュニケーションを行い、相互の理解を深めておくことが重要である。その際、プロジェクトへの関心やかかわりは重要な関係者ごとに異なるので、コミュニケーションの内容や方法について、個別の工夫が必要となる。
あなたの経験と考えに基づいて、設問ア〜ウに従って論述せよ。
設問ア
あなたが携わったプロジェクトの概要と、プロジェクト関係者を、800字以内で述べよ。
設問イ
設問アで述べたプロジェクト関係者の中で、重要と考えた関係者とその理由について述べよ。また、重要な関係者とのコミュニケーションの内容や方法について、あなたが個別に工夫した点を含めて具体的に述べよ。
設問ウ
設問イで述べたコミュニケーションの内容や方法について、あなたはどのように評価しているか。また、今後どのように改善したいと考えているか。それぞれ簡潔に述べよ。
【再現論文 Pman wrote】
１．プロジェクト概要及び関係者
１−１．私が携わったプロジェクトの概要
関東中心に約200店鋪を有する金融機関（以下、ユーザと呼ぶ）では、汎用機で稼働していた財務会計システムが老朽化したことから、Ｗｅｂベースの新システムを再構築することとなった。当システムは、インターネットを利用し、ユーザ本店の基幹サーバと、各店鋪の支店サーバ及びパソコンとの連携により、財務情報を一元管理するデータベースの検索・更新や帳票出力等の事務処理を行うものである。
私が勤務する情報処理サービス会社Ｊ社は、ユーザの既存システム開発・運用を長年にわたり受託してきた。こうした経緯から、今回の新システム開発も要件定義以降をＪ社が一括して受託し、私はプロジェクトマネージャとして全体を統括、指揮することになった。
１−２．プロジェクト関係者
当プロジェクトにおける主な関係者について述べる。
（１）Ｊ社内の他のプロジェクト責任者（Ａ氏）
要件定義工程を４名で行う計画であったが、そのうち２名がＪ社内の他のプロジェクト（以下、現業と呼ぶ）との兼任で参加する。現業とは店鋪統合に関わる開発であり、Ａ氏はそのプロジェクトマネージャである。
（２）ユーザ側の統括責任者（Ｂ部長）
Ｂ部長はプロジェクトオーナーとして、納期や予算に関する一切の決定権を持っている。開発工期または工数に影響が出そうなプロジェクト途中の仕様変更に関しては、最終的にＢ部長の承認が必要になる。
（３）技術部門のオープン系エンジニア（Ｃ氏）
私はＷｅｂ技術を導入する場合の支援を必要としたため、オープン系システムを扱う技術部門に所属するＣ氏をオブザーバーとしてプロジェクトに参画させた。Ｃ氏は１０年以上の実務経験をもつ熟練ＳＥである。
２．重要な関係者とのコミュニケーション（設問イ）
２−１．私が重要と考えた関係者とその理由
プロジェクト関係者の中で、私が特に重要と考えたのはＡ氏である。その理由を以下に述べる。
今回のプロジェクトは、既存システムの再構築とは言え、ユーザ要求の深い分析が必要であった。再構築に伴い、ユーザ業務プロセスが変更されるからである。前述の兼任メンバー２名は、ユーザ本店で常駐ＳＥの経験があり金融業に精通していることから、業務分析及び要件定義の品質を確保するには不可欠な要員であると私は考えていた。しかし兼任のため、現業の作業負荷が大きくなった場合、当プロジェクト側の進行を妨げられ、進捗遅延が発生する恐れもある。したがって、兼任２名の現業の管理者であるＡ氏とは十分なコミュニケーションを行い、相互に調整を図りながらプロジェクトを運営していくことが重要となる。
一方、Ｂ部長については、既にＪ社との契約金額が決定しており仕様変更分は別契約としたことから、プロジェクトにおける重要度はＡ氏に比べ低いと判断した。
また、Ｃ氏については、以前私と共同開発を行ったこともある旧知の間柄であり、コミュニケーションは比較的容易と考えたため重要度は薄いと判断した。
２−２．コミュニケーションの内容と方法
重要な関係者であるＡ氏とのコミュニケーションについて、プロジェクト管理上の視点から以下に述べる。
（１）作業スケジュールの確認
兼任２名の作業は、次のように整理できる。
1)現業のテスト結果の検証作業（管理者はＡ氏）
2)新システムの要件定義作業（管理者は私）
最大のリスクは現業のテスト中に障害が発生することであり、日々の状況確認が不可欠となる。そこで私は、Ａ氏との対話による双方向コミュニケーションを、１日１回決まった時間に行うことをＷＢＳに組み込み、管理作業項目として相互に認識できるように工夫した。
実際の対応としては、Ａ氏に対し作業スケジュール表の提示を求め、遅れは無いか、２名に過度の作業負荷が生じていないか等について、対面で質疑応答をしながら確認した。スケジュール表は社内ＬＡＮ上の共有ディスクに置き、Ａ氏が不在の時も常に最新状態が参照できるように工夫した。また、日々の対面で伝え切れなかった情報は電子メールのやり取りで補充するなど、文字によるコミュニケーションも積極的に取り入れた。
（２）問題管理表の共有
Ａ氏はテスト工程、私は要件定義工程という違いはあるものの、プロジェクトマネージャとしての責任を有する点では同じ立場にあった。このため、Ａ氏との会話では、各々のプロジェクトにおける問題点が浮き彫りになった。例えば、ユーザ要求が曖昧なため要件定義が計画通りに進まない、ユーザの参加意識が不足ぎみ、周知・連絡が行き届かない、といった問題である。
そこで私は、問題管理表をＡ氏と共有し、相互の理解を深めるようなコミュニケーションを実践した。具体的には、個々の問題が兼任２名の作業進捗にどのような影響を及ぼすか、新たなリスクが生じないか等について意見交換を行った。その際に、事実に基づく客観的な意見（推定、判断）と、Ａ氏または私の主観的な意見（主張、直感）を出し合い、より多くの観点から問題解決への糸口を見つけられるように工夫した。
３．評価及び改善点（設問ウ）
３−１．評価
要件定義工程は計画通り２ヵ月で完了し、ユーザからの承認を得られた。兼任２名については、一時的に現業のテスト検証がピークとなり、当プロジェクトの要件定義に遅れが出そうな兆候もあった。しかし、検証作業の一部を他のメンバーに振り分けるなど作業負荷の平準化とスケジュール調整を行い、進捗遅延を防止できた。また、問題管理表の共有によりＡ氏と私の思考を可視化でき、プロジェクトを円滑に進められた。以上により、十分なコミュニケーションの効果があったと評価する。
３−２．今後の改善点
プロジェクトへの関心やかかわりは、関係者の地位、立場、置かれた状況により異なる。Ａ氏と私は共にＪ社内で対等な立場にあるため、コミュニケーションは取りやすかった。その反面、気心が知れてくると場当たり的な対応となり、認識のずれや意思決定の遅れが生じることもあった。こうした点は、さらに別の関係者を巻き込んで協力体制を広げる、コミュニケーション方法の標準化を進めるなど、組織的な改善に取り組む必要があろう。私はその改善点を整理したうえで、今後の開発プロジェクトに適用していく所存である。
以上
1月25日に掲載した「
SM合格時の再現論文」に、解説をつけ加えた。
青字の部分がポイントかと思われる。システム管理だけでなく、その他の論文試験にも応用できるだろう。春試験まで、まだ時間はある。すでに準備論文を仕上げた方も、これから書こうという方も、最後までじっくりと取り組んでみよう。
【タイトル】
システム障害の再発防止策について
【再現論文 Pman wrote】
１．システム概要及び発生した障害
１−１．私が携わった情報システムの概要
首都圏を中心に
約200支店を有する金融機関（以下、ユーザと呼ぶ）は、個人向け住宅ローンを主力商品の１つとしている。ユーザ業務は、
６年前に稼働開始した住宅ローン情報管理システムにより運営されている。当システムの開発・運用は、情報処理サービス会社Ｊ社が
アウトソーシングの形で受託しており、Ｊ社に勤務する私はシステム管理者として保守・運用に携わってきた。
当システムは、Ｊ社に設置される汎用コンピュータ上のデータベース（以下、ＤＢと呼ぶ）に対し、公衆回線を経由して、各支店の専用端末からアクセスする
集中処理方式である。
運用時間は、平日９時から１７時までをオンライン時間帯、同１７時から２０時頃までをバッチ処理時間帯としている。
☆ 1-1.解説 ---------- 約200支店を有する／６年前に稼働開始 システムの規模や背景がイメージしやすいように数字を使う。
アウトソーシング 組織間の関係を端的に示すための用語を入れる。
集中処理方式 集中か分散かを明らかにする。
運用時間 障害発生と防止策について論じるための伏線を敷いておく。
☆--------------------１−２．発生したシステム障害
稼働開始から２年程たった頃、オンライン時間中にあるユーザ支店の端末で、システムの異常終了が発生した。私はまず、
障害事象を正確に把握するため、ユーザ窓口の担当者に状況を確認したところ、経理業務中にある顧客データのＤＢ更新処理で、突然エラーメッセージが表示され更新不可になったという事象であった。次にＪ社内部でダンプリスト取得により障害の原因を調査したところ、該当データの
ＤＢ不整合のためアプリケーションエラーでアベンドしていたことが判明した。
☆ 1-2.解説 ---------- 障害事象を正確に把握 システム管理エンジニアとして適切な行動を書く。
ＤＢ不整合のためアプリケーションエラー ありきたりな事象だが発生したことを飾らず素直に書く。
☆--------------------１−３．ユーザ業務への影響
経理業務は、月単位で締め処理を行う期間が決まっている。この処理は、ローン残高の集計など
企業経営に関わる重要な事務処理であるため、システム障害による業務の停止は避けなければならない。私は、早急に障害対策を講じる必要があると考えた。
☆ 1-3.解説 ---------- 企業経営に関わる重要な事務処理 問題文の１行目「基幹業務に多大な影響」に合わせる。
☆--------------------２．システム障害の再発防止策について（設問イ）
２−１．障害発生の根本原因
障害発生の当日、ほかに１３支店で同じように異常終了が発生した。このことから、特定の顧客データに何らかの異常が起きたのではないかと私は推測した。調査の結果、前日の夜間におけるＤＢパッチ作業のミスが判明した。
ＤＢパッチとは、ユーザからの依頼により、Ｊ社において特定のデータを強制的に塗り変える例外作業で、ユーティリティを用いた手作業である。ところが、本来パッチを当てるべきデータとは異なるデータに対し誤ってパッチを当てたため、ＤＢ不整合が発生したものであった。こうした作業ミスを引き起こすような
運用方法に、障害の根本原因が潜んでいたと私は認識した。
☆ 2-1.解説 ---------- ＤＢパッチとは、 読み手に伝わるように軽く説明を入れておく。
運用方法に、障害の根本原因が潜んでいた やや漠然としているが、運用面の問題があることに言及する。
☆--------------------２−２．システム運用面からの対策案
以上の根本原因を取り除くための対策案を列挙する。
案(1) 作業要員の増強
ＤＢパッチ作業を実施するのは
週１〜２日、夜間バッチ処理後の２時間程度であったため、当初、作業担当者は１名で十分と考えていた。しかし、今回のシステム障害は、
担当者のケアレスミスを防止または発見できなかったことに原因がある。また、顧客データを更新するという重要な作業を一人で行うことは、
Ｊ社にとってリスクが高いと考えられる。そこで私は、作業要員を２名に増強し、パッチ作業時に
ダブルチェックを行い、ミスがないかどうかの検証を強化することを考案した。
案(2) 運用手順書の見直し
運用記録の証跡書類を見ると、通常の運用作業における手順はほぼ確立されていたが、ＤＢパッチ作業等の例外運用については確立されていなかった。例外運用の手順書は、ユーティリティの操作方法や障害発生時の対処方法が中心であり、Ｊ社の責任範囲や作業の承認ルールが不明確であった。今回のシステム障害は、パッチ作業における
承認者及び確認者が曖昧であるなど、手続上の不備があったことに起因する。このため私は、
運用手順書を全面的に見直し、改版することを考案した。
案(3) 検証ツールの導入
パッチ対象のデータ件数が大きいほど、今回のような障害発生による影響も大きくなる。そこで、今までは作業結果をＤＢダンプリストの取得による目視確認としていたが、
検証ツールによる自動確認に変更することを考案した。ツールは
表計算ソフトのマクロ機能を利用したものであり、
確認作業の省力化が期待できる。
☆ 2-2.解説 ---------- 週１〜２日、夜間バッチ処理後の２時間 できるだけ定量的に表現する。
担当者のケアレスミスを防止または発見できなかったことに原因 2-1で言い足りなかったことを具体的に書く。
Ｊ社にとってリスクが高い 組織的な観点から分析したことをアピールする。
ダブルチェックを行い、 要員を増強して何を行うのか明記する。
運用記録の証跡書類を見る 客観的なデータをもとに分析したことをアピールする。
承認者及び確認者が曖昧 2-1で言い足りなかったことを具体的に書く。
運用手順書を全面的に見直し、改版する 問題文の「運用手順」に触れ、見直してどうするのか明記する。
検証ツールによる自動確認 問題文から引用できるものは引用し、論文に組み込む。
表計算ソフト Excelなどの製品名は書かないこと。
確認作業の省力化が期待できる どのようなメリットや効果があるのか述べる。
☆--------------------２−３．対策案の採否の決定方法
まず案(1)については、ダブルチェックの効果がある反面、
作業時間が深夜に及ぶこともあるため、要員の
工数確保が難しかった。体制面を変更するにはユーザからの承認が必要であったが、私の提案に対し、ユーザ側は「１名で十分」との見解を示した。確かに、発生確率の低い障害に対して
体制面を強化するのは非効率である。このため私は案(1)を不採用とした。案(2)については、Ｊ社の
各関係者に対しヒアリングを行ったところ、安定運用のために手順書は整備すべきとの意見が多かった。加えて、ＤＢパッチ作業は一時的なものでなく、
今後も継続する見通しであることを勘案し、私は、運用手順書を
改版することに決定した（採用した）。案(3)については、ツールの開発工数・費用が膨らむことを懸念したが、必要性の高いチェック機能に絞り込むことで
費用を抑えられる。さらに、ツールの入力となるチェック用データをユーザ側で作成して頂けるなど
協力体制が得られたことから、私は案(3)を採用した。
☆ 2-3.解説 ---------- 作業時間が深夜に及ぶ／工数確保が難しかった 要員管理の面から検討したことをアピールする。
体制面を強化するのは非効率 問題文の「体制面などから採否を決定する」に合わせる。
各関係者に対しヒアリング 問題文の「関係者と協議し、」に合わせる。
今後も継続する見通しであることを勘案 総合的に判断して決めた様子を述べる。
改版することに決定した ここぞという箇所は自信をもって言い切ること。
費用を抑えられる／協力体制が得られた 問題文の「費用対効果、体制面などから採否を決定」に合わせる。
☆--------------------３．評価及び課題（設問ウ）
３−１．評価
運用手順書の見直しにより、ＤＢパッチ作業時の
承認〜実施〜検証の流れが明確になり、例外運用でありながら実際には定型的な業務として標準化することができた。また、検証ツールの導入により、パッチ作業時間が従来より
３０％短縮するなど、省力化及び効率化を図ることができた。これらの対策により、
障害の再発防止ができていることから、私の実施した活動は全体的に効果があったと評価する。
☆ 3-1.解説 ---------- 承認〜実施〜検証の流れが明確になり、 案(2)の効果があったことを書く。
３０％短縮 案(3)の効果があったことを書く。
障害の再発防止ができている 論文のテーマをもう一度振り返り、その結果を明らかにする。
☆--------------------３−２．今後の課題
システム障害の再発防止策を検討して実施した結果、運用手順に関しては、改善すべき点が残っていると感じた。なぜなら、手順書の一部の項目については、
運用環境の変化により形骸化したり、実態とかけ離れている部分もあったからである。したがって、今後も継続的に運用手順の有効性や妥当性を確認していく必要があろう。
☆ 3-2.解説 ---------- 運用環境の変化により形骸化 システム管理エンジニアの視点から問題提起する。
☆--------------------
平成17年度 春期 テクニカルエンジニア（システム管理）
【午後２ 問題文】
問１ システム障害の再発防止策について
今日では、情報システムの障害発生が、企業や官公庁の基幹業務に多大な影響を与える可能性が高くなっている。このような状況を踏まえて、障害発生時には、まず障害からの迅速な復旧を図る。その後、発生した障害の根本原因を究明し、再発防止策を検討して実施することが重要である。
システム管理エンジニアとしては、運用上の仕組み、運用手順、関係者間の情報伝達方法など、システム運用面からの再発防止策を講じる必要がある。例えば、システムを確実に運用するために、運用手順の作成時に、同様なシステム運用の経験をもつエンジニアに参加してもらいレビューを行うことや、作業結果を確実に確認するために、目視確認からツールによる自動確認に変更することなどが考えられる。
システム運用面からの再発防止策は、次の手順に従って関係者と協議し、実施が決定される。
(1) 障害発生時に特定された直接的な原因の背景にある根本原因を究明する。
(2) 根本原因を取り除くための対策案を、システム運用面から幾つか列挙する。
(3) 列挙された対策案に対し、費用対効果、体制面などから採否を決定する。
あなたの経験に基づいて、設問ア〜ウに従って論述せよ。
設問ア
あなたが携わった情報システムの概要と、発生したシステム障害の概要及び業務への影響について、800字以内で述べよ。
設問イ
設問アで述べた障害に対し、究明された障害発生の根本原因は何か。また、その根本原因を取り除くために検討した、システム運用面からの再発防止策は何か。さらに、それらの採否をどのように決定したか。工夫した点を中心に、具体的に述べよ。
設問ウ
設問イで述べた再発防止策について、どのように評価しているか。今後の課題は何か。それぞれ簡潔に述べよ。
【再現論文 Pman wrote】
１．システム概要及び発生した障害
１−１．私が携わった情報システムの概要
首都圏を中心に約200支店を有する金融機関（以下、ユーザと呼ぶ）は、個人向け住宅ローンを主力商品の１つとしている。ユーザ業務は、６年前に稼働開始した住宅ローン情報管理システムにより運営されている。当システムの開発・運用は、情報処理サービス会社Ｊ社がアウトソーシングの形で受託しており、Ｊ社に勤務する私はシステム管理者として保守・運用に携わってきた。
当システムは、Ｊ社に設置される汎用コンピュータ上のデータベース（以下、ＤＢと呼ぶ）に対し、公衆回線を経由して、各支店の専用端末からアクセスする集中処理方式である。運用時間は、平日９時から１７時までをオンライン時間帯、同１７時から２０時頃までをバッチ処理時間帯としている。
１−２．発生したシステム障害
稼働開始から２年程たった頃、オンライン時間中にあるユーザ支店の端末で、システムの異常終了が発生した。私はまず、障害事象を正確に把握するため、ユーザ窓口の担当者に状況を確認したところ、経理業務中にある顧客データのＤＢ更新処理で、突然エラーメッセージが表示され更新不可になったという事象であった。次にＪ社内部でダンプリスト取得により障害の原因を調査したところ、該当データのＤＢ不整合のためアプリケーションエラーでアベンドしていたことが判明した。
１−３．ユーザ業務への影響
経理業務は、月単位で締め処理を行う期間が決まっている。この処理は、ローン残高の集計など企業経営に関わる重要な事務処理であるため、システム障害による業務の停止は避けなければならない。私は、早急に障害対策を講じる必要があると考えた。
２．システム障害の再発防止策について（設問イ）
２−１．障害発生の根本原因
障害発生の当日、ほかに１３支店で同じように異常終了が発生した。このことから、特定の顧客データに何らかの異常が起きたのではないかと私は推測した。調査の結果、前日の夜間におけるＤＢパッチ作業のミスが判明した。ＤＢパッチとは、ユーザからの依頼により、Ｊ社において特定のデータを強制的に塗り変える例外作業で、ユーティリティを用いた手作業である。ところが、本来パッチを当てるべきデータとは異なるデータに対し誤ってパッチを当てたため、ＤＢ不整合が発生したものであった。こうした作業ミスを引き起こすような運用方法に、障害の根本原因が潜んでいたと私は認識した。
２−２．システム運用面からの対策案
以上の根本原因を取り除くための対策案を列挙する。
案(1) 作業要員の増強
ＤＢパッチ作業を実施するのは週１〜２日、夜間バッチ処理後の２時間程度であったため、当初、作業担当者は１名で十分と考えていた。しかし、今回のシステム障害は、担当者のケアレスミスを防止または発見できなかったことに原因がある。また、顧客データを更新するという重要な作業を一人で行うことは、Ｊ社にとってリスクが高いと考えられる。そこで私は、作業要員を２名に増強し、パッチ作業時にダブルチェックを行い、ミスがないかどうかの検証を強化することを考案した。
案(2) 運用手順書の見直し
運用記録の証跡書類を見ると、通常の運用作業における手順はほぼ確立されていたが、ＤＢパッチ作業等の例外運用については確立されていなかった。例外運用の手順書は、ユーティリティの操作方法や障害発生時の対処方法が中心であり、Ｊ社の責任範囲や作業の承認ルールが不明確であった。今回のシステム障害は、パッチ作業における承認者及び確認者が曖昧であるなど、手続上の不備があったことに起因する。このため私は、運用手順書を全面的に見直し、改版することを考案した。
案(3) 検証ツールの導入
パッチ対象のデータ件数が大きいほど、今回のような障害発生による影響も大きくなる。そこで、今までは作業結果をＤＢダンプリストの取得による目視確認としていたが、検証ツールによる自動確認に変更することを考案した。ツールは表計算ソフトのマクロ機能を利用したものであり、確認作業の省力化が期待できる。
２−３．対策案の採否の決定方法
まず案(1)については、ダブルチェックの効果がある反面、作業時間が深夜に及ぶこともあるため、要員の工数確保が難しかった。体制面を変更するにはユーザからの承認が必要であったが、私の提案に対し、ユーザ側は「１名で十分」との見解を示した。確かに、発生確率の低い障害に対して体制面を強化するのは非効率である。このため私は案(1)を不採用とした。案(2)については、Ｊ社の各関係者に対しヒアリングを行ったところ、安定運用のために手順書は整備すべきとの意見が多かった。加えて、ＤＢパッチ作業は一時的なものでなく、今後も継続する見通しであることを勘案し、私は、運用手順書を改版することに決定した（採用した）。案(3)については、ツールの開発工数・費用が膨らむことを懸念したが、必要性の高いチェック機能に絞り込むことで費用を抑えられる。さらに、ツールの入力となるチェック用データをユーザ側で作成して頂けるなど協力体制が得られたことから、私は案(3)を採用した。
３．評価及び課題（設問ウ）
３−１．評価
運用手順書の見直しにより、ＤＢパッチ作業時の承認〜実施〜検証の流れが明確になり、例外運用でありながら実際には定型的な業務として標準化することができた。また、検証ツールの導入により、パッチ作業時間が従来より３０％短縮するなど、省力化及び効率化を図ることができた。これらの対策により、障害の再発防止ができていることから、私の実施した活動は全体的に効果があったと評価する。
３−２．今後の課題
システム障害の再発防止策を検討して実施した結果、運用手順に関しては、改善すべき点が残っていると感じた。なぜなら、手順書の一部の項目については、運用環境の変化により形骸化したり、実態とかけ離れている部分もあったからである。したがって、今後も継続的に運用手順の有効性や妥当性を確認していく必要があろう。
以上
| ホーム |
