※留意事項
　この解答速報は、システム監査小論文試験等の 「合格のためのガイドラインを予測するもの」 です。完全性を保障するものではなく、また、 利用される皆さんの合格を保証するものではありません。その点を十分、 ご留意いただいたうえでご利用ください。

新版ＣＤ「ITストラテジスト小論文突破講座（ver2.0）」は
2010年4月16 リリース！
ライバルは既に持っている！
基本的仕様：CD
オプションで午後I,午後IIの添削がつきます。

■合格のためのガイドラインと正答率

合格と足切りのガイドラインは正答率60％であると予想します。

■総評と解答速報

●総評

●午後Ⅱ

• 問1：情報システム又は組込みシステムに対するシステムテストの監査について
• 問2：電子データの活用にかかわるシステム監査について
• 問3：IT保守運用コスト削減計画の監査について

■総評

1. 非常にオーソドックスで平易で良問が多かった
2. 問題文に指定が明確に指定されているから、指定にしたがって解けば容易に論文がかけるる。

■難易度

[難易度]★が多いほど難しい

• 問1　★★★★☆
• 問2　★★★★☆
• 問3　★★★★☆

　上記の難易度を決めた理由は次の通りである。

• 問1：プロジェクト目的を明確に述べておくことが重要である。リスク分析も合理的な手法を述べる必要がある
• 問2：チームリーダへの権限の委譲、良い意味での管理がポイントである
• 問3：進捗管理上のリスク予防措置と課題発生の把握と対処を的確にかけるか

■問題別、小論文戦略

　合格できるか、否かについての基準を示そう。

■総評と解答速報

●総評

●午後Ⅱ

• 問1：情報システム又は組込みシステムに対するシステムテストの監査について
• 問2：電子データの活用にかかわるシステム監査について
• 問3：IT保守運用コスト削減計画の監査について

■2010プロジェクトマネージャ試験　解答速報目次に戻る

■プロジェクトマネージャ試験小論文合格講座

１．プロジェクト概要と重点管理項目

１．１　プロジェクト概要

　私が参画したプロジェクトはＣ社の原価計算システムの開発プロジェクトである。Ｃ社は製造業であり、独自の標準原価計算に基づいた原価計算方式、積算方式を採用している。従来は原価計算のパッケージソフトを採用していたが現実との業務との乖離が発生して課題となっている。そこでリニューアルし、既存の会計パッケージと連携する必要がある。

　本プロジェクト規模はおおよそ50人月。開発組織は顧客の会計担当者と顧客プロジェクト管理者。当社は管理者としての私。会計に詳しいＳＥ、プログラマ2名、データベース管理者1名である。Ｃ社は新年度4月からのカットオーバーであり、テスト期間を含めると余裕期間がない状態であった。

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)レビューの強化
　会計システムでは間違いが許されないので、設計変更のタイミング、作りこみ後のタイミングでユーザを交えたレビューを実施して、設計書上のあいまいさや、作りこんだ製品のアウトプットの正しさを検証した。

１．プロジェクトの特徴とプロジェクト編成

１．１　プロジェクトの概要

　私が開発に関与したプロジェクトはB社のwebシステムの開発システムである。B社は趣味商品の小売業であり、Webサイトで年間数千万円の売上をあげており商品点数も8,000件ある。B社の現行Webシステムは、使い勝手も悪く、Web検索にも弱いシステムであったためB社経営者であるC氏はWebサイトのリニューアルを企画したシステム開発規模は30人月と見積もられた。契約の形態は概要設計までが準委任契約、内部設計から結合テストまでが請負契約であった。

1.2 プロジェクトの特徴

１．３　プロジェクトの組織編制について

２．プロジェクトリーダへの権限委譲

２．１　権限委譲させた業務とその理

