応用情報技術者 2018年 春期 午後 問題

共通の文章

マルウェア感染への対応に関する次の記述を読んで,設問1ー4に答えよ。 ]社は,従業員が100名の商社であり,各種工業製品用の部品・材料を取り扱って いる。 ]社のPCは,情報システム課で管理しており,業務に必要なソフトウェアをあら かじめインストールして各部署に配布し,社内LANに接続している。 コンピュータウイルスなどのマルウェアの感染を防ぐために,自社の情報セキュ リティ規程に治って,PCとサーバにウイルス対策ソフトを導入し,最新のウイルス 定義ファイルとセキュリティパッチを自動的に適用している。サーバ上のファイル は,社内LAN上の共有ディスク装置に定期的にバックアップされている。 また,社内LANに接続されたPCからインターネット上のWebサイトを閲覧する ときに,業務上閲覧することが不適切なWedサイトへの接続を制限する| 。| を導入している。 〔モバイルPCの運用 ]社には社内でだけ利用するPCの他に,営業課員が社外での営業活動時に携行す るモバイルPCが用意され,社内では無線LANによって社内LANに自動的に接続で きる。モバイルPCは,利用時以外は所定のキャビネットにおいて施錠管理されてい る。 モバイルPCには,OSと,業務に必要なソフトウェアだけがインストールされて いる。外出先で利用する文書ファイルなどは,モバイルPCの持出し時に営業課員が 社内のファイルサーバからコピーする。また,モバイルPC利用後は,モバイルPC 上にユーザがコピーした又は作成したファイル(以下,ユーザ作成ファイルという) を全て削除してから,所定のキャビネットに返却する。 [モバイルPCのマルウェア感染] ある日,営業課のK君は,取引先での営業活動のために,ファイルサーバから新 製品の提案書をモバイルPCにコピーして外出した。外出中に当該モバイルPC CH 業日報を作成して,その日は帰宅した。翌日出社し,別の取引先を訪問するために 営業情報をファイルサーバからコピーしようと当該モバイルPCを起動したところ, ーー 金銭の支払を要求する警告メッセージが表示された。当該モバイルPC上のファイル を確認すると,新製品の提案書と営業日報のファイル名の拡張子が特定の文字列に 変更されていた。その拡張子を変更前のものに戻してからファイルを開いても,内 容は文字化けして,判読できなかった。 K君は,直ちに上司を通じて,情報システム課のY課長にこの状況を報告した。Y 課長は取り急ぎ,当該モバイルPC本体の無線LAN機能を停止させて社内LANから 切断し,当該モバイルPCにはそれ以上触らずが,そのままにしておくようK君に指 示した。Y課長は,報告を受けた状況から見て|b|型の|c|に感委 した可能性が高いと判断し,部下で情報セキュリティ担当のS主任に状況の確認と 対策の検討を指示した。 (情報セキュリティ担当者による状況の確認 S主任は,K君から当該モバイルPCの直近の利用状況を聞き取った。 S主任:このモバイルEPCの利用状況について教えてください。 K君:昨日,営業で訪問した取引先の会議室において,当社が取扱いを始めた新 製品のプレゼンテーションに利用しました。取引先では,インターネット を含めネットワーク接続をしていません。その時は特に異常はありません でした。取引先を出た時には終業時刻を過ぎていたので,そのまま自宅に 帰るつもりでした。営業日報だけ当日中に作成しようと,途中で最寄り駅 近くの喫茶店に立ち寄って,このモバイルPCを利用しました。喫茶店では 公衆無線LANでインターネットに接続し,営業日報を電子メール(以下, メールという)で上司に送信しました。 SEE:何か他に利用しましたか。 K君:営業日報のメール送信後に,取引先で質問された情報を調べようとWebサ イトを検索していたところ,突然警告メッセージのような画面が表示され HULA.Webサイトを閲覧中に時々表示される詐欺まがいの広告の類いだ ろうと思い,メッセージはよく読まずにすぐWebブラウザを閉じてモバイ ルPCをシャットダウンしました。今日,別の取引先との商談に,引き続き このモバイルPCを利用する予定でしたので,必要なファイルを追加でコピ ーしようとして,今回の事象に遭遇しました。 ーョー S主任はK君への聞き取りから,今回のマルウェアはインターネット上のWebサ イトから,| q|]にょって当該モバイルPCに感染したものと推測した。 一方,S主任は,SA,K君が当該モバイルPCを社内LANに接続した時刻以降, 社内のネットワークから外部への不審な通信が行われていないこと,①社内の他の PCやサーバに感染被害が拡大していないことを確認した。このことから,S主任は, 今回の被害の影響範囲はK君が利用した当該モバイルPCだけに限られると判断し ee また,S主任は,当該モバイルPC上で変更されたファイル名の拡張子の文字列か ら,最近報告されたマルウェアの疑いが強いこと,当該マルウェアは最新のウイル ス定義ファイルで駆除できることを確認した。S主任は,今回の一連の状況及び調査 結果をまとめ,Y課長に報告した。 [モバイルPCのセキュリティ管理上の問題点〕 モバイルPCには,社内のPCと同じウイルス対策ソフトが導入されている。しか し,ウイルス定義ファイルは,社内LAN接続中に手動又は不特定の時刻に自動で更 新される仕様なので,モバイルPCの利用時にウイルス定義ファイルが最新になって いない可能性がある。 ]社の情報セキュリティ規程では,モバイルPCの利用時には,セキュリティパッ チとウイルス定義ファイルを最新のものに更新するよう定めていた。しかし,FH, K君はウイルス定義ファイルが最新になっていることの確認を怠ってしまつった。 その後,JHC,モバイルPCの利用に関する情報セキュリティ規程を遵守させ SEMI,モバイルPCの持出し時の手順にチェックリストによる点検を新たに追加 した。 [マルウェアに感染した場合に備えた対策の検討] Y課長は,S主任からの報告を受け,今回のようなマルウェアがモバイルPCだけ でなく,社内のPCに感染した場合にも備える必要があると感じた。マルウェア感染 の被害を最小限にとどめる対策として,社内のPC上のファイルのバックアップにつ WT,S主任に検討を指示した。 S主任は,PC上のユーザ作成ファイルは当該PCには保存せず,ファイルサーバ ー6一 に保存するよう情報セキュリティ規程を改定し,さらに②あファイルサーバ上のファ イルのバックアップについても,マルウェアに感染した場合に備えた対策を講じる ための検討に着手した。

共通の文章

