PMプロジェクトマネージャ試験 午後Ⅰ

平成29年度春期 プロジェクトマネージャ 午後Ⅰ 問3

事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。

問題

問3 単体テストの見直し及び成果物の品質向上に関する次の記述を読んで、設問1~4に答えよ。 卸売業 D社は、仕入れ、在庫、販売及び請求の管理業務に使用する基幹系システムを10年前に自社の情報システム部で開発し、その後は半年サイクルで、継続的に情報システム部で改修を行っている。今回の改修内容は、機能Fの管理項目の追加、機能Gのユーザビリティ向上に係るインタフェース仕様の改訂、及び機能Hの帳票様式の変更である。長期にわたり本システムを担当している情報システム部のE課長が、今回の改修案件もプロジェクトマネージャ(PM)に任命された。E課長は機能ごとにチームを割り当ててプロジェクトを進めることにした。 本システムは、長年の改修を経て、プログラム及びデータ構造が複雑になってきており、設計・製造の難易度が高まっている。また、改修においては過去に作成したモジュールを活用することが多いので、テストによってバグが摘出された際には、他のモジュールにも類似バグが内在しているかどうかを調査する必要があることも多い。さらに、タイミング誤りなどのバグが摘出された場合にはプログラムが異常終了してしまい、後続のテストが実行できない場合もある。そこで、スケジュールにはリスクに応じた余裕日数を含め、必要な期間を確保している。 〔設計方法〕 D社はウォータフォールモデルの開発方式を基本としている。 外部設計工程では、担当者が既存の外部設計書を改訂したり、外部設計書を新たに作成したりする。チームリーダが外部設計書をレビューした後、チーム横断的に調整した機能間のインタフェース仕様などを含め、外部設計書の最終確認をPMが行う。その後、利用部門から外部設計書の承認を受ける。外部設計工程の各作業を行う際には、長年の改修実績や経験から、内部仕様に係る内容や内部設計時の考慮事項に関するコメントが出ることがある。その場合、それぞれのタイミングの議事録にこれらのコメントを記録した上で、外部設計書の承認時に内部設計工程への申し送り事項一覧として整理している。 内部設計工程では、担当者がまず影響調査を行う。その際、外部設計書の改訂箇所及び新規作成箇所を参照し、過去の類似改修案件での知見も生かして、外部設計書と内部設計書の対応関係を確認した上で、既存の内部設計書の改訂箇所及び新規作成箇所を特定する。次に、内部設計工程への申し送り事項一覧を参照しつつ、内部仕様を検討して、既存の内部設計書を改訂したり、内部設計書を新たに作成したりする。改訂又は新たに作成した内部設計書については、チームリーダが改訂内容及び新規作成内容をレビューし、PMが最終確認を行う。 〔製造及びテスト方式〕 D社では、単体テスト、結合テスト、総合テストに対して、それぞれテスト計画とテストケースを作成し、テストを行う。単体テスト計画と単体テストケースは、製造時にプログラム仕様を作成したタイミングで、プログラム仕様に基づき作成する。結合テスト計画は、内部設計工程で作成し、結合テストケースは、単体テスト完了後に、内部設計書に基づき作成する。 各テストでは作成した全てのテストケースを実施してバグを摘出し、バグ内容の確認・修正を行い、さらに類似バグの調査・修正を行った上で、バグが摘出されたテストケースの再実施を通じてバグが修正されたことを確認する。この過程において、テストの効率を高めるために、①ある種のバグが摘出された場合は、テストケースの実施を一時的に中断し、バグ内容の確認・修正などを行うことにしている。 なお、バグの内容及び修正方法によっては、バグが摘出されなかったテストケースを再実施したり、場合によってはテストケースを追加したりすることもある。また、製造時やバグへの対応時に、設計内容の誤りが発見される場合も少なくないので、その場合は構成管理プロセスに従って迅速に内部設計書や外部設計書を修正することを徹底させている。 〔今回の改修案件における単体テストの実施方針〕 D社では、最近の改修案件において、単体テストで摘出されるべきバグが結合テストで摘出される、D社内でバグの見逃しと呼ぶ現象が増えてきていた。E課長は、バグの見逃しの増加を問題と捉えて、単体テストのやり方を見直すことにした。 これまでの単体テストケースの多くは、プログラムの内部構造に基づきテストケースを作成する【a】テストを採用していた。その上で、利用者の視点でプログラムの外部から見た入出力に基づきテストケースを作成する【b】テストも採用していた。また、改修箇所が他の箇所に影響していないかどうかを確認するためのテストケースも作成してきた。 E課長は、今回の改修案件では、改修箇所の他の箇所への影響確認を行うテストを充実させる必要があると考えて、テストケースを追加作成することにした。また、今回の単体テストの見直しの成果を評価するために、結合テスト完了後にある分析を行うことにした。 〔単体テストの実施〕 E課長はこのようにテストケースを追加作成した単体テストを実施し、テスト実施状況を機能単位で管理した。 テスト実施期間は、テストの効率と、過去の同レベルの難易度・規模の改修案件のバグ密度の実績に基づき、ある条件を考慮してバグ密度の管理目標を設定し、そこから実働16日間とした。初めの12日間で、ある種のバグは摘出後すぐに修正しながら、作成した全てのテストケースを実施し、残りの4日間で残り全てのバグの修正、類似バグの調査・修正、及び再テストを実施するスケジュールであった。初めの12日間のバグ修正件数の管理目標は70~90件であり、結合テスト開始に対する余裕日数は3日間あった。 テスト開始後12日間経過した時点で、作成した全てのテストケースが実施された。その時点での機能Fの単体テストの品質状況は表1に示すとおりであった。 表1 機能Fの単体テストの品質状況 E課長は、初めの12日間はスケジュールどおりに実施できたが、表1の結果から、今後遅延リスクが顕在化して、機能Fの単体テストがスケジュールどおりには完了しない可能性が高いと考えた。一方、機能G、機能Hの単体テストはスケジュールどおりに完了する見込みであった。 そこで、機能Fで発生しているバグの内容を確認したところ、バグを作り込んだ原因が明確であり、局所的であると判断できることから、品質状況には問題がなかったので、遅延リスクについて詳細に分析した。その結果、摘出されたバグの修正は平易であるので個々の修正工数は大きくないが、再テストに要する工数が大きいので、テストの効率を考えると、実施に6日間掛かる見込みであることが分かった。 これらから、E課長は遅延リスク対応策として、機能Fの単体テスト期間を2日間延長することにした。 〔成果物の品質向上〕 その後、単体テストは見直した計画どおりに完了した。E課長は今後の改修案件において成果物の品質向上に向けた対処をするために、外部設計工程から単体テストまでの作業及び成果物について詳細に分析を行ったところ、次に示す結果が明らかになった。 分析結果1:内部設計工程において、既存の内部設計書の改訂箇所及び新規作成箇所の特定に漏れが発生していた。 分析結果2:内部設計工程において、外部設計工程で出た内部仕様に係る内容や内部設計時の考慮事項に関するコメントは適切に取り込まれていた。 分析結果3:改訂及び新たに作成した外部設計書、内部設計書について、記載の誤り、定義内容の誤り、相互の不整合は少なかった。 分析結果4:処理の論理的誤り、データ定義の誤り、インタフェース仕様の実装誤りなどの製造不良は少なかった。 これらの分析結果から、E課長は、今後の改修案件の内部設計工程において追加のレビューを行い、成果物の品質向上を図ることにした。 設問1 〔製造及びテスト方式〕について、(1)、(2)に答えよ。 (1) 結合テストケースを内部設計工程ではなく、単体テスト完了後に作成する意図は何か。45字以内で述べよ。 (2) 本文中の下線①について、どのようなバグが摘出された場合に、テストケースの実施を一時的に中断し、バグ内容の確認・修正などを行っているのか。20字以内で述べよ。 設問2 〔今回の改修案件における単体テストの実施方針〕について、(1)~(3)に答えよ。 (1) E課長はバグの見逃しの増加をなぜ問題と捉えたのか。25字以内で述べよ。 (2) 本文中の【a】、【b】に入れる適切な字句を答えよ。 (3) E課長は結合テスト完了後にどのような分析を行い、どのように単体テストの見直しの成果を評価しようとしたのか。分析対象を15字以内で述べよ。また、期待した評価結果を20字以内で述べよ。 設問3 〔単体テストの実施〕について、(1)、(2)に答えよ。 (1) バグ密度の管理目標を設定する際に考慮した条件は何か。25字以内で述べよ。 (2) E課長がテスト開始後12日間経過した時点で、表1の結果から今後遅延リスクが顕在化する可能性が高いと考えた根拠は何か。35字以内で述べよ。 設問4 〔成果物の品質向上〕について、成果物の品質向上を図るために、今後の改修案件の内部設計工程においてどのようなレビューを追加するのか。30字以内で述べよ。
表1 機能Fの単体テストの品質状況。機能Fの単体テストについて、摘出バグ件数、修正済みバグ件数、テスト対象ステップ数、バグ密度の管理目標を示す表。
表1 機能Fの単体テストの品質状況。機能Fの単体テストについて、摘出バグ件数、修正済みバグ件数、テスト対象ステップ数、バグ密度の管理目標を示す表。
解き方のヒントを見る