(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的に①仕事の薦め方、②顧客を褒めて動かす方法などを指導する必要があると実感した

１．プロジェクトの特徴とプロジェクト目標

１．１　プロジェクトの概要

私が開発に関与したプロジェクトはＡ社の生産販売管理システムの開発システムである。A社は製造業であり、得意先から引き合いをすると、技術的に対応可能か検討した上で、原価計算、見積り、受注、購買、生産する。情報システムの規模はおおよそ200人月であり、プロジェクトメンバーは常時10人である。

1.2 プロジェクトの特徴

1.3 プロジェクトの目標について

1. リスクを最大に見積もった規模見積りで対処する
2. プロジェクトを黒字プロジェクトで完了させる
3. 品質標準を保ったシステム開発の完了

２．プロジェクトリスクとリスク分析

２．１　プロジェクトリスク

(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)スコープ委員会
　ユーザと委員会で合意を得ながらプロジェクトをすすめたことによって、仕様変更を予想以上に最小化できた。

■総評

1. 非常に意欲的で、システム監査技術者としての実力を問うようなテーマが出題された
2. 問2の内部統制報告と問3の事業継続計画はもしかすると、予想が当たった方もいると思う。
3. 全3問のなかで問2が一番難しいなと思った。

全体的に良く練られていて、相対的に難しい。小論文試験では、その意図を 解答者が読み取って、網羅的に小論文を執筆することが出来るかが合否を分けるポイントであろう。あえて言うと 問２がもっとも難しい問題ではないかと思われる。

■難易度

[難易度]★が多いほど難しい

• 問1　★★★★☆
• 問2　★★★★★
• 問3　★★★★☆

　上記の難易度を決めた理由は次の通りである。

• 問1：システム管理基準にシステムの安全性の確認事項が掲載されている。自分勝手に論文を書くと合格できない。
• 問2：文書の共有化とアクセス管理のトレードオフの問題。両者のバランスの取り方が難しい
• 問3：システム管理基準の該当箇所を今回のテーマである「IT運用コストの削減」に置き換えれば 簡単に解答できる

■問題別、小論文戦略

　合格できるか、否かについての基準を示そう。

■総評と解答速報

●総評

●午後Ⅱ

• 問1：情報システム又は組込みシステムに対するシステムテストの監査について
• 問2：電子データの活用にかかわるシステム監査について
• 問3：IT保守運用コスト削減計画の監査について

■2010システム監査技術者試験　解答速報目次に戻る

■システム監査技術者試験小論文合格講座

※留意事項
　この解答速報は、システム監査小論文試験等の 「合格のためのガイドラインを予測するもの」 です。完全性を保障するものではなく、また、 利用される皆さんの合格を保証するものではありません。その点を十分、 ご留意いただいたうえでご利用ください。

新版ＣＤ「ITストラテジスト小論文突破講座（ver2.0）」は
2010年4月16 リリース！
ライバルは既に持っている！
基本的仕様：CD
オプションで午後I,午後IIの添削がつきます。

■合格のためのガイドラインと正答率

合格と足切りのガイドラインは正答率60％であると予想します。

■総評と解答速報

●総評

●午後Ⅱ

• 問1：情報システム又は組込みシステムに対するシステムテストの監査について
• 問2：電子データの活用にかかわるシステム監査について
• 問3：IT保守運用コスト削減計画の監査について

１．１　組み込みシステムの概要

　　私が内部監査を実施したシステムはＡ社の自動倉庫システムの開発システムである。特に自走ロボットのブロック間移動制御、フォークリフトアームの動作制御システムである。このロボットは自動倉庫内を走行し、指定された貨物を指定された場所に搬送する機能を有している。必要に応じてスタッフのいない深夜にも稼動する。また、スタッフのいる昼間も稼動する。

1.2 設計に関して配慮が必要なこと

1.3 不具合が業務や社会に及ぼす影響

　自走ロボットの誤動作が業務や社会に及ぼす影響は以下のとおりである。

1.3.1 基本的機能、性能要件を満たさないケース

1. 物流業務が遅滞して、荷主、消費者に迷惑がかかる
2. (1)により荷主、販売主に経済的損害が発生する
3. (2)により、自動倉庫会社の信頼が損なわれる

1.3.2 安全性を満たさないケース

　フォークリフト異常、走行異常による影響は次のとおりである。。

1. )自走ロボットの暴走で自動倉庫の施設を破壊する
2. (1)により、倉庫内の商品を破壊する、倉庫内作業員の身体生命に脅威を与える。
3. (1)により、企業の設備投資計画、財務状態の悪化
4. (2)による労働災害の発生とＡ社の使用低下

２．組み込みシステムのシステムテスト内容

