応用情報技術者 2010年 秋期 午後 問10
ソフトウェアパッケージ開発プロジェクトでの品質管理に関する次の記述を読んで、設問1~3に答えよ。
Y社は、企業向けのソフトウェアパッケージを開発し、販売している。Y社では、現在、販売管理パッケージの全面改訂プロジェクト(以下、改訂プロジェクトという)を進めている。現行の販売管理パッケージは、度重なる仕様の追加・変更によってデータベースへのアクセスが複雑になり、レスポンスに悪影響を及ぼす状況が発生している。今回の改訂は、顧客から寄せられた要望への対応と、レスポンスの向上を目標としている。
販売管理パッケージの開発言語はJavaで、データベースには関係データベースを使用している。改訂プロジェクトの体制は図のとおりである。

A~Cチームは、それぞれ異なるサブシステムの開発を担当する。技術支援チームはデータベース設計の検証とプログラムのデータベース処理性能面に関する技術支援を担当する。開発管理チームは品質管理を担当する。
改訂プロジェクトは現在、プログラムの詳細設計工程を完了し、コード作成・単体テスト工程を開始したところである。
〔コード作成における品質管理〕
コード作成は、プログラムのコード作成、チェックリストに基づくコードの自己チェック、ピアコードレビュー、及びコードインスペクションの手順で実施する。
プログラムのコード作成では、詳細設計書に基づいて、Java言語コーディング規約に準拠したコードを作成する。自己チェックでは、コード作成の担当者自身が、チェックリストの項目に沿ってプログラムのコードを確認する。チェックリストは、本人の簡単な確認で是正できるチェック項目を列挙したものである。開発管理チームはチェックリストを提供し、必要に応じて、工程途中でもチェック項目の追加・改定をする。ピアコードレビューでは、チームリーダが進行役となり、チーム内のメンバ同士でプログラムのコードを相互に確認する。コードインスペクションでは、技術支援チームが①特定の視点に絞ってプログラムのコードを検査する。
ピアコードレビューとコードインスペクションの品質基準は、次のとおりである。
(1) ピアコードレビュー
・作成されたプログラムのコードすべてをピアコードレビューの対象とする。
・レビューを実施した結果の指摘数と、レビュー対象コードの行数からプログラム単位の指摘密度を算出する。
・指摘密度は、過去の類似プロジェクトにおける指摘密度の平均値である10件/千行に対し、+50%以下を適正範囲の目安とする。
・指摘密度が適正範囲の上限を上回ったプログラムについては、品質管理上の対策として、指摘への対処完了後、再度ピアコードレビューを実施する。
(2) 技術支援チームによるコードインスペクション
・データベース処理を含むコードをすべてコードインスペクションの対象とする。
・コードインスペクションによる指摘数は、指摘密度による管理対象としない。
〔単体テストにおける品質管理〕
単体テストは、プログラム単位に、コード作成担当者以外のメンバが、単体テストケースに基づいて実施する。単体テストケースは、単体テストを実施するメンバが、詳細設計書の要求事項を網羅するように作成する。単体テストで発見した不良については、一覧形式の管理表に記録し、プログラム単位の不良密度を算出する。
単体テストの品質基準は、次のとおりである。
・不良密度は、過去の類似プロジェクトの平均値を参考に設定した標準値である10件/千行に対し、±50%を適正範囲の目安とする。
・不良密度が適正範囲の上限を上回った、又は下限を下回ったプログラムについては、開発管理チームが問題点の有無を確認し、必要な場合には、品質管理上の対策を指示する。
・単体テストケースの妥当性を確認する一つの目安であるケース密度を算出するために、プログラムごとの単体テストケース数も測定する。過去の類似プロジェクトのケース密度の平均値を参考に、標準値を100ケース/千行に設定するが、適正範囲の設定は特に行わないものとする。
〔初期点検〕
コード作成・単体テスト工程全体の約2割まで進んだ時点で、開発管理チームは、工程の初期段階の問題から品質管理面の改善策を導き出す目的で初期点検を開始した。
初期点検では、チーム単位に、ピアコードレビューと単体テストを現時点までに終えているプログラムに対し、評価を実施することにした。開発管理チームは、最初にAチームのピアコードレビューの状況を表1にまとめた。