事業戦略の策定に関する次の記述を読んで,設問1ご3に答えよ。 G社は,郊外及び駅前に,加工食品・生鮮食品を主体としたスーパーマーケットチ ェーンを展開している,中規模の企業である。これまでのターゲット顧客は,郊外 の住宅地にある中規模な店舗の場合は,近隣に居住している主婦であり,住宅地と 商業地とが混在した地域にある駅前の小規模な店舗の場合は,住宅地の主婦と通勤 者である。 G社は,近年,BEB,利益率とも伸び悩んできたことから,昨年,既存の店舗 (以下,実店舗という)の周囲5 km圏内に居住する共働き者・単身者をターゲット 顧客として取り込もうと,インターネット店舗(以下,ネット店舗という)TOR 売を開始した。ネット店舗では,実店舗で扱っている商品を対象に,受注は受付セ ンタで行い,告包と配送の手配は,実店舗で行っている。 今年度,G社の経営企画部では,売上高,利益率を増加するために,実店舗とネッ ト店舗の活性化を柱とする,新たな中期事業戦略を策定することになった。そこで, 経営企画部のH部長は,1課長に対して,G社の内部環境と外部環境を整理した上で, 中期事業戦略案を作成するよう指示した。 [内部環境と外部環境の整理 課長は,内部環境と外部環境を調査し,次のとおり整理した。 (1)内部環境 (i)実店舗の状況 ・営業時間は,8時から19時までである。 ・価格が安く,価格以外にはこだわりがない顧客向けの食品(以下,低付加価 値食品という)の販売が主体であり,店舗の規模を考慮した品ぞろえとなっ ている。 ・価格が高くても購入してもらえる,品質にこだわりがある顧客向けの食品 (以下,高付加価値食品という)は,少量の販売とはいえ,顧客には好評で ある。 ・丁寧な接客と,商品が見つけやすく明るい雰囲気を特徴とする店舗が,スー パーマーケットチェーンのブランドとして定着してきた。 —{0- ・会員制度を運営しており,実店舗で会員登録した顧客には,実店舗用の顧客 IDの入ったポイントカードを発行して,商品購入時に所定のポイントを付与 している。 Gi)ネット店舗の状況 ・販売は,少量にとどまっている。 ・ネット店舗利用のため,インターネットで会員登録した願客には,ネット店 舗用の顧客IDを割り振り,商品購入時に所定のポイントを付与している。 (iii)購入者及びポイント利用の状況 ・郊外の実店舗では,近隣に居住する主婦への売上が80%を占めている。 ・駅前の実店舗では,住宅地の主婦への売上が40%,通勤者への売上が40%を 占めている。 ・ネット店舗では,共働き者への売上が60%,単身者への売上が20%%HOT いる。 ・実店舗とネット店舗のポイントを相互に利用することはできない。 (iv)社内の情報システムの状況 ・顧客情報は,実店舗とネット店舗での共用は行わず,個々の顧客管理システ AC,それぞれの顧客IDを用いて管理し,購入額を集計している。 (2)外部環境 (i)スーパーマーケット市場の状況 ・実店舗のスーパーマーケットの市場規模は.インターネット通販の台頭など の影響で縮小傾向にある。 ・スーパーマーケット業界では,価格競争が激化している。 Gi)顧客の購入状況 ・主婦には,安全性が高い自然食品などの高付加価値食品が人気になっている。 ・通勤者には,価格の高さにもかかわらず,海外から仕入れたブランド物の酒 類などの高付加価値食品の人気が高まっている。 ・仕事帰りの遅い時間帯に,高付加価値食品が購入される傾向が強く見られる。 ・ブランド物の酒類に合う高級なおつまみ類にこだわる顧客が増えている。 ・“高価格だが,それに見合うおいしさ"などといった友人・知人の口コミから 判断して食品を購入し,その感想を自分の友人・知人に知らせることによっ て,人気となる食品が増えている。 =ih= [中期事業戦略の策定] 1課長は,中期事業戦略案を策定するために,クロスSWOT分析による戦略オプシ ョンを表1のように策定した。 表1クロスSWOT分析による戦略オプション = eee|Beam 強み|・|。|]の品ぞろえを充実して,売上を|・商品購入時の心地良い環境を更に整えること aga,|(田上強化戦略(Webi,又は撤退戦略] cy)|「販売機会拡大する。・関連商品による範囲の経済性を活用する。 [積極的な推進戦略][差別化戦略] ・口コミを拡大して,新規願客を開拓する。 1課長は,戦略オプションに基づいて,中期事業戦略案を次のように作成して,H 部長に説明した。| ・実店舗,ネット店舗の特性に応じて,[a|の品ぞろえを充実する。 ・店舗での販売機会を拡大する。 ・情報システムを改善して,コスト低減とマーケティング強化を図る。 ・店舗の心地良い環境を更に整えることによって,| b|を強化する。 ・ソーシャルメディアを活用して,口コミの拡大を進める。 その後,1課長が提案した中期事業戦略案は経営層の承認が得られ,1課長は,中 期事業戦略に基づいて,ターゲットとする顧客の見直しとポジショニングの設定を 行い,事業施策案の作成を進めた。 【ターゲットとする顧客の見直しとポジショニングの設定 1課長は,事業施策案の作成に当たり,店舗の地域特性と規模に応じて,ターゲッ トとする顧客を見直すことにした。郊外の実店舗とネット店舗では,ターゲットと する顧客をこれまでどおりとし,駅前の実店舗は小規模なので,今後注力すべきタ ーゲット顧客を明確にして,ポジショニングを設定することにした。 (1)注力すべきターゲット顧客の明確化 駅前の実店舗では,高付加価値食品の購入が多い通勤者を,注力すべきターゲ ットとする。 =iB,= (2②2)ポジショニングの設定 {課長は,注力すべきターゲットに基づき,食品の付加価値と食品の価格を二つ の軸として駅前の実店舗のポジショニングマップ案を作成し,H部長に説明した。 H BEDS,このポジショニングマップで顧客の|<|を表現することは できるが,二つの軸は| d|ので,食品の付加価値と駅前の実店舗の閉店時 刻を軸にして,ポジショニングマップを修正するようにアドバイスを受けた。そ こで,I課長は,駅前の実店舗のポジショニングマップを図1のとおり作成し,H 部長の了解を得た。 食品の付加価値 iting,|Oca. Ce Cw) =ーーーーx Mion tion mms (3しぇ) en va 図1駅前の実店舗のポジショニングマップ [事業施策の策定〕 ターゲットとする顧客と実店舗のポジショニングが明確となったので,1課長は引 き続き,事業施策案を作成した。事業施策案の抜粋は,次のとおりである。 (1)商品に関する施策 ・郊外の実店舗では,低付加価値食品の品ぞろえを主体としながら,自然食品を 使った手作りの総菜を充実させる。 ・駅前の実店舗では,①顧客がブランド物の酒類を購入する際に,範囲の経済性 の効果をもたらすように,品ぞろえを充実させる。 (2)各店舗での販売チャネルに関する施策 ・実店舗では,来店した顧客に食品の新たな調理方法や効能を丁寧に説明する。 ・駅前の実店舗では,閉店時刻を19時から23時に変更する。 ・ネツット店舗では,料理のレシピ集を掲載する。 (3)情報システムに関する施策 ・実店舗とネット店舗の両店舗を利用し,会員登録している顧客については,本 人の承諾が得られた場合,②両店舗での総購入額に応じたボーナスポイントを ー]き一 プレゼントし,両店舗でのポイントの合算,利用を可能とする。 (44)プロモーション施策 ・実店舗での購買行動のモデルであるAIDMAに加えて,ネット店舗ではインター ネットを活用した新しい購買行動モデルを反映する。具体的には,顧客がソー シャルメディアなどの口コミ情報を|e|して商品を購入し,使用後の感 想などを[|f|することによって,消費行動の迅速な拡大につなげる。 {課長は,これらの事業施策案についてH部長に説明して,承認を得た後,事業 施策の評価基準及びアクションプランを策定することにした。