２．１　システムテストに当たって準拠する文書

1. 顧客からいただいたRFP(Request For Proposal)
2. 顧客企業との開発打合せ記録
3. システム要件定義書、概要設計
4. テスト計画書、テストデータ、テスト結果報告書

２．２　監査の要点

　以下の観点で監査を実施する。

1. システム開発計画書が顧客によって承認されているか
2. システム開発計画にあたって、リスク分析を網羅的に実施しているか
3. 組み込みシステム異常時の事業継続計画が計画化されているか、システム開発にその要件が組み込まれているか
4. フォークリフトの安全性についてコンプライアンスを満たしているか。
5. システム開発に要する資材の調達が調達基準に適合して適切に実施されているか
6. システム開発の各段階において、担当責任者がシステムの安全性基準への適合性を検証しているか。それをユーザが承認しているか
7. 開発にかかわる以下の要点への準拠を確認すること
• 情報システムの性能は要件定義を満たしていること
• 組み込みシステムの保守点検が容易にするために保守性を高めること
• 他の自動倉庫システムとの整合性を確保すること
• 障害対策を設計段階で講じていること
• 誤謬対策を講じていること
• モニタリング機能を備えていること。

２．３　システムテスト

• (1) システムテスト計画書は開発担当者とテスト担当者が承認していること
• (2) システムテストに当たっては、システムの安全性の要求事項を網羅的にテストケース設定しておくこと
• (3) テストデータ作成はテスト計画に基づいて行われること
• (4) システムテストデータはユーザ、開発、運用、保守責任者すべてが承認すること
• (5) 上記の記録をすべて保存すること

３　監査手続き

　システムテストの適切性を確かめるために、組織的な協力が不可欠である
(1)開発関係者のヒアリング
　ユーザ、依頼者である開発プロジェクトマネージャ、運用担当者、保守責任者のヒアリングを実施して、監査要件を把握する。
(2)予備調査
　①必要とする、安全性にかかわるコンプライアンス要件の調査
　②「要件定義書」レビューによるシステム概要やシステム構成の把握
　③運用担当者、保守責任者アンケートによる、安全性確保の実務の把握
　④「プロジェクト計画書」レビューによる、開発組織と工程管理の概要の把握
　⑤「単体、結合テスト報告書」レビューによる品質、性能の状態の把握。
(3)個別計画
　被監査組織、調査する文書。監査証跡、アンケート、チェックリストおよび監査スケジュールの準備を実施して、被監査組織とスケジュール調整を実施する。
(4)監査の実施
　被監査組織を訪問し、チェックリストに基づいて、①インタビュー、②テスト立会い、③テストデータの評価、④テスト立会い者の意見、結論の記録、⑤そこで発生した不具合、その是正予防計画について監査調書としてとりまとめる。
(5)監査報告書の取りまとめ
　監査目的にあわせて①被監査組織の開発活動の妥当性、②ユーザが求める安全性への準拠基準への適合性、③潜在するリスクへの考慮事項、④事故発生時の事業継続計画への配慮事項について監査報告書にまとめる。 　
監査報告書を上長に提出し、意見を聞き、修正を加える。
(6)監査結果報告会
　被監査組織、利害関係者を含めて監査結果報告会を実施する。そのなかで監査根拠を提示しつつ監査結果を説明して、助言型監査報告を行う。
　報告書の中で修正事項がある場合は相互に検討し報告書を修正する。
(7)是正、予防計画の監視

　被監査組織の不備の対処、是正予防に状況を監視する。
(8)フォローアップ監査
　(7)で安全性が確保されたかについてフォローアップ監査を実施する。
(9)計画の見直し
　Ａ社の開発計画のすすめかたに問題があった場合、開発計画の見直しを助言する。
以上

１．ITコスト削減とその理由

１．１　ＩＴコスト削減の概要

　私が内部監査を実施したシステムはC社のWeb販売システムの運用コストである。C社では農作物系の加工品 をインターネットで販売している。

1.1.1　現行システム

1.1.2 削減取り組み内容と目的

　経営層によるＷｅｂにかかわるＩＴコスト削減の方針は次のとおりである。

