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

共通の文章

DNSのセキュリティ対策に関する次の記述を読んで,設問1ー3に答えよ。 R社は,Webサイト向けソフトウェアの開発を主業務とする,従業員約50名の企 業である。R社の会社概要や事業内容などをREO Webサイト(以下,R社サイト という)に掲示している。 R社内からインターネットへのアクセスは,R社が使用するデータセンタを経由し て行われている。データセンタのDMZには,R社のWebサーバ,権威DNSサーバ, キャッシュDNSサーバなどが設置されている。DMZは,ファイアウォール(以下, FWという)を介して,インターネットとR HAW LANの両方に接続している。デ ータセンタ内のR社のネットワーク構成の一部を図1に示す。 DNSサーバサーバ 図1データセンタ内のR社のネットワーク構成(一部) R社サイトは,データセンタ内のWebサーバで運用され,インターネットからR 社サイトへは,HTTP Over TLS(LAF,HTTPSという)によるアクセスだけが許さ れている。 [インシデントの発生〕 HSH,R社の顧客であるY社の担当者から,“社員のPC A,R社サイトに埋め 込まれていたリンクからマルウェアに感染したと思われる"”との連絡を受けた。Y社 は,Y社が契約しているISPであるZ社のDNSサーバを利用していた。 R社情報システム部のS部長は,部員のTさんに,R社のネットワークのインタ ーネット接続を一時的に切断し,マルウェア感染の状況について調査するように指示 した。Tさんが調査した結果,R社の権威DNSサーバ上の,R社のWebサーバのA レコードが別のサイトのIPアドレスに改ざんされていることが分かった。R HOF ャッシュDNSサーバとWebサーバには,侵入や改ざんされた形跡はなかった。 —4一 Tさんから報告を受けたS部長は,①Y社のPCがR社の偽サイトに誘導され,マ ルウェアに感染した可能性が高いと判断した。 〔当該インシデントの原因調査 S部長は,当該インシデントの原因調査のために,R社の権威DNSサーバ,キャ ッシュDNSサーバ及びWebサーバの騰弄性診断及びログ解析を実施するよう,TA んに指示した。Tさんは外部のセキュリティ会社の協力を受けて,脆弱性診断とログ 解析を実施した。診断結果の一部を表1に示す。 表1 R社サーバの脆弱性診断及びログ解析の結果(一部) [ 上RE Webサーバ・OS及びWebサーバのソフトウェアは最新であった。Y社のPCがマルウェア感染し 権威DNSサ|+OSは最新であったが,DNSソフトウェアのバージョンが|業務時間外にログインされた DNSサーバ・インターネットからキャッシュDNSサーバへのアクセス|されなかった。 ・インターネットから権成DNSサーバへのアクセスはDNS だけに制限されていた。クセスがほとんどなかった。 はDNSプロトコルだけに制限されていた。 プロトコルだけに制限されていた。 診断結果を確認したS部長は,R社の権威DNSサーバのDNSソフトウェアの脆弱 性を悪用した攻撃によって|a|が礁取された可能性が高いと考え,早急にそ の脆弱性への対応を行うようにさんに指示した。 Tさんは,R社の権威DNSサーバのDNSソフトウェアの脆弱性は,ソフトウェア ベンダが提供する最新版のソフトウェアてで対応可能であることを確認し,当該ソフト ウェアをアップデートしたことをS部長に報告した。S SURAT XA,R社の権威 DNSサーバ上のR社のWebサーバのAレコードを正しいIPアドレスに戻し,R社 のネットワークのインターネット接続を再開させたが,Y社のPCからR社サイトに 正しくアクセスできるようになるまで,③しばらく時間が掛かった。R社は,Y社に 謝罪するとともに,当該インシデントについて経緯などをとりまとめて,R社サイト などを通じて,顧客を含む関係者に周知した。 “ag me [セキュリティ対策の検討〕 S部長は,R社の権威DNSサーバに対する③同様ながインシデントの再発防止に有 効な対策と,R社のキャッシュDNSサーバ及びWebサーバに対するセキュリティ対 策の強化を検討するように,Tさんに指示した。 Tさんは,R社のWebサーバが使用しているディジタル証明書が,ドメイン名の 所有者であることが確認できるDV(Domain Validation)証明書であることが問題と 考えた。そこでTTさんは,EV(Extended Validation)証明書を導入することを提案し た。R社のWebサーバにEV証明書を導入し,WebブラウザでR社サイトにHTTPS でアクセスすると,R社の|vb|を確認できる。 またTさんは,⑥R社のキャッシュDNSサーバがインターネットから問合せ可能 であることも問題だと考えた。その対策として,FWの設定を修正してR社社内 LANからだけ問合せ可能とすることを提案した。また,R社のキャッシュDNSサー iz,偽のDNS応答がキャッシュされ,R社の社内LAN上のPCがインターネット 上の偽サイトに誘導されてしまう,|c|の育成があると考えた。DNSソフト ウェアの最新版を確認したところ,ソースポートのランダム化などに対応しているこ とから,この困威については対応済みとして報告した。

共通の文章

情報システム戦略の策定に関する次の記述を読んで,設問1ご3に答えよ。 C社は,中堅の機械部品メーカである。自動車メーカなど顧客の工場に製品を出荷 している。顧客の工場は国内だけでなく,世界の各地域に設置されている。 C社は,これまで情報システムはコストと考えていて,情報システム投資に消極的 であった。その結果,業務効率が上がらず,また必要なデータがすぐに把握できずに 経営陣の意思決定に遅れが生じていた。このような中,経済産業省のDXレポートを 確認したC社の経営陣は危機感をもち,情報システム投資の必要性を強く感じて, 外部からCIO(Chief Information Officer)を採用した。CIOは,次期経営戦略に基づ いて積極的な次期情報システム戦略を策定する方針を掲げ,これを立案する組織横断 型のチームを立ち上げて,情報システム部のD課長をリーダに任命した。 (C社の次期経営戦略 C社の次期経営戦略は,競合他社に対する競争優位性を保つため,次を目的として 策定された。 ・コンプライアンスを最優先し,ステークホルダから選ばれる企業になる。 ・技術力を生かし,顧客及び社会のニーズに合う製品を積極的に市場に投入し,シェ アを拡大して売上を伸ばす。 ・業務効率を向上させ,利益率を改善する。 ・経営陣が必要な情報をタイムリーに把握し,迅速な意思決定を行えるようにする。 (C社の経営環境) C社の経営環境は次のとおりである。 ・これまでは市場の伸びに支えられ,売上も利益も伸びていた。しかし,最近の市場 の伸びの鈍化に伴い,既存製品の売上と利益の伸びが鈍化している。 ・C社が取り扱う製品の開発には高い技術力が要求される。C社は,将来に向けた研 究に力を入れており,研究開発部を設け,競合他社にはない優れたアイディアを出 したり,技術を開発したりしている。しかし,それがどのように製品に結び付けら れるか研究開発部では具体的な活用の方法がイメージできないことがある。BRA と顧客のやり取りにヒントとなる情報があるが,研究開発部には情報が届いていな =3= い。 ・競合他社はアジア地域に工場を設置しているケースが多いのに対し,C社は国内外 を問わず顧客の工場の近くに自社の工場を設置している。 ・C社は,各工場で独自の製造ノウハウを多数もっており,各工場の業務プロセスや 各工場に設置されている情報システムにこれらを反映させ,競争優位性を保ってい る。 ・これまでは,顧客からの引合いに対応することで製品を受注できたので,販売・マ ーケティングにはあまり力を入れてこなかった。しかし,新たな製品を市場に投入 する際には,その特長を顧客に理解してもらう必要があり,現状では不十分である。 ・複数の営業員で,同じ顧客の本社,事業所及び工場を分担して担当している。営業 員が顧客から得た情報や顧客への対応内容が,同じ顧客を担当する他の営業員と十 分に共有できていないので,非効率な営業となっていることがある。 ・C社の製品採用後の顧客に対するサービスは,顧客を訪問して行っている。顧客訪 間時の担当者による丁寧な対応が好評であり,C社のサービスは競合他社に比べて 優れているという,顧客からの好意的な意見が多い。 ・研究開発部が利用している技術開発支援システムを除く,C社の本社や各工場で利 用している情報システム(以下,C社基幹システムという)は,個別に開発・運 用・保守をしているので,データが統合されていない。C社基幹システムの構造は 複雑化しており,情報システム部ではこの運用・保守に掛かる労力が増加している。 ・競合他社に打ち勝つために,情報システム部では,AIなどの最新のディジタル技 術の早期習得が必要となってきているが,既存情報システムの運用・保守の業務に 追われ手が回っていない。 〔パバリューチェーンJ〕 D RRS,バリューチェーン分析を行うこととし,まず,C社で行っている | 。]を作る活動について,調査・分析した。その結果,C社の諸活動は図1 の一般的なバリューチェーンで表されることを確認した。 Hk,バリューチェーンの諸活動のコストも分析した。 as,作られた総|』|e,[oa|を作る活動の総コストの差が, ||とss。 a 全般管理(インフラストラクチャ) 人事労務管理 i技術開発 i)購買物流製造出荷物流ケティング 次買物流fit vats 1 wae|販売・マー 出典:ME,ポーター著“競争優位の戦略"を基に作成 1りりコーチェーシ (C社の強みと弱み} 次に,D課長はバリューチェーンの諸活動について,C社の経営環境から強みと弱 みを分析した。 C社の強みを抜粋して,表1に示す。 表1 C社の強み(抜粋) 競合他社にはない優れたアイディアの創出や技術の開発をしている。|技術開発 独自の製造ノウハウによって競争優位性を保っている。 顧客訪問時の担当者による丁寧な対応が好評である。 一方,弱みとしては,新たな製品の市場投入の際には特に重要な|qd|の活 動が挙げられた。 (次期情報システム戦略と計画) D課長は,これまでの分析結果を基に,C社基幹システムを吊新する次期情報シス テム戦略を策定し,計画を次のとおり立案した。 ・SaaSのERPを導入し,カスタマイズは最小限にして極力標準機能を使用すること によって,情報システム部では|e|を削減し,現在できていない eff. ・経営陣が迅速な意思決定ができるように,データウェアハウスを導入し,様々なソ ーネデー用を。ツールを使ってデータウェアハウスに書き込み,統合 する。 ・同じ顧客を担当する営業員が,情報を共有し効率的な営業を行えるように,SFAを 導入する。 SFAで利用が想定される主な機能を表2に示す。 表2 SFAで利用が想定される主な機能 SFAの機能名称機能概要 顧客企業の情報を収集し,管理する。 顧客担当者管理|名刺の内容をディジタル化し,顧客担当者の情報として管理する。 3|顧客対応管理|製品に対する顧客の意見など営業員が顧客から得た情報や顧客へ の対応内容を記録し,情報共有を可能とする。 4|商談管理営業員が商談の提案内容や進捗状況を入力する。営業マネージャに よる商談の状況把握と部下へのコーチングを可能とする。 5|案件管理顧客からの引合いを受注につなげるために,ME,担当営業員,提 案製品受注見込額などの営業案件の情報を管理する。 予算実績管理|営業員別,顧客別,製品別,期間別などで売上の予算と実績を把握 し,進捗を管理する。 7|行動管理BEAK,提案製品数,受注率などを定量的に把握して,営業 員の行動を管理する。 D課長が,これらの次期情報システム戦略,計画及びSFAで利用が想定される主 な機能をCIOに説明したところ,次の指摘を受けた。 ・C社の経営環境やバリューチェーン分析の結果を考慮すると,①ある活動について lk,C社基幹システムの機能をERPの標準機能に置き換えてよいかを慎重に検討 すべきである。 ・表2中の,②ある機能は,C社の経営環境における営業員以外の課題の解決にも役 立てることができるので,活用を検討すべきである。 D課長はCIOの指摘を踏まえて,次期情報システム戦略と計画を修正した。

共通の文章

クラスタ分析に用いるk-means法に関する次の記述を読んで,設問1~3に答えよ。 k-means法によるクラスタ分析は,異なる性質のものが混ざり合った母集団から互 いに似た性質をもつものを集め,クラスタと呼ばれる互いに素な部分集合に分類する 手法である。新聞記事のビッグデータ検索,店舗の品ぞろえの分類,教師なし機械学 習などで利用されている。ここでは,2次元データを扱うこととする。 [分類方法と例] N個の点をK個(N未満)のクラスタに分類する方法を(1)~て(5)に示す。 (1)N個の点(1からNまでの番号が付いている)からランダムにK個の点を選び (以下,初期設定という),それらの点をコアと呼ぶ、コアには1からKまでのコ ア番号を付ける。なお,K個のコアの座標は全て異なっていなければならない。 (2)N個の点とK個のコアとの距離をそれぞれ計算し,各点から見て,距離が最も 短いコア(複数存在する場合は,番号が最も小さいコア)を選ぶ。選ばれたコアの コア番号を,各点が所属する1回目のクラスタ番号(1からK)とする。ここで, 二つの点をXY座標を用いてP=(a,b)とQ=(,①とした場合,PとQの距離を 7(aーO2+(bdの2で計算する。 (3)K個のクラスタのそれぞれについて,クラスタに含まれる全ての点を使って重 心を求める。ここで,重心のX座標をクラスタに含まれる点のX座標の平均,Y 座標をクラスタに含まれる点のY座標の平均と定義する。ここで求めた重心の番 号はクラスタの番号と同じとする。 (4)N個の点と各クラスタの重心(Gj,…,Gx)との距離をそれぞれ計算し,各点か ら見て距離が最も短い重心(複数存在する場合は,番号が最も小さい重心)を選ぶ。 選ばれた重心の番号を,各点が所属する次のクラスタ番号とする。 (5)重心の座標が変わちなくなるまで,(3③)と(④を繰り返す。 次の座標で与えられる7個の点を,この分類方法に従い二つのクラスタに分類 する例を図1に示す。 P」=(1,0)P2=(2,1)P。三(4,1)Ps=(1.5,2)Ps=(1,3)Pe=(2,3)P,三(4,3) ー4一 YA Ps Py;Pr(①)初期設定はコア1ニニP。,コア2三Psとする。 ーートーパー②)各点とコアの距離から表1のように所属クラスタを求める。 1.….…3)クラスタの重心を計算し,クラスタ1の重心Gュは(2.5,14), |p 1 Ppクラスタ2の重心G。は|アァ]となる。 1すす…(4④)各点と重心の距離から表2のように所属クラスタを見直す。 Pro©)⑬)と(④⑭を繰り返し,重心の座標が変わらなくなると①分類が完 0 1 2 3 4X了する。 図1 7個の点の分類 表1コアとの距離と所属クラスタ表2重心との距離と次の所属クラスタ wg[ATLL]コア2と|所属クラ|重心Gi|HG.|次の所属 "|の距離|の距離|スタ番号“|との距離|との距離|クラスタ番号 et 2|3|ij| rey o|w|1|[gl o|206|1| [Pal y522|v5/2|1|[Pat 116|100|2| Ps|ve|0O|2| ll 2|1|2 IP|167|o50|2 注記距離は小数第3位以下切捨て 〔クラスタ分析のプログラム] この手法のプログラムを図2に,プログラムで使う主な変数,関数及び配列を表3 に示す。ここで,配列の添字は全て1から始まり,要素の初期値は全て0とする。 表3クラスタ分析のプログラムで使う主な変数,関数及び配列 配列|コア番号がtである点P。の番号mを格納する。 idalO nays:|分期設定として次の処理を行う。N個の点(P。P。…,Py)からランダ mムに異なるK個を抽出し,その番号を順に配列coreに格納する。 点P。とコア番号がtである点の距離を返す。 点P。と重心G,の距離を返す。 配列|ある点から見た,コア番号がtである点との距離を格納する。 配列|ある点から見た,重心G,との距離を格納する。 min index()配列の中で,最小値が格納されている添字sを返す。最小値がニつ以 引数は上ある場合は,最も小さい添字を返す。 Se aa Bl右の配列に対する戻り値は2添字1 2 3 4 5 gray length配列 配列|点P。が所属するクラスタ番号を格納する。 配列|重心G。のX座標を格納する。 表3クラスタ分析のプログラムで使う主な変数,関数及び配列(続き) function clustering(N,K)//Nはデータ数,Kはクラスタ数 MaxCount<100//無限ループを防ぐため最大見直し回数を設定 initial(K)//初期設定 for(sを1からNまで1ずつ増やす)//クラスタを決定(1回目) for(tを1からKまで1ずつ増やす) data_length[t]<data dist(s,core[t]) endfor cluster[s]でmin_index(data_length) endfor for(pを1からMaxCountまで1ずつ増やす) //クラスタを見直す if(pが1と等しい) for()//1回目の重心の計算 coordinate x[t]<gravity_x(t) coordinate_yLt]<gravity_y(t) endfor else for()//2回目以降の重心の計算 if(gravity_x(t)&coordinate_x[t]が異なる//重心を修正する 又はgravity y(t)とcoordinate_y[t]が異なる) coordinate x[t]<gravity_x(t) coordinate y[t]<gravity_y(t) flagで1 endif endfor if()//終了して抜ける return endif endif for(sを1からNまで1ずつ増やす)//近い重心を見つける for(tを1からKまで1ずつ増やす) grav length[t]<grav dist(s,t) endfor endfor endfor endfunction 図2クラスタ分析の関数clusteringのプログラム (初期設定の改良 このアルゴリズムの最終結果は初期設定に依存し,そこでのコア間の距離が短いと 適切な分類結果を得にくい。そこで,関数mitialにおいて一つ目のコアはランダムに 選び,それ以降はコア間の距離が長くなる点が選ばれやすくなるアルゴリズムを検討 した。検討したアルゴリズムでは,t番目までのコアが決まった後,t十1番目のコア を残った点から選ぶときに,それまでに決まったコアから離れた点を,より高い確率 で選ぶようにする。具体的には,それまでに決まったコア(コア1てコアt)と,残 ったN-t個の点から選んだ点P。との距離の和をT。とする。Nーt個の全ての点につ いてTek,T。が|カ|ほど高い確率で点P。が選ばれるようにする。この とき,点P。が〔+1番目のコアとして選ばれる確率として|キ|を適用する。

共通の文章

IoT技術を活用した駐車場管理システムに関する次の記述を読んで,RA 1~4に 答えよ。 K社は,大都市圏を中心に約10万台分の時間貸し駐車場(以下,駐車場という) を所有する駐車場運営会社である。K社が所有する駐車場の“満車",“空車"の状況 や課金状況などは,K社が構築した駐車場管理システムで管理している。K社では, 5年後には所有する駐車場を約20万台分に拡大する計画に加え,新規事業の拡大や 顧客サービスの向上策を検討することになった。 K社の経営企画部で,顧客サービスの向上策を検討した結果,その一つとして,駐 車場の利用状況を表示するスマートフォン向けアプリケーションソフトウェア(以下, 駐車場アプリという)を開発することになった。 〔駐車場管理システムと駐車場アプリの仕様の検討] 経営企画部のLさんは,駐車場アプリを実現するために,既存の駐車場管理シス テムを拡張することを検討した。拡張する機能仕様とシステム要件の案の一部を表1 に,駐車場アプリの仕様案の一部を表2に示す。 にーー fees 2|センサで温度・湿度・気圧などの環境情報を取得して,顧客が閲覧できるようにする。環 ーキングスロットに設置するセンサはバッテリ給電とする。 ロットという)ごとに利用状況を確認できるセンサを設置して,利用状況を表示する。パ このシステムで受信可能なパーキングスロットごとの環境情報データのサイズは,1回当 表1拡張する機能仕様とシステム要件の案(一部) たり最大2.000バイトとする。 利用する。 が扱えるシステムとする。 =Bim 表2駐車場アプリの仕様案(一部) ーー Lさんは,表1及び表2の案を実現するために,パーキングスロットに設置する, センサを内蔵した通信端末(以下,端末Pという)の仕様を検討した。端末Pの仕 様案の一部を表3に示す。 表3端末Pの仕様案(一部) = Pee|ae eR 注記1各情報には,端末を特定する情報や日時情報などを含む。 収集する情報とデータサイズ|一つのパーキングスロットの利用状況情報及び環境情報 Telemetry Transport),MQTTS(TLSで暗号化したMQTT) ト 注記2データサイズには,通信プロトコルなどの制御情報を含む。 〔無線通信方式の検討] Lさんは,表3に示す無線通信方式の候補から,表1の項番4の仕様を実現するた めに適切な方式を検討した。検討の過程を次に示す。 LTEは,携帯電話やスマートフォン向けのモバイル通信サービスで利用されてい る方式であり,全国47都道府県で利用可能である。 LPWAは,通信加度は[|。|]が,|b|の通信方式として,IoT向けに 低価格のサービスが普及している。LTEを活用したLPWA(以下,LTE-M方式とい う)を利用すれば,LTEと同様に全国47都道府県で利用可能である。 Wi-Fi及びBLEは,PCやスマートフォンの通信に利用されることが多い通信方式 =HB;es である。BLEも| b|という特徴がある。しかし,いずれも,端末Pからクラ ウドサービスにデータを送信するために,別の無線通信や有線回線などと組み合わせ る必要がある。 検討の結果,端末Pの通信方式にはLTE-M HAO LPWA通信サービス(以下, LPWA通信サービスという)を採用することにした。 (LPWA通信サービスの選択 端末Pで利用可能なLPWA通信サービスでは,月間に使用できる最大データ通信 量に応じて異なる料金プランが用意されていた。候補となったLPWA通信サービス の料金プランを表4に示す。 表4端末Pで利用可能なLPWA通信サービスの料金プラン ==SS= 注記1各料金プランとも,サービスエリアは47都道府県の主要駅周辺をカバーしている。 注記2消費電力量はいずれのサービスも同程度である。 注記3各料金プランとも,最大通信速度は上り下りともに1.000kビットノ秒である。 表2の各仕様を満足させるために,端末Pからクラウドサービスにデータを送信 する頻度は,パーキングスロットの利用状況が変わるごととし,1分以内に送信する ことを基本とした。ただし,利用状況が長時間変わらない場合も環境情報の更新のた めに定期的に送信する。なお,1台の端末P当たりの送信回数は,1日30回を上限 Lok,Ek,使用するデータ送信方式は,表3の候補からHTTPを用いることに した。この仕様を満たした上で,HTTP通信での通信料金が最も安くなる①LPWA通 信サービスの料金プランを選択した。 [クラウドサービスへのデータ蓄積とサービス提供 表2の各仕様を実現するために,全てのパーキングスロットに端末Pを設置して, _BF= (LPWA通信サービスの選択〕で検討した頻度でクラウドサービスにデータを送信し, 蓄積することにした。 一方,駐車場アプリからクラウドサービスへのアクセスでは,利用者のスマートフ ォン1台当たりに必要な帯域は64kビットノ秒と想定した。 結果として,クラウドサービスで使用する②通信帯域は,端末Pからのデータ収 集と駐車場アプリ利用者のスマートフォンからのアクセスが同時に発生することを想 定して,確保することにした。 また,クラウドサービスの⑨③保存領域は,5年後に計画されている拡大した駐車場 の人台数でも,環境情報が最大5年間保管できるように,確保することにした。 〔データ送信方式の検討 LPWA通信でエラーが発生した期間に,送信すべきデータが欠損することを避ける DIL,端末Pに送信すべきデータを蓄積し,現在のデータを送信する際に,過去 に送信できなかったデータを選別して,同時に送信することにした。送信エラーが続 き,送信データ量の累積が|<|を超えないように,新しいデータから順に選 んで送信することにした。 また,(LPWA通信サービスの選択〕で検討時に想定したHTTPでは端末Pからク ラウドサービスに送信するデータが暗号化されないことから,データ送信方式には, 表3に示した候補から,④暗号化通信時に最も通信量の少ない方式を採用することに Liles Lさんは,検討した実現方式を上司に説明し,承認された。

共通の文章

チャット機能の開発に関する次の記述を読んで,設問1ー3に答えよ。 E社は,旅行商品の企画,運営,販売を行う旅行会社である。E社の旅行商品は, 自社の販売店と販売代理会社の販売店を通じて販売している。販売店に顧客が来ると, 販売スタッフが社の旅行販売システムを利用して,顧客の要望に合う旅行商品を 検索し,顧客に提案している。また,顧客からの旅行商品に関する質問の回答が分か らない場合,E社の販売店向けコールセンタに電話で問い合わせることになっている が,販売店からは“コールセンタに電話が繋がらない”などの苦情が出ている。 そこで社は,販売店とコールセンタのスタッフがテキストメッセージで相互に やり取りできるチャット機能を,旅行販売システムに追加することにした。チャット 機能の開発は,E社システム部門のF君が担当することになった。 [ネットワーク構成の調査 F君は。チャット機能を開発するに当たり,現在のネットワーク構成を調査した。 図1にF君が調査したネットワーク構成(抜粋)を示す。 E社販売店E社データセンタ 販売代理会社|et 04602|DNS.| 本社ーHI FnWみ3 10.1.1.2 10.1.1.1ーー一 10.0.0.2 10.10.0.1 ーバ プロキシ旅行販売システム サーバ|eegos EAE 10.10.0.10負人分散 192.168.0.4|ルータ 販売店#1 an eel 192.168.1.wa4|eoonpサーバ #2 FW:ファイアウォールAPサーバ:アプリケーションサーバ 図1 F君が調査したネットワーク構成(抜粋) 旅行販売システムは,2台のAPサーバと負荷分散装置から構成されている。負和荷 分散装置はAPサーバの負荷を分散させるために利用される。DNSサーバのAVA ードには,旅行販売システムのIPアドレスとして[a|が登録されている。 販売代理会社の販売店のPCから旅行販売システムへの通信は,FW,ルータ,プ ロキシサーバを経由している。FW#3では,NAPTを行い,宛先ポートが53番ポー ト,80番ポート又は443番ポートで宛先ネットワークアドレスが10.10.0.0のIPパ ケットとその返信IPパケナットだけを通信許可する設定となっている。 販売代理会社の販売店のPCがHTTPを利用して旅行販売システムにアクセスする 場合プロキシサーバはPCから受信したGETメソッドを参照して,APサーバへ HTTPリクエストを送信する。一方,HTTP Over TLSを利用する場合は,プロキシ サーバは旅行販売システムの機器とTCPコネクションを確立し,①PCから受信した データをそのまま送信する。 また,販売代理会社の販売店のPCから旅行販売システムへアクセスする場合, PCからFW#4に送信されるIPパケットの宛先Pアドレスは|pb|となり, 代理会社接続ルータからFW#1に送信されるIPパケットの送信元IPアドレスは [チャット機能の実装方式の検討] 次にF Ald,チャット機能の実装方式を検討した。チャット機能を実装する場合, 旅行販売システムで利用している②HTTPでは実装が困難である。そこででAld, チャット機能の実装のためにWebSocketについて調査を行った。2にF君が調査 したWebSocketを利用した通信(抜粋)を示す。 GET/chat Upgrade:websocket Connection:Upgrade Upgrade:websocket Connection:Upgrade a & 注記図中のPCは,人社販売店のPCと販売代理会社の販売店のPCを指す。 図2『君が調査したWebSocketを利用した通信(抜粋) WebSocketを利用すると,PCとAPサーバの間のHTTPを用いた通信を拡張し, 任意フォーマットのデータの双方向通信ができる。WebSocketを利用するためには, PCからAPサーバにHTTPと同様のGETメソッドを送信する。このGETメソッド のHTTPヘッダに“Upgrade:websocket”&“Connection:Upgrade"を含めることで, PCとAPサーバの間でWebSocketの接続が確立する。接続が確立したら,PCとAP サーバのどちらからでも,テキストメッセージを送信できる。 この調査結果からF lt,IRC(Internet Relay Chat)プロトコルや新たにチャッ ト機能専用のプロトコルを利用する場合と比較し,③WebSocketを利用することで販 売代理会社のFWやルータの設定変更を少なくできると考えた。 〔チャット機能の設計レビュー〕 F君は,APサーバにチャット機能を追加するための設計を行い,上司のG課長の レビューを受けた。レビューの結果,G課長から次の2点の指摘があった。 指摘1.WebSocketはTCPコネクションを確立したままにするので,負荷分散装置 を経由してチャット機能ヘアクセスすると,旅行販売システムの既存機能 へのアクセスに影響がある。 指摘2.チャット機能をWebSocket Over TLSに対応させないと,販売代理会社から プロキシサーバを経由してチャット機能にアクセスできない。 F君は指摘1について,チャット機能では負荷分散装置を使わなかいことにし,Et データセンタ内にある機器を利用した③④ほかの負荷分散方式に変更した。 次に指摘2について,WebSocketを利用した通信ではTCPコネクションを確立し たままにする必要があるので,プロキシサーバのHTTP Over TLSのデータをそのま ま送信する機能を利用することで,プロキシサーバ経由でチャット機能が利用できる。 そこで,君はTLS証明書を|qd|にインストールし,チャット機能の通信を HTTP Over TLSに対応させた。 その後F AM,チャット機能を旅行販売システムに追加したことで,販売店での チャット機能の利用が開始された。 <2 i=

共通の文章

経営分析システムのためのデータベース設計に関する次の記述を読んで,設問1~ 4に答えよ。 P社は,個人向けのカーシェアリングサービスを運営するMaaS(Mobility as a Service)事業者である。シェアリングのニーズが高い大都市の地区を中心に,500 BE 車場で約2.000台の自動車(以下,車両という)を貸し出している。P社には本社の ほかに,各地区でのサービス運営を担当する支社が10社ある。本社はサービス全体 を統括しており,新サービスの企画やマーケティングなどを行っている。支社は貸出 管理システムを用いて現場で車両の貸出管理業務を行っている。 本社では,サービス運営状況を多角的な観点でタイムリーに把握して,適切な意思 決定を行うために,貸出管理システムのデータをソースとする経営分析システムを構 築することになった。本社の情報システム部のQさんはデータエンジニアに任命さ れ,データサイエンティイストであるRさんとプロジェクトを推進することになった。 [データソースの調査 貸出管理システムには,貸出予約及び貸出実績のデータが過去5年間分蓄積されて いる。貸出管理システムのデータモデルの抜粋を図1に示す。 凡例一一:1装1 プランID支社ID||駐車場ID>:1S プラン名支社名||支社D車両D<>|HS 基本料金地区駐車場名車種ID駐車場ID 従量料金単価車種名車種ID Rite 延長料金単価貸出予約乗車可能人数||車両ナンバ| sues—ic mite, eB ID Seite #41)SD貸出実績コード|注記属性名の実線の下線__は プランD 4HID貸出予約コードギキー,破線の下線-----は外 氏名予約時刻車両ID部キーを示す。 性別キャンセル時刻貸出実績時刻主キーの実線が付いている属性 生年月日貸出予定時刻返却実績時刻名には,外部キーの破線を付け 住所返却予定時刻貸出実績時間ない。 電話番号貸出予定時間延長料金合計 従量料金合計 図1貸出管理システムのデータモデル(抜粋) 利用希望者はあらかじめP社の会員になり,いずれかのプランに加入しておく必 要がある。プランごとに基本料金(月額)従量料金及び延長料金(いずれも10分単 位)の単価が決まっている。会員が車両を借りたいときは,P社のホームページで借 りたい日時や駐車場,車種などを選択し,貸出を予約する。貸出や返却の実績時刻が 予約時の内容と異なる場合であっても,貸出予約の情報は修正しない。従量料金合計 は予約時に指定された貸出予定時間を基に算出する。予約時に指定した返却予定時刻 より早い時刻に返却しても,従量料金合計は減算しない。予約時に指定した返却予定 時刻より遅い時刻に返却した場合は遅延返却として扱う。遅延返却は後の時間帯に予 約している別の会員の迷惑となるので,超過した時間については従量料金よりも高い 延長料金によって延長料金合計を算出する。これによって,遅延返却の発生件数(以 下,遅延返却発生件数という)の低減を図っている。毎月末に当月の基本料金,従量 料金合計及び延長料金合計を合算して,翌月に会員に請求する。 貸出管理システムのデータベースでは,データモデルのエンティティ名を表名にし, 属性名を列名にして,適切なデータ型で表定義した関係データベースによって,デー タを管理している。時刻はTIMESTAMP型,年月日はDATE型で定義されている。 また,P社ではKPIの一つとして車両稼働率を重視している。車両稼働率とは,各 車両における1日当たりの貸出実績時間の割合である。平均車両稼働率の目標データ lk,表計算ソフトのデータとして,年月日別・駐車場別・車種別に過去3 LEMOS 積されており,それ以前のデータは破棄されている。 〔業務要件の把握〕 P社の経営企画部では,車両の追加整備計画の立案を検討している。Rさんは経営 企画部にヒアリングを行い,経営分析システムの業務要件を把握した。業務要件の抜 粋を図2に示す。 Qさんは,データソースの調査結果を踏まえて,図2の業務要件の実現可能性を評 価した。CORR,①業務要件の一部は経営分析システムの運用開始直後には実現で きないことが判明した。対応方針を経営企画部と協議した結果,業務要件は変更せず 運用開始直後の分析は,実現可能な範囲で行うことで合意した。 ー29一 ・地区別の人気車種,会員の性別・年代別の人気車種,駐車場別・車種別の平均車両稼働率, 駐車場別・会員別の遅延返却発生件数を分析できること。なお,貸出実績の件数(以下,貸 出実績件数という)が多い場合を人気車種であるとみなす。 ・表計算ソフトのデータを用いて,平均車両稼働率の目標比や前年同期比を分析できること。 ・これらのいずれにおいても,年別,AB,ABI,AR,曜日別といった時間軸で傾向を分析 できること。 ・過去5年間について,分析対象期間を柔軟に変更して,期間による傾向の違いを分析できる re. ・毎週月曜日の朝に最新のデータを確認できること。ただし,遅延返却発生件数については前 日までの実績を翌営業日の朝に確認できること。 ・貸出実績件数及び遅延返却発生件数は貸出予定の日付で集計すること。 図2経営分析システムの業務要件(抜粋) [経営分析システムのデータモデル設計] RIL,Qさんは図2の業務要件を基に,経営分析システムのデータモデルを多次元 データベースとして設計した。多次元データベースの実装には,データモデルのエン ティティ名を表名にし,属性名を列名にして,適切なかデータ型で表定義した関係デー タベースを用いることにした。列指向データベースは用いず,データを行単位で扱う 行指向データベースを用いることにした。問合せの処理性能を考慮して,データモデ ルの構造には| 』|構造を採用した。経営分析システムのデータモデルの抜粋 を図3に示す。 経営分析システムには,最長で過去5年間分のデータを蓄積することにした。 年月日の週と曜日は,事前に定義したSQLのユーザ定義関数を用いて取得できる。 年年月日 月駐車場TD A車種D 週会員ID 中 gg bol we氏名 C2][2]2an S05 1D ee上朋2= 車種D駐車場ID 平均車両稼働率駐車場名 平均車両稼働率(目標)地区 M3経営分析システムのデータモデル(抜粋) 〔データ加工処理の開発 貸出管理システムのデータベースから経営分析システムのデータベースへのデータ 連携時に,一部のデータを加工する必要がある。Qさんは,データ加工処理用のデー タベースを用意し,データ加工を行うバッチ処理プログラムを開発した。図4の SQL文は,そこで用いられている図3の貸出表の遅延返却発生件数データを作成す るためのものである。ここで,TIMESTAMP TO DATE関数は,指定された TIMESTAMP型の時刻をDATE型の年月日に変換するユーザ定義関数である。 バッチ処理プログラムでは,図4のSQL文で作成したデータを貸出表に挿入する 際,遅延返却発生件数が0件のレコードに対する処理も別途行うようになっている。 に TIMESTAMP_TO_DATE(Y.貸出予定時刻)AS貸出予定年月日,Y.返却予定時刻FROM貸出予約Y)R WHERE R.返却予定時刻くJ.返却実績時刻 FROM(SELECT Y.貸出予約コード,Y.駐車場ID,Y.車種ID,Y.会員ID, 貸出予約コード 図4遅延返却発生件数データを作成するSQL文 〔分析のレスポンス性能の改善〕 性能検証を実施したところ,分析対象期間を過去複数年間,時間軸を月別として人 気車種及び遅延返却発生件数を分析する場合,種々の分析に時間が掛かり過ぎるので 改善してほしいという要望が経営企画部から挙がった。経営分析システムのデータベ ースのインデックスは上既に適切に作成している。分析のレスポンス性能を改善するた めに,Qさんは②データマートとして集計表を追加した。

共通の文章

ディジタル補聴器の設計に関する次の記述を読んで,設問1ー3に答えよ。 H社は,ディジタル補聴器を開発している会社である。開発するディジタル補聴 器(以下,新補聴器という)は,ソフトウェアでの信号処理によって,入力された 音を八つの周波数帯(以下、それぞれを帯域という)に分割し,帯域ごとの音量設 定ができる。さらに,入力された音の大きさに応じて自動的に音量の調節を行う自 動音量調節(以下,AVCという)の機能がある。想定される利用者は,特定の帯域 の音が聞き取りにくい人などである。入力された音の帯域への分割を図1に示す。 そーーー低い周波数高い一一テ M1入力された音の帯域への分割 利用者は,スマートフォンのアプリケーションプログラム(以下,スマホアプリ という)を使用して,帯域ごとの音量設定に必要な各種パラメタ(音量パラメタな ど)を変更する。 [ハードウェア構成〕 新補聴器のハードウェア構成を図2に示す。 DAC:D/AコンバータBluetooth サンプリング高速クロックサンプリング 図2新補聴器のハードウェア構成 ・BTモジュールは,Bluetoothを介してスマホアプリと通信する。 ・ADCは,マイクから入力されたアナログ信号を,1秒間に24,000回サンプリング し,16ビットの符号付き整数のデータに変換して入力バッファに書き込む。64サ ンプルのデータを1フレームとして書き込み,書込みが完了したことを制御部に 通知する。この通知を受信完了通知という。 ・制御部は,受信完了通知を受けると1フレーム分のデータを処理して出力バッフ ァに書き込む。演算は全て整数演算であり,浮動小数点演算は使用しない。 ・DACは,出カバッファに書き込まれた16ビットの符号付き整数のデータをアナロ グ信号に変換する。 ・低速クロック部は,ADC及びDACに24 kHzのサンプリングクロックを供給する。 ・高速クロック部は,制御部に高速クロックを供給する。高速クロックの周波数はf 又はその整数倍で,ソフトウェアによって決定することができる。 [入力バッファ及び出力バッファ]〕 入力バッファ及び出力バッファは,それぞれ三つのブロックで構成されている。 ーつのブロックには1フレーム分のデータを格納できる。入力バッファ及び出力バ ッファのサイズはともに| 』|バイトでぁる。 ADC及びDACは,入力バッファ及び出力バッファの同じブロック番号のブロック にアクセスする。制御部は,ADCによるデータの書込みが完了したブロックにアク セスする。ADC,DAC及び制御部は,ブロック3にアクセスした後,ブロック1の アクセスに戻る。 バッファの使用例を図3に示す。(1)ADC及びDACがブロック1にアクセスして いるとき,制御部はブロック3にアクセスする。次に,(2)ADC及びDACがブロッ ク2にアクセスしているとき,制御部はブロック1にアクセスする。 入力バッファ出力バッファ入力バッファ出力バッファ ADC DAC Q)ADC及びDACがブロック1にアクセスするとき(⑫②)ADC及びDACがブロック2にアクセスするとき 図3バッファの使用例 マイクからのアナログ信号がADCで処理されてから,イヤホンから出力されるま での時間は|b|ミリ秒になる。 ー35— [新補聴器のソフトウェア] 制御部のソフトウェアの主な処理内容は,①信号処理,OAK,QAVC CHS, 制御部が受信完了通知を受けると,次に示すように処理を行う。 ①サンプリングしたデータから一つの帯域を抽出し,帯域に割り当てられた音量 パラメタを乗じる。これを八つの帯域に対して行う。 ②①で得られたそれぞれの帯域のディジタル信号を合成して一つのディジタル信 号にする。 ③合成されたディジタル信号について,AVCで音量を調節して,出力バッファに 書き込む。 新補聴器の消費電力をできるだけ抑えたい。新補聴器では,消費電力は供給され る高速クロックの周波数に比例し,ソフトウェアの実行時間(以下,実行時間とい う)は高速クロックの周波数に反比例することが分かっている。 最適なクロック周波数を決定するために,高速クロックの周波数を用いて,O~ ③の実行時間を計測した。 1フレーム分のデータを処理するとき,①の一つの帯域の最大実行時間をTi,QO BALA Ts,③の最大実行時間をTaとしたとき,1フレーム分のデータを処 理する最大実行時間Tdは,8x+|qa|+[。|で表すこと ができる。 受信完了通知から次の受信完了通知までの時間をTframeとし,高速クロックとし て周波数を供給したときの各処理の実行時間を表1に示す。①て③の全ての処理が Tframe内に完了し,かつ,消費電力が最も抑えられる周波数について,表1を基に 決定する。 表1高速クロックとして周波数f。を供給したときの各処理の実行時間 Pade ー36一 (AVC処理〕 〔新補聴御のソフトウェア〕の③の処理は,1フレームごとに実行し,適切な音声 を出力するように音量を調節する。合成されたディジタル信号の大きさを確認して 所定の大きさよりも大きいときは音量を小さくし,所定の大きさよりも小さいとき は音量を大きくする。 音量を変更するときは1フレームごとに音量を変化させ,M又はM41フレーム 間で徐々に目標の音量にする。Mは2以上の値でシステムの定数である。目標の音 量に到達したら,その次のフレームの合成された信号について目標の音量を決定し, 同様の音量調節を行う。 (AVC処理のソフトウェア] AVCの処理フローで使用する変数,関数,定数を表2に,AVCの処理フローを図 4に示す。特定の条件では,目標の音量を決定したとき,直ちに音量を目標の音量に する。そのための判定を網掛けした判定部で行っている。演算は全て整数演算であ る。 表2 AVCの処理フローで使用する変数,関数,定数 は||awなティッタ2人9のXきS= ー37一 ーーー ヌは|アァ| 図4 AVCの処理フロー

共通の文章

クーポン券発行システムの設計に関する次の記述を読んで,設問1こ3に答えよ。 X社は,全国に約400店のファミリーレストランを展開している。X社の会員向け Webサイトでは,割引料金で商品を注文できるクーポン券を発行しており,会員数 は1,000万人を超える。このたび,会員の利便性の向上や店舗での注文受付業務の効 率向上のために,会員のスマートフォン宛てにクーポン券を発行することになった。 スマートフォン宛てにクーポン券を発行する新しいシステム(以下,新システムと いう)は,スマートフォン向けアプリケーションソフトウェア(以下,スマホアプリ という)とサーバ側のWebアプリケーションソフトウェア(以下,Webアプリとい う)から構成され,Webアプリの開発は情報システム部門のY君が担当することに Ips [新システムの利用イメージ] X社の会員は,事前に自分のスマートフォンにX社のスマホアプリをダウンロー ドし,インストールしておく。会員がクーポン券を利用する際は,スマホアプリに会 員IDとパスワードを入力してログインする。ログインが完了すると,おすすめ商品 と利用可能なクーポン券の一覧が表示される。会員が利用したいクーポン券を選択す ると,QRコードを含むクーポン券画面が表示される。X社店舗の注文スタッフが QRコードを注文受付端末で読み取ると,割引料金での注文ができる。 (Webアプリの処理方式の調査〕 Y君がWebアプリの実現方式を検討したところ,X社のWebサイトで利用してい るブロッキングYO型のWebサーバソフトウェア(以下,サーバソフトという)で は,スマホアプリからの同時アクセス数が増えると対応できないことが分かった。 ブロッキングYO型のサーバソフトでは,ネットワークアクセスやファイルアクセ スなどの10処理を行う場合,CPUは低速なVO処理の完了を待って次の処理を実行1 する。例えば,表1に示す,QRコードを作成するために必要なWebアプリの処理 (AE,QRコード作成処理という)の場合,全体の処理時間の|』|%がLO 処理の完了待ち時間となる。 fi== 表1 QRコード作成処理 処理開処理時間 |3|クーポン番号からQRコードの画像データをメモリに作成|処理2の完了|oo6|cru mm |6|スマホアブリにQRコードの画像ファイルを返信|処理4の完了|5|VOM このため,ブロッキングLO型のサーバソフトでは,複数のスマホアプリにサービ スを提供するために,プロセスやスレッドを複数生成している。しかし,プロセス やスレッドの数が増えると,プロセスやスレッドの切替え処理である|bp|ス イッチがボトルネックとなり,CPUやメモリを追加してもスマホアプリからの同時 アクセスへの対応は困難となる。 そこでY Blk,多数のスマホアプリからのアクセスを効率よく処理できるノンブ ロッキングVO型のサーバソフトの利用を検討した。ノンブロッキングYO型のサー バソフトでは,一つのプロセスやスレッドの中で,CPUはVO処理の完了を待たず に,実行可能なほかの処理を実行する。その結果,Webサーバは複数のプロセスや スレッドを生成する必要がなく,スマホアプリへも効率的にサービスを提供できる。 [リアクタパターンの調査 ノンブロッキング1O型のサーバソフトで,Webアプリを動作させるためには,JE 同期処理の考え方に基づいたソフトウェア設計が必要である。そこで,Y Blk,ノン ブロッキングYO型の処理を実現するデザインパターンの一つであるリアクタパター ンについて調査した。1にY君が調査したリアクタパターンの処理の流れを示す。 |es Sone[fae(7)IO処理の完了 Tay tay Rony Raia L(x)イベント待ち! |(7)ハンドラの登録|ー*ies !(イ)ハンドラを取得 1 Y君が調査したリアクタパターンの処理の流れ VO処理の処理結果を利用する処理をハンドラとして定義する。次に,VO処理の 完了待ちを依頼したいメイン処理が,DVO処理完了後に実行するハンドラ名を引数 に“(ア)ハンドラの登録”"を行うと,リアクタは“(イ)ハンドラを取得"する。次 に,メイン処理がリアクタに“(ウ)イベントのハンドル依頼"を行うと,リアクタ はデマルチプレクサに『(エ)イベント待ち"を指示する。デマルチプレクサは複数 のVO処理の完了を一括して監視し,“(オ)VO処理の完了”を検知した場合には, 対応する“(カ)イベント"”をリアクタに発行する。イベントを受け取ったリアクタ は『“(キ)ハンドラを実行"する。メイン処理は,イベントのハンドル依頼を行つた lk,VO処理の完了を待たずにほかの処理を実行できる。 リアクタパターンを適用する場合は,遅いVO処理の次に実行される処理をハンド ラとして分割するのがよい。しかし,リアクタパターンに基づき設計されたプログラ ムは,⑨保守性が下がるおそれがある。 (QRコード作成処理の設計〕 Y Blt,リアクタパターンを用いて,スマホアプリからのアクセスに対する応答時 間が最小になるように,QRコード作成処理を設計した。図2にY君が設計したQR コード作成処理の流れを示す。 ー42一 (ウ)イベントのハンドル依頼| mele)!!| |!(キ)ハンドラを実行! | |mal)(キ)ハンドラを実生 ||wale 1(*)AY RD Be ea te ||| 注記1図1中の(7),(4)OMIM X ye IR|| 注記2図1中の(エ)~(カ)の非同期メッセージは省略 注記3図1中の応答メッセージは省略 図2 Y君が設計したQRコード作成処理の流れ その後Y Blk,新システムのWebアプリの開発を完了させ,X社の会員はスマー トフォンを通じてクーポン券を利用することが可能となった。

共通の文章

プロジェクトのコスト見積りに関する次の記述を読んで,設問1ー4に答えよ。 L社は大手機械メーカQ社のシステム子会社であり,Q社の様々なシステムの開 発,運用及び保守を行っている。このたび,Q社は,新工場の設立に伴い,新工場用 の生産管理システムを新規開発することを決定した。この生産管理システム開発プロ ジェクト(以下,本プロジェクトという)では,業務要件定義と受入れをQ社が担 当し,システム設計から導入までと受入れの支援をL社が担当することになった。L 社とQ thlt,システム設計と受入れの支援を準委任契約,システム設計完了から導 入まで(以下,実装工程という)を請負契約とした。 本プロジェクトのプロジェクトマネージャには,L社システム開発部のM課長が 任命された。本プロジェクトは現在Q社での業務要件定義が完了し,これからL社 でシステム設計に着手するところである。L社側実装工程のコスト見積りは,同部の N君が担当することになった。 なお,L社はQ社の情報システム部が,最近になって子会社として独立した会社 であり,本プロジェクトの直前に実施した別の新工場用の生産管理システム開発プロ ジェクト(以下,前回プロジェクトという)AS,L社独立後にQ社から最初に受注 したプロジェクトであった。本プロジェクトのTL社とQ社の担当範囲や契約形態は 前回プロジェクトと同じである。 〔前回プロジェクトの問題とその対応] 前回プロジェクトの実装工程では,見積り時のスコープは工程完了まで変更がなか ったのに,L社のコスト実績がコスト見積りを大きく超過した。しかし,①L社は超 過コストをQ社に要求することはできなかった。本プロジェクトでも請負契約とな るので,M課長はまず,前回プロジェクトで超過コストが発生した問題点を次のと おり洗い出した。 ・コスト見積りの機能の範囲について,Q社が範囲に含まれると認識していた機能が, L社は範囲に含まれないと誤解していた。 ・予算確保のためにできるだけ早く実装工程に対するコスト見積りを提出してほしい というQ社の要求に応えるため,L社はシステム設計の途中でWBSを一旦作成し ー46一 これに基づいてボトムアップ見積りの手法(以下,積上げ法という)によって実施 したコスト見積りを,ほかの手法で見積りを実施する時間がなかったので,そのま ま提出した。その後,完成したシステム設計書を請負契約の要求事項として使用し たが,コスト見積りの見直しをせず,提出済みのコスト見積りが契約に採用された。 ・コスト見積りに含まれていた機能の一部に,L社がコスト見積り提出時点では作業 を詳細に分解し切れず,コスト見積りが過少となった作業があった。 ・詳細に分解されていたにもかかわらず,想定外の不具合発生のリスクが顕在化し, 見積りの基準としていた標準的な不具合発生のリスクへの対応を超えるコストが持 かった作業があった。 次に,今後これらの問題点による超過コストが発生しないようにするため,M課 長は本プロジェクトのコスト見積りに際して,N君に次の点を指示した。 Lia|を作成し,L社とQ社で見積りの機能や作業の範囲に認識の相違がな いようにすること。その後も変更があればメンテナンスして,Q社と合意すること ・実装工程に対するコスト見積りは,Q社の予算確保のためのコスト見積りと,契約 に採用するためのコスト見積りの2回提出すること G@)1回目のコスト見積りは,システム設計の初期の段階で本プロジェクトに類 似したシステム開発の複数のプロジェクトを基に類推法によって実施して,概算 値ではあるが,できるだけ早く提出すること Gi)2回目のコスト見積りは,システム設計の完了後に②積上げ法に加えてファン クションポイントGE,FPという)法でも実施すること ・積上げ法については,次の点について考慮すること ⑪作業を十分詳細に分解してWBSを完成すること Gi)標準的なリスクへの対応に基づく通常のケースだけでなく,特定したリスク がいずれも顕在化しない最良のケースと,特定したリスクが全て顕在化する最悪 のケースも想定してコスト見積りを作成すること 1回目のコスト見積り〕 これらの指示を基に,N君はまず,Q社の業務要件定義の結果を基に|a| を作成し,Q社とその内容を確認した。 ー47一 次に,1回目のコスト見積りを類推法で実施し,その結果をM課長に報告した。 その際,L社が独立する前も含めて実施した複数のプロジェクトのコスト見積りとコ スト実績を比較対象にして,概算値を見積もったと説明した。 しかし,M課長は,"⑨自分がコスト見積りに対して指示した事項を,適切に実施 したという説明がない”とN君に指摘した。 N君は,M課長の指摘に対して漏れていた説明を追加して,1回目のコスト見積り についてL社内の承認を得た。M課長は,この1回目のコスト見積りをQ社に提出 Wize [2回目のコスト見積り] N君は。システム設計の完了後に,積上げ法とFP法で2回目のコスト見積りを実 施した。 (1)積上げ法によるコスト見積り N君は,まず作業を,工数が漏れなく見積もれるWBSの最下位のレベルである |b|まで分解してWBSを完成させた後,工数を見積もり,これに単価を 乗じてコストを算出した。 次に,この見積もったコストを最頻値とし,これに加えて,最良のケースを想定 して見積もった楽観値と,最悪のケースを想定して見積もった悲観値を算出した。 楽観値と悲観値の重み付けをそれぞれ1 LL,最頻値の重み付けを4としてコス トに乗じ,これらを合計した値を6で割って期待値を算出することとした。例え ば,最頻値が100 FAC,楽観値は最頻値一10%,悲観値は最頻値寺100%となっ た作業のコストの期待値は|c FAL RS. |b|のコストの期待値を合計して,本プロジェクトの積上げ法によるコ スト見積りを作成した。 (2)FP法によるコスト見積り N君は,FP法によってFPを算出して開発|q|を見積もり,これを十数1 に換算し単価を乗じて,コスト見積りを作成した。表1ユー3は,本プロジェクトに おけるある1機能でのFPの算出例である。表1,表2を基に,表3でFPを算出 Like ー4g一 表1データファンクションの一覧表 データ、レコード|データ|複雑さの IDL|BE:外部インタフェースファイル ILF:BRIBED 7 1 os AEF=—RIT I|af引mu ILF:内部論理ファイル ILP:内理ファイルし叶sa wl 表2トランザクションファンクションの一覧表 トランザクションここ、関連データ複雑さの EQ:外部人 EL PBA EO:外部員カ|中反 TCs A 6も|絢mm| 表3 FPの算出表 eer複雑さの評価 イブaa ar]a|SC]a|Calで|sxe]Sd a EZ)7還証明 Ea ey a eee eee a 7 OT)od Es ed ee 0 総合計(FP) 注記表中の部分は,一部を除いて省略されている。 N Bld,M課長に積上げ法とFP法によるコスト見積りの差異は許容範囲であるこ とを説明し,積上げ法のコスト見積りを2回目のコスト見積りとして採用すること について,L社内の承認を得た。M課長は,承認された2回目のコスト見積りをQ 社に説明し,Q社の合意を得た。その際Q社に,業務要件の仕様変更のりリスクを加 WL,L社のコスト見積りの総額にを追加して予算を確定するよう提案 oh

共通の文章

間19 SaaSを使った営業支援サービスに関する次の記述を読んで,設問1ー4に答えよ。 A社は,オフィス機器の販売・設計・施工会社であり,自社で企画・設計したオフ ィス機器の販売や設計・施工をA社の顧客に実施している。A社営業部の営業部員 は一日の大半を得意先との面会や移動に費やした後に,事務処理のために帰社する必 要があって残業時間が増加していた。そこで,A社では,働き方改革の一環として, 営業部員が営業拠点のPCだけではなく,自宅や外出先からスマートフォンやタプブレ ットなどの端末からも仕事ができる環境を整えることになった。 このような背景から,A社システム部は,営業部員に対して自宅や外出先からも利 用できる営業支援サービスを新規に提供することになった。これに合わせて,システ ム部のB部長は,システム部内にサービスデスクを設置することを決定し,サービ スデスクのリーダとしてC課長を任命した。 [営業支援サービスの概要〕 (1)4月1日から営業支援サービスを開始する。 (2)営業支援サービスは①D社が提供しているSaaSであるEサービスを採用し,一 部の機能をアドオン開発して,提供する。 (3)営業支援サービスは,顧客管理,営業管理及び販売促進の三つのモジュールで 構成され,利用者は端末を使って営業支援サービスを利用する。 ・顧客管理モジュール及び営業管理モジュールは,Eサービスで提供される機能及 び画面をそのまま使用する。 ・販売促進モジュールは,Eサービスで提供される標準の機能及び画面に,A社固 有の機能及び画面をアドオン開発する。システム部の開発課はD社が公開して いるAPIを利用してアドオン開発し,開発したソフトウェアを保守する。 (4)D社からA社向けに,開発・テスト環境及び稼働環境が提供される。 ・開発・テスト環境は,開発課がアドオン開発及びテストで利用する環境である。 D社によって,Eサービスの標準の機能及び画面のモジュールが展開される。 ・稼働環境は,A社の利用者に営業支援サービスを提供する環境であり,開発課に よって三つのモジュールが展開される。 (5)Eサービスは,D社によって,定期的にアップグレードされる。Eサービスのア ー52一 ップグレード及び営業支援サービスへの適用に関する概要は次のとおりである。 ・Eサービスのアップグレードは,四半期に一回,事前に決められたスケジュール に従って実施される。 ・アップグレード予定日の4週間前に,D社からアップグレードされる機能及び画 面や変更点を記載したリリースノートが発行される。 ・Eサービスで提供される標準の機能及び画面については,D社によってリグレッ ションテストが実施される。テスト完了後に,Eサービスの標準の機能及び画面 のモジュールが開発・テスト環境に対して展開される。 ・開発課は,アップグレードの適用に関して,サービスデスクと協議し,社内調整 と必要な作業を行った後,稼働環境に営業支援サービスの三つのモジュールを展 開する。 (6)Eサービス及びD社サービスデスクサービスに関するA社システム部とD社と のSLAの概要(抜粋)を表1に示す。 Rl A社システム部とD社とのSLAの概要(抜粋) >24時間365日(毎週日曜日0.00て5:00に実施 ターズ提人時間基保守"を除く) ;、99.5%以上(1か月の停止時間の合計が 本FARR(a)分以内を目標値する。) 平均サービス回復時、 間(MTRS)2 AeA D社サービスデスBan サービス提供時間帯9:00て17:00(KA,祝日を除く) S$定期保守の中で,四半期に一回のアップグレードが実施される。 S$?D社サービスデスクでは,Eサービスの問合せとインシデント対応,及び公開している APIに関する技術的問題を解決する。A社のアドオン開発分の問合せへの対応は含まない。 (A社サービスデスクサービスの概要〕 (1)4月1日からA社サービスデスクサービスの運用を開始する。 (2)A社サービスデスクサービスは,営業支援サービスの利用者を支援するサービ スデスク機能を提供する。サービスデスクの業務は,従来複数の組織で実施してい た営業部員支援の業務を統合し,|b|としてシステム部に置いた。 (3)A社サービスデスクは利用者からの電話,Web,電子メールでの質問に回答する だけでなく,営業支援サービスのインシデント対応も行う。 C課長は,サービスの設計を開始し,営業部とシステム部とのSLAの概要(抜粋) を表2に,サービスデスクで実施するインシデント管理の手順を表3にまとめた。 表2営業部とシステム部とのSLAの概要(抜粋) aml ag eu ae 24時間365日(毎週日曜日0.00て12:00に実施 営業支援サービス|サービス提供時間する定期保守?FIRS) A社サービスデス y—wagapenemmee|o:00~17:00(休日祝日を除く) ーーHe p==4“NN~17- 注!定期保守の中で,四半期に一回のアップグレード,RO,A社のアドオン開発分の保守が 表3インシデント管理の手順 記録・分類・利用者からインシデントを受け付ける。 ・インシデントを,緊急度,影響を受ける利用者の範囲などで分類し, インシデント管理ファイルリ"に記録する。 優先度付け・インシデントに優先度として“RB”,“中”,“UR”のいずれかを付け る。優先度は,規定されている基準に基づいて付ける。 エスカレーション|・サービスデスクが対応手順書?を使って解決できないインシデント ik,⑨②開発課又はD社サービスデスクのどちらかをエスカレーショ ン先として決定し,エスカレーション先に調査を依頼する。 解決・対応手順書2又はエスカレーション先からの調査の回答を基に,解決 に向けた対処を行う。 ・利用者が対処すべき作業がある場合は,利用者に作業を依頼する。 終了・インシデントが解決したことを利用者に確認する。 ・回答内容などの記録を更新し,終了する。 注記インシデントの記録は,対応した処置とともに随時更新する。 注りインシデント管理ファイルにはインシデントだけでなく質問とその回答内容も記録される。 $2対応手順書は,インシデントに対応するために実施すべき解決処理の詳細が記載されてい る手順書のことで,サービスデスクが作成し整備する。対応手順書には,インシデントが及 ぼすサービスへの影響を低減又は除去する方法を特定した場合の対応手順も記載されている。 [サービスの開始〕 システム部は予定どおり,4月1日から,営業支援サービスとA社サービスデスク サービスの提供を開始した。 ・7月になって,A社サービスデスクでは,インシデント管理ファイルの記録を基に, 高い頻度で発生した質問及びインシデントの中で,利用者が自分で解決できる内容 をまとめた| c|を社内Webに公開した。 ‘Lc|を公開後しばらくして,利用者から,“必要な回答を探すのに時間が掛 DS",“対話的な質問ができないので活用しにくい”という声が上げられ,この結 果,|c|の利用率が低いという課題が明らかになった。 C課長は,利用者からの声に対処するために,10月1日からチャットボットを利 用することにした。チャットボットは,新たにD社が提供を開始するEサービスの モジュールであり,4社は必要なデータを整備することでチャットボットを利用でき る。システム部は,チャットボットを営業支援サービスの四つ目のモジュールとして 位置づけた。利用者が質問のキーワードを入力すると,想定される質問とその回答を 返す。利用者が期待する回答が得られない場合には,キーワードを追加させるなど対 話的な対店をする。チャットボットによって,利用者は,| q|以外でも質問 に回答してもらうことができる。なお,チャットボットを使っても期待する回答が得 られない質問に対しては,サービスデスクが電子メールで対応する。 Eサービスのアップグレード対応〕 CRE,Eサービスがアップグレードされる場合に必要となるシステム部の作業 を計画した。 ERIS,アップグレードされを機能及び画面について記載された|ce|の 中から,A社の業務に関連した機能及び画面を抽出し,彫響するモジュールを特定 する。 IRIS,アップグレードがアドオン開発した機能に影響を及ぼさないかどうかを 調査し,評価する。 ・サービスデスクは,|ec|]に基づいて開発課と協議し,|f|を判断す る。判断の結果に応じて,サービスデスクは,必要な作業を行う。 ・サービスデスクは,営業支援サービスについて利用者に案内すべき内容をまとめ, アップグレードの適用に先立って利用者に通知する。 —Ber=