応用情報技術者 2020年 10月 午後 問題

共通の文章

内部不正による情報漏えいの対策に関する次の記述を読んで,RE 1~3に答えよ。 A社は,小,中,高校生及び大学受験生向けに通信教育を行っている。A社では, 受講生の個人情報や受講履歴などを管理する受講生管理システムと複数の業務システ ム(UE,A社の各種システムという)&E祉のデータセンタで運用している。A 社の各種システムの運用管理は,社内のシステム運用管理室で,F社から派遣された 技術者(以下,F社技術者という)が行っている。A社のネットワーク構成を図1に 示す。 E社のデータセンタ CインターネットA社の各種システム A社ーーてーーーーーーーーーーーーーー |3%|本 |サーバ|サーデバ専用線 にーー DMZi FW:ファイアウォール L2SW:レイヤ2スイッチ ーーシステム|135W:レイヤ3スイッチ !Z Fae ee en iT pc][pc]オフィス!Fn…||!|メール管理システムが稼働 PC}[PC]xy yt IPにIO]しているを。 図1 A社のネットワーク構成(抜粋) メール管理システムは,電子メール(以下,メールという)の誤送信を防止する目 的で導入されている。PCから送信されたメールは,メール管理サーバで一旦保留さ れ,送信者によって,宛先,メール本文及び添付ファイルに間違いがないことの確認 操作が行われた後に,メールサーバに転送される。インターネットアクセスは,プロ キシサーバ経由で行うも。プロキシサーバでは,利用者認証は行っていない。PCには, DHCPサーバからIPアドレスなどの情報が付与されている。 A社では,情報セキュリティ担当役員を委員長とする情報セキュリティ委員会によ って,情報セキュリティ管理規程(以下,管理規程という)が整備されている。管理 規程の内容を基に,次のように運用されている。 ーーー4 comet 保有する情報には,管理規程に基づいて| 。|区分を設定し,電子文書や書 類に,区分に沿ったマークを表示又は押印して,誰でも判別できるようにし,区分に 応じた取扱方法を定めている。社技術者を含む社員による,A社の各種システムの 操作に関しては,そのシステムの利用者だけに,業務上必要となる最低限の機能を利 用できる| b ]を付与している。利用者は,システムが保有する情報を,PC や許可された可搬型記憶媒体にダウンロードできる。資産価値又は重要度の高い情報 の社外への持出しは原則として禁止されているが,持ち出すことが必要になった場合 は,管理者である上司の承認を得た後に持ち出すことができる。社員は,社外の関係 者との間で,添付ファイル付きメールの送受信を行っている。業務上不要なWebサ イトへのアクセスやメールの私的利用は禁止されているが,徹底できていない。 昨今,正社員や派遣社員など,内部者の不正行為による個人情報や営業情報の漏え い事件の報道が後を絶たない。そこで,情報セキュリティ委員会では,内部不正によ る情報漏えいの追加の対策を実施することを決め,A社の情報セキュリティリーダの B主任に,情報システム部の支援を受けて対策案をまとめるように指示した。 〔現状の調査 B主任は,まず,内部不正が発生する要因について調査した。内部不正は,不正の トライアングルと呼ばれる三つの要因(HH,機会,正当化)が揃ったときに,発生 するおそれが増すと言われている。B主任は,IPAの“組織における内部不正防止ガ イドライン"に含まれる,“内部不正チェックシート”"を利用して問題点の把握を行 った。その結果,次の三つの問題があることが判明した。 (1)USBメモリなどの可搬型記憶媒体の運用が,管理規程どおりに行われていない。 (2)メールや社外のWebサイトの利用が,管理規程どおりに行われていない。 3)重要情報へのアクセス履歴及び利用者の操作履歴などのログの取得と管理が適 切に行われていない、。 これらの問題への対策を実施することによって,不正のトライアングルの要因の一 つである機会が低減されることから,不正の抑止につながると考えられるので,これ らの問題への対策について検討することにした。 an= [内部不正に対する技術面での対策] 問題のQ)については,可搬型記憶媒体の運用を管理規程どおりに行うことが必要 CHS,LPL,許可されていない可搬型記憶媒体に情報をダウンロードするなどの 悪意をもった行動に対しては,管理規程だけでは対処できない。そこで,PCの操作 ログの取得機能ややデバイス制御機能をもつPC管理システムを導入することにした。 問題の②については,メール管理システムとプロキシサーバの設定の見直しで対 処することにした。導入済みのメール管理システムの未使用の機能を図2に示す。 ・②添付ファイル付きメールに対して,指定された処理を行う。 2.メールアーカイプ機能 図2メール管理システムの未使用の機能(抜粋) メール管理システムでは,新たに,図2中の情報漏えい対策機能を有効にする。 プロキシサーバでは,URLフィルタリングを稼働させ,業務上必要なWebサイトを ホワイトリストに登録してアクセスを許可し,その他のWebサイトへのアクセスは 遮断する。ホワイトリストへの登録は,情報セキュリティ委員会による認定後に情報. システム部が行う。ホワイトリストに含まれないWebサイトの中にも,業務上必要 となるサイトが存在する可能性があるので,③当該サイトの利用を希望する者がとる べき手段を用意する。 [ログの取得とメールのアーカイブ]〕 問題の(3③の対策として,④プロキシサーバとPC管理システムで全てのログを取得 するとともに,MEK,図2中の,メールアーカイブプ機能を有効にすることにした。 プロキシサーバのログでは,通信が行われた日時,⑧作業者のID,アクセス先IP アドレス,操作内容などが確認できるようになる。PFC管理システムのログでは,PC での全ての操作内容が把握できるようになる。メールアーカイブでは,送信されたメ ール本文及び添付ファイルの内容,送信者及び宛先が特定できるようになる。 B主任は,これらの検討を基に,@PC管理システムの導入,)A-VEBYAT ムの未使用機能の有効化,(cC)プロキシサーバでのURLフィルタリングの稼働と設定 ー6一 の見直し,(①ログの取得と監視,の四つの対策案をまとめた。また,⑥これらの対 策を社内に告知することによって,内部不正を抑止することが期待できるので,四つ の対策の実施と対策内容を社内に告知することを情報セキュリティ委員会に提案し, 承認された。

共通の文章

新事業の創出を目的とする事業戦略の策定に関する次の記述を読んで,設問1~3 に答えよ。 W社は,SMB HS IT企業である。5年前に設立され,現在の従業員数は約80 名である。顧客からは企画提案力と技術力の高さを評価され,業績は好調である。現 在はWeb系システムの受託開発が主体であるが,先端ITを活用した付加価値の高い ソフトウェアパッケージの販売事業やASP(Application Service Provider)事業を,W 社内の先端IT人材の割合を増やすことで新事業として創出するという新たな事業方 針を決定している。 この事業方針の実現を図る事業戦略を策定することになり,経営企画部のX課長 をリーダに任命して,2019年12月に事業戦略策定チームを立ち上げた。先端IT人 材の確保・育成・定着のためには,多様なワークスタイルの整備が必要である。ワー クスタイルとは,業務内容,就業場所,雇用形態,勤務時間など,従業員が働く上で の様々な要素を指す。 〔W社の事業の概要,就業環境及び課題] W社の事業の概要,就業環境及び課題は,次のとおりである。 (1)事業の概要 ・顧客は法人企業であり,顧客の主な業種は,小売業,不動産業,飲食サービス業 CHS,顧客の業種ごとに組織された三つの事業部がある。 ・事業部の主な業務内容は,企画,営業,システムの開発及びシステムの保守であ る。 ・WebポータルやECサイトのシステムの受託開発が中心だが,AIやビッグデー タなどを活用したカスタマサポートシステムの受託開発の割合が増えている。 ・開発案件の事例として,“AIが,蓄積された膨大なカスタマコンタクト履歴情報 からカスタマの行動パターンを分析・学習し,当該カスタマに適したサポートを 助言する。",“AIが,カスタマサポートチームのメンバ間の交流状況を分析・学 BL,高パフォーマンスを引き出すようにチームに助言する。"がある。 (2)就業環境 ーョ一 ・各事業部は,顧客のオフィスの所在地などを勘案して,それぞれ別の賃貸ビルを 拠点にしている。 ・小売業の顧客を担当している事業部は,独自の通販サイトを用いて急成長してい る顧客からECサイトのシステム開発・保守を受託して,顧客かオフィスがある Z駅周辺のビルを賃借している。Z駅には,様々な業種のベンチャ企業が集まり, それらの企業が協業して新しいビジネスモデルを立ち上げる事例がマスコミに開 度も採り上げられ,ベンチャ企業のブランド価値の向上につながっている。 (3)課題 (i)人材の確保 ・過去3年間の従業員の平均採用数は,年間20名程度である。半面,ワーク スタイルへの不満を理由に毎年5名程度退職している。 ・3年後には従業員数を150名に増やす事業方針があるが,W社の知名度が 低く,現在の売り手市場の状態も加わって,採用者の確保に苦労している。 (ii)就業環境の改善 ・各拠点とも手狭で,会議室数が不足している。さらに,3年後を見据えた 十分な規模の就業スペースの確保が必要である。 ・先端IT人材は,拠点内に自席を固定して活動するのではなく,オープンな 環境での活動を好む傾向にあるので,対応が必要である。 ・①現状の就業環境下では,拠点間の交流機会が少なく,事業部横断的な活 動や発想による斬新なアイディアが生み出しづらくなっている。 (PEST分析とW社への影響の検討] X課長は,W社の事業戦略を策定するための準備作業として,IT業界を取り巻く 外部環境が,中長期的にW社にどのような影響を与えるかを把握するために,部下 |のY主任にPEST分析を行うように指示した。PEST分析は,外部環境分析のうち | 。|環境分析に用いるフレームワークである。Y主任は,新聞,専門書籍 インターネットなどから各領域に関する情報を入手して,表1を作成した。 ー9一 表1 PEST分析 P:Politics(政治)+働き方改革関連法・国のIT政策 E:Economy(経済)・第32回オリンピック競技大会,東京2020パラリンピック 競技大会(以下,合わせて東京2020という)後の都市再開 発や労働力需要の動向 ・物価,消費動向・為替相場の動向 S:Society(社会)・少子高齢化に伴う生産年齢人口の推移 ・Society 5.0の提唱・ワークスタイルの多様化 T:Technology(技術)・コミュニケーションツールの劇的な進歩 ・Al,IoT,ビッグデータなどの先端IT動向 表1を見たX課長は,Y主任に次の指示をした。 ・PEST分析の特性として,分析する環境項目を絞らないと作業量が膨大になってし まうので,W社の事業と関わる労働力と就業環境に関するものに絞ること。 ・PEST分析による外部環境分析を終了したら,次に内部環境分析を行うこと。その 際に用いるフレームワークは,W社内の業務プロセスのつながりなどに基づいて 分析する[>|っ ・内部環境分析にスムーズに着手できるように,あらかじめ絞り込んだ環境項目の内 容をブレークダウンした上で,W社への影響を整理しておくこと。 Y主任は,X課長の指示を受けて,表2のとおりに整理した。 表2 PEST分析の環境項目の絞込みとW社への影響 ・働き方改革関連法の制定・従業員の労働条件の改善|・労務管理業務の負荷増 ・世界最先端デジタル国家創造宜|・デジタル化対応によるIT 言・官民データ活用推進基本計|電要の増加 画 E|・大手不動産会社主導の都市再開|・新しい賃貸物件の増加・都市部ビルの賃借料の値上 発促進がり S|・TT業界が必要とする人材のスキ|・先端TT人材の増加・先端TT人材の確保難 ルの変化 ・ワークスタイルの多様化・|。]]の導入促進|・従業員間の対面のコミュニ ケーション機会の減少 ・労務管理業務の負荷増 T|・ビデオ通話Webツールの拡大|・オンライン会議の促進・従業員間の対面のコミュニ ・クライアント仮想化技術の進歩|・[<|の導入促進ケーション機会の減少 [事業戦略の策定と施策への展開] まず,X課長とY主任は,課題への対応に関して,次の方針を立てた。 ・ワークスタイルの多様化に対応すること,及び先端IT企業というブランド価値を 向上させることによって,優秀な先端IT人材の確保・定着を促進する。 ・多様なワークスタイルを整備することによって,従業員個人のモチベーションを向 上させ,業務のパフォーマンスを改善する。さらに,就業スペースの拡大とともに 事業部を越えた従業員間のインフォーマルなコミュニケーションを活性化して,斬 新なアイディアを生み出す就業環境を作り,新事業の創出につなげる。 次に,環境分析の結果と課題への対応方針に基づき,先端IT人材を増やして付加 価値の高い製品を開発することで事業拡大を図るという事業戦略を策定した。先端 IT人材を増やすためには,従業員同士が対面のコミュニケーションを図れる就業環 境とITを活用したコミュニケーション環境を両立させることが有効であると考えた。 また,多様なワークスタイルを整備することも重要だと考えて,次の施策をまとめた。 (1)新しい拠点への集結 Z駅から徒歩圏内の賃貸ビルに入居し,全従業員を集結する。これによって,Z 駅周辺を拠点とする異業種のベンチャ企業と交流を深め,それらの企業と協業し て新事業の創出を目指す。この施策には,②新事業の創出以外の狙いもある。 (2②)新しい就業環境の整備 ・従業員が自席を固定しないフリーアドレス制を採用する。 ・様々な形のテーブルや椅子,PC,.コーヒーサーバなどを設置し,社内の打合せ に自由に利用できるコミュニケーションスペースを設ける。 ・メール機能,スケジュール機能,オンライン会議機能を統合した企業内コミュニ ケーションツールを導入し,社外でも社内と同じように働ける就業環境を作る。 ・インフォーマルなコミュニケーションツールとして,社内SNSを導入する。 ・これらによって,多様なワークスタイルを支援する就業環境が整備された後,従 業員個人の業務への取組み状況及び⑨⑧従業員間の交流状況などの情報を,企業内 コミュニケーションツールや社内SNSの利用履歴からモニタリングする。 (3)多様なワークスタイルの整備に対応した社内制度の見直し ・将来的に,テレワークの勤務制度の導入を検討する。本社業務部門は,関連する 社内規程の改定や人事評価方法の見直しを行う。 ー]1一 ・④テレワークの勤務制度の導入によって,本社業務部門の担当である一部の業務 の負荷が増える懸念があるので,対策を検討する。

