応用情報技術者過去問題 令和5年春期 午後問9
⇄問題文と設問を画面2分割で開く⇱問題PDF問9 プロジェクトマネジメント
金融機関システムの移行プロジェクトに関する次の記述を読んで,設問に答えよ。
P社は,本店と全国30か所の支店(以下,拠点という)から成る国内の金融機関である。P社は,土日祝日及び年末年始を除いた日(以下,営業日という)に営業をしている。P社では,金融商品の販売業務を行うためのシステム(以下,販売支援システムという)をオンプレミスで運用している。
販売支援システムは,営業日だけ稼働しており,拠点の営業員及び拠点を統括する商品販売部の部員が利用している。販売支援システムの運用・保守及びサービスデスクは,情報システム部運用課(以下,運用課という)が担当し,サービスデスクが解決できない問合せのエスカレーション対応及びシステム開発は,情報システム部開発課(以下,開発課という)が担当する。
販売支援システムのハードウェアは,P社内に設置されたサーバ機器,拠点の端末,及びサーバと端末を接続するネットワーク機器で構成される。
販売支援システムのアプリケーションソフトウェアのうち,中心となる機能は,X社のソフトウェアパッケージ(以下,Xパッケージという)を利用しているが,Xパッケージの標準機能で不足する一部の機能は,Xパッケージをカスタマイズしている。
販売支援システムのサーバ機器及びXパッケージはいずれも来年3月末に保守契約の期限を迎え,いずれも老朽化しているので以後の保守費用は大幅に上昇する。そこで,P社は,本年4月に,クラウドサービスを活用して現状のサーバ機器導入に関する構築期間の短縮やコストの削減を実現し,さらにXパッケージをバージョンアップして大幅な機能改善を図ることを目的に移行プロジェクトを立ち上げた。X社から,今回適用するバージョンは,OSやミドルウェアに制約があると報告されていた。
開発課のQ課長が,移行プロジェクトのプロジェクトマネージャ(PM)に任命され,移行プロジェクトの計画の作成に着手した。Q課長は,開発課のR主任に現行の販売支援システムからの移行作業を,同課のS主任に移行先のクラウドサービスでのシステム構築,移行作業とのスケジュールの調整などを指示した。
〔ステークホルダの要求〕
Q課長は,移行プロジェクトの主要なステークホルダを特定し,その要求を確認することにした。
経営層からは,保守契約の期限前に移行を完了すること,顧客の個人情報の漏えい防止に万全を期すこと,重要なリスクは組織で迅速に対応するために経営層と情報共有すること,クラウドサービスを活用する新システムへの移行を判断する移行判定基準を作成すること,が指示された。
商品販売部からは,5拠点程度の単位で数回に分けて切り替える段階移行方式を採用したいという要望を受けた。商品販売部では,過去のシステム更改の際に,全拠点で一斉に切り替える一括移行方式を採用したが,移行後に業務遂行に支障が生じたことがあった。その原因は,サービスデスクでは対応できない問合せが全拠点から同時に集中した際に,システム更改を担当した開発課の要員が新たなシステムの開発で繁忙となっていたので,エスカレーション対応する開発課のリソースがひっ迫し,問合せの回答が遅くなったことであった。また,切替えに伴う拠点での営業日の業務停止は,各拠点で特別な対応が必要になるので避けたい,との要望を受けた。
運用課からは,移行後のことも考えて移行プロジェクトのメンバーと緊密に連携したいとの話があった。
情報システム部長は,段階移行方式では,各回の切替作業に3日間を要するので,拠点との日程調整が必要となること,及び新旧システムを並行して運用することによって情報システム部の負担が過大になることを避けたいと考えていた。
〔プロジェクト計画の作成〕
Q課長は,まず,ステークホルダマネジメントについて検討した。Q課長は経営層,商品販売部及び情報システム部が参加するステアリングコミッティを設置し,移行プロジェクトの進捗状況の報告,重要なリスク及び対応方針の報告,最終の移行判定などを行うことにした。
次に,Q課長は,移行方式について,全拠点で一斉に切り替える①一括移行方式を採用したいと考えた。そこで,Q課長は,商品販売部に,サービスデスクから受けるエスカレーション対応のリソースを拡充することで,移行後に発生する問合せに迅速に回答することを説明して了承を得た。
現行の販売支援システムのサーバ機器及びXパッケージの保守契約の期限である来年3月末までに移行を完了する必要がある。Q課長は,移行作業の期間も考慮した上で,切替作業に問題が発生した場合に備えて,年末年始に切替作業を行うことにした。
Q課長は,移行の目的や制約を検討した結果,IaaS型のクラウドサービスを採用することにした。IaaSベンダーの選定に当たり,Q課長は,S主任に,新システムのセキュリティインシデントの発生に備えて,セキュリティ対策をP社セキュリティポリシーに基づいて策定することを指示した。S主任は,候補となるIaaSベンダーの技術情報を基に,セキュリティ対策を検討すると回答したが,Q課長は,②具体的なセキュリティ対策の検討に先立って実施すべきことがあるとS主任に指摘した。S主任は,Q課長の指摘を踏まえて作業を進め,セキュリティ対策を策定した。
最後に,Q課長は,これまでの検討結果をまとめ,IaaSベンダーに③RFPを提示し,受領した提案内容を評価した。その評価結果を基にW社を選定した。
Q課長は,これらについて経営層に報告して承認を受けた。
〔移行プロジェクトの作業計画〕
R主任とS主任は協力して,移行手順書の作成,移行ツールの開発,移行総合テスト,営業員の教育・訓練及び受入れテスト,移行リハーサル,本番移行,並びに移行後の初期サポートの各作業の検討を開始した。各作業は次のとおりである。
〔リスクマネジメント〕
Q課長は,R主任に,主にリスクの定性的分析で使用されるaを活用し,分析結果を表としてまとめるよう指示した。さらに,リスクの定量的分析として,移行作業に対して最も影響が大きいリスクが何であるかを判断することができるbを実施し,リスクの重大性を評価するよう指示した。
リスクの分析結果に基づき,R主任は,各リスクに対して,対応策を検討した。Q課長は,来年3月末までに本番移行が完了しないような重大なリスクに対して,プロジェクトの期間を延長することに要する費用の確保以外に,現行の販売支援システムを稼働延長させることに要する費用面の⑦対応策を検討すべきだ,とR主任に指摘した。
R主任は,指摘について検討し,Q課長に説明をして了承を得た。
P社は,本店と全国30か所の支店(以下,拠点という)から成る国内の金融機関である。P社は,土日祝日及び年末年始を除いた日(以下,営業日という)に営業をしている。P社では,金融商品の販売業務を行うためのシステム(以下,販売支援システムという)をオンプレミスで運用している。
販売支援システムは,営業日だけ稼働しており,拠点の営業員及び拠点を統括する商品販売部の部員が利用している。販売支援システムの運用・保守及びサービスデスクは,情報システム部運用課(以下,運用課という)が担当し,サービスデスクが解決できない問合せのエスカレーション対応及びシステム開発は,情報システム部開発課(以下,開発課という)が担当する。
販売支援システムのハードウェアは,P社内に設置されたサーバ機器,拠点の端末,及びサーバと端末を接続するネットワーク機器で構成される。
販売支援システムのアプリケーションソフトウェアのうち,中心となる機能は,X社のソフトウェアパッケージ(以下,Xパッケージという)を利用しているが,Xパッケージの標準機能で不足する一部の機能は,Xパッケージをカスタマイズしている。
販売支援システムのサーバ機器及びXパッケージはいずれも来年3月末に保守契約の期限を迎え,いずれも老朽化しているので以後の保守費用は大幅に上昇する。そこで,P社は,本年4月に,クラウドサービスを活用して現状のサーバ機器導入に関する構築期間の短縮やコストの削減を実現し,さらにXパッケージをバージョンアップして大幅な機能改善を図ることを目的に移行プロジェクトを立ち上げた。X社から,今回適用するバージョンは,OSやミドルウェアに制約があると報告されていた。
開発課のQ課長が,移行プロジェクトのプロジェクトマネージャ(PM)に任命され,移行プロジェクトの計画の作成に着手した。Q課長は,開発課のR主任に現行の販売支援システムからの移行作業を,同課のS主任に移行先のクラウドサービスでのシステム構築,移行作業とのスケジュールの調整などを指示した。
〔ステークホルダの要求〕
Q課長は,移行プロジェクトの主要なステークホルダを特定し,その要求を確認することにした。
経営層からは,保守契約の期限前に移行を完了すること,顧客の個人情報の漏えい防止に万全を期すこと,重要なリスクは組織で迅速に対応するために経営層と情報共有すること,クラウドサービスを活用する新システムへの移行を判断する移行判定基準を作成すること,が指示された。
商品販売部からは,5拠点程度の単位で数回に分けて切り替える段階移行方式を採用したいという要望を受けた。商品販売部では,過去のシステム更改の際に,全拠点で一斉に切り替える一括移行方式を採用したが,移行後に業務遂行に支障が生じたことがあった。その原因は,サービスデスクでは対応できない問合せが全拠点から同時に集中した際に,システム更改を担当した開発課の要員が新たなシステムの開発で繁忙となっていたので,エスカレーション対応する開発課のリソースがひっ迫し,問合せの回答が遅くなったことであった。また,切替えに伴う拠点での営業日の業務停止は,各拠点で特別な対応が必要になるので避けたい,との要望を受けた。
運用課からは,移行後のことも考えて移行プロジェクトのメンバーと緊密に連携したいとの話があった。
情報システム部長は,段階移行方式では,各回の切替作業に3日間を要するので,拠点との日程調整が必要となること,及び新旧システムを並行して運用することによって情報システム部の負担が過大になることを避けたいと考えていた。
〔プロジェクト計画の作成〕
Q課長は,まず,ステークホルダマネジメントについて検討した。Q課長は経営層,商品販売部及び情報システム部が参加するステアリングコミッティを設置し,移行プロジェクトの進捗状況の報告,重要なリスク及び対応方針の報告,最終の移行判定などを行うことにした。
次に,Q課長は,移行方式について,全拠点で一斉に切り替える①一括移行方式を採用したいと考えた。そこで,Q課長は,商品販売部に,サービスデスクから受けるエスカレーション対応のリソースを拡充することで,移行後に発生する問合せに迅速に回答することを説明して了承を得た。
現行の販売支援システムのサーバ機器及びXパッケージの保守契約の期限である来年3月末までに移行を完了する必要がある。Q課長は,移行作業の期間も考慮した上で,切替作業に問題が発生した場合に備えて,年末年始に切替作業を行うことにした。
Q課長は,移行の目的や制約を検討した結果,IaaS型のクラウドサービスを採用することにした。IaaSベンダーの選定に当たり,Q課長は,S主任に,新システムのセキュリティインシデントの発生に備えて,セキュリティ対策をP社セキュリティポリシーに基づいて策定することを指示した。S主任は,候補となるIaaSベンダーの技術情報を基に,セキュリティ対策を検討すると回答したが,Q課長は,②具体的なセキュリティ対策の検討に先立って実施すべきことがあるとS主任に指摘した。S主任は,Q課長の指摘を踏まえて作業を進め,セキュリティ対策を策定した。
最後に,Q課長は,これまでの検討結果をまとめ,IaaSベンダーに③RFPを提示し,受領した提案内容を評価した。その評価結果を基にW社を選定した。
Q課長は,これらについて経営層に報告して承認を受けた。
〔移行プロジェクトの作業計画〕
R主任とS主任は協力して,移行手順書の作成,移行ツールの開発,移行総合テスト,営業員の教育・訓練及び受入れテスト,移行リハーサル,本番移行,並びに移行後の初期サポートの各作業の検討を開始した。各作業は次のとおりである。
- 移行手順書の作成
移行に関わる全作業の手順書を作成し,関係するメンバーでレビューする。 - 移行ツールの開発
移行作業の実施に当たって,データ変換ツール,構成管理ツールなどのX社提供の移行ツールを活用するが,Xパッケージをカスタマイズした機能に関しては,X社提供のデータ変換ツールを利用することができないので,移行に必要なデータ変換機能を開発課が追加開発する。 - 移行総合テスト
移行総合テストでは,移行ツールが正常に動作し,移行手順書どおりに作業できるかを確認した上で,移行後のシステムの動作が正しいことを移行プロジェクトとして検証する。R主任は,より本番移行に近い内容で移行総合テストを実施する方が検証漏れのリスクを軽減できると考えた。ただし,P社のテスト規定では,個人情報を含んだ本番データはテスト目的に用いないこと,本番データをテスト目的で用いる場合には,その必要性を明らかにした上で,個人情報を個人情報保護法及び関連ガイドラインに従って匿名加工情報に加工する処置を施して用いること,と定められている。そこで,R主任は本番データに含まれる個人情報を匿名加工情報に加工して移行総合テストに用いる計画を作成した。Q課長は,検証漏れのリスクと情報漏えいのリスクのそれぞれを評価した上で,R主任の計画を承認した。その際,PMであるQ課長だけで判断せず,④ある手続を実施した上で対応方針を決定した。 - 営業員の教育訓練及び受入れテスト
商品販売部の部員が,S主任及び拠点の責任者と協議しながら,営業員の教育・訓練の内容及び実施スケジュールを計画する。これに沿って,営業日の業務後に受入れテストを兼ねて,商品販売部の部員及び全営業員に対する教育・訓練を実施する。 - 移行リハーサル
移行リハーサルでは,移行総合テストで検証された移行ツールを使った移行手順,本番移行の当日の体制,及びタイムチャートを検証する。 - 本番移行
移行リハーサルで検証した一連の手順に従って切替作業を実施する。本番移行は本年12月31日~来年1月2日に実施することに決定した。 - 移行後の初期サポート
移行後のトラブルや問合せに対応するための初期サポートを実施する。初期サポートの実施に当たり,Q課長は,移行後も,システムが安定稼働して拠点からサービスデスクへの問合せが収束するまでの間,⑤ある支援を継続するようS主任に指示した。
〔リスクマネジメント〕
Q課長は,R主任に,主にリスクの定性的分析で使用されるaを活用し,分析結果を表としてまとめるよう指示した。さらに,リスクの定量的分析として,移行作業に対して最も影響が大きいリスクが何であるかを判断することができるbを実施し,リスクの重大性を評価するよう指示した。
リスクの分析結果に基づき,R主任は,各リスクに対して,対応策を検討した。Q課長は,来年3月末までに本番移行が完了しないような重大なリスクに対して,プロジェクトの期間を延長することに要する費用の確保以外に,現行の販売支援システムを稼働延長させることに要する費用面の⑦対応策を検討すべきだ,とR主任に指摘した。
R主任は,指摘について検討し,Q課長に説明をして了承を得た。
設問1
〔プロジェクト計画の作成〕について答えよ。
解答群
- 過去のセキュリティインシデントの再発防止策検討
- 過去のセキュリティインシデントの被害金額算出
- セキュリティ対策の訓練
- セキュリティ対策の責任範囲の明確化
解答入力欄
解答例・解答の要点
- 営業日に業務の停止が不要 (12文字)
- エ
- IaaS利用による構築期間とコスト (17文字)
解説
- システムを移行する方式には、全システムを一度に移行する「一括移行方式」、サブシステムや部門・拠点単位で段階的に移行する「段階移行方式」、一括移行と段階移行の中間的なアプローチとして、限定した部門・拠点単位で新システムを先行導入し、その運用状況を評価してから他の全部門で一斉移行する「パイロット移行方式」などがあります。
一括移行方式と段階移行方式を比較すると、以下のような特徴があります。Q課長が行ったステークホルダからのヒアリングの中で、商品販売部から「切替えに伴う拠点での営業日の業務停止は,各拠点で特別な対応が必要になるので避けたい,との要望を受けた」とあります。P社の営業日は、土日祝と年末年始を除いた日であり、段階移行方式では各回の切替作業に(連続した)3日間を要するので、段階移行方式を採用した場合、年度末までに移行を完了させるためには営業日の業務停止が避けられません。一括移行方式では、移行後のサポート面に配慮する必要があるものの、年末年始を利用することで営業日の業務停止なく移行を完了させることができます。これが経営層や商品販売部にとってのメリットとなります。
∴営業日に業務の停止が不要 - 4つの選択肢を「具体的なセキュリティ対策の検討に先立って実施すべきこと」という観点から検討すると、「ア」「イ」は事後のインシデントに対する、そして「ウ」は将来発生するインシデントに対する具体的なセキュリティ対策ですから、解答として適切なのは「エ」ということになります。
クラウドサービスでは、サービス提供者とサービス利用者がそれぞれの役割を分担し、運用上の責任を共有する必要があります。これを「責任共有モデル」といいます。SaaS、PaaS、IaaSなどの分類に応じて大まかな責任範囲の目安はありますが、個別具体的な責任分界点は一律に決まるものではありません。複雑化するクラウドサービスとその業務利用の進展により、責任範囲の明確化を疎かにしたことによるセキュリティ被害が多発しているため、特にセキュリティ面においてサービス提供者側とサービス利用者側それぞれの責任範囲を明確にしておくことは重要です。
責任範囲の明確化は、適切なセキュリティ対策を行うための前提であり、サービス利用者側は、責任分界点を踏まえてセキュリティの要求事項を満たすために必要な対策を講じることとなります。責任範囲が決まらなければ、具体的なセキュリティ対策を検討することはできないので、Q課長はその点を指摘したと考えられます。
∴エ:セキュリティ対策の責任範囲の明確化 - IaaS型のクラウドサービスを採用した経緯については、〔プロジェクト計画の作成〕に「Q課長は,移行の目的や制約を検討した結果,IaaS型のクラウドサービスを採用することにした」と説明されています。移行の目的と制約に関しては、問題文から以下の背景情報を読み取ることができます。
- 目的
- ・構築期間の短縮やコストの削減を実現する
・Xパッケージをバージョンアップして大幅な機能改善を図る - 制約
- ・OSやミドルウェアに制約がある
・保守契約の期限前に移行を完了する
∴IaaS利用による構築期間とコスト
設問2
〔移行プロジェクトの作業計画〕について答えよ。
解答入力欄
解答例・解答の要点
- ステアリングコミッティで本番データを用いたテストの承認を得る (30文字)
- エスカレーション対応の開発課リソースの拡充 (21文字)
- 移行判定基準書 (7文字)
解説
- 移行総合テストにおける検証漏れリスクと情報漏えいリスクについて、PMであるQ課長が行うべき追加の手続きが問われています。
P社のテスト規定では、個人情報を含む本番データをテストに用いないこと、用いる場合には必要性を明らかにした上で、匿名加工情報に加工する処置を施すことになっています。つまり、今回の移行総合テストでは、原則として禁止されている内容を含むテストを実施するということになります。
情報漏えいのリスクについては〔ステークホルダの要求〕に「経営層からは,…顧客の個人情報の漏えい防止に万全を期すこと,重要なリスクは組織で迅速に対応するために経営層と情報共有すること,…が指示された」とあります。個人情報を含む本番データをクラウドサービス上にアップロードすることは(金融機関であるP社にとっては特に)重要なリスクとなるため、リスクを情報共有する手続きの対象となることがわかります。
Q課長は、本プロジェクトにおいてステアリングコミッティを設置しており、移行プロジェクトの進捗状況の報告、重要なリスク及び対応方針の報告などを行うことにしています。ステアリングコミッティとは、関係者の代表で構成された委員会組織で、プロジェクト全体を見通し、全体最適化の観点から利害調整や意思決定を行うことを責務とする機関です。ステアリングコミッティには経営層も参加していますから、Q課長は、移行総合テストに伴うリスクと対応方針についてステアリングコミッティに報告し、承認を得ることになります。
∴ステアリングコミッティで本番データを用いたテストの承認を得る - 移行後の初期サポートの施策として、サービスデスクへの問合せが収束するまでの間に行うべき支援内容を解答します。
サービスデスクへの問合せに関しては、過去のシステム更改の際に「サービスデスクでは対応できない問合せが全拠点から同時に集中した際に,システム更改を担当した開発課の要員が新たなシステムの開発で繁忙となっていたので,エスカレーション対応する開発課のリソースがひっ迫し,問合せの回答が遅くなった」ことにより、移行後の業務遂行に支障が出たという問題点が記載されています。一括移行方式を採用する今回の移行プロジェクトでも同様の問題が発生する可能性があり、その対策として「商品販売部に,サービスデスクから受けるエスカレーション対応のリソースを拡充することで,移行後に発生する問合せに迅速に回答することを説明して了承を得た」とあります。
問合せ対応が遅くなった原因は、開発課のリソースが足りていなかったことにあるので、「エスカレーション対応の開発課リソースを拡充する」ことが初期サポートにおいて行うべき支援内容となります。
∴エスカレーション対応の開発課リソースの拡充 - 移行可否を評価する上で必要な文書を、本文中の字句を用いて解答します。
新システムの移行可否の評価については〔ステークホルダの要求〕に「経営層からは…クラウドサービスを活用する新システムへの移行を判断する移行判定基準を作成すること,が指示された」とあります。設問文に「本文中の字句を用いて」と指定があることからも、この箇所が解答根拠となると判断できます。移行判定基準は文書化し、事前に明確化しておく必要があります。したがって、答えは「移行判定基準書」です。
∴移行判定基準書
設問3
〔リスクマネジメント〕について答えよ。
- 本文中のa,bに入れる適切な字句を解答群の中から選び,記号で答えよ。
- 本文中の下線⑦について,来年3月末までに本番移行が完了しないリスクに対して検討すべき対応策について,20字以内で具体的に答えよ。
a,b に関する解答群
- 感度分析
- クラスタ分析
- コンジョイント分析
- デルファイ法
- 発生確率・影響度マトリックス
解答入力欄
- a:
- b:
解答例・解答の要点
- a:オ
- b:ア
- 追加発生する保守費用の確保 (13文字)
解説
- 5つの分析手法はそれぞれ以下のようなものです。5つのうち一般的にリスク分析で使われるのは、感度分析と発生確率・影響度マトリックスのみです。
- 感度分析
- 結果に複数の要因が関連しているときに、ある要因の変化が結果に対して影響する度合いを定量的に分析する方法。プロジェクトのリスク管理においては、個別リスクや不確定な要素がプロジェクトの成果に影響を与える度合いを数値として分析するために使用される
- クラスタ分析
- 複数の変数(項目・属性・次元数)を持つ多数のデータがあるとき、その変数間の相互の関係性を分析する方法
- コンジョイント分析
- 顧客が商品を構成する要素(価格・デザイン・機能など)のうち、どの要素をどのくらい重視しているかを定量的に明らかにする手法。主にマーケティング分野において、最適な商品コンセプトを特定するために使用される
- デルファイ法
- 複数の専門家から個別に意見の収集を行い、得られた意見の集約をフィードバックするということを繰り返して、最終的に意見の収束をしていく手法。プロジェクトリスク管理においては、リスク特定の工程で使用されることがある
- 発生確率・影響度マトリックス
- 各リスクの発生確率と影響度の度合いをそれぞれ「高」「中」「低」などの定性的な言葉、または0.1~0.9などの一般的な尺度で表し、それらの組合せで表現されるマトリクス上に各リスクを分類することで、リスクレベルを定性的に分析する手法
「定性的分析で使用される」と「分析結果を表としてまとめる」より、発生確率・影響度マトリックスが適切であるとわかります。発生確率・影響度マトリックスは、リスクの発生確率と影響度の組み合わせをマトリックスとして図示したもので、リスクの優先順位を等級付けするために使用されます。〔bについて〕
「定量的分析」と「影響が大きいリスクが何であるかを判断する」より、感度分析が適切であるとわかります。感度分析は、それぞれのリスクの影響度を定量的に評価する手法であり、どのリスク事象がプロジェクトにどれだけ影響を与えるかを把握するために使用されます。∴a=オ:発生確率・影響度マトリックス
b=ア:感度分析 - 移行プロジェクトは、保守契約の期限前に移行を完了させることを目標にしていますが、移行が完了しない場合には、移行完了まで現行の販売支援システムを稼働延長させざるを得ません。この場合、追加の保守費用が発生することになるので、リスクが顕在化したときの保守費用の負担に備えて、コンティンジェンシー予備などで予算を確保しておくことを検討すべきとなります。
∴追加発生する保守費用の確保