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

共通の文章

ECサイトの利用者認証に関する次の記述を読んで,設問1ー4に答えよ。 M社は,社員数が200名の輸入化粧品の販売会社である。このたび,M社では販 路拡大の一環として,インターネット経由の通信販売(以下、インターネット通販 という)を行うことを決めた。インターネット通販の開始に当たり,情報システム 課のN課長を責任者として,インターネット通販用のWebサイト(以下,M社EC サイトという)を構築することになった。 M社ECサイトへの外部からの不正アクセスが行われると,インターネット通販事 業で甚大な損害を被るおそれがある。そこで,N課長は,BRO C主任に,不正ア クセスを防止するための対策について検討を指示した。 [利用者認証の方式の調査 N課長の指示を受けたC主任は,最初に,利用者認証の方式について調査した。 利用者認証の方式には,次の3種類がある。 (i)利用者の記憶,知識を基にしたもの (ii)利用者の所有物を基にしたもの (ii)利用者の生体の特徴を基にしたもの (ii)には,[a|による認証があり,Gi)には,|b|による朗証 がある。(ii),(ii)の方式は,セキュリティ面の安全性が高いが,①多数の会貞獲 得を目指すM社ECサイトの利用者認証には適さないとC主任は考えた。他社のEC サイトを調査したところ,ほとんど(i)の方式が採用されていることが分かった。 そこで,M社ECサイトでは,(i)の方式のーつであるID,パスワードによる誰証 を行うことにし,ID,パスワード認証のリスクに関する調査結果を基に,対応策を 検討することにした。 (ID,パスワード認証のリスクの調査 ID,パスワード認証のリスクについて調査したところ,幾つかの攻撃手法が報告 されていた。パスワードに対する主な攻撃を表1に示す。 ot os os Rlパスワードに対する主な攻撃 i Co)see IDを固定して,パスワードに可能性のある全ての文字を組み合わ ーせてログインを試行する攻撃 P 4 a ecパスワードを固定して,IDに可能性のある全ての文字を組み合わ こせてログインを試行する攻撃 利用者の個人情報などからパスワードを類推してログインを試行 MM字列などでログインを試行する放撃 辞書や人名録などに載っている単語や,それらを組み合わせた文 セキュリティ強度の低いWebサイト又はECサイトから,IDとパ 5 Coa)xードのリストを作成し,リストを用いて,ほかのサイトへのログ スワードが記録されたファイルを和憲取して,解読したID,パスワ インを試行する攻撃 表1 HOWE 1~4の攻撃に対しては,パスワードとして設定する文字列を工夫す ることが重要である。項番5の攻撃に対しては,MHECサイトでの認証情報の管理 方法の工夫が必要である。しかし,他組織のWebサイトやECサイト(以下,他サ イトという)から流出した認証情報が悪用された場合は,M社ECサイトでは対処で きない。そこで,C主任は,M社ECサイトでのパスワード設定規則,パスワード管 理策及び会員に求めるパスワードの設定方法の3点について,検討を進めることに Lye. [パスワード設定規則とパスワード管理策] 最初に,C主任は,表1中の項番1,2の攻撃への対策について検討した。検討の TR,パスワードの安全性を高めるために,M社ECサイトに,次のパスワード設定 規則を導入することにした。 ・パスワード長の範囲を10て20桁とする。 ・パスワードについては,英大文字,英小文字,数字及び記号の70種類を使用可能 CL,英大文字,英小文字,数字及び記号を必ず含める。 次に,C主任は,M社ECサイトのID,パスワードが袖取・解析され,表1中の 項番5の攻撃で他サイトが攻撃されるのを防ぐために,M和社ECサイトで実施するパ スワードの管理方法について検討した。 —5 a 一般に,Webサイトでは,パスワードをハッシュ関数によってハッシュ値に変 換(以下,ハッシュ化という)し,平文のパスワードの代わりにハッシュ値を秘密 認証情報のデータベースに登録している。しかし,データベースに登録された誰証 情報が流出すると,レインボー攻撃と呼ばれる次の方法によって,ハッシュ値から パスワードが割り出されるおそれがある。 ・攻撃者が,膨大な数のパスワード候補とそのハッシュ値の対応テーブル(以下,R テーブルという)をあらかじめ作成するか,又は作成されたRテーブルを入手す る。 ・袖取したアカウント情報中のパスワードのハッシュ値をキーとして,Rテーブルを 検索する。一致したハッシュ値があればパスワードが割り出される。 レインボー攻撃はオフラインで行われ,時間や検索回数の制約がないので,パス ワードが割り出される可能性が高い。そこで,C主任は,レインボー攻撃によるパス ワードの割出しをしにくくするために,③次の処理を実装することにした。 ・会員が設定したパスワードのバイト列に,ソルトと呼ばれる,会員ごとに異なる 十分な長さのバイト列を結合する。 ・ソルトを結合した全体のバイト列をハッシュ化する。 ・ID,ハッシュ値及びソルトを,秘密認証情報のデータベースに登録する。 〔会員に求めるパスワードの設定方法] 次に,C主任は,表1中の項番3,4及び5の攻撃への対策を検討し,次のルール に従うことをM社ECサイトの会員に求めることにした。 ・会員自身の個人情報を基にしたパスワードを設定しないこと ・辞書や人名録に載っている単語を基にしたパスワードを設定しないこと ・④会員が利用する他サイトとM社ECサイトでは,同一のパスワードを使い回さ ないこと C主任は,これらの検討結果をN課長に報告した。報告内容と対応策はN課長に 承認され,実施さきれることになった。 ー6一

共通の文章

