解説

• システムを移行する方式には、全システムを一度に移行する「一括移行方式」、サブシステムや部門・拠点単位で段階的に移行する「段階移行方式」、一括移行と段階移行の中間的なアプローチとして、限定した部門・拠点単位で新システムを先行導入し、その運用状況を評価してから他の全部門で一斉移行する「パイロット移行方式」などがあります。
  
  一括移行方式と段階移行方式を比較すると、以下のような特徴があります。
  
  Q課長が行ったステークホルダからのヒアリングの中で、商品販売部から「切替えに伴う拠点での営業日の業務停止は，各拠点で特別な対応が必要になるので避けたい，との要望を受けた」とあります。P社の営業日は、土日祝と年末年始を除いた日であり、段階移行方式では各回の切替作業に（連続した）3日間を要するので、段階移行方式を採用した場合、年度末までに移行を完了させるためには営業日の業務停止が避けられません。一括移行方式では、移行後のサポート面に配慮する必要があるものの、年末年始を利用することで営業日の業務停止なく移行を完了させることができます。これが経営層や商品販売部にとってのメリットとなります。
  
  ∴営業日に業務の停止が不要
  
  
• 4つの選択肢を「具体的なセキュリティ対策の検討に先立って実施すべきこと」という観点から検討すると、「ア」「イ」は事後のインシデントに対する、そして「ウ」は将来発生するインシデントに対する具体的なセキュリティ対策ですから、解答として適切なのは「エ」ということになります。
  
  クラウドサービスでは、サービス提供者とサービス利用者がそれぞれの役割を分担し、運用上の責任を共有する必要があります。これを「責任共有モデル」といいます。SaaS、PaaS、IaaSなどの分類に応じて大まかな責任範囲の目安はありますが、個別具体的な責任分界点は一律に決まるものではありません。複雑化するクラウドサービスとその業務利用の進展により、責任範囲の明確化を疎かにしたことによるセキュリティ被害が多発しているため、特にセキュリティ面においてサービス提供者側とサービス利用者側それぞれの責任範囲を明確にしておくことは重要です。
  
  責任範囲の明確化は、適切なセキュリティ対策を行うための前提であり、サービス利用者側は、責任分界点を踏まえてセキュリティの要求事項を満たすために必要な対策を講じることとなります。責任範囲が決まらなければ、具体的なセキュリティ対策を検討することはできないので、Q課長はその点を指摘したと考えられます。
  
  ∴エ：セキュリティ対策の責任範囲の明確化
  
  
• IaaS型のクラウドサービスを採用した経緯については、〔プロジェクト計画の作成〕に「Q課長は，移行の目的や制約を検討した結果，IaaS型のクラウドサービスを採用することにした」と説明されています。移行の目的と制約に関しては、問題文から以下の背景情報を読み取ることができます。

  目的

  ・構築期間の短縮やコストの削減を実現する
  ・Xパッケージをバージョンアップして大幅な機能改善を図る

  制約

  ・OSやミドルウェアに制約がある
  ・保守契約の期限前に移行を完了する

  移行プロジェクトは、サーバ機器とXパッケージの保守期限が到来し、その後の保守費用が大幅に上昇することを避けるためにスタートしています。したがって、提案内容の評価で重視するのは、プロジェクトの目的である構築期間の短縮やコストの削減をどれだけ実現できるかという点となります。OSやミドルウェアは利用者側で用意するため、制約事項に関しては問題ありません。
  
  ∴IaaS利用による構築期間とコスト
  
  

解説

• 移行総合テストにおける検証漏れリスクと情報漏えいリスクについて、PMであるQ課長が行うべき追加の手続きが問われています。
  
  P社のテスト規定では、個人情報を含む本番データをテストに用いないこと、用いる場合には必要性を明らかにした上で、匿名加工情報に加工する処置を施すことになっています。つまり、今回の移行総合テストでは、原則として禁止されている内容を含むテストを実施するということになります。
  
  情報漏えいのリスクについては〔ステークホルダの要求〕に「経営層からは，…顧客の個人情報の漏えい防止に万全を期すこと，重要なリスクは組織で迅速に対応するために経営層と情報共有すること，…が指示された」とあります。個人情報を含む本番データをクラウドサービス上にアップロードすることは（金融機関であるP社にとっては特に）重要なリスクとなるため、リスクを情報共有する手続きの対象となることがわかります。
  
  Q課長は、本プロジェクトにおいてステアリングコミッティを設置しており、移行プロジェクトの進捗状況の報告、重要なリスク及び対応方針の報告などを行うことにしています。ステアリングコミッティとは、関係者の代表で構成された委員会組織で、プロジェクト全体を見通し、全体最適化の観点から利害調整や意思決定を行うことを責務とする機関です。ステアリングコミッティには経営層も参加していますから、Q課長は、移行総合テストに伴うリスクと対応方針についてステアリングコミッティに報告し、承認を得ることになります。
  
  ∴ステアリングコミッティで本番データを用いたテストの承認を得る
  
  
