戦国IT - 情報処理技術者試験の過去問対策サイト
お知らせお問い合わせ料金プラン

応用情報技術者 2016年 春期 午後09


品質評価に関する次の記述を読んで、設問1,2に答えよ。

 P社は、衣料品を全国の店舗で販売している。P社の情報システム部は、競争力強化を目的とした販売アイテムの大幅な増加と販売ポイントサービスに関する機能の拡充のために、商品販売管理システムのサブシステムX、Y、Zへの追加機能の開発を、短期間で行うことになった。商品販売管理システムは、在庫管理システム、経理システムなどの社内システムとデータの送受信を行っている。情報システム部のQ課長は、今回の開発プロジェクトのプロジェクトマネージャ(PM)として、R主任を指名した。   〔プロジェクト開始準備〕  R主任は、サブシステムXの開発に関わる詳細設計・詳細設計レビュー・コーディング・単体テスト・結合テストを請負契約で一括して開発請負会社に発注することにした。サブシステムX、Yの開発については、それぞれ、以前からP社の開発案件を受託しP社の業務仕様を理解しているL社、M社と契約し、サブシステムZの開発については、新規に参入するN社と契約した。N社の実施責任者に現在のコーディング規約を渡して、その内容を説明した。  R主任は、詳細設計書、ソースプログラム、単体テスト項目、結合テスト項目は、各社の手順書に従ってレビューするよう各社の実施責任者に依頼した。各社での結合テスト完了後に、各工程別のテスト成績書による品質判定と納品物の確認を行い、全ての結果が良好と判断されれば後に、総合テスト工程へ進むことにした。  各サブシステムは、開発規模が同程度の二つのモジュールで構成され、モジュール別の開発の難易度は、表1のとおりである。
応用情報技術者試験(平成28年度 午後 問09 表01)
 詳細設計に着手する直前に、次の2項目に変更が入ったので、各社の実施責任者に変更箇所を電子メール〔以下、メールという〕で通知し、開発メンバに周知するように依頼した。  ・在庫管理システムとのインタフェース  ・コーディング規約  さらに、インタフェース仕様書は、他の関連システムにも改修があることから、仕様変更箇所を反映し、各社に再配布した。一方、コーディング規約は、インタフェース仕様書の変更に時間が掛かったことから、プロジェクト完了後に全体を修正することにしたので、再配布はしなかった。  情報システム部が手掛けてきた過去の開発実績のデータに基づき、基本となる工程別の品質判定基準を表2のとおり設定した。
応用情報技術者試験(平成28年度 午後 問09 表02)
 R主任は、品質判定基準を盛り込んだ開発計画書を作成し、Q課長の承認を得てから、自社のプロジェクトメンバ及び各社の実施責任者に開発着手を指示した。   〔品質の評価〕  各社の結合テストが完了後、R主任は、プロジェクトの品質管理担当のメンバから、各社から提出された工程別の品質実績のデータをサブシステム別に整理した表3の報告を受けた。
応用情報技術者試験(平成28年度 午後 問09 表03)
 R主任は、表2の品質判定基準と表3の品質実績から、次のように考えた。  ・サブシステムX及びYは、テスト検度及び欠陥数が、全ての工程で品質判定基準内であった。しかし、サブシステムXは、①表2の工程別の品質判定基準を適用して、追加の分析を行った上で品質を判定すべきである。  ・サブシステムZは、aでのテスト項目不足、又はbの可能性がある。  そこで、R主任は、L社に、追加の分析を依頼した。L社は、分析結果を整理して次のとおりR主任に報告し、Q課長もその結果を了承した。  ・モジュールX1:テスト検度は品質判定基準内であり、欠陥数は品質判定基準を超えているが、開発の難易度を考慮すると品質は良好である。  ・モジュールX2:テスト検度と欠陥数は品質判定基準内であり、品質は良好である。  また、R主任は、N社に、欠陥を工程ごとに、開発メンバ別、モジュール別、本来抽出すべき工程別、作り込み原因別に分析して、その結果を報告するよう依頼した。N社は、分析結果を整理して次のとおりR主任に報告した。  ・特定の開発メンバの力量不足が、欠陥の原因ではなかった。  ・欠陥の82%はモジュールZ1であった。  ・モジュールZ1の欠陥の作り込み原因別の分析では、コーディング規約の違反による欠陥が、単体テストで2件、結合テストで32件抽出された。  ・モジュールZ1の欠陥の工程別分析結果は表4のとおりであった。