ホテルチェーンのビジネスコンセプトに関する次の記述を読んで,設問1ー5 KA えよ。 D社は,国内でビジネスホテルチェーンを展開している業界大手企業である。D社 が運営するホテルのビジネスコンセプトは,次のとおりである。 ・都市のターミナル駅の徒歩圏内に,150~200部屋の中規模ホテルを展開する。 ・ターゲット顧客は,低価格志向の出張客及び観光客とする。 ・ホテルの1階に直営レストランを併設する。 ・ITを活用したサービス向上と,低コスト運営を目指す。 ホテル業界全体は,訪日外国人旅行者の増加で業績が伸びているが,D社は競合ホ テルの低価格戦略の影響を受け,ここ数年の利益は頭打ちとなっている。そこで,D 社経営企画部では,利益を増大させることを目的に,事業戦略立案チームを発足さ せて,これまで自社では手掛けていなかった形態のホテル事業の検討すすることに した。 [D社のファイブフォース分析と課題 チームリーダに任命された経営企画部X BRS,自社の特徴,課題,及び収益構 造を把握するために,ファイブフォース分析を行い,ホテル業界におけるD社が受 ける困威を表1に整理した。 表1 D社が受ける脅威 の脅威い。顧客獲得競争が消耗戦になることが危恨される。 レー ウ|代替サービスの脅威|価値の代替サービスが現れた場合,顧客はそちらへ流れる懸念が ある。 =go= ホテル業界では,新規開業時に掛かる多額の初期投資を,確実に回収することが 課題である。代替サービスの脅威及び顧客の交渉力の脅威に対しては,低価格なだ けではなく,付加価値の高いサービスを提供することが課題である。供給業者の交 渉力の脅威は,現在の仕入価格交渉力を維持できれば大きな問題はない。 X部長は,これらの課題を踏まえて,初期投資と運営コストを抑えた新しい形態の ホテル事業の検討に着手した。 [企業が所有している保養所の実態 新しい形態のホテル事業を検討している中,X部長は,D社の大口顧客の企業経営 者から,多くの企業が自社の保養所運営で問題を抱えていることを耳にした。企業 の保養所は,従業員福利厚生制度の一環として設けられてきた。従業員とその家族 などが,年間を通じて1泊2食付きで3,4千円台で利用できるので,かつての利用 実績は高かった。しかし,近年,①余暇に関する個人の価値観の変化,及び海外旅 行が手軽になったことから,利用者数は大きく減少し,企業の重答になっている。 温泉地で有名なC市では,半径1 km以内の近隣エリアに十数社の保養所が点在し ている。築年数を経た品の良いたたずまいの建物,30年ほど前の好況期に建てられ た高級感のある建物など,それぞれに独自の魅力がある。一方で,隣接する昔なが らの商店街では,地元の名産品を提供する飲食店,土産物屋が細々と営業している。 〔保養所を活用した観光ホテル事業の提案] D社にとって,新たな形態のホテル事業として観光ホテル事業に進出する場合は新 規の参入となり,②その参入障壁を越えなければならない。また,大日顧客の企業 経営者の話から,観光地に保養所を所有する企業(以下,所有企業という)は,長 年黙認してきた保養所の運営コストを削減したいと考えていることが分かった。 X部長は,所有企業と提携し,保養所を活用した観光ホテル事業を考えた。また, 地元の役所,観光組合,商店街と協業して地域を活性化することで,ホテルの集客 力を高めようと考えた。事業戦略立案チームは,X部長の考えを具体的に進めるため に,C市に立地している保養所の現在の運営コストを分析して観光ホテル事業の収支 を試算し,所有企業に対して次の提案をした。 ・D社は,所有企業から土地と建物を借り,保養所の経営及び運営全般を受託する。 ーg一 ・D社は,施設修繕費などのランニングコストを全額負担する。 ・D社は,各保養所での売上の一定料率を,賃借料として各所有企業に避元する。、 ・観光ホテルとして,所有企業の従業員などのほかに一般宿泊客も受け付ける。 ・所有企業の従業員は,現行の保養所の料金のまま一般宿泊客よりも優先的に予約 できる。さらに,他社の魅力的な保養所も他社の保養所の料金で利用でき,楽し みが増える。 この提案を実行することによって,D社は,これまで培ってきたホテルの運営ノウ ハウを生かして利益を増大させ,観光ホテルのチェーン化の足掛かりにすることが CxS,Kk,所有企業は,売上の還元などによって保養所の運営コストを削減で きる。さらに,従業員福利厚生制度を維持したまま,自社の保養所の運営業務から も解放される。 D社の提案は,最終的にC市に保養所を所有する企業8社に受け入れられた。そ の後,D社は,地域の活性化に向けて,地元の役所,観光組合,MGC ORAS 開始した。 〔観光ホテル事業のビジネスコンセプト〕] X部長は,観光ホテル事業のビジネスコンセプトを,次のとおり整理した。 ・近隣エリアの複数の保養所を一つのホテル組織として一体化し,運営する。 ・一般宿泊客は,1泊2食付きで9,000円の年間均一料金とする。 ・D社の既存のビジネスホテルチェーンで使用している宿泊予約システムを一部機能 追加しての導入,各部屋へのタブレット端末設置など,ITを活用した使い勝手の 良いサービスを提供する。 D社の提案とこれらのビジネスコンセプトによって,③所有企業の従業員に対して Ik,値段.サービスなどの機能的価値とは異なる,新たな感情的価値を提供できる。 一般宿泊客に対しては,低価格で付加価値の高いサービスを提供できる。また,HK 給業者に備品などをまとめて発注することで,仕入価格交渉をこれまで以上に有利 に進めることが期待できる。 飲食は観光地のアピールポイントの一つであるが,DMR SEBRO-VDCHS 代替サービスとはあえて争わない。ホテル内で調理して提供するのは朝食だけにし て,宿泊客に商店街の飲食店の食事券と土産物屋の割引券を渡し,夕食時には地元 ー10一 の商店街へ足を運んでもらう。④これには,D社の飲食関連コストの上昇を抑制する こと以外の狙いもある。 X部長は,保養所資産の有効活用と徹底的なコスト削減,及び高い客室稼働率・リ ピート率の確保によって,2年間で観光ホテル事業を黒字にすることを目標にした。 〔複数の保養所を一体化した運営の課題と施策の検討〕 複数の保養所を一体化して運営する上での課題は,顧客に対するサービスの品質 を低下させないことと,人件費全体の縮小である。支配人,部門長などの管理職は 自社の既存ホテルから配置できるが,宿泊客の増加が予想されるのでスタッフ職従 RA(以下,スタッフという)が不足する。そこで急務となる新たなスタッフの確 保と教育に対して,XX部長は次の施策を考えた。 ・スタッフの募集を地元の役所に支援してもらう。 ・スタッフ業務の経験がなくても短期間で就労できるように,業務を標準化すると ともに,スタッフ向け研修を整備する。 ・スタッフ業務遂行基準を作成する。各自が管理職と話し合って設定した目標値を 達成したスタッフに対する厚骨制度を設けて,スタッフのモチベーションを上ばげ る。 支配人と部門長は近隣エリアの複数の保養所を管理し,当初,スタッフは各保養 所に固定で配置する計画であった。その後の検討によって,スタッフの乏働予定及 び実績を管理するスタッフ稼働管理システムを導入し,保養所ごと,時間帯ごとに スタッフの繁閑具合を可視化することにした。⑤このシステムの導入によって,顧 客の予約状況からスタッフを配置するよう計画を見直すことができる。

共通の文章

