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

共通の文章

問2食品会社でのマーケティングに関する次の記述を読んで,設問1ー3に答えよ。 Q社は,スナック菓子の製造・販売会社である。Q社は,老舗のスナック菓子メー カとして知名度があり,長年にわたるファンはいるが,ここ5年間の売上は減少傾 向であり,売上拡大が急務である。Q社の社長は,この状況に危機感を抱き,戦略の 策定から実施までを行う戦略マーケティングプロジェクトを立ち上げ,営業企画部の R課長を戦略マーケティングプロジェクトの貢任者に任命した。R課長は,商品開発 担当者,営業担当者から成るプロジェクトチームを編成し,現状分析とマーケティン グ戦略の策定に着手した。 [現状分析] R課長は,次のような3C分析を実施した。 (1)顧客・市場 ・少子高齢化による人口減少で,菓子の筑要は低下傾向である。 ・従来,主要な顧客は中高生を中心とした子供だったが,大人のスナック菓子の需 要が最近増加しており,今後も成長余地がある。 ・オフィスでおやつとして食べたり,持ち歩いて小腹のすいたときに適宜食べたり するなど,スナック菓子に対する顧客ニーズが多様化している。 ・顧客の健康志向が高まっており,自然の素材を生かすことが求められている。 (2)競合 ・競合他社からQ社の主力商品の素材と似た自然の素材を使った,味もパッケー ジも同じような新商品が発売され,売上を伸ばしている。 ・海外大手メーカから,海外で人気のスナック菓子が発売される予定である。 (3)自社 ・日本全国に販売網をもつ。 ・海外でもパートナーシップを通じて販路を拡大している。 ・食品の素材に対する専門性が高く,自然の素材を生かした加工技術をもつ。 ・新たな利用シーンに対応する商品開発力をもつ。 ・商品の種類の多さや見た目のかわいさなどが中高生から支持されており,熱烈な ーg一 ファンが多い。 [マーケティング戦略の策定] R課長は,〔現状分析〕の結果を基に,戦略マーケティングプロジェクトのメンバ と協議し,新商品のターゲティングとポジショニングについて,次のように定めた。 Q)Q社の主要な既存顧客に加えて,新たな顧客のターゲット|a|として, 普段あまりスナック菓子を食べていない,健康志向の20て40代の女性を設定する。 ②このターゲット|a|に対して,“素材にこだわるという付加価値"を維 持しつつ,O“今までとは違う時間や場所で食べることができる機能性"というポ ジショニングを定める。 これらを踏まえて,R課長は今後のマーケティング戦略を,次のように定めた。 1)希少価値によって話題を集めることで,顧客の購買意欲を高める。 ②)従来の実店舗や広告に加えて,インターネットを活用したデジタルマーケティ ングの採用によって,顧客との接点を増やす。 [商品開発 R課長は,マーケティング戦略に基づき,新商品のコード名を新商品Eとして開 発することとし,健康志向の20て40代の女性を対象に,次の(1)アンケート調査と(2 商品コンセプトの検討を実施した。今後,(3)~(5)を実施予定である。 Q)アンケート調査 ・“大袋やカップは持ち運びにくい",“今のスナック菓子の量は多すぎる”などの 不満があめることが分かった。 ・“健康のためにカロリーを少な目にしてほしい"などのニーズが強いことが分か Die, (2)商品コンセプトの検討 ・商品コンセプトとして,“素材にこだわった健康志向で,蓋を閉めて持ち運びが できる小さな1人用サイズ"を定めた。 ・顧客には“繰り返し密閉でき携行しやすい"というメリットがある。 (3③試作品の開発 =hy ee ・商品コンセプトにあわせて複数の味,素材,パッケージなどの試作品をつくる。 (4)テストマーケティング ・ネット通販限定で,試作品を用いてテストマーケティングを実施する。ただし, 他社にアイディアやネーミングを模令されるリスクがあるので,テストマーケテ ィングを実施する前にそのリスクに対処するための⑨施策を講じる。 (5)新商品の市場導入 ・テストマーケティング後に,新商品Eを顧客向けに販売する。 ・③発売当初は,期間限定で出荷数量を絞った集中的なキャンペーンを実施する。 [プロモーショヨン] R課長は,インターネットを活用したデジタルマーケティングを展開し,商品が売 れる仕組みをデジタル技術を活用して作ることにした。消費者行動プロセスに沿った プロモーションを,次のように設計した。 (1)認知(Aware) ・インタビューへの応対などを通じて雑誌のデジタル版などのメディアに自社に関 する内容を取り上げてもらう| b|や,広告などの施策によって顧客のプ ランドへの認知度が高まる。 (2)訴求(Appeal) ・Q社の運営するSNSの強化に加えて,商品紹介の専用Webページを新設するこ とで,顧客はQ社の商品に,より関心をもつようになる。 (3)調査(Ask) ・Q社が,オウンドメディア(自社で所有,運営しているメディア)を充実するこ とで,顧客が,SNSや商品紹介のWebページ上でQ社の商品のレビューに触れ る機会が増える。 (4)行動(Act) ・Q社が,メールマガジンやデジタル広告などの施策を実施して顧客との接点を増 やすことで,顧客の商品購入が促進される。 (5)推奨(Adqvocate) ‘MEI,プランドに対するが高まり,他者へプランドを推奨する。 meet,[a|が拳げられる。 ーify es R課長は,プロジェクトチームでSNSを担当するS主任に対して,“この消費者行 動プロセスに沿ったプロモーションの施策に基づき,Q社の運営するSNS上で新商 品Eの情報を公開してほしい。ただし,当社の評判を落とすことにつながる対応は 避けるように十分に気を付けてほしい。”と指示をした。 Q社の運営するSNS上では顧客が直接書き込みできる。新商品Eの情報公開から しばらくして,Q社がSNSに投稿した内容に対して,ある顧客から“差別的な表現 が含まれている"というクレームがあった。これに対して,S主任は投稿の意図や意 味を丁寧に説明した。 その後,その顧客から再度クレームがあり,S主任はR課長にこれを報告した。R 課長は“今後の対応を決める前に,④SNS特有の事態と,新商品Eの展開を阻害す るおそれのあるリスクを慎重に検討するように"とS主任に指示をした。

共通の文章

一筆書きに関する次の記述を読んで,設問1ー4に答えよ。 グラフは,有限個の点の集合と,その中の2点を結ぶ辺の集合から成る数理モデル である。グラフの点と点の間をつなぐ辺の列のことを経路という。本問では,任意の 2点間で,辺をたどることで互いに行き来することができる経路が存在する(以下, 強連結という)有向グラフを扱う。強連結な有向グラフの例を図1に示す。辺は始点 と終点の組で定義する。各辺には1から始まる番号が付けられている。 (a)!(b)。辺1=(上Na。点b)辺2=(点b,点の 4 2辺5三(点b,点e)辺6ニ(点e,点d) 用〆ao-(Ne Ho)UAC se) (f)辺7=(点d,点f)辺8=(点5 sb) 凡例辺三(辺の始点,辺の終点) 図1強連結な有向グラフの例 〔一筆書き〕 AMICI,グラフの全ての辺を1回だけ通り,出発点から出て出発点に戻る閉じた 経路をもつグラフを,一筆書きができるグラフとする。 〔一筆書きの経路の求め方] 一筆書きの経路を求めるためには,出発点から辺の向きに従って辺を順番にたどり, 出発点に戻る経路を見つける探索を行う。たどった経路(以下,探索済の経路とい う)について,グラフ全体で通過していない辺(以下,未探索の辺という)がない場 合は,この経路が一筆書きの経路となる。未探索の辺が残っている場合は,探索済の 経路を,未探索の辺が接続する点まで遡り,その点を出発点として,同じ点に戻る経 路を見つけて,遡る前までの経路に連結することを繰り返す。 各点を始点とする辺を接続辺という。グラフの各点に対して接続辺の集合が決まり, 辺の番号が一番小さい接続辺を最初の接続辺という。同じ始点をもつ接続辺の集合で, 辺の番号を小さいものから順番に並べたときに,辺の番号が次に大きい接続辺を次の 接続辺ということにする。 図1のグラフの各点の接続辺の集合を表1に示す。図1において,点bの最初の接 ー14一 続辺は辺2である。辺2の次の接続辺は辺5となる。辺5の次の接続辺はない。 表1図1のグラフの各点の接続辺の集合 一筆書きの経路の探索において,一つの点に複数の接続辺がある場合には,最初の 接続辺から順にたどることにする。 図1のグラフで点aを出発点とした一筆書きの経路の求め方を図2に示す。 経路を構成する辺とその順番が,これ以上変わらない場合,確定済の経路という。 [1[2][3][4] Cr©の 1 とPA aだ 4,6 og fa|#1> wo@G a9 yn 7デーゝ 凡例——:探索済~----:未探索—:HER 注記1点や辺の番号を一部省略している。 注記2矢印は経路の向きを示す。 図2図1のグラフで点aを出発点とした一筆書きの経路の求め方 2を参考にした一筆書きの経路を求める手順を次に示す。 [一筆書きの経路を求める手順] 点aから探索する場合は,Haの最初の接続辺である辺1から始め,辺1の終点b の最初の接続辺である辺2をたどり,同様に辺3,辺4をたどる。辺4の終点aから たどれる未探索の辺は存在しないので,これ以上探索が進められない(図2[1])。 しかし,未探索の辺5,辺6,W7,辺8が残っているので,未探索の辺が接続す る点まで遡る。 終点aから辺4を湖ると,辺4の始点dで未探索の辺7が接続している。遡った経 路は途中で未探索の辺が存在しないので,これ以上,辺の順番が変わらず,辺4は, 一筆書きの経路の一部として確定済の経路となる(図2[2])。 点dから同様に辺7一辺8一辺5一辺6と探索できるので,辺3までの経路と連結 した新しい探索済の経路ができる(図2[3])。 辺6の終点dからは,辺6つ辺5つ辺8つ辺7一辺3つ辺2つ辺1と出発点の点aま CMD,これ以上,未探索の辺がないことが分かるので,全ての辺が確定済の経路に なる(図2[4])。 一筆書きの経路は,次の(1)て(④の手順で求められる。 (1)一筆書きの経路の出発点を決める。 (2)出発点から,未探索の辺が存在する限り,その辺をたどり,たどった経路を探 索済の経路に追加する。 (3)探索済の経路を未探索の辺が接続する点又は一筆書きの経路の出発点まで遡る。 遡った経路は,探索済の経路から確定済の経路にする。未探索の辺が接続する点 がある場合は,それを新たな出発点として,(2②)に戻って新たな経路を見つける。 (4)全ての辺が確定済の経路になった時点で探索が完了して,その確定済の経路が 一筆書きの経路になる。 〔一筆書きの経路を求めるプログラムJ〕 一筆書きの経路を求める関数directedEのプログラムを作成した。 実装に当たって,各点を点n(qは1てN)と記す。例えば,図+のグラフでは,A aは点1,点bは点2と記す。 グラフの探索のために,あらかじめ,グラフの点に対する最初の接続辺の配列 edgefirst及び接続辺に対する次の接続辺の配列edgenextを用意しておく。edgenext において,次の接続辺がない場合は,要素に0を格納する。 1のグラフの場合の配列edgefirst,edgenextを図3に示す。 =if= Fal Z 3 4 5 6 edgeirst[|1|2|3|4|6|8| weer[ol stolrtolo lol 辺1 2 3 4 5 6 7 8 注記edgefrstにはグラフの点に対する最初の接続辺の番号を格納している。 edgenextには接続辺の次の接続辺の番号を格納している。 図3図1のグラフの場合の配列edgefirst,edgenext edgefirstによって点2の最初の接続辺が辺2であることが分かり,点2から最初に たどる接続辺は辺2 UBS,edgenextによって,辺2の次の接続辺が辺5であるこ とが分かるので,点2から次にたどる接続辺は辺5となる。辺5の次の接続辺はない OC,点2からたどる接続辺はこれ以上ないことが分かる。 プログラム中で使用する定数と配列を表2に,作成した関数directedEのプログラ ムを図4に示す。 全ての配列の添字は1から始まる。 表2使用する定数と配列 グラフの点の個数 配列|startlm]には,辺mの始点の番号が格納されている。 配列|enqlm]には,Wmの終点の番号が格納されている。 配列|edgefrstln]には,Knの最初の接続辺の番号が格納されている。 edgenext[m]配列|edgenext[m]には,Amの次の接続辺の番号が格納されている。ROR 続辺がない場合は0が格納されている。 current[n]配列|currentln]には,点nを始点とする未探索の辺の中で最小の番号を格納 FS,Ainを始点とする未探索の辺がない場合は0を格納する。 searched[m]配列|一筆書きの経路を構成する探索済の辺の番号を順番に格納する。(探索 済の経路)- 配列|一筆書きの経路を構成する確定済の辺の番号を順番に格納する。(確定 済の経路) function directedE() for(」を1からNまで1ずつ増やす)//各点での未探索の辺の番号を初期化 current[i]<—edgefirst[i] endfor topで1//探索済の経路の辺の格納位置を初期化 lastとM//確定済の経路の辺の格納位置を初期化 xで1//出発点は点1 while(①lastが1以上) if(current[x]がでない) tempでcurrent[x]//点xからたどる接続辺はtemp searched[top]<temp//接続辺tempを探索済の経路に登録 current[x]て//点ぇから次にたどる未探索の辺を格納 x<end[temp]//接続辺tempの終点を点xにする topをtop+1 else topと//探索済の辺を遡る temp<—searched[top]//遡った辺はtemp path[last]<temp//辺tempを確定済にする -_ lastてlast一1 endif endwhi le endfunction 図4関数directedEのプログラム

共通の文章

クラウドストレージの利用に関する次の記述を読んで,設問1,2に答えよ。 L社は,企業のイベントなどで配布するノベルティの制作会社である。L社には, 営業部,制作部,製造部,総務部,情報システム部の五つの部があり,500名の社員 が勤務している。また,社員の業務時間は平日の9時から18時までである。L社で は,各社員が作成した業務ファイルは各社員に1台ずつ配布されているPCに格納し CH),部内の社員間のファイル共有には部ごとに1台のファイル共有サーバ(以 下,FSという)を利用している。 L社では,社員の働き方改革として,リモートワークの勤務形態を導入することに した。リモートワークでは,社外から秘密情報にアクセスするので,セキュリティを 確保する必要がある。 そこで,L社では業務ファイルをPCに格納しない業務環境を構築することにした。 PC内の業務ファイルをM社クラウドサービスのストレージ(以下,クラウドストレ ージという)に移行し,各PCからクラウドストレージにアクセスして,クラウドス トレージ内のファイルを直接読み書きすることにした。また,FS内のファイルにつ いてもクラウドストレージに移行することにした。クラウドストレージを利用した設 at,実装,移行は,情報システム部のN君が担当することになった。 [クラウドストレージ容量の試算〕 N君は。クラウドストレージに必要なストレージ容量を試算するために,PCやFS に格納済の業務ファイルの調査を行った。PCは,500台のPCから50台のPCをラ ンダムに選定し,移行対象のファイルについて,ファイル種別ごとのディスク使用量 を調査した。N君が調査した,PC 1台当たりのファイル種別ごとのディスク使用量 を表1に示す。 表1 PC 1台当たりのファイル種別ごとのディスク使用量 = FSについては,5台のFSについて,ファイル種別ごとのディスク使用量とファイ ルの利用頻度ごとのディスク使用量の割合の調査を行った。FS 1台当たりのファイ ル種別ごとのディスク使用量を表2に,ファイルの利用頻度ごとのディスク使用量 の割合を表3に示す。ここで,ABE LIS FSに格納済のファイルの年間読出し回 数のことであり,ファイルの読出しはPCからファイルを参照する動作によって発生 する。 表2 FS 1台当たりのファイル種別ごとのディスク使用量 ディスク使用量(Tバイト) 契約書・領収書・納品書などの文書ファイル イベント風景を撮影した写真や動画ファイル 表3ファイルの利用頻度ごとのディスク使用量の割合 利用頻度(回年)平均利用頻度(回年)|ディスク使用量の割合(%) 500回以上1,000回未江 100回以上500[Bl Ait |4 fiom。。|。。。55|。。。80 この調査結果から,L社の全てのPCやFSに格納済のファイルをクラウドストレ ージに移行すると,現時点では少なくとも| 』|Tバイトのストレージ容量が 必要であることが分かった。 [クラウドストレージの利用費用の試算〕 クラウドストレージでは,ストレージ種別によって利用料金が異なる。クラウドス トレージの料金表を表4に示す。読出し料金とは,クラウドストレージに格納した ファイルを読み出すときに発生する料金であり,PCからファイルを参照する動作に よって発生する。 表4クラウドストレージの料金表 -年間保管料金読出し料金 |1|標準ストレージ。|3O|0I 低頻度利用ストレージ 長期保管ストレージ|6e|606| 年間のクラウドストレージの利用費用は,次式で算出できる。 年間保管料金X保管Gバイト数十読出し料金X読出しGバイト数 ファイルの利用頻度に応じてストレージ種別を適切に選択することで,利用費用を 抑えることができる。 N君は,PC内のファイルは標準ストレージに格納することにし,FS内のファイル は利用頻度によって利用するストレージ種別を表4 ORS 1~3のストレージ種別か ら選択した。N君が試算した,ストレージ種別ごとのデータ容量と利用費用を表5に 示す。読出しGバイト数は,データ量x表3の平均利用頻度を用いて求めた。 表5ストレージ種別ごとのデータ容量と利用費用 項番ストレージ竹別ne ee年間保管費用|読出し費用 (千円ノ年)(千円ノ年) (am)| 人上利用ストレージ(a) BMRA RUD [クラウドストレージの実現方式の検討] 次にN君は。クラウドストレージの実現方式を検討した。N君が検討した,クラ ウドストレージの実現方式(案)を図1に示す。 し D>oe し社事業所 aa] 図1クラウドストレージの実現方式(案) M社クラウドサービスにあるストレージサーバ,ストレージ装置,ルータAを利 用してクラウドストレージを実現する。ここで,ルータAとルータBの間はVPNで 接続されており,平均400 Mビットノ秒の速度でデータを送受信できる。L社事業所 内の各機器は平均800Mビットノ秒の速度でデータを送受信できる。また,社外か らクラウドストレージを利用する場合には,PCとルータA間をVPNで接続し,通 信路のセキュリティを確保する。 [PC内ファイルの移行方式の検討〕 N君はPC内のファイルのクラウドストレージへの移行方式を検討した。社員全員 が一斉にPC内のファイルを移行すると時間が掛かる。例えば,500名の社員が自分 のPCに格納済の20Gバイトのデータを,それぞれクラウドストレージにコピーす る場合,各社員のデータが均等に伝送されるものとすると,社員がPCでファイルの コピビーの開始を指示してから全ファイルのコピーが完了するまでの時間は | e|時間となる。 そこでN君は,業務繁忙月を避けて1週間の移行期間を設定し,L社事業所内に 移行用NASを設置して移行する方式を検討した。移行期間には,500名の社員を100 名ずつ五つのグループに分け,グループごとに次の三つの作業を行うことでデータを 移行する。 作業1業務時間内に各社員がPC内のファイルを移行用NASにコピー 作業2業務時間外に移行用NAS内のファイルをクラウドストレージに移動 作業3各社員がクラウドストレージのファイルを確認しPCのファイルを削除 ー93一 グループごとの移行スケジュールを図2に示す。 |a A |クーカesas]|[*)||*)||*)IE クーク||DC)Elにに aa|||(eee!Cobar |クタデブ||||||9際夫腔時||*)|| Ia||||||||(rem emir 注記表中の*※は社員がクラウドストレージを利用して業務を行うことを示す。 図2グループごとの移行スケジュール N lk,クラウドストレージの構築とファイルの移行の検討を終え,上司に報告し 承認を得た。

共通の文章

問5 LANのネットワーク構成変更に関する次の記述を読んで,設問1ー4に答えよ。 K社は,従業員約200名の自動車部品製造会社である。主に国内自動車メーカから 注文を受けて,駆動系部品の開発・設計・製造を行っている。K社の事務所は,工場 敷地内の3階建ての事務棟に置かれており,各フロアで企画部,開発製造部,営業部 及び総務部の,事務所勤務を行う社員約100名が業務を行っている。 事務棟にはK社LANが敷設されており,社員は一人1台のデスクトップPC(以 下,DPCという)を使って各自の業務を行っている。現在のK社LANは,サーバを 接続するサーバLAN,DPCを接続するPC LAN,及びDMZの三つのサブネットワー クで構成されている。無線LANは未導入で,DPCは有線LANで接続している。各 部署の業務で扱っている重要情報と,それを管理するサーバを表1に示す。また,現 在のK社ネットワーク構成を図1に示す。 表1 K社が各部署で扱っている重要情報とそれを管理するサーバ 重要情報名 K社crAN(192.168.10.0)DMZ(192.168.201.0)<= サーバLAN(192.168.101.0) サーバサーバサーバサーバ||IL3SW:レイヤ3スイッチ 192.168.101.11 192.168.101.12 192.168.101.13 192.168.101.14 IL2SW:レイヤ2スイッツチ 注記1 DMZ上のサーバは省略している。 注記2各サブネットワークのサブネットマスクは,255.255.255.0である。 図1現在のK社ネットワーク構成 PC LANとサーバLANはL3SW及びL2SWで接続されており,DPCから全ての サーバにアクセスすることができる。各サーバ内の情報には,社員IDとパスワード で認証を行い,許可された社員だけがアクセスできる。 〔【セキュリティ強化のための対策〕 K社では,サーバの認証情報の設定ミスによって,総務部の一部の社員が顧客情報 を入手して閲覧できる状態になっていたというインシデントが発生した。K社では同 種のインシデントへの対策として,セキュリティの強化を行うことになった。まず PC LANを部署ごとに異なるサブネットワークに分割し,サブネットワークごとに接 続可能なサーバを定め,それ以外のサーバへのアクセスを遮断することにした。また, ランサムウェアなどの新たな脅威に対応できるウイルス対策ソフトを全てのDPCに 導入することにした。サーバLAN上にウイルス対策ソフトの更新サーバを導入し, 全てのDPCから定期的にアクセスして,ウイルス定義ファイルを最新の状態にする ことにした。更新サーバのIPアドレスは192.168.101.21とした。 ネットワーク構成の変更を担当することになった総務部のLさんは,各フロアに 設置されているL2SWを利用して,既設のPC LANを部署ごとに異なるサブネット ワークに分割し,各サブネットワークにVLANを割り当てることを考えた。分割後 のK社ネットワーク構成案を図2に,L3SWのアクセスコントロールリストを表2に 示す。 K社 企画部LAN(192.168.64.0,VLAN64)DMZ(192.168.201.0)vcs 総務部LAN(192.168.67.0,VLAN67)3 ii 開発製造部LAN(192.16865.0。VLAN65) 営業部LAN(192.168.66.0,VLAN66)2階 1階 サーバLAN(192.168.101.0) 注記1 DMZ上のサーバや各LAN上のDPCは省略している。 注記2 VLAN64~VLAN67はVLAN IDを示す。 注記3各サブネットワークのサブネットマスクは,255.255.255.0 CHS. 図2サブネットワーク分割後のK社ネットワーク構成案 ー27一 表2 L3SWのアクセスコントロールリスト(抜粋) (省略) (省略 |4|19216867024|(省略) |6|ANY|ANY|居断| 注記1サブネットマスク長を指定しないIPアドレスはホストIPアドレス(サーバやDPCに付与するIPアド レス)を示す。 注記2 ANYは対象が全てのIPアドレスであることを示す。 注記3 L3SWのダイナミックパケットフィルタリング機能によって,戻りパケットは通過できるものとする。 注記4アクセスコントロールリストは,項番の小さい順に参照され,最初に該当したルールが適用される。 Lさんが検討したセキュリティ強化のための対策案を総務部内で説明したところ, 表3に示す課題が指摘された。Lさんは,各課題に対して対策を検討した。 表3総務部内で指摘された課題 既設のPCLANはカテゴリ5のUTPケーブルを使って配線されており,DPCとは 1 100BASE-TXで接続している。ネットワークの速度が遅く業務に支障が出ているので, 改善してほしいと各部署から要望があめがっている。 8フロア間の管路に余裕がなく,既設のケーブルを撤去しないとフロア間に新しいケーブ ルを配線できない。 近い将来,無線LANを導入し,DPCをノートPCに置き換えることを検討したい。各 3フロアに無線LANアクセスポイント(以下,無線APという)を設置する準備をしてお きたい。 4部署ごとの人員増減に伴って,近い将来部署を配置するフロアが変更となる可能性があ る。その際にもケーブルの配線変更を最小限にしたい。 [物理配線の検討] 表3の項番1,項番2の課題に対応して,既設のPC LAN用のケーブルを撤去し, 新たなケーブルを配線することにした。フロア内のL2SWからDPCまでの配線は, ①1000BASE_T方式に対応したUTPケーブルとした。また,1階のサーバルームに設 置したL3SWから各フロアのLEWまでは,ORA1IOGビットノ秒で通信可能な光 ファイバケーブルとした。 (無線LAN BA OR) 表3の項番3の課題に対して,事務棟の各フロアで無線APの設置に適した場所の 調査を行った。その結果,電源の確保が困難な設置場所が判明した。また,事務棟が 東西方向に約50mと細長く,部屋を仕切る壁が厚いことや金属製の扉が多いことも 確認した。 そこで,各フロアに設置するL2SWを今後リプレースする場合には,UTPケーブ ルで無線APに電力供給が可能な|c|機能を備える機器を導入することにし た。また,③導入予定の無線APと各DPCの設置位置での電波強度の調査を行うこ どもた。 (VLAN構成の検討] 表3の項番4の課題に対して,一つのフロアに複数部署が混在したり,部署がフロ ア内やフロア間で移動する可能性を考慮して,ネットワークスイッチのポート単位に VLANを設定するポートベースVLANではなく,一つのポートに複数のVLANを同 時に設定できる| q|VLANの機能を備えるネットワークスイッチを導入する SE CUE LE, 現状の部署の配置を前提とした,ネットワークスイッチのフロア配置を図3に示す。 図2のネットワーク構成を図3のネットワークスイッチで構成した場合の,各ネット ワークスイッチのVLAN構成の案を表4に示す。 Lさんの検討案は総務部内で承認され,具体的な実施計画を策定することになった。 事務棟P32 注記Pnは各ネットワークスイッチのポートIDを示す。 図3現状の部署の配置を前提としたネットワークスイッチのフロア配置 ー29— 表4各ネットワークスイッチのVLAN構成の案 =eo LasW ee ee a re開 L2SW3

共通の文章

問6企業向け電子書籍サービスの追加設計と実装に関する次の記述を読んで,設問1~ 4に答えよ。 H社は,個人会員向けに電子書籍の販売及び閲覧サービス(以下,既存サービス という)を提供する中堅企業である。近年,テレワークの普及に伴い,企業での電子 書籍の電要が高まってきた。そこで,既存サービスに加え,企業向け電子書籍サービ A(以下,新サービスという)を開発することになった。 新サービスの開始に向けて,企業向け書籍購入サイトを新たに作成し,既存サービ スで提供している電子書籍リーダを改修する。新サービスの機能概要を表1に,検 討したデータベースのER図の抜粋を図1に示す。 このデータベースでは,E-R図のエンティティ名を表名にし,属性名を列名にして 適切なデータ型で表定義した関係データベースによって,データを管理する。 表1新サービスの機能概要 1|一括購入|企業の一括購入担当者が,電子書籍を一括購入する。購入した電子書籍を 企業の社員に割り当てる方法には,次の二つがある。 ①)一括購入担当者が,配布対象の社員にあらかじめ割り当てておく方法 (2)社員が,未割当の一括購入された電子書籍を割当依頼する方法 2|企業補助社員が,自己啓発に役立つビジネスや技術など特定の分類の電子書籍を購 入する。その際,企業が購入額の一部を負担する。ただし,企業は負担す る上限金額を書籍分類ごとに設定する。 3|割引購入社員が,個人として読みたい本や雑誌などの電子書籍を購入する。その 際,それぞれの企業がH社と契約した一定の割引率を適用した価格で購入 できる。 4|書籍閲覧|社員が,電子書籍リーダに,H社が付与した企業ID,社員ID及び社員パ スワードを用いてログインし,No.1~3で購入した電子書籍を閲覧する。 電子書籍リーダにログインすると,一括購入で割り当てられた電子書籍 や,社員が購入した電子書籍が一覧表示され,各電子書籍を選択して閲覧 できる。 書籍TD_|企業補助。|SAID個人会員ID 書籍名BID購入日時個人会員パスワード 毒籍分類ID全業D個人会員D個人会員名 補助率 書籍分類|a』|補助上限金額一括購入 書籍分類ID二括購入TD 書籍分類名一括購入日時 ー企業 リーーーーーL_5]ー括購入数量 社員書籍購入日時5 3 ie括購入金額 EID.ー括購入割当 ae He nme社員パスワード社員D 社員負担金2D 凡例一一:1対1注記属性名の実線の下線—_は主キー, ーー:1対多Tae破線の下線-----は外部キーを示す。 <一>:多対多|属性名主キーの実線が付いている属性名には, 属性名外部キーの破線を付けない。 図1検討したデータベースのE-R図(抜粋) 【一括購入機能の社員割当処理の作成] 表1中の一括購入機能の概要(2)にある,社員が割当依頼した電子書籍を割り当て る処理を考える。検討した処理の流れを表2に示す。ここで,“一括購入ID”は割 当依頼された一括購入IDを,“PM ID”及び“:社員ID”は割当依頼した社員の企 業IDと社員IDを格納する埋込み変数である。 表2検討した処理の流れ 処理概要使用するSQL文 1|社員が割当依頼した一括購入IDから,一括|SELECT一括購入数量 購入数量を取得する。FROM一括購入 WHERE一括購入ID=:一括購入ID 2|社員が割当依頼した一括購入IDのうち,現|SELECT[a| 在割り当てられている数量を取得する。FROM一括購入割当 WHERE一括購入ID=:一括購入ID 3手順1で取得した数量が,手順2で取得し た数量より| e|場合,手順4に進]なし む。そうでない場合,処理を終了する。 4割当依頼した社員に一括購入IDを割り当て|INSERT INTO一括購入割当 る。(一括購入ID,社員ID,企業ID) 表2のレビューを実施したところ,処理の流れやSQL文に問題はないが,①トラ ンザクションの同時実行制御には専有ロックを用いるように,とのアドバイスを受け Tei, [書籍閲覧機能の作成 電子書籍リーダに,社員がログインした際,閲覧可能な重複を含まない書籍の一覧 を取得するSQL文を図2に示す。ここで,“:企業ID”及び“4tB ID”は,ログイ ンした社員の企業Dと社員IDを格納する埋込み変数である。また,2の には,図1の|<|と同じ字句が入る。 SELECT sk|c| FROM社員書籍購入sk WHERE sk.企業ID=:企業ID AND sk.社貞ID=:社員ID SELECT ik|<| FROM一括購入ik INNER JOIN一括購入割当iw WHERE ik.企業ID=:企業ID AND iw.社員ID=:社員ID 図2閲覧可能な重複を含まない書籍の一覧を取得するSQL文 [書籍閲覧機能の改善] 書籍閲覧機能のレビューを実施したところ,既存サービスを個人で利用している社 Bld,電子書籍リーダのログインIDを個人会員IDから企業IDと社員IDに切り替 えて利用しなければならず燃雑である,との指摘を受けた。 そこで,電子書籍リーダに個人会員IDを用いてログインした際,社員として閲覧 できる書籍も一覧に追加して閲覧できるように,E-R図に新たに②一つエンティティ を追加し,電子書籍リーダに③一つ画面を追加した上で書籍閲覧機能に改修を施した。

共通の文章

間7 IoTを利用した養殖システムに関する次の記述を読んで,設問13に答えよ。 G社は,海上の生け供の中で良質な養殖魚の育成を支援する,IoTを利用した装殖 す システム(以下,スマート生け算という)を開発している。 [スマート生け千のシステム構成 スマート生け息の概観を図1に,スマート生け和傘のシステム構成を図2に示す。 無線通信|サーバー ブイの給餌部の74 mLレイTTFFHHTHHHごHHHFFT 7 ct ee ef+t tS stー水中ステレオカメラ sents TT ee TT|O[PT ay... 6 ss ott|}rr a下・ oe 水質センサへン. “”ーZN t ye=t.|ー ZEEE CCE EER ame? SSI各伯検知部FAB YF 図1スマート生け低の概観 ser ie|ES M2 AV-KEVHOV AT ABM AYV—-hEV Rl,網をつるすためのブイに接続された水質センサ,水中ステレ オカメラ,BARAK,及び給餌部で構成される。給餌部は,海中への餌の投入 (以下,給餌という)を行う。残餌検知部は,養殖魚が食べ残して沈んでいく餌 (以下残餌という)を収集する集餌コーン及び残餌センサで構成される。給餌部 ik,残餌検知部で取得した残餌の量を用いて求めた食べた餌の重量,水質センサの 計測データ(以下,水質データという),及び水中ステレオカメラで撮影された動画 (以下,動画データという)をサーバに送信する。サーバは,薔積したデータを基 にAIで分析し,与える餌の重量(以下,給餌重量という),及び餌を与える日時(LA 下,給餌日時という)を決定し,給餌部に送信する。 (給餌部の動作概要) (1)給餌部は,定期的に動画データ及び水質データを受信してフラッシュメモリに 保存する。保存した動画データ及び水質データをサーバに送信する。 (2)給餌部は,給餌重量及び給餌日時をサーバから受信する。指示された給餌日時 になると,給餌部は,給餌重量を基に,給餌を行う回数(以下,給餌予定回数と いう),1回当たりの餌の重量を求める。さらに,給餌の終了判断に用いるしきい 値を決定し,次の動作を開始する。 ・給餌部は,1回目の給餌を開始するとともに,残餌検知部を動作させる。 BARS,集餌コーンによって集められる。残餌センサは,通過する残餌を1個ず つカウントし,その値をカウント値とする。カウント方法は,アップカウント とする。 ・給餌部は,5分間隔でカウント値を読み込み,単位時間当たりのカウント値(以 下,Ct値という)を求める。Ct値がしきい値より少ないときは,養殖魚が餌を 食べ続けていると判断する。Ct値がしきい値以上のときは,養殖魚が餌を食べ なくなったと判断する。 ・給餌部は,Ct値がしきい値より少ないときは,給餌予定回数に達するまで給餌 を繰り返す。 ・給餌予定回数に到達したとき,又はCt値がしきい値以上のとき,給餌を終了す る。終了直前で読み込んだカウント値を,給餌終了時のカウント値とする。 ・給餌部は,給餌を行った回数を基に,実際に給餌した餌の重量を求める。求め た値を用いて,食べた餌の重量を求める。ここで,給餌を行う1個の餌の重量は 均一とする。 ・給餌部は,食べた餌の重量をサーバに送信する。 〔サーバの動作概要) サーバは,動画データを基に,養殖魚の大きさ・形状・推定個体数を抽出し,水 質データと食べた餌の重量を併せて蓄積する。サーバは,薔積したデータを基にAI で分析し,良質な養殖魚を育成する上で適した給餌重量及び給餌日時を決定して, ー37一 給餌部に送信する。 [装置の機能〕 スマート生け穫の構成要素の概要を表1に示す。 表1スマート生け得の構成要素の概要 構成要素名機能概要 ・給餌重量及び給餌日時をサーバから受信する。 BRE HI,給餌予定回数,1回当たりの餌の重量を求める。 給餌部・給餌の終了判断に用いるしきい値を決定し,給餌を行う。 ・動画データ及び水質データを受信すると,フラッシュメモリに保存し,サーバに送信する。 ・給餌終了時のカウント値を用いて,食べた餌の重量を求め,サーバに送信する。 残餌検知部・集餌コーンで残餌を収集し,残仙センサのカウンタで残餌を1個ずつカウントする。 水中ステレオ|・養殖魚を定期的に撮影し,動画データとして給餌部に送信する。 カメラ ・水温,海中の酸素濃度,塩分濃度を計測し,水質データとして給餌部に送信する。 ・動画データを基に,差殖魚の大きさ・形状・推定個体数を抽出する。 サーバ・水質データ,食べた餌の重量,及び養殖魚の大きさ・形状・推定個体数を蓄積する。 ・蓄積したデータを基にAIで分析し,給餌重量及び給餌日時を決定して給餌部に送信する。 給餌日時になったときの給餌処理フローを図3に示す。 給餌予定回数に到達したか。 No給餌終了時の| 。|を用いて 食べた餌の重量を求める。 残餌検知部の動作を終了する。 図3給餌処理フロー

共通の文章

データ中心設計に関する次の記述を読んで,設問1ー4に答えよ。 X社は,30店舗をもつスーーパーマーケットチェーンである。XX社の店舗は,地域の 顧客ニーズに合わせた商品選定,販売戦略によって,売上げを伸ばしている。 X社では,Webサイトで購入した商品を自宅に配送するサービス(以下,ネットス ーパーという)を3年前から開始している。近年,他社も同様のサービスを開始し, 競争が加熱している。 X社のネットスーパーを支える情報システム(以下,現行システムという)ld,シ ステム機能の追加や変更(以下,機能変更という)が多く,ソフトウェアが肥大化, 複雑化している。そこで,X社では,顧客や店舗スタッフからの機能変更の要求に迅 速に対応することを目的に,新しいネットスーパーシステム(以下,新システムとい う)を構築することにした。新システムの開発は,システム部門のY君が担当するこ CHOPS Es 〔システム設計方法の調査〕 Y Bld,機能変更を繰り返しても,ソフトウェアの構造が複雑になりにくく,変更 容易性の高いシステムが構築可能なデータ中心設計について調査した。 X社がこれまで採用してきた| 』。|中心設計は,データの設計に先行して機 能を設計し,機能に合わせて必要なデータを設計する手法である。この手法を用いる と,業務要件が変わると機能もデータも変更が必要となる。 一方で,データ中心設計は,データの構造は機能と比較して変わりにくいという点 に注目し,機能の設計に先行してデータの設計を行う手法である。データを中心に設 計することで,機能変更時にもデータの変更を少なくできる。 [現行システム機能の調査 Y君は,現行システムの三つの機能と機能変更の頻度について調査した。 (1)maa HB eRHE, 顧客情報を登録,更新するための機能。顧客には,顧客種別として,個人顧客と 法人顧客があり,個人顧客には一般個人顧客とX社電子マネーをもつ会員個人顧客 がある。この機能は,過去3年間に顧客種別の追加に関する機能変更が1回だけあ ー49一 だ。 (2)商品表示機能 顧客へ商品を表示する機能。商品には,商品種別として,通常商品のほか,通常 商品を束ねたセット商品,特売商品,タイムセール商品,事前に予約することによ って通常商品を割引価格で購入できる事前予約商品,及び顧客の購入履歴から算出 したお勧め商品がある。商品種別ごとに画面の表示方法が異なる。この機能は,B 客にX社のネットスーパーを選択してもらうための重要な機能であり,商品種別の 追加に関する機能変更が多い。 (3)購入機能 顧客が商品を購入し,料金を支払う機能。料金支払には,X社電子マネー,クレ ジットカード,銀行振込,3種類の他社の電子マネーが利用できる。この機能への 機能変更は多くない。 [概念データモデルの設計〕 Y君は,現行システム機能の調査及び現行システムの関係者に対するヒアリングを 行い,新システムが管理するデータの概念データモデルを設計した。図1にY君が設 計した概念データモデル(抜粋)を示す。 人人人 IE 凡例 Tlに !ーータテ:多対多 図1 Y君が設計した概念データモデル(抜粋)__ この概念データモデルのうち,通常商品と事前予約商品は|c|関係,通常 商品とお勧め商品は|q|関係である。 Ja一 [顧客管理機能の設計〕 Y君は,顧客管理機能については,システム性能に重点を置きつつ,顧客管理機能 への変更が他機能に与える影響を小さくする設計とした。図2にY君が設計した顧客 管理機能の論理テーブルとソフトウェアのクラス図(抜粋)を示す。 論理テーブルのクラス図ソフトウェアのクラス図 顧客種別[mA MMI||顧客番号MAES||法人名 顧客種別名0顧客種別コード顧客種別コード担当者名 ーー配送先住所配送先住所ン担当者電話番号 配送先氏名配送先氏名本社住所 配送先電話番号配送先電話番号本社電話番号 [|し6 nweパ0パ〈〔{|6 gt顧客番号()get法人名() Vo Yo.eel 8—Ble We eet 20 和信|,PUNT?*#5116) 顧客番号顧客番号get配送先氏名()|~|getX社電子マネー||get本社住所() X社電子マネー番号法人名get配送先電話番番号()get本社電話番号() 0|担当者名号0 担当者電話番号ーーーーーーーーーーーーーーーーーーーーーーーテーーニニニーニーーーー 本住所aa er| PARES!|属性名|BB ーーーーーーー!|操作名0.1多重度0又は1 !0.*多重度0以上| 図2 Y君が設計した顧客管理機能の論理テーブルとソフトウェアのクラス図(抜粋) Y君は,顧客管理機能の論理テーブルとして,①顧客種別,顧客,個人顧客,法人 顧客の四つのテーブルを設計した。また,ソフトウェアの設計として,②ソフトウェ アの肥大化を防止するために顧客クラスを定義し,顧客クラスを継承するクラスとし て一般個人顧客,会員個人顧客,法人顧客の三つのクラスを設計した。 [商品表示機能の設計〕 Y Blk,商品表示機能は機能変更の頻度が高いことを考慮し,システム性能よりも 変更容易性に重点をおいた設計とした。図3にY君が設計した商品表示機能の論理テ ーブルとソフトウェアのクラス図(抜粋)を示す。 論理テーブルのクラス図ソフトウェアのクラス図 商品種別 商品種別コード|商品コード商品コード 商品種別名0商品種別コード|||商品種別コード に商品名商品名ンget開始日時() 販売価格販売価格get終了日時() 販売数量販売数量ーーーget割引率() 商品明商品説明get割引額0) 商品個別情報PPE画面表示() セット商品コード(商品種別コード()Rget割引率) ーーーget商品名()get割引額() get販売価格()画面表示() get販売数量()= get商品説明()q 画面表示() が商品一覧0 画面表示()gt予約日() ees F画面表示() Ra 画面表示() 注記商品テーブルの商品個別情報属性には,商品種別ごとに異なる情報をまとめて格納する。 図3 Y君が設計した商品表示機能の論理テーブルとソフトウェアのクラス図(抜粋) Y君は,商品表示機能の論理テーブルとして,⑨特売商品テーブル,セット商品テ ーブルなど商品種別ごとに多数のテーブルを作成するのではなく,商品種別と商品の 二つのテーブルを作成し,運用環境へのリリース時の作業量を低減する設計とした。 また,ソフトウェア設計としては商品クラスを定義むするとともに,④商品種別ごとに 個別のクラスを設計した。 その後Y Blk,新システムの設計及び構築を完了させ,X社は新システムを用いた ネットスーパーのサービスを開始した。

共通の文章

家電メーカでのアジャイル開発に関する次の記述を読んで,設問1ー3に答えよ。 P社は,中堅の家電メーカである。HEH,家電量販店を通じた拡大戦略で事業を伸 ばしてきたが,ここ数年の競争激化によって収益性が急速に悪化している。そこで, P社は,ビジネスモデルを,家電量販店を通じた間接販売から,顧客となる消費者へ 直接販売するインターネット販売へ転換する戦略を打ち出した。これを受けて,消費 者向けのシステムの整備が急務となり,CDO(Chief Digital Officer)lt,インターネ ット販売システム開発プロジェクトUE,本プロジェクトという)を発足させた。 〔本プロジェクトの計画] (1)本プロジェクトの目的 ・インターネット販売は競合相手が多く,インターネット販売システムへの要求が 満たされないと顧客は簡単に競合相手に移ってしまうので,P社として,顧客か らの要求に対して,競合相手と比べてより迅速に対応できるようにする。 ・これまで一部のプロジェクトだけで用いていたスクラムによるアジャイル開発を 採用し,今後同社での利用を拡大させていく端緒とする。 2)本プロジェクトの方針 ・P社にはスクラムの経験者が少ない。そこで試行開発の段階を設けて,スクラム 開発の理解を深め,スクラムの開発要員を育成し,プロセスを確立しながら本プ ロジェクトを遂行する。 ・試行開発を経て,本格的なスクラム開発の人材を確保し,顧客からの要求に迅速 に対応できるようにする。 (3)本プロジェクトのスコープ ・インターネット販売システムは,Webストア,モバイルアプリケーションソフ トウェア(以下,モバイルアプリという)及びSNSの三つのサブシステムから 構成される。Webストアから開発に着手することにして,これを試行開発と位 置付ける。 ・Webストアのプロダクトバックログアイテムのうち,本プロジェクトの開始時 点で洗い出した要件をユーザストーリの形式で記述して,開発の規模,難易度, 複雑さなどによる開発作業の量(以下,サイズという)と優先順位で分類し,ス ー4g一 トーリポイントを算出した。Webストアのユーザストーリ数と,サイズごとの ストーリポイントの合計を表1に示す。 表1 Webストアのユーザストーリ数とサイズごとのストーリポイントの合計 5ストーリポイ 優先順位9A|優先順位B|優先順位Cント?の合計 |か|5|6|4』|sg|sg| Poe|7|eo|』|sm|ss| |天|2 0|1|5|sgs|% し件|sw|」|sm|ぁg|sw| EPユーザストーリをサイズに応じて小,中,大の三つに分類する。 注?優先順位は高い順にA,B,Cで表す。プロダクトバックログアイテムをスプリントバックログに割り 当てるときに,この優先順位を厳守するものとする。 注ツユーザストーリには,サイズに応じて小に2,中に3,大に5のポイント(以下,ptという)を付与 して,これをストーリポイントとする。 (44)本プロジェクトの体制 本プロジェクトの体制を表2に示す。 表2本プロジェクトの体制 役割の説明担当者名担当者の開発経験所属・職位 hnしュ|RE|験はあるが,アジャイル開発プnn™ ,・システム開発プロジェクトの経|。。。。。 ロジェクトは初めてである。~ ・スクラムの実施方法・システム開発プロジェクトの経 を計画・助言する。験は豊富で,スクラムによるア スクラム|・必要に応じてプロジTCジャイル開発プロジェクトを多|情報システム スクラム|マスタェクトの関係者とのく経験している。部門・主任 デムコラボレーションを 促進する。 2)Mea情報システム部門と営業部門の|eo >>=ae Nie oY 混成で,専任8名をアサインすsa 開発チー|作成する。3|部門及び営業 he.実際の開発作業に携|(™る。8名のうち,3名はスクラ|eae oy ちろムによるアジャイル開発プロジ5 °ェクトを経験している。 ay[2-9|Bigeree oe|pa|参加した経験はない。マーケティン —"アジャイル開発プロジェクトに チーム|全てしの人・競合相手の状況や願客の要求な|グ部門・課長 どを把握している。 (以下,省略) ①開発チームは,まずは全メンバでWebストアの開発チームを編成し,Webスト アの開発の完了後に-モバイルアプリの開発チームとSNSの開発チームを編成する こととする。 [本プロジェクトの実行と管理〕 スクラムチームは,本プロジェクトを次のように進めることになった。 (1)スケジュールとその管理方法 ・競合相手のWebストアは,1年に1~2回程度のリリースであるのに対して,P 社のWebストアは,②③リリースのサイクルを3か月に1回とした。 ・Webストアのリリースは,リリース1とリリース2から成る。プロダクトバッ クログアイテムは優先順位によって次の計画でリリースする。 ・優先順位A…リリース1 ・優先順位B…リリース1ただし,今後の進捗状況でリリース2でも可 ・優先順位C…リリース2 ・リリース内では一連のスプリントを繰り返し実施し,各スプリントはS-01,S- 02というように連番を付けて表す。 ・スプリントは2週間を1単位とする。 ・本プロジェクトの進捗状況が計画からどのくらい離れているのかを管理するため に,横軸に時間,縦軸にストーリポイントを割り当て,残りのストーリポイント を折れ線グラフで示す| b|を用いることにした。 (2)スプリントバックログの対応実績 ・Webストアのスプリントバックログ対応実績集計表(S-04終了時点)を表3に 示す。 表3 Webストアのスプリントバックログ対応実績集計表(S-04終了時点) ga 4pt Apt 8pt eee 6pt 3pt Opt 18pt ee eee 5pt 5pt 10pt oe Fag ae a fmt 注記1サイズ別の各スプリントバックログの上段は,優先順位別のユーザストーリ数を表す。下段は,ユー 10pt 8pt Opt Opt 36pt ザストーリのptを表す。合計行は終了したスプリントのユーザストーリ数及びptの合計を表す。 注記2サイズ,優先順位,ptの意味は表1の注を参照すること。 (3)プロダクトバックログアイテムの追加依頼 S-04の途中で,THE R氏の間で次の会話が交わされていた。 TA:重要な新規要件を優先順位Aとして追加することがビジネス上必須となっ Fes RK:その要件が重要なことは理解したが,サイズ大のプロダクトバックログア イテム1個を新規追加することになるので,リリース1でリリースする計 画のプロダクトバックログアイテムを見直すことになる。 TH:アジャイル開発なので,要件の柔軟な追加や変更ができると思っていた。 新規追加のプロダクトバックログアイテムは優先順位Aなので,これは必 ずリリース1に入れてほしい。その上で,アジャイルの作業生産性は高い はずだから,計画したプロダクトバックログアイテムも全てリリース1に 入れられるのではないか。 R氏:依頼については理解したが,リリース1でリリースするプロダクトバック ログアイテムの見直しは不可避だ。 TH:納得できないので,別途調整させてほしい。別件だが,機能的に重複する ところがある類似の要件を,今後数件追加させてもらう可能性が高い。 R氏:了解した。その件については,プログラムの外部から見た動作を変えずに ソースコードの内部構造を整理するを実施することで,今後の 拡張性・柔軟性を高めたいと思う。 〔プロセスの確立と実施) (1)S-04終了時のレトロスペクティブ ・開発チームは,A,関係プロセス及びツールの観点からS-04のレトロスペク ティブを実施し,うまくいった項目とうまくいかなかった項目を特定・整理した。 ・開発チームは,S氏の助言を得て,③R氏とT氏との今回のプロダクトバックロ グアイテムの追加依頼の会話を踏まえて,関係者間でのプロセスの確立について 検討することにした。 ・R氏は,S氏の支援のもと,アジャイル開発は作業生産性の向上を目的とするも のではないことを芽氏に認識してもらうことにした。 (2)S-05開始時のスプリントプランニング ー5g1一 ・S-05,S-06及びリリース2のベロシテイィとして,S-01~S-04の各スプリントで 測定したベロシティの平均値を用いる。 ・R氏は,確立したプロセスに則って調整した結果.,リリース1については,TK 依頼のプロダクトバックログアイテム1個を新規追加した上で,優先順位Aの プロダクトバックログアイテムのリリース日を守り,リリース2については, 残りの全てのプロダクトバックログアイテムをリリース日までに完了することで T氏と合意した。このとき,リリース2で対応予定のストーリポイントは | 』pt ea,ベロシティ上の問題はない。

共通の文章

間19変更管理に関する次の記述を読んで,設問1ー3に答えよ。 B社は,中堅の物流企業である。B社のシステム部は,物流管理システムを開発・ 保守・運用している。物流管理システムは,物流管理サービスとして,B社のサービ ス利用部署に提供されている。物流管理サービスは,週1回設けているサービス停止 時間帯以外であれば,休日,夜間も利用可能である。近年,事業の拡大に伴い,物流 管理サービスへの変更要求(以下,RFCという)の件数が増加し,変更管理に関す る問題が顕在化してきた。 〔変更管理の現状] システム部では,RFCに基づいて,物流管理サービスの変更を行っている。変更 を適用するリリースを稼働環境に展開する作業(以下,展開作業という)は,サービ ス停止時間帯に行われる。RFCは,事業環境の変化などに対応する適応保守と不具 合の修正などの是正保守に大別される。適応保守には,売上げや利益を改善するため の修正や法規制対応などが含まれる。変更の費用は,RASHES CHEVATAM が一旦負担し,その費用をB社の全部署に人数割りで配弁している。 現在顕在化している変更管理に関する主な問題点は,次のとおりである。 (1)RFCの依頼者は,決められた書式の文書を電子メールに添付してシステム部の 変更管理担当に提出する。RFCの依頼者は,依頼部署の上司を写し受信者として 電子メールで提出すればよいので,依頼者の個人的な見解に基づくRFCもある。 (2)適応保守のうち,法規制対応のRFCは,RFCの依頼者が法規制の施行に基づい て設定した実施希望日に変更が実施されるが,法規制対応以外のRFCは,RFCを 受け付けた順に対応しており,システム部の要員の稼働状況によって変更実施日が 決められる。REC件数の増加によって,システム部の要員はひっ迫しており,重 要なRFCの変更実施日がRFCの実施希望日を過ぎてしまう場合があって,依頼者 からクレームが発生している。 (3展開作業の計画が不十分であったり,展開作業中に障害が発生したりするなど の要因で,予定時間内に展開作業が完了しない場合がある。また,展開作業が予定 時間に完了しない場合を想定しておらず,終了予定時刻を超過しても展開作業を継 続し,サービス開始を遅延させてしまうことがある。 ー54一 (4)経営層からは,変更管理について次の指示が出ているが,対応できていない。 (a2)変更決定者を定め,売上げや利益を改善するための修正は,ROIを考慮して RFCの承認を行うこと。 (b)変更の費用は,変更の実施によって利益を受ける受益者が負担すること。そ の場合,関係する部署でRFCを協議して,費用の取扱いを決定すること。 (c)変更実施後の実現効果を利害関係者と確認し,必要に応じて利害関係者と合 意した処置をとること。 [変更管理プロセスの手順案の作成 システム部のC部長は,変更管理の問題点を解決するため,システムの保守・運用 の管理を担当しているD課長に,変更管理の改善に着手するよう指示した。D課長 は,表1に示す変更管理プロセスの手順案を作成した。 表1変更管理プロセスの手順案 |東5|SS〈、〈、〈《〈{中>.| RFCの提出・変更依頼者は,RFCの内容を取りまとめて,①自部署の部長の承認を得た th,変更管理マネージャに提出する。 ・変更管理マネージャは,D課長が担当する。 RFCの受付・変更管理ユマネージャは,受け付けたRFCにRFC番号を割り当てる。 ・変更管理マネージャは,表2の優先度割当表の内容に従って優先度を割り当て る。 RFCの評価変更決定者が招集する,指名された代表で組織する変更府問委員会(以下, CABという)が,変更の影響について助言する。 ・CABの構成メンバ(以下,CAB要員という)は,変更管理マネージャ,RFC を提出した依頼者,依頼部署の部長,開発担当者,及び運用担当者である。 ・CABは適宜開催する。 ・変更管理マネージャは,CAB要員にRFCの内容を事前に送付し,CABの開催 を通知する。 ・システム部は,RFCの優先度と実施希望日を考應して,RFCの承認に必要と なる|。』。|を作成する。 表1変更管理プロセスの手順案(続き) 回証2所細間iL:: RFCの承認|RFCの承認及び差戻しは,変更決定者が決定権限をもつ。変更決定者の役割は 次のとおりである。 ・RFCの受付で設定した優先度が妥当かを判断する。 ・CABに出席し,CAB要員による評価を考慮して,RFCの承認及び差戻しを決 定する。 RFCの承認及び差戻しの判断基準には,ROIと実現可能性を考慮する。 変更決定者は,C部長が担当する。 RFCが承認された場合は,変更の実施を行う。承認されない場合は,RFC OK 頼者にRFCを差し戻しクローズする。 変更の実施|システム部の担当者が,変更を実施する。 ・承認された変更の詳細計画を作成し,開発(構築)及び試験する。 ・試験された変更を,稼働環境に展開する。 クローズ変更管理マネージャは変更の実施を確認して,問題がなければRFCをクローズ する。 表2優先度割当表 |優先度|。肉容。。|件数着人 高RFC 20% 多くのサービス利用者に対して影響与えるRFC,又は緊急性が高い 優先度"高”以外のRFC (C部長の指摘] D課長は,C部長に変更管理プロセスの手順案を説明したところ,次の指摘を受け た。 (1)適応保守の中には,ORO!と実現可能性だけで判断すべきではないRFCもある OC,RFCの承認及び差戻しの意思決定には,この点も考慮すること。 (2)et Bo OIE RILHO*,③変更の費用の費用負担方法を変更すること。こ れに伴い,CAB要員として必ず[|b|を参加させること。 (3)変更管理プロセスの手順案では,変更決定者は自身が務めることになっている が,REC件数が増加傾向にあるので,迅速な意思決定ができる仕組みを構築し, 自身は優先度の高いRFCの意思決定に専念できるようにすること。 (4)現状,“展開作業がサービス停止時間帯内に完了しない事例”が発生している。 変更管理プロセスの手順案の|。|では,サービス開始を遅延させないため の④展開作業時に実施する可能性のある作業を計画すること。 (5)変更を実施した後に,⑤変更実施後のレビュー(以下,PIRという)を行い,変 更の有効性をレビューすること。PIRの実施時期については,RFCの承認の際に決 定すること。 (6)現状の変更管理の問題点が解決されたかを確認するために,変更管理プロセス を評価するKPIを設定すること。KPIは,依頼者からのクレームが減ったことが確 認できるものとすること。 [変更管理プロセスの手順案の修正〕 D課長は,C部長の指摘に漏れなく対応するように,変更管理プロセスの手順案を 修正した。そのうち,迅速な意思決定に関する修正,及びKPIの設定は次のとおりで ある。 (1)迅速な意思決定については,表2に示す優先度がMK”のRFCの承認及び差戻 しの決定は,|<|とする。 (2)変更管理プロセスを評価するKPIとして,次の(3)て(<)を設定する。 (a)失敗した展開作業数の削減率 (b+)変更に起因するインシデント数の削減率 (c)実施希望日どおりに変更が実施できたRECの割合の増加率

共通の文章

システム構築プロジェクトの監査に関する次の記述を読んで,設問ユー6に答えよ。 クレジットカード会社のU社では,顧客利便性の向上,コストの削減などを目的 として,インターネットを通じて各種情報を顧客に提供するシステムの構築プロジ ェクト(以下,本プロジェクトという)を推進している。 U社の内部監査部長は,年度監査計画に基づき,システム監査チームに対して,本 プロジェクトの名段階の適切性を監査するよう指示した。 [要件定義段階の監査で把握した事項〕 システム監査チームは,要件定義段階の監査をX年5月に行い,本プロジェクト に関して,次のことを把握した。 なお,監査の結果,監査報告書に記載すべき重要な指摘事項はなかった。 (1)要件の区分 要件は,機能要件,セキュリティ要件,運用要件などに区分される。 (2)機能要件 従来,クレジットカード利用明細などの顧客向けの情報(以下,カード利用情 報という)は,基幹系システムで作成して出力し,広告用パンフレットなどとと もに,顧客宛に送付していた。本プロジェクトでは,カード利用情報,広告情報 などを顧客がWebブラウザで閲覧できるよう,情報系システムを開発するととも に,基幹系システムを改修する。 (3)セキュリティ要件 情報系システム及び基幹系システムの基本設計で定めるセキュリティ対策は,U 社の情報セキュリティ対策基準に準拠する。 (4)要件の管理 要件定義段階で未確定の要件(以下,未確定要件という)は,課題管理表に記 ML,確定するまで管理する。未確定要件は,基本設計の開始日から2か月以内 に確定させる予定である。 (5)本プロジェクトの運営体制 本プロジェクトの重要事項を決定する会議体であるプロジェクト運営委員会は, U社のシステム部の部長を議長とし,業務管理部,顧客サービス部などユーザ部門 ー60一 の各部長,及びプロジェクトマネージャのV氏で構成される。プロジェクト運営 委員会は月1回の定例開催に加えて,必要に応じて臨時に開催される。 (6)本プロジェクトに適用されるプロジェクト標準 本プロジェクトには,U社のプロジェクト標準が適用される。プロジェクト標準 の一部を表1に示す。 Rlプロジェクト標準(一部) 要件定義|・検討した各要件に要件IDを付与し,要件定義書に記載する。 2|基本設計|・基本設計書は,“機能設計",“セキュリティ設計",“運用設計"などで構 成される。 ・検討した各設計内容に設計IDを付与し,基本設計書に記載する。 ・要件IDと設計IDを対応付けた表(以下,要件対照表という)を作成 し,基本設計書に添付する。 3|進捗管理|・プロジェクトの各段階のタスクの進捗状況は,タスク管理表に記載し,タ スクが完了するまで管理する。 [基本設計段階の予備調査で把握した事項] システム監査チームは,要件定義段階の監査に続いて,基本設計段階の監査を行 うこととした。まず,予備調査をX年8月下旬に行い,プロジェクト計画書の確認 などによって,次のことを把握した。 (1)基本設計は,X年7月1日に開始した。 (2)基本設計検討会は,V氏を議長とし,システム部及びユーザ部門の各部を代表す る部員で構成される。基本設計検討会の議事録には,開催日時,出席者,検討事 項,検討結果などが記載される。 (3)機能設計では,Webページの構成,情報系システムと基幹系システムとのイン タフェースなどを検討し,その結果を基本設計書に記載する。予備調査の時点で lk,機能設計に関する複数のタスクが未完了であった。 (4)セキュリティ設計では,アクセスの制御,データの暗号化などを検討し,その 結果を基本設計書に記載する。 (5)要件対照表は,X年8月31日までに作成を完了する予定である。 (6)プロジェクト運営委員会はし,プロジェクト標準の内容を充足していることを確 認して,X年10月31日に基本設計の終了を承認する予定である。 [システム監査チームの検討〕 システム監査チームは,基本設計段階の監査について,予備調査の結果を踏まえ て,本調査をX年9月10日14日と計画した。また,監査結果に基づいて基本設 計を見直すことができるよう,監査結果報告をX年|』|と計画した。システ ム監査チームが検討した監査要点及び監査手続の一部を表2に示す。 表2監査要点及び監査手続(一部) 整合していること計IDが記載されていることを確認する。 き,機能が設計されていること計書の“MARE”の内容が,基本設計検討会で の検討結果と整合していることを確認する。 のセキュリティ対策が適切に設計さ計書の“セキュリティ設計”の内容が,セキュリ れていることティ要件を充足していることを確認する。 【内部監査部長の指示] 内部監査部長は,システム監査チームが検討した監査スケジュール,監査要点及 び監査手続をレビューし,次のとおり指示した。 (1)表2項番1の監査手続だけでは,監査要点を確かめるための十分な監査証拠を 入手できないので,追加の監査手続を検討すること。 なお,要件対照表には多数の要件ID及び設計IDが記載されているが,監査要 員,監査時間などには制約があるので,効率的な監査手続とすること。 (2)【基本設計段階の予備調査で把握した事項〕の(3)を考慮すると,表2項番2の 監査手続では,監査要点を確かめるための十分な監査証拠を入手できない可能性 がある。その場合に備えて,追加の監査手続を検討すること。 3)【要件定義段階の監査で把握した事項】の(④を考慮して,本プロジェクトの未 確定要件に関して,表2項番1ご3の監査手続以外に,追加の監査手続を検討する mos ー62一 システム監査チームは,内部監査部長の指示を受けて,表3のとおり追加の監査 手続を策定して,内部監査部長の承認を得た。 表3追加の監査手続 ee 1①①要件対照表に記載されている全ての要件Dを|q|とし ②①でサンプリングした要件Dについての要件定義書の内容と,対 て,要件IDをサンプリングする。 る。 "機能設計"の内容を記載する時期を確認する。