共通の文章

ナイトの巡歴問題に関する次の記述を読んで,設問13に答えよ。 ナイトの巡歴問題とは,MAN列(以下MXNマスという)の盤面上でチェス の駒の一種であるナイトを移動させ,全てのマスを1回ずつ通過する経路を発見す る問題である。| ナイト(K)が1回で移動できるマス(以下,移動先という)の位置を図1に示す。 また,4X3マスの場合のナイトの巡歴問題の解の一つを図2に示す。図2に示す, ナイトの移動する順序を表す数を,移動順序という。 なお,行番号は上から下,列番号は左から右に増加する。 列 SOOM 123 jo]|||@|1 人 I@||||e 3 ||I@||@||4[20]5|8| 注記マス内の“KRK”はナイトの位置を表す。注記マス内の数はナイトが ①て⑧はナイトの移動先を表す。移動する順序を表す。 図1ナイトが1回で移動できるマスの位置図2 4X3マスの場合の解のーつ MXNマスのナイトの巡歴問題について,行1列1のマスを起点とする全ての経路 を求める処理の概要を示す。この処理は,再帰による深さ優先探索として実現され ている。 〔ナイトの巡歴問題の処理の概要] (1)移動順序1,行1,列1で,再帰関数searchを呼び出す。 再帰関数search(移動順序,行,列) (i)行と列で指定されるマス(以下,現在のマスという)が盤面の範囲外,又 は既に通過したマスであった場合,何もせずに再帰関数searchの呼出し元へ 戻る。 Gi)(i)以外の場合,現在のマスに,移動順序を記録する。 (ii-1)記録した移動順序がMXNに等しい場合,その経路を解の一つとして ー16一 出力する。 Gi-2)Gi-l)以外の場合,現在のマスを起点とした図1の移動先ひて⑧のそれ ぞれについて再帰関数searchを呼び出す。引数の行と列には,移動先を 指定する。移動順序には,現在の移動順育に1を加えたものを指定する。 Gi-3)現在のマスの移動順序を取り消して,マスを通過していない状態に戻 す。 (ii-4)再帰関数searchの呼出し元へ戻る。 (2)終了する。 この処理の概要をプログラムに実装するために,MXNマスの盤面,ナイトの移動 先をそれぞれ次のデータ構造で表現することにした。 ・MXNマスの盤面を2次元配列board[M][N]で表現する。添字は1から始まる。各 要素の初期値は0 LL,ナイトが通過した場合に,移動順序を各要素に格納する。 ・ナイトの各移動先について,FHA,列方向,それぞれの移動量をdy[],dhl]の 配列で表現する。添字は1から始まる。dy[],dh[]はそれぞれ,八つの要素をもち, 1の移動先ゆー⑧に対応する行方向,列方向の移動量を設定する。 dv[],dh[]に設定する値を表1に示す。①の場合、行方向は上に2マス,列方向は 右に1マス移動するので,dyv[1]は-2,dh[1]は1となる。 表1 dv[],dh[]に設定する値 | ー]7一 [ナイトの巡歴問題の解法のプログラムj〕 MXNマスのナイトの巡歴問題について,解法のプログラムを考える。 解法のプログラムで使用する定数,変数及び関数を表2に示す。 表2解法のプログラムで使用する定数,変数及び関数 再帰関数searchのプログラムを図3に,解答を印字する関数printBoardのプログ ラムを図4に,メインプログラムを図5に示す。 なお,左側の番号はプログラムの行番号を示す。 =8= 1:function search(i,v,h) 2:iff vが1以上,かつ,mLAF) 3:if(hが1以上,かつ,n以下)・ 4:if(board[v][h]が9)//通過したマスを判定する。 5s board[v][h]とi//移動順序を記録する。 6:if() i printBoard//解答を印字する。 8:printFlagと1 9:else 10:for(」を1から8まで1ずつ増やす) 11:search([=上|ォ|,|ヵ|)//次の移動先を調べる。 12s endfor 13:endif 14://移動順序を取り消す。 15:endif 16:endif 17:endif 18:endfunction 図3再帰関数searchのプログラム 19:function printBoard() 20:for(vを1からmまで1ずつ増やす) 21:for(hを1からnまで1ずつ増やす) 22:print(board[v][h]) 23:endfor 24:print(改行) 25:endfor 26:endfunction 図4関数printBoardのプログラム 27:function main() 28:mM 29:nをとN 30:board[][]を初期化する 31:printFlagを6 32:search(1,1,1) 33:if(printFlagが9) 34:print(“解答がありません。") 35:endif 36:endfunction 図5メインプログラム =9= [盤面の表現の変更] ナイトの移動先が盤面の範囲外となった場合の判定処理を簡略化するために,図6 のように盤面をナイトが移動できるマスが全て含まれる範囲まで拡大して表現する。 この変更に合わせて①関数printBoardの変更,②メインプログラムの変更,③再 帰関数searchの一部の行の削除を同時に行うことによって,プログラムを短縮する ことができる。. 変更前の盤面変更後の盤面 M=4,N=3の場合M=4,N=3の場合 列列 1|0|0|0|1 。2[0]0)2 31010|0|slililolololilil 4|9|19|0|ぉ4Hlilololelhh slrlrlololoi| elllrlololoュ 注記マス内の数は,盤面を表す配列board[][]に格納される初期値を表す。 網掛け部分は,ナイトが移動できる盤面の範囲外であることを表す。 図6盤面の表現の変更

共通の文章