応用情報技術者試験(平成28年度 午後 問09 表04)
〔原因分析と再発防止〕  R主任は、N社に対して、モジュールZ1の欠陥について改修し、原因に基づいて単体テストの項目を見直して、再テストを行うよう依頼した。さらに、モジュールZ2 について、コーディング規約の違反が原因で発生した欠陥と同種の欠陥の摘出を行うことによって、品質の確保を行うよう依頼した。  その後、R主任が詳細を調査すると、今回の開発直前に変更した箇所に関係する欠陥が90%であることが判明したので、その結果をQ課長に報告した。  Q課長から、再発防止策を検討するよう指示があったので、まず、R主任は、根本原因分析の技法(以下、なぜなぜ分析という)を使って、分析を実施した。なぜなぜ分析の一部を図1に示す。
応用情報技術者試験(平成28年度 午後 問09 図01)
 そこで、R主任は、根本原因の再発防止策として、コーディング規約などの変更を開発請負会社に通知した場合には、PMが、開発請負会社の実施責任者に、cを確認するよう、開発プロジェクトのルールとして定めることをQ課長に説明した。  Q課長は、次の点についても見直しを行うようR主任に指示した。  ・結合テスト完了時に品質不具合が発覚すると、詳細設計やコーディングにまで遡って対処する必要があるので、deを起こすおそれがある。   したがって、今後、新規に開発に参加する会社と請負契約を締結する場合には、各工程が完了するごとに品質評価結果を提出させることを検討すること。  ・品質が良好であるにもかかわらず、欠陥数が工程別の品質判定基準を超えてしまうという事態が発生した。適切に品質判定ができるよう、fと開発請負会社のスキルレベルを考慮した品質判定基準となるように見直すこと。

設問1〔品質の評価〕について、(1)〜(3)に答えよ。

(1)R主任がL社に、本文中の下線①を依頼した理由を40字以内で述べよ。

模範解答

モジュールごとに品質の偏りがないかどうかを確認する必要があるから

解説

解答の論理構成

  1. 表3ではサブシステムXの「テスト密度」「欠陥数」がいずれも判定基準内でした。
    引用:「サブシステムX及びYは、テスト検度及び欠陥数が、全ての工程で品質判定基準内であった。」
  2. それでもR主任は下線部で「追加の分析を行った上で品質を判定すべき」と判断しました。
    引用:「しかし、サブシステムXは、①表2の工程別の品質判定基準を適用して、追加の分析を行った上で品質を判定すべきである。」
  3. 追加分析が必要な背景は、サブシステムXが難易度の異なる二つのモジュールで構成されている点です。
    引用:「各サブシステムは、開発規模が同程度の二つのモジュールで構成され、モジュール別の開発の難易度は、表1のとおりである。」
    表1より「X1」は“高”、「X2」は“低”と差が大きい。
  4. 難易度差により、サブシステム全体の平均値だけでは品質の偏在を見落とす恐れがあります。そこでL社にモジュール単位の追加分析を依頼しました。
    引用:「R主任は、L社に、追加の分析を依頼した。」
    結果もモジュール別に報告されています(X1とX2を個別評価)。
  5. 以上から、解答は「モジュールごとの品質偏りの有無を確認する必要があるため」と導けます。

誤りやすいポイント

  • サブシステム全体の数値が基準内=合格、と早合点してモジュール間のバラツキを見逃す。
  • 下線①の“表2を適用”を「再計算」と誤読し、理由をテスト密度計算方法の話にしてしまう。
  • L社に依頼したのはXだけであり、Zの欠陥分析はN社が担当。この区別を取り違える。

FAQ