1. 大手ショッピングサイトを、5年をめどに撤退する。その結果、システム利用料を０円にする
2. 独自ドメインサイトの運営を自主運営として、別サーバに移転する。この結果、毎月業者に支払っているＷｅｂサイト運営費を０円とする。

　この結果、Ｃ社のネットビジネス事業の営業利益を売上げに対して７％確保する。

1.2 ＩＴコスト削減の理由

２．監査項目

２．１　コスト削減計画についての監査項目

　Ｃ社ではシンクライアントに関する情報システムリスクを次のように認識している。

1. ＩＴコスト削減計画がＩＴガバナンスに基づいて行われているか
2. ITコスト削減計画が情報化投資構想と矛盾しないこと
3. ＩＴコスト削減後の情報システムが組織の情報システムのあるべき姿と矛盾しないこと
4. ＩＴコスト削減計画が情報セキュリティ基本方針と合致すること。
5. 上記のＩＴコスト削減案を含めた全体計画が組織の長の承認を得ているとともに利害関係者の合意を得ていること。
6. ＩＴコスト削減案の後の経営資源を明確にすること
7. ＩＴコスト削減案の投資効果、リスクが明確になっていること
8. ＩＴコスト削減後の情報システムの品質が明確になっていること
9. ＩＴコスト削減の優先順にが明確になっていること
10. ＩＴコスト削減にあたっては外部資源の活用を考慮していること
11. 情報システム化委員会でＩＴコスト削減案を策定し、モニタリングし、検討すること
12. 情報システム化委員会でＩＴコスト削減案の技術採用方針を明確にすること
13. ＩＴコスト削減について、影響、効果、実現等の観点から選択肢を検討すること
14. ITコスト削減について投資対効果の算出方法を明確にしておくこと

2.2ＩＴコスト削減によるリスク監査

　以下の観点で監査を実施する。

1. 情報資産の管理方針、体制を明確にすること
2. 業務手続の変更が必要になる
3. ＩＴコスト削減にあたってはユーザ、開発、運用、保守責任者が承認するこ
4. ＩＴ資源の調達にあたっては組織のルールにしたがって行われること
5. ＩＴコスト削減に当たってユーザの利便性が確保されること
6. ＩＴコスト削減はユーザ要求を満たすこと
7. ＩＴコスト削減によって障害対策機能が劣化しないこと
8. 誤謬、不正防止、機密保護対策が設計されているこ
9. モニタリング機能を考慮して設計しておくこ

3 監査で発見された問題点と改善案

3.1 監査で発見された問題点

(1)ユーザの求める機能の確保にコストが必要であること
　SSLやPOP Before SMTPなどのセキュリティ機能、ショッピングカート機能、認証機能、代金決済機能などASP(Application Service Provider)を利用するとコスト増に繋がる要因が発見された。

(2)ASPサイトのセキュリティ強度について
　専門家の意見を求めたところ「ショッピングカートが外部の不正なアクセス者によって数ヶ月ダウンしたことがある」「そのような場合、代替案の検討も必要ではないか」とん指摘を受けた。ＡＳＰのセキュリティ強度の 検証が難しい

(3)ユーザ部門の不安
　大手Ｗｅｂサイトを離脱すると顧客リストを返却しなくてはならず、顧客離れが発生するのではないかという 不安がweb運営担当者から提示された。

3.2 改善案

　以上の問題についての改善案を監査報告書の中で助言した。

(2)ASPのセキュリティ強度
　外部ＡＳＰを利用したコストモデルと現行のコストモデルの対比表を項目別に作成し、経営者や利害関係者に説明した。 　比較も個別項目別比較と全体比較をサービス別に行いつつ、営業利益７％達成可能か検討した。

(1)ユーザの求める機能の確保にコスト
　第三者組織に対して内部監査はできない。このため、ＡＳＰ採用は代替案を含めて3案提示して、以下の項目について検討した。①ユーザ数、②おもな利用者の利用実績、③業界の評価、④過去の大きなセキュリティ事故 　この報告データを利害関係者に提示した。

(3)ユーザの不安
　　集客の代替案を販売促進計画書としてとりまとめ、検索エンジン対策等の対策を含めて提示した。
以上

ＣＤ受講生の方からご質問をいただきました

　ご質問いただいた内容は以下のとおりです。

