応用情報技術者 2022年 秋期 午後 問題

共通の文章

マルウェアへの対応策に関する次の記述を読んで,設問に答えよ。 P社は,従業員数400名のIT関連製品の卸売会社であり,309社の販売代理店をも っている。P社では,販売代理店向けに,インターネット経由で商品情報の提供,見 積書の作成を行う代理店サーバを運用している。また,従業員向けに,代理店ごとの 卸価格や担当者の情報を管理する顧客サーバを運用している。代理店サーバ及び顧客 サーバには,HTTP Over TLSでアクセスする。 P社のネットワークの運用及び情報セキュリティインシデント対応は,情報システ ABB(LAK,システム部という)の運用グループが行っている。 P社のネットワーク構成を図1に示す。 <パパインターネットつDD ae L pS PUM MERRIE eRe !|内部|社内|。||外部1.mL Se]|Gear 1 1=FOE z> !eS !3| ニニーーmN【Lo---------2222----_MZ! |!7 1 1 1ー1 FW:ファイアウォール ||ec fe]Pc ibaa kaa L2SW:レイヤー2スイッチ !ー1 L3SW:レイヤー3スイッチ |内部LMN RAN LUii 注記1配布サーバは,PCにセキュリティパッチなどを配布するサーバである。 注記2検証LAMは,サーバ及びPCの動作検証などを行うためのLANである。 図1 P社のネットワーク構成 [セキュリティ対策の現状〕 P社では,複数のサーバ,PC及びネットワーク機器を運用しており,それらには次 のセキュリティ対策を実施している。 ‘La|では,インターネットとDMZ間及び内部LANとDMZ間で業務に必要な 通信だけを許可し,通信ログ及び遮断ログを取得する。 [|5|でょは,SPF(Sender Policy Framework)機能によって送信元ドメイン 認証を行い,送信元メールアドレスがなりすまされた電子メール(以下,電子メー ルをメールという)を隔離する。 と4 ・外部DNSサーバでは,DMZのゾーン情報の管理のほかに,キャッシュサーバの機能 を稼働させており,外部DNSサーバを①DDoSの踏み台とする攻撃への対策を行う。 ・P社からインターネット上のWebサーバへのアクセスは,DMZのプロキシサーバを 経由し,プロキシサーバでは,通信ログを取得する。 ・PC及びサーバで稼働するマルウェア対策ソフトは,BA,決められた時刻にベン ダーのWebサイトをチェックし,マルウェア定義ファイルが新たに登録されている Balt,ダウンロードして更新する。 ・システム部の担当者は,毎日,ベンダーのWebサイトをチェックし,0Sのセキュ リティパッチやアップデート版の有無を確認する。最新版が更新されている場合は, ダウンロードして検証LANで動作確認を1週間程度行う。動作に問題がなければ, PC向けのものは| c|に登録しサーバ向けのものは,体日に担当者が各サ ーバに対して更新作業を行う。 PCは,電源投入時に|c|にアクセスし,更新が必要な新しい版が登録され ている場合は,ダウンロードして更新処理を行う。 ・FW及びプロキシサーバのログの検査は,担当者が週に1回実施する。 [マルウェアXの調査 HSA,システム部の0課長は,マルウェアXの被害が社外で多発していることを 知り,R主任にマルウェアXの調査を指示した。R主任による調査結果を次に示す。 (1)攻撃者は,不正なマクロを含む文書ファイル(以下,マクロ付き文書ファイル Aという)をメールに添付して送信する。 (2)受信者が,添付されたマクロ付き文書ファイルAを開きマクロを実行させると, マルウェアへの指令や不正アクセスの制御を行うインターネット上のC&Cサーバ |と通信が行われ,マルウェアXの本体がダウンロードされる。 (3)PCに侵入したマルウェアXは,内部ネットワークの探索,ROBE,BEL た情報のC&Cサーバへの送信及び感染拡大を,次の(a)一(d)の手順で試みる。 |(a)②PCが接続するセグメント及び社内の他のセグメントの全てのホストアド |レス宛てに,宛先アドレスを変えながらICMPエコー要求パケットを送信し,連 |続してホストの情報を取得する。 |(b)③(a)によって情報を取得できたホストに対して,攻撃対象のポート番号を ー5一 セットしたTCPのSYNパケットを送信し,応答内容を確認する。 (c)(5)でSYN/ACKの応答があった場合指定したポート番号のサービスの脆到 性を悪用して個人情報や秘密情報などを幻取し,C&Cサーバに送信する。 (d)侵入したPCに保存されている過去にやり取りされたメールを悪用し,当該 PC上でマクロ付き文書ファイルAを添付した返信メールを作成し,このメール を取引先などに送信して感染拡大を試みる。 R主任が調査結果を0課長に報告したときの,2人の会話を次に示す。 Q課長:マルウェアXに対して,現在の対策で十分だろうか。 R主任:十分ではないと考えます。文書ファイルに組み込まれたマクロは,容易に処 理内容が分析できない構造になかっており,マルウェア対策ソフトでは発見 できない場合があります。また,④マルウェアXに感染した社外のPCから 送られてきたメールは,SPF機能ではなりすましが発見できません。 0課長:それでは,マルウェアXに対する有効な対策を考えてくれないか。 REE:分かりました。セキュリティサービス会社のS社に相談してみます。 〔マルウェアXへの対応策] R主任は,現在のセキュリティ対策の内容をS社に説明し,マルウェアXに対する 対応策の提案を求めた。S社から,セキュリティパッチの適用やログの検査が迅速に 行われていないという問題が指摘され,マルウェアX侵入の早期発見,侵入後の活動 の抑止及び被害内容の把握を目的として,EDR(Endpoint Detection and Response) システム(以下,EDRという)の導入を提案された。 S社が提案したEDRの構成と機能概要を次に示す。 ・EDRは,管理サーバ,及びPCに導入するエージェントから構成される。 ・管理サーバは,エージェントの設定,エージェントから受信したログの保存,分析 及び分析結果の可視化などの機能をもつ。 ・エージェントは,次の(i),(ii)の処理を行うことができる。 (i)PCで実行されたコマンド,通信内容,ファイル操作などのイベントのログ を管理サーバに送信する。 (ii)PCのプロセスを監視し,あらかじめ設定した条件に合致した動作が行われ たことを検知した場合に,設定した対応策を実施する。例えば,EDR lt,(a)~ ss Yh (c)に示した⑨マルウェアXの活動を検知した場合に,⑥内部ネットワークの探 素を防ぐなどの緊急措置をPCに対して実施することができる。 R主任は,S社の提案を基に,マルウェアXの侵入時の対応策をまとめ,0課長に EDRの導入を提案した。提案内容は承認され,EDRの導入が決定した。

共通の文章

教育サービス業の新規事業開発に関する次の記述を読んで,設問に答えよ。 B社は,教育サービス業の会社であり,中高生を対象とした教育サービスを提供し .ている。B社では有名講師を抱えており,生徒の能力レベルに合った分かりやすく良 質な教育コンテンツを多数保有している。これまで中高生向けに塾や通信教育などの 事業を伸ばしてきたが,COME,生徒数が減少しており,今後大きな成長の見込み が立たない。また,教育コンテンツはアナログ形式が主であり,Web配信ができるデ ジタル形式のビデオ教材になっているものが少ない。B社の経営企画部長であるC HY 締役は,この状況に危機感を抱き,3年後の新たな成長を目指して,デジタル技術を 活用して事業を改革し,B社のDX(デジタルトランスフォーメーション)を実現する 顧客起点の新規事業を検討することを決めた。C取締役は,事業の戦略立案と計画策 定を行う戦略チームを経営企画部のD課長を長として編成した。 [B社を取り巻く環境と取組〕 D課長は,戦略の立案に当たり,B社を取り巻く外部環境,内部環境を次のとおり 整理した。 ・ここて数年で,法人において,非対面でのオンライン教育に対するニーズや,時代の 流れを見据えて従業員が今後必要とされるスキルや知識を新たに獲得する教育(リ スキリング)のニーズが高まっている。今後も法人従業員向けの教育市場の伸びが 期待できる。 ・最近,法人向けの教育サービス業において,異業種から参入した企業による競合サ ービスが出現し始めていて,価格競争が激化している。 ・教育サービス業における他社の新規事業の成功事例を調査したところ,特定の業界 で他企業に対する影響力が強い企業を最初の顧客として新たなサービスの実績を築 いた後,その業界の他企業に展開するケースが多いことが分かった。 ・B社では,海外の教育関連企業との提携,及びE大学の研究室との共同研究を通じ て,データサイエンス,先進的プログラム言語などに関する教育コンテンツの拡充 や,AIを用いて個人の能力レベルに合わせた教育コンテンツを提供できる教育ツ ールの研究開発に取り組み始めた。この教育ツールは実証を終えた段階である。こ のように,最新の動向の反映が必要な分野に対して,業界に先駆けた教育コンテン ツの整備力が強みであり,新規事業での活用が見込める。 [新規事業の戦略立案」 D課長は,内外の環境の分析を行い,B社の新規事業の戦略を次のとおり立案し,C 取締役の承認を得た。 ・新規事業のミッションは,"未来に向けて挑戦する全ての人に,変革の機会を提供 すること”と設定した。 ・B社は,新規事業領域として,①法人従業員向けの個人の能力レベルに合わせたオ ンライン教育サービスを選定し,SaaSの形態(以下,AE SaaSという)で顧客に 提供する。 ・中高生向けの塾や通信教育などでのノウハウをサービスに取り入れ,法人でのDX 推進に必要なデータサイエンスなどの知識やスキルを習得する需要に対して,Al を用いた個人別の教育コンテンツをネット経由で提供するビジネスモデルを構築す ることを通じて,②B社のDXを実現する。 ・最初に攻略する顧客セグメントは,データサイエンス教育の需要が高まっている大 手製造業とする。顧客企業の人事教育部門は,B社の教育SaaSを利用することで, 社内部門が必要なときに必要な教育コンテンツを提供できるようになる。 ・対象の顧客セグメントに対して,従業員が一定規模以上の企業数を考慮して,販売 目標数を設定する。毎月定額で,提示するカタログの中から好きな教育コンテンツ を選べるサービスを提供することで,競合サービスよりも利用しやすい価格設定と する。 ・Webセミナーやイベントを通じてB社の教育SaaSの認知度を高める。また,法人 向けの販売を強化するために,F社と販売店契約を結ぶ。F社は,大手製造業に対 する人材提供や教育を行う企業であり,大手製造業の顧客を多く抱えている。 z課長は,戦略に基づき新規事業の計画を策定した。 [顧客実証 D課長は,新規事業の戦略の実効性を検証する顧客実証を行うこととして,その方 針を次のように定めた。 == ・教育ニーズが高く,商談中の③G社を最初に攻略する顧客とする。G社は,製造業 の大手企業であり,同業他社への影響力が強い。 ・G社への提案前に,B社の提供するサービスが適合するか確認するために [a|を実施する。|a|にはF社にも参加してもらう。 [ビジネスモデルの策定〕 D課長は,.ビジネスモデルキャンバスの手法を用いて,B社のビジネスモデルを図 1のとおり作成した。なお,新規事業についての要素を“廊”で,既存事業について の要素を無印で記載する。(省略)はほかに要素があることを示す。 KP(主要なパートナー)|KA(主要な活動)VP(価値提案)CR(顧客との関係)|CS(顧客セグメント) ・クラウド環境提供会社|・教育コンテンツの|・支従業員のリスキ|(省略)・中高生 ・翻訳会社作成リングに関する課・文大手製造業 (省略)・KA SaaS提供|題の解決(省略) xT]|ca (省略) KR(主要なリソーCH(チャネル) ス)・直接販売 ・開発済みの教育ツ4 c| ール(省略) ・特許.ノウハウ (省略) C$(コスト構造)R$(収益の流れ) ・人件費・売り切りモデルの販売 +KAA SaaS運営費 ・ソフトウェアツール費レー|ーー ・外注費okモデルの販売 (省略) 図1 B社のビジネスモデル [財務計画〕 D課長は,B社の新規事業に向けた財務計画第1 MERIのとおり作成し,C取締 役に提出した。なお,財務計画作成で,次の前提をおいた。 ・競争優位性を考慮して,教育SaaS開発投資を行う。開発投資は5年で減価償却し, 固定費に含める。 ・競合サービスを考慮して,販売単価は,1社当たり19百万円年とする。 ・利益計算に当たって,損益計算書を用い,キャッシュフローや現在価値計算は用い ない。金利はゼロとする。 ーー12ーー 表1財務計画第1版 単位百万円 Ea a)OC))OT)w 費用50 65 90 125 195 525 変動費5 20 45 80 150 300 固定費45 45 45 45 45 225 En- -交|| s wl RAL a)el D課長は,財務部長と財務計画をレビューし,“既存事業の業績の見通しが厳しい ので新規事業の費用を削減して,4年目に累積損失を9にしてほしい"”との依頼を受 けた。 D課長は,C取締役に財務部長の依頼を報告し,この財務計画は現時点で最も確か な根拠に基づいて設定した計画であること,また新規事業にとっては④4年目に累積 損失を0にするよりも優先すべきことがあるので,財務計画第1版の変更はしないこ とを説明し了承を得た。 その後,D課長は,計画の実行を適切にマネジメントすれば,変動費を抑えて4年 目に累積損失を9にできる可能性はあると考え,この想定で別案として財務計画第2 版を追加作成した。財務計画第2版の変動費率は|es|]%となり,財務計画第 1版と比較して5年目の累積利益は,%増加する。 |ー8一

共通の文章

迷路の探索処理に関する次の記述を読んで,設問に答えよ。 始点と終点を任意の場所に設定するnXmの2次元のマスの並びから成る迷路の解 を求める問題を考える。本問の迷路では次の条件で解を見つける。 ・迷路内には障害物のマスがあり,nXmのマスを囲む外壁のマスがある。障害物と 外壁のマスを通ることはできない。 ・任意のマスから,そのマスに隣接し,通ることのできるマスに移動できる。迷路の 解とは,この移動の繰返しで始点から終点にたどり着くまでのマスの並びである。 ただし,迷路の解では同じマスを2回以上通ることはできない。 ・始点と終点は異なるマスに設定されている。 5xX5の迷路の例を示す。解がーつの迷路の例を図1に,解が複数(四つ)ある迷路 の例を図2に示す。 2 y N|||lea 5|||除虹 NN||||に‘N||||に 5||||団NN|||| N||||N N||||N ‘Nea|||N Nee!|||AK やや2も3われもも=e 注記NNは外本円は了守物を表す。 図1解がーつの迷路の例図2解が複数ある迷路の例 〔迷路の解を見つける探索] 迷路の解を全て見つける探索の方法を次のように考える。 迷路と外壁の各マスの位置をx座標とy座標で表し,各マスについてそのマスに関 する情報(以下,マス情報という)を考える。与えられた迷路に対して,障害物と外 壁のマス情報にはNGフラグを,それ以外のマス情報にはOKフラグをそれぞれ設定す る。マス情報全体を迷路図情報という。 探索する際の"移動"には,“進む"と“RS”の二つの動作がある。“進む”は, ー16一 現在いるマスから①y座標を1増やす,©x座標を1増やす,③y座標を1減らす, ④x座標を1減らす,のいずれかの方向に動くことである。マスに“HO”と同時に そのマスのマス情報に足跡フラグを入れる。足跡フラグが入ったマスには“ED”こ とはできない。“戻る”は,今いるマスからSEAT”きた一つ前のマスに動くこと CHS,VAK"移動”したとき,移動先のマスを“訪問したという。 探索は。始点のマスのマス情報に足跡フラグを入れ,始点のマスを“訪問したマ スとして,始点のマスから開始する。現在いるマスから次のマスに“進む”試みを① ー④の順に行い,もし試みた方向のマスに“HD”ことができないならば,次の方向 に“進む”ことを試みる。4方向いずれにも“進む”ことができないときには,現在 いるマスのマス情報をOKフラグに戻し,一つ前のマスに“RS”.これを終点に到達 するまで繰り返す。終点に到達したとき,始点から終点までSED”ことでたどって きたマスの並びが迷路の解のーつとなる。 迷路の解を見つけた後も,他の解を見つけるために,終点から一つ前のマスに“R り”,迷路の探索を続け,全ての探索を行ったら終了する。迷路を探索している間, それまでの経過をスタックに格納しておく。終点にたどり着いた時点でスタックの内 容を順番にたどると,それが解のーつになる。 1の迷路では,始点から始めて,(1L1)っ(12)っ(1.3)っ(1.4)つ(1.5)っ(2,5)つ (1.5)っ(1,4)のように“移動”する。ここまででマスの“移動"は7回起きていて, このときスタックには経過を示す4個の座標が格納されている。さらに探索を続けて, 始めから13回目の“BE”が終了した時点では,スタックには|ア|個の座標 が格納されている。 [迷路の解を全て求めて表示するプログラム]〕 迷路の解を全て求めて表示するプログラムを考える。プログラム中で使用する主な 変数,定数及び配列を表1に示す。配列の添字は全て0から始まり,要素の初期値は 全て0とする。迷路を探索してマスを"移動"”する関数visitのプログラムを図3に, メインプログラムを図4に示す。メインプログラム中の変数及び配列は大域変数とす Bx Rlプログラム中で使用する主な変数,定数及び配列 oa paths[u][v]配列迷路の全ての解の座標を格納する2次元配列。添字のuは解の function visit(x,y) maze[x][y]てVISITED//足跡フラグを入れる stack visit[stack top]<(x,y)//スタックに座標を入れる if(xがgoal xと等しいかつyがgoal yと等しい)//終点に到達 for(kを9からstack topまで1ずつ増やす) <—stack visit[k] endfor sol_num<—sol num十1 else stack topてstack top十1 if(maze[x][y十1]が0Kと等しい) visit(x,y+1) endif (maze[x十1][y]がOKと等しい) visit(x十1,y) endif if(maze[x][yー1]がOKと等しい) visit(x,yー1) endif if(maze[x一1][y]がOKと等しい) visit(x一1,y) endif stack topで endif =W endfunction 図3関数visitのプログラム —FOE es function main stack topで6 soLnumぐ0 maze[x][y]に迷路図情報を設定する start x,start y,goal x,goal yに始点と終点の座標を設定する visit(start x,start y) if(が9と等しい) "迷路の解は見つからなかった"と印字する else paths[][]を順に全て印字する endif endfunction 図4メインプログラム 〔解が複数ある迷路〕 図2は解が複数ある迷路の例で,一つ目の解が見つかった後に,他の解を見つける ために,迷路の探索を続ける。一つ目の解が見つかった後で,最初に実行される関数 visitの引数の値は|カカ|である。この引数の座標を基点として二つ目の解が 見つかるまでに,マスの“BHは|キ|回起き,その間に座標が(4.2)の マスは|7|回"訪問'される。

共通の文章

コンテナ型仮想化技術に関する次の記述を読んで,設問に答えよ。 C社は,レストランの予約サービスを提供する会社である。C社のレストランの予 約サービスを提供するWebアプリケーションソフトウェア(以下,Webアプリという) lt,20名の開発者が在籍するWebアプリ開発部で開発,保守されている。(社のWeb アプリにアクセスするURL ld,“https://www.example.jp/”CHS. Webアプリには,機能X,機能Y,機能7の三つの機能があり,そのソースコードや コンパイル済みロードモジュールは,開発期間中に頻繁に更新されるので,バージョ ン管理システムを利用してバージョン管理している。また,Webアプリは,外部のベ ンダーが提供するミドルウェアA及びミドルウェアBを利用しており,各ミドルウェ アには開発ベンダーから不定期にアップデートパッチ(以下,パッチという)が提供 される。パッチが提供された場合,C社ではテスト環境で一定期間テストを行った後, 顧客向けにサービスを提供する本番環境のミドルウェアにパッチを適用している。 このため,Webアプリの開発者は,本番環境に適用されるパッチにあわせて,自分 の開発用PCの開発環境のミドルウェアにもパッチを適用する必要がある。開発環境 へのパッチは,0台の開発用PC全てに適用する必要があり,作業工数が掛かる。 そこで,Webアプリ有開発部では,Webアプリの動作に必要なソフトウェアをイメー ジファイルにまとめて配布することができるコンテナ型仮想化技術を用いて,パッチ 適用済みのコンテナイメージを開発者の開発用PCに配布することで,開発環境への ミドルウェアのパッチ適用工数を削減することについて検討を開始した。コンテナ型 仮想化技術を用いた開発環境の構築は,Webアプリ開発部のDさんが担当することに en Coa Webアプリのリリーススケジュール〕 まずDさんは,今後のミドルウェアへのパッチ適用とWebアプリのリリーススケジ ュールを確認した。今後のリリーススケジュールを図1に示す。 ー2一 |の2人[mea|oa|oe[a[ne[ee| age ear|Pe an|ibyaa”’(ovewe|[|Peet favs re eee Tee— Some“eexome[ew[me[rar byl|| 商明WWzogm|[Let[me[rat boone 図1今後のリリーススケジュール C社では,ミドルウェアの公開済みのパッチを計画的に本番環境に適用しており, 本番環境のミドルウェアAのパッチ適用がAPA,ミドルウェアBのパッチ適 用が11月中旬に計画されている。また,10H,11月,及び12月に向けて三つのWeb アプリ開発案件が並行して進められる予定である。開発者は各Webアプリ開発案件の リリーススケジュールを考慮し,リリース時点の本番環境のミドルウェアのバージョ ンと同一のバージョンのミドルウェアを開発環境にインストールして開発作業を行う 必要がある。 なお,二つのミドルウェアでは,パッチ提供の場合にはバージョン番号が9.0.1ず つ上がることがミドルウェアの開発ベンダーから公表されている。また,バージョン 番号を飛ばして本番環境のミドルウェアにパッチを適用することはない。 [コンテナ型仮想化技術の調査〕 次にDさんは,コンテナ型仮想化技術について調査した。コンテナ型仮想化技術は, ーつの0S上に独立したアプリケーションの動作環境を構成する技術であり, |[JP bE RAR MPS eB RAR ATE HEBEL て|< ]が不要となり,CPUやメモリを効率良く利用できる。C社の開発環境で 用いる場合には,Webアプリの開発に必要な指定バージョンのミドルウェアをコンテ ナイメージにまとめ,それを開発者に配布する。 [コンテナイメージの作成] まずDさんは,基本的なライブラリを含むコンテナイメージをインターネット上の 公開リポジトリからダウンロードし,Webアプリの開発に必要な二つのミドルウェア |ーー の指定バージョンをコンテナ内にインストールした。次に,コンテナイメージを作成 し社内リポジトリへ登録して,C社の開発者がダウンロードできるようにした。 なお,Webアプリのソースコードやロードモジュールは,バージョン管理システム を利用してバージョン管理し,①コンテナイメージにWebアプリのソースコードやロ ードモジュールは含めないことにした。Dさんが作成したコンテナイメージの一覧を 表1に示す。 表1 Dさんが作成したコンテナイメージの一覧 [コンテナイメージの利用]〕 Webアプリ有開発部のEさんは,機能Xの変更を行うために,Dさんが作成したコン テナイメージ“img-dev_oct”を社内リポジトリからダウンロードし,開発用PCでコ ンテナを起動させた。Eさんが用いたコンテナの起動コマンドの引数(抜粋)を図2 に示す。 図2 Eさんが用いたコンテナの起動コマンドの引数(抜粋) 図2中の-pオプションは,HALOSの10443番ポートをコンテナの443番ポート にバインドするオプションである。なお,コンテナ内では443番ポートでWeb PTY へのアクセスを待ち受ける。さらに,-vオプションは,RAK OSのディレクトリ "/app/FuncX”を,コンテナ内の“/app”にマウントするオプションである。 EさんがWebアプリのテストを行う場合,開発用PCのホスト0Sで実行されるWeb ブラウザから②テスト用のURLへヘアクセスすることで“img-dev oct”内で実行され ているWebアプリにアクセスできる。また,コンテナ内に作成されたファイル “/app/test/test.txt”は,ホスト0Sの[+jeして作成される。 ー22— 12月1日リリース向け開発案件をリリースした後の12月中旬に,19月1日リリー ス向け開発で変更を加えた機能Xに処理ロジックの誤りが検出された。この誤りを12 月中に修正して本番環境ヘリリースするために,Eさんは③あるコンテナイメージを 開発用PC上で起動させて,機能Xの誤りを修正した。 その後,Dさんはコンテナ型仮想化技術を活用した開発環境の構築を完了させ,A 発者の開発環境へのパッチ適用作業を軽減した。

共通の文章

テレワーク環境への移行に関する次の記述を読んで,設問に答えよ。 W社は,東京に本社があり,全国に2か所の営業所をもつ,社員数209名のホーム ページ制作会社である。W社では本社と各営業所との間をVPNサーバを利用してイン ターネットVPNで接続している。 本社のDMZでは,プロキシサーバ,VPNサーバ及びWebサーバを,本社の内部ネッ トワークではファイル共有サーバ及び認証サーバを運用している。 W社では,一部の社員が,社員のテレワーク環境からインターネットを介して本社 VPNサーバにリモート接続することで,テレワークとWeb会議を試行している。 W社のネットワーク構成を図1に示す。 社員のテレワーク環境 サービス —{Pc] こインターネットの ニーーーーーーーニーーーーーーーー-At,営業所1営業所2 iDMZ||本社H== 1サーバサーバ :1|内部ネットワー21||「|内部ネットワーク (ーーif!| コーーー央叶ットラータ||iff ec]-~[Pc |Last内部ネットワa PC PC PC PC! 1ーーーーーーーーーーーニーーーーーーーーニーーニーーニーーーニーー』} !ファイル9レイヤー3スイッチ ア=ミエオキエーババ!:ーーッ ーーーニーーーニーーーニーニーニーニーニーニニニーニーニニーー-|UTM:統合脅威管理システム 注記Web会議サービスは今後利用を検討しているSaaSである。 図1 W社のネットワーク構成 (W社の各サーバの機能〕 W社の各サーバの機能を次に示す。 ・本社VPNサーバは,各営業所のVPNサーバとの間でインターネットVPN CHAS 接続する。また,社員のテレワーク環境にあるPCにリモートアクセス機能を提供 する。 ・本社,各営業所及び社員のテレワーク環境のPCのWebブラウザからインターネッ ト上のWebサイトへの接続は,本社のプロキシサーバを経由して行われる。プロキ ー26一 シサーバは,インターネット上のWebサイトへのアクセス時のコンテンツフィルタ リングやログの取得を行う。 ・ファイル共有サーバには,社員ごとや組織ごとに保存領域があり,PCにはファイ ルを保存しない運用をしている。 ・認証サーバでは,社員のID,パスワードなどを管理して,PCやファイル共有サー バへのログイン認証を行っている。 現在利用している本社のインターネット接続回線は,契約帯域が100Mビットノ/秒 (上りノ下り)で帯域非保証型である。 [テレワークの拡大〕 W社では,テレワークを拡大することになり,情報システム部のX部長の指示でY さんがテレワーク環境への移行を担当することになった。 Yさんが移行計画を検討したところ,テレワークに必要なPC CAF,リモートPC という),VINサーバ及びリモートアクセスに必要なソフトウェアとそのライセンス の入手は即時可能であるが,本社のインターネット接続回線の帯域増強工事は,2か 月掛かることが分かった。そこでYさんは,ネットワークの帯域増強工事が完了する までの間,ネットワークに流れる通信量を監視しながら移行を進めることにした。 [W社が採用したリモートアクセス方式〕 SEYさんが採用したリモートアクセス方式は,| a。|で暗号化された |5|肖信を用いたインターネットVPN接緒機能によって,社員がリモートPC のWebブラウザからVPNサーバを経由して本社と各営業所の内部ネットワークの『C (以下,内部PCという)を遠隔操作する方式である。ここで,リモートPCからの内 部PCの遠隔操作は,内部PCのOSに標準装備された機能を利用して,ネットワーク 経由で内部PCのデスクトップ画面情報をリモートPCが受け取って表示し,リモート PCから内部PCのデスクトップ操作を行うことで実現する。 aこの方式では,リモートPCから内部PCを直接操作することになるので,従来の社 内作業をそのままリモートPCから行うことができる。リモートPCからの遠隔操作で 作成した業務データもファイル共有サーバに保存するので,社員が出社した際にも業 務データをそのまま利用できる。 ー27一 なお,本社VPNサーバと各営業所のVPNサーバとの間を接続する通信で用いられて いる暗号化機能は,|』|とは異なり,ネットワーク層で暗号化する |<|を用いている。 [リモートアクセスの認証処理 Webサーバにリモートアクセス認証で必要なソフトウェアをインストールして,あ らかじめ社員ごとに払い出されたリモートアクセス用IDなどを登録しておく。また, ①リモートPCにはリモートアクセスに必要な2種類の証明書をダウンロードする。 テレワークの社員がリモートアクセスするときの認証処理は,次の二段階で行われ る。 第一段階の認証処理は,本社VPNサーバにリモートPCのWebブラウザからVPN HH 続をする際の認証である。まず,社員はWebサーバのリモートログイン専用のページ にアクセスして,リモートアクセス用のIDを入力することによってVPN接続に必要 で一定時間だけ有効な|q|を入手する。このリモートログイン専用のページ にアクセスする際には,リモートPC上の証明書が利用される。次にWebブラウザか ら本社VPNサーバにアクセスして,リモートアクセス用のIDと|d|を入力 することによってリモートPC上の証明書と合わせてVPN接続の認証が行われる。 第二段階の認証処理は,通常社内で内部PCにログインする際に利用するIDとパス ワードを用いて| e|で行われる。 [テレワークで利用するWeb会議サービス〕 テレワークで利用するWeb会議サービスは,インターネット上でSaaSとして提供 されているりV社のWeb会議サービスを採用することになった。このWeb会議サービス lt,内部PCのWebブラウザとSaaS上のWeb会議サービスとを接続して利用する。 Web会議サービスでは,同時に複数のPCが参加することができ,ビデオ映像と音声 が参加しているPC間で共有される。利用者はマイクとカメラの利用の要否をそれぞ れ選択することができる。 [テレワーク移行中に発生したシステムトラブルの原因と対策] テレワークへの移行を進めていたある日,リモートPCから内部PCにリモート接続 ー28一 するPC数が増えをたことで,リモートPCでは画面応答やファイル操作などの反応が遅 くなったり,We会議サービスでは画面の映像や音声が中断したりする事象が頻発し た。 社員から業務に支障を来すと申告を受けたYさんは,直ちに原因を調査した。 Yさんが原因を調査した結果,次のことが分かった。 (1)社内ネットワークを流れる通信量を複数箇所で測定したところ,本社のインタ ーネット接続回線の帯域使用率が非常に高い。 (2)本社のインターネット接続回線を流れる通信量を通信の種類ごとに調べたとこ ろ,Web会議サービスの通信量が特に多い。このWeb会議サービスの⑳通信経路に 関する要因のほかに,映像通信が集中して通信量が増大することが要因となったの ではないかと考え,利用者1人当たりの10分間の平均転送データ量を実測した。 その結果は,映像と音声を用いた通信方式の場合で129Mバイトであった。これを 通信帯境に換算すると|f|Mビピットノ秒となる。 社員200名のうち60%の社員が同時にこのWeb会議サービスの通信方式を利用す る場合,使用する通信帯域は|g|ビットンノ秒となり,この通信だけで本社 のインターネット接続回線の契約帯域を超えてしまう。 Yさんは,本社のインターネット接続回線を流れる通信量を抑える方策として,営 業所1と営業所2に設置された③UTMを利用してインターネットの特定サイトヘアク セスする設定と営業所PCのWebブラウザに例外設定とを追加した。 Yさんは,今回の原因調査の結果と対策案をX部長に報告しトラブル対策を実施し keその後本社のインターネット接続回線の帯域増強工事が完了し,UTMと営業所PC のWebブラウザの設定を元に戻し,テレワーク環境への移行が完了した。 | ー99一

共通の文章

問7奉シェアリングシステムに関する次の記述を読んで,設問に答えよ。 I社は,鉄道駅,商業施設,公共施設などに無人の傘貸出機を設置し,利用者に傘 を貸し出す,傘シェアリングシステム(WE,本システムという)を開発している。 本システムの構成を図1に,傘貸出機の外観を図2に示す。 2次元 パーロード (インターネッae 貸出・返却口 x傘貸出機 図1本システムの構成図2傘貸出機の外観 傘貸出機は.スマートフォンで動作する専用のアプリケーションプログラム(以 下,アプリという)と組み合わせて傘の貸出し又は返却を行う。利用者がアプリを 使って,利用する傘貸出機に貼り付けてある2次元バーコードの情報を読み,BAH 機を特定する。アプリは,管理サーバへ傘の貸出要求又は返却要求を送る。管理サ ーバは,アプリからの要求に従って指定の傘貸出機へ指示を送り,貸出し又は返却 が実施される。傘貸出機の構成を図3に示す。 Be 2[ee 図3傘貸出機の構成 ーー38ーー 〔傘貸出機の処理]〕 ・貸出・返却口に内蔵されているロック機構は,制御部からの指示で貸出・返却品 のロックを制御する。ロック機構は,1度の操作で傘貸出機から1本の傘の貸出し, 又は,1本の傘の返却ができる。ロックが解除されると,制御部はスピーカーから 音声を出力して,ロックが解除されたことを利用者に知らせる。また,ロック機 構は,貸出時と返却時とでロックの解除方法が異なっており,貸出時のロックの 解除では,傘の貸出しだけが可能となり,返却時のロックの解除では,傘の返却 だけが可能となる。 ・ロック機構の傘検知部は,傘検知部を通過する傘を検知する光センサー(以下, センサーという)及び傘に付与される識別情報を記録したRFIDタグを読み取る RFIDリーダーで構成される。①制御部は,傘検知部のセンサー出力の変化を検出 すると10ミリ秒周期で出力を読み出し,5回連続で同じ値が読み出されたときに, 確定と判断し,その値を確定値とする。傘の特定には,RFIDリーダーで読み出し た情報(以下,RFIDタグの情報という)が使用される。傘貸出機が貸出し,返却 を行うためのロックを解除した後10秒経過しても傘の貸出し,返却が行われなか った場合は,異常と判断し,ロックを掛ける。異常の際は,制御部がスピーカー から音声を出力して,異常が発生したことを利用者に知らせる。 ・傘貸出機内の傘の本数は,制御部で管理する。本システムの管理者は,MOOR 設置の際,管理サーバ経由で傘の本数の初期値を傘貸出機に登録する。 ・傘貸出機は,利用者への傘の貸出し又は返却が終了すると,自機が保有する傘の 本数及び傘を識別するRIDタグの情報(以下,これらを管理情報という)を更新 し,管理サーバに送信する。傘貸出機は,全ての管理情報を管理サーバから受信 し,記憶する。 (制御部のソフトウェア構成 制御部のソフトウェアには,リアルタイムOSを使用する。制御部の主なタスクの 一覧を表1に示す。 ー39— 表1制御部の主なタスクの一覧 ・管理サーバから指示を受信すると,貸出タスク又は返却タスクへ送信する。 ・"RFID情報"を受けると,RFIDタグの情報を確認し,“IER”Rit“BRS”を必要とする送信元タ スクへ送信する。 メイン5 、・"ロック解除完了"”を受けると,人卒の貸出し又は返却が可能なことを知らせる音声をスピーカーか ら出力する。 “ST”を受けると,管理情報を更新し,管理サーバへ管理情報を送信する。 ・“異淀終了”を受けると,異常を知らせる音声をスピーカーから出力し,管理サーバに異常終了を 送信する。 ・要求を受けると,センサーで傘を検知し,RFIDリーダーでRFIDタグの情報を読み出し,“RFID情 報'"をメインタスクに送信してから,傘貸出機のロックを解除し,"ロック解除完了”をメインタ スクに送信する。 貸出・卒が取り出されたことをセンサーで検知すると,傘貸出機のロックを掛け,メインタスクへ"完 J”を送信する。 ・ロックを解除した後,10秒経過しても傘が取り出されなかった場合は,傘貸出機のロックを掛 け,メインタスクへ“REBT”を送信する。 ・要求を受けると,センサーで傘を検知し,RFIDリーダーでRFIDタグの情報を読み出し,“RFID情 報"をメインタスクに送信する。送信後“正常"を受けると,傘貸出機のロックを解除し,"ロッ ク解除完了"をメインタスクに送信する。 返却・傘が傘貸出機へ返知されたことをセンサーで検知すると,傘貸出機のロックを掛け,メインタスク へ完了”を送信する。 “RE”を受けると,傘貸出機のロックを掛け,メインタスクへ“異常終了”を送信する。 ・ロックを解除した後,10秒経過しても卒が返却されなかった場合は,傘貸出機のロックを掛け, メインタスクへ“異常終了"を送信する。

共通の文章

問8設計レビューに関する次の記述を読んで,設問に答えよ。 A社は,PERO SI企業である。A社は,先頃,取引先のH社の情報共有システムの 刷新を請け負うことになった。A tld,H社の情報共有システムの刷新プロジェクト を立ち上げ,B氏がプロジェクトマネージャとしてシステム開発を取り仕切ることに なった。H社の情報共有システムは,開発予定規模が同程度の四つのサブシステムか ら成る。 A社では,プロジェクトの開発メンバーをグループに分けて管理することにしてい る。B氏は,それにのっとり,開発メンバーを,サブシステムごとにCグループ,D グループ,Eグループ,Fグループに振り分け,グループごとに十分な経験があるメ ンバーをリーダーに選定した。 (A社の品質管理方針] 設計上の欠陥がテスト工程で見つかった場合,修正工数が膨大になるので,A社で は,設計上の欠陥を早期に検出できる設計レビューを重視している。また,レビュー で見つかった欠陥の修正において,新たな欠陥である二次欠陥が生じないように確認 することを徹底している。 [A社のレビュー形態〕 A社の設計工程でのレビュー形態を表1に示す。 表1設計工程でのレビュー形態 実施時期 設計途中(グ|グループのメンバーがレビュアとなる。 ループのリー|①④設計者が設計和書(作成途中の物も含む)を複数のレビュアに配布又は回覧して,レビュア ダーが進捗状|が欠陥を指摘する。誤字,脱字,RIVER,この段階でできるだけ排除する。誤 況を考慮して|字,脱字,表記ルール違反のチェックには,修正箇所の候補を抽出するツールを利用する。 RE) 部設計が完了|る。レビュー会議の目的は,設計上の欠陥(FR,FR,重複など)を検出することであ4 AMBRE,内|グループ単位でレビュー会議を実施する。必要に応じて別グループのリーダーの参加を求めビ した時点る。検出した欠陥の対策は,欠陥の検出とは別のタイミングで議論する。設計途中のレビュ ーで対応が漏れた誤字,脱字,表記ルール違反もレビュー会議で検出する。②レビュー会議 の主催者(以下、モデレーターという)が全体のコーディネートを行う。参加者が明確な役 割を受けもち,チェックリストなどに基づいた指摘を行い,正式な記録を残す。レビュー会 議の結果は,次の工程に進む判断基準の一つになっている。 —A一 外部設計や内部設計が完了した時点で行うレビュー会議の手順を表2に示す。 表2レビュー会議の手順 必要な文書の|設計者が設計書を作成してモデレーターに送付する。 準備モデレーターがチェックリストなどを準備する。 モデレーターは,設計書,チェックリストを配布し,参加者がレビューの目的を達成 できるように,設計内容の背景,前提,重要機能などを説明する。 モデレーターは,集合ミーティングにおける設計書の評価について,次の基準に基づ いて定性的に判断することを説明する。 "合格"…………軽微な修正が必要かもしれないが,フォローアップミーティングは RS|不要である。_-- a|oss Be条件付合格”…小規模な修正が必要で,フォローアップミーティングで修正を検証 する。 “OY HL"……大規模な修正が必要,又は,欠陥や課題の検出が十分でないのでレ ビピュー会議をやり直す。 評価を導く意思決定のルール(モデレーターによる決定,SRR,全員一致)につい ても,参加者全員の合意を得る。 モデレーターは,集合ミーティングにおける読み手,記録係,レビュアを指名する。 6参加者の事前|集合ミーティングまでに,レビュアが各自でチェックリストに従って設計書のレビュ レビューーを行い,欠陥を洗い出す。 読み手がレビュー対象の設計書を参加者に説明して,レビュアから指摘された欠陥を 集合ミーティ|記録係が記録する。 ング[a|は,集合ミーティングの終了時に,意思決定のルールに従い“AH”, “条件付合格",“やり直し"の評価を導く。 |orn集ティングで発見された欠陥を設計者が解決する 5合ミーティングで発見された設計者が解>5 発見された欠_ 評価が“条件付合格”OWA,モデレーターと設計者を含めたメンバーとで実施す ズオローアッる。 プミーティン|久陥が全て解決されたことを確認する。 設計書の修正が|bp|を生じさせることなく正しく行われたことを確認する。 [モデレーターの選定] B氏は,グループのリーダーにモデレーターの経験を積ませたいと考えた。しかし, グループのリーダーは自グループの開発内容に精通しているので,自グループのレビ ュー会議にはモデレーターではなく,レビュアとして参加させることにした。 また,B氏自身は開発メンバーの査定に関わっており,参加者が欠陥の指摘をため らうおそれがあると考え,レビュー会議には参加しないことにした。 B氏は,これらの考え方に基づいて,各グループのレビュー会議のつ③⑨モデレーター を選定した。 [レビュー会議におけるレビュー結果の評価]〕 A社の品質管理のための基本測定量(抜粋)を表3に示す。 表3基本測定量(抜粋) 設計程|設計の間科=。|ペンジ|OCSCS レビューエエ数人時表2のレビュー会議の手順の項番3と項番4に要し た工数の合計を測定する。 工数を標準化するために,育成目的などで標準的な スキルをもたないレビュアを参加させる場合は,そ の工数は含めない。 レビュー指摘件数RE,MF,表記ルール人違反の件数を測定する。 第2 BY件誤字,脱字,表記ルール赴反以外の,設計上の欠陥 の件数を測定する。 レビュー会議における設計書のレビュー結果を,基本測定量から導出される指標を 用いて分析する。設計書のレビュー結果の指標を表4に示す。 表4設計書のレビュー結果の指標 レビュー指摘密度(第1群1ページ当たりの第1群のレビュー指摘件数 レビュー指摘密度(第2群1ページ当たりの第2群のレビュー指摘件数 レビュー工数密度には,下方管理限界(以下,LCLという)と上方管理限界(以下, UCLという)を適用する。 ④レビュー指摘密度(第1群)にはUCLだけ適用する。レビュー指摘密度(第2 群)には,LCLとUCLを適用する。レビュー指摘密度(第1群)が高い場合,設計途 中に実施したグループのメンバーによるレビューが十分に行われていないことが多く, レビュー指摘密度(第2群)も高くなる傾向にある。 H社の情報共有システムの内部設計が完了して,内部設計書のレビュー会議の集合 ミーティングの結果は,全てのグループについて"条件付合格"”であった。指標の集 計が完了して,フォローアップミーティングも終了した段階で,B氏は,次の開発エエ 程に進むかどうかを判断するために,内部設計書のレビュー結果の詳細,及び指標を ーー44— 確認した。 開発グループごとに,レビューエエ数密度を横軸に,レビュー指摘密度を縦軸にとっ た,レビューのゾーン分析のグラフを図1に示す。 LCL UCL E Ro レ i.@D te EE 摘アデae'上 密eee Saale”“Sema Ui LCL(第2群) 度!C|© レビュー工数密度 凡例〇:第1群の数値@:A2#HORE ーーー--:しきい値………:同じグループの数値 図1レビューのゾーン分析 B氏が,各グループのモデレーターにレビュー会議の状況について確認した結果と, B氏の対応を表5に示す。 表5レビュー会議の状況についての確認結果と対応 確認結果|対応| 計画した時間内にチェックリストの項目を全て|しきい値内であり,問題なしと判断した。 確認した。 E集合ミーティングの時間中に,一部の欠陥の修レビュー会議の進め方についてレビュー効率向 正方法,修正内容の議論が始まってしまい,会|上の観点から⑤改善指針を示した上で,レビュ 議の予定時間を大きくオーバーした。ー会議のやり直しをモデレーターに指示した。 ‘レビュー予定箇所を全てチェックしたものの, 集合ミーティングの後半部分で取り上げた設計 書のレビューがかなり駆け足になった。 F指摘件数が多かったので,欠陥の抽出は十分と|レビューが不十分なおそれが大きく,追加のレ 考えて,集合ミーティングの終了予定時刻より|ビューを実施するようにモデレーターに指示し 前に終了させた。た。 B氏は,表5の対応後に,対応状況を確認して,次の工程に進めると判断した。

共通の文章

プロジェクトのリスクマネジメントに関する次の記述を読んで,設問に答えよ。 K社は機械部品を製造販売する中堅企業であり,昨今の市場の変化に対応するため に新生産計画システムを導入することになった。K tlt,この新生産計画システムに., T社の生産計画アプリケーションソフトウェアを採用し,新生産計画システム導入プ ロジェクト(以下,本プロジェクトという)を立ち上げた。本プロジェクトのプロジ ェクトマネージャに,情報システム部のL君が任命された。本プロジェクトのチーム は,業務チーム及び基盤チームで構成される。 本年7月に本プロジェクトの計画を作成し,8月初めから10月末まで要件定義を行 い,11月から基本設計を開始して,来年6月に本番稼働予定である。T社の生産計画 アプリケーションソフトウェアには,生産計画の作成を支援するためのAI機能があ り,K社はこのAI機能を利用する。ただし,生産計画を含む日次バッチ処理時間に 制約があるので,AI機能の処理時間(以下,AI処理時間という)の検証を基盤チー ムが担当する。K社はこれまでAl機能を利用した経験がないので,要件定義の期間 中に,T社と技術支援の契約を締結してAI処理時間の検証(以下,AI処理時間検証 という)を実施する。このAI処理時間検証が要件定義のクリティカルパスである。 [リスクマネジメント計画の作成 L Bld,リスクマネジメント計画を作成し,特定されたリスクへの対応に備えてコ ンティンジェンシー予備を設定し,それを使用する際のルールを記載した。また,リ スクカテゴリに関して,特定された全てのリスクを要因別に区分し,そこから更に 個々のリスクが特定できるよう詳細化していくことでリスクを体系的に整理するため に| 』|を作成することとした。 [リスクの特定〕 L君は。プロジェクトの計画段階で次の方法でリスクの特定を行うこととした。 (1)本プロジェクトのK社内メンバーによるブレーンストーミング (2)K社の過去のプロジェクトを基に作成したリスク一覧を用いたチェック (3)業務チーム,基盤チームとのミーティングによる整理 この方法について上司に報告したところ,LADS,①K社の現状を考慮すると, ー48一 この方法ではAI機能の利用に関するリスクの特定ができないので見直しが必要であ ると指摘された。また,上司から次のアドバイスを受けた。 ・リスクの原因の候補が複数想定されることがしばしばある。その場合, [oJを用いて,リスクとリスクの原因の候補との関係を系統的に図解して 分類,整理することが,リスクに関する情報収集や原因の分析に有効である。 L君は,上司の指摘やアドバイスを受け入れて,方法を見直して7月末までにリス クを特定し,リスクへの対応を定めた。また,リスクマネジメントの進め方として, プロジェクトの進捗に従ってリスクへの対応の進捗をレビューすることにした。 現在は8月末であり要件定義を実施中である。L Blt,各チームと進捗の状況を確 認するミーティングを行った。基盤チームから,“Al処理時間検証の10月に予定し ている作業が難航しそうで,想定の期間内で終わりそうにない。”という懸念が示さ れた。L君は,この懸念が,現在実施中の要件定義で顕在化する可能性があることか ら対応の緊急性が高いと判断し,新たなかリスクとして特定した。 〔リスク対策の検討〕 L君はこのリスクについて,詳細を確認した結果,次のことが分かった。 ・AI処理時間検証に当たっては,技術支援の契約に基づきT社製AIの専門家である T社のU氏にAl処理時間について問合せをしながら作業している。その問合せ回数 をプロジェクト開始時には最大で4回ノ週までと見積もっていて,8月の実績は4 回ノ週であった。U氏は週4回までの問合せにしか対応できない契約なので,問合 せ回数が5回ノ週以上になると,U氏からの回答が遅れ,AI処理時間検証も遅延す る。今の見通しでは,9月は問合せ回数が最大で4回週で,5回ノ週以上に増加 する週はないが,10月は5回ノ週以上に増加する週が出る確率が30%%と見込まれ る。なお,19月に問合せ回数が増加したとしても,8回ノ週を超える可能性はなく, 10月初めから要件定義の完了までの問合せ回数の合計は最大で32回と見込まれる。 ・AI処理時間の問合せへの回答には,T社製A1に関する専門知識を要する。【社内に その専門知識をもつ要員はおらず,習得するにはT社の講習の受講が必要で,受講 には稼働日で20日を要する。 Al処理時間検証が遅延すると,要件定義全体のスケジュールが遅延する。要件定 =<i= 義の完了が予定の10月末から遅延すると,その後の遅延回復のために要員追加な どが必要になり,遅延する稼働日1日当たりで20万円の追加コストが発生する。 ・何も対策をしない場合,仮に19月以降,問合せ回数が5回ノ週以上の週が出ると, 要件定義の完了は稼働日で最大20日遅延する。 ・AI機能の利用に関する作業量は想定よりも増加している。T社の技術支援が終了す る基本設計以降に備えて早めに要員を追加しないと今後の作業が遅延する。 L君は.このリスクへの対応を検討した。まず,基盤チームのメンバーであるM君 の担当作業の工数が想定よりも小さく,他のメンバーに作業を移管できるので,9月 第2週目の終わりまでに移管し,M君を今後,作業量が増加するAI機能の担当とす る。次に,問合せ回数の増加への対応として,表1に示すT社との契約を変更する案, RUM君にT社の講習を受講させる案を検討した。ここで,1か月の稼働日数は20 日,1週間の稼働日数は5日とする。 表1 AI処理時間検証遅延リスクへの対応検討結果 対応までに必要な|対応に要する [+fesvonmaneals cauate meron aera Juana T社との契約を変更し問ace a やす。人° 。|!君がT社講習を受け,|URCMBO2ZATIO/BET|講習受講日数oar 問合せに回答する。の問合せに回答可能となる。20日 Pajama.TC 0《〈1tト|-lm| 注!)M君の講習受講費用のプロジェクトでの負担額 L君は状況の確定する10月に入って対応を決定するのでは遅いと考え,現時点か ら2週間後の9月第2週目の終わりに,問合せ回数が5回ノ週以上に増加する週が出 る確率を再度確認した上で,対応を決定することとした。しL君は,9月第2週目の終 わりの時点で表1の対応を実施した場合の効果を,それぞれ次のように考えた。 EE 1の対応の場合,T社との契約変更が9月末に完了でき,10月に問合せ回数が 5回ノ週以上の週があっても対応することが可能となる。 ・項番2の対応の場合,9月第3週目の初めからM君は,T社講習の受講を開始する。 M君が受講を終え,AI処理時間について4回ツ週までの問合せ回答ができるのは, ーー50ーー 10月第3週目の初めとなる。これによって,10月の第1週目と第2週目はU氏だ けでの問合せ回答となり,16月第3週目の初めからU氏とM君が問合せ回答を行え るようになる。この結果,要件定義は当初予定から最大で5日遅れの,11月第1週 目の終わりに完了する見込みとなる。 L君は,表1の対応による効果を検討するために,問合せ回数増加の発生確率の今 の見通しを基に図1のデシジョンツリーを作成した。 m※ギノード30%Matees,23a$e mb @#4/-k T社との契約を変更する。ーーニーーニーーー= 70%|問合せ回数が,全ての週で4回ノ週 以下で,遅延なし 30%|問合せ回数が,ある週で5回ノ週以 ーー-上で,385 Augie M君がT社講習を受講する。 70%|問合せ回数が,全ての週で4回ノ周 以下で,遅延なし 30%|問合せ回数が,ある週で5回ノ週以 70%|問合せ回数が,全ての週で4回ノ週 以下で,遅延なし 図1問合せ回数増加に対する対応のデシジョンツリー さらにL君は,図1を基に対応に要する追加コストと,要件定義の完了の遅延によ って発生する追加コストの最大値を算出し,表2の対応と追加コスト一覧にまとめた。 表2対応と追加コスト一覧 _、|遅延によって|追加コスト 項Ba poms 10月の1週間当たり|発生内発生する追加|合計の最大 番°.CHEの問合せ回数確率|ロコ)コストの最大|値の期待値 値(万円)(万円) 更し問合せへの回°me=3 2受け,問合せに回P|ーー| slice vbw.|—|===| 注記表中の部分は,省略されている。 9月第2週目の終わりに,問合せ回数増加の発生確率が今の見通しから変わらない 場合,コンティンジェンシー予備の範囲に収まることを確認した上で,追加コスト合 計の最大値の期待値が最も小さい対応を選択することにした。 [リスクマネジメントの実施] L Ald,現時点でのリスクと対応を整理したことで,本プロジェクトのリスクの特 定を完了したと考え,今後はこれまでに特定したリスクを対象にプロジェクト完了ま で定期的にリスクへの対応の進捗をレビューしていく進め方とし,上司に報告した。 しかし,上司からは,その進め方では,リスクマネジメントとして不十分であると指 摘された。そこでL君は②ある活動をリスクマネジメントの進め方に追加することに した。

共通の文章

間19サービス変更の計画に関する次の記述を読んで,設問に答えよ。 D社は,中堅の食品販売会社で,D社の営業部は,小売業者に対する受注業務を行 っている。D社の情報システム部が運用する受注システムは,オンライン処理とバッ チ処理で構成されており,受注サービスとして営業部に提供されている。 情報システム部には業務サービス課,開発課,基盤構築課の三つの課があり,受注 サービスを含め複数のサービスを提供している。業務サービス課は,サービス運用に おける利用者管理,サービスデスク業務,アプリケーションシステムのジョブ運用な どの作業を行う。開発課は,サービスの新規導入や変更に伴う業務設計,アプリケー ションソフトウェアの設計と開発などの作業を行う。基盤構築課は,サーバ構築,ア プリケーションシステムの導入,バッチ処理のジョブの設定などの作業を行う。 業務サービス課にはE君を含む数名のITサービスマネージャがおり,E君は受注サ ービスを担当している。業務サービス課では,運用費用の予算は,各サービスの作業 ごとの1か月当たりの平均作業工数の見積りを基に作成している。運用費用の実績は, 各サービスの作業ごとの1か月当たりの作業工数の実績を基に算出し,作業ごとに毎 月の実績が予算内に収まるように管理している。運用費用の予算はD社の会計年度単 位で計画され,今年度は,各サービスの作業ごとに前年度の1か月当たりの平均作業 工数の実績に対して19%の工数増加を想定して見積もった予算が確保されている。 〔D社の変更管理プロセス]〕 D社の変更管理プロセスでは,変更要求を審査して承認を行う。変更要求の内容が サービスに重大な影響を及ぼす可能性がある場合は,社内から専門能力のあるメンバ ーを集めて,サービス変更の計画から移行までの活動を行う。また,サービス変更の 計画の活動では,①変更を実施して得られる成果を定めておき,移行の活動が完了し てサービス運用が開始した後,この成果の達成を検証する。 (受注サービスの変更〕 これまで営業部では,受注してから商品の出荷までに,受注先の小売業者の信用情 報の確認を行っていた。このほど,売掛金の回収率を高めるという営業部の方針で, 与信管理を強化することとなり,受注時点で与信限度額チェックを行うことにした。 ー54.— そこで,営業部の体制増強が必要となり,取引実績のあるM社に営業事務作業の業務 委託を行うことになった。 受注サービスの変更の活動は,情報システム部の業務サービス課,開発課及び基盤 構築課が実施し,業務サービス課の課長がリーダーとなった。 システム面の実現手段として,ソフトウェアパッケージ販売会社であるN社から信 用情報管理,与信限度額チェックなどの与信管理業務の機能をもつソフトウェアパッ ケージの導入提案を受けた。この提案によると,N社のソリフトウェアパッケージをサ ブシステムとして受注システムに組み込み,与信管理データベースを構築することに なる。また,受注システムのバッチ処理でN社の提供する情報サービスに接続し,信 用情報を入手して与信管理データベースを毎日更新する。D社はこの提案を採用し, 受注サービスを変更することにした。変更後の受注サービスは,今年度後半から運用 を開始する予定である。 E君は,各課を取りまとめるサブリーダーとして参加し,受注サービス変更後のサ ービス運用における追加作業項目の洗い出しと必要な作業工数の算出を行う。 [追加作業項目の洗い出し E君は,今回の受注サービス変更後の,サービス運用における情報システム部の追 加作業項目を検討した。その結果,E君は追加で次の作業項目が必要であることを確 Be Le. ・利用者管理の作業にサービス利用の権限を与える利用者としてM社の要員を追加す る。また,サービスデスク業務の作業に利用者からの与信管理業務の機能こついて の問合せへの対応とFAQの作成・更新を追加する。 ・受注システムのバッチ処理に,“信用情報取得ジョブ”のジョブ運用を追加する。 このジョブは,毎日の受注システムのオンライン処理終了後に自動的に起動され, 起動後はバッチ処理のジョブフロー制御機能によってN社の提供する情報サービス に接続して,更新する信用情報を受信し,与信管理データベースを更新する。バッ チ処理が実行されている間,業務サービス課の運用担当者が受注システムに対して 行う作業はないが,N社の情報サービスへの接続,情報受信,及びデータベース更 新のそれぞれの処理が完了した時点で,運用担当者は,処理が正常に完了したこと を確認する。正常に完了していない場合には,開発課が作成したマニュアルに従い, ー55一 再実行などの対応を行う。 ・N社から,機能アップグレード用プログラムが適宜提供され,N社リソフトウェアパ ッケージの機能を追加することができる。営業部は,追加される機能の内容を確認 し,利用すると決定した場合は業務変更のための業務設計と機能アップグレードの 適用を情報システム部の開発課に依頼する。なお,機能アップグレードの適用は, テスト環境で検証した後,受注システムの稼働環境に展開する手順となる。 ・また,N社からは機能アップグレード用プログラムのほかに,ソフトウェアの使用 性向上や不具合対策用の修正プログラム(以下,パッチという)が,臨時に提供さ れる。このパッチは業務に影響を与えることはなく,パッチの適用や結果確認の手 順は定型化されている。 E君は,情報システム部の追加作業項目とその作業内容の一覧を,表1のとおり作 成した。 表1情報システム部の追加作業項目とその作業内容の一覧 四 7293 常でない場合の対応対応 E@ld,表1をリーダーにレビューしてもらった。リーダーから,“表1の作業項目 | 』|には情報システム部が行う作業内容が漏れているので,追加するように” と指摘された。E Blt,各チームで必要となる作業を再検討し,表1の作業項目 [a|に@漏れていた作業内容を追加した。 〔サービス運用に必要な作業工数の算出〕 E Ald,追加が必要な作業のうち,定常的に必要となる利用者管理,サービスデス ク業務及びジョブ運用の作業工数を算出した。算出手順として,表2に示す受注サー ビスの変更前の作業工数の実績一覧を基に,変更後の作業工数を見積もった。なお, ー56一 変更前の1か月当たりの平均作業工数の実績は,予算作成に用いた前年度の1 DAS たりの平均作業工数の実績と同じであった。 表2受注サービスの変更前の作業工数の実績一覧 作業1回当たりの平均PME|1か月当たりの平均 作業工数(人日)(回ノ月)|作業工数(AB) Fes ce el el 注り運用担当者は受注サービス以外の運用作業も行っていることから,ジョブ 運用の作業工数には,システム処理の時間は含めないものとする。 E Blt,関係者と検討を行い,追加で必要となる作業工数を算出する前提を次のと おりまとめた。 ・利用者管理及びサービスデスク業務の発生頻度は,今回予定しているM社の要員の 利用者追加によって,それぞれ10%増加する。 ・与信管理業務の機能の追加によって問合せが増加するので,サービスデスク業務の 発生頻度は,利用者追加によって増加した発生頻度から,更に5%増加する。 ・利用者管理及びサービスデスク業務について1回当たりの平均作業工数は変わらな い。 ・ジョブ運用について,信用情報取得ジョブは,現在のバッチ処理のジョブに追加さ れるので,その運用の発生頻度は,現在と変わらず月に29回である。ジョブ1回 当たりのシステム処理及び運用担当者の確認作業の実施時間は表3のとおりである。 表3信用情報取得ジョブ1回当たりの実施時間 客間(人 社の情報サービスへの反和 N社の情報サービスへの接統処理の確認|運用担当者の確認作業|S| 軍用担当者の確作業|8| 軍用担当者の確認 pga 表2と,追加が必要となる作業工数算出の前提及び表3から,EAM,サービス変 更後のサービス運用に必要な作業工数を算出した。作業工数の算出においては,ジョ ブ運用の1回当たりの平均作業工数は,表2の受注サービスの変更前の平均作業工数 に表3の信用情報取得ジョブ1回当たりの実施時間から算出した作業工数の合計を加 算した。なお,運用担当者は1日3交替のシフト勤務をしているので,作業時間の単 位“分を日に換算する場合は,情報システム部では480分を1日として計算す る規定としている。算出結果を表4に示す。 表4サービス変更後のサービス運用に必要な作業工数 jemsmm[ef eC pa|eceararmm[TT Ce 注記表中の_部分は,省略されている。 Ee W'sel[gr] E Blt,サービス変更後の作業ごとの1か月当たりの平均作業工数を算出した結果, ③ある作業には問題点があると考えた。その問題点についてリーダーと相談して対策 方針を決め,対策を実施することになった。

共通の文章

テレワーク環境の監査に関する次の記述を読んで,設問に答えよ。 大手のマンション管理会社であるY社は,業務改革の推進,感染症拡大への対応な どを背景として,X年4月からテレワーク環境を導入し,全従業員の約半数が業務内 容に応じて利用している。このような状況の下,テレワーク環境の不適切な利用に起 因して,情報漏えいなども発生するおそれがあり,情報セキュリティ管理の重要性は 増大している。 Y社の内部監査部長は,このような状況を踏まをえて,システム監査チームに対して, テレワーク環境の情報セキュリティ管理をテーマとして,監査を行うよう指示した。 システム監査チームは,X年9月に予備調査を行い,次の事項を把握した。 〔テレワーク環境の利用状況] (1)テレワーク環境で利用するPCの管理 Y社の従業員は,貸与されたPC(以下,貸与PCという)を,Y社の社内及び テレワーク環境で利用する。 システム部は,全従業員分の貸与PCについて,貸与PC管理台帳に,PC管理 番号,利用する従業員名,テレワーク環境の利用有無などを登録する。貸与PC 管理台帳は,貸与PCを利用する従業員が所属する各部に配置されているシステ ム管理者も閲覧可能である。 (2)テレワーク環境の利用者の管理 従業員は,テレワーク環境の利用を申請する場合に,テレワーク環境利用開始 届(以下,利用届という)を作成し,所属する部のシステム管理者の確認,及び 部長の承認を得て,システム部に提出する。利用届には,申請する従業員の氏名, 利用開始希望日,Y社の情報セキュリティ管理基準の遵守についての痺約などを 記載する。システム部は,利用届に基づき,BS PCをテレワーク環境でも利用 できるように,VPN接続ソフトのインストールなどを行う。 各部のシステム管理者は,従業員が異動,退職などに伴い,テレワーク環境の 利用を終了する場合に,テレワーク環境利用終了届(以下,終了届という)を作 成し,システム部に提出する。終了届には,テレワーク環境の利用を終了する従 業員の氏名,事由などを記載する。システム部は,終了届に基づき,貸与PCを —6= テレワーク環境で利用できないようにし,終了届の写しをシステム管理者に返却 する。 (3)テレワーク環境のアプリケーションシステム テレワーク環境では,従業員の利用権限に応じて,基幹業務システム,社内ポ ータルサイト,Web会議システムなど,様々なアプリケーションシステムを利用 することができる。これらのアプリケーションシステムのうち,Web会議システ Alt,年6月から社内及びテレワーク環境で利用可能となっている。EK,従 業員は,基幹業務システムなどを利用して,顧客の個人情報,営業情報などにア クセスし,BS PCのハードディスクに一時的にダウンロードして,加工・編集 する場合がある。 [テレワーク環境に関して発生した問題 (1)顧客の個人情報の漏えい Y社の情報セキュリティ管理基準では,テレワーク環境への接続に利用する Wi-Fiについて,パスワードの入力を必須とすることなど,セキュリティ要件を 定めている。 X年5月20日に,業務管理部の従業員が,セキュリティ要件を満たさないWi- Fiを利用してテレワーク環境に接続したことによって,貸与PCのハードディス クにダウンロードされた顧客の個人情報が漏えいする事案が発生した。 (2)貸与PCの紛失・盗難 テレワーク環境の導入後,貸与PCを社外で利用する機会が増えたことから, 貸与PCの紛失・盗難の事案が発生していた。 各部のシステム管理者は,従業員が貸与PCを紛失した場合,貸与PCのPC管 理番号,紛失日,紛失状況,最終利用日,システム部への届出日などを紛失届に 記載し,遅くとも紛失日の翌日までに,システム部に提出する。システム部は, 提出された紛失届の記載内容を確認し,受付日を記載した後に,紛失届の写しを _システム管理者に返却する。 営業部の7氏は,X年8月9日に営業先から自宅に戻る途中で貸与PCを紛失 したまま,紛失日の翌日から1週間の休暇を取得した。同部のシステム管理者は, 7氏からX年8月17日に報告を受け,同日中に当該PCの紛失届をシステム部に ー61一 提出した。 [情報セキュリティ管理状況の点検〕 (1)点検の体制及び時期 システム部は毎年1月に,各部における情報セキュリティ管理状況の点検(以 下,セキュリティ点検という)について,年間計画を策定する。各部のシステム 管理者は,年間計画に基づき,セキュリティ点検を実施し,点検結果,及び不備 事項の是正状況をシステム部に報告する。システム部は,点検結果を確認し,ま た,不備事項の是正状況とモニタリングする。X年の年間計画では,2月,5月, 8月,11月の最終営業日にセキュリティ点検を実施することになっている。 (2)点検の項目,内容及び対象 システム部は,毎年1月に,利用されるアプリケーションシステムなどのリス ク評価結果に基づき,セキュリティ点検の項目及び内容を決定する。また,新規 システムの導入,システム環境の変化などに応じて,リスク評価を随時行い,そ の評価結果に基づき,セキュリティ点検の項目及び内容を見直すことになってい る。各部のシステム管理者は,前回点検日以降3か月間を対象にして,セキュリ ティ点検を実施する。X年のセキュリティ点検の項目及び内容の一部を表1に示 す。 表1セキュリティ点検の項目及び内容(一部) 管理状況ついて,終了届をシステム部に提出しているか。 キュリティ要件の周知状況|セキュリティ要件は周知されているか。 に,紛失届をシステム部に提出しているか。 の利用権限の設定状況対して,適切な利用権限が設定されているか。 (3)点検の結果 業務管理部及び営業部のシステム管理者は,テレワーク環境導入後のセキュリ ー62一 ティ点検の結果,表1の項番2及び項番3について,不備事項を報告していなか 57に。 【内部監査部長の指示] 内部監査部長は,システム監査チームから予備調査で把握した事項について報告を 受け,X年11月に実施予定の本調査,テレワーク環境に関するセキュリティ点検 について重点的に確認する方針を決定し,次のとおり指示した。 (1)表1項番1について,| a|と|b|を照合した結果と,セキュリ ティ点検の結果との整合性を確認すること。 (2)表1項番2について,業務管理部におけるセキュリティ点検の結果を考慮して, システム管理者が[|cc|しているかどうか,確認すること。 (3)表1項番3について,紛失届に記載されている|d|と[|es Jer 合した結果と,セキュリティ点検の結果との整合性を確認すること。 (4)表1項番4について,システム部が| f|の結果に基づいて,X年8月の セキュリティ吉検対象のアプリケーションシステムとして,| g|の追加を 検討したかどうか,確認すること。 (5)セキュリティ点検で不備事項が発見された場合,システム管理者が不備事項の 是正状況を報告しているかどうか確認するだけでは,監査手続として不十分であ る。システム部が| h|しているかどうかについても確認すること。