システムアーキテクト試験 2009年 午後1 問03

模範解答の核心キーワード・論点整理

解答がそうなる理由の論理的説明

aの解答：「パッケージの仕様どおりに動作すること」

「カスタマイズを行っていない機能については a を含めて確認する。」

「カスタマイズを行っていない機能を含め、システム全体の機能について、業務が確実に遂行できることを確認する。」

bの解答：「対応期限が到来している障害が解決していること」

「H氏は各チームが管理している障害管理票の内容の報告によって、bを確認し、当日のテストが開始できる状態になっているかどうかを判断する。」

「障害管理票には対応の要否、対応の内容、予定工数、優先度、＜c＞、＜d＞ を追記する。」

受験者が誤りやすいポイント・ひっかけの理由

• aの設問で「仕様どおりに動作すること」を確認する対象がカスタマイズしなかった機能も含むことを見落とす
  →「カスタマイズしていない機能も含めて確認する」という記述を正確に理解していないと、変更部分のみ検証すれば良いと誤解しやすい。
• bの設問で単に「障害がないこと」や「障害の状況の報告」で満足する誤り
  →「対応期限が到来している障害の解決が必須」という具体的な条件を確認することがポイント。単に障害が存在するとか報告されているだけでは不十分。

試験対策として覚えておくべきポイント

1. システム適格性確認テスト（サイクルテスト）の目的は、カスタマイズ部分だけでなくパッケージ全体の仕様どおりの動作確認も含むこと。
   →「カスタマイズしなかった機能も含めて」検証対象だと理解する。
2. テスト運営において、テスト開始前は「対応期限の迫った障害が適切に解決しているか」を必ず確認する。
   →未解決障害があるとテスト進行に支障をきたすため、この確認は必須。
3. 障害管理票には詳細な情報を記入し、関係者全員で管理・共有することが品質管理上重要。
4. テストの朝会・夕会は、進捗管理や課題管理、障害対応の指示伝達の重要な場であることを認識する。

模範解答の核心キーワード・論点

• c：対応期限
• d：対応担当者

解答になる理由の論理的説明

「障害管理票には、障害が発生した時点で、発生日時、発見者、障害の状況、影響範囲を記入する。
その後、原因、対応の要否、対応の内容、予定工数、優先度、c、d を追記する。
対応が終了した時点で…」

• 対応期限（c）
  障害対応の期限を明確にすることで、いつまでに障害を解決すべきかの目標を設定し、プロジェクトの遅延を防ぎます。
• 対応担当者（d）
  実際に障害対応を担当する責任者を明示することで、対応の漏れや責任の曖昧さを防ぎます。

受験者が誤りやすいポイント・ひっかけ選択肢

• 「障害内容」や「障害の状態」などの項目との混同
  障害内容や状態は発生時や進捗管理で扱う項目ですが、さらに「対応期限」「対応担当者」を管理票に必ず掲げなければ障害対応の指示や管理が機能しません。
  これらは問題文で「予定工数、優先度」に続いて、障害対応の管理のため不可欠と明言されています。
• 対応期限と優先度の混同
  「優先度」は障害の重要度や緊急度を示す指標で、「対応期限」は具体的な対応終了予定日です。問題文では両方別々に記載されているため、両者は異なる管理項目です。
• 役割の混同
  　時として「対応者」ではなく「報告者」や「発見者」など他の関係者と混同しやすいですが、ここで求められているのは「対応担当者」、実際に障害対応を行うチームメンバーを指します。

試験対策として覚えておくべきポイント

• 障害管理票に記載すべき基本項目は、「発生日時」「発見者」「障害状況」「影響範囲」「原因」「対応要否」「対応内容」「予定工数」「優先度」「対応期限」「対応担当者」などがある。
• 特に、「対応期限」と「対応担当者」は障害の対応管理で絶対に欠かせない情報。
• 障害管理票は単なる記録ではなく、進捗管理や対応漏れ防止の手段。必須項目をもれなく記入できているかを意識する。
• 問題文の記述に「予定工数」「優先度」と並列されているため、それに準じた管理指標が連続した書き方で求められる。

参照：問題文抜粋（表2の障害発生時の対応と管理）

模範解答の核心となるキーワードや論点の整理

• テストデータの網羅性の不足
• 「方式1」は現行業務で使用している実データを活用するが、すべてのテストケースをカバーするための多様なデータが不足する可能性がある
• 「方式2」はテストケースに合わせたデータを作成できるため機能確認が十分できると評価されている

