応用情報技術者 2013年 春期 午後 問11
業務で利用する PC及びソフトウェアの管理に関する次の記述を読んで、設問1〜3に答えよ。
Z社は、従業員数約3,000名の総合商社である。営業系・事務系の従業員は一人1台のPCを使用しており、日中だけでなく深夜も海外との折衝を行っている。
〔Z社におけるPC及びソフトウェアの管理状況〕
業務部は、PC及びソフトウェアの管理に関して次の業務を担当している。
(1) 全従業員が統一的に利用するPC、統合型ビジネスソフトウェア、ウイルス対策ソフトウェアなどを社内標準として選定し、一括購入する。
(2) PCの資産管理、業務で利用するソフトウェアのライセンス管理を行う。
(3) 従業員が新たにPCを必要とする場合、事前にPCの標準的な設定を行い、社内標準のソフトウェアの基本セットをインストールした後、利用者に引き渡す。
(4) ①インシデントの連絡の受付、対応及び解決に向けた活動を行う。
業務部は、表1に示すソフトウェア管理台帳を使ってソフトウェアライセンスの購入、貸出し及び返却を管理する手順について、次のとおり定めている。従業員は、自分のPCにソフトウェアを勝手にインストールすることは禁止されている。
(1) 事前にインストールされているもの以外のソフトウェアを利用したい従業員は、ソフトウェア利用申請書(新規)を業務部へ提出する。
(2) 業務部は、申請内容を確認し、ソフトウェアライセンスの在庫確認を行う。ライセンスの在庫がない場合は、ライセンスを購入する。
(3) 業務部は、利用者にライセンスを貸し出し、インストールを許可する。同時に、ソフトウェア管理台帳の貸出し日欄に貸し出した日付を、インストール先PC欄にインストール先のPCのPC資産コードを登録する。
(4) ライセンスを返却する場合、利用者は、ソフトウェア利用申請書(返却)を提出する。業務部は、ソフトウェア管理台帳の該当項目を抹消する。
事前にインストールされた社内標準のソフトウェアの基本セットは、業務部がソフトウェア管理台帳に一括登録している。

〔Z社内で発生したPCに関わるインシデント〕
Z社では、この半年間でPCに関わる重大なインシデントが2件発生した。
(1) 社外に持ち出していたPCのウイルス感染
海外に長期出張していた従業員が、社外に持ち出していたPCを持ち帰り、社内LANに接続したところ、ウイルスに感染していたことが発覚した。出張中に数日間、PCをスタンドアロンで使用した期間があり、ウイルス定義ファイルが最新版でなくなっていた。その状態で滞在先のホテル内のLANを通じてPCをインターネットに接続し、信頼できないサイトにアクセスした時に、ウイルスに感染してしまった。
(2) ソフトウェアライセンス管理の不備
毎月のライセンス棚卸作業で、あるソフトウェアのソフトウェア管理台帳上での貸出ライセンス数が、実際にインストールされている本数よりも多いことが判明した。原因は、PCを廃棄する際に、利用者がソフトウェア利用申請書(返却)を業務部に提出し忘れていたことであった。
その他、インシデントではないが、既に使われなくなったソフトウェアがインストールされたままになっているPCが相当数あり、無駄が生じているという問題もあった。業務部は、ソフトウェアの利用実態までは詳細に把握しきれておらず、従業員が利用申請したときにライセンスの在庫がない場合には、単純に購入していた。
〔検疫ネットワークの構築とPC診断ツールの導入〕
Z社では、インシデントの再発防止策として、次の決定を行った。
(1) 図1に示す検疫ネットワークを新たに構築する。
(2) 利用者のPCの環境設定やインストールされているソフトウェアのバージョン、
パッチなどの対応状況やセキュリティ関連の設定状態を自動的に診断するツール(以下、PC診断ツールという)を導入する。