券売機の注文の状態を判定するプログラムに関する次の記述を読んで,設問1~3 に答えよ。 T社では,U社が経営する飲食店の店舗に設置する券売機のシステムを開発してい る。U社が店舗で提供する商品には,丼物や定食などのメイン商品のほか,みそ汁や サラダなどのサイドメニューがある。 U社では,特定の種類の商品を組み合わせたものをセットメニューとし,単品で注 文した場合よりも安く提供している。 [食券購入時の要件] 食券購入時の主な要件を図1に示す。 [食券購入時の操作の流れ] ・利用者は,券売機の画面上に表示されるボタンを押すことで食券を購入する。 ・食券の購入は1名ずつ行う。 ・利用者は,購入したい全ての商品を指定後,合計金額を投入し,発券ボタンを押す。 [メニューの構成 ・商品はメイン商品,サイドメニュー1,サイドメニュー2,オプションに分類される。商品に Ik,サイズやドレッシングの種類など,オプションの指定が必須なものがある。 ・メイン商品は必ず1品注文する必要がある。サイドメニューの注文は任意である。 ・メイン商品1品に対し,サイドメニューは複数注文することができる。 ・券売機の画面は,。メイン商品の選択画面,サイドメニュー1の選択画面.,サイドメニュー2の 選択画面の順に有居移する。サイドメニュー1を注文しない場合は,サイドメニュー1の選択画 面での注文をスキップできる。オプションは,オプションの指定が必須の商品の選択画面で 指定できる。 [発券ボタンの制御] ・発券ボタンはメイン商品の注文後,任意のタイミングで押すことができる。ただし,オプシ ョンの指定が必須な商品でオプションが未指定の場合は,押すことができない。 [セットメニューの値引きのルール〕 ・セットメニューに適用できるメイン商品,サイドメニュー1,サイドメニュー2を,それぞれ 1品以上選んだ場合,50円値引きする。値引きは食券購入ごとに1回だけ適用される。 図1食券購入時の主な要件 商品と分類の具体例を表1に示す。表1中のNは分類番号,Sはセットメニュー への適用可否,0Oはオプションの指定に関する情報である。Sは1のものがセットメ ニューへの適用可の商品である。分類番号1て3で,Oが0以外のものは,オプショ ンの指定が必須であることを示し,Oの値は,分類番号4のOの値と対応している。 オプションを指定する際には,Oの値が一致するオプションだけが選択できる。 表1商品と分類の具体例 [ems INlslo|me|2m INwlslol am - “[ae[a[a[ol wo[me[efi fol wl |-|-|-|-|-[#8|2lolo|eo| |=[-|-[-[-[aa[efolo[z| pases[os|』| [ais INISlo|wm|績mlslol wm| pact|3|ilo|6|並|4lolil|ol we,しFlslele|10[emo Ta[o fa|00| "[a7[a[a[o[0[me fa fo fi[20| |=[-[-[-[-|ドッシタ|4|ol2|o| |=|-|-|-|-|生ドレッシッタク|4|ol2|6| [注文の状態の判定手順] 券売機は,画面上で商品を選択するボタンが押されるたびに,商品の情報を蓄積 する。そして,蓄積した商品の情報を用いて状態遷移を初期状態から評価し直し, 注文の状態を判定する。状態の判定には図2の状態乱移園を用いる。初期状態は0 である。表1のN,S,Oを左から順に並べた3桁の数をイベントコードと呼び,イ ベントコードの値によって状態の遷移先を制御する。 | サイド1(212) メインァションサイド1、サイド2凡例 NO(9212)O26”ste.a oe(a)発券不可の状態 K)と (200)サイド2(300,310)サイド2(300)(イベントコード) :商品の分類名 注記1 nは状態番号を表す。 注記2メイン,サイド1,サイド2は,それぞれメイン商品,サイドメニュー1,サイドメニュー2を表す。 注記3複数のイベントコードで同じ状態遷移をする場合,イベントコードをカンマで区切って表記する。 図2注文の状態遷移図 状態の判定処理では,商品の情報を入力された順に取得し,状態遷移図に基づい て状態須移を評価する。例えば和牛丼,大盛り,濱物を注文した場合,状態は0,1,2, 4の順に居移する。この場合,最後の状態が発券可の状態なので,発券ボタンを押す ことができる。また,値引きのルールの条件を満たさないので,値引きはしない。 [状態遷移表] 状態遷移図をプログラムとして実装するためには,状態遷移図を状態遷移表にし て取り扱う。注文の状態遷移表を表2に示す。表2は,状態番号とイベントコード の組合せの表であり,表の各マスには居移先の状態番号と,乱移の際の値引きの金 額が入る。 例えば,Bl 2で状態が2のときに漬物の注文が入ると状態4(CEBU,値引きは 発生しないので,表2では,状態番号が2でイベントコードが210のマスには4:0 が入る。乱移後の状態が発券可の状態なので,発券ボタンを押すことができる。 表2注文の状態乱移表 [0|20liolgolgmolgiolgolg:olgiolgo|fase| しにュgolgolgielgiolsiolgiolEolsiols:o|tase| n|_2 lgiolgiol2ol4olsiols5iol5iolgiolgio|true_ ls lmolmelmelselmelselselmelseビ| 8)[eo[evo[oo[oo[EZ]40[see0[eo[woo[ee |5|e:0[8:0]e:0|b:0[e:0[5:0]5:0]E:0]E:0]true| 注記1各マスには,“BBAOREBS:値引きの金額”が入る。 注記2 Eは想定しない居移であることを意味する。 〔券売機の注文の状態を判定するプログラム〕 券売機の注文の状態を判定するプログラム(以下,判定プログラムという)を作 成した。判定プログラムは,画面上で商品を選択するボタンが押されるたびに実行 される。注文の状態を判定する手順を図3に示す。判定プログラム中で利用する主 な変数,定数及び関数を表3に,作成した判定プアログラムを図4に示す。 (1)状態番号を0,注文金額を0,値引金額を0として初期化する。 (2)注文された商品を先頭から順に一つ参照し,商品の金額を注文金額に加算する。 (3)注文された商品のイベントコードを算出する。 (4)状態遷移の際の値引きの金額を取得し,値引金額に加算する。 (5)状態遷移表を参照し,現在の状態番号とイベントコードから次の状態番号を取得して,状態 番号を更新する。 (6)(5)で取得した次の状態番号がEだった場合は,エラー終了として処理を中断する。 ⑦)未処理の注文が残っていれば(2)に戻って次の商品を処理する。 (8)状態遷移表を参照し,発券の可否を判定して,発券ボタンの状態を変化させる。 M3注文の状態を判定する手順 表3判定プログラム中で利用する主な変数,定数及び関数 status table[stat][ev]|配列表2の注文の状態遷移表を格納した2次元配列である。stat は遷移前の状態番号,eyはget_event index()で取得する値又 はACCEPT INDEXである。 配列の要素は構造体で,status table[stat]lev].status CHEB 5 の状態番号を,status_table[stat][ev].discountで値引きの金額 を,status table[stat][ACCEPT INDEX].acceptで,発券可の列 の値を参照できる。 配列status tableの,発券可の列のインデックス番号である。 get event index(code)|関数codeにイベントコードを指定して実行すると,それに対応す る,配列status tableの列のインデックス番号を返す。codeは order[]配列注文された商品の情報が順番に入る配列である。商品の情報 を格納する構造体を要素にもつ。i番目の注文については, order[i].N,order[i].S,order[i].0,order[i].Aで,それぞれ表1 のN,S,0及び商品の金額を参照できる。配列の添字は1か ら始まる。N,S,0O及び商品の金額は整数である。 上きれたのである、 statusを9//状態番号 amountと9//注文金額 discountと9//値引金額 accepted<false for(iを1からorder_countまで繰り返す) amount<amount+ event_codeで+order[i],0 event indexでget_event_index(event_code) discountをdiscount t+ cat if(statusがEに等しい) エラー終了 endif endfor accepted<status table[status][ACCEPT_INDEX].accept ャしーー) 発券ボタンを押せるようにする else 発券ボタンを押せないようにする endif 注記判定プログラムがエラー終了となった場合は,券売機の画面上にエラーが発生した旨を表示 し,処理を中断する。 図4作成した判定プログラム ー18一

共通の文章

システム構成の見直しに関する次の記述を読んで,設問13に答えよ。 S社は,電子書籍をPCやタブレット,スマートフォンのWebブラウザで購読する サービスを提供している。利用者数の増加に伴うシステムの応答性能の低下や,近 年のWebブラウザの機能の向上に対応するために,現状のシステム構成を見直すこ とになった。 [現状のシステム構成と稼働状況 現状のシステム構成を図1に,各機器の機能と稼働状況を表1に示す。 2 CA Haak ar Te サーバ FW:ファイアウォールLB:BRAY AP:アプリケーションサーバRDB:関係データベースサーバ 図1現状のシステム構成 表1各機器の機能と稼働状況(抜粋) 機能と稼働状況 -Webプラウザからの要求をAPに引き渡して,その処理結果をWedコンテンツとして サーバ[Webブラウザに返す。WebコンテンツをTLSによって暗号化する機能を兼ねているの で,CPU負荷が高い。 利用者の認証,電子書籍情報を検索する処理,端末の種別に応じて電子書籍データを 変換する処理及び利用者にポイントを定期的に付与するバッチ処理など,複数の処理 APを担っている。利用者数の多い時間帯は,CPU使用率が80%を超える状態が続くこ とがあり,その時間帯にバッチ処理が実行されると,Webブラウザからのリクエスト に対する応答待ちが極端に長くなってしまうことがある。 app|MAHON,電子書籍の書籍名や著者などの書籍情報と書籍の本文や画像情報を保 持する。CPU負荷は低いが,ディスクの読込み負荷が常に高い。 〔新システムの構成の検討] 現状のシステムへの負荷の問題を解消するために,次の方針に治っつた新システム の構成を検討する。 ・費用や変更容易性を考慮し,仮想環境上に新システムを構築する。 ・WebサーバのCPU負荷を軽減するために専用の機器を導入する。 ・Webブラウザよりも操作性に優れたスマートフォン用のアプリケーションプログ ラム(以下、スマホアプリという)を開発して,それにも対応するようにAP上の 処理を見直す。 ・電子書籍データをRDB上に集中配置する方式から,KVS(Key-Value Store)を用 いて複数のサーバに分散配置する方式に変更する。 新システムの構成を図2に,各機器の機能を表2に示す。 Web We の oe NE pas ark I XL Kvs| viv ak ws| 図2新システムの構成 表2各機器の機能(抜粋) 認証AP利用者の認証を行うWeb APIを提供する。Web APIはフロントAP又はバック APからWebサーバを介して呼び出される。 利用者DB利用者の情報を保持するデータ管理システムである。 フロントAP|[b|を行い,バックAPから電子書籍データを取得し,Webブラウザの 種類に応じたWebコンテンツとして変換してWebサーバに返す。 バックAP[|b|を行い,KVSから電子書籍情報の検索や電子書籍データの取得を行 うWeb APIを提供する。Web APIはフロントAP又はスマホアプリからWebサ ーバを介して呼び出される。また,利用者にポイントを定期的に付与するバッ チ処理も行う。 KVS電子書籍の書籍名や著者などの書籍情報と,書籍の本文や画像情報をキーバリ ュー形式で保持するデータ管理システムである。複数台のサーバで同じデータ を保持することによって,現状のシステムで高かった| c|を分散する。 [新システムの構成の評価〕 新システムの構成の評価を行う。 ・フロントAPとバックAPのスケーリング スマホアプリの優位性から,利用者はWebブラウザの利用からスマホアプリの 利用に移行していくことが予想される。この変化に応じて,①フロントAPとバッ クAPの台数を見直すことが可能である。 将来的には,Webブラウザの機能の向上に伴い,フロントAPで変換されたコン テンツを表示する方式から,Webブラウザ上で実行されるアプリケーションプロ グラムが処理する方式に変更することで,②スマホアプリと同様のデータ処理を Webブラウザだけで実現することができる。 ・バックAPの課題 現状のシステムのAP上の間題が新システムの構成でも解消されておらず,バッ クAPへのリクエストに対する③応答待ちが極端に長くなってしまうおそれがある。

共通の文章

無線LANの導入に関する次の記述を読んで,設問1ー3に答えよ。 E社は,社員数が150名のコンピュータ関連製品の販売会社であり,オフィスピル の2フロアを使用している。社員は,オフィス内でノートPC(以下,NPCという) を有線LANに接続して,業務システムの利用,Web閲覧などを行っている。社員に よるインターネットの利用は,DMZのプロキシサーバ経由で行われている。現在の E社LANの構成を図1に示す。 E社の各部署にはVLANが設定されており,NPCからは,所属部署のサーバ(以 下,部署サーバという)及び共用サーバが利用できる。DHCPサーバからIPアドレ スなどのネットワーク情報をNPCに設定するために,レイヤ3スイッチ(以下, L3SWという)でDHCP| 』|を稼働させている。 eae omer)|oswH ‘pee!}VLAN10 1 1 VLAN50 esseasssssl|||Fal LN 1サーバ] |7 3 rw avant oe(Ne|me iLmmel"lme| 注記VLAN10~50は,部署1て5に設定されているVLANIDを示す。 図1現在のE社LANの構成(抜粋) 総務,経理,情報システムなどの部署が属する管理部門のフロアには,オフィス エリアのほかに,社外の人が出入りできる応接室,会議室などの来訪エリアがある。 E社を訪問する取引先の営業員(以下,来訪者という)の多くは,NPCを携帯して いる。一部の来訪者は,モバイルWi-Fiルータを持参し,携帯電話網経由でインター ネットを利用することもあるが,多くの来訪者から,来訪エリアでインターネット を利用できる環境を提供してほしいとの要望が挙がっていた。また,社員からは, 来訪エリアでもELANを利用できるようにしてほしいとの要望があった。そこで, =1= E社では,来訪エリアへの無線LANの導入を決めた。 情報システム課の課長は,部下のGさんに,無線LANの構成と運用方法につい て検討するよう指示した。F課長の指示を受けたGさんは,最初に,無線LANの構 成を検討した。 (FE LANの構成の検討〕 Gさんは,来訪者が無線LAN経由でインターネットを利用でき,社員が無線LAN 経由でE社LANに接続して有線LANと同様の業務を行うことができる,来訪エリ アの無線LANの構成を検討した。 無線LANで使用する周波数帯は,高速通信が可能なIEEE 802.11acとIEEE 802.11nの両方で使用できる| b|GHz帯を採用する。データ暗号化方式には, | c|senso AES(Advanced Encryption Standard)が利用可能なWPA2 を採用する。来訪者による社員へのなりすまし対策には,IEEE|q|を採用 し,クライアント証明書を使った認証を行う。この認証を行うために,RADIUSサー バを導入する。来訪者の認証は,RADIUSサーバを必要としない,簡便なPSK(Pre- Shared Key)方式で行う。 無線LANアクセスポイント(以下,APという)は,来訪エリアの天井に設置す る。APは| e|対応の製品を選定して,APのための電源工事を不要にする。 これらの検討を基に,Gさんは無線LANの構成を設計した。来訪エリアへのAP の設置構成案を図2に,E tt LANへの無線LANの接続構成案を図3に示す。 管理部門のオフィスエリア来訪エリア |デー Re ©:AP Py} 注記図中の円内は,APがカバーするエリア(以下,セルという)を示す。 図2来訪エリアへのAPの設置構成案 ー一 EE !サーバセグメント||Lest ee |sw| (|ees|ican 4陸計ー|ap| 注記1 AY,4 vec head Al/w em be.ae a waneoa he iL wre"Ne jf wpe}-L ref[eas 7 図3 E社LANへの無線LANの接続構成案 2中の4台のAPには,図3中の新規導入機器のL2SW8から|ec|で電カ 供給する。APには,社員向けと来訪者向けの2種類のESSIDを設定する。図3中の 来訪エリアにおいて,APに接続した来訪者のNPCと社員のNPCは,それぞれ異な るVLANに所属させ,利用できるネットワークを分離する。 社員のNPCは,APに接続するとRADIUSサーバでクライアント認証が行われ, 認証後にVLAN情報がRADIUSサーバからAPに送信される。APに実装されたダイ ナミックVLAN機能によって,当該NPCの通信パケットに対して,APでVLAN10 ~50の部署向けのVLANが付与される。一方,来訪者のNPCは,APに接続すると PSK認証が行われる。①認証後に,NPCの通信パケットに対して,APで来訪者向け のVLAN100が付与される。 社員と来訪者が利用できるネットワークを分離するために,図3中の②L2SW8の ポートに,VLAN1O~50又はVLAN100を設定する。ルータ2 Clk,DHCPサーパ機 能を稼働させる。 次に,Gさんは,無線LANの運用について検討した。 〔無線LANの運用] RADIUSサーバは,認証局機能をもつ製品を導入して,社員のNPC向けのクライ アント証明書とサーバ証明書を発行する。クライアント証明書は,無線LANの利用 を希望する社員に配布する。来訪者のNPC向けのPSK認証に必要な事前共有鍵(パ ー26一 スフレーズ)は,毎日変更し,無線LANの利用を希望する来訪者に対して,来訪者 向けESSIDと一緒に伝える。 来訪者のNPCの通信パケットは,APでVLAN IDが付与されるとルータ2と通信 できるようになり,ルータ2のDHCPサーバ機能によってNPCにネットワーク情報 が設定され,インターネットを利用できるようになる。社員のNPCの通信パケット は,APでVLAN IDが付与されるとサーバセグメントに設置されているDHCPサー バと通信できるようになり,DHCPサーバによってネットワーク情報が設定され,E 社LANを利用できるようになる。 Gさんは,検討結果を基に,無線LANの導入構成と運用方法を設計書にまとめ, F課長に提出した。設計内容はF課長に承認され,実施されることになった。

共通の文章

薬剤管理システムの再構築に関する次の記述を読んで,設問1ー4に答えよ。 W病院は,複数の外来診療科をもっており,症状や病状に応じて処方箋を発行し ている。W病院には院内薬局があり,受診者の多くは院内薬局で薬剤の処方を受け る。 処方箋には期限があり,発行年月日から有効年月日までを,薬剤の処方を受ける ことのできる期間としている。 W病院では,受診者への医療サービス向上を目的に,薬剤管理システムの再構築 を行うことになった。再構築するシステムには,医師の処方箋作成を支援する次の チェック機能を実装する。 ・処方箋発行の際,処方しようとしている薬剤と過去6か月以内にW病院で発行し た処方箋に記載の薬剤との組合せに対し,薬剤億用チェックを行う。薬剤併用チ ェックでは,併用を禁止する“併用禁忌”となる薬剤の組合せ,及び併用に注意 を要する"併用注意”となる薬剤の組合せに該当しないことを確認する。 ・院内薬局で処方することを前提に,処方箋発行時に院内薬局の薬剤に対する在庫 チェックを行う。在庫チェックでは,発行した処方箋に記載の薬剤が,院内薬局 で有効年月日まで確保されるよう,在庫の保証を行う。 開発に当たり設計した,薬剤管理システムのデータベースのE-R図を図1に示す。 なお,"在庫量大人1 A”,“処方量大人1日"とは,“KAI日の分量”を単位 とした在庫量,処方量を示す。 =忠一 受診者TD受診者ID RABID 氏名受診予定日時い]発行医師コード 性別|』|診療科コード発行年月日 生年月日ARID有効年月日 住所薬剤処方年月日 薬剤在庫pe ーー——Port ae em AIA 2]seme,処方明細 大人1日の分量Oo処方箋世 凡例薬剤コード -@一〇-:1対0又は1ーー 量大人1 RIES-@一一@-:1対1薬剤併用情報 属性名-@—O>:1対多(0以上)〇薬剤コード1 属性名-@—@>:1対多(1以上)O|薬剤コード2 <—?1 ae ee注意情報 注記属性名の実線の下線___-はキキー,破線の下線-----は外部キーを示す。 主キーの実線が付いている属性名には,外部キーの破線を付けない。 図1薬剤管理システムのデータベースのE-R図(抜粋) このデータベースでは,E-R図のエンティティ名をテーブル名に,属性名を列名に LC,適切なデータ型で表定義した関係データベースによって,データを管理する。 業務処理と操作対象のテーブルを表1に示す。また,テーブルの列に対する処理 内容を表2に示す。ここで,表2中の括弧付き数字は,表1中の業務処理の括弧付 き数字に対応している。 表1業務処理と操作対象のテーブル(抜粋) a操作対象のテーブル 4 um F理 pues受診者 «loa|@ranmoneen|axes|-|-| oupmnmmmoeE|-|=e%|-| 5=ee™ la[a本 の久生人本9行‘|maw|-| ast|在庫チェック 、、AS 院: ut lcommamonewm[|-|-|-| (12)薬剤併用情報の定期メンテナンス薬剤佐用情報 表2テーブルの列に対する処理内容(抜粋) :oo teak' NULLを設定する。(1)(⑫)|値を更新する。(④⑭ ————値を更新する。(⑦ ラーles° _値を更新しない。(8) WL FG SE有効年月日NULLを設定する。(④⑭ ss値を更新しない。(⑦) RASA値を更新する。⑧ 薬剤在庫在庫量大人1日|0を設定する。⑨ae Te -値を減ずる。(⑧ CRAIGS xy 7 REE) 薬剤管理システムでは,薬剤併用情報テーブルに“併用禁忌"と“併用注意"と なる薬剤の組合せを保持しており,この情報を使い,薬剤併用チェックを行う。 “併用禁忌”と“併用注意"に該当する薬剤の組合せ一覧を出力するSQLを図2 に示す。ここで,“BB ID”’,“:半年前年月日",“:処方箋ID”は,該当の値を格納 する埋込み変数である。また,TO DATE関数は,指定された文字型の年月日を DATE型に変換するユーザ定義関数である。 薬剤の組合せ一覧には,今回の外来受診では処方しない薬剤や院内薬局で処方を 受けなかった薬剤の組合せも含まれており,出力内容を医師が確認し,必要に応じ て処方する薬剤を見直す。見直しの結果,処方箋明細が0件になることもあるが, このような場合には,処方箋の発行は行わない運用とし,処方箋レコードは削除し ない。 WITHチェック対象薬剤AS( SELECT B1.薬剤コードFROM処方箋明細B1, (SELECT A1.処方箋ID FROM外来受診A1,処方箋A2 WHERE A1.受診者ID=:受診者ID AND A1.処方箋ID=A2.処方箋ID AND A2.発行年月日>>T0_DATE(:半年前年月日))B2 WHERE B1.処方箋ID=B2.処方箋ID SELECT C1.薬剤コードFROM処方箋明細C1 WHERE C1.処方箋ID=:処方箋ID) SELECT*FROM薬剤併用情報T1 (SELECT T2.薬剤コード1,T2.薬剤コード2 FROM (SELECT U1.薬剤コードAS薬剤コード1,U2.薬剤コードAS薬剤コード2 FROMチェック対象薬剤U1 CROSS JOINチェック対象薬剤U2)T2 WHERE T1.薬剤コード1=T2.薬剤コード1 AND T1.薬剤コード2=T2.薬剤コード2) 図2“併用禁忌"と“併用注意"に該当する薬剤の組合せ一覧を出力するSQL [在庫チェック処理] 在庫チェックでは,“発行した処方箋に記載の薬剤が,院内薬局で有効年月日まで 確保されるよう,在庫の保証を行う。"。という要件の判定を簡素化するために,処方 箋を発行し,有効年月日までに院内薬局で処方する可能性のある薬剤の処方量の合 計を,確保量として管理するためのビューを作成することにした。 ビューを作成するSQLを図3に示す。ここで,CURRENT DATE関数は,参照時 の日付をDATE型で返す日時値関数である。 在庫チェックで在庫不足が判明した際は,医師は処方する薬剤の見直しや,長期 処方を希望する受診者との処方量の調整を行う。 CREATE VIEW処方前確保在庫(薬剤コード,確保量大人1日)A5 SELECT 13.薬剤コード,|i] FROM (SELECT T2.薬剤コード,T2.処方量大人1日 FROM処方箋T1,処方箋明細T2 WHERE T1.処方箋ID=T2.処方箋ID AND T1.発行年月日<=CURRENT_DATE AND T1.有効年月日|」|AND TI.薬剤処方年月日|k|)r3 GROUP BY T3.薬剤コード 3確保量を管理するためのビューを作成するSQL

共通の文章

家庭用浴室給湯システムに関する次の記述を読んで,設問1ー3に答えよ。 G社は,家庭用浴室給湯システム(以下,浴室給湯システムという)を開発してい る。浴室給湯システムは,設定された給湯温度で浴槽に給湯を行う機能と,浴室に 入った人が洗い場又は浴槽で動かなくなる事象(以下,異常事象という)を監視し て,異常事象が発生したらブザーで同居人に知らせる機能をもつ。浴室給湯システ Ald,浴室内に設置されるリモコン,浴室の出入口に設置される出入りセンサ,及 び浴室外に設置される給湯器で構成される。浴室給湯システムの構成を図1に,浴 室給湯システムの構成要素の概要を表1に示す。 リモコン信号線We oom A]Deg|会、|(を一出入りセンサ でロ給湯||Hy||旨温度変更ボタン 給湯ボタン給湯)/——【運転直 ーー—_——S浴槽への給湯管 —シリアルIF上水道管 Aeブザー運転ボタン給湯器 図1浴室給湯システムの構成 表1浴室給湯システムの構成要素の概要 ・表示器,人感センサ,ブザー,運転ボタン,給湯ボタン,給湯温度変更ボタ ン,及びMCUで構成される。 ・表示器は,設定された給湯温度と,給湯器の運転状態を表示する。 リモコン・人感センサは,人の動きを検出したときは1を,検出しなかったときは0を,1 秒ごとに出力する。人の動きを検出する範囲は,浴室内に限られる。 ・出入りセンサと接続され,出入りセンサの出力を読み出すことができる。 ・給湯器と接続され,給湯器に指示を送信することができる。 ・人が浴室の出入口を横切っていることを検出している間は1を,それ以外の間 出入りセンサは0を出力する。人が浴室に入ったのか,浴室から出たのかは判別できない。 ・非常に短い間隔で0と1を交互に出力する現象が発生することがある。 ・リモコンからの指示に従い,運転,停止,給湯,及び給湯温度の変更を行う。 給湯器・リモコンからの各指示のデータ長は,いずれも3バイトの固定長である。 ・シリアルIFの通信速度は,9,600ビットノ秒である。 注記人感センサの出力,出入りセンサの出力,及びリモコンの各ボタンの入力は,MCUの入力 ポートで読み出すことができる。 〔出入りセンサの出力の確定方法] MCUは,出入りセンサの出力を1回の読出しでは確定せず,10ミリ秒周期で出力 を読み出して,5回連続で同じ値が読み出せたときに確定し,その値を確定値とする。 [リモコンの動作 (1)リモコンは,各ボタンによって操作を受け付け,給湯器に指示を送信する。 ・運転ボタンが押されたら給湯器の運転又は停止,給湯ボタンが押されたら給湯, 給湯温度変更ボタンが押されたら給湯温度の変更というように,ボタンに応じ た指示を給湯器に送信する。 (2)リモコンは,人の浴室の出入り及び異常事象を監視する。 ・人感センサの出力が1であれば,人が浴室に入ったと判定する。 ・人が浴室に入ったと判定した後,出入りセンサの確定値が1となった後で人感 センサの出力が0となれば,人が浴室から出たと判定する。 ・人が浴室に入ったと判定した後,出入りセンサの確定値が1となる前に,人感 センサの出力が連続して3分以上0であればぱば,異常事象と判定する。. ・異常事象と判定したら,いずれかのボタンが押されるまでブザーを鳴動する。 [リモコンのソフトウェア構成〕 リモコンの組込みソフトウェアには,リアルタイム0Sを使用する。異常事象の監 視に関係する主なタスクの一覧を表2に示す。 ー35一 表2異常事象の監視に関係する主なタスクの一覧 ・リモコン全体の管理及びブザーの鳴動制御を行う。 メイン・監視タスクから“異常”が通知されたら,ブザーを鳴動させる。 ・ブザーの鳴動を停止したときは,“IR”を監視タスクに通知する。 ・10ミリ秒周期で出入りセンサの出力を読み出す。 0 el・確定値が1となったら,“出入り”を監視タスクに通知する。 ・一度“出入り”を通知したら,次に“出入り”を通知するのは,確定値が 一度0となった後で,再び確定値が1となったときである。 ・500ミリ秒周期で人感センサの出力を読み出す。 人検出・出力が1であれば“検出”を,出力が0であれば“AMM”を監視タスク に通知する。 -_・出入り検出タスク及び人検出タスクの通知から,異常事象を判定する。 “・異常事象と判定した場合は,メインタスクに“異常”を通知する。

共通の文章

ebサイトの開発に関する次の記述を読んで,設問1一5に答えよ。 J社は,コーヒー店をチェーン展開する外食事業者である。J社が運営するコーヒ ー店のWebサイトは開設後数年が経過し,デザインが古くなっていることから, Webサイトのリニューアルを実施することになった。 社のシステム部門に所属するK Ald,Webサイトの担当として,リニューアルに 当たってのデザイン及び開発方針を整理することになった。 [リニューアルにおけるWebサイトデザインの要件〕 リニューアルに当たり,システム部門のL部長から“スマートフォンやタプブレッ トからのアクセスが大きな割合を占めることから,Webサイトにアクセスする手段 に応じて,Webサイトの表示を切り替え,利用者が見やすいWebサイトにすること" との要件が示された。 (実現案の検討]. K君は。スマートフォン,タブレット及びPCをWebサイトにアクセスするデバ イスとして想定し,この要件に対する実現方法として,次の2案を比較検討した。 案1:WebサイトにアクセスするWebブラウザやデバイスのスクリーンサイズ (画面幅)を基準に,表示を切り替える方法 案2:WebサイトにアクセスするWebブラウザやデバイスのユーザエージェン ト情報によって,表示を切り替える方法 案1は,| 』|と呼ばれる手法である。 K君が調査した両案の特徴を表1に示す。 | =9= 表1 K君が調査した両案の特徴 Webサイト|様々なデバイスに対して単一の|デバイスごとに最適化した複数の 表示の切替|p|]ファイルを使用する。[||ファイルを準備しておく。 え方法Webブラウザのウィンドウ幅を基準|Webサーバへのアクセス時に通知されるユ に,CSSで表示を切り替える。ーザエージェント情報(Webブラウザの て,適切な|bp|ファイルにリダイ レクトを行うことで表示を切り替える。 表示速度|リダイレクトを行わないので,表示の|案1と比較した場合,リダイレクトを行う 遅延は発生しない。ただし,PCの高解|分,表示の遅延が発生する。 像度ディスプレイ用の画像をスマート フォンでも共通して使用する場合に は,表示の遅延が発生する。 デザインのどのデバイスでも同じ|b|ファデバイスごとに異なる|b|ファィ 自由度イルを表示するので,基本的なデザイ|ルを表示するので,デバイスごとに自由に ンは共通とをなる。そのため,デバイス|デザインすることが可能である。 ごとに大幅にデザインを変更すること は難しい。 K Mlk 1の両案の特徴を比較し,次の理由から案1を採用する方針とした。 ・]社が運営するコーヒー店のWebサイトでは,デバイスごとに大きくデザインを変 更する必要がない。 ・①案2は初期開発や将来のデザイン変更において,開発コストが大きくなると考 えられる。 [デザインイメージの作成〕 K君はスマートフォン,タブレット及びPCの3種類のデバイスに対して,それ ぞれのウィンドウ幅に適したデザインイメージを作成した。 K君が作成したデバイスごとのデザインイメージを図1に示す。 スマートフォンとタブレットはシングルカラムのレイアウトとし,PCは2カラム のレイアウトとした。また,見出しや画像の水平方和のレイアウトは,スマートフ ォンではセンタリング,タブレットとPCでは左寄せとし,上下方向のレイアウトは デバイスにかかわらず上寄せとした。画像はデバイスごとのWebブラウザに合わせ たサイズ,縦横比の画像を表示することとし,繰返し表示は行わなかいこととした。 見出し2 (スマートフォン用) 見出し1見出し1見出し1 見出し2見出し2; スマートフォンタプレットPC 図1 K君が作成したデバイスごとのデザインイメージ [ブレークポイントの決定〕 案1の実現方法では,デバイスの解像度,ウィンドウの幅・向きなどの指定条件 に合わせて別々のCSSを適用する“メディアクエリ”の機能によってCSSを切り替 RS,Webブラウザのウィンドウ幅でCSSを切り替える条件を“ブレークポイント”" という。ブレークポイントはピクセルで指定し,単位はpxで表す。 K君は,図1のデザインイメージに合わせて,スマートフォンとタブレットのブレ ークポイントを768 px,タブレットとPCのブレークポイントを1.024 pxとし,表2 のように対象デバイスごとのWebブラウザで想定されるウィンドウ幅の範囲を決定 した。 表2 K君が決定したウィンドウ幅の範囲 ウィンドウ由の和 また,表1に示す案1の特徴から,②非機能要件を考慮して,デバイスごとにサ イズの異なる画像を用意し,表2のウィンドウ幅の範囲に合わせて,表示する画像 を切り替える方針とした。 (CSSの作成 K Ald,表2で決定したウィンドウ幅の範囲に合わせてCSSを作成した。CSSで 使用する書式及びデータの一部を表3に示す。また,K君が作成したCSSのうち, タブレット用のブレークポイントの指定と画像表示に関する部分の抜粋を図2に示 す。ここで,図1中で“タイトル1”の下に表示する画像は,backgroundプロパティ を用いて表示することにした。 表3 CSSで使用する書式及びデータの一部 | @media screen and()ブレークポイントを指定する。括弧内の条件に合致する場合,以降 のCSSを適用する。条件は複数設定することができる。 ワインドのか人を RO cas BEIT, 7 ROME RT, スマートフォン用の画像ファイルのURLを表す。 タブレット用の画像ファイルのURLを表す。 PC用の画像ファイルのURLを表す。 ae ERTS, background色,背景画像,原点と寸法,繰返し方法などを設定するプロパティ である。 background-image背景画像を指定する。 urlO:括弧内に背景画像のファイルのURLを指定する。 none:背景画像を指定しない。 background-position背景画像を表示する水平・垂直位置を指定する。 位置は水平方向,垂直方向,それぞれに指定可能である。 top:上寄せで表示することを示す。 bottom:下寄せで表示することを示す。 left:左寄せで表示することを示す。 right:右寄せで表示することを示す。 center:中央に表示することを示す。 background-repeat背景画像の表示の繰返しを指定する。 repeat:繰り返して表示し,領域からはみ出す部分は切り取られ る。 space:繰り返して表示し,領域からはみ出ないよう間隔を調整す る。 round:繰り返して表示し,領域内に収まるよう拡大・縮小する。 repeat-x:水平方向に繰り返して表示する。 repeat-y:垂直方向に繰り返して表示する。 no-repeat:繰り返して表示しない。 @nedia screen and min-width:|e|)and max-widthi|fi|)( /*タブレット用のCSSを記述*/ .keyvisual( height:309px: background-image:ur sg|a) background-position:top left; background-repeat:[h|] } } 図2 K君が作成したCSS(抜粋)

共通の文章

問19サービス運用のアウトソーシングに関する次の記述を読んで,設問1~5に答えよ。 A社は,生活雑貨を製造・販売する中堅企業で,首都圏に本社があり,全国に支社 と工場がある。A社では,10年前に販売管理業務及び在庫管理業務を支援する基幹 システムを構築した。現在,基幹システムは毎日8:00て22:00にA社販売部門向けの 基幹サービスとしてオンライン処理を行っている。基幹システムで使用するアプリ ケーションソフトウェア(以下,業務アプリという)A HIT部門が開発・運用・ 保守し,IT部門が管理するサーバで稼働している。 [基幹サービスの概要)〕 A社IT部門とA社販売部門との間で合意している基幹サービスのSLA(以下,社 内SLAという)の抜粋を,表1に示す。 表1社内SLA(抜粋) エーサービス提供時間帯。|4H 8:00~22:00|保守のための計画停止時間リを除く。 eam。|999%E| -| Rea CS ae -| インシデントを受け付けてから最終的なイン 信頼性重大インシデントの2時間以内シデントの解決をA社販売部門に連絡するま [>]‘での経過時間(サービス提供時間帯以外は, 経過時間に含まれない) オシライン店時間[sem[Cd 注記1業務アプリ及びサーバ機器の保守に伴う変更で,リリースパッケージを作成して稼働環境に展開する 作業は,サービス提供時間帯以外の時間帯又は計画停止時間を使って行われる。 注記2天災,法改正への対応などの不可抗力に起因するインシデントは,SLA目標値達成状況を確認する対 象から除外する。 注!計画停止時間とは,サービス提供時間帯中にサービスを停止して保守を行う時間のことであり,A社IT 部門とA社販売部門とで事前に合意して設定する。 -2インシデントに優先度として“重大”,“HH,“UR”のいずれかを割り当てる。優先度として“HRA”を 割り当てたインシデントを,重大インシデントという。 [インシデント処理手順の概要] A社IT部門では,インシデントが発生した場合は,インシデント担当者を選任し てインシデントを管理し,インシデント処理手順に基づいてサービスレベルを回復 させる。インシデント処理手順を表2に示す。 表2インシデント処理手順 ・インシデントを受け付け,インシデントの内容をインシデント管理徳りに記録する。 優先度の割当て|・インシデントに優先度(“HK”,“高",“UR”のいずれか)を割り当てる。 ・インシデントを,あらかじめ決められたカテゴリ(ストレージの障害など)に分類する。 .・インシデントの内容,割り当てた優先度,分類したカテゴリなどで,TyV FY bee ・インシデントの内容に応じて,専門知識をもったA tHe IT部門の技術者などに, e179. 解決インシデントの解決を図る。 ・A社IT部門が解決と判断した場合は,サービス利用者にインシデントの解決を連絡する。 ・A社IT部門は,“サービス利用者がサービスレベルを回復したこと"を確認する。 中・インシデント管理徳に必要な内容の更新を行う。 注記インシデントに割り当てた優先度に応じて,インシデントを受け付けてからサービス利用者に最終的なイ ンシデントの解決を連絡するまでの経過時間(サービス提供時間帯以外は経過時間に含まれない)の目標値 が定められている。経過時間の目標値は,優先度“重大"が2時間,優先度“高"が4時間,優先度“低" が8時間である。 AVY FY DRE LI,インシデントの内容などを記録する管理徳のことである。A社IT部門の運用者 からのインシデント発見連絡.サービス利用者からのインシデント発生連絡などに基づいて記録する。 [アウトソーシングの検討] 現在,社内に設置されている基幹システムのサーバは,運用・保守の費用が増加 し,管理業務も類雑になってきた。また,A社の事業拡大に伴い,新規のシステム開 発案件が増加する傾向にある。そこで,A社IT部門がシステムの企画と開発に集中 できるように,基幹システムをB社提供のPaaSに移行する検討を行った。検討結果 は次のとおりである。 ・当該PaaSはB社の運用センタで稼働するサービスである。B社にサービス運用を アウトソースする場合は,A社IT部門が行っているサーバの運用・保守と管理業 務はB社に移管され,B社からA社IT部門に対して運用代行サービスとして提供 される。 ・業務アプリ保守及びインシデント管理などのサービスマネジメント業務は,引き 続きA社IT部門が担当する。 A社IT部門とB社は,インシデント発生時の対応について打合せを行い,それぞ れの役割を次のように設定した。 ・表2の手順“記録”"における,B社の役割として,|d|を行うこととする。 ・表2の手順“優先度の割当て”における優先度の割当ては,A tt IT部門が行い, 割当て結果を|e|に伝える。 (A社とB社のSLA) A社IT部門は,B社へのアウトソース開始後も,A社販売部門に対して,社内 SLAに基づいて基幹サービスを提供する。そこで,AIT部門は,社内SLAを支え, 整合を図るため,A社とB社間のサービスレベル項目と目標値については,表1に 基づいてB社と協議を行い,合意することにした。また,B社へのアウトソーシン グ開始後,A te B社との間で月次で会議を開催し,サービスレベル項目の目標値 達成状況を確認することにした。 A社とB社のSLAは,B社からの要請で次の二つを追加して,合意することにし た。 ・①サービスレベル項目として,B社が保守を行うための計画停止予定通知日を追加 する。B社はPaaSの安定運用の必要性から,PaaSのサービス停止を伴う変更作業 を行う。その場合,事前に計画停止の予定通知を行うこととする。計画停止予定 通知日の目標値は,A社IT部門と販売部門の合意に要する時間を考慮して,B tt からA社への通知日を計画停止実施予定日の7日前までとし,必要に応じてA社 とB社で協議の上,計画停止時間を確定させる。 ・サービスレベル項目のうち,B社の責任ではA社と合意するB社の目標値を遵守 できない項目があるので,②A社とBED SLAの対象から除外するインシデント を決める。 なお,PaaSのリソースの増強は,A社からB社にリソース増強要求を提示して行 われるものとする。その際,A社からB社への要求は,増強予定日の2週間前まで に提示することも合意した。アウトソース開始時のPaaSのリソースは,A社基幹シ ステムのキャパシティと同等のリソースを確保する。 その後,A社とB社はSLA契約を締結し,A社IT部門の業務の一部がB社にア ウトソースされた。 【新商品の販売開始】 アウトソースが開始されて半年が経過した時点で,A社は,2か月後に新商品の販 売を控え,A社の販売部門とIT部門で次のことが確認された。 ー5一 ・新商品の販売開始後,販売量の大幅な増加が予測されている。 ・販売量の大幅な増加に伴って,基幹システムが扱うデータ量も大幅に増加する。 ・新商品の販売開始後も,社内SLAの目標値を達成する。 新商品の販売開始に対応するためには,B社でPaaSのリソースを増強する必要が HS,そこで,A社IT部門は,キャパシティ管理に関わる③必要な活動を行い,B 社にリソース増強要求を提出することにした。

共通の文章

1 RPA(Robotic Process Automation)の監査に関する次の記述を読んで,設問1ン7 に答えよ。 保険会社のX社は,ここ数年,経営計画の柱の一つとして“働き方改革"を掲げ ており,それを実現するために業務の効率向上に取り組んできた。こうした中,全 国のX社拠点の業務処理の統括部署である事務部は,約1年前に,ITベンダのY社 の提案を基に,X社で初めてRPAを導入した。 事務部がY社に委託して,RPAを導入して開発したシステム(以下,事務部RPA という)は,導入後,おおむね順調に稼働してきたが,一度だけシステムトラブル が発生し,稼働不能になったことがある。 X HORS,システムトラブルが発生したこともあり,またRPA導入の効果に ついても関心があったことから,内部監査部に対して,事務部と情報システム部を 対象に監査を実施することを指示した。監査の主な目的は,事務部RPAの運用・保 守体制の適切性,X社全体のRPA管理体制の適切性,及び事務部RPA導入の目的達 成状況を確かめることである。 (RPAの特徴と対象業務] (1)RPAの特徴 Y社の提案によると,RPAの主な特徴は次のとおりである。 QO複数の業務システムを利用する定型業務の自動化に適しており,業務の効率 向上,ミスの削減などに有効である。例えば,複数の画面を参照し,必要なデ ータを表計算ソフトに反映して電子メールを送信するなどの一連の業務の自動 化に適している。 ②実際のPC操作を基に開発できるので,プログラミングは不要であり,業務知 識があれば容易に開発できる。変更や複製も同様に,容易に行うことができる。 (2)事務部RPAの対象業務I 事務部は,X社拠点の定型業務のうち,RPAを導入することによって効率向上 の効果が期待できる複数の業務を,対象業務として選定した。選定した業務の例 CUT,生命保険料搾除証明書(以下,控除証明書という)の再発行業務がある。 この業務は,顧客からX社への控除証明書の再発行依頼に対して,複数の業務シ =Bf ステムの情報を参照して控除証明書を作成し,顧客に送付するものである。 [事務部RPA導入による業務プロセスの主な変更点と効果] (1)事務部RPA導入による業務プロセスの主な変更点 各拠点の対象業務を事務部に集約し,集約した業務にRPAを導入した。控除証 明書の再発行業務の場合,事務部RPA導入前の業務プロセスでは,顧客の依頼を 受け付けた拠点の担当者が,控除証明書の再発行に関わる全ての業務を行ってい た。これに対して,事務部RPA導入後の業務プロセスは,次のとおりである。 ①顧客から控除証明書の再発行の依頼を受け付けた拠点は,事務部の所定のメ ールアドレス宛てに,電子メールで控除証明書の再発行依頼を行う。 ②事務部の担当者は,拠点からの依頼メールに基づいて事務部RPAを稼働させ, 自動的に作成された控除証明書を顧客に送付する。 (2)事務部RPA導入による効果 事務部は,事務部RPA導入によって一定の効率向上効果が得られることを,処 理時間などが記録された事務部RPAの実行ログを基に確認した。控除証明書の再 発行業務の場合,従来は1件当たり15分程度要していた処理時間が1分程度に短 縮された。 [事務部RPAの開発体制及び運用・保守体制〕 (1)事務部RPAの開発体制 事務部RPAの開発は,Y社のシステムエンジニア2名が約2か月間,事務部の 開発用ブースに常駐して行われた。開発に当たって,事務部は,投資効果などを 記載した“導入計画書"を作成し,Y tlt,開発及び変更に必要なドキュメントと して“事務部RPA開発用資料”を作成した。 (2)事務部RPAの運用・保守体制 事務部の担当者2名が,事務部RPAの運用・保守業務を行っている。事務部は, 以前のシステムトラブルを踏まえて,情報システム部と連携して,再発防止策を 講じて運用・保守面を強化することにした。 ー55一 〔システムトラブルの概要) 事務部RPAが稼働不能になった原因は,事務部RPAと連動している複数の業務シ ステムのうち,あるシステムの画面レイアウトの変更に伴い,事務部RPAとのイン タフェースに不整合が生じたことである。本来であれば,事務部が,事前に画面レ イアウトの変更に関する情報を把握して対応すべきであったが,画面レイアウトが 変更されたシステムは,事務部以外の部署が主管していたので,事務部が変更に関 する情報を事前に把握することができなかった。こうした変更に関する情報を事前 に把握できるのは,情報システム部である。 システムトラブルが判明した直後に,事務部の担当者から連絡を受けたY HOV ステムエンジニアが原因を特定して対応を行った。ただし,あらかじめ障害対応手 順を定めていなかったので,システムトラブルの対応に時間が掛かってしまった。 (情報システム部へのヒアリング結果] 情報システム部へのヒアリング結果は,次のとおりである。 ①今後,RPAがより広く利用されるようになることを想定して,早急にRPAに 関する管理方針を定める予定である。 ②RPAの管理には,全社のRPAの管理責任部署が必要であり,その部署として 情報システム部が適任であると考えている。 ③HE,社内のシステム関連規程類の改訂案の策定を終えた段階である。 〔本調査における監査項目及び監査手続] 内部監査部は,以上の予備調査の結果を踏まえ,本調査に向けて監査項目及び監 査手続を表1のとおりまとめた。 ー56一 表1監査項目及び監査手続(抜粋) aA ar Bt 事務部RPAの導入目的は達成さ||』|を査開し,処理件数と処理時間を把握して, 1|れているがか。“導入計画書"に記載されている導入目的が達成されて いるかどうかを確認する。 事務部RPAの変更に必要となる||pb ]を査関し,変更に必要となる情報(対象業 2|情報が整備されているか。務,正常処理と異常処理,関連する業務システム,入出 カデータなど)が明示されているかどうかを確認する。 還務部RPAのシステムトラブル|| 』|を対象にヒアリングし,事務部RPAと連動 。|に対する|<|が講じらち|している業務システムのインタフェースの| 。|に れているか。関する情報を,事務部が適時に把握できる体制が整備さ れているかどうかを確認する。 事務部RPAのシステムトラブル|事務部を対象にヒアリングし,システムトラブル発生時 4|発生時の影響を最小化するため|の| f|が策定されているかどうかを確認する。 の対策が講じられているか。 管理不在のRPAの導入・利用がを査開し,RPAに関する管理方針として, 5|広がっていくことを防ぐためのFT)が定められているかどうかを確認する。 対策が講じられているか。