応用情報技術者 2017年 春期 午後 問09
システムの移行レビューに関する次の記述を読んで、設問1、2に答えよ
P社は、家電量販店を営む会社である。約20店舗での店頭販売に加え、インターネットや電話による通信販売を行っている。電話応対は、コールセンタに勤務する約50名のオペレータが、商品の注文受付、問合せ対応などの業務を行っている。
〔コールセンタの新 CTI システム開発プロジェクトの概要〕
現在P社で運用しているコールセンタのシステム(以下、現行システムという)は、コンピュータと電話を統合したCTIシステムであり、Q社が提供するソフトウェアパッケージ(以下、現行パッケージという)を導入している。現行システムは、顧客の属性情報や購買履歴などを管理するCRMシステムや商品在庫管理システムなどの関連システムと、オンライン処理又はバッチ処理でデータ連携している。
現行システムのハードウェアが年度末に保守期限を迎えるので、Q社が新たに開発したソフトウェアパッケージ(以下、新パッケージという)に更改することを決め、新CTIシステム(以下、新システムという)開発プロジェクトを立ち上げた。プロジェクトマネージャにはシステム部開発課のX課長が選任された。プロジェクトのスコープは、現行パッケージに施されていたP社独自のカスタマイズを新パッケージに取り込んで導入すること、及び既存の関連システムとデータ連携できるようにすることである。
今回、新たなP社独自のカスタマイズ要件はない。新パッケージでは、主要なデータベース(以下、DBという)の一つである顧客属性管理テーブルの一部のコードの値が細分化された。新システムでは、新パッケージのコードの値を使用するが、今回は関連システムとの接続仕様を変更せず、新パッケージのコードの値を現行パッケージのコードの値に変換してから関連システムに引き渡すことにした。新パッケージで細分化されたコードの値の例を、図1に示す。