• 設問ア「シンクライアント導入の目的と効果」についてどうとらえるか。
• 設問イ「シンクライアントリスク」を網羅的に示せば良いのか。それとも「リスクと効果について比較すべきか」
• アとイは別設問なのですから、相互の関連に神経質にならなくても良いでしょうか？

回答

• 設問ア「シンクライアント導入の目的」は「通常のＰＣを放置することのリスク 低減を目的と書けば良い。「効果」はシンクライアント導入によるメリットを書けば良い
• 設問イでは「シンクライアントリスク」を網羅的に淡々と示せば良い。 「リスクと効果について比較すべきか」は必要がない。
• 「アとイは別設問だから、相互の関連に神経質にならなくても良いか？」 については問題文に「設問アに関連して」と書いているから関連して書くべき

質問内容

回答

• 監査計画の立案「情報セキュリティ監査基準」＝実施基準＝　１．監査計画の立案
• 監査証拠の入手と評価「情報セキュリティ監査基準」＝実施基準＝　２．監査の実施　2.1
• 監査調書の作成と保存「情報セキュリティ監査基準」＝実施基準＝　２．監査の実施　2.2
• 監査業務の体制の確保「情報セキュリティ監査基準」＝実施基準＝　３．監査業務の体制
• 監査報告書の提出と開示「情報セキュリティ監査基準」＝報告基準＝　１．報告書の提出と開示
• 監査報告に基づく改善指導（フォローアップ）「情報セキュリティ監査基準」＝報告基準＝　５．監査報告に基づく改善指導

• 監査計画の立案年度監査計画、経営者レビュー、予備調査、個別監査計画
• 監査証拠の入手と評価本調査(インタビュー、監査ツールの使用、アンケート、レビュー)
• 監査調書の作成と保存
• 監査業務の体制の確保監査報告書の作成、上位監査者の評価
• 監査報告書の提出と開示証拠の提示、改善勧告もしくは監査結果の開示
• 監査報告に基づく改善指導（フォローアップ）是正、予防、マネジメントレビューの監視、フォローアップ監査

読者からの質問内容

回答

試験センターの出題趣旨

題意

• 問題文のなかで「情報システムの運用特性に応じた全般統制の有効性監査が必要」としている
• 設問イでも「情報システムの運用特徴と関連づけて」と論述範囲を定めている
• よって、情報システムの運用特性と関連付けつつ、監査手続きを述べるべきである

回答

• 題意に従うことは重要である
• しかし、そのほかに重要なことがあり、それはシステム監査基準に準拠していることである
• システム監査基準に準拠していなければ、たとえ実務的に有効な手段であっても減点対象となりうる

1.1 情報化促進の目的

　私がコンサルティングで関与したするB社は、自動車関連の部品を 製造販売する製造業である。
B社では自動車会社大手数社から部品の生産を依頼されると 、その新部品であると仕様を技術検討したうえで原価計算、見積りを行い 契約、受注にいたる。従来部品の場合は仕様変更の有無を確認して 部品展開や部品調達後生産する。
　情報化促進の目的は次のとおりである。

1. 自動車部品メーカから受注に関連する作業を迅速化するように求められていて対応したい
2. 受注にかかかわる情報をデータベース化して経営層は受注残の状況を把握したい
3. そのことによって資金計画立案を円滑化したい
4. 受注には顧客対応、原価計算、技術検討などの多部署との連携が必要で情報共有化を図りたい

1.2 業務特性

　第一回目の経営者とのヒアリング、現場代表者の意見収集の結果、次のような 業務特性が存在することが判明した。

1. かつて、2000万円かけて構築した受注管理システムが現在、殆ど使われていない
2. その原因として、現場の意見や実情が反映されていないという不満が存在する
3. メーカからの依頼書はEDIを通じてオンラインでB社に通達される
4. しかしEDIの仕様が各社によって異なり、標準的な作業が存在しない
5. ISO9000を取得している。そのためには受注に関連する標準的な書式が必要となっている
6. この結果、ISO9000とEDIとの結果に矛盾が発生する

　基本的に標準化を進めたいが、どのように標準化を すすめてよいのかがわからないような状態であることがわかった。　

2 情報化促進の阻害要因と原因究明