なぜ「テストケースを網羅するデータがない可能性がある」が適切な解答なのか

受験者が誤りやすいポイント・ひっかけの選択肢

• 「方式1は入力データの準備が容易」との記載から、「方式1で十分テストできる」と誤解しやすい
  → 実データを利用するため入力準備は容易でも、カバーできるテストケースの範囲には限界があることを理解することが重要
• 「機能の確認は十分にできるか」で「X」とあるため「十分できない」が正解だが、その理由を「作業工数の問題」や「手間の問題」と誤解しないこと
• 逆に「方式2は入力データ作成の負荷がある」が理由で「機能確認が不十分」と混同しない

試験対策として覚えておくべきポイント・知識

• 実業務データをテストに使う場合、網羅性に欠けるのでカバーできないテストケースが存在する可能性がある
• テストデータ作成の方式は「業務効率（準備しやすさ）」と「テスト品質（網羅性・正確性）」のバランスを考慮する
• 機能確認の十分性を評価する際は、網羅性とテストケースの対応が重要な観点
• テスト計画では、テストデータの作成方式、準備負荷、テスト品質向上のポイントを理解した上で検討する必要がある

テストケースを網羅するデータがない可能性がある

模範解答の核心キーワード・論点整理

なぜその解答になるのか（問題文の引用を交えた論理的説明）

１．システム日付の設定に関する問題点

「システム日付を年度の初日である4月1日に設定し、1週間は1日ずつ進め、以降は月次処理などのイベントに合わせてシステム日付を設定し翌年度4月に行う年次集計処理まで行う」

• 1年分の期間設定では、再リース機能の「翌々月の満了通知」および契約の継続（最大5年）を含む状態の確認ができず、カスタマイズに関わらず重要な業務シナリオを網羅できません。

２．障害発生時の対応に関する問題点

• 機能検証チームが障害管理票で障害を管理し、対応終了後に再テストを行う。
• 障害は発生したテストケースごとに管理され、対応期限も明確に管理されている。
• しかし、複数チームの朝会・夕会での障害情報の共有は行われているものの、具体的に重大な障害が発生した場合に他チームへ「即座に」情報連携をする仕組みが明示されていません。

• 重大な障害の発生をリアルタイムに関係チームへ通知・連携する体制やルールがなく、遅延や混乱が生じるリスクがある点にある。

受験者が誤りやすいポイント・ひっかけの注意点

• システム日付の設定問題で「1週間の逐次進行が短すぎる」という誤解
  → 問題は進行期間の長さにあるので、1週間単位のテスト進め方自体は問題ではない。年間シミュレーションが必要な理由を整理すること。
• 障害対応では「障害管理票の活用状況のみ確認すれば十分」と考える点
  → 個々のチーム内での管理はできていても、テスト全体に影響を及ぼす重大障害については、即時の横断的連携が欠かせない。
• カスタマイズ範囲の認識不足
  → システム全体の機能テストを網羅するために、カスタマイズしていない機能の検証も含めて計画する必要がある点に注意。

試験対策として覚えておくべきポイント・知識

1. システムテストにおけるシステム日付設定の重要性と業務期間の網羅性
   • 業務の自然な流れを正確に検証するには、必要な期間をカバーしたシステム日付の設定が必須。特に契約期間や複数年をまたぐ処理は要注意。
2. 複数チームで進めるテストにおける障害連携の仕組みの必要性
   • 重大障害発生時は、即座に全関係者へ情報共有し、影響範囲の把握と対策を講じることが大切。
3. 障害管理票はチーム内の障害管理だけでなく、横断的な情報共有の起点となることも重要。
4. テスト計画のレビューでは網羅性（業務プロセス・期間）と運営管理（障害対応フロー）をチェック。

1. 模範解答の核心となるキーワードや論点の整理

• テストケース確認完了件数の「予定」と「実績」の比較による進捗管理
  → 予定通りにテストが進んでいるかを判断するには、計画（予定件数）と現状（実績件数）を比較することが重要。
• 表3「進捗管理表」における「予定累計件数（オ）」と「実績累計件数（ウ）」の関係
  → 「実績累計」が「予定累計」以上 (ウ ≧ オ) であれば、遅れなく進んでいると判断できる。
• 「ウ」「オ」の値は、テストケース確認完了の累積件数を示す。

2. なぜその解答になるのか（論理的説明）

