2010年04月22日
2010年プロジェクトマネージャ試験 午後ＩＩ 論文 解凍速報目次
2010（平成22年度)プロジェクトマネージャ試験午後Ⅱ解答速報
※留意事項
この解答速報は、システム監査小論文試験等の
「合格のためのガイドラインを予測するもの」
です。完全性を保障するものではなく、また、
利用される皆さんの合格を保証するものではありません。その点を十分、
ご留意いただいたうえでご利用ください。
新版ＣＤ「ITストラテジスト小論文突破講座（ver2.0）」は
2010年4月16 リリース！
ライバルは既に持っている！
基本的仕様：CD
オプションで午後I,午後IIの添削がつきます。
■合格のためのガイドラインと正答率
合格と足切りのガイドラインは正答率60％であると予想します。
■総評と解答速報
●総評
●午後Ⅱ
2010年04月21日
2010年プロジェクトマネージャ試験 午後ＩＩ 解答速報概況
2010年プロジェクトマネージャ試験 午後II 小論文の総評
■総評
- 非常にオーソドックスで平易で良問が多かった
- 問題文に指定が明確に指定されているから、指定にしたがって解けば容易に論文がかけるる。
■難易度
[難易度]★が多いほど難しい
- 問1 ★★★★☆
- 問2 ★★★★☆
- 問3 ★★★★☆
上記の難易度を決めた理由は次の通りである。
- 問1：プロジェクト目的を明確に述べておくことが重要である。リスク分析も合理的な手法を述べる必要がある
- 問2：チームリーダへの権限の委譲、良い意味での管理がポイントである
- 問3：進捗管理上のリスク予防措置と課題発生の把握と対処を的確にかけるか
■問題別、小論文戦略
合格できるか、否かについての基準を示そう。
| 問題 | 問題の必須条件 | 合格のための工夫 |
| 問1 | プロジェクトの特徴とリスクを合理的に結び付ける | 設問アで潜在的なリスクを述べておいて、対処の具体的対策を述べられるか |
| 問2 | チームリーダをいかに管理するかが課題 | 権限の範囲を限定して、権限を委譲しつつ、コントロールすることが要点 |
| 問3 | 進捗管理に品質確保がからめて出題されていることがポイント | 予防対策と対処を設問イとウに切り分けて書く |
■総評と解答速報
●総評
●午後Ⅱ
■2010プロジェクトマネージャ試験 解答速報目次に戻る
■プロジェクトマネージャ試験小論文合格講座
平成22年(2010年)度、プロジェクトマネージャ試験 午後ＩＩ 問3解答例
平成22年 プロジェクトマネージャ試験 午後Ⅱ 問3 解答例
１．プロジェクト概要と重点管理項目
１．１ プロジェクト概要
私が参画したプロジェクトはＣ社の原価計算システムの開発プロジェクトである。Ｃ社は製造業であり、独自の標準原価計算に基づいた原価計算方式、積算方式を採用している。従来は原価計算のパッケージソフトを採用していたが現実との業務との乖離が発生して課題となっている。そこでリニューアルし、既存の会計パッケージと連携する必要がある。
本プロジェクト規模はおおよそ50人月。開発組織は顧客の会計担当者と顧客プロジェクト管理者。当社は管理者としての私。会計に詳しいＳＥ、プログラマ2名、データベース管理者1名である。Ｃ社は新年度4月からのカットオーバーであり、テスト期間を含めると余裕期間がない状態であった。
1.2 重点管理したアクティビティ
開発工程をWBS(Work Breakdown Structure)として細分化して、アクティビティかする。これらの工程をスケジュール上に並べてパート図化すると次の工程が課題となっていることがわかる。(1)原価計算の仕様の要件定義
通常の原価計算と、Ｃ社方式との原価差異を明確化して開発用件として定義しておく必要がある。特に、勘定科目体系や原価差異などの取り扱いについて、企業会計原則や商法及び法人税法上の取り扱いでコンプライアンス上の問題点がないか十分な精査が必要であると共に、顧客との意見調整も必要と予想された。
(2)会計パッケージとのインターフェース部分の設計
原価差異分析がかわると勘定科目体系に影響が出る。現在使用中の会計パッケージの勘定科目体系との調整が必要になる。現行の財務諸表に影響が出ないような対策が必要と予測された。
２．完了日を守るための対策について
２．１ 対策の基本戦略
上記のアクティビティとクリティカルパスが進捗管理上の課題と予想されたため、その対策として以下の考えを文書化して、上司の承認を得た上でプロジェクト組織に周知徹底、及び顧客に伝達した
(1)(1) 財務諸表アウトプットの品質確認のため最終1.5ヶ月はテスト期間とすること
(2)(2) 勘定科目の作りこみや、その影響調査を含めて顧客の協力を要請すること。そのために要件定義に1.5ヶ月の期間を確保すること
(3)会計に関連する専門用語、アクティビティ名を徹底して標準化して、紛らわしい用語、類似用語を使わないようにすること
(4)ユーザと開発部隊の認識を共有化するために、用語や認識のあいまいさを徹底的に排除して疑問点があれば即座に質問、回答、報告、共有するための掲示板をネット上に構築すること
(5)(4)の仕組みを使って、プロジェクトの進捗の可視化をユーザ側と共有すること
2.2 分担のルールと周知徹底の工夫
顧客の協力が得られない場合、システムの仕様確定が遅れて納期遅延になる可能性があった。
2.2 重点アクティビティへの配慮
原価差異分析アクティビティが原価管理システムの品質と、会計システムへの影響が大きいと判断した。この仕組みが混乱するとプロジェクトの納期に大きな遅延が予想されるので次のような配慮を計画した。
(1)会計に詳しいＳＥのユーザ会議、プロジェクト会議への参画。
(2)(2)要件定義段階で、会計システムのコンプライアンスを確保するために当社顧問税理士への相談の実施。
(3)原価差異分析の勘定科目変更による、会計システムへの影響を波及分析を、シミュレータ実施。その結果のユーザ共有・プロジェクト内共有
(4)重点アクティビティについての週単位での進捗管理の実施。予想される進捗遅れに関する顧客への連絡体制の整備
３ 進捗遅れの原因と影響分析および対策
3.1 進捗遅れとその原因
(1)コンプライアンス上の問題
当初、ユーザの説明では一部、出力される勘定科目が変更されても問題ない。そのままシステム開発を継続してほしいという意見であった。しかし、要件定義段階で税理士から「企業会計原則の継続性の原則から問題がある」という指摘をうけて見直し作業を実施したため、要件定義作業が2週間の遅れが発生した。
(2)単体テスト結果のユーザ確認遅れ
ユーザとの進捗管理情報、製品情報の共有化を実施していた。しかし、原価加工費の差異分析用データベース詳細設計の結果にユーザー担当者のＯＫがでて、次の作業に取り掛かったタイミングで担当者上司から、原価分析データ用の識別符号をぜひ付加して欲しいという意見がでた。これは、ユーザ担当者が上司の意見を我われに伝達忘れしたことが原因である。また、上司も他の会議に時間を割かれていて、共有されている仕様に対するチェックが甘くなったのが原因と予想された
3.2 追加対策
(1)変更管理ついて
変更管理についてはユーザを交えた、スコープ管理委員会を臨時に開催して、優先順位、他のシステムへの影響度を考慮して判断。上記2案は重要なので採択。進捗スケジュールを見直した。
(2)スケジュール対応
今回のスケジュール対応についてのポリシとして「専門性の高いプロジェクトであるから、追加要員投入は混乱の原因である」と判断。実施しなかった。
従って、スケジュールの組み換えで対処した。勘定科目対応の必要性のないアクティビティ開発を優先させて、会計に強いＳＥとデータベース技術者を集中的にユーザ変更要求に対応させた。他のメンバーは別作業を並列化した。
(3)レビューの強化
会計システムでは間違いが許されないので、設計変更のタイミング、作りこみ後のタイミングでユーザを交えたレビューを実施して、設計書上のあいまいさや、作りこんだ製品のアウトプットの正しさを検証した。
平成22年(2010年度）プロジェクトマネージャ試験 午後II 問2解答例
平成22年 プロジェクトマネージャ試験 午後Ⅱ 問2 解答例
１．プロジェクトの特徴とプロジェクト編成
１．１ プロジェクトの概要
私が開発に関与したプロジェクトはB社のwebシステムの開発システムである。B社は趣味商品の小売業であり、Webサイトで年間数千万円の売上をあげており商品点数も8,000件ある。B社の現行Webシステムは、使い勝手も悪く、Web検索にも弱いシステムであったためB社経営者であるC氏はWebサイトのリニューアルを企画したシステム開発規模は30人月と見積もられた。契約の形態は概要設計までが準委任契約、内部設計から結合テストまでが請負契約であった。
1.2 プロジェクトの特徴
開発に当たってユーザと協議したことは①ユーザにとって更新しやすいシステムであること。②8000件あるデータの移行、エントリ変更が円滑にできること。このため、開発ツールとして、データベースとWebを連度させるCMS(Contrents Management System)ツールを利用することになった。当社にとってCMSツールの使用は初めてであり、CMS開発に強い企業との連携が必要であった。１．３ プロジェクトの組織編制について
プロジェクト編成は、顧客側がB社C社長、D氏、E氏である。当社側がプロジェクト管理者の私、SE兼リーダのT氏、SEのU氏である。また、当社には不慣れなCMS開発であったため、社外パートナーとしてCMSにつよいP社に外注依頼した。外注先の選定基準は当社規則にしたがった。P社にはSEであるQ氏、WebデザイナーであるR氏がいた。
私は本来、本プロジェクトに専任でありたかったが、上司から招請を受けて別プロジェクトと兼任体制であった。このため、プロジェクトマネージャの代理としてT氏を指名していた。
２．プロジェクトリーダへの権限委譲
２．１ 権限委譲させた業務とその理
(1)権限委譲させた業務
私がプロジェクトリーダT氏に権限委譲した業務は①進捗管理業務、②パートナー企業との交渉権限である
(2)権限委譲したその理由
①プロジェクトマネージャ兼任であること
管理者である私が兼任であるため、業務過多になる可能性が高かった。この結果、事務処理量を軽減する必要があった。
②パートナー企業のコントロール
本プロジェクトの成否は、工数の60%を占めるパートナー企業P社のコントロールであった。この進捗を把握し、かつ、成果物の品質を十分管理するためには部下に権限委譲したほうが水準の高い管理が実現できると考えた。
③部下の人間的特性と力量
部下のT氏の人間的特性・力量として、SEとしての力量よりも正確な事務処理能力、理論的な交渉力に期待するところが多かった
2.2 分担のルールと周知徹底の工夫
顧客の協力が得られない場合、システムの仕様確定が遅れて納期遅延になる可能性があった。
2.2 リスク分析
(1)分担のルール
部下に権限の以上に当たっては、プロジェクト計画書に組織図を明記したうえで、権限分掌範囲を明記した。また、T氏に面接を行い、なぜ、権限委譲を行う理由についても丁寧に説明して合意を得た。
(2)周知徹底の手段について
①プロジェクト記録の共有
パートナ企業との交渉記録、決定事項、懸案事項についてイントラネットで共有した。私は外部に出張している際は毎日、VPN回線からアクセスし記録の確認を行った。
②日報での報告
Tからプロジェクトの進捗や課題、及び労働時間とその作業との関連を電子メールで日報として報告させた。そして、疑問がある場合は、電子メールで質問した。
③週一回の面談
共有ファイルだけでは、プロジェクトのディテールが不明なケースも多い。そこで週一回の面会のチャンスを得て。現状の課題とその原因、Tがもっている解決策とその評価を行った。
３ 評価と課題
3.1 評価
(1)進捗管理
進捗管理について、パートナー企業とは順調だったが、ユーザ企業B社の作業が遅れ気味であった。これはB社がプロジェクトよりも現状業務を優先させたためである。このため当社やパートナー企業に待ち工数が発生した。
(2)パートナーとの交渉力
パートナー企業へ当社の要望や意見を正しく伝える能力、パートナー企業の成果物をテストで吟味してゆき、その記録を残す能力において、T氏は期待した能力どおりの力を発揮した。
3.2 課題と改善点
(1)課題
T氏の場合、理論的である反面、理が勝ちすぎる点がある。したがって、当社に理があって、顧客企業に否があっても、顧客が協力を渋ることがあった。
T氏はそれを「勝手だ」と断定する点があった。
(2)改善点
Tのいうことはもっともな点はあるが、Webは顧客の協力なくしてプロジェクト目的を達成させることはでき
ない。このため、T氏についてはOJT的に①仕事の薦め方、②顧客を褒めて動かす方法などを指導する必要があると実感した
2010年04月20日
平成22年(2010年度)プロジェクトマネージャ試験 午後II 解答例
平成22年 プロジェクトマネージャ試験 午後Ⅱ 問1 解答例
１．プロジェクトの特徴とプロジェクト目標
１．１ プロジェクトの概要
私が開発に関与したプロジェクトはＡ社の生産販売管理システムの開発システムである。A社は製造業であり、得意先から引き合いをすると、技術的に対応可能か検討した上で、原価計算、見積り、受注、購買、生産する。情報システムの規模はおおよそ200人月であり、プロジェクトメンバーは常時10人である。
1.2 プロジェクトの特徴
契約の形態はA社が当社得意先との関係も深いため、詳細設計から結合テストまでが請負契約となっている。また、A社は原価管理システムに独自の計算方法を持っていて、A社担当者の協力なくして開発は困難である。また、受注電文のフォーマットが取引先によって異なっているため、どの電文を標準化するかが未確定要素であった。私は開発以前からA社担当者B課長と打ち合わせをしていて上記二点について開発着手前の解決を依頼していたが、達成されないまま開発プロジェクトが開始された。また、A社からの依頼事項として、クラウドの開発を懇願されていたが、当社にとっては始めての開発であり不安要素であった。
1.3 プロジェクトの目標について
プロジェクト本来の目標は、A社の要求する納期、品質で、情報システムを依頼されたコスト内で納めることである。しかし、今回は契約面において不利な交渉であったこと、内部設計工程からが請負契約である条件であること、未確定要素の多い開発プロジェクトであるため、次のような目標を立てた。- リスクを最大に見積もった規模見積りで対処する
- プロジェクトを黒字プロジェクトで完了させる
- 品質標準を保ったシステム開発の完了
２．プロジェクトリスクとリスク分析
２．１ プロジェクトリスク
(1)赤字プロジェクトの恐れ
未確定の機能開発を正確に見積もることができないため、開発工程が最悪1.5倍程度になる可能性がある。このケースは25％程度の赤字プロジェクトになる
(2)品質標準が保てないこと
未確定仕様について、顧客の仕様変更がプロジェクト中に頻発すると、品質標準が保ちにくくなり、顧客の利益が損なわれること。
(3)納期遅延
顧客の協力が得られない場合、システムの仕様確定が遅れて納期遅延になる可能性があった。
2.2 リスク分析
(1)規模見積りについての分析
上記、リスクのうち、最大のものが(1)味覚提要その影響による赤字プロジェクトである。これを定量的に分析する手法として iCOST法を使った。
iCOST法はFP法で概算の規模見積りを一端、行い、その後、COCOMO法を用いて再見積りを行う。そのなかで、リスク要因となる①未確定要素、②はじめての技術基盤（クラウド開発）をパラメタとして計算式にいれ他結果、最悪のケースは開発段階で1.5倍の規模となるという結果が出た。
(2)品質標準と維持について
ここで品質とは、①バグなどの不具合、②ユーザの求める機能の作りこみ、③ユーザの求める性能、④テストが不十分なことによるキャリーオーバーなバグの存在、⑤ドキュメント品質、⑥移植性などを総合的にさしていう。
バグなどはゴンベルツ曲線などによるバグの摘出数で定量的に見積もることができる。また、ユーザの求める機能や品質はユーザからのクレーム数などで測定できる。ドキュメント品質はドキュメントのページ数/kstepの定量的側面と、曖昧さの排除のような定性的側面で評価する。
３ リスク対応計画と評価
3.1 リスク対応計画
(1)(1)規模見積りリスク
規模見積り対策として以下の対策を講じた。
①COCOMOで最終算出した予算規模に当社標準の待ち工数を加算して、概要設計後の段階で顧客に提出した。この段階で未解決な仕様は残っていた。
②顧客の意思決定責任者と相談して、未解決のキャリーオーバは顧客のメリットにならないことを説明して、顧客サイドの協力を得て仕様確定を加速した。当社側も、上司の承認を得て、製造業の仕様確定の専門家を招請して顧客のニーズを引き出してゆき、内部設計中盤には仕様を確定していった。
(2)品質管理対策
仕様変更が品質に与える影響をA社責任者に説明し、スコープ委員会を設置してもらった。仕様変更依頼が発生するつどにスコープ委員会で決済し、採択、優先順位付けを行い仕様変更を仕分けした。
(3)納期遅延対
納期遅延対策は独立して開発できる機能を選定して、仕様確定待ちしているメンバーをシフトして先攻開発していった。
3.2 評価
(1)顧客との利害の共有
顧客と利害を共有し、交渉を進めることにより、円滑に顧客の協力を引き出すことができた.
(2)意志決定者へのアプローチ
顧客窓口の立場を守ることも重要であるが、重要な決定事項がある場合は、先方の責任者に可能な限り同席してもらった。
(3)定性的見積りの導入
顧客に規模と人月、コストの関係を可視化することによって、顧客のコスト意識を引き出すことに成功した。また、開発サイドでもリスクとコストの関係が明確になって先手を打って顧客にアプローチできた。また、リスクと思える技術基盤を開発前に技術習得させることにしたことも有効だった。
(4)スコープ委員会
ユーザと委員会で合意を得ながらプロジェクトをすすめたことによって、仕様変更を予想以上に最小化できた。
2010年システム監査技術者試験小論文 概況
2010年システム監査技術者試験 午後II 小論文の総評
■総評
- 非常に意欲的で、システム監査技術者としての実力を問うようなテーマが出題された
- 問2の内部統制報告と問3の事業継続計画はもしかすると、予想が当たった方もいると思う。
- 全3問のなかで問2が一番難しいなと思った。
全体的に良く練られていて、相対的に難しい。小論文試験では、その意図を 解答者が読み取って、網羅的に小論文を執筆することが出来るかが合否を分けるポイントであろう。あえて言うと 問２がもっとも難しい問題ではないかと思われる。
■難易度
[難易度]★が多いほど難しい
- 問1 ★★★★☆
- 問2 ★★★★★
- 問3 ★★★★☆
上記の難易度を決めた理由は次の通りである。
- 問1：システム管理基準にシステムの安全性の確認事項が掲載されている。自分勝手に論文を書くと合格できない。
- 問2：文書の共有化とアクセス管理のトレードオフの問題。両者のバランスの取り方が難しい
- 問3：システム管理基準の該当箇所を今回のテーマである「IT運用コストの削減」に置き換えれば 簡単に解答できる
■問題別、小論文戦略
合格できるか、否かについての基準を示そう。
| 問題 | 問題の必須条件 | 合格のための工夫 |
| 問1 | システム管理基準が理解できているか | システム開発工程に遡っての監査がかけるか |
| 問2 | アクセス管理と文書共有化の妥当な共存点をみつけられるか | 電子文書の共有化の有効性と監査証跡とを合理的に結び付けられるか |
| 問3 | システム管理基準が理解できているか | コスト削減の実現性とコスト削減のリスクの両論を明確に書き抜くこと |
■総評と解答速報
●総評
●午後Ⅱ
■2010システム監査技術者試験 解答速報目次に戻る
■システム監査技術者試験小論文合格講座
平成22年度(2010年)システム監査技術者試験 小論文 解答速報
2010（平成22年度) システム監査技術者試験午後Ⅱ解答速報
※留意事項
この解答速報は、システム監査小論文試験等の
「合格のためのガイドラインを予測するもの」
です。完全性を保障するものではなく、また、
利用される皆さんの合格を保証するものではありません。その点を十分、
ご留意いただいたうえでご利用ください。
新版ＣＤ「ITストラテジスト小論文突破講座（ver2.0）」は
2010年4月16 リリース！
ライバルは既に持っている！
基本的仕様：CD
オプションで午後I,午後IIの添削がつきます。
■合格のためのガイドラインと正答率
合格と足切りのガイドラインは正答率60％であると予想します。
■総評と解答速報
●総評
●午後Ⅱ
2010年システム監査技術者試験 午後II 問１ 解答例
平成22年 システム監査技術者試験 午後Ⅱ 問1 解答例
１．１ 組み込みシステムの概要
私が内部監査を実施したシステムはＡ社の自動倉庫システムの開発システムである。特に自走ロボットのブロック間移動制御、フォークリフトアームの動作制御システムである。このロボットは自動倉庫内を走行し、指定された貨物を指定された場所に搬送する機能を有している。必要に応じてスタッフのいない深夜にも稼動する。また、スタッフのいる昼間も稼動する。
1.2 設計に関して配慮が必要なこと
自走ロボットの組み込みシステム設計に当たっては、概要設計書が作成され、①自走ロボットの機能定義、②自走ロボットの安全制御機能定義、③①と②の性能定義が記載された。
そのうえで、①や③もさることながら②の安全制御機能が最重要課題となり、制御異常を検知した場合、最悪の場合システムを全面停止にする必要がある。
1.3 不具合が業務や社会に及ぼす影響
自走ロボットの誤動作が業務や社会に及ぼす影響は以下のとおりである。
1.3.1 基本的機能、性能要件を満たさないケース
- 物流業務が遅滞して、荷主、消費者に迷惑がかかる
- (1)により荷主、販売主に経済的損害が発生する
- (2)により、自動倉庫会社の信頼が損なわれる
1.3.2 安全性を満たさないケース
フォークリフト異常、走行異常による影響は次のとおりである。。
- )自走ロボットの暴走で自動倉庫の施設を破壊する
- (1)により、倉庫内の商品を破壊する、倉庫内作業員の身体生命に脅威を与える。
- (1)により、企業の設備投資計画、財務状態の悪化
- (2)による労働災害の発生とＡ社の使用低下
２．組み込みシステムのシステムテスト内容
２．１ システムテストに当たって準拠する文書
以下の文書に準拠してシステムテストを実施する。- 顧客からいただいたRFP(Request For Proposal)
- 顧客企業との開発打合せ記録
- システム要件定義書、概要設計
- テスト計画書、テストデータ、テスト結果報告書
２．２ 監査の要点
以下の観点で監査を実施する。
- システム開発計画書が顧客によって承認されているか
- システム開発計画にあたって、リスク分析を網羅的に実施しているか
- 組み込みシステム異常時の事業継続計画が計画化されているか、システム開発にその要件が組み込まれているか
- フォークリフトの安全性についてコンプライアンスを満たしているか。
- システム開発に要する資材の調達が調達基準に適合して適切に実施されているか
- システム開発の各段階において、担当責任者がシステムの安全性基準への適合性を検証しているか。それをユーザが承認しているか
- 開発にかかわる以下の要点への準拠を確認すること
- 情報システムの性能は要件定義を満たしていること
- 組み込みシステムの保守点検が容易にするために保守性を高めること
- 他の自動倉庫システムとの整合性を確保すること
- 障害対策を設計段階で講じていること
- 誤謬対策を講じていること
- モニタリング機能を備えていること。
２．３ システムテスト
上記の観点でシステムテストの実施計画を述べる。- (1) システムテスト計画書は開発担当者とテスト担当者が承認していること
- (2) システムテストに当たっては、システムの安全性の要求事項を網羅的にテストケース設定しておくこと
- (3) テストデータ作成はテスト計画に基づいて行われること
- (4) システムテストデータはユーザ、開発、運用、保守責任者すべてが承認すること
- (5) 上記の記録をすべて保存すること
３ 監査手続き
システムテストの適切性を確かめるために、組織的な協力が不可欠である
(1)開発関係者のヒアリング
ユーザ、依頼者である開発プロジェクトマネージャ、運用担当者、保守責任者のヒアリングを実施して、監査要件を把握する。
(2)予備調査
①必要とする、安全性にかかわるコンプライアンス要件の調査
②「要件定義書」レビューによるシステム概要やシステム構成の把握
③運用担当者、保守責任者アンケートによる、安全性確保の実務の把握
④「プロジェクト計画書」レビューによる、開発組織と工程管理の概要の把握
⑤「単体、結合テスト報告書」レビューによる品質、性能の状態の把握。
(3)個別計画
被監査組織、調査する文書。監査証跡、アンケート、チェックリストおよび監査スケジュールの準備を実施して、被監査組織とスケジュール調整を実施する。
(4)監査の実施
被監査組織を訪問し、チェックリストに基づいて、①インタビュー、②テスト立会い、③テストデータの評価、④テスト立会い者の意見、結論の記録、⑤そこで発生した不具合、その是正予防計画について監査調書としてとりまとめる。
(5)監査報告書の取りまとめ
監査目的にあわせて①被監査組織の開発活動の妥当性、②ユーザが求める安全性への準拠基準への適合性、③潜在するリスクへの考慮事項、④事故発生時の事業継続計画への配慮事項について監査報告書にまとめる。
監査報告書を上長に提出し、意見を聞き、修正を加える。
(6)監査結果報告会
被監査組織、利害関係者を含めて監査結果報告会を実施する。そのなかで監査根拠を提示しつつ監査結果を説明して、助言型監査報告を行う。
報告書の中で修正事項がある場合は相互に検討し報告書を修正する。
(7)是正、予防計画の監視
被監査組織の不備の対処、是正予防に状況を監視する。
(8)フォローアップ監査
(7)で安全性が確保されたかについてフォローアップ監査を実施する。
(9)計画の見直し
Ａ社の開発計画のすすめかたに問題があった場合、開発計画の見直しを助言する。
以上
平成22年度、システム監査技術者試験 午後II、問3
平成22年 システム監査技術者試験 午後Ⅱ 問3 解答例
１．ITコスト削減とその理由
１．１ ＩＴコスト削減の概要
私が内部監査を実施したシステムはC社のWeb販売システムの運用コストである。C社では農作物系の加工品 をインターネットで販売している。
1.1.1 現行システム
現在稼動しているWebシステムは２つある。１つは大手ショッピングモールであり、いまひとつはWeb専門企業に構築、運営を任せている独自ドメインWebサイトである。この独自ドメインＷｅｂサイトは運営業者サイトにおかれていて、業者の提供する機能を利用している。
1.1.2 削減取り組み内容と目的
経営層によるＷｅｂにかかわるＩＴコスト削減の方針は次のとおりである。
- 大手ショッピングサイトを、5年をめどに撤退する。その結果、システム利用料を０円にする
- 独自ドメインサイトの運営を自主運営として、別サーバに移転する。この結果、毎月業者に支払っているＷｅｂサイト運営費を０円とする。
この結果、Ｃ社のネットビジネス事業の営業利益を売上げに対して７％確保する。
1.2 ＩＴコスト削減の理由
大手ショッピングモールでは、売上課金やメルマガ課金などが負担になっており、現在では月額1,000万円近くシステム使用量の名目で支払っている。また、独自ドメインサイトでは、月額10万円程度の運用コストがかかっていて、Webショップの費用対効果を低下させている。 また、大手ショッピングモールに毎月支払う1000万円の金額が事業運転資金の資金繰りを悪化させている。この問題を放置すると、黒字倒産になる可能性もある。このほか前年度の税理士法人監査でも独自ドメインサイトの運営コストの高さが指摘事項でもあった。２．監査項目
監査上、重要な点は情報システムコスト削減が経営方針や戦略的目標を実現するために貢献できるかがポイントである。２．１ コスト削減計画についての監査項目
Ｃ社ではシンクライアントに関する情報システムリスクを次のように認識している。
- ＩＴコスト削減計画がＩＴガバナンスに基づいて行われているか
- ITコスト削減計画が情報化投資構想と矛盾しないこと
- ＩＴコスト削減後の情報システムが組織の情報システムのあるべき姿と矛盾しないこと
- ＩＴコスト削減計画が情報セキュリティ基本方針と合致すること。
- 上記のＩＴコスト削減案を含めた全体計画が組織の長の承認を得ているとともに利害関係者の合意を得ていること。
- ＩＴコスト削減案の後の経営資源を明確にすること
- ＩＴコスト削減案の投資効果、リスクが明確になっていること
- ＩＴコスト削減後の情報システムの品質が明確になっていること
- ＩＴコスト削減の優先順にが明確になっていること
- ＩＴコスト削減にあたっては外部資源の活用を考慮していること
- 情報システム化委員会でＩＴコスト削減案を策定し、モニタリングし、検討すること
- 情報システム化委員会でＩＴコスト削減案の技術採用方針を明確にすること
- ＩＴコスト削減について、影響、効果、実現等の観点から選択肢を検討すること
- ITコスト削減について投資対効果の算出方法を明確にしておくこと
2.2ＩＴコスト削減によるリスク監査
以下の観点で監査を実施する。
- 情報資産の管理方針、体制を明確にすること
- 業務手続の変更が必要になる
- ＩＴコスト削減にあたってはユーザ、開発、運用、保守責任者が承認するこ
- ＩＴ資源の調達にあたっては組織のルールにしたがって行われること
- ＩＴコスト削減に当たってユーザの利便性が確保されること
- ＩＴコスト削減はユーザ要求を満たすこと
- ＩＴコスト削減によって障害対策機能が劣化しないこと
- 誤謬、不正防止、機密保護対策が設計されているこ
- モニタリング機能を考慮して設計しておくこ
3 監査で発見された問題点と改善案
3.1 監査で発見された問題点
(1)ユーザの求める機能の確保にコストが必要であること
SSLやPOP Before SMTPなどのセキュリティ機能、ショッピングカート機能、認証機能、代金決済機能などASP(Application Service Provider)を利用するとコスト増に繋がる要因が発見された。
(2)ASPサイトのセキュリティ強度について
専門家の意見を求めたところ「ショッピングカートが外部の不正なアクセス者によって数ヶ月ダウンしたことがある」「そのような場合、代替案の検討も必要ではないか」とん指摘を受けた。ＡＳＰのセキュリティ強度の
検証が難しい
(3)ユーザ部門の不安
大手Ｗｅｂサイトを離脱すると顧客リストを返却しなくてはならず、顧客離れが発生するのではないかという
不安がweb運営担当者から提示された。
3.2 改善案
以上の問題についての改善案を監査報告書の中で助言した。
(2)ASPのセキュリティ強度
外部ＡＳＰを利用したコストモデルと現行のコストモデルの対比表を項目別に作成し、経営者や利害関係者に説明した。
比較も個別項目別比較と全体比較をサービス別に行いつつ、営業利益７％達成可能か検討した。
(1)ユーザの求める機能の確保にコスト
第三者組織に対して内部監査はできない。このため、ＡＳＰ採用は代替案を含めて3案提示して、以下の項目について検討した。①ユーザ数、②おもな利用者の利用実績、③業界の評価、④過去の大きなセキュリティ事故
この報告データを利害関係者に提示した。
(3)ユーザの不安
集客の代替案を販売促進計画書としてとりまとめ、検索エンジン対策等の対策を含めて提示した。
以上