A~Cの各チームとも、チェックリストに記載されている項目の確認は適切に実施されていた。しかし、ピアコードレビューでは、Java言語コーディング規約に規定されたコメントが、プログラムのコードに記載されていないという指摘が多かった。開発管理チームは、本人の簡単な確認で解消させるような②改善策を講じることにした。
開発管理チームは続けて、Aチームの単体テストの状況を表2にまとめた。品質管理上の対策として、プログラム1については、ピアコードレビューを再度実施してaを確認し、プログラム3については、bを確認するようAチームに指示した。

設問1:
本文中の下線①について、技術支援チームの役割上、コードインスペクションに最も重要となる視点を解答群の中から選び、記号で答えよ。
解答群
ア:Java言語コーディング規約に準拠しているか
イ:SQL文の記述に処理性能面の問題がないか
ウ:コメントの記述に過不足がないか
エ:メッセージの文言は状況を適切に表現しているか
模範解答
イ
解説
解答の論理構成
-
技術支援チームの職責を把握
【問題文】には
「技術支援チームはデータベース設計の検証とプログラムのデータベース処理性能面に関する技術支援を担当する。」
と明示されています。職務が “データベース” と “処理性能” に特化している点がポイントです。 -
コードインスペクションの目的を確認
同じく【問題文】で
「コードインスペクションでは、技術支援チームが①特定の視点に絞ってプログラムのコードを検査する。」
と示されています。特定の視点とは、前段で示された技術支援チームの専門領域と一致する必要があります。 -
選択肢との対応付け
解答群を照合すると、データベース処理性能に直接対応するのは
「イ:SQL文の記述に処理性能面の問題がないか」
です。その他の選択肢- 「ア」「ウ」は Java コーディング規約やコメントの過不足 → 開発チーム側・チェックリストで対応済み
- 「エ」はメッセージ内容 → ユーザビリティ寄り
であり、技術支援チームの本来業務とはズレます。
-
結論
したがって、技術支援チームがコードインスペクションで最も重要視すべきなのは
「イ:SQL文の記述に処理性能面の問題がないか」 となります。
誤りやすいポイント
- 「技術支援チーム=技術全般のプロ」と思い込み、コーディング規約チェック(選択肢ア)を選ぶ。問題文は“データベース処理性能面”に限定している点を見落としがちです。
- “コメント不足が多数指摘された”という直前の記述に引きずられ、選択肢ウを選んでしまう。コメント問題はピアコードレビューで解消するため、インスペクションの主眼ではありません。
- “メッセージ文言”はユーザからの見た目品質ですが、今回の品質管理スコープ(詳細設計~単体テスト)とは直接関係しません。
FAQ
Q: コードインスペクションとピアコードレビューの違いは何ですか?
A: ピアコードレビューはチーム内でコード全般を相互確認し、指摘密度で品質を管理します。一方、コードインスペクションは専門チーム(ここでは技術支援チーム)が“特定の視点”に絞って深掘りする点が異なります。
A: ピアコードレビューはチーム内でコード全般を相互確認し、指摘密度で品質を管理します。一方、コードインスペクションは専門チーム(ここでは技術支援チーム)が“特定の視点”に絞って深掘りする点が異なります。
Q: SQL の性能問題はなぜ早期に発見すべきなのですか?
A: 後工程でデータアクセス不具合や低速レスポンスが発覚すると、テーブル設計・インデックス設計の見直しが必要になり、工数・リスクが急増するためです。
A: 後工程でデータアクセス不具合や低速レスポンスが発覚すると、テーブル設計・インデックス設計の見直しが必要になり、工数・リスクが急増するためです。
Q: コーディング規約違反はインスペクション対象外なのですか?
A: 完全に対象外ではありませんが、本問の文脈ではチェックリストとピアレビューで対処し、インスペクションはデータベース性能に集中する運用ルールになっています。
A: 完全に対象外ではありませんが、本問の文脈ではチェックリストとピアレビューで対処し、インスペクションはデータベース性能に集中する運用ルールになっています。
関連キーワード: SQL最適化、指摘密度、コードレビュー、単体テスト、品質基準
設問2:初期点検におけるピアコードレビューの状況について、(1)、(2)に答えよ。
(1)表1に示したプログラム1〜4のうち、品質管理上の対策が必要なプログラム名を一つ挙げよ。また、品質基準に従って実施すべき対策の内容を35字以内で述べよ。
模範解答
プログラム名:プログラム4
実施すべき対策:指摘への対処完了後、再度ピアコードレビューを実施する。
解説
解答の論理構成
-
品質基準を確認
・【問題文】に「指摘密度は、過去の類似プロジェクトにおける指摘密度の平均値である10件/千行に対し、+50%以下を適正範囲の目安とする。」
・さらに「指摘密度が適正範囲の上限を上回ったプログラムについては、品質管理上の対策として、指摘への対処完了後、再度ピアコードレビューを実施する。」とある。
⇒ 上限は 件/千行。 -
表1から指摘密度を算出
-
適正範囲との比較
・「15件/千行」を超えているのは「プログラム4」のみ。
・従って品質管理上の対策が必要なプログラムは「プログラム4」。 -
実施すべき対策
・基準文に沿って「指摘への対処完了後、再度ピアコードレビューを実施する。」が該当。
以上より、模範解答どおり
プログラム名:プログラム4
実施すべき対策:指摘への対処完了後、再度ピアコードレビューを実施する。
プログラム名:プログラム4
実施すべき対策:指摘への対処完了後、再度ピアコードレビューを実施する。
誤りやすいポイント
- 指摘密度を「指摘数」で判断してしまい、行数で割る計算を忘れる。
- 上限「+50%」を「±50%」と混同し、下限も同時に確認しようとして迷う。
- 再レビューの条件を「再度ピアコードレビュー」ではなく「コードインスペクション」と取り違える。
- 小数点の計算を誤り「プログラム1」が基準外と勘違いする。
FAQ
Q: 指摘密度が基準内でも指摘数が多い場合は対策不要ですか?
A: はい。【問題文】が管理指標としているのはあくまで「指摘密度」であり、総指摘数のみでの対策指示はありません。
A: はい。【問題文】が管理指標としているのはあくまで「指摘密度」であり、総指摘数のみでの対策指示はありません。
Q: 下限値は設定されていますか?
A: ピアコードレビューについては下限の記載がなく、対策条件は「上限を上回った場合」のみです。
A: ピアコードレビューについては下限の記載がなく、対策条件は「上限を上回った場合」のみです。
Q: コードインスペクションでも再レビューは必要ですか?
A: コードインスペクションは「指摘密度による管理対象としない」と明記されているため、再レビュー条件は設けられていません。
A: コードインスペクションは「指摘密度による管理対象としない」と明記されているため、再レビュー条件は設けられていません。
関連キーワード: 指摘密度、ピアコードレビュー、品質基準、コードレビュー、再レビュー
設問2:初期点検におけるピアコードレビューの状況について、(1)、(2)に答えよ。
(2)本文中の下線②の改善策について、本文中のコード作成の手順に含まれる活動にかかわる対策として適切と考えられる手段を40字以内で述べよ。
模範解答
対策:チェックリストにコメントの記載漏れがないかのチェック項目を追加する。
解説
解答の論理構成
-
問題点の把握
【問題文】には
「ピアコードレビューでは、Java言語コーディング規約に規定されたコメントが、プログラムのコードに記載されていないという指摘が多かった。」
と記載されています。コメント漏れという“形式的かつ自己解決可能”な欠陥が多数発生していることが分かります。 -
改善策の条件
同じく【問題文】で
「本人の簡単な確認で解消させるような②改善策を講じることにした。」
と述べられており、手間を掛けずに“作成者自身が即時是正できる”方策が求められています。 -
手順との適合確認
コード作成の手順説明では
「自己チェックでは、コード作成の担当者自身が、チェックリストの項目に沿ってプログラムのコードを確認する。」
「チェックリストは、本人の簡単な確認で是正できるチェック項目を列挙したものである。」
と定義されています。
したがって、チェックリストへ項目を追加すれば“自己チェックの段階”でコメント漏れを防止できます。 -
解答
以上から、②改善策として
「チェックリストにコメントの記載漏れがないかのチェック項目を追加する。」
が妥当であると導かれます。
誤りやすいポイント
- ピアコードレビュー自体を強化する案を挙げてしまい、自己チェックとの区別を忘れる。
- 「技術支援チームが特定の視点に絞って…」という記述に引きずられ、インスペクション側での対応を答えてしまう。
- チェックリストの定義を読み落とし、別途ツール導入や教育実施など“簡単でない”施策を提案してしまう。
FAQ
Q: コメント漏れは品質に直接影響しないのでは?
A: 可読性・保守性が下がり、後工程での不良混入リスクが高まります。小さなコストで是正できるので早期に対処すべきです。
A: 可読性・保守性が下がり、後工程での不良混入リスクが高まります。小さなコストで是正できるので早期に対処すべきです。
Q: チェック項目追加だけで再発防止になるのか?
A: 自己チェック→ピアレビュー→インスペクションと多段で確認するため、先頭の自己チェックが強化されれば後段の指摘は自然に減少します。
A: 自己チェック→ピアレビュー→インスペクションと多段で確認するため、先頭の自己チェックが強化されれば後段の指摘は自然に減少します。
Q: コーディング規約自体を変更する必要は?
A: 規約に違反しているのではなく“遵守忘れ”が問題なので、規約変更は不要です。遵守の確実化が目的です。
A: 規約に違反しているのではなく“遵守忘れ”が問題なので、規約変更は不要です。遵守の確実化が目的です。
関連キーワード: コードレビュー、コーディング規約、チェックリスト、品質管理、自己チェック
設問3:初期点検における単体テストの状況について、(1)〜(3)に答えよ。
(1)本文中のaに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:共通化がされていない冗長なコードがないか
イ:コードが読みやすいよう字下げが適切にされているか
ウ:コードは詳細設計書の内容を正確に反映しているか
エ:テストデータの項目に不正な値がないか
模範解答
a:ウ
解説
解答の論理構成
-
再レビューの対象
- 本文には「指摘密度が適正範囲の上限を上回ったプログラムについては、品質管理上の対策として、指摘への対処完了後、再度ピアコードレビューを実施する。」とあります。
表2より「プログラム1」の不良密度は「18.0」で、基準「10件/千行」に対して「+50%」の上限「15.0」を超過しています。したがってプログラム1が再レビュー対象になります。
- 本文には「指摘密度が適正範囲の上限を上回ったプログラムについては、品質管理上の対策として、指摘への対処完了後、再度ピアコードレビューを実施する。」とあります。
-
再レビューで確認すべき観点
- 不良密度の超過は機能的な誤りが多いことを示唆します。機能的誤りの主因は、コードが設計を正しく実装していない点にあるのが一般的です。
- 本文のコード作成手順では「詳細設計書に基づいて、Java言語コーディング規約に準拠したコードを作成する。」と明記されています。従って、再レビューで最優先に確認すべきは「コードが詳細設計書を正確に反映しているか」です。
-
解答群の照合
- ア:冗長コードの有無 → 性能や保守性の観点であり今回の超過理由と直結しません。
- イ:字下げの適切さ → コーディングスタイルであり機能的不具合には直接結び付きません。
- ウ:コードは詳細設計書の内容を正確に反映しているか → 機能的不具合と直結。
- エ:テストデータの不正値有無 → 単体テスト側の観点であり、ピアコードレビューの再実施目的とは異なります。
したがって a に入るのは「ウ:コードは詳細設計書の内容を正確に反映しているか」です。
誤りやすいポイント
- スタイル指摘との混同
ピアレビューで「コメントが記載されていない」というスタイル系の指摘が多発していたため、同じくスタイル改善(字下げやコメント追加)を再レビュー目的と誤解しやすいです。 - 単体テスト結果の読み違え
単体テストで高い不良密度が出た原因を“テストケースの質”と短絡的に判断しがちですが、まず設計‐実装の整合性を疑うのが定石です。 - コードレビューとテスト工程の目的混同
コードレビューは「実装が設計どおりか」を、テストは「実装が仕様どおりか」を主に確認します。この区別を意識しないと観点を取り違えます。
FAQ
Q: 再レビューで確認する観点は複数あってはいけないのですか?
A: 本文では再レビューの目的を品質管理上の対策として最も効果的な一点に絞る趣旨です。不良密度超過の主因を潰すことが優先されます。
A: 本文では再レビューの目的を品質管理上の対策として最も効果的な一点に絞る趣旨です。不良密度超過の主因を潰すことが優先されます。
Q: 単体テストで発見できるのに、なぜコードレビューで再確認するのですか?
A: テストだけでは後工程手戻りが発生します。コードレビュー段階で設計‐実装不整合を是正すれば、後続のテスト・結合工程の手戻りを大幅に削減できます。
A: テストだけでは後工程手戻りが発生します。コードレビュー段階で設計‐実装不整合を是正すれば、後続のテスト・結合工程の手戻りを大幅に削減できます。
Q: コメント不足の指摘は無視してよいのでしょうか?
A: 無視するわけではありません。本文には「本人の簡単な確認で解消させるような②改善策を講じる」とあるため、コメント不足は個別に自己チェックで対処し、再レビューの主目的からは外します。
A: 無視するわけではありません。本文には「本人の簡単な確認で解消させるような②改善策を講じる」とあるため、コメント不足は個別に自己チェックで対処し、再レビューの主目的からは外します。
関連キーワード: コードレビュー、不良密度、詳細設計、ピアレビュー、品質管理
設問3:初期点検における単体テストの状況について、(1)〜(3)に答えよ。
(2)表2中のc、dに入れる適切な字句を本文中から選んで答えよ。
模範解答
c:不良密度
d:下限を下回った
解説
解答の論理構成
- 【問題文】には単体テストの品質基準として
「不良密度は、過去の類似プロジェクトの平均値を参考に設定した標準値である10件/千行に対し、±50%を適正範囲の目安とする。」
「不良密度が適正範囲の上限を上回った、又は下限を下回ったプログラムについては、開発管理チームが問題点の有無を確認し…」
と明記されています。 - したがって適正範囲は
10件/千行 × 0.5 = 5件/千行 (下限)
10件/千行 × 1.5 = 15件/千行 (上限)
になります。 - 表2を見ると、プログラム3の「不良密度」は「2.0」。これは下限 5件/千行 を下回っています。
- 表2の評価欄には「cが適正範囲のd。」とあり、該当する指標は上記で判定したもの、つまり「不良密度」。下回った事実を示す語は「下限を下回った」です。
- よって
c:不良密度
d:下限を下回った
誤りやすいポイント
- ケース密度と混同する
「ケース密度」には適正範囲が設定されておらず、判定基準がないため評価対象になりません。 - 「上限を上回った」と早合点する
数字を見ずに条件文だけで判断すると逆の結論を出しやすいので、必ず計算して確認しましょう。 - 千行あたりの計算忘れ
件数そのものではなく「件/千行」で比較する点を見落としがちです。
FAQ
Q: なぜ不良密度が低すぎても問題視されるのですか?
A: テストが十分に実施されていない、あるいはテストケースが不十分で不良を検出できていない可能性があるためです。
A: テストが十分に実施されていない、あるいはテストケースが不十分で不良を検出できていない可能性があるためです。
Q: ケース密度が基準を外れていても対策は取らないのですか?
A: 【問題文】に「適正範囲の設定は特に行わない」とあるため、数値のみ測定して参考値とします。
A: 【問題文】に「適正範囲の設定は特に行わない」とあるため、数値のみ測定して参考値とします。
Q: ±50%の計算は暗記すべきですか?
A: 暗記よりも「標準値 × (1 ± 割合)」の式を即座に適用できるよう演習で慣れることが大切です。
A: 暗記よりも「標準値 × (1 ± 割合)」の式を即座に適用できるよう演習で慣れることが大切です。
関連キーワード: 不良密度、ケース密度、コードレビュー、品質基準
設問3:初期点検における単体テストの状況について、(1)〜(3)に答えよ。
(3)本文中のbに入れる適切な字句を35字以内で述べよ。
模範解答
b:単体テストケースが詳細設計書の要求事項を網羅しているか
解説
解答の論理構成
-
単体テストの目的
【問題文】では
「単体テストケースは、単体テストを実施するメンバが、詳細設計書の要求事項を網羅するように作成する。」
とあり、まず“要求事項を網羅しているか”がテストケース妥当性の判断軸であると示されています。 -
品質基準と評価の判定方法
単体テストでは
「不良密度は、…標準値である10件/千行に対し、±**50%**を適正範囲の目安とする。」
と定められています。適正範囲は 5件/千行〜15件/千行 に相当します。 -
プログラム3の状況
表2より、プログラム3は
「不良密度 2.0」
であり、適正範囲の下限 5件/千行 を下回っています。 -
下限割れ時に確認すべき内容
品質基準には
「不良密度が適正範囲の上限を上回った、又は下限を下回ったプログラムについては、開発管理チームが問題点の有無を確認し、必要な場合には、品質管理上の対策を指示する。」
とあります。下限割れは“バグが少な過ぎる”状態であり、テストが甘い可能性があるため、まずテストケースの網羅性を疑うのが一般的です。 -
導くべき確認事項
網羅性を確かめる具体的観点は先述のとおり「詳細設計書の要求事項を網羅しているか」であり、これがbに入る文言となります。
以上より、bには
「単体テストケースが詳細設計書の要求事項を網羅しているか」
が入るのが妥当です。
「単体テストケースが詳細設計書の要求事項を網羅しているか」
が入るのが妥当です。
誤りやすいポイント
- 不良密度が低い=優秀と早合点してしまい、テストケース不足のリスクを見逃す。
- 件/千行の範囲計算を誤り、下限割れを認識できない。
- 「ケース密度100ケース/千行」をそのまま下限基準と思い込み、網羅性確認の必要性を見落とす。
- “詳細設計書”ではなく“基本設計書”や“要件定義書”と混同して記述してしまう。
FAQ
Q: 不良密度が低いのに問題視されるのはなぜですか?
A: 不良が少ないのではなく“検出できていない”可能性があるためです。テストケースが不足すると欠陥が表面化せず、後工程で重大欠陥が残るリスクがあります。
A: 不良が少ないのではなく“検出できていない”可能性があるためです。テストケースが不足すると欠陥が表面化せず、後工程で重大欠陥が残るリスクがあります。
Q: ケース密度100ケース/千行を下回っても自動で再テストとなりますか?
A: ケース密度には適正範囲を設定していません。あくまで「妥当性を確認する目安」であり、下回った場合はテストケース内容をレビューし、必要に応じて追加する運用です。
A: ケース密度には適正範囲を設定していません。あくまで「妥当性を確認する目安」であり、下回った場合はテストケース内容をレビューし、必要に応じて追加する運用です。
Q: 下限割れ対策としてコードレビューを再実施してはいけませんか?
A: もちろんコードにも課題が潜む可能性はありますが、本問の文脈では“テスト不足”が最も疑わしいため、まずテストケース網羅性を確認する指示が優先されます。
A: もちろんコードにも課題が潜む可能性はありますが、本問の文脈では“テスト不足”が最も疑わしいため、まずテストケース網羅性を確認する指示が優先されます。
関連キーワード: 不良密度、ケース密度、コードレビュー、テストケース設計、網羅性