〔移行判定会議の開催と報告〕
プロジェクトは順調に進み、システム適格性確認テスト(以下、システムテストという)、運用者による受入れテスト(以下、運用テストという)及び利用者による受入れテストが終了したので、新システムへの移行の可否を判定する会議(以下、移行判定会議という)を開催することになった。X課長は、前工程のソフトウェア適格性確認テストの終了判定会議への出席者に加え、プロジェクトオーナーであるE常務、プロジェクト責任者であるシステム部のF部長、営業部のG部長、及び①コールセンタの責任者であるHセンタ長に出席を依頼するように、部下のW君に指示した。
移行判定会議では、各担当リーダから次のとおり報告があった。
(1) システムテストの実施結果及び評価(報告者:X課長)
・システムテストの実施と検証、及び検出したバグの対応を完了した。バグ検出件数、バグ検出密度ともP社の品質基準を満たした。バグの検出状況を分析した結果、異常はなかった。
・システムテストは、新システムが稼働を予定している環境を使用して実施した。性能テストでは、関連システムも時間帯を調整して稼働環境を使用する予定であったが、商品在庫管理システムだけは時間帯の調整ができなかった。商品在庫管理システムのテスト環境の構成を調べたところ、性能テストをテスト環境で実施しても問題ないと判断できたので、稼働環境と同一のソフトウェアとDBをコピーしてテストを行った。
・業務機能のテストでは、業務要件に基づく業務フローの正当性を、関連システムを含めて検証した。さらに、新システムで現行機能が正しく動作することを保証するために、新パッケージにおけるコードの値の細分化を考慮した上で現行システムと新システムに同一データを投入し、主要なテーブルの処理結果を比較した。②顧客属性管理テーブルのコードの値を自動的に比較するために、比較検証ツールを作成して検証を行った。結果は良好であった。
・性能要件やデータボリューム要件など、a を満たしていることを検証するテストでの実測結果は目標値を満たし、システム全体の処理性能やデータボリュームに関する問題はなかった。
・新システムのメンテナンスマニュアルを整備し、保守チームに引き継いだ。
(2) 運用テストの評価(報告者:システム部運用課C課長)
・システム部運用課の担当者も参加してテストを行い、結果は良好であった。
・新システムの運用スケジュール、手順書、障害発生時の連絡体制など、必要なドキュメントを全て作成し、システム運用担当者に説明済みである。
(3) 利用者による受入れテストの評価(報告者:X課長、コールセンタDリーダ)
・顧客属性管理画面のレイアウトが見づらいなどの指摘が2件あった。業務運用への影響は軽微なので、稼働後にプログラムを改修することを条件にHセンタ長から了承を得た。これらは、申し送り事項として管理する(X課長)。
・新システムを使用して業務運用を行った。新パッケージの新機能や関連システムとの連動処理など、全ての業務を問題なく実施することができた(Dリーダ)。
(4) 利用者訓練の状況と評価(報告者:Dリーダ)
・コールセンタのオペレータの運用訓練を完了した。訓練のカリキュラムに従った業務運用を行い、参加者全員が一定の水準に達したことを確認した。
・新システムの業務オペレーションマニュアルを整備した。
(5) 移行計画(報告者:X課長)
・稼働開始前日の業務終了後、現行システムから新システムへ移行する。
・稼働開始日の午前9時に、新システムのサービスを開始する。
・移行作業に必要な時間は、十分に確保している。
・新システムの稼働開始日に、現行システムの運用を停止する。
(6) b 達成度確認(報告者:F部長)
・新システムの品質と性能、利用者の業務運用の習得度が、移行可能な基準に達しており、移行作業の準備が十分であることを確認した。
〔移行判定会議での指摘事項〕
各担当リーダからの報告後、次の質疑応答があった。
G部長:新システムへの移行及び稼働開始時に、不測の事故が発生した場合のcその発動条件を定めていますか。
X課長:はい。G部長に承認していただいたものを、文書化して共有しています。
F部長:性能テストで、商品在庫管理システムはテスト環境を使って実施しても問題ないと判断した理由を説明してください。
X課長:商品在庫管理システムのテスト環境の構成を調べ、d であることを確認できたからです。
F部長:③新システムの稼働後に行うランステム関連作業を整理してください。
X課長:承知しました。引継ぎが必要な場合は、打合せを設定します。
E常務は、会議の報告内容と b の達成度から、新システムの移行までに対応すべき課題を解決することを条件に、新システムへの移行を承認した。
また、X課長は、Y 部長からの指摘を受けて、新システムが安定稼働していることを確認した後に実施すべきである e の計画を策定することにした。そこで、運用及び保守の組織だけでなく利用者も参加させて、この活動を開始した。
設問1:〔移行判定会議の開催と報告〕について、(1)~(3)に答えよ。
(1)本文中の下線①について、X課長がHセンタ長を移行判定会議の出席者に選定した理由を、解答群の中から二つ選び、記号で答えよ。
解答群
ア:オペレータが新システムで業務を行えると判断したことを報告するから
イ:コールセンタ業務への指摘事項に対するシステムへの改修を指示するから
ウ:新システム稼働後の顧客満足の向上施策結果を報告するから
エ:利用者による受入れテストの評価に基づいて、システム品質が妥当であると判断したことを報告するから
オ:利用部門の責任者として、新システムへの業務要件を要求するから
模範解答
ア、エ
解説
解答の論理構成
-
出席依頼の対象
【問題文】には「①コールセンタの責任者であるHセンタ長に出席を依頼する」と明記されています。Hセンタ長は利用部門のトップであり、コールセンタ業務に関する最終判断者です。 -
オペレータが新システムで業務を行えるかの確認
利用者訓練について「コールセンタのオペレータの運用訓練を完了した。…参加者全員が一定の水準に達したことを確認した」と報告されています。訓練結果を踏まえ、オペレータが実運用可能であることを利用部門責任者が保証・報告する必要があります。これは解答群「ア:オペレータが新システムで業務を行えると判断したことを報告するから」に一致します。 -
受入れテストの品質判断
利用者による受入れテストでは「稼働後にプログラムを改修することを条件にHセンタ長から了承を得た」とあり、Hセンタ長はテスト結果に基づいてシステム品質が許容範囲であると判断しています。この判断を移行判定会議で正式に示すため、解答群「エ:利用者による受入れテストの評価に基づいて、システム品質が妥当であると判断したことを報告するから」が適切です。 -
他の選択肢が不適切な理由
・イ:改修指示はX課長が行う役割であり、Hセンタ長の出席理由とは異なります。
・ウ:稼働後の顧客満足向上施策は会議範囲外です。
・オ:追加の業務要件は今回は存在せず、出席目的ではありません。
以上より、適切な選択肢は「ア」と「エ」です。
誤りやすいポイント
- 「利用者訓練完了=Hセンタ長は不要」と早合点し、アを外してしまう。
- 「改修指示」を“利用部門の責任者が行う”と考えイを選ぶが、実際には改修管理はプロジェクト側の責務。
- 受入れテストの品質判断が誰の責任かを混同し、エを見落とす。
FAQ
Q: 利用者訓練が完了していればHセンタ長は出席しなくてもよいのでは?
A: 訓練結果を公式に報告し、利用部門として「業務遂行に支障なし」と保証する役割があるため出席が必要です。
A: 訓練結果を公式に報告し、利用部門として「業務遂行に支障なし」と保証する役割があるため出席が必要です。
Q: 改修が必要な指摘事項がある場合、イは該当しないのですか?
A: 改修指示自体はプロジェクト側(X課長)が管理し、Hセンタ長は承認者として立ち会うだけなので出席理由の主目的ではありません。
A: 改修指示自体はプロジェクト側(X課長)が管理し、Hセンタ長は承認者として立ち会うだけなので出席理由の主目的ではありません。
Q: 追加要件がなくても利用部門責任者は要件提示をするのでは?
A: 今回のスコープで「新たなP社独自のカスタマイズ要件はない」と示されており、要件提示は議題に含まれていません。
A: 今回のスコープで「新たなP社独自のカスタマイズ要件はない」と示されており、要件提示は議題に含まれていません。
関連キーワード: 受入れテスト, 運用訓練, 品質保証, CTIシステム, 移行判定
設問1:〔移行判定会議の開催と報告〕について、(1)~(3)に答えよ。
(2)本文中の下線②について、比較検証ツールの機能仕様を40字以内で述べよ。
模範解答
新パッケージのコードの値を現行パッケージのコードの値に変換する。
解説
解答の論理構成
- 【問題文】には、比較検証ツールについて
「②顧客属性管理テーブルのコードの値を自動的に比較するために、比較検証ツールを作成して検証を行った」とあります。 - さらに同段落では、
「新パッケージにおけるコードの値の細分化を考慮した上で現行システムと新システムに同一データを投入し、主要なテーブルの処理結果を比較した。」と述べています。 - 図1に示された細分化例では、現行パッケージのコード「10」に対し、新パッケージは「11」「12」へ細分されています。
- このように粒度が異なる両システムのデータを正しく比較するには、
新パッケージ側のコード値を現行パッケージ側へ“集約”しなければ対応付けが取れません。 - したがって、比較検証ツールの核心機能は
「新パッケージのコードの値を現行パッケージのコードの値に変換」し、そのうえでテーブル内容を自動比較することになります。
誤りやすいポイント
- 「自動的に比較」をそのまま転記し、変換(マッピング)機能の記述を忘れる
- 「現行→新」方向に変換すると誤解しがちだが、比較時は「新→現行」に合わせる必要がある
- 単に「コード比較」とだけ書いて機能の具体性が不足する
FAQ
Q: コード変換ルールはどこで定義すべきですか?
A: 比較検証ツール内部にマスタを持たせる、または外部ファイル化して保守しやすくするのが一般的です。
A: 比較検証ツール内部にマスタを持たせる、または外部ファイル化して保守しやすくするのが一般的です。
Q: なぜ現行パッケージ側の値へ合わせるのですか?
A: 今回は「関連システムとの接続仕様を変更しない」ため、現行コード体系が比較の基準となるからです。
A: 今回は「関連システムとの接続仕様を変更しない」ため、現行コード体系が比較の基準となるからです。
Q: ツールは本番移行後も利用しますか?
A: 初回移行での整合性確認が主目的ですが、将来の保守やデータ移行時にも再利用できます。
A: 初回移行での整合性確認が主目的ですが、将来の保守やデータ移行時にも再利用できます。
関連キーワード: コード変換, テスト自動化, データ整合性, レガシーマイグレーション
設問1:〔移行判定会議の開催と報告〕について、(1)~(3)に答えよ。
(3)本文中のa、bに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:QMS
イ:WBS
ウ:機能要件
エ:ソフトウェア導入基準
オ:導入可否判断基準
カ:非機能要件
模範解答
a:カ
b:オ
解説
解答の論理構成
- a を判断する根拠
- 問題文では「性能要件やデータボリューム要件など、a を満たしていることを検証するテスト」とあります。
- 「性能要件」「データボリューム要件」は機能そのものではなく品質・運用面に関わる要求であり、一般に “非機能要件” と総称されます。
- 解答群で “非機能要件” に該当するのは「カ:非機能要件」であるため、
⇒ a=カ
- b を判断する根拠
- 問題文の該当箇所は「(6) b 達成度確認(報告者:F部長) ・新システムの品質と性能、利用者の業務運用の習得度が、移行可能な基準に達しており…」です。
- ここでは“品質・性能・習得度が移行可能な基準に達しているか”を最終確認しています。これは実際にシステムを“導入するか否か”を決定するための評価であり、導入可否を判定する基準そのものです。
- 解答群で「導入可否」を示すものは「オ:導入可否判断基準」のみ。
⇒ b=オ
誤りやすいポイント
- 性能要件を“機能要件”と混同する
性能や可用性などはシステムが「どのように」動くかを定める非機能側。画面入力や計算処理など「何を」行うかが機能要件です。 - “導入可否判断基準”と“QMS(品質マネジメントシステム)”の取り違え
QMS は品質プロセス全体の仕組みを指す概念であり、今回問われているのは導入決定時に参照する『基準』です。 - 文脈で b を「WBS」と誤読
“達成度確認”とあるため進捗管理(WBS)と勘違いしがちですが、ここでは最終移行可否の観点が問われています。
FAQ
Q: 非機能要件には具体的に何が含まれますか?
A: 性能、可用性、セキュリティ、拡張性、運用保守性など、機能以外でシステム品質を左右する要求が該当します。
A: 性能、可用性、セキュリティ、拡張性、運用保守性など、機能以外でシステム品質を左右する要求が該当します。
Q: 導入可否判断基準はいつ策定するのが望ましいですか?
A: 一般には要件定義段階で策定し、テスト・レビューの各工程で合否判定に活用します。本問でも移行判定会議の材料になっています。
A: 一般には要件定義段階で策定し、テスト・レビューの各工程で合否判定に活用します。本問でも移行判定会議の材料になっています。
Q: 達成度確認の責任者は誰が適切ですか?
A: プロジェクト責任者や品質保証部門など、システム全体を横断的に評価できる立場が望ましく、問題文でも「F部長」が担当しています。
A: プロジェクト責任者や品質保証部門など、システム全体を横断的に評価できる立場が望ましく、問題文でも「F部長」が担当しています。
関連キーワード: 非機能要件, 性能テスト, 受入れテスト, 導入判定, 品質保証
設問2:〔移行判定会議での指摘事項〕について、(1)~(4)に答えよ。
(1)本文中の c に入れる適切な字句を答えよ。
模範解答
c:緊急時対応計画
解説
解答の論理構成
-
問題文の確認
- 問題文には次の発言が示されています。
「G部長:新システムへの移行及び稼働開始時に、不測の事故が発生した場合のcその発動条件を定めていますか。」 - ここで G 部長が問い掛けているのは、移行当日にトラブルが起こった際の“計画”と“発動条件”の有無です。
- 問題文には次の発言が示されています。
-
文脈から求められる計画を特定
- “不測の事故”に備える計画は、システム移行では一般に「バックアウトプラン」「ロールバック計画」「緊急時対応計画」などが該当します。
- しかし、質問では「その発動条件を定めていますか」と述べており、発動条件まで明文化するのは通常“緊急時対応計画”の範疇です。
-
選択肢の絞り込み
- 「バックアウトプラン」は旧システムへ戻す具体的手順を指し、発動条件までドキュメント化するケースもありますが、狭義には“切替失敗時の手順”に限定されることが多いです。
- 一方「緊急時対応計画」は、障害・災害・事故など広範な“不測の事態”に対し、発動条件・組織体制・復旧手順を包含した総合計画を示します。
-
用語の整合性
- IPA のシステム監査基準や開発管理ガイドラインでも「緊急時対応計画」という語が正式に用いられ、発動条件・手順・責任者を定める文書として定義されています。
- したがって空欄 c には「緊急時対応計画」が最も適切です。
-
結論
- c:緊急時対応計画
誤りやすいポイント
- 「バックアウトプラン」と解答してしまう
- バックアウトは旧システムに戻す狭義の手順であり、発動条件を明文化する“計画”全体を必ずしも指さない点に注意が必要です。
- 「ロールバック手順」と答える
- “手順”は具体的な作業内容を示しますが、質問は“計画”を聞いているため不十分です。
- “緊急対応手順”など類似語を使ってしまう
- IPA や PMBOK で一般的に採用される正式名称「緊急時対応計画」をそのまま用いることが求められます。
FAQ
Q: バックアウトプランと緊急時対応計画の違いは何ですか?
A: バックアウトプランは主に「新システムから旧システムへ戻す」技術的手順を示します。一方、緊急時対応計画は障害発生時の判断基準、体制、連絡網、復旧手順などを包括的に定めた文書で、バックアウトプランを内包するのが一般的です。
A: バックアウトプランは主に「新システムから旧システムへ戻す」技術的手順を示します。一方、緊急時対応計画は障害発生時の判断基準、体制、連絡網、復旧手順などを包括的に定めた文書で、バックアウトプランを内包するのが一般的です。
Q: “発動条件”とは具体的に何を指しますか?
A: 例として「障害が業務に与える影響が重大以上になった場合」「復旧見込みが○時間を超える場合」など、緊急時対応計画を実行に移すトリガーとなる判定基準を指します。
A: 例として「障害が業務に与える影響が重大以上になった場合」「復旧見込みが○時間を超える場合」など、緊急時対応計画を実行に移すトリガーとなる判定基準を指します。
Q: 計画を事前に文書化するメリットは?
A: 緊急時に判断や手続きで迷うことなく迅速な対応を実現でき、責任分担の明確化・情報共有の徹底により復旧時間を短縮できます。
A: 緊急時に判断や手続きで迷うことなく迅速な対応を実現でき、責任分担の明確化・情報共有の徹底により復旧時間を短縮できます。
関連キーワード: BCP, フォールバック, ロールバック, リカバリ手順, バックアップ計画
設問2:〔移行判定会議での指摘事項〕について、(1)~(4)に答えよ。
(2)本文中の d に入れる適切な字句を、25字以内で述べよ。
模範解答
d:テスト環境の容量・能力が稼働環境と同等
解説
解答の論理構成
-
前提把握
【問題文】には、性能テストを本番環境ではなくテスト環境で行った理由として
「商品在庫管理システムのテスト環境の構成を調べたところ、性能テストをテスト環境で実施しても問題ないと判断できた」
と示されています。 -
追加情報の読み取り
さらに同じ箇所で
「稼働環境と同一のソフトウェアとDBをコピーしてテストを行った」
と明言されています。これは“ハードウェア・ソフトウェア構成や性能面で本番と同等”であることを裏付けています。 -
空欄の要件整理
F部長の質問は「テスト環境を使って実施しても問題ないと判断した理由」です。したがって、空欄 d には「テスト環境が本番環境に対して性能・容量で同等」という趣旨の説明が入るはずです。 -
解答導出
以上より d は
「テスト環境の容量・能力が稼働環境と同等」
が最も自然かつ論理的な補完となります。
誤りやすいポイント
- 「ソフトウェアとDBをコピーした」だけを根拠に、ハードウェア要件を見落としてしまう。容量・能力まで同等であることを示さないと説得力に欠けます。
- 「テスト環境=本番環境の縮小版」と早合点してしまい、“同等”ではなく“類似”や“近似”と書いて失点するケース。
- 形式面で「稼働」ではなく「本番」など別語に置き換え、原文の語を改変してしまうミス。
FAQ
Q: 「容量」と「能力」は両方書く必要がありますか?
A: はい。性能テストの妥当性を担保するにはストレージ容量・CPU性能など両面の同等性が不可欠です。
A: はい。性能テストの妥当性を担保するにはストレージ容量・CPU性能など両面の同等性が不可欠です。
Q: ソフトウェアやDBが同一なら十分では?
A: いいえ。ハードウェア性能が劣れば処理時間に影響します。性能テストの目的は処理能力の検証なので、ハードウェア面の同等性も必須です。
A: いいえ。ハードウェア性能が劣れば処理時間に影響します。性能テストの目的は処理能力の検証なので、ハードウェア面の同等性も必須です。
Q: 「稼働環境と同じ構成」と書いても正しい?
A: 趣旨は合っていますが、容量と能力の具体的観点を示したほうが明確で、採点基準にも合致しやすいです。
A: 趣旨は合っていますが、容量と能力の具体的観点を示したほうが明確で、採点基準にも合致しやすいです。
関連キーワード: 性能テスト, 本番同等環境, ハードウェア容量, 処理能力, 構成比較
設問2:〔移行判定会議での指摘事項〕について、(1)~(4)に答えよ。
(3)本文中の下線③について、ソフトウェアの保守作業担当者に引き継ぐべき事項を、30字以内で述べよ。
模範解答
利用者による受入れテストで指摘されたプログラム改修
解説
解答の論理構成
-
問題文の確認
下線③は「新システムの稼働後に行うランステム関連作業」を整理せよという指示に対して引き継ぐ内容を問うている。 -
引き継ぎ対象を特定
受入れテストに関する報告(3)で、X課長は
「顧客属性管理画面のレイアウトが見づらいなどの指摘が2件あった。業務運用への影響は軽微なので、稼働後にプログラムを改修することを条件にHセンタ長から了承を得た。これらは、申し送り事項として管理する」
と述べている。 -
稼働後に実施すべき保守作業
上記引用のとおり、稼働後に残る作業は「顧客属性管理画面」などの軽微な改修のみである。したがって、ソフトウェア保守担当者へは“受入れテストで指摘されたプログラム改修”を申し送る必要がある。 -
結論
よって解答は「利用者による受入れテストで指摘されたプログラム改修」となる。
誤りやすいポイント
- 成果物の引き継ぎと作業指示を混同し、移行計画や運用マニュアル作成など完了済みのタスクを列挙してしまう。
- 稼働前後のタイミングを誤り、バグ修正全般や性能チューニングまで含めてしまう。
- 指摘事項が「軽微」と明記されているため不要と判断し、引き継ぎ対象から漏らす。
FAQ
Q: 稼働後に改修する理由は何ですか?
A: 「業務運用への影響は軽微」かつ稼働期日が迫っているため、サービス開始を優先し、改修は保守フェーズに回す判断です。
A: 「業務運用への影響は軽微」かつ稼働期日が迫っているため、サービス開始を優先し、改修は保守フェーズに回す判断です。
Q: 受入れテストで指摘された内容は必ず保守作業になりますか?
A: 重大度や影響度によります。今回は「軽微」と判断されたため移行後の保守作業に回されています。
A: 重大度や影響度によります。今回は「軽微」と判断されたため移行後の保守作業に回されています。
Q: 引き継ぎ時に重要なのは何ですか?
A: 残課題の内容・優先度・影響範囲を明確にし、担当者やスケジュールを決めて漏れなく管理することです。
A: 残課題の内容・優先度・影響範囲を明確にし、担当者やスケジュールを決めて漏れなく管理することです。
関連キーワード: 受入れテスト, 保守作業, 移行判定, 申し送り, システム改修
設問2:〔移行判定会議での指摘事項〕について、(1)~(4)に答えよ。
(4)本文中の e に入れる適切な字句を、15字以内で答えよ。
模範解答
e:現行システムの廃棄
解説
解答の論理構成
- 【問題文】には
「X 課長は、Y 部長からの指摘を受けて、新システムが安定稼働していることを確認した後に実施すべきである e の計画を策定することにした。」
とある。この文脈から e は “新システムが安定してから取り掛かる作業” であると分かります。 - さらに同じ段落で
「そこで、運用及び保守の組織だけでなく利用者も参加させて、この活動を開始した。」
と述べられています。運用・保守部門だけでなく利用者も巻き込む活動は、移行直後の障害対応やパフォーマンス調整ではなく、旧資産の撤去手続きのような全社的タスクが典型です。 - 本プロジェクトの背景として
「現行システムのハードウェアが年度末に保守期限を迎えるので…新CTIシステム…に更改する」
とあり、旧環境はサポート切れになるため最終的に廃棄・撤去が必要です。 - 旧システムは移行当日に「停止」されますが、停止と廃棄は別工程です。停止後しばらく並行保管して正常稼働を確認したうえで、本番データの完全バックアップ取得・媒体の物理破壊・資産管理台帳の更新など “廃棄” 作業を計画するのが一般的です。
- 以上より、新システム安定稼働後に行うべき活動は「現行システムの廃棄」であり、模範解答と一致します。
誤りやすいポイント
- 「停止」と「廃棄」の混同
移行当日の停止=廃棄と早合点しがちですが、停止後にもデータ保持義務やトラブル時のリカバリを考慮して一定期間旧機を保管することが多いです。 - ロールバック計画との取り違え
質疑応答で G 部長が触れた「cその発動条件」がロールバック手順なので、e もロールバックと勘違いしやすい点に注意してください。 - 「改善活動」など抽象語の選択
利用者も交えた活動=業務改善と連想しがちですが、問題文には改善内容や追加開発の示唆がなく、保守期限を迎える旧システム資産の行方こそ論理的に導けるキーワードです。
FAQ
Q: 新旧並行運用期間を設ける場合でも廃棄計画は立てるべきですか?
A: はい。並行運用を行う場合でも、終了時期と廃棄方法をあらかじめ決めておくことで資産管理や情報漏えい防止を徹底できます。
A: はい。並行運用を行う場合でも、終了時期と廃棄方法をあらかじめ決めておくことで資産管理や情報漏えい防止を徹底できます。
Q: 廃棄作業に利用者を参加させる理由は何ですか?
A: 利用者側で旧データを参照したいケースや帳票の保管義務があるため、必要なデータ抽出・保管形式の確認に利用者の意見が不可欠です。
A: 利用者側で旧データを参照したいケースや帳票の保管義務があるため、必要なデータ抽出・保管形式の確認に利用者の意見が不可欠です。
Q: ハードウェアとソフトウェアの廃棄手順は同じですか?
A: いいえ。ハードウェアは物理的破壊やリサイクル処理、ソフトウェアはライセンス解除や媒体破棄、データは無復元化処理など、対象ごとに手順が異なります。
A: いいえ。ハードウェアは物理的破壊やリサイクル処理、ソフトウェアはライセンス解除や媒体破棄、データは無復元化処理など、対象ごとに手順が異なります。
関連キーワード: データ消去, 資産管理, ライフサイクルマネジメント, リスク低減, ロールバック


