平成27年度 秋期 午後Ⅰ

本文の根拠

〔IT 資産管理の概要〕

PC 管理者は，情報システム部から四半期ごとに配付される棚卸調査表に基づいて，PC の棚卸，及び PC に導入されている業務用ソフトウェアの棚卸を実施し，結果を情報システム部に報告している。

〔IT 資産管理の精度向上〕

エージェントプログラムは，PC から資産管理台帳の作成に必要な情報を収集する。

〔IT 資産管理の精度向上〕

エージェントプログラムで収集した情報は，社内 LAN 接続中に，資産管理システムが稼働している管理用サーバ（以下，資産管理サーバという）に送信され，資産管理台帳に登録される。

下線（ア）が除かれているので，精度の向上・利用規程の遵守・セキュリティの強化・適切なライセンスの購入は答えにならない。残るのは手間の話である。

現在，PC管理者は四半期ごとに棚卸調査表を受け取り，PCと業務用ソフトウェアを1台ずつ調べて報告している。20支店ぶん，約1,000台が対象なので，まとまった作業量になる。

資産管理システムでは，エージェントプログラムが情報を集め，社内LANに接続しているあいだに自動で台帳へ登録される。人が調べて回る必要がなくなる。

20字。解答例は「IT資産管理に関わる作業工数の低減」で16字。誰の作業が減るのかを意識して，PC管理者の棚卸作業と書いてもよい。

採点講評（IPA）

設問1は，正答率が低かった。システム化によってIT資産管理の精度向上を狙えるだけでなく，PC管理者の棚卸作業の工数が低減できることを認識してほしかった。

本文の根拠

〔IT 資産管理の概要〕

情報システム部は，ソフトウェアが導入された PC の PC 管理番号をソフトウェア管理台帳に登録し，基本ライセンスの使用数を管理している。

〔IT 資産管理状況の監査〕

ソフトウェア管理台帳に登録されている基本ライセンス使用先の PC 管理番号と，実際にソフトウェアを導入している PC の PC 管理番号の不一致が散見された。

〔IT 資産管理の精度向上〕

情報システム部は，PC 管理システムと資産管理システムを使って，日次で定刻にバッチ処理を行い

バッチ処理は「PC管理システムと資産管理システムを使って」行うと書いてある。2つのシステムを使うのだから，それぞれの台帳を突き合わせる処理になる。

持っているものが違う。ソフトウェア管理台帳（PC管理システム側）には，申請を経て許可されたPCの管理番号が載っている。資産管理台帳（資産管理システム側）には，エージェントが集めてきた実際に導入されているPCの情報が載っている。

調査で見つかった問題も，まさにこの2つのPC管理番号の不一致だった。これまでは四半期に一度の棚卸でしか気づけなかったものを，日次で照合して通知する。

50字。解答例は「ソフトウェア管理台帳と資産管理台帳とのソフトウェアごとのPC管理番号の不一致の状況」で41字。

資産管理台帳だけから分かること（マルウェアの感染状況など）を答えると，2つのシステムを使う意味が説明できない。

採点講評（IPA）

設問2は，IT資産管理の精度向上に関わるシステム面からの対策を出題した。資産管理台帳から得られるマルウェア感染の有無などを指摘する誤った解答があったが，二つのシステムの管理台帳を使って行う照合処理の内容を解答してほしかった。

本文の根拠

〔業務用ソフトウェアの利用規程の遵守〕

情報システム部は，申請内容を確認し，不備があった場合は利用申請を差し戻し，不備がなかった場合は a し，利用申請を受理する。ここで，当該ソフトウェアの使用数が，既に，契約上の基本ライセンス数に達しているときは，契約を更新し，基本ライセンス数を追加する。

〔IT 資産管理の概要〕

ソフトウェアを使用するには，使用数に応じた基本ライセンスが必要であり，使用許諾契約（以下，契約という）を締結して使用数を取り決める。

空欄aの直後が手がかりになる。「ここで，当該ソフトウェアの使用数が，既に，契約上の基本ライセンス数に達しているときは」と続くので，空欄aで使用数を調べていることが分かる。