2.1 情報化促進の阻害要因

2.1.1 EDIと当社標準化受注フォームとの矛盾

　当社は５社の自動車、家電大手との付き合いがある。 その関係で各社のEDIを全て使っていて、その電文フォーマットにしたがって 受注処理をしている。各大手の受注フォーマットはそれぞれ少しずつ異なっており B社の受注処理標準化遅れの原因となっている。
　その問題点は次のとおりである。

1. 受注した電文を印刷し、当社の標準フォーマットに手作業で再記入する
2. その記入に間違いがないか記入者本人が確認する
3. さらに記入者の上司が確認する

2.1.2　当社標準化受注フォームとISO9000との矛盾

　ISO9000では品質保証を目的として受注記録の記入と 保持、点検を標準化することを求めている。
　その現在の問題点は次のとおりである。

1. 当社の標準フォーマットをISO9000審査・監査に耐える フォーマットに改ざんしている
2. かいざんは、ISO9000の審査直前1ヶ月に集中的実施する
3. すなわち改ざんに関連する受注に関わる二重処理の実態がある

2.2 分析手法について

　私の分析法は、①経営者へのヒアリング、②組織図のレビュー、 ③現場代表者（課長）のインタビュー、④現状分析（業務分析と 情報化のワークフロー）、⑤現場作業員を交えた情報化会議開催である
　特に、業務分析は今回の問題解決の要と考えて、次の手法を 駆使して分析時間の短縮と正確化を図った。

1. ISO9000の品質マニュアル、作業マニュアル等の文書を 精査する
2. ISO9000のマニュアルに記入された作業手順を ワークフロー化する。（DFD）
3. DFDの読み方をスタッフに教育して、DFD化した作業と 実際の作業を比較して矛盾点、欠落点を情報化委員会で指摘してもらう
4. 再度、作り直したDFDをもとに、 現実的な現状作業を洗い出す
5. その際に、上記の矛盾点や、標準化推進の課題を社内や経営層にに周知徹底する

3 促進案

　促進案にはIT的手法と、経営的手法がある。

3.1 促進案

　提案内容は次のとおりである。
3.1.1 標準化について

①各社EDIからの受注データを一端、データベースに蓄積する。
②データベースには各社受注種別ごとのフォーマットを作りこんでおく。
③その際に受注電文の原本と、名寄せした項目に変換し、蓄積した電文を の両方を保持する
④標準的な名称に名寄せした電文を標準フォーマットへ 変換し、これを受注フォームとする
⑤これにより、転記作業が廃止される
3.1.2 現場の意見を反映した情報システム
　このほか、情報化委員会で明らかになった現場の不満や 欠落していた業務プロセスを情報システムに反映することにする。

3.2 経営的手法

　上記のIT的問題解決を円滑に図るために次のような施策を 提案する。

1. ISOの自己適合宣言を行う。
2. ISO監査機関の教条的監査から逃れるために。 ISO自己適合宣言し、ISO本来の趣旨を理解し監査する団体に監査を依頼する
3. その結果、監査用の文書作成という価値０の作業が軽減される。
4. 情報化促進の状況を確認するために内部監査としてISO以外にシステム監査を実施する。
5. システム監査によってITガバナンスの適切さが検証される

1.1 事業施策の概要

　私が勤務するA社は、中古のコミックブックの販売チェーン店である。 Ａ社では倒産した書店の本を買い取り、チェーン店舗で販売するほか、 インターネットカフェなどの企業向けに法人営業を新規に事業化し、 ネット販売で営業を行う計画である。
　通常事業所向けコミック販売は漫画ごとのシリーズセット売り が原則となる。この他、次のような仕様を備えていなければならない。

1. 倒産した書店から買い取った書籍をカテゴリ別に分類する
2. 分類した書籍をカテゴリ別、セット単位にストックする
3. セット単位で在庫ストックに格付け（美本、汚損、欠本等）し、値付けする
4. ストックを台帳登録する
5. 在庫セットをチェーン店用、ネット販売用と所在を明確にする
6. 必要に応じて在庫移動ができるようにする

1.2 情報システムの果たす役割

　情報システムの果たす役割は、コミック法人セット販売事業（以下法人事業） のインフラとして、次のような機能を備えていることを期待されている。

