解説

• 〔aについて〕
  〔本プロジェクトの内容〕(2)には、プロジェクトを公式に認可する文書とありますからプロジェクト憲章が該当します。
  
  PMBOK第5版によれば、「プロジェクト憲章は、プロジェクトの存在を正式に認可し、プロジェクト活動に組織の資源を適用する権限をプロジェクト・マネジャーに与えるための文書」とされています。
  
  以下の項目は、プロジェクト憲章に記載する内容の代表的なものとなります。
  • プロジェクトの目的または正当性
  • プロジェクトの目標
  • 前提条件と制約条件
  • 要約予算
  • 任命されたプロジェクト・マネージャー、その責任と権限のレベル
  • スポンサーやステークホルダ
  • WBSは、プロジェクト全体を管理可能な単位に細分化するため、プロジェクト開始後に作成する資料です。
  • プロジェクト開始の際に作成する資料です。プロジェクト憲章より後に作成する資料になります。
  • 正しい。
  • プロジェクトが順調に進んでいるかを評価するための指標を定義した資料です。
  ∴a＝ウ：プロジェクト憲章
  
  
• 本プロジェクトでは、B社の事業開始日という延ばせない納期があるため迅速な意思決定が求められます。このため、部門をまたがる意思決定はトップダウンで行う方針とされています。
  
  本プロジェクトの体制としては、業務チームとITチームがあり、これらの部門を取りまとめる役割であるプロジェクトマネージャは、情報システム部門のD課長となっています。プロジェクトマネージャは情報システム部門に所属しているため、業務チームの内容に精通しているわけではありません。一方、C取締役は、A社のIoT関連事業とITを統括しているため、ITチーム・業務チームの部門間をまたがる意思決定を行う者として適任です。
  
  以上より、C取締役がプロジェクトを統括する理由は「部門間にまたがる意思決定をトップダウンで行うため」となります。
  
  ∴業務とITの両部門にまたがる意思決定をトップダウンで行うこと
  
  
• 〔bについて〕
  ITベンダへ提示する文書、かつ、ITベンダの提案を比較し、依頼先を選定するための文書ですからRFPが該当します。5文字以内ですから「提案依頼書」でも大丈夫かと思います。
  
  RFPは、Request For Proposalの略で、日本語で「提案依頼書」と呼ばれています。発注側の要件を正しく伝え、ベンダからの提案が的を射たものにするために作成する資料です。記載する内容として下記のものが挙げられます。
  • システムの目的や背景
  • 予算、スケジュール
  • 業務要求
  • 必須機能
  • 運用、保守
  • 成果物
  類似のものとして、RFI(Request For Information)が挙げられますが、こちらは、発注側がベンダに対してどのような会社なのかを知るための情報提供依頼書となります。RFIに対するベンダーからの回答は、既存のサービスや製品の紹介や実績などが想定されます。違いに注意しましょう。
  
  ∴b＝RFP

解説

• 業務のイメージを把握するために実際に動作させるということから、プロトタイプモデル(プロトタイピングともいう)の開発手法であることがわかります。プロトタイプモデルとは、システム開発の早い段階で、利用者が目に見える形で要求を確認できるような試作品を作成し、実際に動かしながら詳細の仕様を決めていく開発手法となります。
  
  プロトタイプモデルで作成する試作品をプロトタイプといいます。よってcにはプロトタイプが入ります。
  
  ちなみに、開発サイクルを繰り返す類似の開発手法として、アジャイル開発が挙げられますが、それぞれの開発手法の特徴としてはプロトタイプモデルが全体を大雑把に作ってから質を上げていく手法であることに対して、アジャイル開発は、細かい機能ごとに追加的に作り込んでいく開発手法となります。
  
  ∴c＝プロトタイプ
  
  
• IoT関連事業の中期計画では、5年間での売上を5倍に拡大することを目標としています。売上拡大の方策として製品ラインアップ拡充やM&Aが予定されているため、B社基幹システムはシステム稼働後も段階的に拡大していくことが想定されます。
  
  自社でインフラを構築する場合、当初から5年後の規模を見据えてシステムを構築するのでは無駄が生じますし、段階的に増強するとしてもその度に時間やコストがかかります。この点、クラウドサービスでは利用規模に合わせて柔軟に変化させることが可能です。
  
  以上2点より、B社がクラウドサービス上での運用を採用した理由は、「売上規模の拡大に合わせて、動的にシステムの規模を変化させられるから」であると判断できます。
  
  ∴d＝今後の売上規模の拡大にあわせて，柔軟にシステムを拡張すること
  
  
• Xパッケージに投入できるデータ形式は、Xパッケージに仕様によって規定されています。よって、移行プログラムにはA社基幹業務システムのデータを、Xパッケージの投入データ形式に変換する処理が必要になります。eは10文字以内であり、すぐ前が「Xパッケージに合わせた」となっているので、データ形式への変換が入ります。
  
  ∴e＝データ形式への変換

解説

• 表1のリスク管理表には、業務チームのXパッケージに関する知識不足がリスクとして挙げられており、このリスクに対してプロジェクト準備フェーズで対策できることが問われています。また、リスクNo.1のリスク対応戦略が「軽減」であり、転嫁、受容ではないことにも注目し、知識不足を軽減すること、つまり従業員の知識不足を補う施策が回答となります。
  
  パッケージ提供元のX社のサービス部門では、Xパッケージに関する充実した教育コースを提供しているため、これを従業員教育に利用できます。事前に業務チームの従業員に知識をつけることで、知識不足によって適用設計フェーズが遅延する確率を下げられます。
  
  ∴Xパッケージの教育コースを業務チームに受講させる
  
  
• PMBOK第5版によれば、マイナスのリスクへの対応策には以下の4つがあります。

  回避

  リスクを完全に取り除く戦略です。情報漏洩リスクに対して、そもそも情報を持たないこと等が当てはまります。

  軽減

  リスク発生の確率や発生した場合の影響度を下げる戦略です。自動車事故に対して、速度を落とすことなどが当てはまります。

  転嫁

  リスクが避けられない場合、リスク発生時の責任を他者に渡す戦略です。自動車事故に対する自動車保険などが当てはまります。

  受容

  リスク発生の可能性が低く影響度も低い場合、あえて対策を行わず、リスクが発生した場合は受け入れることを容認する戦略です。

  残る選択肢の、活用、強化、共有は、受容と合わせてプラスのリスク(好機)に対する戦略になります。
  
  本文中には、fの戦略を選択した理由として「脅威を全て除去することは困難であり，かつ，発生確率も低いことから」とあります。リスクの大きさを表すリスクレベルは「影響度×発生確率」で表されるので、発生確率が非常に低いリスクはリスクレベルも低いと評価されます。またコンティンジェンシー予備は、既知のリスクが顕在化したときに対応するための予備費用ですので、コンティンジェンシー予備の確保をリスク対応策にしているということは、表1以外のリスクに対してはあえて何もしないリスク受容を選択したと判断できます。
  
  ∴f＝オ：受容