プロジェクトマネージャ 2011年 午後1 問04

解答の導き方

誤りやすいポイント

• 見つかった欠陥の修正だけを対策とすることです。設問が問うているのは、欠陥を混入させた前工程に対する品質管理上の対策です。
• 現在の工程でテストを増やすことだけを答えることです。欠陥の混入元が前工程と分かっているため、その工程の成果物を確認する対策が適切です。
• 120%を超えた欠陥数そのものを答えることです。120%は対策を検討する判断基準であり、求められているのは実施する対策です。

FAQ

解答の導き方

1. 下線②は、改修工数の大きな欠陥を分析し、再発防止策を立てることが、なぜ今後の生産性向上につながるのかを問うています。
2. 本文では、結合テスト以降で見つかった欠陥について、「ドキュメントやプログラムの修正」と「その再レビュー・再テスト」に掛かった工数を改修工数として集計しています。つまり、改修工数が大きい欠陥は、修正だけでなく、修正内容の確認やテストにも多くの作業時間を要した欠陥です。
3. そのような欠陥について再発防止策を立てる目的は、同種の欠陥を次の開発で繰り返さないことです。欠陥の混入を防げれば修正作業そのものを減らせます。また、混入した欠陥を早い段階で摘出できれば、後工程での修正や再レビュー・再テストを抑えられます。
4. したがって、改修工数の大きい欠陥を予防し、早期に検出することで、後工程で発生する手戻りの工数を減らせます。この工数削減が、今後の開発の生産性向上につながる理由です。

誤りやすいポイント

• 欠陥の件数を減らすことだけに注目し、修正や再レビュー・再テストに必要な工数を減らす視点を落とさないようにします。
• 再発防止策は、欠陥の混入を防ぐことだけではありません。混入した場合に早い工程で摘出することも含まれます。
• 「品質が向上するから」とだけ答えると、生産性向上とのつながりが不明確です。手戻り工数の低減まで説明することが大切です。

FAQ

解答の導き方

1. 下線③は、静的プログラム解析ツールで摘出したい欠陥のうち、「処理結果や性能には影響しないので、テストでは検出しにくい」ものを尋ねています。機能テストや性能テストでは、実行結果や処理時間を確認します。そのため、プログラムを実行しても表面化しない問題は、通常のテストだけでは見つけにくくなります。
2. 一方、本文では静的プログラム解析ツールについて、プログラムを実行せずにソースコードを解析し、「欠陥のおそれ、脆弱性、開発標準に対する違反など」を指摘すると説明しています。つまり、実行結果や性能だけでは判断しにくい、ソースコードの性質に関する問題も見つけられます。
3. その代表が、変更や修正を難しくする保守性に関する欠陥と、脆弱性につながるセキュリティに関する欠陥です。通常の機能テストで期待どおりの結果が出ても、コードが保守しにくい状態であることや、特定の条件で悪用される脆弱性があることまでは分からない場合があります。

誤りやすいポイント

• 「テストでは検出しにくい」を、「どのようなテストでも検出できない」と捉えないようにしましょう。ここでは、処理結果や性能を確認する通常のテストだけでは見つけにくい欠陥を指しています。
• 静的プログラム解析ツールが扱うものとして、本文にある「脆弱性」からセキュリティの問題を読み取ります。
• 保守性に関する欠陥は、機能の誤りや性能低下が起きていなくても存在し得ます。処理結果だけで欠陥の有無を判断しないことが大切です。

FAQ

解答の導き方

誤りやすいポイント

• 「品質を高めるためにテストを増やす」のような一般的な対策だけを書くと、設計時点の理解不足という原因に対応していないため、答えとして弱くなります。
• 担当者の能力不足と決めつけず、本文にある「周辺の機能、ライブラリに関する理解が不十分」という原因に沿って考えます。
• 模範解答にある対策例を両方とも書かなければならないわけではありません。原因に対応する対策を一つ選びます。

FAQ

解答の導き方

誤りやすいポイント

• 詳細設計で摘出した欠陥の総数だけを見て、前工程に原因があったと判断しないようにします。欠陥を「摘出した工程」と「混入した工程」は分けて確認します。
• 前工程で混入した欠陥数は、表の詳細設計の列から、要件定義と基本設計の行を取り出して合計します。
• 計画値との比較では、単に実績が計画を上回ったかではなく、本文にある「計画値の120%を上回った場合」という基準に達したかを確認します。

FAQ

解答の導き方