• 移行後の初期サポートの施策として、サービスデスクへの問合せが収束するまでの間に行うべき支援内容を解答します。
  
  サービスデスクへの問合せに関しては、過去のシステム更改の際に「サービスデスクでは対応できない問合せが全拠点から同時に集中した際に，システム更改を担当した開発課の要員が新たなシステムの開発で繁忙となっていたので，エスカレーション対応する開発課のリソースがひっ迫し，問合せの回答が遅くなった」ことにより、移行後の業務遂行に支障が出たという問題点が記載されています。一括移行方式を採用する今回の移行プロジェクトでも同様の問題が発生する可能性があり、その対策として「商品販売部に，サービスデスクから受けるエスカレーション対応のリソースを拡充することで，移行後に発生する問合せに迅速に回答することを説明して了承を得た」とあります。
  
  問合せ対応が遅くなった原因は、開発課のリソースが足りていなかったことにあるので、「エスカレーション対応の開発課リソースを拡充する」ことが初期サポートにおいて行うべき支援内容となります。
  
  ∴エスカレーション対応の開発課リソースの拡充
  
  
• 移行可否を評価する上で必要な文書を、本文中の字句を用いて解答します。
  
  新システムの移行可否の評価については〔ステークホルダの要求〕に「経営層からは…クラウドサービスを活用する新システムへの移行を判断する移行判定基準を作成すること，が指示された」とあります。設問文に「本文中の字句を用いて」と指定があることからも、この箇所が解答根拠となると判断できます。移行判定基準は文書化し、事前に明確化しておく必要があります。したがって、答えは「移行判定基準書」です。
  
  ∴移行判定基準書
  
  

解説

• 5つの分析手法はそれぞれ以下のようなものです。5つのうち一般的にリスク分析で使われるのは、感度分析と発生確率・影響度マトリックスのみです。

  感度分析

  結果に複数の要因が関連しているときに、ある要因の変化が結果に対して影響する度合いを定量的に分析する方法。プロジェクトのリスク管理においては、個別リスクや不確定な要素がプロジェクトの成果に影響を与える度合いを数値として分析するために使用される

  クラスタ分析

  複数の変数（項目・属性・次元数）を持つ多数のデータがあるとき、その変数間の相互の関係性を分析する方法

  コンジョイント分析

  顧客が商品を構成する要素（価格・デザイン・機能など）のうち、どの要素をどのくらい重視しているかを定量的に明らかにする手法。主にマーケティング分野において、最適な商品コンセプトを特定するために使用される

  デルファイ法

  技術革新や社会変動などに関する未来予測においてよく用いられ、多数の専門家が他の専門家の意見も相互に参照しながら意見交換をし、最終的に意見の収束をしていく手法。プロジェクトリスク管理においては、リスク特定の工程で使用されることがある

  発生確率・影響度マトリックス

  各リスクの発生確率と影響度の度合いをそれぞれ「高」「中」「低」などの定性的な言葉、または0.1～0.9などの一般的な尺度で表し、それらの組合せで表現されるマトリクス上に各リスクを分類することで、リスクレベルを定性的に分析する手法

  〔aについて〕
  「定性的分析で使用される」と「分析結果を表としてまとめる」より、発生確率・影響度マトリックスが適切であるとわかります。発生確率・影響度マトリックスは、リスクの発生確率と影響度の組み合わせをマトリックスとして図示したもので、リスクの優先順位を等級付けするために使用されます。
  
  〔bについて〕
  「定量的分析」と「影響が大きいリスクが何であるかを判断する」より、感度分析が適切であるとわかります。感度分析は、それぞれのリスクの影響度を定量的に評価する手法であり、どのリスク事象がプロジェクトにどれだけ影響を与えるかを把握するために使用されます。
  
  ∴a＝オ：発生確率・影響度マトリックス
  　b＝ア：感度分析
  
  
• 移行プロジェクトは、保守契約の期限前に移行を完了させることを目標にしていますが、移行が完了しない場合には、移行完了まで現行の販売支援システムを稼働延長させざるを得ません。この場合、追加の保守費用が発生することになるので、リスクが顕在化したときの保守費用の負担に備えて、コンティンジェンシー予備などで予算を確保しておくことを検討すべきとなります。
  
  ∴追加発生する保守費用の確保