応用情報技術者 2015年 秋期 午後 問09

解答の論理構成

1. 下線①では「プロジェクトが成功するために満たすべき条件」を列挙すると明記されています。
   引用：
   ・「①機能要件の他に、プロジェクトが成功するために満たすべき条件をプロジェクト目標として定める」
2. 条件は本文中で次の3点に整理できます。
   (1) 期間に関する条件
   • 「本年度末までに稼働する必要がある」
     ⇒ “いつまでに”を示すスケジュール目標。
     (2) 性能に関する条件
   • 「現状の応答時間を維持する必要がある」
     ⇒ システム性能を示す品質目標。
     (3) コストに関する条件
   • 「1,000万円以内で開発」
     ⇒ 開発費用を示すコスト目標。
3. これら3要素はプロジェクト管理の“三大制約（スコープ・コスト・時間）”のうち、スコープ以外の2要素＋品質に対応し、下線①で求める「プロジェクト目標」と判断できます。
4. 以上を20字以内に要約した結果が模範解答の
   ・「本年度末までの稼働」
   ・「現状の応答時間の維持」
   ・「1,000万円以内の費用での開発」
   となります。

誤りやすいポイント

• 「応答時間」の条件を“短縮”と誤記しがちですが、原文は「維持」です。
• 「1,000万円以内」は開発費用の上限であって予備費ではありません。額を変える・四捨五入するなどは不可です。
• スコープ変更手続きやファンクション数など、本文の他情報を目標に混在させると失点します（例：ファンクション数“18”を目標に入れる誤答）。

FAQ

解答の論理構成

1. 問題文には、スコープ管理計画を立案する手順として
   「実現すべき機能の一覧など、プロジェクトの成果物である機能追加された販売システムの特性や要求事項を収集し、aを作成する。」
   とあります。成果物そのものの特性や要求事項をまとめるドキュメントは PMBOK でいう “成果物記述書” です。よって a＝「成果物記述書」(エ) となります。
2. 続いて「これらを基に、bを作成する。」とあります。“これら” には①機能要件とプロジェクト目標が含まれています。要求事項・制約条件を統合し “何を行い何を行わないか” を明確にするのがスコープ記述書です。したがって b＝「スコープ記述書」(ウ) となります。
3. 次に「プロジェクトにおいて必要な作業と成果物を定義し、cを作成する。」とあります。作業と成果物を階層構造で分解したものは Work Breakdown Structure なので c＝「WBS」(ア) です。

誤りやすいポイント

• 成果物記述書とスコープ記述書の混同
  成果物記述書は“物”の説明、スコープ記述書は“仕事”の説明という切り分けを意識しましょう。
• WBS を「体制図」や「ワークパッケージ」と取り違える
  WBS 全体と、その末端要素であるワークパッケージの違いに注意が必要です。
• 記述書＝見積書と早合点するミス
  「見積り」は費用・工数の算定結果であり、スコープ管理のドキュメント群とは別です。

FAQ

解答の論理構成

1. 問題文は、プロジェクトで機能量を定量的に管理する指標として「ファンクション数」を用いることを明言しています。
   引用：「システム部と販売管理部が、機能量を定量的に表す指標として、このファンクション数を用いることで合意している。」
   この時点で、プロジェクト全体の機能量＝ファンクション数合計が管理対象になります。
2. 下線②では、スコープ管理計画をまとめ「ベースラインの定義を加えて…E部長の承認を得る」とあります。
   引用：「②ベースラインの定義を加えてスコープ管理計画としてまとめ、E部長の承認を得る」。
3. ベースラインとは、計画‐実績差異を測る“ものさし”です。よって「機能量」のベースラインに何を設定するか事前合意が必須になります。
4. すでに①で機能量を示す指標が「ファンクション数」であると合意済みなので、プロジェクト全体の基準値は「ファンクション数合計」に設定するのが自然です。個々の機能単位では差異集計が煩雑になり、目的である“全体管理”とずれます。
5. 以上より、E部長と合意すべき事項は「ファンクション数合計を機能量のベースラインとすること」となります。

誤りやすいポイント

• コストや工数をベースラインと誤解し、ファンクション数を忘れる。
• 各機能の個別ファンクション数をベースラインと答えてしまい、「全体」の視点が抜ける。
• ベースライン＝変更不可と決めつけ、差異管理の目的を見落とす。

FAQ

解答の論理構成

1. 予備費の算定
   • もともとの開発費見積りは「総額は750万円」
   • 上限は「開発費用の上限値を1,000万円とし」
   • よってプロジェクト予備費 = 1,000 − 750 = 250万円
2. 追加機能で“高”が付くものの洗い出し
   • 再確認結果
     • 「入荷連絡業務のメール送信機能は…必須の機能とまでは言えない」
       → 優先度は“高”ではなくなる
     • 「予約キャンセル業務の機能は必須となる」
       → 以下3機能は“高”のまま
       ① 引取り期限設定（費用「50万円」）
       ② 指定予約キャンセル（元費用「100万円」）
       ③ 期限切れ予約検索（費用「120万円」）
3. 指定予約キャンセル機能の代替案
   • 「予約履歴データ保存機能を除けば…代替できる」
   • 追加するのは「予約履歴データ保存機能の開発費用を30万円」
   • したがって指定予約キャンセル(100万円) → 代替案(30万円)へ置換
4. 追加開発費の合計
   • 引取り期限設定：50万円
   • 期限切れ予約検索：120万円
   • 予約履歴データ保存：30万円
   • 合計 = 200万円
5. 予備費の残額
   • 残額 = 250 − 200 = 50万円

誤りやすいポイント

• 表3の「100万円」をそのまま足し、代替案の30万円への置換を見落とす。
• メール送信機能が“高”から外れたことを失念し、70万円を加算してしまう。
• 予備費を1,000万円と誤って計算し、元の750万円を引かずに残額を求める。

FAQ

解答の論理構成

• 【問題文】には、変更申請が出た後のプロセスとして
  「D君は、表3の追加費用がプロジェクト予備費を上回るので、追加開発を極力減らしたいと考えた。そこで、予約キャンセル業務のための機能について、代替案の検討を行うことにし、F課長に検討を依頼した。」
  とあります。追加機能が予算超過になるかどうかは費用見積りでわかりますが、採否を判断する材料として“代替策の有無”も重要です。この流れから「代替案の検討」が審議前に行われるべき作業だと導けます。
• また同じ段落の直前で
  「開発期間の見積りを行ったところ、開発期間は1か月で、開発要員を速やかに参加させれば、本年度末までに開発を完了できることが分かった。」
  と明示されており、変更を受け入れても納期に収まるかどうかを判断するため「開発期間の見積り」が不可欠であることが示唆されています。
• したがって、費用見積り以外に必要な準備作業は
  ①「開発期間の見積り」
  ②「代替案の検討」
  となります（いずれも10字以内）。

誤りやすいポイント

• 「進捗の確認」や「リスク分析」も大切ですが、問題文に直接示されておらず根拠が弱いので選択ミスしやすいです。
• 「テスト計画の立案」など開発後工程に目が向きがちで、審議前に行う“判断材料集め”という意図を取り違えるケースがあります。
• “10字以内”を超える長い表現（例：「開発スケジュール見積り」）を書いて減点されることがあります。

FAQ