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

共通の文章

マルウェア対策に関する次の記述を読んで,設問に答えよ。 R社は,全国に支店・営業所をもつ,CHAN 150名の旅行代理店である。国内の 宿泊と交通手段を旅行パッケージとして,法人と個人の双方に販売している。R社は, 旅行パッケージ利用者の個人情報扱うので,個人情報保護法で定める個人情報取扱 事業者である。 [ランサムウェアによるインシデント発生〕 HSA,R社従業員のSさんが新しい旅行パッケージの検討のために,R社から3$ さんに支給されているPC(以下,PC-Sという)を用いて業務を行っていたところ, PC-Sに身の代金を要求するメッセージが表示された。Sさんは連絡すべき窓口が分か らず,数時間後に連絡が取れた上司からの指示によって,R社の情報システム部に連 絡した。連絡を受けた情報システム部のTさんは,PCがランサムウェアに感染した と考え,①PC-Sに対して直ちに実施すべき対策を伝えるとともに,PC-Sを情報シス テム部に提出するようにSさんに指示した。 Tさんは,セキュリティ対策支援サービスを提供しているZ社に,提出されたPC-S 及びR社LANの調査を依頼した。数日後にZ社から受け取った調査結果の一部を次に 示す。 ・PC-Sから,国内で流行しているランサムウェアが発見された。 ・ランサムウェアが,取引先を装った電子メールの添付ファイルに含まれていて,$ さんが当該ファイルを開いた結果,PC-Sにインストールされた。 ・PC-S内の文書ファイルが暗号化されていて,復号できなかった。 ・PC-Sから,インターネットに向けて不審な通信が行われた痕跡はなかった。 ・PC-Sから,R社LAN上のIPアドレスをスキャンした痕跡はなかった。 ・ランサムウェアによる今回のインシデントは,表1に示すサイバーキルチェーンの 攻撃の段階では|a|まで完了したと考えられる。 a ge Rlサイバーキルチェーンの攻撃の段階 攻撃の段階代表的な攻撃の事例 |1|偵察。|インターネットなどから攻撃対象組織に関する情報を取得する。 マルウェアなどを作成する。 マルウェアを添付したなりすましメールを送付する。 |4|エクスプロイト|ユーザーにマルウェアを容行ききる。。。| 攻撃対象組織のPCをマルウェアに感染させる。 マルウェアとC&Cサーバを通信させて攻撃対象組織のPCを遠隔操 作する 攻撃対象組織のPCで収集した組織の内部情報をもち出す。 〔セキュリティ管理に関する評価〕 TSAI,情報システム部のU部長にZ社からの調査結果を伝え,PC-Sを初期化し, 初期セットアップ後にSさんに返却することで,今回のインシデントへの対応を完了 すると報告した。U部長は再発防止のために,R社のセキュリティ管理に関する評価 をZ社に依頼するよう,Tさんに指示した。Tさんは,Z社にR社のセキュリティ管 理の現状を説明し,評価を依頼した。 R社のセキュリティ管理に関する評価を実施したZ社は,ランサムウェア対策に加 えて,特にインシデント対応と社員教育に関連した取組が不十分であると指摘した。 Z社が指摘したR社のセキュリティ管理に関する課題の一部を表2に示す。 表2 R社のセキュリティ管理に関する課題(一部) 種別 PC上でランサムウェアの実行を検知する対策がとられていない。 インシデント|インシデントの予兆を捉える仕組みが整備されていない。 対応インシデント発生時の対応手順が整備されていない。 インシデント発生時の適切な対応手順が従業員に周知されていな 社員教育い。 標的型攻撃への対策が従業員に周知されていない。 U部長は,表2の課題の改善策を検討するようにTさんに指示した。Tさんが検討 したセキュリティ管理に関する改善策の候補を表3に示す。 _5ーー 表3 Tさんが検討したセキュリティ管理に関する改善策の候補 改善策の候補 2 PCやサーバ機器,ネットワーク機器のログからインシデントの予 兆を捉える仕組みを導入する。 インシデント|PCやサーバ機器の資産目録を随時更新する。 対応新たな脅威を把握して対策の改善を行う。 インシデント発生時の対応体制や手順を検討して明文化する。 |6|脆弱性情報の収集方法を確立する。 i caeインシデント発生時の対応手順を従業員に定着させる。 |8|S|標的型攻撃への対策についての社員教育を行う。 [インシデント対応に関する改善策の具体化 Tさんは,表3の改善策の候補を基に,インシデント対応に関する改善策の具体化 を行った。Tさんが検討した,インシデント対応に関する改善策の具体化案を表4に 示す。 表4インシデント対応に関する改善策の具体化案 改善策の具体化案対応する表3の項番 R社社内に③インシデント対応を行う組織を構築する。 R社の情報機器のログを集約して分析する仕組みを整備する。 3 R社で使用している情報機器を把握して関連する脆弱性情報を[L 収集する。 |4|社内外の連絡体制を整理して文書化する。 。|@セキュリティインシデント事例を調査し,技術的な対策の 改善を行う。 検討したインシデント対応に関する改善策の具体化案をU部長に説明したところ, 表4の項番5のセキュリティインシデント事例について,特にマルウェア感染などに よって個人情報が補取された事例を中心に,Z社から支援を受けて調査するように指 示を受けた。 社員教育に関する改善策の具体化] Tさんは,表3の改善策の候補を基に,社員教育に関する改善策の具体化を行った。 Tさんが検討した,社員教育に関する改善策の具体化案を表5に示す。 —_6一 表5社員教育に関する改善策の具体化案 期的に実施する。 R社では,標的型攻撃に対応する方法やインシデント発生時の対応手順が明確化さ れておらず,従業員に周知する活動も不足していた。そこで,標的型攻撃の内容とリ スクや標的型攻撃メールへの対応,インシデント発生時の対応手順に関する研修を, 新入社員が入社する4月に全従業員に対して定期的に行うことにした。 また,R社でのインシデント発生を想定した訓練の実施を検討した。図1に示す一 連のインシデント対応フローのうち,⑤全従業員を対象に実施すべき対応と,経営者 を対象に実施すべき対応を中心に.。ランサムウェアによるインシデントへの対応を含 めたシナリオを作成することにした。 図1一連のインシデント対応フロー Tさんは,今回のインシデントの教訓を生かして,ランサムウェアに感染した際に PC内の重要な文書ファイルの束失を防ぐために,取り外しできる記録媒体にバック アップを取得する対策を教育内容に含めた。検討した社員教育に関する改善策の具体 化案をU部長に説明したところ,⑥バックアップを取得した記録媒体の保管方法につ いて検討し.その内容を教育内容に含めるようにTさんに指示した。

共通の文章

中了堅の電子機器製造販売会社の経営戦略に関する次の記述を読んで,設問に答えよ。 Q tit,中堅の電子機器製造販売会社で,中小のスーパーマーケット(以下,スー パーという)を顧客としている。0社の主力製品は,商品管理に使用するバーコード を印字するラベルプリンター,及びバーコードを印字する商品管理用のラベル(以下, バーコードラベルという)などの消耗品である。さらに,技術を転用してバーコード 読取装置(以下,。バーコードリーダーという)も製造販売している。 顧客がバーコードラベルを使用する場合は,商品に合った大きさ,厚さ,及び材質 のバーコードラベルが必要になり,これに対応してラベルプリンターの設定が必要に なる。商品ごとに顧客の従業員がマニュアルを見ながら各店舗でラベルプリンターの 画面から操作して設定しているが,続々と新商品が出てくる現在,この設定のスキル の習得は,慢性的な人手不足に悩む顧客にとって負担となかっている。 【現在の経営戦略] Q社では,ラベルプリンターの機種を多数そろえるとともに,ラベルプリンター及 びバーコードリーダーと連携して商品管理や消耗品の使用量管理などを支援するソフ トウェアパッケージ(以下,Q社パッケージという)を業界で初めて開発して市場に 展開し,①競合がない市場を切り開く経営戦略を掲げ,次に示す施策に基づき積極的 に事業展開して業界での優位性を保っている。 ・顧客の従業員がQ社パッケージのガイド画面から操作して,接続されている全ての 店舗のラベルプリンターの設定を一度に変更することで,これまでと比べて負担を 軽減できる。さらに@②顧客の依頼に応じて,ラベルプリンターの設定作業を受託す る。 ・ラベルプリンターの販売価格は他社より抑え,バーコードラベルなどの消耗品の料 金体系は,Q社パッケージで集計した使用量に応じたものとする。 BE,従来機種を改良したラベルプリンターを開発し,ラベルプリンターが有する 様々な便利な機能を最大限活用できるように,Q社パッケージの機能を拡充する。 これらの施策の実施によって,0社は。|。|ビジネスモデルを実現し,価 格設定や顧客への対応などが受け入れられて,リピート受注を確保でき,業界平均以 ー19一 上の収益性を維持している。 [現在の問題点〕 一方で,今後も業界での優位性を維持するには次の問題もある。 ・最近開発したラベルプリンターで,設置される環境や操作性などについて,顧客ニ ーズの変化を十分に把握しきれておらず,顧客満足度が低い機種がある。 ・ラベルプリンターは定期的に予防保守を行い,部品を交換しているが,交換する前 に故障が発生にしてしまうことがある。故障が発生した場合のメンテナンスは,顧客 の担当者から故障連絡を受けて,高い頻度で発生する故障の修理に必要な部品を持 って要員が現場で対応している。しかし,故障部位の詳細な情報は事前に把握でき ず,修理に必要な部品を持っていない場合は,1回の訪問で修理が完了せず,顧客 の業務に影響が出たことがある。また,複数の故障連絡が重なるなど,要員の作業 の繁閑が予測困難で,要員が計画的に作業できずに苦慮している。 ・多くの顧客では,消費期限が近くなった商品の売れ残りが発生しそうな場合には, 消費期限と売れ残りの見通しから予測した時刻に,値引き価格を印字したバーコー ドラベルを重ねて貼っている。食品の取扱いが多い顧客からは,顧客の戦略目標の ーつである食品廃棄量削減を達成するために,値引き価格を印字したバーコードラ ベルを貼る適切な時刻を通知する機能を情報システムで提供するよう要望を受けて いるが,現在の0Q社パッケージで管理するデータだけでは対応できない。 ・ラベルプリンターの製造コストは業界では平均的だが,バーコードリーダーは,開 発に多くの要員を割かれていて製造コストは業界での平均よりも高い。バーコード リーダーの製造販売において,他社と差別化できておらず,販売価格を上げられな いので利益を確保できていない。 ・ラベルプリンターでは,スーパーを顧客とする市場が飽和状態になりつつある中で, 大手の事務機器製造販売会社のS社がラベルプリンターを開発して,スーパーを顧 |客とする事務機器の商社を通して大手のスーパーに納入した。S社は,スーパーと の直接的な取引はないが,Sk,Q社が事業を展開している中小のスーパーを顧客 とする市場にも進出するおそれが出てきた。 将来に備えて経営戦略を強化することを考えた0社のR社長は,外部企業へ依頼し て,0社が製造販売する製品と提供するサービスに関する調査を行った。 ーー 〔経営戦略の強化] 調査の結果,R社長は次のことを確認した。 ・ラベルプリンターの開発において,顧客ニーズの変化に素早く対応して他社との 差別化を図らなければ,顧客満足度が下がり業界での優位性が失われる。 ・メンテナンス対応において,故障による顧客業務への影響を減らせば顧客満足度 が上がる。顧客満足度を上げれば,既存顧客からのリピート受注率が高まる。 ・顧客満足度を上げるためには,製品開発力及びメンテナンス対応力を強めること に加えて,顧客が情報システムに求める機能の提供力を強めることが必要である。 ・バパーコードリーダーは,Q社のラベルプリンターや0社パッケージの製造販売と競 合せず,POS端末及び中小のスーパーで定評のある販売管理ソフトウェアパッケー ジを製造販売するU社から調達できる。 そして,0社及びS社の現状に対して,競争要因別の顧客から見た価値の相対的な 高さと,R社長が強化すべきと考えた0社の計画を図1に示す戦略キャンバス(抜粋) にまとめた。 EE a ee ee凡例 |XX社の計画 OH©0社の現状 ーートーンーーーA$社の現状 図1 R社長が考えた戦略キャンバス(抜粋) R社長は戦略キャンバス(抜粋)に基づいて,業界での優位性を維持するために社 内の幹部と次に示す重点戦略をまとめた。 (1)ラベルプリンターの製品開発 ラベルプリンターの製品開発において,顧客のニーズを聞き,迅速にラベルプ リンターの試作品を開発して顧客に確認してもらうことで,従来よりも的確にニ ーズを取り込めるようにする。 ラベルプリンターの試作や顧客確認などの開発段階での業務量が増えることに なるが,|b|。これによって,開発要員を増やさないことと製品開発 ー12一. を強化することとの整合性を確保する。 (2)メンテナンス対応力 R社長は.メンテナンス対応の要員数を変えたず,③メンテナンス対応力を強化 して顧客満足度を上げることを考えた。具体的には,OO社パッケージが,イン ターネット経由で,0Q社のラベルプリンターの稼働に関するデータ,及びモータ ーなどの部品の劣化の兆候を示す電圧変化などのデータを収集して適宜0社に送 信する機能を実現する。 (3)情報システムの提供力 0社の業界での優位性を更に高めるために,⑤SDGsのーつである“つくる責任, つかう責任"に関して,顧客が食品の廃棄量の削減を達成するための支援機能な ど,0社パッケージの機能追加を促進する。このために,U社と連携して,0社 パッケージとり社の販売管理ソフトウェアパッケージとを連動させる。

共通の文章

多倍長整数の演算に関する次の記述を読んで,設問に答えよ。 コンピュータが一度に処理できる整数の最大桁には,CPUが一度に扱える情報量に 依存した限界がある。一度に扱える桁数を超える演算を行う一つの方法として,10 を基数とした多倍長整数(以下,多倍長整数という)を用いる方法がある。 [多倍長整数の加減算〕 多倍長整数の演算では,整数の桁ごとの値を,1の位から順に1次元配列に格納し て管理する。例えば整数123は,要素数が3の配列に(3,2,1}を格納して表現する。 多倍長整数の加算は,“桁ごとの加算"の後,“繰り上がり"”を処理することで行う。 456十789を計算した例を図1に示す。 桁ごとの加算:(6,5,4)+{9,8,7)>(6+9,5+8,4+7}>{15,13,11} 繰り上がり:@13,>6&Bm>6 4@)>&4 2M) SE 1の位の繰り上がり106の位の繰り上がり100の位の繰り上がり 図1 456+789を計算した例 *桁ごとの加算”を行うと,配列の内容は{15,13,11}となる。1の位は15にな るが,15は19X1十5なので,10の位である13に1を繰り上げて{5,14,11)とする。 これを最上位まで繰り返す。最上位で繰り上がりが発生する場合は,配列の要素数を 増やして対応する。減算も同様に“桁ごとの減算”と“繰り下がり”との処理で計算 できる。 [多倍長整数の乗算〕 多倍長整数の乗算については,計算量を削減するアルゴリズムが考案されており, その中の一つにカラツバ法がある。ここでは,桁数が2のべき乗で,同じ桁数をもっ た正の整数同士の乗算について,カラツバ法を適用した計算を行うことを考える。桁 数が2のべき乗でない整数や,桁数が異なる整数同士の乗算を扱う場合は,上位の桁 を9で埋めて処理する。例えば,123X4は9123X9994として扱う。 に16 ims 〔ツリー構造の構築〕 カラツバ法を適用した乗算のアルゴリズムは,計算のためのツリー構造(以下、。ツ リーという)を作る処理と,ツリーを用いて演算をする処理から成る。ツリーは,多 倍長整数の乗算の式を一つのノードとし,一つのノードは3個の子ノードをもつ。 M桁XM桁の乗算の式について,乗算記号の左右にある値を,それぞれM/2桁ずつ に分けてA,B,C,Dの四つの多倍長整数を作る。これらの整数を使って,①AxC, @BXD,③(A十B)X(C十)の3個の子ノードを作り,M/2桁XM/2桁の乗算を行う層 を作る。(A+B),(CD)は多倍長整数の加算の結果であるが,ここでは“桁ごとの加 算だけを行い,“繰り上がり"の処理はツリーを用いて行う演算の最後でまとめて 行う。生成した子ノードについても同じ手順を繰り返し,1桁X1桁の乗算を行う最 下層のノードまで展開する。 1234X5678についてのツリーを図2に示す。図2の層2 OBA,Mit 12x56,@ は34X78,③は46X134となる。③の(C+D)は,“桁ごとの加算”だけの処理を行う と,10の位が5十7ニ12,1の位が6+8=14となるので,12X104+14=134となる。 層1 11234 X 5678|-->A:12 B:34 C:56 D:78 居3 Lix5][2x6][Sx1ll[ア][4xg][7xiしイ](x14)[6x28| 注記この例では層3が最下層となる。 図2 1234X5678についてのツリー [ツリーを用いた演算〕 ツリーの最下層のノードは,整数の乗算だけで計算できる。最下層以外の層は,子 ノードの計算結果を使って,次の式で計算できることが分かっている。ここで,gw, B,は,それぞれ子ノード①,©,③の乗算の計算結果を,Kは対象のノードの桁 数を表す。 wX10"+(Yーw一8)X102+8……(1) 図2のルートノードの場合,K=ニ4,a=672,B=2652,y=ニ6164なので,HH 果は次のとおりとなる。 672X10099十(6164一672一2652)x109十2652=7006652 ー17一 〔多倍長整数の乗算のプログラムJ〕 桁数が2のべき乗の多倍長整数va1,val2の乗算を行うプログラムを作成した。 プログラム中で利用する多倍長整数と,ツリーのノードは構造体で取り扱う。構千 体の型と要素を表1に示す。構造体の各要素には,構造体の変数名要素名でアクセ スできる。また,配列の添字は1から始まる。 表1構造体の型と要素 多倍長整雪|N[ek|多倍長整数の桁数 values整数の配列|桁ごとの値を管理する1次元配列。1の位の値から順に値を 格納する。配列の要素は,必要な桁を全て格納するのに十 分な数が確保されているものとする。 ノード整数ノードが取り扱う多倍長整数の桁数。図2の1234X5678の ノードの場合は4である。 多倍長整数|乗算記号の左側の値 多倍長整数|乗算記号の右側の値 多倍長整数|乗算の計算結果 多倍長整数の操作を行う関数を表2に,プログラムで使用する主な変数,配列及び 関数を表3に,与えられた二つの多倍長整数からツリーを構築するプログラムを図3 に,そのツリーを用いて演算を行うプログラムを図4に,それぞれ示す。表2,表3 中のp,a,vl,v2の型は多倍長整数である。また,図3,図4中の変数は全て大域 変数である。 表2多倍長整数の操作を行う関数 多倍長整数 多倍長整数 left(p,k)多倍長整数|pについて,valuesの添字が大きい方のk個の要素を返す。 pのvaluesが{4,3,2,1),kが2であれば,valuesが{2,1) の多倍長整数を返す。 right(p,k)多倍長整数|pについて,valuesの添字が小さい方のk個の要素を返す。 p@valuesが{4,3,2,1},kが2であれば,valuesが(4,3} の多倍長整数を返す。 多倍長整数|add(left(p,k),right(p,k))の結果を返す。 Ea 多倍長整数|pとqについて,“桁ごとの減算"を行いpqを返す。 ーー18ーー 表3使用する主な変数,配列及び関数 elements[]配列|ノードツリーのノードを管理する配列。ルートノードを先頭に,各 ーー層の左側のノードから順に要素を格納する。図2の場合は, 順で格納する。 {12345678,12X56,34X78,46X134,1X5,2X6,…)の a ee layer_top[]配列|整数ルートノードから順に,各層の左端のノードの,elements配 列上での添字の値を格納する。図2の場合は1234X5678,12 ene REE[aaaewtconec anh new_elem(k,v1,v2)|関数|ノード取り扱う多倍長整数の桁数がkで,v1Xv2の乗算を表すノー の値で,vallは1234,val2は5678 CHS, //ツリーの各層の,elements配列上での先頭インデックスを算出する Layer_top[1]<—1//ルートノードは先頭なので1を入れる for(iを1からt depth一1まで1ずつ増やす) layer_top[i+1]<layer_top[i]+ endfor //ツリーを構築する elements[1]<—new elem(val1.N,vall,val2)//ルートノードを用意。桁数はvaの桁数を使う for(dpを1からt_depth一1まで1ずつ増やす)//ルートノードの層から,最下層以外の層を順に処理 for(iを1からpow(3,dp一1)まで1ずつ増やす)//親ノードになる層の要素数だけ繰り返す peとelements[layer_top[dp]+(i一1)]//親ノードの要素を取得 cn<—pe.N/2//子ノードの桁数を算出 tidx layer_top[dp+1]+//子ノード①へのインデックス elements[tidx J]とnew_elem(cn,leftォ|,cn),left(|ヵ|,Cn)) elements[tidx+1]てnew_elem(cn,riaht(ォ|,cn),right(|a_],Cn)) elements[tidx+2]てnew elem(cn,Ladd(|ォ|,cn),lradd(|ヵ|,Cn)) endfor endfor 図3与えられた二つの多倍長整数からツリーを構築するプログラム I ーー1人9一 //最下層の計算 for(ijを1からpow(3,t_depth一1)まで1ずつ増やす)//最下層の要素数は3のt_depth一]乗個 el<—elements[layer_top[t_depth]+(i一1)]//最下層のノード mul<el.vall.values[1]*el.val2,values[1]//最下層の乗算 el.result.N<—2//計算結果は2桁の多倍長整数 el.result.values[1]で//1の位 el.result.values[2]<—mul/10//19の位 endfor //最下層以外の計算 for(dpをt_depth一1から1まで1ずつ減らす)//最下層よりーつ上の層から順に処理 for(iを1からpow(3,dp一1)まで1ずつ増やす)//各層の要素数だけ繰り返す el<—elements[layer_top[dp]+(i一1)]//計算対象のノード cidxでlayer_top[dp+1]+//子ノード①へのインデックス sl<—sub(|2__]-resutt,[|ヶ__J.resutt) s2<sub(s1,elements[cidx+1].result)//yーw一を計算 pl<shift(elements[cidx].resut,el.N)//wX10を計算 p2てshift(s2,eLN/2)//(yーw一8)X107%を計算 p3てelements[cidx+1].result//8を計算 el.result<add(add(p1,p2),p3) endfor endfor //繰り上がり処理 answer<—carry(elements[1].resut)//計算結果をanswerに格納 注記図4中の|エ|には,図3中の|エ|と同じ字句が入る。 図4ツリーを用いて演算を行うプログラム

共通の文章

ITニュース配信サービスの再構築に関する次の記述を読んで,設問に答えよ。 H社は,IT関連のニュースを配信するサービスを提供している。このたび,0Sや 開発フレームワークの保守期間終了を機に,システムを再構築することにした。 [現状のシステム構成と課題] ITニュース配信サービスでは,多くの利用者にサービスを提供するために,複数 台のサーバでシステムを構成している。配信される記事には,それぞれ固有の記事番 号が割り振られている。現状のシステム構成を図1に,ニュースを表示する画面一覧 を表1に示す。 ( tay プオォオン FW:ファイアウォールAP:アプリケーションサーバ RDB:関係データベースサーバ 図1現状のITニュース配信サービスのシステム構成 表1画面一覧 ITニュース一覧|記事に関連する画像,見出し,投稿日時を新しいものから順に一覧形式で表 示する。一覧は一定の記事数ごとにページを切り替えることで,古い記事の 一覧を閲覧することができる。 ITニュース記事|ITニュース一覧画面で記事を選択すると,この画面に遷移し,選択された記 事の見出し,投稿日時,本文及び本文内の画像を表示する。さらに,BRS れた記事と関連する一定数の記事の画像と見出しを一覧形式で表示する。 現状のシステム構成では,PC,タブレット,スマートフォン,それぞれに最適化し たWebサイトを用意している。AP Git,RDBとのデータ入出力とHTMLファイルの生 成を行っている。また,関連する記事を見つけるために,夜間にWebサーバのアクセ スログをRDBに取り込み,URL中の記事番号を用いたアクセス解析をRDB上のストア ー22一 ドドプロシージャによって行っている。 最近,利用者の増加に伴い,通勤時間帯などにアクセスが集中すると,応答速度が 遅くなったり,タイムアウトが発生したりしている。 [新システムの方針〕 この課題を解消するために,次の方針に沿った新システムの構成とする。 ・|_』Jの機能を用いて,一つのWebサイトで全ての種類の端末に最適な画面 を表示できるようにする。 ・APでの動的なHTMLの生成処理を行わかない,SPA(Single Page Application)の構 成にする。HTML,スクリプトなどのファイルはWebサーバに配置する。動的なデー タはAP DS Web APIを通して提供し,データ形式は各端末のWebブラウザ上で実 行されるスクリプトが扱いやすい|pb|とする。 ・RDBへの負荷を減らし,応答速度を短縮するために,キャッシュサーバを配置する。 ・ITニュース一覧画面に表示する記事の一覧のデータと,ITニュース記事画面に表 示する関連する記事に関するデータは,キャッシュサーバに格納する。キャッシュ サーバには,これらのデータを全て格納できるだけの容量をもたせる。その上で, 記事のデータは,閲覧されたデータをキャッシュサーバに設定したメモリの上限値 まで格納する。 ・RDBのデータベース構造と,関連する記事を見つける処理は現状の仕組みを利用す る。 APで提供するWeb APIを表2に示す。 表2 APで提供するWeb API ITNewsList表示させたいITニュース一覧画面のページ番号を受け取り,そのページに含 まれる記事の記事番号,関連する画像のURL,RAL,投稿日時のリストを返 す。データは,キャッシュサーバから取得する。 ITNewsDetail ITニュース記事画面に必要な見出し,投稿日時,本文,本文内に表示する画 像のURL,関連する記事の記事番号のリストを返す。1件の記事に対して関連 する記事は6件である。データは,キャッシュサーバに格納されている場合 はそのデータを,格納されていない場合は,RDBから取得してキャッシュサー バに格納して利用する。キャッシュするデータは①LFU方式で管理する。 ITNewsHeadtine|ITニュース記事画面に表示する,関連する記事1件分の記事に関する画像の URLと見出しを返す。データは,キャッシュサーバから取得する。 —23—_ 次に,Webブラウザ上で実行されるスクリプトの概要を表3に示す。 表3 Webブラウザ上で実行されるスクリプトの概要 ITニュース一覧表示させたいITニュース一覧画面のページ番号を指定してWeb API “ITNewsList”を呼び出し,取得したデータを一覧表として整形する。 ITニュース記事|表示させたい記事の記事番号を指定してWeb API“ITNewsDetail”を呼び 出し,対象記事のデータを取得する。次に,表示させたい記事に関連する 記事の記事番号を一つずつ指定してWeb API“ITNewsHeadline”を呼び出 し,関連する記事の表示に必要なデータを取得する。最後に,取得したデ ータを文書フォーマットとして整形する。 [キャッシュサーバの実装方式の検討] キャッシュサーバの実装方式として,次に示す二つの方式を検討する。 (1)各APの内部にインメモリデータベースとして実装する方式 (2)1台のNoSQOLデータベースとして実装する方式 APの0Sのスケジューラーが5分間隔で,ITニュース一覧画面に表示する記事の一 Bi,各記事に関連する記事の一覧のデータを更新する処理を起動する。(1)の場合, 各AP上のプロセスが内部のキャッシュデータを更新する。(2)の場合,特定のAP上 のプロセスがキャッシュデータを更新する。 なお,APのCPU使用率が高い場合,Web APIの応答速度を優先するために,更新処 理は行わない。 [応答速度の試算〕 新システムにおける応答速度を試算するために,キャッシュサーバの二つの方式を それぞれテスト環境に構築して,本番相当のテストデータを用いて処理時間を測定し た。その結果を表4に示す。 =—24一 表4テストデータを用いて処理時間を測定した結果 |sw靖 間間間間測定結果 1|WebサーバがITニュース一覧画面又はITニュース記事画面のリク89ms 80ms エストを受けてから,HTMLやスクリプトなどのファイルを全て転 送するまでの時間 2|APがWeb API“ITNewsList”のリクエストを受けてから,応答デ100ms 200ms ータを全て転送するまでの時間 3|APがWeb API“ITNewsDetail”でリクエストされた対象記事のデ60%90% ータがキャッシュサーバに格納されている割合 4|APがWeb API“ITNewsDetail”のリクエストを受けてから,キャ120ms ッシュサーバにある対象記事のデータを全て転送するまでの時間 5|APがWeb API“ITNewsDetail”のリクエストを受けてから,RDBに300ms 300ms ある対象記事のデータを全て転送するまでの時間 APがWeb API“ITNewsHeadline?のリクエストを受けてから,応15ms 20ms 答データを全て転送するまでの時間 注記ms:ミリ秒 インターネットを介した転送時間やWebブラウザ上の処理時間は掛からないと仮定 して応答時間を考える。その場合,ITニュース一覧画面を初めて表示する場合の応 答時間は,方式(1)では189ms方式(2)では|cc|msである。TITニュース一覧 画面のページを切り替える場合の応答時間は,方式(1)では100ms,方式(2)では |39|msである。次に,記事をリクエストした際の平均応答時間を考える。 Web API“ITNewsDetail”の平均応答時間は,方式(1)では156ms,方式(2)では |e lm CHS,したがって,Web API“ITNewsHeadline”の呼び出しも含め たITニュース記事画面を表示するための平均応答時間は,方式①)では|f|] ms,方式(2)では258msとなる。 以上の試算から,方式(1)を採用することにした。 〔不具合の指摘と改修] 新システムの方式(1)を採用した構成についてレビューを実施したところ,ROH 摘があった。 (1)ITニュース記事画面の応答速度の不具合 ITニュース記事画面を生成するスクリプトが実際にインターネットを介して実 行された場合,試算した応答速度より大幅に遅くなってしまうことが懸念される。 Web API“| g|”内から,Web API"|h|を呼び出すように 処理を改修する必要がある。 (2)APのCPU使用率が高い状態が続いた場合の不具合 APに処理が偏ってCPU使用率が高い状態が続いた場合,②ある画面の表示内容 に不具合が出てしまう。 この不具合を回避するためには,各APのCPU使用率を監視して,しきい値を超 えた状態が一定時間以上続いた場合,APをスケールアウトして負荷を分散させる 仕組みをあらかじめ用意する。 (3)関連する記事が取得できない不具合 関連する記事を見つける処理について,③現状の仕組みのままでは関連する記事 が見つけられない。Webサーバのアクセスログを解析する処理を,APのアクセスロ グを解析する処理に改修する必要がある。 以上の指摘を受けて,必要な改修を行った結果,新システムをリリースできた。

共通の文章

Webサイトの増設に関する次の記述を読んで,設問に答えよ。 F社は,契約した顧客(以下,顧客という)にインターネット経由でマーケット情 報を提供する情報サービス会社である。「F社では,マーケット情報システム(LE, Mシステムという)で顧客向けに情報を提供している。Mシステムは,Webアプリケ ーションサーバ(以下,WebAPサーバという),DNSサーバ,ファイアウォール(以下, FWという)などから構成されるWeb+7 KX社の運用PCから構成される。現在, Webサイトは,B社のデータセンター(以下,b-DCという)に構築されている。 現在のMシステムのネットワーク構成(抜粋)を図1に,DNSサーバbに登録され ているAレコードの情報を表1に示す。 PPGーーーニニーーーニニーーニニニーニーニーニニーーっ '[Wepp||pms|Neb bby !|サーバM||サーバb 1 i !: !DMZ 192,168.0.0/24 7 me L2SW:レイヤー2スイッチに L3SW:レイヤー3スイッチGia—9® 広域イーサ網:広域イーサネットサービス網 [dwトー[rw} 図1現在のMシステムのネットワーク構成(抜粋) 表1 DNSサーバbに登録されているAレコードの情報 |1|DWSサーパb|rsbamplejp|200aki79| 注記1 209.x.y.z(x,y,zは,0~255 OBR)のIPアドレスは,グローバルアドレスである。 注記2各リソースレコードのTTL(Time To Live)は,604800が設定されている。 [Mシステムの構成と運用]〕 ・Mシステムを利用するにはログインが必要である。 ・FWbには,DMZに設定されたプライベートアドレスとインターネット向けのグロー バルアドレスを1対1で静的に変換するNATが設定されており,表1に示した内容 で,WebAPサーバb及びDNSサーバbのIPアドレスの変換を行う。 ・DNSサーバbは,インターネットに公開するドメインexample.jpと「社の社内向け のドメインf-sha.example.lanの二つのドメインのゾーン情報を管理する。 ・F社のL3SWの経路表には,b-DCのWebサイトbへの経路と①デフォルトルートが 登録されている。 ・運用PCには,②優先DNSサーバとして,FQDNがnsb.f-sha.example.lanのDNS+ ーバbが登録されている。 ・F社の運用担当者は,運用PCを使用してMシステムの運用作業を行う。 【Mシステムの応答速度の低下〕 mil,MEDS,Mシステムの応答が遅くなることがあるという苦情が,Mシステ ムのサポート窓口に入ることが多くなった。そこで,F社の情報システム部(LUE, システム部という)の運用担当者のD主任は,運用PCを使用して次の手順で原因究 明を行った。 (i)顧客と同じURLであるhttps://| 』。|/でWebAPサーバbにアクセスし, 顧客からの申告と同様の事象が発生することを確認した。 (ii)FWbのログを検査し,異常な通信は記録されていないことを確認した。 (iii)SSHを使用し,③広域イーサ網経由でWebAPサーバbにログインしてCPU使用 率を調べたところ,設計値を超えた値が継続する時間帯のあることを確認した。 この結果から,D主任は,WebAPサーバbの処理能力不足が応答速度低下の原因で あると判断した。 (Webサイトの増設 D主任の判断を基に,システム部では,これまでのシステムの構築と運用の経験を 生かすことができる,現在と同一構成のWebサイトの増設を決めた。システム部のE 課長は,C社のデータセンター(LAF,c-DCという)にWebサイトcを構築してMシ ステムを増強する方式の設計を,D主任に指示した。 ー29— D主任は,c-DCにb-DCと同一構成のWebサイトを構築し,DNSラウンドロビンを利 用して二つのWebサイトの負荷を分散する方式を設計した。 D主任が設計した,Mシステムを増強する構成を図2に示す。 bDCLL 2 i Web b|Web 1 |ebサイトebサイney ieサーバ| ott|サーバ!ia une |! '“|L 1 iDMZ 192.168.0.0/24 iDMZ__192.168.1.0/24) su}-—L et} M2 Mシステムを増強する構成 図2の構成では,DNSサーバbをプライマリDNSサーバ,DNSサーバcをセカンダ リDNSサーバに設定する。また,運用PCには,新たに| b|を代替DNSサーバ に登録して。|b|も利用できるようにする。 そのほかに,L3SWの経路表にWebサイトcのDMZへの経路を追加する。 DNSサーバbに追加登録するAレコードの情報を表2に示す。 表2 DNSサーバbに追加登録するAレコードの情報 |4|Webarサーバc|ac.fosha,example,tan|192.168.1.224| 注記各リソースレコードのTTLは,表1と同じ604800を設定する。 表2の情報を追加登録することによって,WebAPサーバb,cが同じ割合で利用され るようになる。DNSサーバb,cには| c|転送の設定を行い,DNSサーバbの =30— 情報を更新すると,その内容がDNSサーバcにコピーされるようにする。 WebAPサーバのメンテナンス時は,作業を行うWebサイトは停止する必要があるの で,次の手順で作業を行う。④メンテナンス中は,一つのWebサイトでサービスを提 供することになるので,Mシステムを利用する顧客への影響は避けられない。 (i)事前にDNSサーバbのリソースレコードの| q|を小さい値にする。 (ii)メンテナンス作業を開始する前に,メンテナンスを行うWebサイトの,インタ ーネットに公開するドメインのWebAPサーバのFQDNに対応するAレコードを, DNSサーバb上で無効化する。 (iii)COR,一定時間経てばメンテナンス作業が可能になるが,作業開始が早過ぎ ると顧客に迷惑を掛けるおそれがある。そこで,⑤手順(ii)でAレコードを無効 化したWebAPサーバの状態を確認し,問題がなければ作業を開始する。 D主任は,検討結果を基に作成したWebサイトの増設案を,E課長に提出した。増 設案が承認され実施に移されることになった。