使用数はどこにあるか。本文のとおり，情報システム部はソフトウェアが導入されたPCの管理番号をソフトウェア管理台帳に登録して，基本ライセンスの使用数を管理している。だから確認先はソフトウェア管理台帳である。

設問が「確認方法とともに」と言っているので，何を確認するか（基本ライセンスの利用状況）と，どこで確認するか（ソフトウェア管理台帳）の両方を書く。

30字。解答例は「基本ライセンスの利用状況をソフトウェア管理台帳で確認」で26字。

本文の根拠

〔IT 資産管理状況の監査〕

インターネットに接続して販売元 Web サイトからダウンロードして利用する手順になっている業務用ソフトウェアを，誤って別の Web サイトに接続してダウンロードし，マルウェアに感染してしまった事例が確認された。

〔業務用ソフトウェアの利用規程の遵守〕

情報システム部では，当該ソフトウェアの配付用写しを社内のファイルサーバに準備しておく。

設問が「版を確実に使うこと以外に」と断っているので，もう1つの狙いを探す。手がかりは調査で見つかった事例である。

これまでは各自がインターネットに出て，販売元のWebサイトからダウンロードしていた。その途中で別のサイトにつないでしまい，マルウェアに感染した事例があった。Q氏が「セキュリティの強化」を挙げたのもここが理由である。

社内のファイルサーバに写しを置けば，そもそもインターネットへ出る必要がない。偽サイトに誘導される余地が消える。

40字。解答例は「インターネット接続する場合に起きる可能性のあるマルウェアの侵入を防ぐため」で35字。フィッシングサイトへの誘導という言い方でもよい。

採点講評（IPA）

設問3(2)及び設問4(1)は，IT資産管理のセキュリティ分野から出題した。マルウェアからの保護及び利用者アクセスの管理については，理解されているようであった。

本文の根拠

〔IT 資産管理の概要〕

ソフトウェアを使用するには，使用数に応じた基本ライセンスが必要であり，使用許諾契約（以下，契約という）を締結して使用数を取り決める。

〔IT 資産管理状況の監査〕

基本ライセンスの過剰購入によって，余分な費用が発生している

監査人の指摘は「基本ライセンスの過剰購入によって余分な費用が発生している」で，これは除外されている。つまり多すぎる側ではなく，足りない側のリスクを答える。

申請せずに導入すると，その使用分はソフトウェア管理台帳に載らない。台帳上の使用数より，実際に使われている数のほうが多くなる。

使用数は契約で取り決めたものなので，そこを超えて使えば使用許諾契約の違反になる。損害賠償や利用停止につながる話で，費用の無駄とは性質が違う。

20字。解答例は「基本ライセンスに関する契約違反となる。」で18字。設問が「ライセンス管理の観点から」と限っているので，マルウェア感染などセキュリティ面の話はここでは答えない。

本文の根拠

〔個人所有の PC を使った社内業務の開始〕

使用できる個人所有の PC は，社内 LAN に接続できるネットワークアダプタ内蔵のノートブック PC に限定する。申請書の項目は次のとおりである。申請理由，利用者社員情報，PC 機種名，OS 名称，OS の版，MAC アドレス。

表1

ハードウェア資産：PC 管理番号，ディスク容量，メモリ容量，MAC アドレス。

申請書の項目を並べると，PC機種名もOS名称もOSの版も，同じ値をもつPCが何台も存在する。個体を指せるのはMACアドレスだけである。ネットワークアダプタごとに固有の番号だからである。

個人所有のPCなので，会社が配ったPCと違って，申請していないPCを持ち込むことができてしまう。社内LANにつないできたPCのMACアドレスと申請書の値を突き合わせれば，承認されたPCかどうかを判定できる。

表1のハードウェア資産にもMACアドレスがあるので，資産管理台帳の側と突き合わせる形にもできる。

40字。解答例は「社内LANに接続するPCが申請したものと一致するか判断するため」で31字。「PCを特定するため」だけでは，特定して何をするのかが言えていない。

本文の根拠

〔IT 資産管理の精度向上〕

資産管理システムは，資産管理サーバで稼働するサーバプログラムと PC で稼働するエージェントプログラムで構成される。エージェントプログラムは，PC から資産管理台帳の作成に必要な情報を収集する。

〔IT 資産管理の精度向上〕

