プロジェクトマネージャ 2010年 午後1 問01

解答の導き方

誤りやすいポイント

• E社システムに稼働実績がないことから、要件の追加や変更が頻発すると考えてしまうことがあります。ここで問われているのは、実稼働後に表面化する障害への対応です。
• 「追加の作業」を、開発工程で行うテストや設計変更と捉えないようにします。本文では、本番稼働の実績が不足していることが、その作業の発生理由として示されています。
• 「障害対応」だけでは範囲が広いため、稼働開始直後に発生する障害、つまり初期障害への対応と具体化することが大切です。

FAQ

解答の導き方

1. 問われているのは、用語集を作ること自体の効果ではなく、それによってC社が得るメリットです。本文には、D課長が「外部設計以降の開発作業におけるC社にとってのメリットを考え」たとあります。したがって、用語集がその後の開発作業にどう役立つかを考えます。
2. 用語集に載せるのは、「E社特有の用語を収集して解説した」ものです。新システム担当にとって、E社特有の用語はなじみが薄く、意味を知らないままでは、E社システムの機能や設計内容を理解しにくくなります。用語の意味を調べられるようにしておけば、用語の確認にかかる時間を抑え、内容への理解を早められます。
3. 外部設計以降の開発では、E社システムを基に新システムを構築します。担当者がE社特有の用語を理解していれば、設計内容を把握しやすくなり、関係者とのやり取りでも認識のずれが起きにくくなります。その結果、C社側の担当者が開発作業にスムーズに加われるため、開発の立ち上がりを円滑にする効果もあります。

誤りやすいポイント

• 用語集を作成することが、E社側の作業を助ける効果だけに注目しないようにします。設問はC社にとってのメリットを尋ねているため、新システム担当の理解や開発作業への貢献に結び付けます。
• 用語集の作成を、単なる記録や資料作りとして捉えないようにします。用語の意味を共有することで、システム理解を促し、担当者間の認識のずれを抑える点が重要です。
• 「開発規模を小さくできる」「要件定義が早く終わる」など、本文で用語集の効果として述べられていない内容に広げないようにします。

FAQ

解答の導き方

誤りやすいポイント

• 「スケジュールが遅れること」だけを書くと、遅れにつながる原因が不足します。改修量や開発規模の拡大が原因であることを押さえます。
• CIOに協力を要請すること自体は、リスクではなくリスクを軽減するための対応です。
• E社システムの機能不足を補うリスクと捉えるのではなく、利用部門の変更要望によって改修が増えるリスクと考えます。
• 品質上の問題ではなく、要件や変更の増加による開発規模の膨張に着目します。

FAQ

解答の導き方

誤りやすいポイント

• 「プロトタイプを作るから」とだけ答えると、精度の高い要件定義につながる理由が示せません。利用部門が何を確認できるのかまで説明します。
• 開発期間の短縮や開発規模の縮小を、プロトタイプを作る直接の理由として答えないようにします。設問が尋ねているのは、利用部門が要件を正確に定められる理由です。
• プロトタイプを完成版と同一視しないようにします。ここでは、利用部門がシステムの操作や特徴を具体的に把握するための手段として捉えます。

FAQ

解答の導き方

1. 下線③では、品質評価に用いるステップ数を「新規に開発又は修正したステップ数」だけにせず、条件に該当するプログラムのステップ数も一定割合加えると説明しています。したがって、問われているのは、新規開発・修正部分そのものではなく、それ以外で加算対象となるプログラムの条件です。
2. その理由は、テスト密度や障害密度を「新規に開発又は修正した部分の全体への影響を加味して適切に評価するため」です。変更した箇所だけでなく、その変更の影響が及ぶプログラムも品質評価に関係するため、加算対象に含めると考えられます。
3. 以上から、条件に該当するのは、新規に開発又は修正した部分の影響を受けるプログラムです。同じ趣旨を、変更部分との関連性が深いプログラムと言い換えることもできます。影響や関連性の薄いプログラムまで一律に加算するのではなく、変更部分と関係するプログラムを対象にする点が重要です。

誤りやすいポイント

• 加算対象を、新規に開発又は修正したプログラムだけだと捉えないようにします。設問では、それらのステップ数に加えるプログラムについて尋ねています。
• 既存のプログラムをすべて対象にすると考えるのも誤りです。本文の目的は、変更部分の影響を加味することであり、影響や関連性のないプログラムまで含めるとは述べていません。
• 「関連性がある」だけでなく、変更部分の影響を受ける、または関連性が深いという条件が伝わるように答えます。