1. セット本の在庫管理機能（保管、ストック場所、在庫数、状態、価格、移動）
2. 在庫機能と倉庫、物流、受注機能との有機的連携の保持
3. 在庫のWebイトへの公開機能
4. Webサイトからの受注、対応機能（受注確認メールを含む）
5. Webサイトから得た顧客の登録機能、内部からの参照分析機能
6. 売上データの参照、分析機能

　当該事業はスタッフ5人だけで実施する予定である。 このため、省力化、合理化が求められ、本の仕入れ、検本識別、整理、倉庫業者への指示だし、 出荷指示、販売対応・集計・分析以外の業務は極力IT化する 必要があった。　

2 個別情報システム化構想について

2.1 システムが備えているべき機能の定義

　Webシステムと内部のネットワークシステム、及び、在庫管理や顧客管理、店舗管理を 行うシステムとの連携が必要とされる。

1. クッキーによる同一顧客の識別機能
2. アクセスログの採取機能
3. cgiを通したWebサイトと顧客データベース、在庫データベースとの連携機能
4. 顧客との通信の安全性を確保するためのSSL等のセキュリティ機能
5. 既存の在庫管理システム、顧客管理システム、社内ネット管理システムとの連携機能

2.2 情報システムの構築手法について

　全ての情報システムを手作り作りこむと1億円以上のシステム構築費が 必要となる試算が情報システム部から出た。
　そこで、情報システムの費用対効果を高めるために、 そして、迅速に短期間（10ヶ月以内で）情報システムを高知kするために次のような 情報化構想を立案して経営者の承認を得た。

1. Webサーバ、データベースサーバのセキュリティ機能はストレージ企業に委託して 集中管理させる
2. 物流システム、在庫システムとの連携は、物流と在庫を委託している3rd-partyの 提供するインターフェースを標準とする
3. 受注機能、発送や分析機能は3rd-party提供の派ケージソフトウェアを活用する
4. Webサイトの運営保守はCMS(Contents Management System) を使い省力化する
5. その他の不足する機能のみ新たに作りこむ

3 検討と評価

3.1 検討したこと

　上記の方針に基づき、経営者、情報システム部、3rd-party担当者を含めて 以下の検討を実施した。 ①当初の予算と納期で実現が可能か。
②既存の情報システムが3rd-pary提供のインターフェースで 他のシステムとの連携が技術的に可能か。
③運用コストが新たに全て作りこんだ場合に比べて安価にすいいできるか。
④計数化、可視化しているため、ＩＴ予算組みが容易に可能であるか ⑤情報システム部がシステム運用監視が現状体制で可能か
⑥過不足なく、新事業部の求める機能が実現可能か

3.2 評価

　検討事項に関連する評価事項は次のとおりになる。

1. 年間の運用コストは1,500万円となり、独自新規構築よりも安価。
2. インターフェースの部分実現可能性は課題があるものの3rd-partyの強力 が得られて技術開示があれば可能。
3. サーバ監視を外部に委託するため情報システム部の運用負担もかるい。
4. 機能的に細部の不足はあるものの既存システム機能を遣えば 欲しい機能の90％は実現可能。
5. 調査結果、在庫状況や販売実績、顧客管理機能も充実していることが判明
6. これにより経営の可視化が可能。。
7. また、コンテンツ管理や販売促進企画に新事業部が集中できることが判明

※総評は以下のとおりです。

• レベル５からレベル４に格下げになった関係で、情報戦略の視点に欠ける出題となった
• 問３は情報化計画よりも、やや開発よりの問題となった。
• 試験形式として設問イで概略を述べて、設問ウで具体策と評価を述べる形式に変わった
• アナリストのコンサル的視点から、官僚的計画者の要素が多くなった気がする。

新版ＣＤ「ITストラテジスト小論文突破講座（初版）」は
2008年5月　中旬 リリース開始！
ライバルは既に持っている！
基本的仕様：CD
オプションで午後I,午後IIの添削がつきます。
「提案型システムコンサルタント養成講座」セット販売もあり！

■合格のためのガイドラインと正答率

合格と足切りのガイドラインは正答率60％であると予想します。

■解答速報のトップページに帰る

●目次