Q: 「追加の分析」とは具体的に何をしたのですか?
A: モジュールX1・X2ごとにテスト密度と欠陥密度を算出し、難易度を加味して良否判断を行いました。
Q: なぜサブシステムYでは同様の分析をしなかったのですか?
A: 表1でY1・Y2の難易度はどちらも“中”で差が小さく、バラツキ懸念がXほど大きくなかったためです。
Q: 難易度が高いと欠陥数が多くても品質良好と評価できるのですか?
A: はい。難しい機能では欠陥が相対的に増えるため、難易度補正を行い“想定範囲内”なら品質良好と判断します。

関連キーワード: 品質判定基準, テスト密度, 欠陥密度, モジュール難易度, 品質評価

設問1〔品質の評価〕について、(1)〜(3)に答えよ。

(2)本文及び図1中のaに入れる適切な字句を10字以内で答えよ。

模範解答

a:単体テスト

解説

解答の論理構成

  1. 【問題文】の該当箇所
    ・「サブシステムZは、aでのテスト項目不足、又はbの可能性がある。」
    ・表3ではサブシステムZのテスト密度が
    • 「単体テスト:118」
    • 「結合テスト:85」
      と示されています。
  2. 【問題文】表2の品質判定基準
    • 「単体テスト」のテスト密度最小値は「150」。
    • 「結合テスト」のテスト密度最小値は「50」。
  3. 判定手順
    • サブシステムZの「単体テスト」密度118は150未満で基準外。
    • サブシステムZの「結合テスト」密度85は50〜100の範囲で基準内。
    • よってテスト項目数が不足している工程は「単体テスト」であると特定できます。
  4. 図1との整合
    • 図1の発生事象にも「a のすり抜け欠陥が多数発生した。」とあり、工程で欠陥が検出しきれなかった状況を説明しています。
    • 以上より a に入る字句は「単体テスト」と結論付けられます。

誤りやすいポイント

  • 表3の「結合テスト」密度85が高めに見えるため、テスト不足を結合テストと早合点してしまう。基準値(50〜100)を照合し忘れるミスが多発します。
  • 欠陥数4.1/kステップ(結合テスト)が基準外なので、“テスト不足ではなく欠陥多発工程だ”と混同し、a を誤記するケースがあります。
  • 図1と本文を別々に読んでしまい、同じaが両方に登場することを見逃すと整合チェックが不十分になります。

FAQ

Q: テスト密度と欠陥数、どちらを優先して判断すればよいですか?
A: 今回は「テスト項目不足」を指摘しているのでテスト密度を主軸に置きます。欠陥数は原因(テスト抜け・作り込み)の特定で補助的に参照します。
Q: なぜ欠陥が多い結合テストではなく単体テストが不足と判断するのですか?
A: 結合テストの密度85は基準範囲内(50〜100)で「不足」とは評価されません。基準外なのは単体テスト118<150のみです。
Q: 図1の「すり抜け欠陥」はどの工程からどの工程に抜けたことを指しますか?
A: 本来「単体テスト」で捕捉すべき欠陥が抜け出し、後工程(結合テスト)まで到達したことを示しています。

関連キーワード: テスト密度, 欠陥密度, なぜなぜ分析, 品質判定基準

設問1〔品質の評価〕について、(1)〜(3)に答えよ。

(3)本文中のbに入れる適切な字句を15字以内で答えよ。

模範解答

b:詳細設計での品質不足

解説

解答の論理構成

  1. 表2では、単体テストのテスト密度の最小値を「150」、欠陥数の最大値を「3」と定めています。
  2. 表3でサブシステムZの単体テストを見ると、テスト密度は「118」で基準を下回り、欠陥数は「1.2」で基準内です。したがって、R主任が指摘した「aでのテスト項目不足」は、テスト密度が不足している単体テストを示します。
  3. 一方、結合テストではテスト密度「85」が基準内にもかかわらず欠陥数が「4.1」で基準の「2」を超えています。テスト項目は十分にあっても欠陥が多い場合、上流工程で不良が作り込まれている疑いが強くなります。
  4. 作り込みが発生する代表的な上流工程は「詳細設計レビュー」であり、表2の欠陥数基準は「3〜7」。表3でサブシステムZの詳細設計レビューの欠陥数は「3.5」で基準内ですが、基準上限寄りであり、結合テストで大量欠陥が露見した点から「設計そのものの品質不足」が疑われます。
  5. 以上より、R主任が挙げた二つ目の原因候補「b」は「詳細設計での品質不足」と判断できます。