共通の文章

KPI達成状況集計システムの開発に関する次の記述を読んで,設問に答えよ。 G社は,創立29年を迎えた従業員509人規模のソフトウェア開発会社である。G社 では,顧客企業や業種業界の変化に応じた組織変更を行ってきた。また,スキルや業 務知識に応じた柔軟な人事異動によって,人材の流動性を高めてきた。 G社の組織は,表1の例に示すように最大三つの階層から構成されている。 従業員の職務区分には管理職,一般職の二つがあり,1階層から3階層のそれぞれ の組織には1名以上の従業員が所属している。なお,複数階層,複数組織の兼務は行 わない規定であり,従業員は一つの組織だけに所属する。 表1 G社の組織の例 組織の説明 |監査室=|一| -|単独階層の組織 |総務部””。|人事課。”。CO全社共通のスタッフ組織 技術開発部オープンソース推進課|—-|全社共通の開発組織 金融システム本部証券開発課|業種業界ごとの開発組織 (KPIの追加〕 G社では,仕事にメリハリを付け,仕事の質を向上させることが,6社の業績向上 につながるものと考え,従来のKPIに加え,働き方改革,従業員満足度向上に関する KPIの項目を今年度から追加することにした。追加したKPIの項目を表2に示す。 表2追加したKPIの項目 定量的成果目標 年間総労働、・一般職従業員の個人実績を組織単位で集計し,平均値の 時間1,980時間以内人|人成状況を評価する。 RAB・年度途中入社,年度途中退職した従業員は,評価対象外 加取得晶数16日以上人とする。 ー・個人実績の集計は,集計日時点で従業員の所属している _-6日以上人_- 年間研修受、直属の組織に対して行う。所属組織の上位階層,又は下 講日数位階層の組織の集計には含めない。 追加したKPIの達成状況を把握し,計画的な目標達成を補助するためにKPI達成状 況集計システム(以下,Kシステムという)を開発することになり,H主任が担当と 32= なった。 Kシステムでは,次に示す仕組みと情報を提供する。 ・従業員各人が,月ごとの目標を設定する仕組み ・日々の実績を月次で集計し,各組織がKP1I達成状況を評価するための情報 [データベースの設計〕 G社では,組織変更と人事異動を管理するためのシステムを以前から運用している。 H主任は,このシステムのためのE-R図を基に,KPIとその達成状況を把握するため に,KPI,月別個人目標,及び日別個人実績の三つのエンティティを追加して,Kシ ステムのためのE-R図を作成することにした。 作成したE-R図(抜粋)を図1に示す。Kシステムでは,このE-R図のエンティテ ィ名を表名に,属性名を列名にして,適切なデータ型で表定義した関係データベース によってデータを管理する。 組織コード従業員コード役職コード 組織開始年月日| a』|所属開始年月日役職名 組織終了年月日所属終了年月日職務区分 組織名所属組織コード 上位組織コード所属組織開始年月日日別個人実績 土位組織開始年月日役職コード従業員コード 従業員年月日 ーーーー L_5]ERED 氏名 月別個人目標生年月日IKE 従業員コードメールアドレス||PLコード KPIコード住所年度 年月KPI項目名 月別目標値定量的成果目標 注記属性名の実線の下線__.は主キー,os iia 破線の下線___は外部キーを示す。属性名—>:1対多 主キーの実線が付いている属性名には,属性名<>:多対多 外部キーの破線を付けない。Rae one 図1 KシステムのためのE-R図(抜粋) ee 33 a 追加した三つのエンティティを基に新規に作成された表の管理内容と運用方法を表 3に示す。 表3表の管理内容と運用方法 KPI項目と定量的成ーーPAL ・年度開始時点で在籍している全従業員に対して,当該年 度分のレコードを,目標値を9として初期作成する。 ・初期作成したレコードに対して,各人で定量的成果目標 _|個人ことの月別目を意識した月別目標値を入力し,定期的に見直し,更新 月別個人目標標値を管理するする。 :・年度途中入社の従業員については,初期作成レコードが 存在しない。月別目標値の入力も行わない。 ・管理職従業只はKPI評価対象外であるが,月別目標値の 入力は一般職従業員と同様に行う。 ・勤怠管理システム,研修管理システムで管理している追 日別個人実績個人ごとの日別実加したKPI項目に関する全従業員の実績値を基に,日次 績値を管理する。バッチ処理によってレコードを作成する。 ・日別実績のない従業員のレコードは作成しない。 組織,所属,HHS,及び役職の各表は,以前から運用しているシステムから継承 したものである。組織表と所属表では,組織や所属に関する開始年月日と終了年月日 を保持し,現在を含む,過去から未来に至るまでの情報を管理している。 組織表の“組織終了年月日"と所属表の“所属終了年月日"には,過去の実績値, 又は予定を設定する。終了予定のない場合は9999年12月31日を設定する。 なお,組織表の“上位組織コード","上位組織開始年月日"には,1階層組織では NULLを,2階層組織と3階層組織では一つ上位階層の組織の組織コード,組織開始年 月日を設定する。また,役職表の職務区分"の値は,管理職の場合に01’,一般職 の場合に'92"とする。 [達成状況集計リストの作成 H主任は,SHARED KPI達成状況を評価するための情報として,毎月末に達成状況 集計リスト(以下,集計リストという)を作成し,提示することにした。 集計リスト作成は,オンライン停止時間帯の日次バッチ処理終了後の月次バッチ処 理によって,処理結果を一時表に出力して後続処理に連携する方式で行うことにした。 ー34一 集計リスト作成処理の概要を表4に示す。 表4集計リスト作成処理の概要 |!|所属役職|従業員所属一時|一般職従業員と所属組織の対応表を作成する。。| ee従業員ごと目標集|年度開始年月から集計月までの従業員,KPI項目ごとの目 ™“計一時標個人集計値を求める。 従業員ごと実績集|年度開始年月日から集計日までの従業員,KPI項目ごとの 組織ごと目標実績|組織。KPI項目ごとの目標集計値,実績集計値,従業員数 組織,KPI項目ごとの目標集計値,実績集計値,従業員 項番4の出力表数,目標平均値,実績平均値を一覧化した集計リストを 作成する。 集計リスト作成処理のSQL文を図2に示す。ここで,TO_DATE関数は,指定され た年月日をDATE型に変換するユーザー定義関数である。関数COALESCE(A,B)は,A がNULLでないときはAを,AがNULLのときはBを返す。また,『":年度開始年月日", ”":年度開始年月",“:集計年月日",“:集計年月”"は,該当の値を格納する埋込み変 数である。 H主任は,図2の項番4のSQL文の設計の際に,次に示す考慮を行った。 ・表2の評価方法に従い,管理職の従業員データは対象に含めず,年度途中入社と, 年度途中退職の従業員データについては出力しないように,抽出日に退職している 従業員データを出力しない“従業員所属_一時表”と,年度開始時点で入社してい ない従業員データを出力しない“従業員ごと"目標集計一時表”を よって結合しておく。 [|<Jieる結合結果と,実績がある場合だけレコードの存在する“従業員 ごと実績集計一時表"を| d|によって結合しておく。また,①実績個人 集計がNULLの際は,0を設定しておく。 —_35— INSERT INTO従業員所属一時(従業員コード,組織コード) SELECT A.従業員コード,A.所属組織コードFROM所属A,役職B WHERE 10_DATE(:集計年月日)|e|ん所属開始年月日ANDA.所属終了年月日 AND A.役職コード=B.役職コードAND INSERT INTO従業員ごと目標集計一時(従業員コード,KPIコード,目標個人集計) SELECT従業員コード,KPIコード,SUM(月別目標値)FROM月別個人目標 <WHERE年月| e|:年度開始年月AND:集計年月 INSERT INTO従業員ごと実績集計_一時(従業員コード,KPIコード,実績個人集計) SELECT従業員コード,KPIコード,SUM(日別実績値)FROM日別個人実績 WHERE年月日|。|TO_DATE(:年度開始年月日)AND TO_DATE(:集計年月日) INSERT INTO (組織コード,KPIO—k,目標組織集計,実績組織集計,対象従業員数) SELECT A.組織コード,B.KPIコード,SUM(B.目標個人集計), SUM(COALESCE(.実績個人集計,9)),|」| FROM従業員_所属_一時A 従業員ごと目標集計一時B ON A.従業員コード=B.従業員コード [a ]従業員ごと.実績集計一時C ON B.従業員コード=C.従業員コードAND B.KPIコード=C.KPIコード GROUP BY A.組織コード,B.KPIコード SELECT A.*,A.目標組織集計/A.対象従業員数,A.実績組織集計/A.対象従業員数 FROM A ORDER BY A.組織コード,A.KPIコード 図2集計リスト作成処理

共通の文章

位置通知タグの設計に関する次の記述を読んで,設問に答えよ。 E社は,GPSを使用した位置情報システムを開発している。今回,超小型の位置通 知タグ(以下,PRTという)を開発することになった。 PRT ld,ペンダント,ブレスレット,バッジなどに加工して,FR,老人などに持 たせたり,ペット,荷物などに取り付けたりすることができる。利用者はスマート フォン又はPC(以下,端末という)を用いて,PRTの現在及び過去の位置を地図上 で確認することができる。 PRTの通信には,通信事業者が提供するIoT用の低消費電力な無線通信回線を使用 する。また,PRTは本体内に小型の電池を内蔵しており,ワイヤレス充電が可能であ る。長時間の使用が要求されるので,必要な時間に必要な構成要素にだけ電力を供 給する電源制御を行っている。 位置情報システムの構成 PRTを用いた位置情報システムの構成を図1に示す。 ー <I> 図1 PRTを用いた位置情報システムの構成 端末がPRTに位置情報を問い合わせたときの通信手順を次に示す。 ①端末は,PRIの最新の位置を取得するための位置通知要求をサーバに送信する。 サーバは端末からの位置通知要求を受信すると,通信事業者を介して,PRTと通信 可能な基地局に位置通知要求を送信する。 ②PRTは電源投入後,基地局から現在時刻を取得するとともに,サーバからの要求 を確認する時刻(以下,要求確認時刻という)を受信する。以降の要求確認時刻 はサーバから受信した要求確認時刻から40秒間隔にスケジューリングされる。 PRTは要求確認時刻になると,基地局からの情報を受信する。 ③基地局は要求確認時刻になると,PRIへの位置通知要求があればそれを送信する。 ④PRTは基地局からの情報に位置通知要求人含まれているかを確認する処理(以下 ー38—| 確認処理という)を行い,位置通知要求が含まれていると,基地局,通信事業者 を介して,PRTの最新の位置情報をサーバに送信する。 ©サーバはPRTから位置情報を受信し,管理する。サーバは端末と通信し,PRTの 最新の位置情報,指定された時刻の位置情報を地図情報とともに端末に送信する。 端末は,受信した位置情報及び地図情報を基に,PRTの位置を地図上に表示する。 (PRTのハードウェア構成 PRTのハードウェア構成を図2に,PRTの構成要素を表1に示す。 通信ライン ||制御信号 注記太線は,電力供給線を示している。 図2 PRTのハードウェア構成 表1 PRTの構成要素 ・タイマー,CPU,メモリなどから構成され,PRT全体の制御を行う。 ・CPUの動作モードには,実行モード及び休止モードがある。実行モードでは命令の実行が 制御部できる。休止モードでは命令の実行を停止し,消費電流が最小となる。 ・CPUは休止モードのとき,タイマー,測位モジュール,通信モジュールからの通知を検出 すると実行モードとなり,必要な処理が完了すると休止モードとなる。 ・GPS信号を受信(以下,測位という)してPRTの位置を取得し,位置情報を作成する。 ・電力が供給され,測位可能になると制御部に測位可能通知を送る。 測位モジュール|・制御部からの測位開始要求を受け取ると測位を開始する。測位の開始から6秒経過する と測位が完了して,測位結果(PRTの位置取得時の位置情報又はPRTの位置取得失敗)を 測位結果通知として制御部に送る。 ・基地局との通信を行う。 ・電力が供給され,通信可能になると制御部に通信可能通知を送る。 通信モジュール|・制御部から受信要求を受け取ると,確認処理を行い,制御部へ受信結果通知を送る。 ・制御部から送信要求を受け取ると,該当するデータをサーバに送信する。データの送信 が完了すると,送信結果通知を制御部に送る。 ・制御部と測位モジュールとの間,又は制御部と通信モジュールとの間の通信を行うとき 通信ラインに使用する。 ・通信モジュールとの通信と,測位モジュールとの通信が同時に行われると,そのときの データは正しく送受信できずに破棄される。 電源部・制御部からの制御信号によって,測位モジュール及び通信モジュールへの電力の供給を ies開始又は停止する。 (PRTの動作仕様 ・49秒ごとに確認処理を行い,基地局から受信した情報に位置通知要求が含まれて いる場合,測位中でなければ,測位を開始する。測位の完了後,PRTの位置を取得 したら位置情報を作成する(以下,測位の開始から位置情報の作成までを測位処 理という)。測位処理完了後,位置情報をサーバに送信する。また,測位の完了後 PRTの位置取得に失敗したときは,失敗したことをサーバに送信する。 ・120秒ごとに測位処理を行う。失敗しても再試行しない。 ・690秒ごとに未送信の位置情報をサーバに送信する(以下,データ送信処理とい hs (468 FAT BE Bes Fa) 電池を満充電後,PRTが機能しなくなるまでの時間を使用可能時間という。その間 に放電する電気量を電池の放電可能容量といい,単位はミリアンペア時(mAh)CH BH.PRTは放電可能容量が299mAhの電池を内蔵している。 使用可能時間,放電可能容量,PRTの平均消費電流の関係は,次の式のとおりであ る。 使用可能時間=放電可能容量+PRTの平均消費電流 PRTが基地局と常に通信が可能で,測位が可能であり,基地局から受信した情報に 位置通知要求含まれていない状態における各処理の消費電流を表2に示す。表2 の状態が継続した場合の使用可能時間は| a|時間である。 なお,PRTはメモリのデータの保持などで,表2の処理以外に9.91mAの電流が常 に消費される。 表2各処理の消費電流 lmmam AD) wm|画| =e 〔制御部のソフトウェア] 最初の設計ではタイマーを二つ用いた。初期化処理で,120秒ごとに通知を出力す る測位用タイマーを設定し,初期化処理完了後,サーバからの要求確認時刻を受信 すると,49秒ごとに通知を出力する通信用タイマーを設定した。しかし,この設計 では不具合が発生することがあった。 不具合を回避するために,タイマーを複数用いず,要求確認時刻を用いて49秒ご とに通知を出力するタイマーだけを設定した。このタイマーを用いて,図3に示す タイマー通知時のシーケンス図に従った処理を実行するようにした。 構成要素 前回の通信から49秒経過1通信モジュール ::LL leas- 6 6<x ve IH H通信可能通知* しーー|ian 9-抽和部の活性区癌では, a、W Uは実行モードである。 9受信結果通知0_;制御部以外の活性区間で 1||男信モジュール||は,そのモジュールには電 a電源オフ力が供給される。 前回の測位から1296秒経過又は位置通知要求あり測位モジュール|条件| 8 let att 1 7条件成立時に |dd ee処理される 測位開始要求i 1) 測位結果通知1 1|ea 測位モジュール 0電源オン Yee ya 0 i)[] i]6 :Pc| |mm|| 送信結果通知、7 通信モジュール 0 LL|電源オフ 図3タイマー通知時のシーケンス図