判断の前提と対象範囲をそろえる

システム改修に関する判断では、用語の印象だけで結論を急がず、その判断がどの前提と対象範囲に基づくかに注目しましょう。与えられた情報の中で、明示された条件と自分が補った条件を分けて整理することが手掛かりになります。

この問題で問われていること

検討の焦点は、判断の前提が与えられた条件とそろっているかです。記述や数値などを扱うときも、対象範囲を自分の思い込みで広げたり狭めたりしていないかを確かめ、条件の明示されていない部分は決めつけずに考えましょう。

視点

判断の前提とは、考えを進める際に土台として扱う条件です。明示された条件と自分で補った条件を区別すると、どこまでが与えられた情報に基づく考えなのかを整理できます。

確認ポイント

  • 判断の土台にした条件は、どこに示されていますか。
  • 対象範囲を、示された条件に沿って捉えていますか。
  • 明示されていない条件を、自分で補っていませんか。
正解と解説を見る

解説

単体テストで必要なバグを早期に摘出して後工程の手戻りを抑え、テストケースの追加に応じた管理目標を設定することが要点です。摘出バグ密度から遅延リスクを捉え、設計変更箇所の特定漏れを防ぐレビューにつなげます。

問題の全体像

D社は、長年改修してきた基幹系システムの三つの機能を変更する。プログラムやデータ構造が複雑になり、単体テストで摘出すべきバグが結合テストで見つかる現象が増えていた。E課長は影響確認のテストケースを追加し、摘出状況からスケジュールを見直した上で、設計工程の改善策を検討する。公式の出題趣旨では、テストの見直しと、バグ・作業・成果物の分析を通じた品質向上策の立案能力を問うとしている。バグ件数の大小だけでなく、どの工程で摘出すべきか、何が発生原因かを読み取ることが重要です。