FAQ

解答の導き方

1. 下線④では、障害密度が基準値の上限を超えた機能について、原因分析を踏まえて適切な対応が行われたかを確認するとしています。さらに、原因が開発チームの体制面にある場合には、「結合テストを開始するまでの開発作業の実施状況」を再確認する必要があります。
2. 原因がチームの体制にあるなら、品質上の問題が見つかった機能だけを調べても不十分です。同じチームが担当したほかの機能にも、同じ原因による品質上の問題が及んでいる可能性があるからです。
3. また、問題の影響は機能だけでなく、チームが作成した成果物にも及ぶ可能性があります。そのため、再確認では、当該チームが担当したほかの機能に品質の問題がないことと、当該チームが作成したすべての成果物に問題がないことを確認します。

誤りやすいポイント

• 障害密度が上限を超えた機能だけを再確認することです。原因がチームの体制にある場合、同じチームが担当したほかの機能も確認対象になります。
• テストケースだけを見直すことです。この設問では、結合テスト前の開発作業について、チームの体制面の問題を踏まえて確認することが求められています。
• チームの体制を改善する方法を答えることです。問われているのは改善策ではなく、再確認で何を確認するかです。

FAQ

解答の導き方

1. 問われているのは、障害密度の実績値が基準値の下限を下回る機能について、「十分な品質が確保できている場合」以外に考えられる状態です。障害密度が低いことだけでは、品質が高いとは判断できません。
2. 本文では、下限を下回る機能について、二つの場合のどちらに当たるかを判断するために「テストケースの内容が適切であるかどうかを確認する」としています。テストケースが不適切だったり不足していたりすると、実際には障害が残っていても、テストで発見できないことがあります。
3. したがって、もう一つの場合は、テストが十分に行われず、障害を検出しきれていない状態です。20字以内で表すなら、「テストケースが不足している場合」などが該当します。

誤りやすいポイント

• 障害密度が低いことを、そのまま「品質が高い」と判断しないようにします。テストが不十分な場合も、検出される障害数は少なくなります。
• テストケースの数だけで判断せず、障害を検出できる内容になっているかも確認します。
• 「障害が少ない場合」とだけ答えると、テスト不足によって障害を検出できていないという原因が伝わりません。

FAQ

解答の導き方

1. まず、テスト密度は「単位ステップ数当たりのテストケース数」です。したがって、実績値が基準値の範囲外ということは、対象の機能について、プログラム量に対するテストケース数が基準より多いか少ない状態です。
2. ただし、テスト密度が範囲外だからといって、直ちにテストケースが不適切だとは判断できません。テストケース数が少なくても、必要な条件や処理を網羅していれば十分な場合があります。一方、数が多くても、内容に重複があったり、必要な観点が抜けていたりする可能性があります。
3. 本文では、テスト密度の実績値が基準値の範囲外となる機能について、「テストケースに着目した適切な対応」が行われたかを確認するとしています。そこで、テストケースの内容が妥当かを確認し、必要に応じて再レビューすることが対応になります。

誤りやすいポイント

• テスト密度が基準値の範囲外というだけで、テストケースを単純に増やす、または減らすと決めつけないようにします。まず内容の妥当性を確かめます。
• 障害密度の実績値が基準値の範囲外となる場合の確認と混同しないようにします。この設問では、テスト密度に対して、テストケースに着目した対応を問われています。
• プログラムの修正や障害原因の分析ではなく、テストケースの確認・再レビューが中心です。

FAQ

解答の導き方

誤りやすいポイント

• 「障害発生の都度対応しない」という計画だけに注目し、まとめて対応することで作業の重複を減らせる点を見落とさないようにします。
• 単に「結合テストの後半の方が時間に余裕があるから」と考えるのは不十分です。品質が比較的安定した状態で対応できることや、既存作業への影響が少ないことも理由になります。
• まとめて対応するのは、障害を放置するという意味ではありません。この設問では、対応時期をまとめることによる作業効率上の利点を説明します。

FAQ

解答の導き方

誤りやすいポイント

• 障害の原因や修正方法だけを確認する回答では、納期の観点が抜けています。
• 発生した障害にはすべて稼働開始前に対応すると決めつけると、本文が求める確認を捉えられません。
• 「対応を稼働開始後に回す」だけでは不十分です。そもそも稼働開始時に対応が必須かどうかも確認します。
• 対応の先送りを一律に決めるのではなく、影響や対応内容、必要工数を踏まえて判断することが重要です。

FAQ