社内 LAN に接続された PC から，一定時間内に収集情報が送信されなかった場合，資産管理システムは警告メッセージを情報システム部に通知する。

個人所有のPCであっても，社内LANにつないで業務を行う以上，会社のPCと同じようにIT資産管理の対象にしなければならない。どんなソフトウェアが入っているか，セキュリティパッチが当たっているか，マルウェアに感染していないかを把握する必要がある。

それを集めるのがエージェントプログラムである。入っていなければ情報が上がってこない。しかも本文のとおり，社内LANに接続しているのに一定時間内に収集情報が送られてこないと，資産管理システムが警告を出す仕組みになっている。入れずに接続すれば，そのたびに警告が鳴ることになる。

20字。解答例は「エージェントプログラム」で11字。マルウェア対策用ソフトウェアはすでに直前に挙がっているので，重ねて書かない。

本文の根拠

計算式

呼量 ＝ 平均利用時間 × 平均呼数

〔サービス窓口の計算〕

平均利用時間（単位：時間）とは，問合せ及び回答で利用する 1 回当たりの通話時間である。また，平均呼数とは，1 時間当たりの電話受付数である。

〔サービス窓口の計算〕

2 次回答を必要とする問合せがあることから，平均問合せ件数の 1.5 倍を平均呼数とする。

〔生産管理システムの更新〕

T 氏はサービス利用部門と調整し，生産管理システムの“来期の平均問合せ件数の見通し”を 8 と見積もった。

変わるのは生産管理システムの件数だけである。表4の4が8になり，受注発送の5と会計の3はそのまま。来期の平均問合せ件数は 8 ＋ 5 ＋ 3 ＝ 16。

平均呼数は1.5倍なので 16 × 1.5 ＝ 24。

平均利用時間は5分だが，式は時間単位なので 5 ÷ 60 時間に直す。

呼量 ＝ 5 ÷ 60 × 24 ＝ 2アーラン。

分に直し忘れると120という値になる。今期の数字で検算できる。12 × 1.5 ＝ 18，5 ÷ 60 × 18 ＝ 1.5で，本文の「呼量は1.5アーランとなる」と一致する。

本文の根拠

〔生産管理システムの更新〕

来期からは，SLA で呼損率の目標値が 3％以下に変更される。

表3

呼損率 3％のとき，席数 1 から 8 に対して 0.03，0.28，0.72，1.26，1.88，2.54，3.25，3.99。

呼損率の目標値が5％から3％へ変わる点に注意する。表3の読む行が変わる。

呼損率3％の行を左から見ていき，呼量2アーランを収容できる最初の席数を探す。席数5では1.88で2に届かない。席数6で2.54となり2を上回る。したがって6席。

表3の値は「その席数で，その呼損率に収まる最大の呼量」である。だから求める呼量以上になる最初の席数を選ぶ。1.88のほうが2に近いからと席数5を選ぶと，呼損率が3％を超えてしまう。

今期の4席から2席増える。呼量が1.5から2へ増えたことと，目標値が3％へ厳しくなったことの両方が効いている。

本文の根拠

〔段階的取扱い作業の調査〕

サービスデスク内で解決した場合は，目標値を大きく達成している状態であったのに対し，段階的取扱いを行った場合は，もう少しで目標値の達成が難しい状態であった。

〔段階的取扱い作業の調査〕

システム保守課では生産管理システムなどの業務ソフトウェアの保守作業は，主要業務として計画的に実施しているが，サービスデスクからの依頼に基づく調査活動は，支援業務として副次的に取り扱われていることが分かった。

表2 注1

サービスデスクは，SLA の回答完了時間と整合を図った回答期限を設定する。

回答完了時間はどれもSLAを達成している。それでも段階的取扱いのときだけ余裕がない，という差が出ている。差の出どころはシステム保守課である。

システム保守課では，保守作業が主要業務として計画的に実施される一方，サービスデスクからの調査依頼は支援業務として副次的に扱われている。計画に入っていない仕事は後回しになりやすい。

回答期限はSLAの回答完了時間と整合を図って設定されているので，回答期限を守れるかどうかがSLAを守れるかどうかに直結する。したがって調べるのは，システム保守課で依頼がどういう優先度で扱われているか，回答期限をどれだけ守れているか，守れないときの理由は何か，といった点になる。