誤りやすいポイント

  • 単体テストのテスト密度不足に気を取られ、上流工程の品質問題に思い至らない。
  • 「欠陥数が基準内=問題なし」と早合点し、後工程での欠陥増加との関連を見逃す。
  • 詳細設計レビューの欠陥数が基準内であることから、詳細設計は無関係と誤解する。

FAQ

Q: テスト密度が不足しているだけで欠陥が多いのは普通では?
A: 不足しているのは単体テストだけで、結合テストのテスト密度は基準内です。にもかかわらず欠陥数が基準外という点が「上流で作り込まれた不良」を示唆します。
Q: 詳細設計レビューの欠陥数が基準内なのに、なぜ詳細設計品質不足と判断するのですか?
A: 基準ギリギリであること、そして結合テストで設計由来と考えられる欠陥が集中したことを合わせて考えると、設計品質が十分でなかった可能性が高いからです。
Q: 実装工程の問題ではないのですか?
A: 実装由来であれば単体テストで多くの欠陥が摘出されるはずですが、単体テストの欠陥数は基準内でした。したがって実装よりも設計段階に問題があると推定されます。

関連キーワード: 品質判定基準, テスト密度, 欠陥分析, 上流工程, 詳細設計

設問2〔原因分析と再発防止〕について、(1)〜(3)に答えよ。

(1)本文及び図1中のcに入れる適切な字句を20字以内で答えよ。

模範解答

c:開発メンバが正しく理解したこと

解説

解答の論理構成

  1. 問題文では、根本原因の再発防止策として
    「コーディング規約などの変更を開発請負会社に通知した場合には、PMが、開発請負会社の実施責任者に、cを確認するよう、開発プロジェクトのルールとして定めることをQ課長に説明した。」
    と記載されています。
  2. さらに図1(なぜなぜ分析)の根本原因には
    「コーディング規約の変更をメールで通知しただけで、c を確認するプロセスがなかった。」
    とあります。
  3. つまり、メール通知だけでは不十分であり、PMが「開発メンバが変更内容を正しく理解しているか」を確認する必要がある、という文脈です。
  4. 以上より、c に入る字句は
    解答:開発メンバが正しく理解したこと
    となります。

誤りやすいポイント

  • 「理解させること」「説明したこと」など“行為”を答えてしまい「確認」という要求を外してしまう。
  • 「受領確認」だけでは、資料を受け取った事実の確認に留まり“内容理解”を担保できない。
  • メールで通知しただけという原因を見逃し、会議の開催など別の対策を連想してしまう。

FAQ

Q: “理解”ではなく“周知”ではダメですか?
A: 周知は情報を伝える行為に重点があり、受け手が内容を把握したかまでは保証しません。「正しく理解したこと」を確認するのがポイントです。
Q: 「開発メンバ全員が…」と人を明示する必要は?
A: 問題文の「開発メンバが…理解したこと」という表現に合わせれば十分です。人数や全員といった語は不要です。
Q: 具体的な確認方法(テスト実施やヒアリング)まで書く必要は?
A: 本設問は“何を確認するか”を問うため、方法は不要です。別設問で指示がある場合のみ記述します。

関連キーワード: なぜなぜ分析, コーディング規約, 品質管理, 欠陥原因, 再発防止

設問2〔原因分析と再発防止〕について、(1)〜(3)に答えよ。

(2)本文中のdeに入れる適切な字句を10字以内で答えよ(dとeは順不同)。

模範解答

d:開発コストの増大 e:納期の遅延

解説

解答の論理構成

  1. 問題文では、結合テストの完了時点で欠陥が発覚した場合の影響について
    「結合テスト完了時に品質不具合が発覚すると、詳細設計やコーディングにまで遡って対処する必要があるので、deを起こすおそれがある。」
    と明示しています。
  2. 結合テストは開発工程の後段に位置し、ここで手戻りが発生すると
    – 既に実施したテストをやり直す
    – 設計書・ソース・テスト資源を再修正する
    といった追加作業が発生します。
  3. 追加作業は人件費や外注費を押し上げるため「開発コストの増大」を招きます。
  4. さらに、後工程での修正はスケジュールのバッファを食い潰し、最終的なリリース日を後倒しにします。これが「納期の遅延」です。
  5. 以上より、
    d:開発コストの増大
    e:納期の遅延
    が最も適切な字句となります。