クラウドサービスに関する次の記述を読んで,設問1ー4に答えよ。 保険代理店であるC社は,同業の小規模な代理店数社を吸収合併することになっ た。現在,C社の業務システムは,販売管理,顧客管理,事務支援,保険計上の四つ のサブシステムから構成されている。各サブシステムは,ベンダに委託して開発し たアプリケーションや市販ソフトウェアを利用しており,その運用については,シ ステム運用を請け負うD社に外部委託している。合併後の業務システムは,C HO 業務システムを継続して使用する前提であるが,D社のクラウドサービスの利用を検 討することになった。システム部のE部長は,部下の課長に,費用の削減を目的 としたクラウドサービスへの移行案を,既存の業務システムの使い勝手や可用性, セキュリティレベルを維持して策定するように指示した。 [クラウドサービス移行案の策定〕 F課長は,D社の営業部長からクラウドサービスの内容について説明を受けた。ク ラウドサービスは,SaaS,PaaS,IaaSの三つのサービス形態があり,それぞれのサ ービス形態に.パブリッククラウドとプライベートクラウドの二つの提供形態があ る。そこで,F課長は既存の業務システムをクラウドサービスに移行する場合,各サ ブシステムに対して,D社のクラウドサービスの最も適切な利用形態(サービス形態 と提供形態の組合せ)を検討し,その結果をクラウドサービス移行案とすることに し。 [クラウドサービスの利用形態の選定手順] F課長は,クラウドサービスの利用形態を選定する手順を図1のように決定した。 ーー 提供形態の概要を表2にまとめる。 サービス形態の概要を表1に,||要を表3にまとめる。るシステム要件を表4にまと める。 Re,表6にまとめる。 まとめる。 図1クラウドサービスの利用形態を選定する手順 —gg一 [D社クラウドサービスの概要)〕 表1と表2は,それぞれ,D社の説明を基にF課長がまとめた,サービス形態の 概要と提供形態の概要である。 表1サービス形態の概要 自社開発アプリケーション 業務システム自社で調達する。 市販ソフトウェア 自社で調達する。 D社が提供する。 自社と接続するためのネットワーク D社が提供する。|プライベートクラウド 他のシステム,サクラウドやではD社が提供する ブシステムとのデ記章のの次が,パブリッククラリウ|利用できない。 ータ連携?ドでは利用できない。 D社クラウドセンタ外自社で調達する。? 注りハードウェアとは,サーバ,ストレージ,ネットワーク回線などのことである。 2データ連携とは,データの受渡しのことである。 3保険会社とのデータ連携のために,C社と保険会社が,D社クラウドセンタに接続するためのネットワーク を調達することを含む。 表2提供形態の概要 ン\リーーBoe 4 他社システムの処理状況の影響を受 —_—D社と利用契約を結んだリソー|リソースは全|SaaS|けない。リソースを同一企業内で使 ws 4スを一つの会社で独占的に利用|て社クラ|PaaS|用しているので,サブシステム間の する方式である。ウドセンタ内|IaaS|分配を自由に設定できる。パブリッ にあり,IE-ククラウドに比べて高価である。 リソースを複数の会社で共有す|VPN,専用線他社システムの処理状況の影響を受 パブリック|る方式である。利用契約分のリ|などで自社と|SaaS|ける。ベストエフォート型のサービ クラウド|ソースの独占的な利用を保証さ|接続する。PaaS|スである。プライベートクラウドに れているわけではない。比べて安価に利用できる。 注記リソースとは,サーバ,ストレージ,ネットワーク回線などのことである。 F課長は,クラウドサービスへの移行費用や5年間の運用費用などを合計してサー ビス形態ごとのC社での費用を試算したところ,IaaSが最も高価で,SaaSが最も安 価になることが分かった。 [クラウドサービスの選定に向けた検討] F課長は,D社の説明を基に,サブシステムごとにクラウドサービスの利用形態を 決定するために,既存の各サブシステムの概要を,表3にまとめた。 なお,D社がSaaSで提供している事務支援ソフトウェアは,C社が事務支援サ ブシステムで利用している市販ソフトウェアと,使い勝手や可用性,セキュリティ レベルがほぼ同じである。 表3各サブシステムの概要 サブ利和上接続システム及び|稼働の eeし|汎用的な販売管理機能を有する市|・保険計上 支店ごと,担当者ごと|、- 販売管理|に保険の契約状況を縮」っトゥェアを利用している。|ETE有 理する。 ベンダに委託して開発したアプリ pn Fa ae 既存顧客及び見込顧客|ケーションとD社が提供してい ME|ems 3,るOS以外のOSを利用していAe EE a Be 事務支援|生理,給与などの一般|。千本る市販ソフトウェアを利用|なしfe sym ee ters vgn gy|汎用的な経理機能と給与管理機能 事務作業を行う。 している。 ーーx|保険会社とのデータ連失機能を信|・保会社のシス 客から申込みを愛 保険計上mere ag[Orペンダに委託して開発したア|テム有 るプリケーションを利用している。|・販売管理 注!月間や,四半期,半期でのデータ量や利用頻度,システム負荷のゾークの時間帯の変動の有無 次にF課長は,各サブシステムに求められるシステム要件を表4にまとめた。 表4システム要件 pe他のシステム,サブシステムとの間で,データの受渡しをする機能が必要で データ連携ある 稼働の変動への対応|ay軽減やンステム負荷のゲークを考慮した対応が必要である。 変りルい 扱うデータ量や利用頻度などに変動があるシステムで,他サブシステムへの 共通の業務への対応|一般的な業務は,市販ソフトウェアを利用する必要がある。 ベンダに委託して開発したアプリケーションや,市販ソフトウェアをカスタ 独自の業務への対応|。。したものを利用する必要がある。 F課長は,表3と表4を照らし合わせ,各サブシステムとシステム要件の対応を表 5にまとめた。 表5各サブシステムとシステム要件の対応 草間voli es稼働の変動|共通の業務|独自の業務 |meme|O|のO|o|x| [wena|o|<|*x|o| wee|x|x|o|x| 注記〇はシステム要件に該当することを,Xはシステム要件に該当しないことを表す。 [クラウドサービスの利用形態の選定] F課長は図1に基づき,クラウドサービスの利用形態をサブシステムごとに選定し た。サブシステムごとの利用形態を次に示す。 ・事務支援サブシステムについては,D社提供の市販ソフトウェアに置き換えること ができるので,他の利用形態よりもコストが安いSaaSのパブリッククラウドを選 定する。 ・保険計上サブシステムは,保険会社とのデータ連携機能を含め,ベンダに委託し て開発したアプリケーションを利用している。D社クラウドセンタ外の保険会社の システムとのデータ連携をシステム要件とすることから,IaaSのプライベートク ラウドを選定する。 表6は,F課長がクラウドサービスの利用形態を選定した結果である。 表6クラウドサービスの利用形態を選定した結果 [仕様の変更 F課長がサブシステムごとにクラウドサービスの利用形態を選定した後に,合併後 の営業社員の給与制度を業績連動型に変更することになった。そのため,販売管理 サブシステムで管理されている営業社員の契約状況を利用して給与を計算するとい うシステム仕様の変更が必要となり,F課長は,D社が提供している市販ソフトウェ アをカスタマイズして使用することにした。 F課長は,給与計算の仕様を変更したクラウドサービスの利用形態の選定結果を, E部長に提出した。ここで,複数の利用形態が選択可能であったので,費用が安価な 利用形態を選択した。

共通の文章

Webシステムの構成変更に関する次の記述を読んで,設問1ユーこ3に答えよ。 A社は,従業員が300名の情報機器卸売会社であり,250社の販売会社と販売代理 店契約を結んでいる。A社では,DMZに設置したWebサーバで代理店向けのWebサ イトを運営している。Webサイトでは,商品情報の閲覧,見積書作成,問合せ対応 などを行う代理店支援システムを稼働させている。インターネット接続には,ISPの B社のサービスを利用している。4社の現在のネットワーク構成を図1に示す。 くに>PR !! |200.a.8 1 200.a.6.2 |HLAN|r2W:レイヤ2スイッチ 注記200.e.8.1及び200.a.8.2は,グローバルIPアドレスを表す。 図1 A社の現在のネットワーク構成(抜粋) Webサイトは開設から3年が経過し,アクセス数が初年度の5倍に増加した。Web サイトの利用拡大に伴い,システム停止が商品販売に大きな影響を及ぼすようにな った。そこで,ARC,Webシステムの処理能力,可用性及びセキュリティを高め る目的で,Webシステムの構成変更を行うことを決めた。 情報システム部のM課長は,まず,Webシステムの処理能力と可用性の向上策の 立案を,部下のN主任に指示した。 (Webシステムの処理能力と可用性の向上策の検討] |N主任は,Webサーバ及びDNSサーバそれぞれの処理能力と可用性を向上させる |冗長化構成を検討した。 |Webサーバの冗長化には,Webサーバを2台構成にし,DNSの機能であるDNS [a|]にょって負荷分淫する方式があるが,可用性向上策としては十分でない。 そこで,負荷分散装置を利用してWebサーバを冗長化することにした。人負荷分散装 置自体は。アクティブノスタンバイ方式で冗長化する。 == A社のドメイン(example.co.jp)の情報(以下,ゾーン情報という)を管理する DNSサーバの冗長化は,B社が提供するDNSサービスを利用して実現する。A社の DNSサーバ(ns.example.co.jp)をマスタDNSサーバにし,B社のDNSサーバ(以 下,B社DNSサーバという)(ns-asha.example1.ne.jp)をスレーブDNSサーバにす る場合,A社又はB社が実施する作業を次に示す。 ・A社のドメインを管理するDNSサーバとして,B社DNSサーバのFQDNと | b|を,jpドメイン名の登録管理事業者に登録申請する。 ・A社のDNSサーバのゾーン情報にNSレコードを追加して,スレーブDNSサーバ のFQDNを設定する。 ・ゾーン情報の設定・変更作業を一度で済ませるために,A社のDNSサーバのゾー ン情報を,|c|DNSサーバへ転送させるのに必要な情報を設定する。 (Webシステム変更後の構成] N主任が考えた,Webシステム変更後の構成を図2に,そのときの,マスタDNS サーバのゾーン情報の内容を図3に示す。 GERD :2=Br ns-asha.examplelnejp スレーブプ|. |a| rーーーーーーコーーニーニーーー-注記1 IPアドレスは,全てグローバルIPアドレスを表す。 !社内LAN!注記2 IPアドレス200.e.8.4は,負荷分散装置設定する仮想IPアドレスを示す。 図2 Webシステム変更後の構成 ー29— 1 lexample IN NS ns.example.co.jp. _3 ns IN A|。| 4|w3 IN A 注記外側の太線の枠内に,ゾーン情報を示す。 図3マスタDNSサーバのゾーン情報の内容(抜粋) N主任が検討結果をM課長に報告したときの,2人の会話の一部を次に示す。 N主任Webシステムを図2の構成に変更します。Webシステム変更後のマスタ DNSサーバのゾーン情報の内容は,図3のとおりになります。図3の設定 によって,Webサイトの利用者は,使有中のURLを変更せずに済みます。 MERE:分かった。この構成なら処理能力と可用性を高めることができるだろう。 ところで,Webシステムのセキュリティを高めるために,WAF(Web Application Firewall)の導入も必要ではないかと考えているが,当社の体制 ではWAFの運用は難しそうなので困っている。良い方法はないだろうか。 N主任:クラウド型WAFサービスが利用できるか調べてみます。 [クラウド型WAFサービスの利用]〕 N主任の調査の結果,B社が提供するクラウド型WAFサービスが利用可能なこと が分かった。その際の利用者のWebサイトへのアクセス手順は,次のとおりになる。 ・A社のWebサイトの利用者は,始めにWAFサービスのFQDNであるwat- asha.examplel.ne.jpにアクセスする。 ・WAFサービスで通信パケットが検査される。 ・パケットに問題がなかいとき,そのパケットがA社のWebサイトに転送される。 B社のWAFサービスを利用する場合,次の対応も必要になる。 ・利用者にWAFサービスの存在を意識させることなくWAFサービスを利用するた めに,①図3中の4行目の後に,Webサイトのホスト名w3の別名を定義むせするレコ ー30一 ードを追加する。さらに,WAFサービスが,検査後のパケットをAO Webサイ トに転送できるようにするために,OM 3中の転送先を示す資源レコードを変更 する。図3中に追加設定する資源レコードを図4に示す。 図4図3中に追加設定する資源レコード ・③WAFサービスを経由せず,直接Webサイトにアクセスされるのを防止するため のアクセス制御を,A社のFWに設定する。 N主任が調査結果をM課長に報告したときの,2人の会話の一部を次に示す。 N主任:B社のWAFサービスを利用すれば,運用の問題は発生しません。図3の 変更,図4の追加設定などによって,WAFサービスが利用できます。 M課長:それは良いな。それでは,N主任の検討結果を基に,Webシステムの構成 変更を行うことにしよう。

共通の文章

備品購買システムの設計と実装に関する次の記述を読んで,設問1ー4に答えよ。 R社は,ソフトウェアパッケージの開発及び販売を行う中堅企業である。これまで 備品の購買は,総務部が表計算ソフトを用いて管理し,行っていた。このたび,見 積依頼や発注,納品された備品の確認などを円滑に行うために,備品購買システム を構築することになった。 備品購買の処理の流れとシステム化対象を表1に示す。 表1備品購買の処理の流れとシステム化対象 PP 総務部が依頼された調達の内容を確認し,在庫がない場合は取引先に見積り べ,数量及び希望回答日と一緒に入力する。 [fas[EerReadteafeaniltkoen, ーー|その際,見積有効期限や価格情報などを入力する。 =その際,発注する商品の数量や希望納品日を入力する。 ーー 5|納品その際,届いた商品の数量などを入力する。取引先の在庫状況によっては, 複数回に分けて商品が届くことがある。 ||Ce| EN ne 注記処理名の下線。はシステム化対象を示す。 この処理の流れから検討した,備品購買システムのデータベースのER図を図1 に示す。 このデータベースでは,E-R図のエンティティ名を表名にし,属性名を列名にして, 適切ながデータ型で表定義した関係データベースによって,データを管理する。 =%= 取引先番号netaーー|»発注番号 見積依頼番号見積番号ーー検収番号 取引先担当者取引先番号AES検収者 ABUL ABI Halas(POLE 見積依頼者見積有効期限ae peeled at 納品番号 発注番号 Wales 見積依頼番号見積番号発注番号納品日時 見積依頼明細番号||見策明細番号発注明細番号納品対応者 商品番号商品番号商品番号 商品名商品名商品名 i ri 3= 商品単価発注単価Maes 納品明細番号 凡例注記属性名の実線の下線___は商品番号 oie,PE,tort|ee 属性名部キーを示す。納品数量 ーー:18S|属性名キキーの実線が付いている属性= <—>:多対多|属性名名には,外部キーの破線を付け 1ない。 図1備品購買システムのデータベースのE-R図(抜粋) 〔相見積り機能の検討] 備品購買システムに相見積り機能を追加することを検討する。相見積り機能とは, 複数の取引先へ同じ内容の見積依頼を出す機能である。これによって,より安い価 格を提示した取引先へ発注を行うことができるようになる。見積依頼を一度に複数 の取引先へ出すために,見積依頼エンティティを二つのエンティティに分けること を考える。 ーつ目のエンティティは,複数の取引先への見積依頼を束ねるエンティティとし て,主キーに見積依頼番号,属性に見積依頼日と見積依頼者|。|]をもたせ る。 ーニつ目のエンティティは,各取引先への見積依頼を管理するエンティティとして, 主キーに|』|と|e ],属性に取引先担当者をもたせる。 この変更に伴い,|f|エンティティにも変更を加えることで,この機能を 実装することができた。 〔検収機能の作成 検収のために,発注した各商品の数量と納品された数量を,商品番号の昇順に一 覧表示するSQL文を図2に示す。ここで,『“:発注番号"は,指定された発注番号を 格納する埋込み変数である。 なお,関数COALESCE(A,B)は,AがNULLでないときはAを,AがNULLのと きはBを返す。 SELECT 0RD.発注番号,0RD.商品番号,0RD.商品名,ORD.HERS, COALESCE([~ g ]9 FROM (SELECT 0D.発注番号,0T.商品番号,OT.商品名,0T.発注数量 FROM発注OD INNER JOIN発注明細OT ON OD.発注番号=OT.発注番号 )ORD LEFT OUTER JOIN (SELECT DE.発注番号,DD.商品番号,SUM(DD.納品数量)AS納品数量計 FROM納品DE INNER JOIN納品明細DD ON DE.納品番号=DD.納品番号 WHERE DE.発注番号=:発注番号 )DLI ON ORD.発注番号=DLI.発注番号 AND ORD.商品番号=DLI.商品番号 図2一覧表示する3SQL文 【返品対応〕 備品購買システムが完成し,運用が開始されてから数か月後,総務部から問合せ があった。取引先から納品された商品を登録した後,利用部門から商品の一部に問 題があったので返品したが,その際の情報を記録したい,とのことであっつた。 納品登録したレコード中の納品数量から返品した数を減らす方法をまず考えたが, その方法では,納品された商品数量や返品したという事実を記録することができな い。そこで,データベースの定義や納品登録した際のレコードには変更を加えずに., ①納唱表と納品明細表にそれぞれ新しいレコードを追加することで,返品に関する 情報を記録することができた。

共通の文章

プログラムの品質評価に関する次の記述を読んで,設問1ー3に答えよ。 Z社では,全国に店舗展開する家電量販店向けに,顧客管理システムを開発してい る。開発中の顧客管理システムは,運用開始後,家電量販店の業務内容の変化に合 わせて,3か月おきを目安に継続的に改修していくことが想定されている。 Z社では,プログラムの品質を定量的に評価するために,メトリクスを計測し,活 用している。プログラムを関数の単位で評価する際には,関数の長さとサイクロマ ティック複雑度をメトリクスとして計測し,評価する。開発プロセスにおいては, プログラムのテストを開始する前にメトリクスを計測し,評価された値が.あらか じめ設定されたしきい値を上回らないことを確認することにしている。 開発中の顧客管理システムについても,開発プロセスのルールに従い,この評価 方法によって評価した。 [サイクロマティック複雑度] サイクロマティック複雑度とは,プログラムの複雑度を示す指標である。プログ ラムの制御構造を有向グラフで表したときの,グラフ中のノードの数Nとリンク (辺)ORLを用いて次の式で算出する。 サイクロマティック複雑度だ=ニエーN十2 プログラムの制御構造を有向グラフで表した例を図1に示す。プログラムの開始 位置と終了位置,反復や条件分岐が開始する位置と終了する位置をノードとし,ノ ード間をつなぐ順次処理の部分をリンクとしてグラフにする。ノードの間に含まれ る順次処理のプログラムの行数は考慮せず,一つのリンクとして記述する。また, 1のリンク1やリンク4のように,処理がない場合もーーつのリンクとして記述す る。 I ー40一 function sample()…Po ROD …リンク1 ean 2}®でロリシタクーー if(条件1)…ノード②@Api [処理1 J er Uwe 1@):ノード [処理3]on YOR(3③/注記n,6は,それぞれノードと [処理4 jリンクの番号を示す。 endif…ノード③(の …リンク4 endfunction…ノード④ 図1プログラムの制御構造を有向グラフで表した例 図1の場合,。ノードの数Nは4,リンクの数しは4となり,Cは|。|と評 価される。 ソフトウェアの内部構造及び内部仕様に基づいたテストを| b|とぃぅ。z2 社では,|b|を実施するに当たって,全ての条件分岐の箇所で,個々の判定 条件の真及び偽の組合せを満たすことを基準としたテストを実施する方針としてい る。このような方針を|c JES.一般に,サイクロマティック和複雑度は小 さい方が,実行網羅率100%を目指すために必要なテストケース数が少なくなり,+ スト工程の作業が容易になる。Z社では,サイクロマティック複雑度のしきい値を 10に設定している。 【評価対象のプログラム〕 開発中の顧客管理システムにおいて,顧客から問合せを受け付けた際に記録する 情報には,タイトル,概要,発生店舗,詳細情報及び顧客の個人情報が含まれてお り,これらの情報をまとめたものを案件と呼ぶ。案件には,未完了と完了のステー タスがある。画面に案件の情報を表示する際には,案件のステータスとシステムの 利用者の立場によって,情報の公開範囲と編集可否の権限を制御する必要がある。 2は,画面上に案件の一覧を表示する際の権限判定を行うプログラムの一部で ある。システムの利用者の役職や所属する店舗と,それぞれの案件のステータスか ら,画面上に表示する情報の公開範囲と編集可否についての権限を判定する。 図2のプログラムについて,メトリクスの計測を行った。計測結果を表1に示す。 BSE,サイクロマティック複雑度の計測のために作成した有向グラフの記載は省 略する。 ーー 1:function get permission() 2:for(案件の数だけ繰り返し) 3:権限<—詳細情報,個人情報を参照不可 4:if(案件のステータスが完了でない) 5:if(案件の店舗に所属している) 6:権限<詳細情報だけを参照可能 7 if(管理職である) 8:if(案件の登録者である) 9:権限<詳細情報,個人情報を参照・編集可能 10:else 11:権限詳細情報だけを参照・編集可能 123 if(店長である) 13:権限詳細情報,個人情報を参照・編集可能(A) 14:endif 15:endif 16:else 17:if(案件の登録者である) 18:権限<詳細情報,個人情報を参照・編集可能 19:endif 20:endif 21s endif 22:else 23:if(公開フラグが立っている) 24:権限<詳細情報だけを参照可能 25:endif 26:endif ai:if(システム管理者である) 29:if(案件のステータスが完了である)か 28:権限で詳細情報,個人情報の参照・編集が可能 30:権限<—詳細情報,個人情報を参照可能 313 endif 32;endif 33:案件の表示・操作権限で権限 34:endfor 35:endfunction 図2権限判定を行うプログラム(一部) 表1計測結果 注記関数の長さには,関数の開始と終了の行は含まない。 |表1の計測結果から,2のプログラムはサイクロマティック複雑度がしきい値 を上回っており,テスト実施のコストが大きくなることが予想される。そこで,プ ログラムの外部的振る舞いを保っつたままプログラムの理解や修正が簡単になるよう に内部構造を改善する|q|を行うことにした。改善する一つの方法として, 2のプログラム中(A)の範囲を“未完了案件権限判定",(B)の範囲を“管理者 権限判定”という名称で関数化することを検討した。改善後のプログラムを図3に, 改善後のプログラムの有向グラフを図4に示す。 function get_permission() for(案件の数だけ繰り返し)()凡例 権限で詳細情報,個人情報を参照不可O:ノード if(案件のステータスが究了でない)の—&1 Bios 権限未完了案件権限判定()C) else if(公開フラグが立っている) 権限<詳細情報だけを参照可能 endif endifの if(システム管理者である)() endif『1 権限<管理者権限判定()Stes 案件の表示・操作権限<権限 endfor C)注記ノードとリンク endfunction 6の番号は省略す る。 図3改善後のプログラム図4改善後のプログラムの有了向グラフ 3のプログラムのサイクロマティック複雑度は|f|であった。また,関 数“未完了案件権限判定”については6,“管理者権限判定"については2となった。 その結果,全てのプログラムのサイクロマティック複雑度がしきい値を上回らない ことが確認された。 [改善の効果 簡潔なプログラムにすることによって,プログラムの可読性が高まり,初期開発 時の機能実装のミスを減少させることができる。また,プログラムのリリース後に 発生する改修や修正の難易度を下げることができる。そうすることによって,ソフ トウェアの品質モデルのうち,機能適合性及びを高めることができる。 Z社で開発している顧客管理システムのような場合,〇①リリース後の改修や修正の 難易度を下げることが,初期開発が容易になることよりも重要であることが多い。

共通の文章

問9 ERPソフトウェアパッケージ導入プロジェクトに関する次の記述を読んで,設問1 と4に答えよ。 O社は,ホームセンタをチェーン展開する中堅企業である。O社では,“良質の商 品を低価格で販売する”という経営方針の下で売上を伸ばし,事業規模を拡大して Xk,社の店舗業務管理システムはこれまで,店舗ごとの販売管理手法と売れ筋商 品に合わせて改修してきたので,店舗の業務の標準化が進まず,業務の効率向上が 重要な課題しなっている。O社では,この課題に対応するためのプロジェクト(以下, 本プロジェクトという)を立ち上げることにした。 [本プロジェクトの概要】 (1)ERPソフトウェアパッケージの導入 ・小売業界で広く採用されているPHO ERPソフトウェアパッケージ(以下,パ ッケージという)を導入する。その理由は,スクラッチ開発よりも低コストで の導入が可能であり,かつ,パッケージに合わせて全店舗の業務を標準化する ことによって,業務効率を上げることができるとO社の経営層が判断したから である。 ・パッケージの導入対象業務は,店舗に関わる販売管理(需要予測を含む),在庫 管理,購買管理,会計管理及び要員管理である。 ・特に,販売管理業務は,各店舗での独自の販売管理手法によって,売上拡大に 大きく寄与している重要な業務である。 (2)本プロジェクトの立上げ ・本プロジェクト全体の予算は8,000 FAT,期間は6か月間である。経営層から, 6か月後の稼働が必須との指示が出ており,予算もスケジュールも余裕がない プロジェクトとなっている。 ・プロジェクトマネージャ(PM)には,OF IT部門のW氏が任命された。 ・特に,リスクマネジメントを重視し,計画・管理・対応策について検討する。 |(〔リスクマネジメント計画 (1)リスクマネジメントの現状 ー46一 | O社にとっては,今回のような全社にわたるパッケージ導入プロジェクトは初め ての経験であるが,従来どおりIT部門が主導的な立場で推進することになった。 以前のプロジェクトでは,リスクマネジメントが十分に機能しておらず,様々な リスクが顕在化していた。例えば,業務部門から重要案件として提示された案件 の中に,実際には重要度がそれほど高くない案件が含まれている場合もあった。 そのような場合でも,案件の採耕決定のベースとなる重要度を評価するための社 内基準がないので,IT部門での重要度の判断も属人的となり,多くは見直されな かった。また,業務部門と重要度を調整する場を設けなかったので,結果として 重要度にかかわらず全ての案件を受け入れざるを得なくなるというリスクが顕在 化し,プロジェクトの全体予算を超過したことがあった。 (2)リスクの特定方法 W氏は,本プロジェクトにおいてリスクマネジメントをしっかり行うために, まずプロジェクト予算超過のリスクを次の方法で特定し,リスクマネジメント計 画書に記載した。 ・本プロジェクトのプロジェクト企画書,現行システムの仕様書から,予測され るリスクを抽出する。 ・IT部門でリスクに関するブレーンストーミングを行い,リスクを洗い出す。 ・①TT部門のPM経験者に対して,過去に担当したプロジェクトの経験から,今 後発生が予測されるリスクに関してアンケートを行い,その結果を回答者にフ ィードバックする。これを数回繰り返してリスクを集約し,リスク源を特定す る。 次に,W氏は,この方法では特定できない未知のリスクが発生した場合の対策 LUT,本プロジェクト全体の予算の5%を,| 。』|]として上乗せすすること を,経営層に報告し,承認を得た。 [リスクの管理]. W氏は,特定したリスク源を,リスク管理表にまとめた。表1は,その抜粋であ る。表1中の“カスタマイズ”Lid,O社の要求で機能を変更・追加したモジュール をパッケージに組み込むことをいう。 ー47一 表1 W氏が作成したリスク管理表(抜粋) IT部門に,業務に精通した要員が不足し 案件の取りまとめが不十分で,案件が確| 定しない。 +|ている。重要度がそれほど高くない案件でも,全 て受け入れてしまい,プロジェクトの予 算を超過する。 フィット&ギャップ分析の結果,ギャッ|多くのギャップに対応するので,カスタ プの数が想定以上に多くなる。マイズの費用が増える。 4 3 a _必要以上に業務部門から業務仕様・シス ae MORE ZOSA|テム仕様の変更を受け入れてしまい,プ|50 ロジェクトの予算を超過する。 パッケージ導入の意図・目的が,IT部門|過剰なカスタマイズ要求カスタマイ から業務部門に周知徹底されていない。|ズの費用が増える。 。|バッケージ導入に精通した要員が不足し|工数が見積りよりも増加し,プロジェク ている。 .トの予算を超骨する。 [リスク対応策〕 W氏は,特定したリスク源への対応策を検討して一覧にまとめ,経営層の承認を 得た。表2は,その抜粋である。ここで,“No.”は表1の“No.”に対応する。 表2リスク対応策一覧(抜粋) ・案件の取りまとめに当たっては,OO IT部門よりも業務に精通している社に支援してもらう。 、|部門が案件採吾のベースとして,案件の|ob|を定める。 .業務部門から提示された案件について,BEE,コスト及びスケジュールを勘案した上で,KHOR 否を決定する。その最終決定権はIT部門がもつこととし,決定事項について経営層の承認を得る。 ・重要な業務でカスタマイズが必要になった場合で,プロジェクト予算を超過する際は,稼働後1 ED, wok内にカスタマイズ費用を回収できることを条件に検討する。 ・②カスタマイズの対象業務を販売管理業務に限定し,その他の業務については,パッケージに合わせ て業務を標準化することをプロジェクト基本計画書に記載し,経営層の承認を得る。 ・仕様変更のプロセスを定め,業務部門から提示された仕様変更の表求・依頼を管理する。 | [カスタマイズの方針〕 W氏は,投入可能なカスタマイズ費用の上限を見積もることにした。稼働してか ら1年間の景気動向予測では,好景気の確率が70%,不景気の確率が30%であり, カスタマイズの有無によって月間利益増加見込額が,表3のように変動することが 予想されている。 なお,表3の月間利益増加見込額は,現行システムを継続利用する場合を基準と している。パッケージを導入した場合,カスタマイズをしなくても業務の効率向上 によって,利益の増加が見込めるが,各店舗独自の販売管理手法を全て実現すると いうカスタマイズをした場合,更に利益の増加が見込める。 表3カスタマイズの有無による月間利益増加見込額 単位万円 W氏は,販売管理機能のカスタマイズをする場合としない場合について,表3を 基に月間利益増加額の期待値を算出した。その結果,投入可能なカスタマイズ費用 を,| dq ]万円と見積もった。さらに,③カスタマイズをする場合の,BAM 下以外のリスクについても検討した。 〔リスクの監視・コントロール〕 本プロジェクトが開始され,現在,IT部門で案件の取りまとめを行っているとこ ろである。この段階で,一部の業務部門から,“IT部門が基準に従って評価した重要 度を案件の採否決定前に業務部門で確認できないので,本当に必要な案件が受け入 れられなくなるのではないか"という不安の声が寄せられた。W氏は,これを二次 リスクと認識し,④リスク対応策の内容を変更することにした。 ー49—

共通の文章

問11システム更改プロジェクトの監査に関する次の記述を読んで,設問1ー5に答えよ。 貸金業者のV社は,主要システムの一つである債権管理システムの稼働を7年前 に開始し,これまで改修を重ねて,債権管理業務の変更に対応してきた。しかし,業 務要件の多様化が進み,業務要件間の整合性を確保することが困難になってきた。そ こで,Y社の経営陣はシステム更改が必要と判断し,現在,債権管理システムの更改 プロジェクト(以下,本プロジェクトという)を推進している。 V社の内部監査部長は,年度監査計画に基づき,システム監査チームに対して本プ ロジェクトの要件定義の適切性について監査を実施するよう指示した。 [予備調査] システム監査チームは,X年6月上旬に予備調査を行い,本プロジェクトの概要を 次のとおり把握した。 Q)システム更改スケジュールの概要は,図1のとおりである。 Cr 要件定義設計開発テスト移行準備 図1システム更改スケジュールの概要 (2②)本プロジェクトの重要事項を決定する会議体であるプロジェクト運営委員会(以 下,運営委員会という)は,V社のシステム部担当役員を議長とし,システム部, 債権管理部,法務部の各部長で構成される。運営委員会では,本プロジェクトの重 要課題が記載された課題管理表を確認し,必要に応じて各部などに対応を指示する。 運営委員会の会議内容は,議事録に記録される。 (3)要件定義を行う要件検討会は,運営委員会が指名した各部の部員(以下,要件定 義ペメンバという)で構成される。債権管理部及び法務部の要件定義メンバは,業務 要件の検討結果を業務要件一覧にまとめ,システム部の要件定義メンバは,RHE 件一覧に基づき,システム要件の検討結果をシステム要件一覧にまとめる。業務要 件一覧の一部を表1に,システム要件一覧の一部を表2に示す。 ー58一 表1業務要件一覧(一部) 根拠資料 @|受取証書に,当社の商号・登録番号,契約年月日,受領金額・その|債権管理法令集 利息,受領年月日などを記載する。(法務部) 債務者に対して,法令で定める時間帯(以下,法定時間帯という)|債権管理法令集 に電話発信することを禁止する。(法務部) 債務者に対して,法定時間帯の開始前1時間及び終了後1時間(以|業務マニュアル ③|下,当社規制時間帯という)に電話発信した場合電話の内容と理|(債権管理部) 由を確認するよう,業務管理者に注意を促す。 受取証書:債務の弁済を証明する文書 備考|X年6月1日現在の法定時間帯:21~翌日8時 X年6月1日現在の当社規制時間帯:20こ21時,及び8~9時 表2システム要件一覧(一部) 表1項番①|、受取証書データベースに登録する。 基幹システムから連携された債権データに基づき,受取証書データを編集 ALRBO|場合,エラーメッセージを表示し,発信できないようにする。 パラメタに設定した法定時間帯に,業務担当者が電話発信ボタンを押した @|je|日次の夜間バッチ処理で,パラメタに設定した当社規制時間帯の発信記録 を抽出し,業務管理用端末に要注意発信一覧を表示する。 (4)要件検討会の議事録には,要件定義メンバの出席状況,検討テーマ,質疑応答・ 意見,検討結果などが記載されている。例えば,XX年6月8日に開催された要件検 討会の議事録には,“要件定義書の作成が遅れており,双年6月30日までに運営委 員会で承認されないおそれがある"と記載されていた。また,V社のプロジェクト 管理基準には,要件検討会の開催後に.プロジェクトに参加している各部の管理職 全員が,回覧される議事録を閲覧し,記載事項を確認するよう定められている。 〔本調査〕 システム監査チームは,予備調査の結果を踏まえ,要件定義書承認前のX年6月 中旬に本調査を実施した。 (1)全権管理部及び法務部において,業務要件が適切に確認されているかどうかを, 次のとおり確認した。 ①要件検討会の議事録を閲覧したところ,債権管理部の要件定義メンバP KAS 第2回要件検討会を欠席していることが記録されていた。 @P氏にインタビューしたところ,P Kid,“欠席した第2回要件検討会も含め て,全ての要件検討会の議事録を閲覧し,記載事項を確認している”と回答した。 @また,P氏は,“プロジェクト管理基準に従って,債権管理部の管理職全員が 要件検討会の議事録の記載事項を確認していると認識している"と回答した。 ④P氏の③の回答内容が事実かどうかを確認するために,追加の監査手続を行っ Tes (2)業務要件の根拠が明確かどうかを,次のとおり確認した。 ①業務要件一覧に記載された業務要件をサンプル抽出し,根拠資料の内容と照合 した。しかし,業務要件の一部は根拠資料の内容との関係が不明確であったこと から,業務要件の根拠が明確であることを立証するための十分な|a|を 得られなかった。例えば,表1項番①の業務要件が,債権管理法令集に記載さ れた法令のどの条項に対応するのか,システム監査チームは確認できなかった。 ②業務要件の根拠が明確であることを立証するために,|b Je |c|を説明するよう求めた。 (3)業務要件とシステム要件が整合しているかどうかを,次のとおり確認した。 ①業務要件一覧とシステム要件一覧を照合したところ,業務要件ごとにシステム 要件が定義されていた。 ②業務要件及び対応するシステム要件をサンプル抽出し,関連する要件検討会の 議事録を閲覧するとともに,要件定義メンバにインタビューした。その結果,業 務要件及びシステム要件の具体的な内容についての誰識が,要件定義メンバ間で 合致していないケースがあった。例えば,P氏は,表1項番③の当社規制時間帯 が,前日の20て21時,及び当日の8~9時の間であると考えていた。一方,シ ステム部の要件定義メンバは,KR 2 BOLT,バッチ処理時間帯の制約 があるので,前日の8~9時,及び前日の20-21時の間の発信記録を,要注意 発信一覧として表示しようと考えていた。 ③②の状況が生じた原因を確認した上で,“業務要件とシステム要件を整合させ ることが必要である”ことを指摘した。 ww靖 (4)要件検討会認識された重要課題が,運営委員会で確認されているかどうかを確 認するために| q|,|e|及び[|if]emavux.