共通の文章

誤差拡散法による減色処理に関する次の記述を読んで,設問1ユー4に答えよ。 画像の情報量を落として画像ファイルのサイズを小さくしたり,モノクロの液晶 画面に画像を表示させたりする際に,減色アルゴリズムを用いた画像変換を行うこ LMHS,誤差拡散法は減色アルゴリズムの一つである。誤差拡散法を用いて,階 調ありのモノクロ画像を,黒と白だけを使ったモノクロ2値の画像に画像変換した 例を図1に示す。 階調ありのモノクロ画像の場合は,各ピクセルが色の濃淡をもつことができる。 濃淡は輝度で表す。輝度0のとき色は黒に,輝度が最大になると色は白になる。モ ノクロ2値の画像は,輝度が0か最大かの2値だけを使った画像である。 変換前変換後 図1画像変換の例 [誤差拡散法のアルゴリズム]〕 画像を構成するピクセルの輝度は,1ピクセルの輝度を8ビットで表す場合,0て 255の値を取ることができる。0が黒で,255が白を表す。誤差拡散法では,ROR つの処理をピクセルごとに行うことで減色を行う。 ①変換前のピクセルについて,白に近い場合は輝度を255,黒に近い場合は輝度を 0としてモノクロ2値化し,その際の輝度の差分を評価し,輝度の誤差Dとする。 例えば,変換前のピクセルの輝度が223の場合,変換後の輝度を255とし,輝 度の誤差Dは,223一255から,一32 CHS, ②事前に定義した誤差拡散のパターンに従って,評価した誤差Dを周囲のビクセ ル(以下,拡散先という)に拡散させる。 拡散先の数が4の場合の,誤差拡散のパターンの例を図2に,減色処理の手順を 図3に示す。なお,拡散する誤差の値は整数とし,小数点以下は切り捨てる。 ー]4一 ||ae の前還還 図2拡散先の数が4の場合の,誤差拡散のパターンの例 1.変換前画像のピクセルの数と同じ要素数の整数の2次元配列を,変換処理後の輝度を格納 するための配列(以下,変換後輝度配列という)として用意し,全ての要素を0で初期化す る。 2.変換前画像の一番上の行から,各行について左から順に1ピクセル選び,輝度を得る。 3,変換前画像の輝度と,変換後輝度配列の同じ要素の値を加算し,これをFとする。 4.Fの値が128以上なら変換後輝度配列の輝度を255とし,誤差の値DをFー255とする。 Fの値が128未満なら変換後輝度配列の輝度を0とし,誤差の値DをFとする。 5.Dの値について,誤差拡散のパターンに定義された割合に従って配分し,拡散先の要素に 加算する。ただし,画像の範囲を外れる場合は,その値を無視する。 6.処理していないピクセルが残っている場合は2.に戻って繰り返す。 7.変換後輝度配列で輝度が0を黒,輝度が255を白として,画像を出力する。 図3減色処理の手順 図2のパターンを使い,図3の手順に従って,1行目の左上から2ピクセル分の処 理をした後,その右隣のピクセル(左上から3ピクセル目)について処理した例を 図4に示す。変換前画像の郊度の値が128で,変換後輝度配列の同じ要素の値がー14 なので,Fは128+(一14)三114となる。Fが128未満なので,輝度は0,誤差Dは 114となる。誤差114に716を乗じて,小数点以下を切り捨てた値は49 BOT,変 換後交度配列の一つ右の要素に49を加算する。同様に,左下には21,下には35, 右下には7を加算する。 Co[as[es][|[0 fesuyo fo][ofasToT#10| slel elel[ef n[os[7|| ololololo||eololeloleol olololole|[evloleolelol 左上から2ピクセル分の処理後左上から3ピクセル目の処理後 変換前画像変換後輝度配列 図4左上から3ピクセル目について処理した例 [誤巻拡散法を用いて減色するプログラム] 誤差拡散法を用いて減色するプログラムを作成した。プログラム中で使用する主 な変数,定数及び配列を表1に,作成したプログラムを図5に示す。 表1プログラム中で使用する主な変数,定数及び配列 bmpFrom[x,y]|配列|変換前画像の輝度の配列。輝度が0て255の値で格納される。 x,yはそれぞれX座標とY座標で,画像の左上が[1,1],AFA [width,height]lである。 |beer bmpTolx,y]配列|変換後輝度配列。x,yはbmpFromlx,y]と同様である。全ての要素は0 tdx[]配列|拡散先の,ピクセル単位のX方向の相対位置。2の場合は[1一1, 0,1]が入る。 tdy[]配列|拡散先の,ピクセル単位のY方向の相対位置。図2の場合は[0,1,1, 1]]が入る。 る。 for(yを1からheightまで繰り返す) for(xを1からwidthまで繰り返す)キーーーーーーーーーーーーーーーーーー① 『 +) df-255 bmpTo[x,y]<255 else df bmpTo[x,y]<—@ endif for(cを1からratioCountまで繰り返す) px-x+tdx[c]<—_—_—________————_& pyでy+tdy[c] if((pxが1以上)かつ(pxがwidth以下)}③ かつ(pyが1以上)かつ(pyがheight以下)) hmpfofpx,py]こ endif endfor endfor endfor 図5作成したプログラム [画質向上のための改修 ピクセルを処理する順番を,Y座標ごとに逆向きにすることで,誤差拡散の方向の 偏りを減らし,画質を改善することができる。 Y座標が奇数の場合:ピクセルを左から順に処理する。 Y座標が偶数の場合:ピクセルを右から順に処理する。 なお,Y座標が偶数の場合は,誤差拡散のパターンを左右逆にして評価する。 画質を向上させるために,図5ののと②の行の処理を書き換えた。書き換えた後 の①の行の処理を図6に,書き換えた後の②の行の処理を図7に示す。なお,A mod Blt,AをBで割った余りである。 ce xをtx endif if(([=|mod[ォ|)が6に等しい) = 図6書き換えた後の①の行の処理 図7書き換えた後の②の行の処理 [処理の高速化に関する検討] 図5中の③の箇所では,誤差を拡散させる先のピクセルが画像の範囲の外側にな らないように制御している。このような処理をクリッピングという。 ③のitxlt,プログラムの終了までに|+|回呼び出され,その度に,条件 判定における比較演算と論理演算の評価が,あわせて最大で回行われる。 ここでの計算量が少なくなるようにプログラムを改修することで,処理速度を向上 させることができる可能性がある。 |

共通の文章

ヘルスケア機器とクラウドとの連携のためのシステム方式設計に関する次の記述を 読んで,設問1て3に答えよ。 C社は,ヘルスケア機器の製造販売を手掛ける中堅企業である。このたび,従来の 製品である,歩数や心拍数などを測定する活動量計を改良して,クラウドを利用した 新しいサービス(以下,新サービスという)を開発することになった。 従来の活動量計の概要] 従来の活動量計の概要を次に示す。 ・リストバンド型で生活防水に対応する。 ・24時間装着して,歩数や心拍数,睡眠時間を記録する。 ・横10文字,縦2文字のモノクロ液晶画面に,現在時刻や測定中のデータ,記録さ れたデータを表示できる。 ・四つのボタンを備えており,表示切替えや数値入力など簡単な操作ができる。 ・測定データ記録用のメモリ容量は64Mバイトあり,使用中のメモリが一杯になっ たときには,データの古いものから順に新しいデータに上書きされる。 〔[新サービスの概要] 従来の活動量計を基に,通信機能などを追加した新しい活動量計を開発する。測定 データや手元で入力したデータをクラウド上に保存し,分析するWebサービスを開 発する。そして,Webサービスの分析結果を手元の活動量計で確認できるようにす ることで,次の機能を提供する。 ・1日24時間の総消費カロリーを推測する機能 歩数や心拍数などの測定データを長期間保存して,消費カロリーと基礎代謝を推 HL,利用者の日々の総消費カロリーをグラフで示す。 ・歩行やジョギングなど運動についてアドバイスする機能 事前登録した身長や体重,目標体重などの情報から,利用者に適切な運動種目と 時間を提案する。 ・責立など食生活についてアドバイスする機能 飲食した内容を文字や写真で記録することで,利用者に栄養バランスの良い責立 =ip を提案する。 [非機能要件の整理] 新サービスでは,利用者の日常生活に密着してデータを24時間収集し続ける必要 がある。個人のヘルスケアデータという機微な情報を取り扱うので,情報の漏えいや 盗聴を防ぐ対策も重要である。新サービスの非機能要件を表1に整理した。 表1新サービスの非機能要件 メトリクス(指標) 可用性継続性1日24時間の総消費カロリーを推測するために,1日23時間 30分以上の活動量計の測定データが必要である。 クラウドは十分な稼働率が保証されたサービスを選択する。 耐障害性活動量計本体が故障した場合は交換対応を行う。 活動量計からクラウドまでのネットワークが切断されている間 も測定データは消失しない。 性能業務処理量活動量計から1回の測定で100バイト,毎分100回の測定デ ータが生成される。 クラウド上の保存期間は3年間,利用者数は最大10万人を見 込む。 性能目標値クラウド上のWebサービスの応答時間は5秒以内,順守率 95%とする。 測定データをクラウドへ保存する処理は,業務処理量と [a|の品質を考慮して,再実行を2回行う余裕をもた せる。 セキュリ|アクセス制限活動量計での利用者の認証には,暗証番号を用いる。 ティクラウド上のWebサービスでの利用者の認証には,IDとパス ワードによるログインに加えて,①ショートメッセージサービ スや電子メールからの確認コードによる認証も用いる。 データの秘匿伝送データ及び保存データは全て暗号化する。 なお,暗号化されたデータのサイズは元のデータと同じとす る。 Web対策Webサービスをリリースする前にソースコード診断を実施す る。さらに,定期的な脆弱性検査を実施する。 [システムアーキテクチャの検討] まず,クラウド上のシステム構成について考える。Webサーバとアプリケーショ ンサーバは,新サービスの利用者数に応じてスケールアウトできる構成にする。デー タベースは,②新サービスのデータ特性からKVS(Key Value Store)を採用する。 Mil,新サービスを実現するためのシステム方式について考える。三つの検討案を 表2に示す。 表2三つの検討案 TE: 中クラウド直接活動量計にモバイル通信サービスを利用するためのモジュールや カメラなどを組み込み,。インターネットに直接接続してデータ連 携を行う。リストバンド型の形状やサイズを維持するために,デ ータ入力や画面表示方法を工夫する必要がある。 2モバイル端末|活動量計に近距離無線通信モジュールを組み込んで,スマートフ 経由ォンやタブレットなどのモバイル端末を経由してクラウドとのデ ータ連携を行う。カメラはモバイル端末に内蔵されているものを 利用する。伝送データ及び保存データの暗号化や画面描画など, ほとんどの処理をモバイル端末上のアプリケーションソフトウェ ア(WE,アプリという)が担う。 3専用端末経由|検討案2で用いられるモバイル端末の代わりに,モバイル通信サ ービスを利用するためのモジュールや近距離無線通信モジュー ル,HAD,タッチスクリーンなどを組み込んだ,手のひら大の 専用端末を開発して,それを利用する。伝送データ及び保存デー タの暗号化や画面描画などの処理の一部は,専用端末内のハード ウェアが処理する。 表2の各システム方式について,その実現可能性と新サービスの利便性を評価す るために,五つの評価軸を設けて整理した結果を表3に示す。 表3五つの評価軸を設けて整理した結果 本FE ARE|GRE Pa josorme[Oo 14|x|x[a[am| axe|A|O|o|0|x|7a| omean|A|x|A|^|GO|sw| 凡例〇:優れている,2点A:軽微な課題がある,1点※:重大な課題がある,OR クラウド直接方式の場合,③活動量計の柔軟性と拡張性に課題がある。 モバイル端末経由方式は最も評価点が高いが,他のアプリの影響による通信のタイ ムアウトやバッテリー切れが原因でアプリの処理が中断されてしまうことがあるので, 安定性に課題がある。この課題が解決できれば,本方式を採用できる。 専用端末経由方式の場合,安定性は優れているが,モバイル端末に匹英する柔軟性 や拡張性を備えた端末を独自に開発することは難しく,コストが高くなってしまう課 題がある。 [モバイル端末経由のシステム方式設計] 三つのシステム方式の中で,評価点の高いモバイル端末経由方式を採用するために, 安定性に関する対策を検討する。 モバイル端末において,通信のタイムアウトやバッテリー切れによってアプリの処 理が中断されてしまった場合でも,測定データが消失せずに保存できるように,次の 機能をアプリとして実装する。 ・活動量計内に保存されている測定データを,モバイル端末内のストレージに保存す る機能 ・モバイル端末内に保存されている測定データを,インターネット接続時にクラウド 上のストレージに保存する機能 活動量計とモバイル端末が通信できない最大許容日数を7日間としてシミュレー ションしたところ,④ある間題が判明した。そのため,⑤活動量計に一部変更を加え ることで,その問題を回避した。

共通の文章

仮想デスクトップ基盤の導入に関する次の記述を読んで,設問1~3に答えよ。 L社は,本社のほか,全国に5か所の営業所をもつ中堅の医療機器販売会社である。 L社では,本社と営業所の間を広域イーサネットサービス網(以下,広域イーサ綱と いう)で接続し,業務サーバやファイルサーバ(以下,FSという)などを運用して WS,現在のL社のネットワーク構成を図1に示す。 iTWebllDNS| ! fest LSWI pi oe tee] ed…[NPC]!回9c +営業所5_|! 16 S87|| L2SW:レイヤ2スイッチPR:ブリンタ—|![nec][npc]ml L3SW:レイヤ3スイッチNPC:ノートPC 1 FW:ファイアウォールwee 注記1 a,by cはプロバイダとの契約帯域を示し,a bは100Mビットノ秒,cは10Mビットノ秒である。 注記2本社のルータ1,DMZ,サーバ室,オフィスエリア,営業所のルータ及び事務室は,異なるセグメント である。 注記3五つの営業所のネットワークは,全て同一構成である。 図1現在のL社のネットワーク構成(抜粋) L社の本社と営業所の社員による,現状のNPCの利用形態を次に示す。 ・本社の社員は,サーバ室の業務サーバを利用するとともに,ルータ1経由でイン ターネットにアクセスする。資料の印刷はオフィスエリアのPRで行い,ファイル 共有はサーバ室のFS1で行う。 ・営業所の社員は,広域イーサ網経由で本社の業務サーバを利用するとともに,AS 業所のルータ経由でインターネットにアクセスする。資料の印刷は自営業所のPR で行い。ファイル共有は自営業所のFS(FS2~6)と本社のFS1の両方で行う。 ・本社と営業所の営業員は,外出時に各自のNPCを携帯し,NPCに保存したファイ ルを使って,顧客先でプレゼンテーションや製品の説明などを行う。 [現状の問題点と改善策の実施] L社では,営業員が外出時にNPCを持ち出すので,NPCの紛失などによる秘密情 報の漏えいリスクがあり,改善策が求められていた。一方,営業員からは,外出先で もNPCを利用して社内と同じ作業を行いたいという要望が挙がっていた。また,情 報システム部では,営業所のシステム運用負荷を軽減したいという課題をもっていた。 そこで,L社では,仮想デスクトップ基盤(以下,VDIという)の導入を決め,VDI 導入プロジェクトを立ち上げた。このプロジェクトの責任者となった情報システム部 のM課長は,部下のN主任に,導入するネットワーク構成の設計を指示した。 (VDIの導入後のネットワーク構成の検討] N主任は,VDIの方式を調査してネットワーク構成を検討した。N主任が設計した VDI導入後のネットワーク構成を図2に示す。 イジターつの eS)Sa| Ah{sw ow| |om aS bel bel mec| 1...事務和室1=i 人|[re]~-[re]—3 ermal 9 PPなの4し、オフィスエリア|サーバ室ceccececeadl 注記1網掛けは,新規に導入する機器を示す。 注記2 VDIサーバに接続するディスクシステムの記述は,省略されている。 図2 N主任が設計したVDI導入後のネットワーク構成(抜粋) N主任が,VDI導入後のネットワーク構成と併せて検討した運用方法を次に示す。 ・本社のサーバ室に,仮想PCを稼働させるVDIサーバと関連機器を導入する。 ・5か所の営業所のFS2~6を,本社のサーバ室に移設するとともに,サーバ室に DHCPサーバを導入して,全社のTC及び仮想PCにIPアドレスなどのネットワ ーク情報を付与する。そのほかに,営業所からのインターネットアクセスを本社経 ー27一 由に変更することで,営業所のシステム運用負荷を軽減する。 ・VDIの導入時に,NPCの内蔵ディスクに保存されているファイルを,VDIサーバ に接続するディスクシステムに移した後,NPCから消去してNPCをTC化する。 ・社内からは,TCでセッション管理サーバに接続して認証を受けた後に,当該利用 者向けの仮想PCが使用できる。仮想PCからTCに,画面の情報が転送される。 ・外出先からは,DMZに導入するSSL-VPN装置経由で仮想PCを使用する。TCで SSL-VPN装置に接続すると,TCに保存されたクライアント証明書と,利用者ID, パスワードという異なった利用者認証方式を組み合わせた| 』|認証を受け る。SSL-VPN装置は,|b|と認証連携して,SSL-VPN装置での認証だけで 仮想PCを使用できるようにする。 ・TCで仮想PCに接続すると,社内と同じ作業が外出先でも行える。 [通信トラフィックの変化内容の検討] 次に,N主任は,VDI導入による通信トラフィックの変化について検討した。最初 に,現在,全社で発生している主要な通信の種類と内容を表1にまとめた。 表1全社で発生している主要な通信の種類と内容 次に,表1に示す通信に対する通信帯域の実績値などを基に,VDI導入後に,本社 の社員向けの全仮想PC(以下,本社仮想PCという)及び五つの営業所の社員向け の全仮想PC(以下,全営業所仮想PCという)で発生する通信について検討した。 N主任がまとめた,VDI導入後の最も混雑した時間帯に必要な平均通信帯域の予測値 を表2に示す。表2中の項番6,7は,VDI導入後に新たに発生する通信であり,項 番7は,外出先のTCがSSL-VPN装置経由で仮想PCを使用したときに発生する通 信である。 ー93— 表2 VDI導入後の最も混雑した時間帯に必要な平均通信帯域の予測値 単位ビットノ秒 Paonia 項本社|SERA &we Be仮想|仮想PC PC |5[siamese|人PCとFS1の間の通信Sisco|7sw| 営業所FS利用通信営業所の社員向けの仮想PCと営業所用のFSの間の通信|一|75M| |6|画面転送通信(社内)|仮想PCから本社内及び営業所内のTCへの通信 画面送信RAE) 注記1各通信の最も混雑した時間帯は同一の時刻とする。 注記2各通信とも双方向で行われるが,平均通信帯域の杉は,通信帯域が大きい通信方向の値示している。 表2の結果から,プロバイダと契約している広域イーサ網への接続回線の帯域, 及び本社のインターネットへの接続回線の帯域の見直しは,不要であると判断できた。 N主任は,検討結果をM課長に報告し,VDIの導入構成案が承認された。

共通の文章

宿泊施設の予約を行うシステムに関する次の記述を読んで,設問1ご3に答えよ。 U社は,旅館や民宿などの宿泊施設の宿泊予約を行うWebシステム(以下,予約 システムという)を開発している。予約システムの主な要件を図1に示す。 ・利用者が予約システムを最初に利用する際には,氏名,住所,電話番号を入力し,利用者登 録を行う。 ・利用者は空き部屋照会のための条件入力の画面上で,希望する施設に対し,チェックインと チェックアウトの日付,予約したい部屋の種別及び部屋数を指定して空き状況を照会する。 ・予約は部屋の種別ごとに行う。種別の違う部屋を予約したい場合は,部屋の種別ごとに分け て予約を行う。 ・空き状況の照会を行った時点で,希望した種別の部屋に,希望した部屋数の空きがなかった 場合は,部屋が空いていない旨を画面に表示する。 ・空き状況の照会を行った時点で希望した部屋数の空きがあった場合は,予約手続の画面に遷 移する。利用者は,宿泊人数を入力し,部屋の予約を確定する。 ・部屋の予約を確定するまでの間に他の利用者が予約を入れてしまい,必要な部屋数を確保で きなくなってしまった場合には,その旨を画面に表示して予約の処理を中断する。 図1予約システムの主な要件 〔データベースの設計】 予約システムを開発するに当たり,データベースの設計を行った。データベースの E-R図を図2に示す。 部屋種別マスタ|凡例 施設名[し_5人]|a属性名 部屋種別D宿泊可能人数属性名 部屋番号属性名 ーーミュ半5 利用者ID予約D|a|予約明細ID.ーー:1対多 氏名利用者TD予約ID<>:多対多 住所人数部屋ID 電話番号チェッタイン日付宿泊日注記属性名の実線の下線____は主キー チェックアウト日付宿泊料破線の下線-----は外部キーを示す。 主キーの実線が付いている属性名には, 外部キーの破線を付けない。 図2データベースのE-R図(一部) このデータベースでは,E-R図のエンティティ名を表名にし,属性名を列名にして, 適切なデータ型で表定義した関係データベースによって,データを管理する。部屋 IDは,全施設を通して一意な値である。また,予約ID,予約明細IDは,レコード を挿入した順に値が大きくなる。 (部屋の予約の流れ] 部屋の予約は,部屋の空き状況の確認と,予約確定の二つの処理から成る。部屋を 予約する際には,希望した施設,部屋の種別,チェックイン日付,チェックアウト日 付,部屋数について,空き状況の照会を行う。照会の結果,部屋に空きがあった場合 lt,予約手続の画面を表示する。部屋に空きがなかった場合は,部屋が空いていない 旨を画面に表示し,空き部屋照会のための条件入力の画面に戻って条件を変更するよ う促す。 部屋の空き状況の確認を行うためのSQL文を図3に示す。予約する部屋の施設ID, 部屋種別ID,チェックイン日付,チェックアウト日付及び部屋数は,埋込み変数 本施設ID",“:部屋種別ID",“:チェックイン日付",“:チェックアウト日付"及び “部屋数”に設定されている。 ーー SELECT施設1D,部屋種別ID,COUNT(*)FROM部屋 L_』|※如必 WHERE( GROUP BY施設ID,部屋種別ID SELECT*FROM予約明細WHERE予約明細.部屋ID=部屋.部屋ID AND予約明細.宿泊日>=>:チェックイン日付AND予約明細.宿泊日く<:チェックアウト日付 図3部屋の空き状況の確認を行うためのSQL文 〔部屋の空き状況の確認の処理] 予約システムは,3のSQL文の検索結果として,レコードが返された場合に予 約可能であると判定し,予約手続の画面を表示する。レコードが返されなかった場合 は,部屋が空いていない旨を画面に表示する。空き状況確認の処理の流れを図4に 示す。 =i= 図3のSQL文で予約可能かを確認 ーー3ーーー* nc ee WAWS 予約手続の画面を表示面面に表示 | 図4空き状況確認の処理の流れ [予約確定の処理〕 予約手続の画面が表示された後,利用者は予約の確定の操作を行うことで部屋の予 約を確定させる。予約の確定の処理では,予約のレコードを挿入した後,各宿泊日に ついて,予約明細に必要な部屋数分のレコードを挿入する。 予約手続の画面が表示されてから,利用者が予約の確定の操作を行うまでの間に, 他の利用者が先に予約を確定してしまうこともある。そこで,予約確定の処理では, レコードの挿入の前に図3のSQL文を再度実行し,まだ予約可能な状態であるかを 確認してから挿入を行う。予約確定の処理の流れを図5に示す。 図3のSQL文で予約可能かを確認 St 予約可能な部屋の部屋IDを取得する いない旧を 画面に表示 レコードを挿入する 図5予約確定の処理の流れ 〔不具合の報告と対応 予約システムのテスト中に,同じ宿泊日の同じ部屋について,予約明細のレコード が重複して挿入されてしまう不具合が報告された。報告された事象について確認する と,別々の利用者が同じ時刻に予約確定の操作を行った際に発生していた。 そこで,今後同じ宿泊日の同じ部屋の予約が重複して入らないようにするために, 予約明細テーブルの| e ]列と|ft ]列の複合キーに対して制約を追加 することにした。このような制約のことを,|gz Jews. |g|を追加するためには,既に重複して挿入されてしまったレコードを削 除する必要がある。削除に当たっては,同じ宿泊日の同じ部屋の予約が重複した予約 明細のレコードについて,最初に挿入された予約のレコードと,それに紐づく予約明 細のレコードを残し,それ以外の予約明細,予約のレコードを削除することにした。 予約明細について,削除するレコードを抽出するSQL文を図6に示す。図6で得 られた該当の予約明細のレコードを削除するとともに,それらに紐づく予約のレコー ドを削除してから,テストの作業を再開することにした。 予約明細テーブルへの制約の追加後,当該の不具合について再度テストを行ったと ころ,追加した制約によって,重複が発生しなくなったことが確認できた。 WHERE t1.予約ID>(SELECT FROM予約明細t2 図6削除するレコードを抽出するSOL x

共通の文章

多言語多通貨対応両替システムに関する次の記述を読んで,設問14に答えよ。 G社は,訪日外国人観光客が所持する外貨紙幣を日本円に両替するための,多言語 多通貨対応両替システム(以下,両替システムという)を開発している。両替シス テムは,駅,商店などに設置される両替機,及びインターネットを介して両替機の 管理と両替機への情報提供を行う管理サーバで構成される。両替システムの構成を 1に,両替機の外観を図2に,両替機の内部構成を図3に,両替機の構成要素の 機能概要を表1に示す。 タッチパネルーーー一 ー生還 出金ロー明細書排出 図1両替システムの構成図2両替機の外観 シリアルバス 制御部 wo 図3両替機の内者構成 表1両替機の構成要素の機能概要 ・両替機全体の制御及び管理サーバとの通信を行う。 ッッテバネル|"制御部からの指示を茜に画面表示を行う。 ・利用者が画面にタッチしたら,座標情報を制御部に通知する。 ・外貨紙向が入金口から挿入されたら,通貨・金種を識別して制御部に通知する。 入金部・制御部からの指示を基に,挿入された外貨紙幣を入金口に戻すか,内部に格納す る。 ・制御部からの指示を基に,出金口から日本円紙幣・硬貨を出金する。 印刷部 ・制御部からの指示を基に,両替の結果を示す明細書を印刷して明細書排出口から排 出する。 [タッチパネルの画面構成 タッチパネルの画面は,両替可能な通貨の一覧表,言語名を表示した複数の言語 ボタン,及び両替ボタンで構成される。両替可能な通貨の一覧表には,通貨名,A 金額,両替レート,日本円額が含まれる。言語ボタンにタッチすると,タッチされ たボタンに対応した言語で画面を再表示する。タッチパネルの画面例を図4に示す。 —Wek Poca |※ドル|0o|iss|| |ウォン|ol|os|ol |Ame|ol|js49|ol 言語ボタン 図4タッチパネルの画面例 [両替機の動作概要〕 両替機は,利用可のとき,利用者が1枚目の外貨紙幣を入金口に挿入したら,i 替状態にする。両替機は,挿入された外貨紙幣を,通貨・金種の識別後,入金口に RID,入金部の内部に格納する。外貨紙幣を入金部の内部に格納したら,その外 貨紙幣の通貨に対応する,タッチパネルの画面の一覧表の入金額及び日本円額を更 新する。両替機は,両替状態の場合,外貨紙幣が1枚挿入されるたびに,これらの 動作を繰り返す。 利用者が両替ボタンにタッチすると,両替機は,明細書の印刷・排出と日本円紙 幣・硬貨の出金を行い,印刷・排出と出金が全て完了したら,両替状態を解除して, 1回の両替の動作を完了する。 [両替機の仕様 両替機の仕様は,次のとおりである。 ・1回の両替の動作で出金できる日本円額の合計は,1円以上10万円以下である。 ・次のいずれかの場合は,挿入された外貨紙幣を入金部の内部に格納せずに,入金 ー35一 口に戻してエラーメッセージを表示する。 -挿入された外貨紙幣を,両替可能な通貨・金種として識別できなかった。 -挿入された外貨紙幣を,入金部の内部に格納できない状態になっていた。 -挿入された外貨紙幣を格納しても,日本円額の合計が1円に満たない。 -挿入された外貨紙幣を格納すると,日本円額の合計が10万円を超えてしまう。 -挿入された外貨紙幣を格納すると,出金部がもっている日本円紙幣・硬貨の組 合せでは出金できない日本円額となかってしまう。 ・入金部の内部に一度格納した外貨紙幣は,入金口に戻さない。 ・両替ボタンは,両替状態で,日本円額の合計が1円以上の場合に反応する。 ・両替状態でないとき,定期的に管理サーバに問い合わせて両替レートを更新する。 両替レートを更新したら,タッチパネルの画面の一覧表も更新する。両替状態で は両替レートの更新を行わず,両替状態を解除した時に両替レートの更新を行う。 なお,両替状態となってから,入金部の内部に外貨紙幣を1枚も格納しないまま3 分経過した場合も,両替状態を解除する。 ・印刷・排出と出金が全て完了した時,次の事象が一つ以上発生していたら利用不 可とする。保守作業によって事象が全て解決されると,利用可にする。 -外貨紙幣を入金部の内部に格納できない状態である。 -出金部がもっている日本円の合計金額が10万円未満である。 -印刷部に格納されている明細書の用紙が不足している。 ・印刷・排出と出金が全て完了した時,管理サーバに利用可・利用不可のいずれか を報告する。 〔シリアルバス通信の概要〕 シリアルバス通信はポーリング方式とする。制御部から入金部,出金部,印刷部 の順に10ミリ秒周期でデータを送信し,入金部,出金部,印刷部は,自分宛てのデ ータを受信したら,制御部にデータを送信する。データは,宛先コード,データ長, 通知又は指示で構成される。シリアルバス通信のシーケンスを図5に,シリアルバ スで通信される主なメッセージを表2に示す。 ー36一 10ミリ秒|10ミリ秒|10ミリ秒①制御部一入金部②入金部一制御部 ls[el[e]lel[e}[al③制御部つ出金部④出金部一制御部 時間一-テ⑥制御部一印刷部⑥印刷部つ制御部 図5シリアルバス通信のシーケンス 表2シリアルバスで通信される主なメッセージ 〔制御部のソフトウェア構成 制御部の組込みソフトウェアには,リアルタイムOSを使用する。制御部の主なタ スクの一覧を表3に示す。 表3制御部の主なタスクの一覧 po RISEES Eee メイン・シリアルバスタスクを介して,入金部,出金部,印刷部を制御する。 ・通信タスクを介して,管理サーバと情報の送受信を行う。 ーー 表示操作・タッチパネルから通知された座標情報がボタン位置でもわれば,そのボタンの 情報をメインタスクに通知する。 [メインタスクのタイマ利用処理] メインタスクは両替状態となった時,| 』|後にイベントを受信するように, リアルタイム0Sのタイマを設定する。このイベントの受信時,両替状態となってか ー37一 ら,①ある条件を満たしたら,|pb|して,|c|を行う。

共通の文章

アジャイルソフトウェア開発手法の導入に関する次の記述を読んで,設問1~3に 答えよ。 H社は,電車や飛行機などの移動手段と宿泊施設をセットにしたパッケージツア ーをインターネットで販売している。このサービスを提供している現行システムに 移動途中や宿泊先近辺の商業施設と提携して,観光地の情報提供やクーポン配布を行 うサービスを追加することになった。その開発手法として,アジャイルソフトウェア 開発(以下、アジャイル開発という)手法の一つであるスクラムを採用する。 [開発体制の検討] 本開発を通してH社でアジャイル開発経験者を育成するために,プロジェクトメ ンバに求められる役割と割り当てるメンバ(MI~M7)について検討した。その開発 体制を表1に示す。 表1開発体制 [a|提携する商業施設との調整を行|MIアジャイル開発経験はなく,知識も い,追加するサービスに必要な機ほとんどない。 能を定義し,その機能を順位付け する。 スクラムマメンバ全員が|b|CH M2アジャイル開発経験はあるがスクラ KESできるように支援,マネジメントムマスタの経験はない。 する。 アジャイル|週に2日,社外から招へいされ,|M3スクラムマスタの経験が豊富であ コーチメンバに対してアジャイル開発手る。 法の導入や改善を支援する。 開発チーム|実際に開発を行う。M4,M5|アジャイル開発経験はないが,現行 システムをウォータフォールで開発 した経験はある。 M6,M7|アジャイル開発経験はあるが,現行上 システムを開発した経験はない。 [開発プロセスの検討 アジャイル開発経験者からアジャイル開発経験のないメンバに経験を伝えるために, プランニングポーカやペアプログラミングなどのプラクティスを幾つか導入すること にした。検討した開発プロセスを表2に示す。 表2開発プロセス プロジェクト|(1)プロジェクト方針の検|追加するサービスの目標,あるべき姿,基本的価 立上げay値観の共有を図る。 プロダクトバ|2)システムの目的の合意|システムの目的やゴールの共有を行う。 ックログの決|(3)リリース計画プロダクトバックログのグルーピングを行い,プ 定ロダクトバックログアイテムを決定する。 スプリント(4)スプリント計画プランニングポーカを用いて,チーム全員の知識 (イテレーション計画)や経験を共有しながらストーリポイントを用いた 見積りを行う。実施するタスクをスプリントバッ クログに追加する。 (5)スプリントタスクを実施する。プロダクトコードを開発する Bik,①ペアプログラミングを行う。デイリース クラム(日次ミーティング)でチームの状況を共 有する。 (6)スプリントレビュースプリントの成果物を|』|にデモする。 (デモ)その結果を,次のスプリント計画のインプットに する。 (7)レトロスペクティブスプリント中の改善事項を検討し,次回以降のス (ふりかえり)プリントで取り組むべき課題にする。 週に2 A,社外から招へいするアジャイルコーチが効果的にプロジェクトに参画 できるようにするため,招へいするタイミングを| c|及び[aq oz ァシリテータを依頼するタイミングに合わせてもらうことにした。 また,プロジェクトの進捗状況を可視化するためにバーンダウンチャートをホワイ トボードに書き,| e|ためにスプリントごとのベロシティを計測することに した。 [レトロスペクティブの実施〕 初回のスプリントのレトロスペクティブにおいて,二つの問題点が取り上げられた。 ーつ目は,デイリースクラムに目安の倍以上の時間を掛けてしまう問題点である。 状況を確認したところ,このミーティングはメンバの出社時間がバラバラなので夕方 に実施していた。また,その日の間題を解消するために解決方法まで議論することに していた。さらに,進捗状況を共有するために,タスクボードを作成し,その周囲に 集まって立った状態で実施していた。 二つ目は,スプリント計画どおりにタスクを全て終わらせることができなかった間 題点である。③スプリントバックログ管理上の課題を分析するために,バーンダウン チャートを用いてポイントと考えられる人箇所について確認した。バーンダウンチャー トを図1に,確認したポイントを図2に示す。 ・スプリント開始直後はメンバがスクラ [残ストーリポイント]ム開発の進め方に慣れていないために spニコソー実績が少なかった。 70 8日経過時点で。提携する商業施設から ーーの要亡でスプリントバックログにタス NO ey、、 fdクが追加された。 PN・8日経過時点からの7日間,類似機能の 30 TRE TELE fs, 20}Sonn開発のため予定より速くタスクを消化 CPべべ、Sg 9生か 9。2 4 6 8 10 12 14 16 18 20・16日経過時点で,考慮していないテス 凡例:………予定一実績[経過日数]トシナリオのタスクが見つかったの で,そのタスクが追加された。 図1バーンダウンチャート図2確認したポイント ニニつの問題点それぞれについて原因と解決策,課題を分析して,次回以降のスプリ ントで改善に取り組んだ結果.それらの問題点を解決できた。

共通の文章

稼働延期に伴うプロジェクト計画の変更に関する次の記述を読んで,設問1~4に 答えよ。 Q社は中堅の飲料メーカであり,卸や小売の顧客企業に酒類を販売している。一定 規模以上の顧客企業からはED]で注文を受けているが,小規模な顧客企業からはQ 社の販売部門がファックスや電話で注文を受けていた。小規模な顧客企業は約150社 存在し,販売部門の業務負荷が高かった。そこで業務効率向上を目的にWeb受注シ ステムを開発することを経営会議で決定した。さらに顧客企業への受注金額に応じた 支払代金の一部の定期的な払戻しや売掛金管理や入出金管理などの業務を手作業で実 施しているので,これらの業務も併せてシステム化することにした。販売部門からシ ステム部に開発を依頼し,プロジェクト(QE,Q社プロジェクトという)を立ち上 げた。 [Q社プロジェクトの概要) )開発対象のサブシステム 開発対象のサブシステムの概要と機能数を表1に示す。なお,各機能は全て同等 の開発規模である。 表1開発対象のサブシステムの概要と機能数 oe aa”)。|売金香。入出金管理。他システムとの酸読などの機能。|sl 顧客企業への払戻しの通知の機能 (2)開発体制 Q社のシステム部のR氏がプロジェクトマネージャ(PM)に任命され,開発要 員8人が割り当てられた。稼働日は2020年3月末が目標であった。 ーa= [プロジェクト計画の変更] Q社プロジェクトはソフトウェア要件定義(以下,要件定義という),ソフトウェ ア方式設計(以下,基本設計という),ソフトウェアコード作成及びテスト(以下, 製造という)の工程が終了し,テスト密度やテスト検出不具合密度などの品質管理の 指標値に問題がないことを確認した。しかし,ソフトウェア結合テスト(以下,結合 テストという)のテスト項目の消化が終了した時点で,全てのサブシステムで目標と するテスト検出不具合密度を大幅に超過する障害が発生していた。R氏は,システム 部の部長に状況を説明し,次週の経営会議に報告するよう指示を受けた。 経営会議では,品質に問題があって注文が正しく処理されないと顧客企業に迷惑が 掛かるので,品質の確保を最優先にすること,社内の業務効率向上が目的であり乏働 日には調整の余地があるので販売部門に確認すること,予算を超過するコストの追加 が必要な場合は経営会議の承認を得ること,が指示された。この指示を受けてR氏 lk,一了皇プロジェクトを中断してプロジェクト計画変更の検討を開始した。 R ld,販売部門に稼働日についてヒアリングして,“業務の都合上,2020年6月 30日に稼働させてほしい"との回答を得た。1週間後の経営会議で承認が得られて, 翌日にプロジェクトを再開すれば,6月29日までのプロジェクトの作業可能な日数 は100日であった。 〔結合テスト工程の障害の原因分析] R氏は上司のアドバイスを受けながら,結合テスト工程で発生した障害を複数の観 点で分析し, 2~4に整理した。テストケースの不備やテスト作業のミスを除くと, 障害件数は合計240件であった。 表2サブシステム別表3障害動作別の表4原因工程別の の障害分析表障害分析表障害分析表 co ae= 製造|40 —45— なお,表3の画面表示の障害とは,画面に表示する項目の位置がずれる障害で,商 品サブシステム及び販売サブシステムで発生している。また,表4の原因工程とは障 害の原因が作り込まれた工程を意味する。 R氏は品質の状態をサブシステム別の観点の分析から見た結果,特に販売サブシス テムの品質を強化することにした。さらに| 』|別の観点の分析から,成果物 を確認したところ,機能をまたがる整合性の確認が不十分であったことが分かった。 これによって,障害件数が目標とするテスト検出不具合密度を大幅に超過した根本原 因を特定した。そこで,R氏はこれまでに発生した障害の状況を踏まえて是正処置を 講じた上で,|b|工程から作業を再実施する方針とした。 〔販売部門との調整〕 R氏は,プロジェクト計画の変更に向けて,工数と期間の再見積りをすることにし た。その際,“再実施する工程",“再実施する結合テスト工程の障害の解消"及び “ソフトウェア適格性確認テスト・受入れテスト”"に分けて見積もることにして,表 5にその前提条件をまとめた。また,Q社のシステムの開発の経験があり,現在の開 発要員と同様の開発生産性を期待できる開発要員を社外から2名調達して,開発要員 を合計10名とすることにした。なお,開発要員は全てのサブシステムの全ての工程 に対応が可能なので,タスクの待ちはなくフル稼働し,PMの工数は見積りに含めな いものとする。 表5見積りの前提条件 前提条件 再実施する工程||p|エ程~結合テスト工程の再実施に,販売サプシステムは1機能 当たり20人日,他のサブシステムは1機能当たり10人日の工数を要する。 ・再実施する結合テスト工程の障害の解消の作業工数は上記の工数に含めな Wo 再実施する結合テ|・|b|エ程ご結合テスト工程を再実施することで,作業対象の障害件 スト工程の障害の|数は目標とするテスト検出不具合密度に収まり120件になる。 解消-障害の解消には,1件当たり2人日の作業工数を要する。 ソフトウェア適格|・プロジェクト計画変更前の見積りを採用し,両テスト合計で30日の期間を 性確認テスト・受|設ける。 入れテスト =46= "再実施する工程"と“再実施する結合テスト工程の障害の解消"それぞれの工数 と期間を見積もり,“ソフトウェア適格性確認テスト・受入れテスト”の期間を加え た。 見積りの結果,全てのサブプシステムを| b|工程からやり直し,再実施する 結合テスト工程の全ての障害を解消する場合,開発要員を増員した体制でも,稼働ま での作業に必要な日数は|c|日となり,期限に問に合わないことが分かった。 R氏は,開発要員を更に増やして作業期間を短縮する方法と,各工程の一部を並行実 行して作業期間を短縮する方法を検討したが,いずれも品質を確保する上でリスクが あるので,別の方法を検討する必要があると考えた。 そこで,R氏は販売部門とシステム稼働の開始を判断するための| q|を変 更することにした。検討の結果,“画面表示の障害はシステム利用の際に支障のある 問題点とはならないので6月30日の稼働後に対応する",“稼働日を考慮し,①リベ ートサブシステムを6月30日に稼働するスコープから外す"ことを提案することに した。これによる見積りの前提条件の変更点を表6にまとめた。 表6見積りの前提打件の変更点 前提条件の変更点 再実施する工程・リベートサブシステムをスコープから外す。この変更による他のサブシス テムの作業への影響はない。 再実施する結合テ|・表5で前提条件としたりリベートサプシステムの障害を障害件数から除外す スト工程の障害の|る。 解消・画面表示の障害を作業対象から除外する。 ・作業対象の障害件数は75件となる。 ソフトウェア適格|・リベートサプシステムをスコープから外すので,期間は4日短縮できて, 性確認テスト・受|26日間となる。 入れテスト 調整の結果,6月30日の稼働後に追加開発を行うことを条件に販売部門と |』|の変更の合意が取れた。作業が必要な日数は|ce|日となり,其 限に間に合う計画になつた。 〔経理の処理のパターンへの対応〕 販売部門からシステム部に,経理サブプシステムで算出する金額の誤りは業務への影 響が大きいので,全ての経理の処理のパターンにおいて現行業務で算出している金額 と経理サブシステムで算出する金額に差異がないように,特に注意して検証するよう 要請があった。R氏は,経理の処理に関する条件は多岐にわたるので,販売部門にデ ータの提供を依頼し,②結合テストで予定していたテストの他に別のテストを追加し た。このテストを追加しても期限には間に合うことも確認した。 [プロジェクトの監視〕 R氏は,これまでの検討結果を反映して,プロジェクト計画を変更し,予定してい た経営会議で承認を得たので,プロジェクトを再開した。R氏は,プロジェクトを再 開するに当たって,CPEMIMAT,計画どおりの工数で完了できるかどうかを見 極めるため,検証と監視を強化した。再実施する工程については,一部機能で先行作 業を行って,見積りどおりの工数に収まることを検証した。さらに再実施する結合テ スト工程の障害の解消については,表5及び表6の前提条件に基づいて,③再実施す る結合テスト工程で二つの指標の実績値を監視することにした。

共通の文章

問19サービスの予算業務及び会計業務に関する次の記述を読んで,設問1ー3に答えよ。 D社は,中堅の人材教育会社である。主な事業は次の三つである。 1)集合教育事業:大学受験や資格取得のための教室で受講する講座(以下,教室 講座という)の企画,教材開発及び運営 (2)通信教育事業:大学受験や資格取得のための自宅などからインターネットで受 講する講座(以下インターネット講座という)の企画,教材開発及び運営 (3)書籍出版事業:参考書籍の企画,制作,出版及び販売 これらの事業に対して,それぞれ担当する事業部がある。また,D社のシステム部 は,それぞれの事業部を顧客としてITサービスを提供し,事業活動を支援している。 システム部が提供するITサービスは,表1のとおりである。 表1システム部が提供するITサービス Se 注!集合教育事業部は,人気講師が行う好評な教室講座の内容を録画して,講座の教材 講座管理録・受講管理,講座内容のコンテンツ管理など 受講管理,講座内容の録画情報管理りなど など として活用している。講座の録画情報は,録画内容を素早く閲覧できるなどの多彩な 機能を備えた管理ソフトウェアを使って管理される。 D社の利用者は,高校生から社会人までと幅広いが,少子化や同業他社との競争激 化で,利用者数は年々減少傾向にある。特に学生層の利用者数の減少が顕著である。 その中で通信教育事業のインターネット講座だけは,その利便性から受講者数が増 加しているが,講座テキストを加工した音声のない静止画による講座(以下,静止画 講座という)の提供にとどまっていた。近年の無線通信の高速化の進展を受けて,受 講者からは動画による講座(以下,動画講座という)への要望が高まっつている。 動画講座の検討を開始した通信教育事業部のE課長は,システム部のF課長に動 画講座システムの実現方法の検討を依頼し,システム部のG主任が担当になった。 ー50一 [直接費の割当てと間接費の配農] D社では,システム部をコストセンタと位置付けている。また,D社の管理会計で は直接費と間接費を次のように定義している。システム部の費用のうち,特定の事業 部のITサービスで専用に使用されているシステム機器の費用,特定の事業部の指示 で実施する作業の費用は,直接費として当該事業部に割り当てる。複数の事業部の ITサービスで共用するシステム機器の費用,システム部管理職の人件費など,直接 費以外の費用は,総額を各事業部の売上額で接分して,各事業部に間接費として配須 する。一部の事業部では,©OMMAK ITサービスの利用実態に沿っていないと, 不公平感が高まっていた。 また,システム部は,ITサービスの提供のために管理する必要のある要素(以下, CIという)を,| 』|で管理している。[|』|には,“CIの属性",“CI間 の関係",“CIがどのサービスに使用されているか"などが登録されている。システ ム部では,CIが特定の事業部のITサービスで専用に使用されているか,|sa] を使って判定し,直接費を算出している。例えば,教室講座の内容の録画に必要な機 器及び管理ソフトウェアは,教室講座管理サービスだけで使用されているCIと判定 できるので,録画に必要な機器や保存に関わる教室講座の録画費用の全額を,ROK 育事業部に直接費として割り当てている。 [動画講座シレステムの実現] G主任は,通信教育事業部とともに,動画講座システムの実現に向けた調査を行っ Tee ・動画講座の提供によって,受講者数が1年間で1.5倍程度に増えることが見込まれ る。 ・集合教育事業部の録画情報を有効活用して,現行の静止画講座のコンテンツと組み 合わせることで,動画講座のコンテンツが作成できる。 D社では,このようなサービスの変更の実施に先立って,変更要求を変更管理プロ セスに提出する。変更管理プロセスでは変更審査会を開催し,変更要求の実施可否を 意思決定する。意思決定では,事業利益,技術的実現性,財務的な影響などを考慮す る。そこで,G主任は,動画講座システムの総所有費用(TCO)の見積りを作成す Soi,総所有費用の見積項目(抜粋)を表2にまとめた。 =Sif oe 表2動画講座システムの総所有費用の見積項目(抜粋) 初期サーバ,ストレージ,通信機器などの購入費用 用 開発人件費動画講座のコンテンツ作成,アプリケーションソフトウェア(以 及び外部委託費下,アプリソフトという)の開発などの費用 運用機械室,付帯設備などの使用料 費用通信回線の使用料 システム運用,アプリソフト保守に関わる人件費のうちの直接費 注記初期費用は,D社の会計基準にのっとり減価償却され,BA,減価償却費として計上される。 G主任は,システム運用作業及びアプリソフト保守作業についてシステム部内で調 査した。その結果,それぞれ作業工数は発生するが,システム運用作業は機械室の現 有オペレータの体制で運用可能であること,アプリソフト保守作業はインターネット 講座管理サービスの現有保守担当者の体制で保守可能であることが分かり,どちらも 増員の必要はない,と判断できた。G主任は,それぞれの作業で増員が発生しないの で,表2の運用人件費を0円として見積りを作成した。見積結果を上司のF課長に 報告すると,①運用人件費の算出の考え方を見直すように指示された。そこで,GE 任は,F課長の指示に従って正しく運用人件費の見積りを再作成した。 EOE,動画講座システムを追加するインターネット講座管理サービスの変更要求 に関する変更審査会が開催された。大規模な変更になるので,社経営会議のメンバ が承認者となった。変更審査会では,業界の動向調査の内容及び動画講座のメリット が説明された。また,動画講座のコンテンツ作成は,集合教育事業部の録画情報を有 効活用することで,費用を抑えることが可能であると説明された。承認者は,技術的 実現性に問題がなく,受講者数の拡大によって売上と利益の増加を見込めると判断し, 変更要求を承認した。承認された変更要求に基づき,GEES,動画講座システムの 構築作業を開始した。 なお,変更審査会では,“受講者数の増加傾向を毎月捕捉すること。”"との指示が あった。G主任は,これを受けて方策を検討した。利用者がITサービスを利用する 場合,まずシステムにログインして認証確認した後に,講座を受講したり,書籍を 購入したりする。このとき,利用者がどのサービスを利用したかという履歴が,ア クセスログとして記録されている。そこで,GEES,アクセスログを使って動画講 座の受講者数の増加傾向を捕捉することにした。 〔サービスの予算業務及び会計業務の改善検討] F課長は,動画講座システムが来年度から稼働することに決まったので,予算業務 として,今年度中に来年度のインターネット講座管理サービスの費用をまとめること にした。また,動画講座において予算の超過や不採算状況の発生が想定される場合に 迅速な対応がとれるように,②KPIを設定して管理していくことにした。RKPIは,毎 月,会計業務で扱う実績データの収集後に算定し,評価していく。 F課長は,一部の事業部が抱く間接費の配上方式への不公平感について,改善する 必要があると考えた。そこで,各事業部の売上額で捧分するのではなく,ITサービ スの利用実態に応じて披分する方式に変更する方法として,③アクセスログを使用し た間接費の配央方式を検討することにした。

共通の文章

販売システムの監査に関する次の記述を読んで,設問1一5に答えよ。 S社は中堅の電子部品メーカである。電子機器メーカなどの得意先に対して,電子 部品を製造し,販売している。 S社監査部では,定期的に業務監査を行っているが,これまでITに精通した要員 がおらず,業務で利用されている情報システムの監査が十分にはできていなかった。 そこで,情報システム部における開発経験が豊富なK氏を監査部に異動させること で,システム監査体制を強化した。GEE,監査部が販売システムの監査を実施す るに当たり,監査部長は,①K氏を監査人に任命することに関して,独立性の観点か ら確認し,監査チームのメンバとして参加させることにした。 監査チームは予備調査を行い,その結果,次のことが分かった。 〔販売業務の概要】 ①)受注処理 ・得意先からの発注データはEDIによって販売システムに取り込まれる。EDIを 利用していない得意先からの発注情報は.ファックス又は電子メールで送られ てくるので,それに基づいてS社営業部担当者が営業部端末から販売システム に直接受注入力する。 ・得意先ごとの受注条件,与信限度額は,営業部担当者の申請に基づき,管理部 担当者が,管理部長の承認を受け,販売システムのマスタ管理機能を利用して 得意先マスタに登録する。 ・得意先マスタに登録されている受注条件,与信限度額の範囲内の発注データは, 自動で受注確定されるとともに,物流システムに出荷指図データが送信される。 ・事前に登録された,受注条件や与信限度額の範囲を逸脱した発注データは,受 注エラーリストに出力され,受注処理が保留される。保留された発注データは, 営業部担当者が内容を確認のうえ,保留解除申請を行い,営業課長が販売シス テム上で承認処理を行うことで受注確定される。 (2)He tap ULE ・物流センタでは,出荷予定日になると,物流システムの出荷指図データに基づ き,出荷作業を行う。出荷作業が完了すると,物流システムから販売システム ce に出荷完了データが自動送信される。 ・物流システムからの出荷完了データに基づき,販売システムで販売データが作 成される。 (3)売上計上処理 ・販売データは,会計システムに日次バッチ処理で自動送信され,出荷基準に基 づいて売上計上される。会計システムからは,得意先別の売上金額などが記載 された得意先元帳を出力することができる。 ・営業部担当者は,販売システムから得意先別販売リストを毎月出力し,内容を 確認した後,営業課長に報告を行っている。 [システムの概要) ・S社の販売業務に関連するシステムは,販売システム,物流システム,会計システ ムである。各システムの関係及びデータの流れは,図1のとおりである。 ・販売システムと物流システムは,外部システムベンダに開発委託したシステムで ある。会計システムは,ソフトウェアパッケージをそのまま使用しており,販売 システムからのインタフェース部分を除き,特に独自機能の追加などは行ってい ない。 に ①発注データ ee Cos es っ出荷完了データ ⑨出荷指図データ ググ|販売データ 受注エラー|x リストだ ーーーーテ:帳票出力 図1販売業務関連システムの関係及びデータの流れ ー57一 〔本調査に向けた監査手続書の策定] 監査チームは,予備調査の結果に基づき,販売システムに関する監査手続を,表1 のとおりまとめた。 表1監査手続(抜粋) 1|受注|得意完マスタに受注条件や与信限度|得意先マスタへの登録手続に関して,@ 処理|額が事前に登録される。意先マスタへの登録時に|。|が あることを確かめる。 得意先マスタへのアクセス権限管理に関 LC,営業部担当者に得意先マスタの | b|ことを確かめる。 事前に登録された受注条件や与信限|発注データのチェックに関して,ORE 度額の範囲を逸脱した発注データ|条件や与信限度額の範囲を逸脱した架空 ik,受注エラーリストに出力され|の発注データを監査人が作成し,営業部 る。端末から販売システムに入力して,受注 エラーリストに出力されることを確かめ る。 受注エラーリストに出力された取引|受注処理の権限管理に関して,承認処理 は,営業課長が承認処理を行うこと|を行う営業課長には|c|]ことを で受注確定される。確かめる。 2|出荷|物流システムから販売システムに出|物流システムと販売システムのインタフ 処理|荷完了データが自動送信される。|エースに関して,物流システムの出荷完 了データ件数と販売システムの出荷完了 データ件数が一致することを確かめる。 3売上|販売システムから会計システムには|販売システムと会計システムのインタフ 計上|販売データが日次バッチ処理で自動|エースに関して,⑧得意先別販売リスト 処理|送信される。の販売金額と得意先元帳の売上金額がゲー 致することを確かめる。 K氏は,売上計上処理の監査手続の前提として,得意先別販売リストの販売金額が 適切に出力されていることを確かめるために,次の監査手続の追加を提案した。 ・販売システムに取り込まれた|ai]を集計し,得意先別販売リストの販売金 額と一致することを確かめる。