40字。解答例は「システム保守課におけるサービスデスクから依頼された問合せへの優先度の扱い」で35字。主要業務と支援業務の割合，回答期限の遵守率と守れない理由，という切り口でもよい。

採点講評（IPA）

設問2(1)は，正答率が低かった。サービスデスクに関わるSLA目標値を意識して解答してほしかった。

本文の根拠

〔段階的取扱い作業の調査〕

サービスデスクは，管理課と情報システム部内の支援協定である運用レベル合意書を締結し，SLA の目標値を達成するための活動を行っている。

〔段階的取扱い作業の調査〕

段階的取扱いが必要な場合に，回答期限を過ぎたときは，システム保守課に対処方法の回答を催促している。

表2 注1

サービスデスクは，SLA の回答完了時間と整合を図った回答期限を設定する。

いま運用レベル合意書があるのは，サービスデスクと管理課の間だけである。システム保守課との間には何もないので，回答期限は守ってもらう約束ではなく，過ぎたら催促するだけのものになっている。

新たに結ぶ合意書に書くべきは，この回答期限である。サービス目標値として定めれば，催促に頼らず守るべきものとして扱われる。

値の根拠はSLAにある。回答期限はSLAの回答完了時間と整合を図って設定されているので，顧客との約束（SLA）を，内部の約束（運用レベル合意書）で支える形になる。

40字。解答例は「サービスデスクから依頼された調査の回答期限に関するサービス目標値の合意事項」で36字。遵守率100％という具体的な値の形で書いてもよい。

採点講評（IPA）

設問2(2)は，正答率が高かった。サービス提供者と内部グループで結ばれる運用レベル合意書（OLA）とSLAとの間で整合を図ることの重要性は，理解されていると思われる。

本文の根拠

〔サービス提供時間帯拡大の要望〕

現在のオペレータ要員体制ではサービス提供時間帯を拡大できないので，よくある問合せとその解決策を FAQ として整備し，要望があった利用部門に提供した。

〔サービス提供時間帯拡大の要望〕

FAQ の利用は，サービス利用者の一部に限られていたが，FAQ は，ある程度有効に機能していることが分かった。

いまFAQを渡しているのは要望のあった利用部門だけで，利用も一部にとどまっている。社内のWebに公開すれば，全社の利用者が見られるようになる。

ただし，置いただけでは今と変わらない。一部しか使わない状態が続くので，利用を勧める活動が要る。設問が「実施すべき活動内容とともに」と言っているのはここを書かせるためである。

利点は，利用者が自分で解決できるぶんサービスデスクへの問合せが減ることである。要員を増やせないという制約は変わらないので，入ってくる件数のほうを減らす。利用者から見れば，サービス提供時間帯の外でも自分で解決できるようになる，という言い方もできる。

50字。解答例は「サービス利用部門にFAQの利用を推奨することによって，サービスデスクが扱う問合せ件数が減少する。」で47字。活動と利点の両方を入れる。

本文の根拠

表2 終了

終了：a。回答内容などの記録を更新し，終了する。

〔顧客満足度の調査〕

サービスデスクの回答に従って操作しても解決できず，再度問い合わせることになった。

表1 注1

問合せを受け付けてから解決までの経過時間。

利用者の声は「回答に従って操作しても解決できず，再度問い合わせることになった」である。回答は出しているが，そのとおりにやって直ったかどうかを確かめていない。

T氏が「手順に従って作業をしているか」を調べようとしている，ということは，手順の側には確かめる作業が書いてあるはずである。それが空欄aになる。

SLAの回答完了時間も「問合せを受け付けてから解決までの経過時間」と定義されている。解決を確認しなければ，いつ終わったのかも決められない。手順“解決”で回答し，手順“終了”で解決を確認する，という並びである。

40字。解答例は「利用者が回答に基づき対処を行い，問合せが解決したことを確認する。」で31字。「利用者に確認する」だけでなく，何を確認するのか（解決したこと）まで書く。

採点講評（IPA）

設問4では，手順書を更新するなど，サービスデスク内の管理プロセスの改善と誤って解答した受験者が多かった。利用者からの問合せに着実に回答するとともに，解決を確認することが必要であることを意識してほしい。