1. まず、表1と表2では、欠陥を「どの工程で混入したか」と「どの工程で摘出したか」を分けて整理しています。行が混入工程、列が摘出工程です。この区別が、監視する数値を考える手掛かりになります。
2. 詳細設計で摘出した欠陥の総数は、計画の240件に対して実績が347件です。ただし、表2の内訳を見ると、そのうち前工程で混入した欠陥は、要件定義で混入したものが4件、基本設計で混入したものが30件です。計画値もそれぞれ4件、32件なので、前工程で混入した欠陥が大幅に増えたとはいえません。
3. そのため、本文では、詳細設計の摘出総数が計画を大きく上回った差異は「前工程の問題によるものではない」と判断しています。表2では、詳細設計で混入し、詳細設計で摘出した欠陥が、計画の204件に対して実績は313件です。つまり、詳細設計で混入した欠陥が多かったことが、詳細設計の摘出総数を押し上げたと考えられます。
4. しかし、本文には「詳細設計で混入した多くの欠陥を、まだ十分に摘出しきれていない可能性」とあります。詳細設計の完了後に、詳細設計で混入した欠陥が後続工程でどれだけ見つかるかを確認する必要があります。表2では、その欠陥はプログラム製造・単体テストで25件、結合テストで27件、総合テストで9件摘出されています。
5. したがって、監視すべきなのは、後続工程で見つかった欠陥のうち、混入工程が詳細設計である欠陥の数です。

誤りやすいポイント

• 後続工程で摘出した欠陥の総数を監視すると、基本設計やプログラム製造で混入した欠陥も含まれます。詳細設計で混入した欠陥の残存状況を把握するには、混入工程を区別する必要があります。
• 詳細設計で摘出した欠陥の総数を監視するのではありません。問われているのは、詳細設計の完了後に見つかる、詳細設計で混入した欠陥の数です。
• 「混入工程」と「摘出工程」を取り違えないようにします。欠陥を作り込んだ工程と、欠陥を発見した工程は別の場合があります。

FAQ

解答の導き方

誤りやすいポイント

• aを「プログラム」とし、bを「ドキュメント」とするなど、文中で挙げられている修正対象の順序を取り違えないようにします。
• cは、修正そのものではなく、修正後に正しく直ったかを確認する作業です。「再レビュー・再テスト」や、それらをまとめた「検証」が該当します。
• dは、欠陥の原因や修正方法ではありません。基本設計の修正によって、どこまで修正が必要になるかという「影響範囲」の見極めを指します。
• 欠陥の件数だけで改修の大きさを判断しないようにします。表3では、基本設計で混入した欠陥は22件ですが、改修工数合計占有率は47.7％に達しています。

FAQ

解答の導き方

1. 本文では、基本設計で混入し、結合テスト以降で摘出した22件の欠陥を対象に、「なぜ混入したのかという観点」と、もう一つの観点から精査するとあります。したがって、問われているのは欠陥が混入した理由とは別の分析視点です。
2. これらの欠陥は、基本設計のレビューで見つけられず、後の工程で摘出されたものです。そこで、欠陥を混入させた原因だけでなく、レビュー時に見つけられなかった理由も調べる必要があります。
3. 精査の結果は、来季モデル開発のレビュー計画に改善策として組み込むとあります。レビューで欠陥を摘出できなかった原因を分析すれば、レビュー方法の見直しにつなげられます。このため、もう一つの観点は、なぜレビューで欠陥を摘出できなかったかという観点です。

誤りやすいポイント

• 「なぜ混入したのか」という観点を、もう一つの観点として答えてしまうことです。本文では、それとは別の観点を問われています。
• 欠陥の混入防止だけに注目することです。設問では、レビューで摘出できなかった理由を分析し、レビュー計画の改善につなげる点が重要です。
• 「レビューを改善する」とだけ答えることです。問われているのは改善策そのものではなく、欠陥をレビューで見つけられなかった理由を調べる観点です。

FAQ

解答の導き方

1. まず、Y課長が何を防ごうとしているのかを確認します。本文には「同種の欠陥が混入することを予防するために」とあります。したがって、評価ミーティングで行うことは、今季モデル開発で見つかった欠陥への対応だけではなく、来季モデル開発で同じ欠陥を再び混入させないための活動です。
2. 次に、共有する情報を確認します。基本設計で混入し、結合テスト以降で摘出した「22件の欠陥」について、Y課長は、混入した理由などを精査してレポートにまとめています。このレポートには、再発防止に役立つ分析結果が含まれています。
3. さらに、評価ミーティングには今季モデル開発の「メンバ全員が参加」します。同じメンバで来季モデル開発を行うため、精査結果を全員に伝え、欠陥の原因や注意点を共有すれば、各メンバが同種の欠陥を混入させないようにできます。
4. したがって、Y課長が実施すべきことは、メンバ全員で精査結果のレポート内容を共有することです。

誤りやすいポイント

• 欠陥を混入させた担当者だけにレポートを見せることだと考えないようにします。本文では、メンバ全員が参加する評価ミーティングを活用するとしています。
• レポートを作成すること自体を答えにしないようにします。本文では、すでに精査結果をレポートにまとめているため、その内容をミーティングでどう活用するかが問われています。
• レビュー計画の改善と混同しないようにします。レビュー計画への反映は、基本設計のレビューを改善するための別の対策です。この設問では、同種の欠陥の混入を予防するためにメンバ全員で行うことを答えます。

FAQ