設問1(1)

着目するのは、結合テストケースを内部設計書に基づいて作成することと、製造時やバグ対応時に発見した設計誤りを設計書へ迅速に反映することです。内部設計工程でケースを作成すると、その後の設計修正に伴ってケースも修正する手戻りが生じる。単体テスト完了後なら、修正を反映した内部設計書を利用できる。公式解答例では、この手戻りの削減を意図としている。45字以内では「内部設計後に発見した設計内容の誤りを修正した内部設計書を利用して手戻りを減らすため」とまとめられる。

設問1(2)

冒頭に、タイミング誤りなどによってプログラムが異常終了し、後続のテストが実行できない場合があると記されている。この状態では予定したテストを進められないため、先にバグ内容を確認・修正する必要がある。公式解答例では、バグの種類の名前ではなく、テストへの影響を示して「後続のテストが実行できないバグ」としている。この表現で20字以内に収まる。

設問2(1)

本文でいう「バグの見逃し」は、単体テストで摘出すべきバグが結合テストまで残ることです。ウォータフォールモデルでは、後工程で発見するほど前工程の成果物の修正や再テストが発生し、手戻りが増える。公式解答例では「手戻りが増え、テストの効率が下がるから」としており、25字以内ではこの二つの要素を押さえる。採点講評でも、類似バグや異常終了そのものへの着目ではなく、後工程でのバグ摘出による手戻りに着目してほしかったと述べている。