本文の根拠

表2 販売管理システム

毎日 2 時，8 時，14 時及び 20 時にバッチ処理を自動起動し，注文情報を生産管理サーバに送信する。バッチ処理の対象は，該当するバッチ処理直前の 6 時間で作成された注文情報である。バッチ処理時間は 10 分以内である。

表2 例2

例2）2 時のバッチ処理は，前日 20 時から当日 2 時までに作成された注文情報を対象とする。

表3

1 時 00 分：現システムで「注文のオンライン処理終了」「バッチ処理の自動起動を停止」，新システムは－，10 分。

移行は1時から4時までで，1時00分にバッチ処理の自動起動を停止している。この時間帯に本来動くはずだったものを探す。

販売管理システムは2時に，注文情報を生産管理サーバへ送るバッチ処理を自動起動している。自動起動を止めたままだと，このバッチ処理が実行されない。前日20時から1時までに作られた注文情報が生産管理システムへ渡らず，工場の生産計画に反映されない。

だから1時10分に手動で実行しておく。所要時間が10分とされているのも，表2の「バッチ処理時間は10分以内である」と合う。

40字。解答例は「前日20時から作成されている注文情報を生産管理システムに送信」で30字。対象がどこからの注文情報かまで書けると確かである。

本文の根拠

表2 販売管理システム

生産管理サーバから生産実績情報を受信したときは，バッチ処理が自動的に起動される。バッチ処理では，在庫情報を更新する。

表3

3 時 00 分：現システムは－，新システムで「生産管理システムから取得した生産実績情報をバッチ処理で反映」，30 分。

生産管理システムとの連携は双方向である。生産管理システムから生産実績情報を受け取る向きと，生産管理システムへ注文情報を送る向きの2つがある。

受け取る向きは，表3の3時00分に移行作業の一部として実施し，そのあとの移行確認試験で確かめている。移行日のうちに確認が済む。

送る向きはそうはいかない。注文情報を送るバッチ処理は2時・8時・14時・20時に動くので，移行後の最初の実行は8時である。移行作業の時間帯には確かめようがない。だから初期サポート活動の確認項目に入れる。

40字。解答例は「注文情報を販売管理サーバから生産管理サーバに正常に送信できている。」で32字。移行作業中に確認済みの受信側を書くと，わざわざ初期サポートで見る意味がない。

本文の根拠

表3

3 時 55 分：現システムで「（移行結果が“不可”と判定された場合）現システムでオンライン処理開始」，新システムで「（移行結果が“可”と判定された場合）新システムでオンライン処理開始」，5 分。

〔販売管理システムの移行計画〕

移行作業時間として 3 時間必要なので，移行日の 1 時から 4 時まで販売管理システムを停止する移行計画案を策定した。

表1

可用性のサービス時間：24 時間 365 日（計画停止を除く）。

部長の指摘は「計画どおりに作業が進まなかった場合」，つまり移行結果が“不可”と判定されて現システムへ切り戻す場合である。

表3の3時00分の作業をもう一度見る。「生産管理システムから取得した生産実績情報をバッチ処理で反映」は，新システムでしか行っていない。現システムには反映されていない。

したがって切り戻すときは，現システムでも同じ反映を行わなければならず，30分が丸ごと余分にかかる。オンライン処理の開始は4時を過ぎる。計画停止は1時から4時までと営業部に了承を得たものなので，それを超えれば表1のサービス時間を割ることになる。

40字。解答例は「移行結果が“不可”と判定され切り戻しを行う場合に，サービス開始時刻が遅れる。」で37字。SLAを満たさなくなる，という言い方でもよい。設問が「理由とともに」と言っているので，切り戻す場合という条件を必ず入れる。

採点講評（IPA）

設問3では，安易に移行作業時間を延長すると誤って解答した受験者が多かった。利用者への影響を最小限にするためには，限られた時間の中で取り得る対策がないかを検討するよう意識してほしい。

本文の根拠

表3

3 時 00 分：現システムは－，新システムで「生産管理システムから取得した生産実績情報をバッチ処理で反映」，30 分。

表2 販売管理システム