共通の文章

バージョン管理ツールの運用に関する次の記述を読んで,設問に答えよ。 A社は,業務システムの開発を行う企業で,システムの新規開発のほぼほか,リリース 後のシステムの運用保守や機能追加の案件も請け負っている。A社では,ソースコー ドの管理のために,バージョン管理ツールを利用している。 バージョン管理ツールには,1人の開発者がファイルの編集を開始するときにロッ クを獲得し,他者による編集を禁止する方式(以下,ロック方式という)と,編集は 複数の開発者が任意のタイミングで行い,編集完了後に他者による編集内容とマージ する方式(以下,。コピー・マージ方式という)FHS,Zh,バージョン管理ツウール には,ある時点以降のソースコードの変更内容の履歴を分岐させて管理する機能があ る。以降,分岐元,及び分岐して管理される,変更内容の履歴をブランチと呼ぶ。 ロック方式では,編集開始時にロックを獲得し,他者による編集を禁止する。編集 終了時には変更内容をリポジトリに反映し,ロックを解除する。ロック方式では,一 つのファイルを同時に1人しか編集できないので,複数の開発者で開発する際に変更 箇所の競合が発生しない一方,①開発者間で作業の待ちが発生してしまう場合がある。 A社では,規模の大きな改修に複数人で取り組むことも多いので,コピー・マージ 方式のバージョン管理ツールを採用している。A社で採用しているバージョン管理ツ ールでは,開発者は,社内に設置されているバージョン管理ツールのサーバ(以下, サーバという)のリポジトリの複製を,開発者のPC上のローカル環境のリポジトリ として取り込んで開発作業を行う。編集時にソースコードに施した変更内容は,ロー カル環境のリポジトリに反映される。ローカル環境のリポジトリに反映された変更内 Bit,編集完了時にサーバのリポジトリに反映させる。サーバのリポジトリに反映さ れた変更内容を,別の開発者が自分のローカル環境のリポジトリに取り込むことで, 変更内容の開発者間での共有が可能となる。 コピー・マージ方式では,開発者間で作業の待ちが発生することはないが,他者の 変更箇所と同一の箇所に変更を加えた場合には競合が発生する。その場合には,ソー スコードの変更内容をサーバのリポジトリに反映させる際に,競合を解決する必要が ある。競合の解決とは,同一箇所が変更されたソースコードについて,それぞれの変 更内容を確認し,必要に応じてソースコードを修正することである。 A社で使うバージョン管理ツールの主な機能を表1に示す。 ー44一 表1 A社で使うバージョン管理ツールの主な機能 ブランチ作成|あるブランチから分岐させて,新たなブランチを作成する。 プルサーバのリポジトリに反映された変更内容を,ローカル環境のリポジトリに反 映させる。 ソースコードの変更内容を,ローカル環境のリポジトリに反映させる。 ローカル環境において,あるブランチでの変更内容を,他のブランチに併合す る。 プッシュローカル環境のリポジトリに反映された変更内容を,サーバのリポジトリに反 映させる。 リバート指定したコミットで対象となった変更内容を打ち消す変更内容を生成し,ロー カル環境のリポジトリにコミットして反映させる。 注記A社では,ローカル環境での変更内容を,サーバのリポジトリに即時に反映させるために, コミット又はマージを行ったときに,併せてプッシュも行うことにしている。 [ブランチ運用ルール〕 開発案件を担当するプロジェクトマネージャのMI氏は,ブランチの運用ルールを決 めてバージョン管理を行っている。取り扱うブランチの種類を表2に.ブランチの運 用ルールを図1に,ブランチの樹形図を図2に示す。 表2ブランチの種類 システムの運用環境にリリースする際に用いるソースコードを,永続的に管理する デラYF, このブランチへの反映は,他のブランチからのマージによってだけ行われ,TOT ランチで管理するソースコードの直接の編集,コミットは行わない。 develop開発の主軸とするブランチ。開発した全てのソースコードの変更内容をマージした 状態とする。 mainブランチと同じく,このブランチ上で管理するソースコードの直接の編集,コ ミットは行わない。 feature開発者が個々に用意するブランチ。担当の機能についての開発とテストが完了した ら,変更内容をdeveloppブランチにマージする。その後に不具合が検出された場合 は,このブランチ上で確認・修正し,BR developブランチにマージする。 releaseリリース作業用に一時的に作成・利用するブランチ。developブランチから分岐させ て作成し,このブランチのソースコードで動作確認を行う。不具合が検出された場 合には,このブランチ上で修正を行う。 ・開発案件開始時に,mainブランチからdevelopブランチを作成し,サーバのリポジトリに反 映させる。 ・開発者は,サーバのリポジトリの複製をローカル環境に取り込み,。ローカル環境でdevelop ブランチからfeatureブランチを作成する。ブランチ名は任意である。 ・featureブランチで機能の開発が終了したら,開発者自身がローカル環境でテストを実施す る。 ・開発したプログラムについてレビューを実施し,問題がなければfeatureブランチの変更内 容をローカル環境のdeveloppブランチにマージしてサーバのリポジトリにプッシュする。 ・サーバのdevelopブランチのソースコードでテストを実施する。問題が検出されたら,ロー カル環境のfeatureブランチで修正し,RRNA developブランチに再度マージしサーバ のリポジトリにプッシュする。テスト完了後,featureブランチは削除する。 ・開発案件に関する全てのfeatureブランチがサーバのリポジトリのdevelopブランチにマー ジされ,テストが完了したら,サーバのdevelopブランチをローカル環境にプルしてから releaseブランチを作成し,テストを実施する。検出された問題の修正はreleaseブランチ で行う。テストが完了したら,変更内容を|。|ブランチと[|b|ブランチにマ ージし,サーバのリポジトリにプッシュして,releaseブランチは削除する。 図1ブランチの運用ルール main凡例 〇Oコミット develop*iS ae feature Xプランチの削除 4Aテストの実施 release az Aレビューの実施 図2ブランチの樹形図 〔開発案件と開発の流れ〕 A社が請け負ったある開発案件では,A,B,Cの三つの機能を既存のリリース済の システムに追加することになった。 A,B,Cの三つの追加機能の開発を開始するに当たり,開発者2名がアサインされ た。機能AとCは1氏が,機能BはK氏が開発を担当する。開発の流れを図3に示す。 — _ rsrs—C™~™~—S develop feature-A O—0—0—0007-% feature-Cーー一で一Ox大 (ryt)4 a feature-B O O O O COー一〇O—O—0- re lease O O 図3開発の流れ I氏は,機能Aの開発のために,ローカル環境で|a|ブランチから feature-Aブランチを作成し開発を開始した。1氏は,機能Aについて(ア),(9), (オ)の3回のコミットを行ったところで,(ウ)でコミットした変更内容では問題があ ることに気が付いた。そこで1氏は,(gw)のタイミングで,②(ア)のコミットの直後 の状態に滞りなく戻すための作業を行い,編集をやり直すことにした。プログラムに 必要な修正を加えた上で| c|した後,③テストを実施し,問題がかいことを 確認した。その後,レビューを実施し,| 』|ブランチにマージした。 機能Bは機能Aと同時に開発を開始したが,規模が大きく,開発の完了は機能A, Cの開発完了後になかった。K氏は,機能Bについてのテストとレビューの後,ローカ ル環境上の|a|ブランチにマージし,サーバのリポジトリにプッシュしよう としたところ,競合が発生した。サーバのリポジトリから| a』|ブランチをプ VL,その内容を確認して競合を解決した。その後,ローカル環境上の|。| ブランチを,サーバのリポジトリにプッシュしてからテストを実施し,問題がないこ とを確認した。 全ての変更内容をdevelopブランチに反映後,releasesブランチをdevelopブラン チから作成して④テストを実施した。テストで検出された不具合を修正し,release ブランチにコミットした後,再度テストを実施し,問題がないことを確認した。修正 内容を|a|プランチと|b|プランチにマージし,|[bp|ブラン チの内容でシステムの運用環境を更新した。 〔運用ルールについての考察〕 feature-Bブランチのように,ブランチ作成からマージまでが長いと,サーバのリ ポジトリ上のdevelopブランチとの差が広がり,競合が発生しやすくなる。そこで, レビュー完了後のマージで競合が発生しにくくするために,随時,サーバのリポジト リからdevelopブランチをプルした上で,⑤ある操作を行うことを運用ルールに追加 した。

共通の文章

金融機関システムの移行プロジェクトに関する次の記述を読んで,設問に答えよ。 P社は,本店と全国39か所の支店(以下,拠点という)から成る国内の金融機関 である。P tit,土日祝日及び年末年始を除いた日(以下,営業日という)に営業を している。P社では,金融商品の販売業務を行うためのシステム(以下,販売支援シ ステムという)をオンプレミスで運用している。 販売支援システムは,営業日だけ稼働しており,拠点の営業員及び拠点を統括する 商品販売部の部員が利用している。販売支援システムの運用・保守及びサービスデス クは,情報システム部運用課(以下,運用課という)が担当し,サービスデスクが解 決できない問合せのエスカレーション対応及びシステム開発は,情報システム部開発 課(以下,開発課という)が担当する。 販売支援システムのハードウェアは,P社内に設置されたサーバ機器,拠点の端末, 及びサーバと端末を接続するネットワーク機器で構成される。 販売支援システムのアプリケーションソフトウェアのうち,中心となる機能は,X 社のソフトウェアパッケージ(以下,Xパッケージという)を利用しているが,Xパ ッケージの標準機能で不足する一部の機能は,Xパッケージをカスタマイズしている。 販売支援システムのサーバ機器及びXパッケージはいずれも来年3月末に保守契約 の期限を迎え,いずれも老朽化しているので以後の保守費用は大幅に上昇する。そこ で,P社は,本年4月に,クラウドサービスを活用して現状のサーバ機器導入に関す る構築期間の短縮やコストの削減を実現し,さらにXパッケージをバージョンアップ して大幅な機能改善を図ることを目的に移行プロジェクトを立ち上げた。X社から, 今回適用するバージョンは,0Sやミドルウェアに制約があると報告されていた。 開発課の0課長が,移行プロジェクトのプロジェクトマネージャ(PM)に任命され, 移行プロジェクトの計画の作成に着手した。0課長は,開発課のR主任に現行の販売 支援システムからの移行作業を,同課の3S主任に移行先のクラウドサービスでのシス テム構築,移行作業とのスケジュールの調整などを指示した。1 [ステークホルダの要求〕 Q課長は,移行プロジェクトの主要なステークホルダを特定し,その要求を確認す ることにした。 =By)= 経営層からは,保守契約の期限前に移行を完了すること,顧客の個人情報の漏えい 防止に万全を期すこと,重要なリスクは組織で迅速に対応するために経営層と情報共 有すること,クラウドサービスを活用する新システムへの移行を判断する移行判定基 準を作成すること,が指示された。 商品販売部からは,5拠点程度の単位で数回に分けて切り替える段階移行方式を採 用したいという要望を受けた。商品販売部では,過去のシステム更改の際に,全拠点 で一斉に切り替える一括移行方式を採用したが,移行後に業務遂行に支障が生じたこ とがあった。その原因は,サービスデスクでは対応できない問合せが全拠点から同時 に集中した際に,システム更改を担当した開発課の要員が新たなシステムの開発で繁 忙となっていたので,エスカレーション対応する開発課のリソースがひっ人迫し,BA せの回答が遅くなったことであった。また,切替えに伴う拠点での営業日の業務停止 は,各拠点で特別な対応が必要になるので避けたい,との要望を受けた。 運用課からは,移行後のことも考えて移行プロジェクトのメンバーと緊密に連携し たいとの話があった。 情報システム部長は,段階移行方式では,各回の切替作業に3日間を要するので, 拠点との日程調整が必要となること,及び新旧システムを並行して運用することによ って情報システム部の負担が過大になることを避けたいと考えていた。 [プロジェクト計画の作成〕 Q課長は,EF,ステークホルダマネジメントについて検討した。Q課長は経営層, 商品販売部及び情報システム部が参加するステアリングコミッティを設置し,移行プ ロジェクトの進捗状況の報告,重要なリスク及び対応方針の報告,最終の移行判定な ざごを行うことした。 Ric,0課長は,移行方式について,全拠点で一斉に切り替える①一括移行方式を 採用したいと考えた。そこで,0課長は,商品販売部に,サービスデスクから受ける エスカレーション対応のリソースを拡充することで,移行後に発生する問合せに迅速 に回答することを説明して了承を得た。 現行の販売支援システムのサーバ機器及びXパッケージの保守契約の期限である来 年3月末までに移行を完了する必要がある。0課長は,移行作業の期間も考慮した上 で,切替作業に問題が発生した場合に備えて,年末年始に切替作業を行うことにした。 ー51一 0課長は,移行の目的や制約を検討した結果,1aaS型のクラウドサービスを採用す ることにした。1aaSベンダーの選定に当たり,0課長は,S主任に,新システムのセ キュリティインシデントの発生に備えて,セキュリティ対策をP社セキュリティポリ シーに基づいて策定することを指示した。S主任は,候補となるlaaベンダーの技 術情報を基に,セキュリティ対策を検討すると回答したが,0課長は,②具体的なセ キュリティ対策の検討に先立って実施すべきことがあるとS主任に指摘した。$主任 ld,課長の指摘を踏まえて作業を進め,セキュリティ対策を策定した。 最後に,0課長は,これまでの検討結果をまとめ,IaaSベンダーに③RFPを提示し, 受領した提案内容を評価した。その評価結果を基にW社を選定した。 0課長は,これらについて経営層に報告して承認を受けた。 [移行プロジェクトの作業計画 R主任と$主任は協力して,移行手順書の作成,移行ツールの開発,移行総合テス ト,営業員の教育・訓練及び受入れテスト,移行リハーサル,本番移行,並びに移行 後の初期サポートの各作業の検討を開始した。各作業は次のとおりである。 (1)移行手順書の作成 移行に関わる全作業の手順書を作成し,関係するメンバーでレビューする。 (2)移行ツールの開発 移行作業の実施に当たって,データ変換ツール,構成管理ツールなどのX社提供 の移行ツールを活用するが,Xパッケージをカスタマイズした機能に関しては,X 社提供のデータ変換ツールを利用することができないので,移行に必要なデータ変 換機能を開発課が追加開発する。 (3)移行総合テスト 移行総合テストでは,移行ツールが正常に動作し,移行手順書どおりに作業でき るかを確認した上で,移行後のシステムの動作が正しいことを移行プロジェクトと して検証する。R主任は,より本番移行に近い内容で移行総合テストを実施する方 が検証漏れのリスクを軽減できると考えた。ただし,P社のテスト規定では,個人 情報を含んだ本番データはテスト目的に用いないこと,本番データをテスト目的で 用いる場合には,その必要性を明らかにした上で,個人情報を個人情報保護法及び 関連ガイドラインに従って匿名加工情報に加工する処置を施して用いること,と定 =Bb= められている。そこで,R主任は本番データに含まれる個人情報を匿名加工情報に 加工して移行総合テストに用いる計画を作成した。0課長は,検証漏れのリスクと 情報渦えいのリスクのそれぞれを評価した上で,R主任の計画を承認した。その際, PMである0課長だけで判断せず,④ある手続を実施した上で対応方針を決定した。 (4)営業員の教育・訓練及び受人れテスト 商品販売部の部員が,S主任及び拠点の責任者と協議しながら,営業員の教育・ 訓練の内容及び実施スケジュールを計画する。これに沿って,営業日の業務後に受 入れテストを兼ねて,商品販売部の部員及び全営業員に対する教育・訓練を実施す る。 (5)移行リハバーサル 移行リハーサルでは,移行総合テストで検証された移行ツールを使った移行手順, 本番移行の当日の体制,及びタイムチャートを検証する。 (6)本番移行 移行リハーサルで検証した一連の手順に従って切替作業を実施する。本番移行は 本年12月31日一来年1月2日に実施することに決定した。 (7)移行後の初期サポート 移行後のトラブルや問合せに対応するための初期サポートを実施する。初期サポ ートの実施に当たり,0課長は,BARE,システムが安定稼働して拠点からサー ビスデスクへの問合せが収束するまでの間,⑤ある支援を継続するようS主任に指 示した。 Q課長は,これらの検討結果を踏まはえて,⑥新システムの移行可否を評価する上で 必要な文書の作成に着手した。 [リスクマネジメント〕 0課長は,R主任に。主にリスクの定性的分析で使用される| a|を活用し, 分析結果を表としてまとめるよう指示した。さらに,リスクの定量的分析として,移 行作業に対して最も影響が大きいリスクが何であるかを判断することができる |b|を実施し,リスクの重大性を評価するよう指示した。 リスクの分析結果に基づき,R主任は,各リスクに対して,対応策を検討した。0課 長は,来年3月末までに本番移行が完了しないような重大なリスクに対して,プロジ ー53一 ェクトの期間を延長することに要する費用の確保以外に,現行の販売支援システムを 稼働延長させることに要する費用面の⑦対応策を検討すべきだ,とR主任に指摘した。 R主任は,指摘について検討し,0課長に説明をして了承を得た。

共通の文章

クラウドサービスのサービス可用性管理に関する次の記述を読んで,設問に答えよ。 L社は,大手の自動車部品製造販売会社である。2023年4月現在,全国に八つの製 MAES,L社の製造部は,昼勤と夜勤の2交替制で部品を製造している。しL社 の経理部は,基本的に昼勤で経理業務を行っている。L社のシステム部では,基幹系 業務システムを,L社本社の設備を使って,オンプレミスで運用している。また,会 計系業務システムは,2023年1 All,オンプレミスでの運用からクラウド事業者M 社の提供するSaaS(以下,Sサービスという)に移行した。L社の現在の業務システ ムの概要を表1に示す。 表1 L社の現在の業務システムの概要 業務システム名称業務システムの運用形態 |1|基幹系!り|自社開発のアプリケーションソフトウェアをオンプレミスで運用 $サービスを利用 注り対象は,販売管理,購買管理,在庫管理,生産管理,原価管理などの基幹業務 S$?対象は,財務会計,SHAH,債権債務管理,手形管理,給与計算などの会計業務 [L社のITサービスの現状]〕 システム部は,L社内の利用者を対象に,業務システムをITサービスとして提供 し,サービス可用性やサービス継続性を管理している。 システム部では,ITILを参考にして,サービス可用性として異なる3種の特性及 び指標を表2のとおり定めている。 表2サービス可用性の特性及び指標 —あらかじめ合意された期間にわたって,要求された機能を実行す|サービス るITサービスの能力稼働率 ITサービスを中断なしに,合意された機能を実行できる能力 ITサービスに障害が発生した後,通常の稼働状態に戻す能力 基幹系業務のITサービスは,生産管理など事業が成功を収めるために不可欠な重 要事業機能を支援しており,高可用性の確保が必要である。基幹系業務システムでは L社本社建屋内にシステムを2系統用意してあり,本番系システムのサーバの故障や 定期保守などの場合は,予備系のサーバに切り替えてITサービスの提供を継続でき るシステム構成を採っている。また,ストレージに保存されているユーザーデータフ ァイルがマルウェアによって破壊されるリスクに備え,定期的にユーザーデータファ イルのフルバックアップを磁気テープに取得している。バックアップを取得する磁気 テープは2組で,1組は本社建屋内に保存し,もう1組は災害に対する脆弱性を考え る必要があるので,遠隔地に保管している。 [Sサービスのサービス可用性〕 システム部のX氏は,会計系業務システムにSサービスを利用する検討を行った際, M社のサービスカタログを基にサービス可用性に関する調査を行い,その後,L社と M社との間でSLAに合意し,2023年1月から$Sサービスの利用を開始した。M社が案 内しているSサービスのサービスカタログGRE)ERIK,L社とM社との間で合 意したSLAのサービスレベル目標を表4に示す。 表3 Sサービスのサービスカタログ(抜粋) サービスを提供する時間24時間365日(計画 _(サービス時間一サービス停止時間!)月間目標値99.59%以 =定期的なソフトウェアのバージョンアップや保守作|毎月1回 計画停止時間|業のために設ける時間。サービスは停止される。|午前2時一午前5時 注りインシデントの発生などによって,サービスを提供できない時間(計画停止時間を除く)。 表4 L社とM社との間で合意したSLAのサービスレベル目標 合意したSLAのサービスレベル目標 サービス時間L社の営業日の午前6時翌日午前2時(1 A 20時間) 月間目標値99.5%以上 計画停止時間 2023年1月は,Sサービスでインシデントが発生してサービス停止した日が3 BH ったが,サービス停止の時間帯は3日とも表4のサービス時間の外だった。よって, 表4のサービス稼働率は1999%である。仮に,サービス停止の時間帯が3日とも表4 のサービス時間の内の場合,サービス停止の月間合計時間が| b|分以下であ hid,表4のサービス稼働率のサービスレベル目標を達成する。ここで,1月のL社 の営業日の日数を39とする。 3月は,表4のサービス時間の内にSサービスでインシデントが発生した日が1日 あった。復旧作業に時間が掛かったので,表4のサービス時間の内で90分間サービ ス停止した。3月のL社の営業日の日数を39とすると,サービス乏働率は99.75%と なり,3月も表4のサービスレベル目標を達成した。しかし,このインシデントは月 未繁忙期の日中に発生したので,L社の取引先への支払業務に支障を来した。 X Bld,サービス停止しないことはもちろんだが,サービス停止した場合に迅速に 対応して回復させることも重要だと考えた。そこで,X氏はM社の責に帰するインシ デントが発生してサービス停止したときの①サービスレベル項目を表4に追加できな いか,M社と調整することにした。 また,Sk,経理部では,勤務時間を製造部に合わせて,交替制で夜勤を行う勤務 体制を採って経理業務を行うことで,業務のスピードアップを図ることを計画してい る。この場合,会計系業務システムのサービス時間を見直す必要がある。そこで,X 氏は,表4のサービスレベル目標の見直しが必要と考え,表3のサービスカタログを 念頭に,②経理部との調整を開始することにした。 基幹系業務システムのクラウドサービス移行 2023年1月に,L社はBCPの検討を開始し,システム部は地有苦が発生して基幹系業 務システムが被災した場合でもサービスを継続できるようにする対策が必要になった。 X氏が担当になって,クラウドサービスを利用してBCPを実現する検討を開始した。 X氏は,まずM社が提供するパブリッククラウドのTIaaS(LAF,IサービスといCs う)を調査した。Iサービスのサービスカタログでは,サービスレベル項目としてサ ービス時間及びサービス稼働率の二つが挙げられていて,サービスレベル目標は,そ neh 24時間365日及び月間目標値99.99%以上になっていた。1!Iサービスでは,物 理サーバ,ストレージシステム,ネットワーク機器などのIT基盤のコンポーネント oo BE ies (以下,物理基盤という)は,それぞれが冗長化されて可用性の対策が採られている。 また,ハイパーバイザー型の仮想化ソフト(以下,仮想化基盤という)を使って,1 台の物理サーバで複数の仮想マシン環境を実現している。 次に,X氏は,1サービスを利用した人災害対策サービスについて,M社に確認した。 災害対策サービスの概要は次のとおりである。 ・M社のデータセンター(DC)は,同時に被災しないように東日本と西日本に一つず DHS,通常時は,L社向けの1サービスは東日本のDCでサービスを運営する。 東日本が被災して東日本のDCが使用できなくなった場合は,西日本のDCで1サー ビスが継続される。 ・西日本のDCの1サービスにもユーザーデータファイルを保存し,東日本のDCの1 サービスのユーザーデータファイルと常時同期させる。東日本のDCの仮想マシン 環境のシステムイメージは,システム変更の都度,西日本のDCにバックアップを 保管しておく。 M社の説明を受け,X氏は次のように考えた。 ・地苦や台風といった広範囲に影響を及ぼす自然災害に対して有効である。 ・災害対策だけでなく,物理サーバに機器障害が発生した場合でも業務を継続できる。 ・西日本のDCの1Iサービスのユーザーデータファイルは,東日本のDCのTIサービス のユーザーデータファイルと常時同期しているので,現在行っているユーザーデー タファイルのバックアップの遠隔地保管を廃止できる。 X Kid,上司にM社の災害対策サービスを採用することで効果的にサービス可用性 を高められる旨を報告した。しかし,LADS,OX氏の考えの中には見直すべき点 があると指摘されたので,X氏は修正した。 さらに,上司はX氏に,M社に一任せずに,M社と協議して実質的な改善を継続し ていくことが重要だと話した。そこで,X氏は,サービス可用性管理として,サービ スカタログに記載されているサービスレベル項目のほかに,④可用性に関するKPIを 設定することにした。また,基幹系業務システムの災害対策を実現するに当たって, コストの予算化が必要になる。X Kid,災害時のサービス可用性確保の観点でサービ ス継続性を確保するコストは必要だが,コストの上昇を抑えるために災害時に基幹系 業務システムを一部縮退できないか検討した。そして,事業の視点から捉えた機能ご ー59一 との⑤判断基準に基づいて継続する機能を決める必要があると考えた。

共通の文章

工場在庫管理システムの監査に関する次の記述を読んで,設問に答えよ。 Y社は製造会社であり,国内に5か所の工場を有している。Y社では,コスト削減, 製造品質の改善などの生産効率向上の目標達成が求められており,あわせて不正防止 を含めた原料の入出庫及び生産実績の管理の観点から,情報の信頼性向上が重要とな っている。このような状況を踏まえ,内部監査室長は,工場在庫管理システムを対象 に工場での運用状況の有効性についてシステム監査を実施することにした。 [予備調査の概要] 監査担当者が予備調査で入手した情報は,次のとおりである。 (1)工場在庫管理システム及びその関連システムの概要を,図1に示す。 MES(製造実行システム) 購買管理システム|csy工場在庫管理レステム ファイル データ出庫データデータデータマスタ 図1工場在庫管理システム及びその関連システムの概要 ①工場在庫管理システムは,原料の入庫データ・出庫データ,原料・仕掛品の 在庫データ,仕掛品の工程別の製造実績データ及び工程マスタを有している。 また,工程マスタには,仕掛品の各製造工程で消費する原料標準使用量などが 登録されている。 ②原料の入庫データは,購買管理システムの入荷データから人入手する。また, 製造実績データは,製造工程を制御・管理しているMESの工程実績データから 入手する。 ③工程マスタ,入庫データ・出庫データなどの入力権限は,工場在庫管理シス テムの個人別の利用者IDとパスワードで制御している。過去の内部監査におい て,工場の作業現場のPCが利用後もログインされたまま,複数の工場担当者が ーー62ーー 利用していたことが指摘されていた。 ④工場在庫管理システムの開発・運用業務は,本社のシステム部が行っている。 (2)工場在庫管理システムに関するプロセスの概要は,次のとおりである。 ①工場担当者が購買管理システムの当日の入荷データをCNファイルにダウン ロードし,件数と内容を確認後に工場在庫管理システムにアップロードすると, 入庫データの生成及び在庫データの更新が行われる。工場担当者は,作業実施 結果として,作業実施日及びエラーの有無を入庫作業台帳に記録している。 ②製造で消費された原料の出庫データは,製造実績データ及び工程マスタの原 料標準使用量に基づいて自動生成(以下,出庫データ自動生成という)される。 このため,実際の出庫実績を工場在庫管理システムに入力する必要はない。ま た,工程マスタは,目標生産効率を考慮して,適宜,見直しされる。 ③仕掛品については,MESから日次で受信した工程実績データに基づいて,日 次の夜間バッチ処理で,製造実績データ及び在庫データが更新される。 ④工場では,本社管理部の立会いの下で,原料・仕掛品の実地棚卸が月次で行 われている。工場担当者は,保管場所・在庫種別ごとに在庫データを抽出し, 実地棚卸リストを出力する。工場担当者は,実地棚卸リストに基づいて実地棚 卸を実施し,在庫の差異があった場合には実地棚卸リストに記入し,在庫調整 入力を行う。この入力に基づいて,原料の出庫データ及び原料・仕掛品の在庫 データの更新が行われる。 ©工場では,工場在庫管理システムから利用者ID,利用者名,権限,ID登録日, 最新利用日などの情報を年次で利用者リストに出力し,不要な利用者IDがない か確認している。この確認結果として,不要な利用者IDが発見された場合は, 利用者IDが削除されるように利用者リストに追記する。 〔監査手続の作成 監査担当者が作成した監査手続案を表1に示す。 =6= 表1監査手続案 [|[a[Peteacitiannaeeenses.noe 庫記載されているか入庫作業台帳を確かめる。 i設定されているか確かめる。 在庫@当日にMESから受信した工程実績データに基づいて,仕掛品の在庫が敵 切に更新されているか確かめる。 ②実地棚卸で判明した差異が正確に在庫調整入力されているか確かめる。 (アクセないか確かめる。 ABE)|@利用者リストを閲覧し,長期間アクセスのない工場担当者を把握し,利 用者Dが適切に削除されるように記載されているか確かめる。上 内部監査室長は。表1をレビューし,次のとおり監査担当者に指示した。 (1)表1項番1の①は,|b|を確かめる監査手続でもある。これとは別に不正 リスクを鑑み,アップロードしたCVファイルととの整合性を確保す るためのコントロールに関する追加的な監査手続を作成すること。 (2)表1項番2の①は,出庫データ自動生成では| d|が発生する可能性が 高いので,設定される工程マスタの妥当性についても確かめること。 (3)表1項番3の②は,| e|を確かめる監査手続なので,今回の監査目的を 踏まえて実施の要否を検討すること。 (4)表1項番4の①の前提として,に記載された| g|の網羅性 が確保されているかについても確かめること。 (5)表1項番4の②は,在庫の改ざんのリスクを踏まえ,差異のなかった |9|にっいて在庫調整入力が行われていないか追加的な監査手続を作成す ること。 (6)表1項番5の②は,不要な利用者IDだけでなく,を利用してアク セスしている利用者も検出するための追加的な監査手続を作成すること。 ー64—