設問2(2)(a)

空欄aの直前にある「プログラムの内部構造に基づきテストケースを作成する」が判断根拠となる。内部の処理や分岐などに着目してケースを設計する方式は、ホワイトボックステストです。公式解答例でもaは「ホワイトボックス」としている。空欄の後に「テスト」があるため、記入する字句は「ホワイトボックス」となる。

設問2(2)(b)

空欄bでは「利用者の視点」と「プログラムの外部から見た入出力」に着目する。外部から与える入力と、それに対して得られる出力を基にケースを設計する方式は、ブラックボックステストです。公式解答例でもbは「ブラックボックス」としている。空欄には「ブラックボックス」を記入する。

設問2(3)(分析対象)

見直しの目的は、単体テストで摘出すべきバグが結合テストで見つかる現象を減らすことです。したがって、結合テスト完了後には、そこで摘出されたバグについて、この見逃しに該当するものを分析する。公式解答例の分析対象は「バグの見逃しと呼ぶ現象」であり、15字以内に収まる。結合テストで摘出されたバグ全体ではなく、本文で定義された見逃しを対象とする点を押さえる。

設問2(3)(評価結果)

影響確認のテストケースを追加したことで、従来は結合テストまで残っていたバグを単体テストで摘出できれば、見直しの成果があったと判断できる。そのため、分析対象であるバグの見逃しを過去の改修案件と比較する。公式解答例では「過去の改修案件よりも減っている。」としている。20字以内ではこの比較結果を示し、バグの総数が減ることや見逃しが完全になくなることまで条件にしない。

設問3(1)

過去の同程度の難易度・規模の実績に加えて考慮すべきなのは、今回、影響確認のテストケースを追加したことです。同じプログラム規模でもケースを増やすと、従来見逃していたバグを摘出でき、摘出バグ密度が高くなることが想定される。公式解答例では「単位ステップ数当たりのテストケースの追加量」としており、25字以内で条件を示せる。採点講評でも、ケースの追加によってバグ摘出が増えることを理解してほしかったと述べている。

設問3(2)

表1の摘出バグ件数180件をテスト対象12kステップで割ると、摘出バグ密度は15件/kステップとなり、管理目標の上限12件/kステップを超えている。想定より多くのバグが摘出され、残り期間に行う修正・類似バグ調査・再テストの負荷が増えるため、遅延リスクが高いと判断できる。一方、修正済み80件は管理目標70~90件の範囲内です。公式解答例に沿った35字以内の要点は「摘出バグ密度がバグ密度の管理目標の上限を超えているから」となる。

設問4

分析結果1では、内部設計書の改訂箇所と新規作成箇所の特定に漏れがあった。一方、申し送りの反映、改訂・新規作成した設計書の内容、製造品質には大きな問題がなかった。そこで、追加レビューは変更対象を特定するための影響調査に向ける。本文では、外部設計書と内部設計書の対応関係を確認して変更箇所を特定するため、その確認状況をレビューすることで漏れの防止につながる。公式解答例では「外部設計書と内部設計書の対応関係の確認状況」としており、30字以内ではこのレビュー対象を示します。

学習のポイント

バグの見逃しと手戻りの関係、テスト追加による摘出量の変化、設計書の対応関係と変更範囲の確認を学びましょう。

出典:独立行政法人 情報処理推進機構(IPA)平成29年度春期 プロジェクトマネージャ試験 午後Ⅰ 問3(公式資料:問題冊子(PDF) / 解答例 / 採点講評)

関連する過去問一覧

IPA Advancedは非公式の学習サイトです。解説にはAIによる補助生成を含む場合があります。公式の問題冊子・解答例・採点講評を優先し、誤りは確認後に訂正します。運営・編集方針