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

共通の文章

リモート環境のセキュリティ対策に関する次の記述を読んで,設問に答えよ。 0社は,首都園で複数の学習塾を経営する会社であり,各学習塾で対面授業を行っ ている。生徒及び生徒の保護者からはリモートでも受講が可能なハイブリッド型授業 の導入要望があり,0社の従業員からはテレワーク勤務の導入要望がある。 〔Q社の現状のネットワーク構成] Q社のネットワーク構成(抜粋)を図1に示す。 i FWヲァイアウォールL2SW:レイヤー2スイッチ 注記学習塾2…学習塾nは学習塾1と同様の構成である。 Bll Q社のネットワーク構成(抜粋) [Q社の現状のセキュリティ対策〕 Q社のセキュリティ対策は次のとおりである。 ・パケットフィルタリングポリシーに従った通信だけをFWで許可し,その他の通信 を遮断している。 ・業務上必要なサイトのURL情報を基に,URLフィルタリングを行うソフトウェアを プロキシサーバに導入して,業務上不要なサイトへの接続を禁止している。 ・PC及びサーバ機器には,外部媒体の使用ができない設定をした上で,マルウェア 対策ソフトを導入して,マルウェア感染対策を行っている。 PC,ネットワーク機器及びサーバ機器には,脆静性に対応する修正プログラム(以 下,セキュリティパッチという)を定期的に確認した後,適用する方法で,脆弱性 対策を行っている。 ー6一 〔Q社の現状のセキュリティ対策に関する課題] ・ネットワーク機器及びサーバ機器のEOL(End Of Life)時期が近づいており,機 器の更新が必要である。 ・セキュリティパッチが提供されているかの調査及び適用してよいかの判断に時間が 掛かることがある。 ・ルータとFWを利用した①境界型防御によるセキュリティ対策では,防御しきれな い攻撃がある。 ・セキュリティインシデントの発生を,迅速に検知する仕組みがない。 Q社では,ハイブリッド型授業とテレワーク勤務が行えるリモート環境を実現し, Q社のセキュリティに関する課題を解決する新たな環境を,クラウドサービスを利用 して構築することになり,情報システム部のR課長が担当することになった。 [リモート環境の構築方針] R課長は,境界型防御の環境に代えて,いかなる通信も信頼しないという | 』|の考え方に基づくリモート環境を構築することにした。 R課長は,リモート環境について次の構築方針を立てた。 ・クラウドサービスへの移行に伴い,ネットワーク機器及びサーバ機器は廃棄し,今 後のQ社としてのEDL対応を不要とする。 ・②課題となっている作業を不要にするために,クラウドサービスはSaaS型を利用 する。 ・セキュリティインシデントの発生を迅速に検知する仕組みを導入する。 ・従業員にモバイルルータとセキュリティ対策を実施したノートPC(以下,貸与PC という)を貸与する。今後は,AH,学習塾及びテレワークでの全ての業務におい て,貸与PCとモバイルルータを使用してクラウドサービスを利用する。 ・貸与PCから業務上不要なサイトへの接続は禁止とする。 ・生徒は,自宅などのPC(以下,自宅PCという)からクラウドサービスを利用して リモートでも授業を受講できる。 [リモート環境構築案の検討〕 R課長はリモート環境の構築方針を部下のS君に説明し,構築する環境の検討を指 | 示した。| S君はリモート環境構築案を検討した。| ・リモート環境の構築には,T社クラウドサービスを利用する。| ・貸与PCからWebサイトを閲覧する際は,プロキシを経由する。 ・貸与PPからインターネットを経由して接続するWeb会議。オンラインストレージ 及び電子メール(以下,メールという)を利用することで,0社の業務及びリモー トでの授業を行う。 ・貸与PCからT社クラウドサービスへのログインは,ログインを集約管理するクラ ウドサービスであるIDaaS(Identity as a Service)を利用する。従業員はIDと パスワードを用いてシングルサインオンで接続してクラウドサービスを利用する。 ・④SIEM(Security Information and Event Management)の導入と,アラート発生 時に対応する体制の構築を行う。 ・貸与PCには,マルウェア対策ソフトを導入し,外部媒体が使用できない設定を行 う。また,⑤紛失時の情報漏えいリスクを低減する対策をとる。 ・生徒は,自宅PCからインターネット経由で,Web会議に接続して,リモートで授 業を受講できる。 S君が検討したリモート環境構築案(抜粋)を図2に示す。 —— T社クラウドサービス <ごインターネットつ 図2リモート環境構築案(抜粋) [構築案への指摘と追加対策の検討〕 S君は検討した構築案についてR課長に説明した。すると,セキュリティ対策の不 足に起因するセキュリティインシデントの発生を懸念したR課長は,“[ a|で は,クラウドサービスにアクセスする通信を信頼せずセキュリティ対策を行う必要が あるので,エンドポイントである貸与PCと自宅PCに対する攻撃への対策及びクラウ ドサービスのユーザー認証を強化する対策が必要である。追加の対策を検討するよう ー8一 co”と指摘した。 R課長が懸念したセキュリティインシデント(抜粋)を表1に示す。 表1 R課長が懸念したセキュリティインシデント(抜粋) クセス S君は,R課長の指摘に対して,表1のセキュリティインシデントに対応した次の 対策を追加することにした。 ・項番1,2の対策として,貸与PCに⑥EDR(Endpoint Detection and Response)ソ フトを導入する。 ・項番3の対策として,T社クラウドサービスは不正アクセス及びマルウェア感染の 対策がとられていることを確認した。 ・項番4の対策として,知識情報であるIDとパスワードによる認証に加えて,所持 情報である従業員のスマートフォンにインストールしたアプリケーションソフトウ ェアに送信されるワンタイムパスワードを組み合わせて認証を行う,|b| を採用する。 SAld,これらの対策を追加した構築案をR課長に報告し,構築案は了承された。

共通の文章

物流業の事業計画に関する次の記述を読んで,設問に答えよ。 B社は,運送業務及び倉庫保管業務を受託する中規模の物流事業者である。従業員 数は約199名で,関東甲信越エリアを中心に事業を行っており,高速道路や幹線道路 へのアクセスの良い立地に複数の営業所と倉庫を構えている。主に,地場のメーカー と販売店との間の配送などを中心に事業を行ってきたが,同業他社との競争が激しく, ここて数年は収益が悪化傾向にあり,このままでは経営は厳しくなる一方である。B社 OC取締役は,この状況の打開に向けて,顧客への新たな価値の提供を目指すべく, 経営企画部のD部長に事業計画の立案を指示した。 (B社の環境分析] D部長は,自社の事業の置かれている状況を把握するために,環境分析を実施する 必要があると考えた。環境分析には,自社を取り巻く経営環境のうち,自社以外の要 因をマクロ的視点とミクロ的視点で分析する外部環境分析と,自社の経営資源に関す る要因を分析し,自社の特徴を洗い出す内部環境分析がある。D部長は,経営企画部 のE課長に,外部環境分析から実施するよう指示した。E課長は,まず,PEST分析を行 い,PEST分析の結果としてB社の事業に影響する要因の概要を表1のように整理した。 表1 B社のPEST分析の結果 aOR 1|政治的要因[a]改正による総労働時間に関する規制の設定 ・運送・倉庫保管業は,以前は需給調整規制によって新規参入が困難で あったが,近年,事業経営能力や安全確保能力のある事業者の参入が 可能となり,参入障壁が低下 ・今後は,外国人労働者をドライバーとして採用できるように規制DE 和される見通し 2|経済的要因・燃料費上昇によるコストの上上昇 ・トラックによる運送の供給量に比べ,顧客からの運送に対する需要量 の方が大きいことから,運送料が上昇することを顧客は一定の範囲で 許容 3|社会的要因・高齢化が進み退職するドライバーが増える一方で少子化の影響で若年 層のドライバーのなり手は減少することから,より良い処遇を提供し なければドライバーの確保が困難 ・EC市場の拡大に起因する運送需要の増加は今後も継続 4|技術的要因・自動運転に必要な技術の急速な発展 ・SNSを活用した多様な購買方法の登場 次に,E課長は,ファイブフォース分析を進めることにした。ファイブフォース分 析の結果,B社が受ける脅威の概要を表2のように整理した。 表2 B社のファイブフォース分析の結果 Pa Eee coe 1|#RAORSORR運送・倉庫保管だけの物流サービスではコモディティ化して, いることから脅威は大きい。 aよる陸送に代わるものではなく脅威は小さい。 ・車両の自動運転による配送やドローン配送の実証実験が行わ れているが,実用化はまだ先であり,現状の脅威は小さい。 れる脅威は大きい。 E課長は,①PEST A,ファイブフォース分析の順に分析し,その結果について検 討した。PEST分析の結果から,| a|が改正されたことによって,ドライバー を含む労働力の総量が減少することが懸念され,また,社会的要因によってドライバ ーのなり手が減ることを認識した。このことはファイブフォース分析の結果における 売手の交渉力の脅威にも大きな影響を及ぼすことに気が付き,ドライバーの需要に対 して供給が減ることから,| d|と考えた。 E課長は,これらの外部環境分析の結果を踏まをると,| b|競争の渦中にあ り,減収減益となっている現状において,OB社が業界内において競争優位を確立す るための分析が必要であると考えた。E課長は,その分析を実施した結果,B社は, 好立地にある営業所と倉庫をもっているにもかかわらず,そのことを生かして,多様 化する顧客の要望に応えられていないことが収益悪化の原因であると結論付けた。 E課長は,必要な分析を終えてその結果をD部長に報告した。 [顧客情報の定性的分析〕 E課長は,D部長から,運送・倉庫保管だけの物流サービスから,③マーケットイ ン志向の物流サービスに転換していくことによって,顧客に新たな価値を提供できる ー13一 | のではないかとアドバイスを受けた。E課長は,これまでの自社の顧客情報の分析は,| 受注履歴,契約金額などの数値を基に分析を行うことだけであり,数値だけでは捉え| きれない顧客の要望を把握する分析を行っていなかったことに気が付いた。| E課長は,顧客との接点が多いドライバーは,運送業務の過程で,顧客の事業に関| して様々な気付きを得ているのではないかと考えた。そこで,ドライバーのもつ願客| の事業に関する気付きを把握するために調査を実施した。ドライバーからの回答には,| 顧客の事業に関する未知の情報,B社に対する期待やクレーム,顧客に対する感想, 相対する顧客社員への好悪の感情といった顧客の事業に関する情報とそれ以外の種々 雑多な情報が混在していた。しかし,これまでは顧客情報として管理されていなかっ た様々な情報が含まれており,分析することで,顧客の要望を把握することができる のではないかと考えた。 ドライバーからの回答は,自由記述形式のテキストデータであり,テキストマイニ ングによる定性的分析を行うことができる。D BRI,テキストマイニングによる分 析を行うに当たり,テキストデータを選別するよう,E課長にアドバイスをした。 E課長は,選別したテキストデータの分析の結果,顧客の事業に関するキーワードと Lt,“コア業務","一括委託'といった単語が頻出しており,“コア業務′は集中" との単語間の結びつきの強さがあり,複数の単語が同一文章中に共に出現することを 意味する共起関係が強く表れていた。E課長は,定性的分析の結果をD部長に報告し, 顧客への新たな価値の提供に向けた検討の了承を得た。 [顧客への新たな価値の提供] B社が顧客の業務を確認したところ,B社倉庫から顧客の拠点に荷物が届いた後に, 顧客はその荷物の検品やタグ付け,複数の荷物を一つに箱詰めすることといった作業 を顧客社内で行うか,又はB社とは異なる事業者へ委託しており,顧客にとって負担 となっていた。B社では,昨年,業務効率の向上を図るために営業所と倉庫内のレイ アウト変更を実施し,新たな業務を行うことが可能なスペースを確保している。そこ で,E課長は,運送,倉庫保管といった従来の業務に加え,検品やタグ付け,箱詰め といった作業を行う流通加工業務を一括で受託して顧客に新たな価値を提供する3PL (3rd Party Logistics)サービスが有効ではないかと考え,D部長に提案した。D部 長は,3PLサービスを提供することで,B社の既存顧客の要望を満たすとともに,新 0= たな顧客の獲得につながる可能性もあると考え,E課長の提案に賛同した。さらに., D部長は,顧客が作業を委託している流通加工業者の一つであるR社において,流通 加工業務の需要拡大に伴い施設の拡張を検討しているという話を聞いていた。そこで, B社の営業所と倉庫を作業所として,B社の運送・倉庫保管業務とR社の流通加工業 務とを組み合わせてサービスする業務提携をR社と行うことで,BHO 3PLサービス の提供が可能になるのではないかと考えた。D Mild,E課長に,R社との業務提携 の可能性があるかを調査するよう指示した。 E課長は,顧客からR社の紹介を受けて,業務提携の協議を行った。R社との協議 を行う中でE課長はR社の状況を次のように把握した。 ・R社は流通加工業務の需要拡大に伴い,社員や作業所を増やし事業を拡大してきた が,作業所の多くは手狭になってきていて,別の作業所を探さなくてはならない。 ・流通加工業務は,荷物の受入れと発送をスムーズに行えることが重要であり,これ が作業所の選定上の最優先事項である。 ・希望する場所に作業所を自前でもつことは,作業所の土地の取得費や倉庫の建築費 といった初期費用の負担が大きいので,回避したいと考えている。 E課長は,B社の事業の概要を説明した上で,業務提携が可能であるか検討してほ しいとR社に依頼した。後日,R社から,⑤B社のもつつ経営資源は,R社の事業を展開 する上で魅力的なものであることから,是非とも業務提携を行いたいとの連絡があっ Tes E課長は,R社との業務提携による3PLサービスの事業化案についてD部長に報告 Lick.部長は,⑥E課長の事業化案を実現することで,B社の顧客の物流に関わる 作業に対する要望を満たすことができる,さらに,B社とKR社で業務提携することで 顧客を紹介し合って,相互に新たな顧客の開拓につなげられると判断した。D部長は, 収益向上によってドライバーの処遇を改善することも含めて(C取締役の承諾を得て, E課長に事業化案に基づき事業計画をまとめるよう指示した。

共通の文章

グラフのノード間の最短経路を求めるアルゴリズムに関する次の記述を読んで,設| 間に答えよ。| | グラフ内の二つのノード間の最短経路を求めるアルゴリズムにダイクストラ法があ| る。このアルゴリズムは,車載ナビゲーションシステムなどに採用されている。| | [経路算定のモデル化]〕 グラフは,有限個のノードの集合と,その中の二ニつのノードを結ぶエッジの集合と| から成る数理モデルである。ダイクストラ法による最短経路の探索問題を考えるに当 EY,本問では,エッジをどちらの方向にも行き来することができ,任意の二つのノ ード間に経路が存在するグラフを扱う。ここで,グラフを次のように定義する。 ・ノードの個数をNとし,Nは2以上とする。ノードの番号(以下,ノード番号とい う)は,始点のノード番号を1とし,1から始まる連続した整数とする。ノードに lt,ノード番号に対応させて,Vi,V2,V3,…,VNとラベルを付ける。 ・二つのノードが他のノードを経由せずにエッジでつながっているとき,それらのノ ードは隣接するという。隣接するノード間のエッジには,ノード間の距離として正 の数値を付ける。 ・始点のノード(以下,始点という)とは別のノードを終点のノード(以下,終点と いう)として定める。始点からあるノードまでの経路の中から,経路に含まれるエ ッジに付けられた距離の和が最小の距離を最短距離という。始点から終点までの最 短距離となる経路を最短経路という。 図1にノードが五つのグラフの例を示す。図1の例では,始点をVIのノードとし, 終点をV5のノードとした場合の最短経路は,Vi,V2,V3,V5のノードを順にたどる 経路である。 oO(ゅ (Nf 図1ノードが五つのグラフの例 ー18一 [始点から終点までの最短距離を求める手順〕 ダイクストラ法による始点から終点までの最短距離の算出は次のように行う。 最初に,各ノードについて,始点からそのノードまでの距離(以下,始点ノード距 離という)を作業用に導入して十分に大きい定数としておく。ただし,始点の始点ノ ード距離は9とする。この時点では,どのノードの最短距離も確定していない。 Ric,終点の最短距離が確定するまで,①ー③を繰り返す。ここで,始点との嘘離 を算出する基準となるノードを更新起点ノードという。 ①最短距離が確定していないノードの中で,始点ノード距離が最小のノードを更 新起点ノードとして選び,そのときの始点ノード距離の値で,当該更新起点ノー ドの最短距離を確定する。更新起点ノードを選ぶ際に,始点ノード距離が最小と なるノードが複数ある場合は,その中の任意のノードを更新起点ノードとして選 x, ②更新起点ノードが終点であれば,終了する。 ③①④で選択した更新起点ノードに隣接しており,DO,最短距離が確定していない 全てのノードについて,更新起点ノードを経由した場合の始点ノード距離を計算す る。ここで計算した始点ノード距離が,そのノードの現在までの始点ノード距離よ りも小さい場合には,そのノードの現在までの始点ノード距離を更新する。 〔図1の例における最短距離を求める手順と始点ノード距離〕 図1の例において,始点V1から終点V5までの経路に対して,上の①~て③を繰返し 適用する。そのとき,更新起点ノードを選ぶたびに,更新起点ノードの始点ノード距 at,更新起点ノードと隣接するノードの始点ノード嘘離,及び最短距離が確定してい ないノードの始点ノード距離を計算した内容を表1に示す。 表1 1の例における最短距離を求める手順と始点ノード距離 a Emm[e{>p[-|-| 注記1 INFは,定数で十分大きい数を表す。 注記2内の数値は,当該ノードの始点ノード距離を表す。 ー19一 | [最短距離の算出プログラム〕 始点から終点までの最短距離を求める関数distanceのプログラムを図2に示す。 配列の要素番号は1から始まるものとする。また.,行頭の数字は行の番号を表す。| | 1:〇整数型:distance()| 2:整数型:N/*ノードの個数*/| 3:整数型:INF/*十分大きい定数*/| 4:整数型の二次元配列:edge/*edge[m。n]には,ノードmからノードnへの距離を格納| ーーつのノードが隣接していない場合にはINEを格納*/| 5:整数型:GOAL/*終点のノード番号*/| 6:整数型の配列:dist/*始点ノード距離。初期値はINF。要素番号がノード番号を表す。*/| 7:整数型の配列:done/*初期値は0。最短距離が確定したら1を入れる。| 要素番号がノード番号を表す。*/ 8:整数型:curNode/*更新起点ノードのノード番号*/ 9:整数型:minDist/*更新起点ノードを求める際に使用する一時変数*/ 10:整数型:k/*要素番号*/ 11:dist{i]—0/*始点の始点ノード距離を9とする。¥/ 12:while(true) 13:minDist<INF 14:for(kを1からNまで1ずつ増やす) 15:if(done[k]が0かっ|ィ|) 16:minDist<— 1Z3 curNodeとk 18:endif 19:endfor 20:done[curNode]<1 21:if(curNodeがGOALと等しい) 20's return dist[curNode] 23%endif 24:for(kを1からNまで1ずつ増やす) 25:if(|エ|がdist[k]より小さいかつdone[k]が0) 26:dist[k]< 272 endif 28:endfor 29:endwhile 2 pee distanceのプログラム [最短経路の出力] 関数distanceを変更して,求めた最短距離となる最短経路を出力できるようにす る。具体的には,まず,ノード番号1Nを格納する配列viaNodeを使用するために, 図3の変数宣言を図2の行19の直後に,図4のプログラムを図2の行21の直後に, それぞれ挿入する。さらに,各ノードの始点ノード距離を更新するたびに,直前に経 由したノード番号をviaNodeに格納する①代入文を一つ,図2のプログラムの行 の直後に挿入する。 このプログラムの変更によって,終点のノード番号を起点として|カ|たど ることで,最短経路のノード番号を逆順に出力する。 整数型の配列:viaNode/*最短経路のノード番号を格納する。初期値は9。*/ 整数型:j/*要素番号*/ 図3最短経路を出力するために関数distanceに挿入する変数宣言 jでGOAL/*終点のノード番号*/ GOALを出力/*終点のノード番号の出力*/ while(」が1より大きい)/*最短経路の出力*/ viaNode[j]を出力 j<—viaNode[j] endwhi Le 図4最短経路を出力するために関数distanceに挿入するプログラム 〔計算量の考察] 関数distanceでは,次のを選ぶために始点ノード距離を計算する回 数は最大でもN回である。また,|キ|を選ぶ回数は,一度選ばれると当該ノ ードの最短距離は確定するので,最大でもN回である。よって,最悪の場合の計算量 lt,0(|ク|)でぁる。

共通の文章

CRM(Customer Relationship Management)システムの改修に関する次の記述を読 ATC,設問に答えよ。 C社は,住宅やビルなどのアルミサッシを製造,販売する中堅企業である。取引先 の設計・施工会社のニーズにきめ細かく対応するために,自社で開発したCRMシステ ム(以下,CRMシステムという)を使用している。CRMシステムは,データベースと Webアプリケーションプログラム(以下,Webアプリという)から成り,C社のLAN 上にあるPCから利用される。このたび,営業担当者が外出先からスマートフォンや ノートPCを用いてCRMシステムを利用できるようにするために,データベースは変 更せずにWebアプリを改修することになった。 (Webアプリの改修方針] Webアプリの改修方針を次に示す。 ・必要以上の開発コストを掛けない。 ・営業担当者が外出先で効率的にCRMシステムを利用できるように,スマートフォン に最適化した画面を追加する。 ・将来的に,CRMシステム以外の社内システムとも連携できるように拡張性をもたせ る。 (Webアプリの実装方式の検討] これらの改修方針を受けて,図1のWebアプリを実装するシステムの構成案を検討 しただ。 AP:アプリケーションサーバ FW:ファイアウォール用静的ファイルのWeb API に ーーテーしDB| Webサーバ 3 の社内システム DB:データベースサーバ 図1 Webアプリを実装するシステムの構成案 ー24一 検討したWebアプリの実装方式を次に示す。 ユーザーイシンタフェースとデータ処理を分ける。ユーザーイシタラウラェースは。Web サーバにHTML,Cascading Style Sheets(CSS),GR,スクリプトなどを静的な ファイルとして配置する。データ処理は,APがDBから取得したデータをJSON形 式のデータで返すWeb APIとして実装する。 ・ユーザーインタフェースとなる静的ファイルは,PCとスマートフォンそれぞれの Webブラウザ用に個別に作成し,データ処理用のWeb APIは共用する。 ・ユーザーインタフェースの表示速度を向上させるために,①静的ファイルを最適化 する。 〔実現可能性の評価〕 [Webアプリの実装方式の検討で示した方式の実現可能性を評価するために,TF ロトタイプを用いて多くのデータを扱う機能について検証した。その結果,スマート フォンの特定の画面において次の問題が発生した。 ・扱うデータ量が増えるに連れて,レスポンスが著しく低下する。 ・②スマートフォンのCPU負荷が大きく,頻繁に使用するとバッテリの消耗が激しい。 そこで,これらの問題の原因を調べるために,Webアプリの処理を分析した。レス ポンスの悪かった日誌一覧の表示画面を図2に,Web APIからの応答データを図3に 示す。 【日誌一覧】ユーザー名:情報太郎{ 取引先名:〇AX設計事務所"customer”:"〇AX設計事務所", “count”:16, "diaries":(<a 情報太郎("date":"2023-08-21", 当社の新商品のツのプレゼンを実施。従来の製"salesperson":"情報花子", 品に比べて軽量である点が高く評価された。…編集"salesprocess”:"問合せ", 情報花子|製品詳細説明“diary”:"(省略)"}, 商品展示場で興味をもっていただいた製品群に ついてエンジニアを同行させ,詳細な説明を…{"date”:"2023-10-04", 情報太郎|製品概要紹介"salesperson”:"情報太郎", 商品展示場にお招きLT,当社製品群をご紹介。"salesprocess”:"製品概要紹介", 予定の時間を大幅に超過して,熱心に質問…“diary”:”(省略)9 tae| 当社及び主力製品のご説明を実施会社案内へーー. の反応は少なかったが,主力製品の機能に関…) 2日誌一覧の表示画面3 Web APIからの応答データ スマートフォンのWebブラウザから図2の画面をリクエストしてから描画されるま での一連の処理について,処理ごとに所要時間を測定した結果を表1に示す。 表1処理ごとに所要時間を測定した結果 En 所要時間 |1|Webブラウザが画面に必要となる静的なファイルを全て受信する。 WebブラウザがWeb APIにリクエストして,図3の応答データを全て受信す る。 Webブラウザ内で日誌のデータを日付の降順にソートして,画面に表示する1時6 最大件数である4件目までを抽出する。 ‘日誌本文が42文字を超える場合,先頭から41文字に文字“…”を結合し= た42文字の文字列にする。 。日誌一覧の表示を実行したユーザーが作成した日誌か否かを判断して,本- 人が作成した日誌には"編集"ボタンを表示する。 |6|データをWebプラウザに摘画する。。。|5 |表1から,図3の応答データのスマートフォンへの転送処理と,Webブラウザ内で その応答データを加工する処理に多くの時間を要していることが判明した。 (Webアプリの見直し]〕 |Webブラウザが画面をりリクエストしてから描画されるまでの所要時間の目標値を3 |秒以内に設定して,それを達成するために,次の三つの方式を検討した。 |①スマートフォンのユーザーインタフェースをアプリケーションプログラム(以下 スマホアプリという)として開発して,そのスマホアプリ内でWeb APIからの応答 データを加工・描画する方式 ②リクエストのあった応答データのうち,Webブラウザに描画するデータだけを返 すWeb APIを開発して,スマートフォンのWebブラウザからそのWeb APIを利用す る方式 ③②で開発したWeb APIを①で開発したスマホアプリから利用する方式 各方式について,応答データを加工・描画するソフトウェア又はサーバと,TOR 現可能性を評価するために,設けた評価項目について整理した結果を表2にホす。各 評価項目の評価点に対する重み付けは均一とし,また,将来的な拡張性については各 —26 oe 実装方法を設計するタイミングで検討することにした。 なお,〔実現可能性の評価]においてプロトタイプを用いて検証した方式を方式⑤) とする。 表2整理した結果 fie i anaes |①|スマホアプリ|スマホアプリ|O|A|A|4m |@|Weプラッザ|mw|O|oO|O|em |@|スマボアプリ|AP|@|X|O|5京| att 凡例O:とても優れている,3点〇:優れている,2点 A:あまり優れていない,1点X:優れていない,OR [レスポンス時間の試算〕 表2の結果から,方式②について更に検討を進めることになり,そのレスポンスが 実用上問題ないか,表1を基に所要時間を試算した。 表1中のNo.2の所要時間について考える。方式⑦のWeb APIからの応答データの サイズは,3のデータのサイズの4分の1になり,サーバ側でのデータ転送には時 間を要しないものと仮定すると,No.2の所要時間は|a|ミリ秒となる。 次に,No.3~No.5の処理時間について考える。No.3の処理はDBで,No.4とNo.5 の処理はAPで行われる。処理時間は各機器のCPU処理能力だけに依存すると仮定す る。各機器のCPU処理能力は,スマートフォンが10,990MIPS相当,DBが40,QOOMIPS 相当,APが20,000MIPS相当の場合,No.3No.5の処理時間の合計は|pb|ミ リ秒となる。 以上の試算の結果,方式ので十分なレスポンスが期待できることから,方式②を採 用することにした。 a[システム構成の検討 方式⑦で開発したWeb APIの配置について検討した。図1のAP上に配置する案も Rat LED,③将来的な拡張性を考慮した結果,1のAPとは別に,スマートフォ ンやノートPCから呼び出されるWeb APIのためのAPを,新たに追加する構成にした。 ー27一 | | このシステム構成を採用した結果,問題を解消し,さらに将来的な拡張件をもたせ ることができた。

共通の文章

クラウドサービスを活用した情報提供システムの構築に関する次の記述を読んで, 設問に答えよ。 L社は,国内の気象情報を様々な業種の顧客に提供する企業である。現在は,社外 から購入した気象データを分析し,気象情報として提供している。今回,全国に設置 するlol機器から気象データを収集し,S社のクラウドサービス(LUE,S社クラウ ドという)で分析した結果を気象情報として提供する新しい気象情報システム(以下, 新システムという)を構築することになった。新システムの設計を,L社の情報シス テム部のMさんが担当することになった。 Mさんは,新システムの構成と,新システムが備えるべき主な機能を検討した。新 システムの構成案を図1に,新システムが備えるべき主な機能を表1に示す。情報提 供先のPC,IoT機器やL社の保守用PCから,S社クラウド上に構築された新システム の各機能に対応するサーバにアクセスして,必要な機能を利用する。 テー|1oT機器|…|or機器| データデータ情報Lat 収集用分析用提供用 サーバ||サーバ||サーバこインターネットつ 200.a.b.11 200.a.b.12 200.a.b.13 200.c.d.101 情報提供先||情報提供先 FW:ファイアウォールon wre 注記図中の209.x.x.xはグローバルIPアドレスである。 図1新システムの構成案 Hl新システムが備えるべき主な機能 データ収集機能|全国に設置したIoT機器から気象データを受信し,データ収集用サーバのデータベースに 蓄積する。データ収集用サーバにはデータ収集用のWeb API(LAK,データ収集APIとい う)があり,loT機器はデータ収集APIを利用して気象データを送信する。 データ分析機能|データ収集用サーバのデータベースに蓄積した気象データを定期的に処理して気象情報 を作成し,情報提供用サーバに保存する。 情報提供機能情報提供先からの要求に対して必要な気象情報を送信する。情報提供用サーバには情報 提供用のWeb API(LAR,情報提供APIという)があり,情報提供先のPC上のアプリケ ーションプログラム(以下,情報提供先アプリという)の情報提供APIを利用した要求に 対して気象情報を送信する。 Mさんが検討した新システムの構成について,情報システム部のN部長は次の検討 —30 aa を行うようにMさんに指示した。 ・IoT機器から送信される気象データの特徴を踏まえて,データ収集APTIに用いる通 信プロトコルを選定すること。 ・新システムにインターネットからアクセス可能な機器の数を最小限にするように S社クラウド上のFWに設定する通信を許可するルール(以下,FWの許可ルールと いう)の設計を行うこと。 ・将来,IoT機器の数や情報提供先の数が増加した場合に備えて,各機能の処理遅延 対策を行うこと。 〔データ収集APIに用いる通信プロトコルの検討〕 IoT機器は全国に10,000台設置する計画であり,通信事業者のLPWA(Low Power Wide Area)サービスを用いて各IoT機器から1件当たり最大599バイトの気象デー タを,1分どとに①データ収集用サーバに送信する設計とした。気象データは,1件 当たりのデータ量は少ないが,IoT機器からデータ収集用サーバへの通信回数が多く, データ収集用サーバヘアクセスが集中するおそれがある。そこで,データ収集APIに ld,通信の都度TCPPコネクションを確立して通信を行うHTTPDではなく,②TCP上で HTTPよりプロトコルヘッダサイズが小さく,多対1通信に対応するプロトコルを用 いることにした。 (FWの許可ルールの設計】〕 Mさんは,S社クラウド上のFWの許可ルールの設計方針を検討した。 ・IoT機器からデータ収集用サーバへのアクセスや情報提供先アプリから情報提供用 サーバへのアクセスに対しては,通信プロトコルの制限を行うが,インターネット の接続元IPアドレスによる制限は行わない。 ・L社の保守用PCから各サーバへのアクセスに対しては,各サーバにログインして 更新プログラムの適用などの保守作業を行うために,SSHだけを許可する。 ・各サーバからインターネットへのアクセスに対しては,ソフトウェアベンダーの Webサイトから更新プログラムをダウンロードするために,任意のWebサイトへの HTTPSだけを許可する。 ー31一 Mさんが検討した,FWの許可ルールを表2に示す。 表2 FWの許可ルール インターネット 注記1 FWは,応答パケットを自動的に通過させる,ステートフルパケットインスペクション機能 注記2 at最初に該当したルールが適用される。 【処理遅延対策の検討 Mさんは,IoT機器の数や情報提供先の数が現在の計画よりも増加した場合に,表 1の各機能の処理にどのような処理遅延が発生するか確認した。 IoT機器の数が増加した場合,全国に設置した1oT機器からS社クラウドのFWを経 由してデータ収集用サーバにアクセスする通信が増加する。また,情報提供先の数が 増加した場合情報提供先アプリから3S社クラウドのFWを経由して情報提供用サー バにアクセスする通信が増加する。 特に|d|については,データ収集機能の通信と情報提供機能の通信の両方 が経由することから,単位時間内に処理できる通信の量を表す|ce|と,同時 に処理できる接続元の数を表す|f|が,必要な性能を満たすよう管理するこ とにした。 また,データ収集用サーバと情報提供用サーバの性能を超えた要求が発生して,デ ータ収集APIと情報提供APIの両方に処理遅延が発生した場合の対策として,③スケ ールアウトによってシステムの処理性能を高めるために必要な機能を新システムで利 用することにした。 ー32— Mさんは指示された内容の検討結果をN部長に説明し,了承されたので,新システ ムの設計及び構築を進めることになった。

共通の文章

人事評価システムの設計と実装に関する次の記述を読んで,設問に答えよ。 K社は,人事評価システムを中小企業に提供するSaaS事業者である。現在は,契 約している会社ごとに仮想サーバを作成して,その中にデータベースを個別に作成し TWH,現在のシステムのUSやフレームワークのサポート期限が迫ってきたのを機 に,機能は変更せずにサーバリソース最適化を目的として,システムを再構築するこ どだした。 [人事評価システムの機能概要〕 人事評価システムの機能概要を表1に示す。 表1人事評価システムの機能概要 祝日管理|国民の祝日に加えて,創立記念日などの会社ごとの記念日を年月日で管理する。 従業員が入社した際,従業員番号を割り振り,配属先の部署及び入社年月日を登録 する。 評価者管理部署の管理者を評価者として登録する。1人の従業員が複数の部署を管理する場合 S|がある。管理者の評価者は,評価時に個別に設定する。 目標設定年度の始めに,その年度の目標を設定する。目標は複数設定することができ,重要 度や達成までの期間などを考慮して重み付けする。 ee年度の終わりに,その年度の実績を入力する。実績は,年度の始めに設定した目標 にに対して,実績内容や目標達成度を自己評価として記入する。 評価年度の終わりに,管理者は評価対象の従業員が設定した目標とそれに対する実績を 「評価して,評価内容や達成度合を記入する。 snag従業員の退職が決まると,その退職年月日と在籍期間を登録する。さらに,BBO 管理者や人事部が対象の従業員にヒアリングした退職理由を登録する。 退職分析 cope人事部の管理者が自社及び自社と同じ業種の退職者について,在籍期間と退職理由 を分析する。 [単二データベース・単一スキーマ方式の検討 データベースのリソースを最適化するために,会社ごとに個別に作成していたデー タベース及びスキーマを一つにまとめることを考える。検討したE-R図を図1に示す。 なお,再構築するシステムでは,E-R図のエンティティ名を表名に,属性名を列名 にして,適切なデータ型で表定義した関係データベースによって,データを管理する。 国民の祝日 会社番号会社番号祝日 会社名会社記念日祝日名 業種会社記念日名 会社番号 anes SHES Sees目標設定年度 従業員番号||BEES目標番号 従業員氏名| 。[see算理者番号 部署番号BRASS評価内容 入社年月日ーーーニニニニニニニー一一一eee mat ls “SHES SHES 従業員番号従業員番号 会社番号目標設定年度目標設定年度 従業具番号目標番号目標番号 在籍期間目標内容実績内容 退職理由目標の重み目標達成度 凡例注記属性名の実線の下線___は主キー, ーーー:1対1属性名破線の下線----は外部キーを示す。 >1S|属性名外部キーの破線を付けない。 >1 93|e主キーの実線が付いている属性名には, <>:多対多|属性名 1 E-R 図1を関係データベースに実装した際のSQL文を考える。 (1)指定された会社と年度における,国民の祝日と会社記念日の一覧を日付の昇順 に出力するSQL文を図2に示す。ここで『:会社番号′は指定された会社の会社番 号を,“BRIA”,“:年度終了日"は,それぞれ指定された年度の開始日,終 了日を表す埋込み変数である。 SELECT祝日AS日付,祝日名AS日付名 FROM国民の祝日 UNION ALL SELECT会社記念日AS Aft,会社記念日名AS日付名 FROM会社記念日 WHERE会社番号=:会社番号 mo会人id Bf 2国民の祝日と会社記念日の一覧を日付の昇順に出力するSLX (2)指定された管理者が評価する対象の従業員の一覧を部署番号,従業員番号の昇 順に出力するSQL文を図3に示す。ここで『:会社番号′と“:管理者番号”は,そ れぞれ指定された管理者の会社番号と従業員番号を表す埋込み変数である。 Eee FROM従業員EMP INNER JOIN#832 DEP ON EMP.会社番号=DEP.会社番号 AND EMP.会社番号=:会社番号 AND DEP.管理者番号=:管理者番号 DEP.MBBS,EMP.RASS 注記|<|]には,図2中の|c|と同じ字名が入る。 図3従業員の一覧を部賭番号,従業員番号の昇順に出力するSQL文 [単-データベース・単一スキーマ方式のレビュー〕 検討した単二データベース・単一スキーマ方式のレビューを受けたところ,次の指 摘とアドバイスを受けた。 ・指摘 この検討案は,サーバリソース最適化を実現することができるが,SQLインジェ クションの脆弱性が見つかってしまった場合多くの情報が濡えいしてしまうおそ れがある。 ・アドバパイスズ データベースは一つのまま,システム全体で共有するデータだけを格納する共有 用のスキーマと,①システム利用者の会社どとのスキーマに分ける方式にするとよ い。共有用のスキーマに作成した表は,会社どとのスキーマに対象の表と同じ名前 のビューを作成して照会できるようにすると,現在のシステムのSQL文への修正を 少なくすることができる。 〔単-データベース・個別スキーマ方式の検討] [単-データベース・単一スキーマ方式のレビュー〕のアドバイスを受け,複数の スキーマを作成して各スキーマに表とビューを配置する。検対したスキーマを整理し た結果を表2に示す。 ee 表2スキーマを整理した結果 2H,BORE|- 個別会社用Cxxx会社記念日,従業員,BS,目標,St, (xxxは任意の英|実績,評価,退職国民の祝日 数字) 次に,ビューを作成するSQL文について考える。 スキーマC001に国民の祝日ビューを作成するSOL文を図4に示す。 CREATE view[ce|(祝日,祝日名) AS SELECT祝日,祝日名 FROM| f| 図4国民の祝日ビューを作成するSQL文 [単二データベース・個別スキーマ方式のレビュー]〕 検討した単二データベース・個別スキーマ方式のレビューを受けたところ,ROH 摘を受けた。 ・システム利用者ごとに,利用するスキーマを指定するために,| g|表に |!|列を追加する必要がある。 ・表2の表とビューの配置のままでは②利用できない機能があるので,③配置を一部 見直す必要がある。 レビューで受けた指摘に全て対応することで,システムを再構築することができた。

共通の文章

業務用ホットコーヒーマシンに関する次の記述を読んで,設問に答えよ。 6G社は,業務用ホットコーヒーマシン(以下。コーヒーマシンという)を開発して いる。コーヒーマシンの外観を図1に,コーヒーマシンの内部構成を図Ic,コー ヒーマシンの主な構成要素を表1に,それぞれ示す。 <P? 制御部 ;||抽出部 ||| =~||bet || ューのSSs.cusカップ電年部 ご|い ンーこさミグ PN ny ith ep 図1コーヒーマシンの外観図2コーヒーマシンの内部構成 表1コーヒーマシンの主な構成要素 ・コーヒーマシン全体の制御及び状態管理を行う。また,カップの有無やサイズ, 制御部カップが空か否かを判定(QE,カップ判定という)するための画像認識を行 う。 an・制御部から指示された画面を表示する。 ・利用者がタッチした座標情報を制御部に通知する。 ・制御部から指示された分量のコーヒーを抽出し,コーヒー排出口から排出する。 ・開閉センサーをもち,開閉状態を0/1のデジタル信号で制御部に入力する。 ドア・ドアを閉じた状態でロックすることができるロック機構をもつ。ロック機構は, 制御部からの指示でロック及びロック解除ができる。ロック及びロック解除に掛 かる時間は無視できるほど小さいものとする。 -コーヒー排出口から排出されたコーヒーを受けるカップを置く場所である。 nus・カップ埋置部を撮影するカメラで,制御部からの指示で撮影を行い,制御部と共 ?有するメモリに画像データを書き出す。 [カップ判定の仕様 カップ判定は,利用者がドアを閉じた時に,カメラでカップ載置部を複数回撮影 して行う。カップ判定の結果一覧を,表2に示す。 表2カップ判定の結果一覧 カップのサイズ(大,中,小)が付加される。 [ドアの開閉状態の判定仕様 ドアの開閉センサーは,ドアが完全に閉じているときは9,それ以外は1を出力す る。非常に短い間隔で9と1とを交互に出力することがあるので,制御部のソフト ウェアは入力された値を19ミリ秒間隔で読み出し,4回連続で同じ値が読み出され たらドアの開閉状態を確定する。 [コーヒーマシンの動作概要〕 コーヒーマシンの動作概要を次に示す。 (1)電源が入ると,初期化処理を行う。初期化処理が完了したら待機中となり,カ ップをカップ載置部に置くように促す画面をタッチパネルに表示する。 (2)利用者がドアを開けて,購入したカップをカップ載置部に置く。 (3)利用者がドアを閉じると,カップ判定を行う。 (4)カップ判定の結果が“空カップあり"”となるので,カップのサイズを表す文字 と,確認ボタンで構成される画面をタッチパネルに表示する。 (5)利用者が確認ボタンにタッチすると,| a』|し,カップのサイズに応じた 分量のコーヒーを抽出してコーヒー排出口からカップに注ぎ込む。タッチパネル には,抽出中であることを示す画面を表示する。 (6)コーヒーの排出が終わると,ドアをロック人解除し,タッチパネルにカップの引 取りを促す画面を表示する。 (7)利用者がドアを開け,カップを引き取る。 (8)利用者がドアを閉じると,カップ判定を行う。 (9)カップ判定の結果が“カップなし"となるので,待機中に戻る。 ここで,カップ判定中に利用者がドアを開けた場合は,カップ判定を中止し,利 用者がドアを閉じるのを待つ。また,確認ボタンがタッチされる前に,利用者がド ー41一 | アを開けた場合は,カップ判定の結果を破棄して,利用者がドアを閉じるのを待つ。 カップ判定の結果が“カップあり"又は“BBWS”の場合,カップ判定の結 果に応じた適切な画面をタッチパネルに表示する。 〔制御部のソフトウェア構成〕 制御部のソフトウェアは,リアルタイムOSを用いて実装する。制御部の主なタス クの処理概要を表3に示す。| 表3制御部の主なタスクの処理概要 ・メインタスクから“HE”を受けると,カメラで複数回撮影を行い,得られた画像データを 用いてカップ判定を行った後。結果を"判定結果"でメインタスクに通知する。判定に掛か カップ判定る時間は,300ミリ秒以上500ミリ秒以下である。 ・カップ判定中にメインタスクから“Hub”を受けると,5ミリ秒以内にカップ判定を中止して“中 止完了"をメインタスクに通知する。カップ判定中以外で“中止”を受けたときは無視する。 ・メインタスクから“抽出"を受けると,抽出部を起動して抽出を開始し,抽出部から抽出終 sat了を受信するまで待つ。 ・抽出終了を受信すると,コーヒーの排出が終了したと判断し,抽出部を停止して“抽出完 T”をメインタスクに通知する。 rT・メインタスクから"画面表示′を受けると,指定された画面をタッチパネルに表示する。 ・利用者が確認ボタンに触れたことを検出すると,“確認”をメインタスクに通知する。 ・開閉センサーの出力を10ミリ秒周期で読み出し,確定したドアの開閉状態を保持する。 a・確定したドアの開閉状態が変化したら,“ドア開"又は“ドア閉"をメインタスクに通知する。 ,・メインタスクから“ロック”又は“Oy OBR"を受けると,ロック機構を操作して,ドア をロック又はロック解除する。

共通の文章

ダッシュボードの設計に関する次の記述を読んで,設問に答えよ。 Y社は,食品などを販売する店舗を経営する企業である。複数ある店舗では,商品 の販売状況や在庫状況に合わせて,割引率を設定したり,店舗間で在庫の移動を行っ たりしている。販売に関する情報は販売管理システムで管理しているが,状況をリア ルタイムで監視するには不向きであった。そこで,販売状況とそリアルタイムで監視で きるシステム(以下,ダッシュボードという)を開発することにした。 Y社では,商品ごとに商品分類を設定し,売上金額や販売数の集計に利用している。 Y社が扱う情報のデータモデル(抜粋)を図1に,ダッシュボードのイメージ(一部) を図2に示す。 店舗コード店舗コード商品分類コード 店舗名商品コード商品分類名 om 凡例店舗コード |テーブル名|__sy syy||店舗コード販売コード商品コード 項目名|ee販売コード商品コード商品分類コード 項目名リン販売日時単価商品名 <>:多対多|売上金額合計BUR単価 図1データモデル(抜粋) 時間帯ごと商品分類ごとの売上金額売上金額全体に対する店舗時刻ごと店舗ごとの売上金額推移 (FAごとの割合(FF) 3,000|Mi:RO:総菜O:肉類1%3,000 2,000 49%,0 2,000 1,000 3490 1,000 9 0」 7:00-8:00-9:00-10:00-11.00.MAM OBS OCH 8:00 9:00 10:00 11:00 12:00 —@AJE-@-BEA CE M2ダッシュボードのイメージ(一部) 販売状況や在庫状況はデータベースで管理する。データベースに新たな販売実績が 追加されたり,在庫数が更新されたりすると,その内容がダッシュボードに随時反映 ーーガオーー され,最新の情報が表示される。 Y社は,ダッシュボードの開発をZ社に依頼し,Z社はその設計に取り掛かった。 [ダッシュボードのクラスの設計〕 Z社は.ダッシュボードのクラスの設計を行った。設計したクラス図を図3に,表 示できるグラフの種類を表1に,主なクラスの説明を表2に示す。Controllerクラス は,システム全体の挙動を制御するクラスである。Viewクラスは,画面にグラフを 表示する機能をもつクラスである。グラフには複数の種類があるので,その種類ごと に,Viewクラスを|a|したクラスを作成する。Subjectクラスは,データベ ースが更新されたことをViewクラスのオブジェクトに通知するクラスである。図1 のデータモデル中のテーブルのうち,ダッシュボードで監視したい情報に関するテー ブルのそれぞれについて,Subjectクラスを|as|したクラスを作成する。以 下,Viewクラス,Subjectクラスを| 』|したクラスのオブジェクトを,それ ぞれViewオブジェクト,Subjectオブジェクトという。 <<Singleton>> Controller —instance —views[] —subjects[] +getInstance(_)Q. dbUpdated(テーブル名[J),|一軸の識別子 0..*ABC J OFテーブル名 moifyt) -viewst]©十set集計項目(集計項目[]d)= ee___Co]|immer eer) 十add0bserver(View V)Tc]—— = 折れ線グラフView ーープーでーーイーでーーー|画面表示更新()|||+画面表示更新())!一 本なデーだII 1‘ <ステレオタイプ>|一関連<==依存1| |hailedペーョジッション)を1{az !|一属性名。|集約0.…*多重度0以上|mene] ep|<ぐ-人体は抽象を意味する|ーー リー。-、下線は欧的を意味する。1 注記集計項目クラスの属性“軸の識別子"は,グラフの“縦軸",“MOR”などを一意に示す値である。 図3クラス図 表1表示できるグラフの種類 グラフの構成要素 棒グラフ横軸の項目,集計対象の項|横軸の項目について,任意の値の範囲で区切 目,分類り,集計対象の項目の値を縦棒で表現する。終 棒の値は,分類ごとに色分けし,それらを積み 上げて表示する。 円グラフ集計対象の項目,分類集計対象の項目について,分類ごとに集計し て,その割合を扇形の面積で表現する。 扇形は分類ごとに色分けして表示する。 折れ線グラフ横軸の項目,集計対象の項|横軸の項目について,任意の値の範囲で区切 目,分類り,集計対象の項目の値の推移を折れ線で表現 する。折れ線は分類ごとに分けて表示する。 表2主なクラスの説明 Controllerプログラムの流れを制御するクラス。データベースが更新されたときに,更新 されたテーブル名の配列を引数にして,dbUpdatedメソッドを呼び出す。 データベースにアクセスするためのクラス。 Subjectデータの更新をViewオブジェクトに通知するクラス。通知先は,addObserver メソッドで登録する。notify0bserversメソッドは,登録された全ての通知先 のnotifyメソッドを呼び出す。 Viewダッシュボードに一つのグラフを表示するクラス。グラフの軸や集計対象の項 目の情報を,集計項目オブジェクトの配列で保持している。notifyメソッド は,画面表示更新メソッドを呼び出す。画面表示更新メソッドは,対象に関す る集計を行い,画面の表示を更新する。 集計処理グラフを表示する際に必要になる,各種の集計の処理を実装したクラス。 [グラフの新規表示] 例えば,“時間帯ごと商品分類ごとの売上金額′"のグラフを新たに画面上に表示す る場合を考える。グラフの種類は棒グラフなので,棒グラフViewクラスのオブジェ クトを作成する。次に,①関係するSubjectオブジェクトのaddObserverメソッドを 呼び出す。その後,画面の初期表示のために,画面表示更新メソッドを呼び出す。 [グラフの表示内容更新] 店舗で商品が販売されると,販売管理システムが,データベースにレコードを追加 する。そのとき,ダッシュボードのControllerクラスに実装されているdbUpdated メソッドが呼び出されるように,システム間の連携が行われている。 Controllerクラスは,dbUpdatedメソッドが呼び出されると,更新されたテーブル に対応するSubjectオブジェクトのnotifyObserversメソッドを呼び出す。 notifyObserversメソッドは,そのオブジェクトが属性としてもつ配列viewsに格納 されている全てのViewオブジェクトのnotifyメソッドを呼び出す。notifyメソッド は,画面表示更新メソッドを呼び出す。Viewクラスの画面表示更新メソッドは |d|メソッドなので,例えば,“時間帯ごと商品分類ごとの売上金額”の場合 は| 。|]クラスに実装されたメソッドを呼び出す。 データのフィルタリング] Y社からの追加の要求で,集計結果をフィルタリングする機能を追加することにな った。例えば,“時間帯ごと商品分類ごとの売上金額"のグラフ上で,特定の商品分 類の表示箇所をマウスでクリックしたときに,表示されている全てのグラフについて 指定した商品分類で絞り込んだ結果を表示したい。そこで,絞込条件を取り扱うクラ スとして絞込条件クラスを導入し,次の改修を加えることで機能を実現することにし a ・絞込条件クラスは,属性として“テーブル名”",“HBA”,“絞込条件の値"をもつ。 例えば,商品分類で絞り込む場合は,テーブル名に“商品マスタ”,項目名に“商 品分類コード",絞込条件の値に“商品分類コードの値"が入る。 ‘Controllerクラスの属性に絞込条件クラスのオブジェクトを追加し,その属性に 条件を設定するためのsetFilterメソッドを追加する。 ・Viewオブジェクトが画面の表示を更新する際に,絞込条件のオブジェクトが引き 渡されるようにするために,SubjectクラスのnotifyObserversメソッドと,View クラスのnotifyメソッドのそれぞれについて,呼出しの⑨仕様を変更する。 ・集計処理クラスの処理で絞込条件を考慮して集計し,画面を更新する。 画面の操作が行われたら,Viewオブジェクトが絞込条件オブジェクトを生成し, ControllerオブジェクトのsetFilterメソッドを呼び出す。COR,全てのViewオ ブジェクトの画面表示更新メソッドを呼び出すことで,機能を実現する。 【過負荷の回避〕 設計レビューを実施したところ,次の点が指摘された。 ・販売管理システムが,データベースに販売実績のレコードを連続で追加すると,ダ ーー ッシュボードが過負荷になるおそれがある。 ・ーつのViewオプジェクトは|f|ので,1回の販 売実績の登録で,表示の更新が複数回発生してしまう。 そこで,Viewクラスの属性に“更新フラグ”を追加し,notifyメソッドでは画面 表示更新メソッドを呼び出すのではなく,“更新フラグ”を立てるようにした。また, “更新フラグ”を立てる処理とは別に,定期的に画面表示更新メソッドを呼び出す仁 組みを用意し,"更新フラグ"”が立っている場合だけ画面の更新処理を実行してから “更新フラグ”を降ろすようにした。

共通の文章

LoT活用プロジェクトのマネジメントに関する次の記述を読んで,設問に答えよ。 P農業組合が管轄する地域では,いちご栽培が盛んである。いちごは繁殖率が低く, 栽培技術の向上や天候不順への対応が必要である。P農業組合員のいちご栽培農家は 温度調節や給水などの栽培管理を長年の経験と勘に頼っていたので,一部の農家を除 いて生産性が低い状態が続いていた。そこで,数年前に生産性向上を目指してW社の lolシステムを導入した。LIoTシステムの主な機能は,次のとおりである。 ・栽培ハウス(以下,ハウスという)内外に環境計測用センサー(以下,Kセンサー という),温度調節や給水などを行う装置,装置に無線で動作指示する制御機器 (以下,$機器という)を設置する。 ・Kセンサーは,BE,湿度などの環境データを取得してS機器に送信する。 ・S機器は,受信した環境データと,S機器の動作指示を制御するパラメータ(以下, 制御パラメータという)とを基に,装置に温度調節や給水などの動作指示をする。 ・農家は,その日の天候及びP農業組合内に設置されたデータベース(以下,DBと WS)サーバに鞭積された過去の環境データを参考にして,より良い栽培環境にな るように,農家に配付されているタブレット端末を使って制御パラメータを変更で きる。 (SaaSを活用したlolの効果向上〕 IoTシステムの導入によって,ハウス内の温度や湿度などをコントロールできるよ うになった。しかし,大半の農家では,過去の環境データを分析して制御パラメータ を最適に設定することが難しかったので,期待していたほどの効果は出ていなかった。 そこで,P農業組合の0組合長はA社に支援を依頼した。A社は,ICTを活用した農作 物の生産性向上に資するデータ分析サービスをSaaSとして提供する企業である。A社 のB部長は,導入したIoTシステムの効果を向上させるために,AO SaaSを活用し て制御パラメータを自動的に変更するサービス(以下,本サービスという)の導入をE 提案しようと考えた。 A社のSaaSは,実装されたAIのデータ分析を最適化するためのパラメータ(以下, 分析パラメータという)を参照し,過去と現在の環境データ,及び外部気象サービス が提供する予報データを統合して分析する。本サービスでは,この分析結果から最適 ー59一 な制御パラメータを算出してS機器に送信し,制御パラメータを変更する。 提案に先立って,B部長は0組合長に,A社のSaaSにはW社のIoTシステムとの接 続実績がなく,またA社にはいちご栽培でのデータ分析サービスの経験がないので, 分析パラメータの種類の選定及び値の設定の際に,試行錯誤が予想されることを説明 した。さらに,B部長は,本サービスの実現に不確かな要素は多いが,導入を試して みる価値が十分あると伝えた。0組合長はこれらを理解した上で,本サービスの導入 プロジェクト(LAR,SaaS導入プロジェクトという)の立ち上げを決定し,OMAR 自身がプロジェクトオーナーに,B都長がプロジェクトマネージャになった。 B部長は,プロジェクトの目的を“農家が,本サービスを使っていちご栽培を改善 し,より良い収穫を実現すること"にした。なお,SaaS導入プロジェクトが完了し て本サービスが開始されるときの分析パラメータは,プロジェクト活動中にいちご栽 培に適すると評価された設定値とする。本サービス開始後,農家は,タブレット端末 から分析パラメータの設定をガイドする機能(以下,ガイド機能という)を使って設 定値を変更できる。その際,P農業組合は,農家がガイド機能を活用できるようにな る支援を行う。本サービスを導入したシステムの全体の概要を図1に示す。 (iA)【P農業組合】 [A社のSaaS) [W社のloTシステム】 [ハウス】|e einem|! !|給水装置|!|—|Seas eRe) 注記P農業組合のDBサーバに蓄積されたデータは,本サービス開始前にA社のSaaSに移される。 図1本サービスを導入したシステムの全体の概要 〔概念実証の実施〕 B部長は,①SaaS導入プロジェクトの立ち上げに先立って,概念実証(Proof of Concept LAR,PoCという)を実施することにした。PoCの実施メンバーには,A社 DS B部長のほかに,導入支援担当として(氏が選任された。C氏は,IoTシステム とのデータ連携機能の開発経験があり,また様々なデータ分析の手法を熟知していた。 P農業組合からは,いちご栽培の熟練者であるR氏が選任された。また,P農業組合 DS W社に,IoTシステムとARO SaaSとのデータ連携に関する支援を依頼した。 PoCの実施に当たって,P農業組合がいちご栽培の独自情報を開示すること,A社及 びW社が製品の重要情報を開示することから,3者間で| 』|を締結した。 PoCでは,IoTシステムが導入された農家で実際に栽培している環境の一部(以下, PoC環境という)を使うことにした。A社とW社が協力してIoTシステムとAHO SaaSとの簡易なデータ連携機能を開発し,P農業組合内に設置されたDBサーバに薔 積された過去の環境データを利用することにした。C氏が分析パラメータの種類の選 定と値の設定を担当し,R氏が装置への動作指示の妥当性を評価することになった。 PoCは計画どおりに実施された。TIoTシステムとAMO SaaSとのデータ連携は確認 され,分析パラメータの種類の選定と値の設定に基づく動作指示も受当であった。一 FC,R氏から,Kセンサーの種類を増やして糖度,BK,色づきのなどの多様なデ ータを取得し,きめ細かく装置を動作させたいとの意見が出された。これに対してC 氏は,Kセンサーの種類を増やすとデータ連携機能の開発規模が増え,DO,分析パ ラメータの種類の再選定が必要になると指摘した。 B部長は,PoCによって得られた本サービスの実現性の検証結果に加え,導入コス ト,導入スケジュールなどを提案書にまとめた。A社内で承認を受けた後,B部長は 0組合長にA社のSaaS導入提案を行って了承され,準委任契約を締結してSaaS導入 プロジェクトが立ち上げられた。 (SaaS導入プロジェクトの計画〕 SaaS導入プロジェクトには,PoCの実施メンバーに引き続き参加してもらい,A社 からの業務委託でW社も参加することになった。現在のIorTシステムに追加するKセ ンサーの種類の選定はR氏が中心になって進め,IoTシステムとA社のSaaSとのデー タ連携機能の開発,及び分析パラメータの種類の選定と値の設定はC氏がリーダーに なって進める。さらに,P農業組合の青年部からいちご栽培の経験がある2名が,Fil 用者であるいちご栽培農家の視点で参加することになった。0組合長は,この2名に ②R氏及びC氏と協議しながら分析パラメータの値を設定するよう指示した。 B部長は,プロジェクトメンバーとともにプロジェクト計画の作成に着手し,プロ ジェクトのスコープを検討した。SaaS導入プロジェクトには,二つの作業スコープ ー52一 がある。一つは,Kセンサーの種類の追加というW社側の作業スコープである。もう ーつは,Kセンサーの種類の追加に対応したデータ連携機能の開発及び分析パラメー タの種類の選定と値の設定というA社側の作業スコープである。この二つの作業スコ ープは密接に関連しており,VW社側の作業スコープの変更はA社側の作業スコープに 影響する。B部長は,まずPoCの実施結果を基に,PoC環境の規模から実際に栽培し ている環境の規模に拡張することを当初スコープにした。このスコープでサービスを 開発し,開発したサービスをプロジェクトメンバー全員で検証,協議した上で,開発 項目の追加候補を決めてスコープを変更する開発アプローチを採用することにした。 B部長は,この開発アプローチでは適切にスコープをマネジメントしないと③スコユ ープクリープが発生するリスクがあると危恨した。そこで,スコープクリープが発生 するリスクへの対応として,| b|及び|<|のペースラインを基に次 のスコープ管理のプロセスを設定した。 (1)追加候補の開発項目を,スコープとして追加する価値があるか否かをプロジェ クトメンバー全員で確認し,追加の可否を判断する。 (2)追加候補の開発項目を加えたスコープがベースラインに収まれば追加する。 (3)追加候補の開発項目を加えたスコープがベースラインに収まらず,スコープ内 の他の開発項目の優先順位を下げられる場合は,優先順位を下げた開発項目をスコ ープから外し,追加候補の開発項目をスコープに追加する。 (4)他の開発項目の優先順位を下げられない場合は,スコープが拡大してしまうの で,プロジェクトの品質を確保するため|b|及びのベースラ インの変更をプロジェクトオーナーに報告し,変更可否を判断してもらう。 次に,B部長は,本サービスは,Kセンサー,RB,S機器などの多種多様のIoT# 器,及びA社のSaaSで実現するシステムであることから,テスト項目数が多くなる と予想し,テストで着目する点を明確にして効率よくテストを実施すべきだと考えた。 PoCの実施環境,実施状況,及び実施結果を踏まえ,次のとおり着目する点を設定し てテストを実施することにした。 Ci)利用規模を想定して,IoT機器の接続やデータ連携に着目したテスト (ii)同一ハウス内で動作する複数の装置の競合に着目したテスト (iii)利用場所,利用シーンに着目したテスト (iv)システムやデータの機密性,完全性,可用性に着目したテスト ー53— 本サービスを『農業組合へ導入したことをもってプロジェクトは完了するが,農家 はいちごの栽培を続け,収穫によって導入効果を評価する。④B BRA,プロジェク トの完了時点では,プロジェクトの目的の実現に対する真の評価はできないと考えた。 そこで,B部長は,A社とP農業組合とで,これについて事前に合意することにした。

共通の文章

0テレワーク環境下のサービスマネジメントに関する次の記述を読んで,設問に答 えよ。 E社は,東京に本社があり,全国に3か所の営業所をもつ,従業員約209名の保険 代理店である。E社には,保険商品の販売や顧客サポートを行う営業部,入出金処理 や伝票処理を行う経理部,情報システムの開発や運用を行う情報システム部などの部 署がある。営業部の従業員(以下,営業員という)は,営業先に出向いて業務を行う ことが多く,その際の顧客サポートの質の向上が課題となっている。 E社の従業員には,ノートPCが一人1台貸与され,一部の営業員には,ノートPC とは別にタブレット端末が貸与されている。ノートPCやタブレット端末(以下,こ れらを社内デバイスという)では,本社内に設置しているサーバのアプリケーション ソフトウェア(以下,業務アプリという)と,電子メール送受信やスケジュール管理 を行うことができるグループウェア(以下,業務アプリとグループウェアを合わせて 社内IT環境という)の利用が可能である。社内デバイスは,社外から社内IT環境へ のネットワーク接続は行えない。 E社の情報システム部には,開発課と運用課がある。開発課は,各部署が利用する 社内IT環境の企画・開発を行う。運用課は,管理者のF RR,運用業務の取りまと めを行う6G主任及び数名の運用担当者で構成され,サーバなどのTT機器の管理だけ でなく,次のITサービスを提供している。 ・社内IT環境の運用 ・従業員からの問合せやインシデントの対応を受け付けるサービスデスク [社内IT環境とサービスマネジメントの概要〕 現在の社内IT環境とサービスマネジメントの概要を次に示す。 ・営業員は,社内IT環境から営業活動に必要なデータを,社内でタブレット端末に ダウンロードし,営業先ではタブレット端末をスタンドアロンで使用している。 ・社内デバイスの0S WRI,セキュリティ修正プログラムを含む05バージョンの アップデート(以下,0S8パッチという)を実施している。 ・0Sパッチを適用するには,社内デバイスのシステム設定で自動適用と手動適用の いずれか一方を設定する必要がある。現在は手動適用に設定している。 ー56一 ・0Sパッチを適用すると,社内デバイスで業務アプリを正常に利用できなくなるお それがある。そこで,OSパッチの展開管理に責任をもつ運用課は,OSパッチが公 開されると,まず,RRR OSパッチを適用した社内デバイスでテストを行い, 業務アプリを正常に利用できることを確認するように依頼する。業務アプリを正常 に利用できることを確認後,運用課から,従業員に社内デバイスを操作してOSパ ッチを手動適用するように依頼する。 ・従業員からの問合せやインシデントに対応するために,従業員が使っている社内デ バイスの操作が必要な場合がある。サービスデスクは,従業員が社内デバイスを利 用している場所が本社のときは対面でサポートを行い,営業所のときは電話でサポ ートを行っている。ただし,サービスデスクでは,電話でのサポートは時間が掛か るという問題を抱えている。 ・サービスデスクだけでインシデントをタイムリーに解決できない場合,開発課への | 。|を行うことがある。 [テレワーク環境の構築の計画〕 営業部の課題を解決するため,全ての営業員にタブレット端末を貸与し,社外から インターネットを介して社内IT環境に接続可能なテレワーク環境を,開発課が構築 し,運用課が運用することになった。なお,テレワーク環境は,当初はタブレット端 未だけの利用とするが,社会情勢の変化を受けて在宅勤務などで,ノートPCにも今 後利用を拡大する予定である。 テレワーク環境では,サービスデスクは,社外でタブレット端末を使う営業員から の問合せやインシデントに,営業所の場合と同様に,電話によるサポートで対応する。 [テレワーク環境の運用の準備] F課長は,テレワーク環境の運用の準備に着手した。 テレワーク環境の利用開始直後は,営業員から問合せが多発することやインシデン トの発生が想定された。F課長は,テレワーク環境の利用開始から安定稼働になるま での間は,開発課による初期サポートが必要と判断し,開発課に依頼して初期サポー ト窓口を開発課に設けることを計画した。ただし,開発課による初期サポートの実施 中は,問合せ先及びインシデントの連絡先を営業員自身が判断し,テレワーク環境に ー57一 ついては初期サポート窓口に,.その他についてはサービスデスクに対応を依頼するこ ととなる。F課長は,利用開始後のテレワーク環境に関する問合せとインシデントの 対応が|b|ことを,テレワーク環境の安定稼働の条件と考えた。また,初期 サポート窓口の設置は,テレワーク環境の利用開始後から4週間を目安とし,テレワ ーク環境に関する問合せとインシデントの対応が|b|ことを初期サポートの 終了基準とし,終了基準を満たすまで,初期サポート窓口を継続する。 サービスデスクは本来,機能的にSPOC(Single Point Of Contact)とするのが望 ましい。そこで,『課長は,①SPOCを実現する時期の判断のために,テレワーク環境 の問合せ対応に関して,初期サポートが終了するまでに開発課からme +,HA R-KhORYT RELL CTHUSNECHSLBAR.課長は,これらの計 画について営業部と開発課に説明して了承を得た。 次に,F BR,タブレット端末をもつ営業員が増え,また社外での利用機会が拡 大すること,及び今後ノートPCを利用した在宅勤務が予定されていることから,社 内デバイスの利用状況の管理を効率的に行う必要があると考えた。そこで,現状の人 手による管理に代えて,社内デバイスの利用状況を統合的に管理することができるツ ール(以下,統合管理ツールという)を導入することにした。F課長は,G主任に統 合管理ツールの調査を指示し,G主任は,統合管理ツールの機能と概要を表1にまと めた。 表1統合管理ツールの機能と概要 1|台帳管理社内デバイスのハードウェア情報,0S及び導入しているミドルウェアの バージョン情報を自動取得し,管理することができる。 2|操作ログ管理|社内デバイスへのログイン及びログアウト状況など社内デバイスの利用 状況を把握することができる。 3|リモート操作|統合管理ツールから社内デバイスをリモートで操作したり,ロックして 使用できないようにしたりすることができる。 4|パッチ適用配信用サーバを構築することで,社内デバイスの0Sに対して,OSパッチE を自動的に展開することができる。 G主任は,調査結果を『課長に説明した。F課長は,現在実施している0Sパッチの 手動適用では,従業員が0Sパッチの適用のタイミングをコントロールできてしまう ことから,0Sパッチの適用に不確実さがあることを問題視していた。「課長は,パッ チ適用機能を使うことで,展開管理としてOSパッチを確実に適用できると考えた。F 課長は,パッチ適用機能の実現には,テスト済みの0Sパッチを配信用サーバに登録 する手順の追加が必要となることを6主任に指摘し,検討するように指示した。そこ で,F課長は,.テレワーク環境の利用開始時点では,統合管理ツールのパッチ適用以 外の機能を使用し,②現在,サービスデスクで行っているサポートの問題を解決する wohe ly Fes [パッチ適用機能の使用〕 テレワーク環境の構築が完了し,営業員によるテレワーク環境の利用が開始された。 初期サポート窓口での対応は,終了基準を満たして,計画どおり4週間で終了した。 テレワーク環境はおおむね好評で,営業員のタブレット端末の利用頻度が上がり,タ ブレット端末による営業活動への効果が向上していた。一方で,以前から,営業部で は,運用課からの指示がないにもかかわらず0Sパッチを手動適用したり,指示した にもかかわらず手動適用を忘れたりして,社内デバイスで業務アプリを正常に利用で きないというインシデントが発生しており,現在も営業活動に影響が出ていた。 この状況を受けて,F課長は,“今後のインシデント発生を防止するという問題管 理の視点から有効でもるだけでなく,展開管理の視点からも有効である"と考えて, 早期にパッチ適用機能の使用を開始することにし,G主任にその後の検討状況の報 告を求めた。G主任は,展開管理の手順の検討結果を報告し,F課長は了承した。ま た,G主任は,パッチ適用機能を実現するためには,現在,手動適用の運用をしてい る社内デバイスの設定を変更する準備作業が必要となることを報告した。報告を受け た「課長は,準備が整い次第,パッチ適用機能を使用することを決定した。

共通の文章

支払管理システムの監査に関する次の記述を読んで,設問に答えよ。 V社は大手の製造会社であり,2年前に12年間利用していた自社開発の債務管理シ ステムから業務パッケージを利用した支払管理システムに移行した。そこで,内部監 査室は,支払管理システムの運用状況に関するシステム監査を実施することにした。 支払管理システム及び関連システムの概要〕 支払管理レステム及び関連システムの概要を図1に示す。 マスター登録・承認入力 調達管理システム支払管理システム会計システム マスターリ\データマスターリファイルUしデータデータデータ 図1支払管理システム及び関連システムの概要 (1)支払管理システムは業務パッケージの標準機能を利用し,約1年間で,企画, 要件定義,業務パッケージ選定,設計,開発,テスト及びリリースの各段階を経 て移行された。V社では,規程類に適合しない機能を採用する場合は,対応策を 含めて,リスク委員会の承認を受ける必要がある。 (2)会計システムは業務パッケージである。 (3)調達管理システムは,10年前に構築した自社開発システムであり,各工場製造 部の原料及び外注加工に関する見積依頼・発注・入荷・検収を管理している。検 収入力で作成される調達実績データは,半月ごとに支払管理レステムへ取り込ま れる。 (4)4年前に実施された債務管理システムのシステム監査では,規程類に適合した 機能が導入され,運用されていると結論付けられ,指摘事項はなかった。 (5)昨年実施された調達管理システムの監査では,取引先別の調達実績データの合 計額が支払管理システムの支払予定データの合計額と一致していないことが発見 された。これについて,調達管理システムには問題はなく,支払管理システムの ー62一 運用状況の詳細な調査が必要と結論付けられ,経理部で調査中とのことである。 〔支払管理システムの運用の概要〕 監査担当者が予備調査で把握した内容は,次のとおりである。 (1)支払管理システムでは,業務パッケージの標準機能である利用者ID情報管理機 能及びパスワード管理機能を利用している。承認された利用者ID申請書が情報シ ステム部サポート担当に提出され,利用者ID情報が登録,変更,削除される。利 用者ID情報には,利用者ID,利用者名,BBA,各メニューの利用権限などが 含まれ,登録・変更・削除履歴は利用者ID更新ログに記録される。業務パッケー ジのパスワードポリシーの一部には,規程類に適合するようにパスワードポリシ ーを適用できない箇所があった。 (2)支払管理システムに関連するプロセスは,次のとおりである。 ①経費精算などは,支払管理システムに支払申請入力を行い,承認者が承認入力 を行うことで支払予定データが生成される。支払予定データは修正できないので, 支払額を減額したい場合は,減額の支払申請を入力する。 ②支払規程によると,支払金額が一定額を超過する場合には,事業本部長の承認 及び担当役員の承認が必要になる。支払管理システムには,一つの申請に対し複 数の承認者を設定する機能がないので,承認入力後に承認者から必要な上位者に 経理部宛のCCを含む電子メールで承認を受ける手続としている。 ③支払申請入力では,請求書・領収書などの証ひょう類を承認者に回付せず,申 請者が入力後に経理部に送付する。経理部は,支払予定データについて一定額超 過の承認メールを含む証ひょう類に不備がないかチェックする。経理部は,証ひ ょう類に不備のある支払予定データについて,未承認の状態に変更することがで き,その場合は,申請者に電子メールで通知される。また,各工場管理部は調達 管理システムの調達実績データについて,取引先からの請求書とチェックしてい る。 ④調達実績データから支払予定データを生成するには支払先マスターに調達連携 用の支払先(以下,調達用支払先という)を登録しておく必要がある。調達用支 払先は,調達管理システムに関する支払業務以外では利用しない。 ー@= ⑤支払管理システムでは,半月ごとの調達実績データの取込処理によって,支払 予定データが生成される。取込処理の実行時にエラーがあった場合は,情報シス テム部でエラー対応を行う。一方,エラーではないが支払先マスターに調達用支 払先が未登録などの場合は,保留ファイルに格納される。経理部は保留ファイル に対し,支払先マスター登録などの対応後に保留ファイルの更新処理を実行する ー連の作業を行う。 ©原料・外注加工費は半月ごとに支払が行われるので,調達管理システムでの検 収入力が遅れ,次回の取込処理となってしまうと支払遅延となる。そこで,支払 遅延とからないように工場製造部の申請に基づき,工場管理部は,当該取引先に 対応した調達用支払先を利用して追加の支払申請入力を行う。また,次回の取込 処理までに重複防止のための減額の支払申請入力が必要となる。 ⑦経理部は,作業が完了した支払予定データに対して振込データ作成画面で対象 範囲を指定して,銀行に送信する振込データを作成する。 監査手続の作成 監査担当者が,予備調査に基づき策定した監査手続案を表1に示す。 表1監査手続案(抜粋) 録,BE,削除される。書の内容と利用者ID情報が一致しているか確かめる。 は,適切に設定される。程類に準拠しているか確かめる。 実績データによって適切|.調達実績データの取込処理が漏れなく実行され,エラーが に作成される。発生した場合は適切に対処されているか確かめる。 データは,適切に承認さかめる。 れる。・支払申請が未承認で残っていないか確かめる。 成される。クしているかを確かめる。 ー64一 内部監査室長は表1をレビューし,次のとおり監査担当者に指示した。 (1)表1項番2の監査手続は,予備調査の結果を踏まえると不備が発見される可能 性が高い。これに対応する追加手続として,| a|段階で|b|が行 われていたかどうかについての監査手続を含めるべきである。 (2)表1項番3の監査手続だけでは,監査要点を十分に評価できない。 に対する作業について評価する監査手続を追加すること。 (3)表1項番4の監査手続だけでは,監査要点を十分に評価できない。支払金額が | 』|の支払予定データについては,監査手続を追加すること。 (4)表1項番5について,支払予定データに対して経理部の|”e|が振込デー タ作成前に完了していることを確かめる監査手続を追加すること。 (5)昨年度のシステム監査での発見事項については,表1の項番|「|で確か めている。TO,差異が発生する可能性のある次の二つの事象に関する監査要 点及び監査手続を追加すること。 ①調達管理システムと異なる支払申請入力において,間違って|sg|を 利用してしまった。 ②支払遅延防止として追加の支払申請入力した後に,。|h|を行わなかっ た。