社内LANへの接続には、DHCP方式を用いる。利用者がPCを社内LANに接続しようとすると、DHCPサーバは検疫ネットワーク用の仮IPアドレスを割り当てる。次に、PCに認証画面を表示し、利用者はログインID(従業員コード)とパスワードを入力する。認証サーバで正しく利用者を認証できれば、PC診断ツールが自動起動して後述の診断を実施し、一定レベル以上の問題がなければ社内LAN用の正式なIPアドレスを割り当てて、社内LANに接続できる。
PC診断ツールは、診断サーバと利用者のPCに事前にインストールされている。診断サーバは、全利用者のPCの前回診断結果情報を保存している。最新のウイルス定義ファイルやパッチは、診断サーバの管理の下、インターネット経由で入手する。利用者は、各自の利用者属性情報(従業員コード、所属部門、内線番号など)とPC属性情報(ハードウェアシリアル番号、PC資産コードなど)をPC診断ツールの初回利用時に登録する。社内の各部門に配置されている部門管理者は、部門サーバを使って部門内利用者の属性管理、セキュリティ管理を行う。情報管理サーバでは、従来のソフトウェア管理台帳をDB化して管理する。PC診断ツールの主な機能を表2に示す。

PC診断ツールによるPCの診断は、次の手順で行われる。
(1) PC診断ツールは、診断対象のPCにインストールされているOSとソフトウェアの製品名、バージョン情報などを収集する。
(2) PC診断ツールは、表2に示した機能に基づいて診断し、診断結果をPC画面に表示する。診断結果には、“○(問題なし)”、“△(注意)”、“×(問題あり)”がある。
(3) 診断結果が“×”又は“△”と判定された場合は、利用者がPC診断ツールのガイドに従ってPCを操作し、診断項目ごとに不適切な状態を修復する。
(4) ②利用者は、最低限“×”の状態を修復され社内LANに接続できる。“△”の状態の修復は利用者に任せられており、事後に修復することが容認されている。
(5) 診断結果は、診断の都度、診断サーバに送られる。部門管理者は、個別に利用者を指定することで、その利用者が使用しているPCの直近の診断結果を参照することができる。
ソフトウェアライセンス管理を強化するために、PC診断ツールをカスタマイズする。ソフトウェアのインストールなど、ライセンスに変更が発生したときにもPC診断ツールを起動し、診断手順の(1)を実行する。診断時にPC属性情報である a とPCにインストールされているソフトウェアの情報を収集し、bサーバ内向けに送り渡す。それらを基に、その都度、ソフトウェア管理台帳DBを更新し、実際にインストールされているライセンス数を集計し直す。PCを廃棄した場合、PC管理台帳DBに廃棄情報が登録されると、ソフトウェア管理台帳DB上の当該PCに関する情報を初期化し、実際にインストールされているライセンス数を集計し直す。
設問1:本文中の下線①について、(1)、(2)に答えよ。
(1)業務部が担当しているこの活動をITILで定義される機能名称で答えよ。
模範解答
サービスデスク
解説
解答の論理構成
- まず、問題文の該当箇所を確認します。業務部の役割として
「①インシデントの連絡の受付、対応及び解決に向けた活動を行う」
と明示されています。 - ITIL では、利用者からの問い合わせや障害報告(インシデント)の“受付窓口”となり、一次対応・エスカレーションを行う機能を「サービスデスク」と呼びます。
- 該当する ITIL 用語を照合すると、インシデントの“連絡の受付”と“対応・解決に向けた活動”を統括するのは「サービスデスク」だけであるため、解答は
― サービスデスク
となります。
誤りやすいポイント
- 「インシデント管理プロセス」と混同する
- インシデント管理はプロセス、サービスデスクは組織的な“機能”という違いがあります。
- 「問題管理」や「運用管理部門」と誤答する
- 問題管理は根本原因分析が主業務で、“受付窓口”ではありません。
- 用語を “ヘルプデスク” と書く
- ITIL 用語では“サービスデスク”が正式名称です。
FAQ
Q: インシデント管理プロセスとサービスデスクの関係は?
A: サービスデスクが利用者窓口となり、インシデント管理プロセスを“実行・統制”する中心的な役割を担います。プロセスは手順、サービスデスクは人と組織の機能という位置付けです。
A: サービスデスクが利用者窓口となり、インシデント管理プロセスを“実行・統制”する中心的な役割を担います。プロセスは手順、サービスデスクは人と組織の機能という位置付けです。
Q: サービスデスクが行う一次対応にはどこまで含まれますか?
A: 電話・メール・Web での受付、影響度の判断、暫定対処、記録、エスカレーション、進捗連絡など利用者への総合的なサポートが含まれます。
A: 電話・メール・Web での受付、影響度の判断、暫定対処、記録、エスカレーション、進捗連絡など利用者への総合的なサポートが含まれます。
Q: ITIL で“ヘルプデスク”は使われないのですか?
A: ITIL v3 以降では“サービスデスク”が正式用語です。“ヘルプデスク”は旧来用語として扱われるか、限定的な技術サポート窓口を指す場合に使われます。
A: ITIL v3 以降では“サービスデスク”が正式用語です。“ヘルプデスク”は旧来用語として扱われるか、限定的な技術サポート窓口を指す場合に使われます。
関連キーワード: インシデント管理, エスカレーション, サービスレベル, 問題管理, プロセス統制
設問1:本文中の下線①について、(1)、(2)に答えよ。
(2)業務部がインシデントの連絡を受け付けた際に、業務部内で解決できない場合は、正確な調査や対応ができる他部署や外部に解決を依頼している。この行動の名称を答えよ。
模範解答
エスカレーション
解説
解答の論理構成
- 【問題文】の下線部には
“①インシデントの連絡の受付、対応及び解決に向けた活動を行う”
と書かれており、業務部がインシデントの一次窓口(サービスデスクに相当)であることが読み取れます。 - 続く設問の説明では、
“業務部内で解決できない場合は、正確な調査や対応ができる他部署や外部に解決を依頼している”
と明示されています。 - 一次窓口が自部門で解決できないインシデントを、より専門的な組織へ依頼する行為は、IT サービスマネジメントや障害対応で一般に「エスカレーション」と呼ばれます。
- したがって、設問で求められている行動の名称は「エスカレーション」と判断できます。
誤りやすいポイント
- “委託”“アウトソーシング”と混同する
→ 他部署・外部へ丸ごと業務を移管するわけではなく、解決するために問題を引き上げる点が異なります。 - “インシデント管理”そのものを答えてしまう
→ 設問は “行動の名称” を聞いているため、管理プロセス全体ではなく個別のアクションを答えるのが正解です。 - “情報共有”“連絡”など一般語で済ませる
→ ITIL などで確立した専門用語「エスカレーション」を使う必要があります。
FAQ
Q: エスカレーションには種類がありますか?
A: はい。管理レベルへ報告・承認を求める「マネジメントエスカレーション」と、技術的な解決力を持つチームへ引き継ぐ「ファンクショナルエスカレーション」に大別されます。設問の文脈は後者です。
A: はい。管理レベルへ報告・承認を求める「マネジメントエスカレーション」と、技術的な解決力を持つチームへ引き継ぐ「ファンクショナルエスカレーション」に大別されます。設問の文脈は後者です。
Q: エスカレーションのタイミングは誰が判断しますか?
A: 一般的には一次窓口(サービスデスク)が、事前に定めた優先度・対応時間の基準に従って判断します。基準を超える場合や自部門のスキル外と判断した時点でエスカレーションを行います。
A: 一般的には一次窓口(サービスデスク)が、事前に定めた優先度・対応時間の基準に従って判断します。基準を超える場合や自部門のスキル外と判断した時点でエスカレーションを行います。
Q: エスカレーションを自動化するツールはありますか?
A: インシデント管理システムやチケット管理ツールには、SLA 監視と連動して自動的に担当部署へ再割当て(エスカレーション)する機能が備わっているものが多数あります。
A: インシデント管理システムやチケット管理ツールには、SLA 監視と連動して自動的に担当部署へ再割当て(エスカレーション)する機能が備わっているものが多数あります。
関連キーワード: インシデント管理, サービスデスク, エスカレーション, 優先度設定, SLA
設問2:
本文中の下線②について、“△”の状態を放置する利用者に対する監視を強化し、修復を促進するために、部門管理者向けに追加すべき機能を、30字以内で述べよ。
模範解答
部門内利用者のPCの“△”の状態について警告する機能
解説
解答の論理構成
-
現状の運用確認
- 本文には、下線部②として
「②利用者は、最低限“×”の状態を修復され社内LANに接続できる。“△”の状態の修復は利用者に任せられており、事後に修復することが容認されている」
とあります。 - さらに「部門管理者は、個別に利用者を指定することで、その利用者が使用しているPCの直近の診断結果を参照することができる。」とも記載されています。
- 本文には、下線部②として
-
問題点の抽出
- “△”は放置可能なため、利用者が修復を怠るリスクがあります。
- 部門管理者は「直近の診断結果を参照」できますが、“△”の放置を速やかに把握・是正する機能は明示されていません。
-
求められる追加機能の導出
- 設問は「“△”の状態を放置する利用者に対する監視を強化し、修復を促進」する部門管理者向け機能を問うています。
- よって、部門管理者が“△”を自動で把握し、注意喚起できる仕組みが妥当です。
-
具体的な機能の言語化
- “△”状態を検出したら部門管理者に通知し、利用者へ修復を催促できる「警告機能」を追加すれば目的を達成できます。
-
解答
- 以上より、模範解答である
「部門内利用者のPCの“△”の状態について警告する機能」
が導かれます。
- 以上より、模範解答である
誤りやすいポイント
- “×”ではなく“△”の監視強化が問われている点を読み違える。
- 部門管理者向け機能なのに利用者側の手順を答えてしまう。
- 「参照はできる」現行機能と「警告する」追加機能を混同し、既に実装済みと誤解する。
- “×”修復の強制を提案し、設問の意図から外れる。
FAQ
Q: “×”と“△”の違いは何ですか?
A: 本文によれば、“×”は「最低限修復しないと社内LANに接続できない」重大な問題、“△”は「接続は許可されるが修復を推奨」される注意事項です。
A: 本文によれば、“×”は「最低限修復しないと社内LANに接続できない」重大な問題、“△”は「接続は許可されるが修復を推奨」される注意事項です。
Q: 既に診断結果が参照できるのに、なぜ追加機能が必要なのですか?
A: 参照は受動的行為であり、部門管理者が自発的に確認しなければ“△”放置を見逃します。警告機能により能動的に監視・指導できます。
A: 参照は受動的行為であり、部門管理者が自発的に確認しなければ“△”放置を見逃します。警告機能により能動的に監視・指導できます。
Q: 利用者自身へ直接アラートを出す機能では不十分ですか?
A: 利用者だけでは放置が続く恐れがあります。管理側にも通知し、組織的に是正を促すことで修復率が向上します。
A: 利用者だけでは放置が続く恐れがあります。管理側にも通知し、組織的に是正を促すことで修復率が向上します。
関連キーワード: 検疫ネットワーク, セキュリティ設定, パッチ管理, アセットマネジメント, アラート通知
設問3:ソフトウェアのライセンス管理について、(1)〜(3)に答えよ。
(1)本文中のa、bに入れる適切な字句を答えよ。
模範解答
a:PC資産コード
b:情報管理
解説
解答の論理構成
-
PC 診断ツールが収集する PC 属性
【問題文】には「利用者は、各自の利用者属性情報(従業員コード、所属部門、内線番号など)とPC属性情報(ハードウェアシリアル番号、PC資産コードなど)をPC診断ツールの初回利用時に登録する。」とあります。
さらにソフトウェア管理台帳では「インストール先PC欄にインストール先のPCのPC資産コードを登録する。」と明記されています。
このように“ライセンスと PC をひも付ける主キー”として一貫して用いられているのは「PC資産コード」です。従って a=「PC資産コード」となります。 -
収集した情報の送信先サーバ
【問題文】には「情報管理サーバでは、従来のソフトウェア管理台帳をDB化して管理する。」と書かれています。
また、a とソフトウェア情報を「bサーバ内向けに送り渡す」とあるため、このサーバはソフトウェア管理台帳DBを保持しているサーバでなければなりません。ここで該当するのは「情報管理サーバ」です。
したがって b=「情報管理」となります。 -
整合性確認
・PC資産コード+ソフトウェア情報 → 情報管理サーバ → ソフトウェア管理台帳DB更新
という流れが【問題文】記載の再発防止策と矛盾なく接続できます。
誤りやすいポイント
- 「ハードウェアシリアル番号」を選んでしまう
物理機器識別には使えますが、台帳や返却手続きに登場するのは一貫して「PC資産コード」です。 - 「診断サーバ」や「部門サーバ」を送信先だと思い込む
診断サーバは診断結果の保存、部門サーバは部門管理用であり、ライセンス台帳の更新主体は「情報管理サーバ」です。 - サーバ名を省略して「○○DB」と書く
設問は“○○サーバ”の名称を聞いており、DB ではありません。
FAQ
Q: PC資産コードとハードウェアシリアル番号はどう使い分けるのですか?
A: PC資産コードは社内で付番した管理用キーで、台帳・ライセンス・廃棄管理に使用します。ハードウェアシリアル番号はメーカー固有番号で、保守や保証確認に利用されます。
A: PC資産コードは社内で付番した管理用キーで、台帳・ライセンス・廃棄管理に使用します。ハードウェアシリアル番号はメーカー固有番号で、保守や保証確認に利用されます。
Q: 情報管理サーバがダウンした場合、診断ツールは機能しなくなりますか?
A: 診断自体はローカルと診断サーバで実行できますが、ライセンス情報の自動更新ができず、貸出数のリアルタイム把握が困難になります。冗長化が望まれます。
A: 診断自体はローカルと診断サーバで実行できますが、ライセンス情報の自動更新ができず、貸出数のリアルタイム把握が困難になります。冗長化が望まれます。
Q: “△”判定を放置したときのリスクは?
A: 設定不備や旧バージョンのまま運用される可能性があり、将来のインシデント発生確率が高まります。部門管理者が定期的に診断結果を確認し、是正を促すことが重要です。
A: 設定不備や旧バージョンのまま運用される可能性があり、将来のインシデント発生確率が高まります。部門管理者が定期的に診断結果を確認し、是正を促すことが重要です。
関連キーワード: 検疫ネットワーク, ライセンス管理, 資産情報収集, パッチ管理, インシデント対応
設問3:ソフトウェアのライセンス管理について、(1)〜(3)に答えよ。
(2)カスタマイズ後のPC診断ツールの仕様では、ライセンス棚卸作業において、実際にインストールされているライセンスの○、特定の時点での本数を把握することが難しい。その理由を、40字以内で述べよ。
模範解答
診断の都度、実際にインストールされているライセンス数を集計し直すから
解説
解答の論理構成
- 問題文には、カスタマイズ後の仕様として
「その都度、ソフトウェア管理台帳DBを更新し、実際にインストールされているライセンス数を集計し直す。」
と明記されています。 - ここでいう「その都度」とは、PC診断ツールを起動するたびに最新情報へ置き換える運用を指します。
- ライセンス棚卸は、ある“特定時点”でのインストール本数を固定的に把握する作業ですが、台帳が随時更新されてしまうと過去のスナップショットが残りません。
- したがって「実際にインストールされているライセンスの本数を把握しづらい」理由は、台帳が“診断のたびに再集計される動的管理”だから、という結論になります。
誤りやすいポイント
- 「集計し直す」という表現を読まず、単に「更新されるから」とだけ書いてしまう。理由の核心は“毎回再集計”にあります。
- PC廃棄時の初期化手順と混同し、「廃棄時に情報が消えるから」と答えてしまう。棚卸作業の難しさは、廃棄ではなく都度更新に起因します。
- 「ライセンスの在庫が変動するから」など在庫管理の話へ逸れてしまう。棚卸は“時点把握”である点が本質です。
FAQ
Q: なぜ「再集計」があると時点把握が難しいのですか?
A: 更新のたびに過去データが上書きされ、固定した数量を参照できなくなるためです。
A: 更新のたびに過去データが上書きされ、固定した数量を参照できなくなるためです。
Q: ログを残せば解決しますか?
A: ログ保存やスナップショット取得の仕組みを導入すれば、点時の本数を抽出しやすくなります。現仕様ではその仕掛けがありません。
A: ログ保存やスナップショット取得の仕組みを導入すれば、点時の本数を抽出しやすくなります。現仕様ではその仕掛けがありません。
Q: 「廃棄情報の登録」も影響しますか?
A: 廃棄時は初期化が行われますが、問題の本質は“診断のたびに”再集計される点です。廃棄の有無にかかわらず時点把握は困難です。
A: 廃棄時は初期化が行われますが、問題の本質は“診断のたびに”再集計される点です。廃棄の有無にかかわらず時点把握は困難です。
関連キーワード: 資産管理, ライセンス監査, 検疫ネットワーク, 自動診断, データベース更新
設問3:ソフトウェアのライセンス管理について、(1)〜(3)に答えよ。
(3)ソフトウェアのライセンス管理の精度が向上し、現在Z社が抱えている問題の対策が進んだ場合に期待できる効果を、35字以内で述べよ。
模範解答
ソフトウェアライセンス数の適正化によるライセンス購入費用の抑制
解説
解答の論理構成
-
現状の課題を整理
- ソフトウェア資産の実態と台帳が乖離
― “ソフトウェア管理台帳上での貸出ライセンス数が、実際にインストールされている本数よりも多い” - 不要ソフトウェアが放置され、ライセンスが遊休化
― “既に使われなくなったソフトウェアがインストールされたままになっているPCが相当数あり、無駄が生じている” - 在庫不足と判断すると“単純に購入”しているため、余剰ライセンスが拡大
- ソフトウェア資産の実態と台帳が乖離
-
対策の内容
- PC診断ツールの“資産情報収集機能”でインストール状況を自動収集
- 収集した“PC属性情報”と“ソフトウェアの情報”を“ソフトウェア管理台帳DB”に送信し、常に最新の実数へ更新
-
期待できる効果の導出
- 実インストール数と台帳数をリアルタイムで突合 → 余剰ライセンスを把握
- 不要ソフトウェアを検出・アンインストール → ライセンスを回収
- 結果として、必要数のみを保有する“適正化”が実現 → 新規購入の発生を抑えられる
-
よって解答は
- 「ソフトウェアライセンス数の適正化によるライセンス購入費用の抑制」となる。
誤りやすいポイント
- コスト以外(セキュリティ向上など)を主効果に挙げてしまう。
- “管理精度向上”を述べるだけで、最終的なビジネス効果(費用削減)に触れない。
- 単に“無駄の削減”と書き、何の無駄かを具体化しない。
FAQ
Q: 台帳更新の自動化で、コンプライアンス違反の防止も効果に入りますか?
A: 付随的には期待できますが、本設問は“問題の対策が進んだ場合に期待できる効果”を聞いており、直接的に表れている費用面を示すのが妥当です。
A: 付随的には期待できますが、本設問は“問題の対策が進んだ場合に期待できる効果”を聞いており、直接的に表れている費用面を示すのが妥当です。
Q: “ライセンス利用効率の向上”でも正しいですか?
A: 方向性は合っていますが、設問では“効果”を聞いているため、効率向上に伴う費用削減まで踏み込んだ表現の方が明確になります。
A: 方向性は合っていますが、設問では“効果”を聞いているため、効率向上に伴う費用削減まで踏み込んだ表現の方が明確になります。
Q: なぜセキュリティ面の効果を前面に出してはいけないのですか?
A: 本文で強調されているソフトウェア管理の課題はライセンス数の過不足と無駄購入です。セキュリティは別の設問で扱われるテーマであり、焦点が異なります。
A: 本文で強調されているソフトウェア管理の課題はライセンス数の過不足と無駄購入です。セキュリティは別の設問で扱われるテーマであり、焦点が異なります。
関連キーワード: ソフトウェア資産管理, ライセンス最適化, 棚卸, コスト削減, 自動インベントリ