• 計画（予定）では、第n日で「合計オ件」のテストケース完了を見込んでいる。
• 実績では、第n日までに「合計ウ件」のテストケースが完了している。
• したがって、予定に対して遅れていない（つまりスケジュール通り、もしくは前倒しで進んでいる）とは、「実績累計（ウ）」が「予定累計（オ）」以上であるとき。

判断を行うのに最も必要な数値：ウ、オ
大小関係：オがウ以上であるとき

「テストの消化状況、障害の解決状況は…進捗管理表にまとめ、全員で共有する。」
「進捗管理表にはあらかじめ、テストケースの総件数と毎日の確認完了予定件数を記入しておく。」
「それぞれのテストケースについて、結果が正しいことが確認できたら確認完了とする。」

3. 受験者が誤りやすいポイント、ひっかけの選択肢の解説

• 「予定累計」と「実績累計」のどちらが上位か判断するか混同する
  よくある誤りは「予定値が実績値より大きければ進捗良好」と考えてしまうことですが、実際には「実績値が予定値を超えていれば計画どおり」に進んでいると判断します。
• 「予定」だけを見て判断するミス
  単に当日予定の件数だけを見て進捗良否を判断するのは不十分で、累積で見て遅れが発生しているかどうかを判断すべきです。
• 「障害発生件数」や「障害解決件数」と混同する
  進捗の判断はテストケースの確認完了件数であり、障害発生や解決件数ではありません。混同しないように注意が必要です。

4. 試験対策として覚えておくべきポイントや知識

• 進捗管理は「累積値」を比較して判断する
  テストケース進捗計画では「予定累計」と「実績累計」の大小関係で遅延の有無を把握する。
• テスト計画・管理における用語の整理
  • 「予定」：計画上のスケジュール数値
  • 「実績」：実際に終了した数値
  • 累計：試験開始日からの合計件数
• 表や管理票（例：進捗管理表、障害管理票）の読み取り能力を高めること
  表の各列の意味・役割を正確に理解し、判断基準を明確にする力が求められる。
• 障害管理と進捗管理は別々の管理指標である
  それぞれを混同せずに理解すること。

1. 模範解答の核心となるキーワードや論点の整理

• 判断に必要な数値：ア（総テストケース数）、オ（当日までのテストケースのすべてについて正しい結果が得られたことの確認件数）
• テスト完了の条件は、「当日実施予定のすべてのテストケースについて、正しい結果が得られたことを確認できた場合」
• 「ア」と「オ」が等しいことが、サイクルテスト完了の判断基準となる

2. なぜその解答になるのか（問題文の記述を引用しつつ論理的説明）

テストの完了

当日実施予定のすべてのテストケースについて、正しい結果が得られたことが確認できた場合、当日のテストが完了したと判断する。

• 「ア」＝「総テストケース数」→テスト対象全体の件数
• 「オ」＝「テストケース確認完了の実績累計件数」→合格したテスト件数の累計

3. 受験者が誤りやすいポイントやひっかけ選択肢について

• テスト完了の判断に「障害発生件数」や「障害解決件数」と混同しやすい：
  表3には「障害発生件数」や「障害解決件数」もありますが、テスト完了の判断基準には直接用いません。障害対応中は、そのテストケースは「確認完了とはしない」と明記されているため、障害が残っていれば「確認完了件数」は増えません。
• 単に「予定されたテストケースを実施した件数」と「確認が済んだ件数」の混同
  テストケースを実施した件数（エ・実績など）と、それが合格し正しい結果が確認できたか（オ）では意味が異なります。完了判断は正しい結果の「確認完了件数」が基準です。
• 「ウ」や「イ」など予定と実績の累計を混合して判断しがち
  特に当日の判断では「実績累計（オ）」を見て判断します。予定値はあくまで目安であり、完了には「実績累計」が総テストケース数に等しいことが必要です。

4. 試験対策として覚えておくべきポイントや知識

• サイクルテストの完了条件は「すべてのテストケースで正しい結果が得られたことの確認」である
• 進捗管理では「総テストケース数」と「確認完了件数（実績）」を絶対に比較し、両者が一致していることを確認する
• 障害が発生し、解決していないテストケースは「確認完了」として扱わないため、障害件数と解決件数の管理も重要だが完了判断の直接基準ではない
• テスト計画書や運営要領書に書かれた「完了判断の条件」の文言を正確に読み取り、その基準を理解することが合格のカギ