誤りやすいポイント

  • 「品質低下」「信頼性の低下」なども影響として考えられますが、問題文は“コスト”と“スケジュール”の2大制約に直結する語を求めています。
  • d と e が順不同であることを見落として、答案欄を逆に書き写すミス。
  • 「生産性低下」や「工数増大」を選び、コスト・納期という経営指標レベルの言葉に置き換えられなかったケース。

FAQ

Q: 「工数増大」ではだめですか?
A: 本文が「遡って対処する必要があるので」とコスト全体を示唆しているため、経営管理指標の「開発コストの増大」がより適合します。
Q: 「品質低下」が起こるのに、なぜ選ばれないのですか?
A: 質問は“遡り対処の結果”として発生するリスクを聞いており、品質は原因側で既に問題になっているため、影響としてはコストとスケジュールが優先されます。
Q: 順不同とある場合、どちらを d にしても良いのですか?
A: はい。問題が「順不同」と明記しているので、d・e の順序は採点で区別されません。

関連キーワード: 手戻り, コスト増, スケジュール遅延, テスト工程, 品質管理

設問2〔原因分析と再発防止〕について、(1)〜(3)に答えよ。

(3)本文中のfに入れる適切な字句を15字以内で答えよ。

模範解答

f:モジュールの開発の難易度

解説

解答の論理構成

  1. 【問題文】の指示
    「適切に品質判定ができるよう、fと開発請負会社のスキルレベルを考慮した品質判定基準となるように見直すこと。」
    ここで “f” は、品質判定基準を補正するときに考慮すべきもう一つの観点を問うています。
  2. ヒントとなる前段の記述
    R主任がL社に依頼した追加分析結果の中で、次の報告があります。
    ・「モジュールX1:テスト検度は品質判定基準内であり、欠陥数は品質判定基準を超えているが、開発の難易度を考慮すると品質は良好である。」
    この一文は、難易度を考慮することで“欠陥数が基準超過でも品質良好と判定できる”ことを示しています。
  3. 難易度を明示的に扱う箇所
    【問題文】冒頭の表1は「モジュール別の開発の難易度」を示しており、以降の議論でも基準の補正要素として繰り返し登場します。
  4. 以上より、品質判定基準を見直す際に考慮すべき要素 “f” は「モジュールの開発の難易度」であると導けます。

誤りやすいポイント

  • 表1に「高・中・低」の区分があるため “f” を「難易度」だけで回答すると、設問の趣旨である “何を” 考慮するのかが曖昧になってしまいます。「モジュールの開発の難易度」と具体化する必要があります。
  • fと開発請負会社のスキルレベル” という並列関係から、人に関する指標(経験年数など)を想起してしまいがちですが、前段のL社の分析が難易度に触れている点を見落とすと誤答になりやすいです。
  • 既に「欠陥数」や「テスト密度」は判定基準に含まれているため、これらを再度入れてしまう混同ミスに注意が必要です。

FAQ

Q: 難易度を定量化する方法はありますか?
A: LOC、機能数、複雑度指標(サイクロマティック数など)を基に「高・中・低」とランク付けするのが一般的です。
Q: なぜスキルレベルと難易度を同時に考慮するのですか?
A: 難易度が高いモジュールでもエキスパートチームなら欠陥を低減できますし、逆に難易度が低くても新人主体なら欠陥が増える可能性があります。両者を補正要素とすることで、より公平な品質評価が可能になります。
Q: 品質判定基準を変更するときの留意点は?
A: 過去データとの整合性を確認し、変更理由と影響範囲を文書化してステークホルダに共有することが重要です。

関連キーワード: テスト密度, 欠陥数, 品質判定基準, 難易度, スキルレベル
戦国ITクイズ機能

\ せっかくなら /

応用情報技術者
クイズ形式で学習しませんか?

クイズ画面へ遷移する

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてプライバシーポリシー利用規約特商法表記開発者について