生産管理サーバから生産実績情報を受信したときは，バッチ処理が自動的に起動される。バッチ処理では，在庫情報を更新する。

切り戻しに時間がかかるのは，現システムだけ生産実績情報が反映されていないからである。ならば移行作業のうちに，現システムにも反映しておけばよい。

そうしておけば，“不可”と判定されてもそのままオンライン処理を始められる。3時55分から5分で開始でき，4時に間に合う。

新システムでの作業と並行して行えるので，移行作業全体の時間が延びるわけでもない。

30字。解答例は「現販売管理システムにも生産実績情報を反映させておく。」で25字。移行作業時間を延ばす，判定を早める，といった答えでは，1時から4時という枠を営業部と合意している以上，そのままでは通らない。

採点講評（IPA）

設問3では，安易に移行作業時間を延長すると誤って解答した受験者が多かった。利用者への影響を最小限にするためには，限られた時間の中で取り得る対策がないかを検討するよう意識してほしい。

本文の根拠

〔販売管理システムの移行計画〕

既に移行を完了した生産管理システムでは，移行後初日から 5 日間は，1 日当たりに発生するインシデント数が移行前の 1 日当たりに発生するインシデント数の平均値よりも多く，6 日目以降は移行前のインシデント数と同程度となった。そこで，K 氏は，生産管理システムの状況を参考にして，販売管理システムの初期サポート活動期間を移行後 5 日間とした。

〔システム移行の概要〕

社内だけで利用している生産管理システムを最初に移行し，その後，小売店が利用している販売管理システムを移行することにした。

〔販売管理システムの移行〕

1 日当たりに発生するインシデント数が移行前の 1 日当たりに発生するインシデント数の平均値よりも多い状態が続いていること

期間を「5日間」と日数で決め打ちしたことが問題である。根拠にしたのは生産管理システムの実績だが，2つのシステムは条件が違う。生産管理システムは社内だけで使うのに対し，販売管理システムは小売店も使い，しかも今回は機能改善まで入っている。同じ日数で収まる保証はない。

実際，5日を過ぎてもインシデント数は移行前の水準に戻っていない。

K氏が生産管理システムで見ていたのは，本当は日数ではなく「インシデント数が移行前と同程度になった」という状態のほうである。そこを終了基準に据える。安定したかどうかで終わりを決めれば，システムごとの違いを吸収できる。

40字。解答例は「初期サポート活動の終了時期は，インシデントの発生状況を加味して判断する。」で35字。「期間を長くする」では，何日にすればよいのかという同じ問題が残る。

採点講評（IPA）

設問4(1)は，正答率が低かった。リリース後の初期サポート計画は，システムの特性に応じて計画する必要があり，新システムがどのような状態になったときに安定稼働に達したと判断して初期サポートを終了するのか，終了基準についてを検討するようにしてほしい。

本文の根拠

〔販売管理システムの移行計画〕

展開チームは，移行後に想定されるよくある問合せとその回答を FAQ として事前に作成し，サービスデスクに引き継ぐ。

〔販売管理システムの移行〕

展開チームは，暫定的な回避策を作成してインシデントに対応した。利用者からの問合せに対しては，サービスデスクから依頼を受けて展開チームが回答した。

〔販売管理システムの移行〕

事前に引き継いだ FAQ だけではサービスデスクで対応できない問合せが度々発生している状況であることから

いまサービスデスクが持っているFAQは，移行前に「想定される」問合せで作ったものである。実際に起きたことは入っていないので，対応しきれないのは当然である。

一方で展開チームは，発生したインシデントに暫定的な回避策を作り，サービスデスクからの依頼を受けて利用者にも回答している。答えはすでに出ているのに，サービスデスクの手元には残っていない。

そこで，初期サポート活動のあいだに，作った回避策と実際の回答をFAQへ足していく。初期サポート活動はいずれ終わり，展開チームは離れるので，その前にサービスデスクが自力で答えられる形にしておく必要がある。

40字。解答例は「展開チームが初期サポート活動で実施した回避策をFAQに反映し，整備する。」で35字。

採点講評（IPA）

設問4(2)は，正答率が高かった。展開チームの対応内容をFAQに反映することの必要性は，理解されているようであった。