IPA 品質マネジメント — 頻出論点と過去問

頻出論点

1. この分野は何か

設計書やプログラムの欠陥は外見から数えられないため、ソフトウェア開発では工程ごとのレビュー指摘やテスト結果の記録を集め、目標とする品質に届いているかを確かめます。達成すべき水準と測り方をあらかじめ計画に置き、作業の手順が守られているかを確かめる活動と、出来上がった成果物を検査する活動の両面から品質を支えます。検査の数値が基準の範囲に入っていても、レビューやテストのやり方が浅ければ欠陥は残るため、数値の背景にある作業の中身まで点検対象に入ります。

2. 実際の出題のされ方

不具合の記録や原因のデータをどの図表で可視化するかという道具選びが基礎として問われます。ITパスポートでは、件数の多い原因項目を絞り込む図、不具合と原因のつながりを整理する図、2つの量の関係を見る図、単位規模当たりの不具合数を上下の限界線と比べる図の名称を答えさせる問題が出ています。一方、応用情報技術者の午前では、収集したアイデアや意見をまとめる技法の名前や、系統図法の活用例を選ぶ問題のほか、テスト密度と欠陥密度の2軸で分けた領域の状況を判定させる問題が出題されています。

規格が定める品質プロセスの役割や測定指標の選定は、プロジェクトマネージャの午前IIならびにITサービスマネージャの午前IIで中心的に扱われます。このうちプロジェクトマネージャの午前IIでは、機能ごとの規模と基本設計書レビューの指摘件数の表から、組織の標準値と比べて品質上の懸念がある機能を選ぶ計算問題が出題されています。またITサービスマネージャの午前IIでは、国際規格に基づくJIS Q 21500:2018の「品質の計画」について適切な記述を選ぶ問題、PMBOKガイド第6版の品質マネジメントプロセス間で受け渡される文書を選ぶ問題、ソフトウェア品質特性の保守性を定量評価する指標の式を選ぶ問題が出題されています。

信頼性・安全性の検証や統計的な検査・改善の手順については、システムアーキテクトおよびITストラテジストの午前IIで具体的な場面に即して問われます。システムアーキテクトの午前IIでは、バグ管理図の3本の線が変化しなくなった状態から読み取れる状況を選ぶ問題、JIS X 25010:2013の品質副特性の説明から信頼性に分類されるものを選ぶ問題、アシュアランスケースの導入目的を問う問題が見られます。またITストラテジストの午前IIでは、抜取検査で本来合格とすべきロットを不合格と判定してしまうリスクの呼び名、シックスシグマで業務改善を進める5つの段階の順序、ブレーンストーミングの後に原因や意見を整理する図表を選ぶ問題が出題されています。

保守やテスト完了判定の妥当性を確かめる観点からは、システム監査技術者の午前IIで保守作業者から見た利用時の品質に影響する製品品質特性を選ぶ問題が出ています。同区分の午後Iでは、結合テストの完了評価において不良密度やテスト密度の数値目標だけで合格とせず、複雑な機能に対するテスト内容の妥当性や類似不良の調査まで確かめる監査手続が問われます。

午後試験では、応用情報技術者とプロジェクトマネージャの事例問題において、数値目標の設定と現場の検証プロセスを組み合わせる判断が問われます。設計レビューの方式と指摘件数の管理限界線の使い分け、既存システム改修時の回帰テストの範囲設定、顧客体験価値（UX）を設計から総合テストまで段階的に検証する計画、生成AIを組み込むシステムでの学習データの品質確保と効果検証、終結時の直接原因と根本原因の切り分けが題材になっています。

3. 学習のポイント

品質マネジメントの規格（JIS Q 21500:2018およびPMBOKガイド第6版）では、「基準と測り方を決める計画」「決めた手順が守られているかを確かめる実行段階の保証」「できた成果物を測って合否を判定する管理」の3つの向きに活動が分かれます。計画段階で定めた品質尺度は、実行段階のプロセス監査と管理段階の成果物検査の双方に引き渡されて判断の物差しとなります。また、発生した不適合に対してその場のミスを直す直接原因への対処にとどめず、なぜそのミスを防げなかったのかという標準手順や教育の不足（根本原因）まで掘り下げてプロセスへ反映させることで再発を防ぎます。

レビュー指摘件数やテスト項目数・摘出バグ数は、機能の規模が大きいほど増えるため、そのままの件数では機能間の比較ができません。ソースコード行数や設計書ページ数などの単位規模当たりに割り算して密度にそろえ、過去実績に基づく基準範囲や管理図の上方・下方管理限界線と照らし合わせます。

このとき、測定値が基準の下限を下回っていることだけを根拠に「欠陥が少なく高品質である」とは結論づけられません。レビューでモデレータを置いたインスペクションが行われず誤字脱字の指摘にとどまっている場合や、複雑な機能に対して単純なテストケースしか作られていない場合にも、指摘密度や欠陥密度は低く出るためです（誤字脱字のような単純ミスはそもそも少ないほど良いため下方管理限界を設けないこともあります）。テスト密度が基準を満たしていても欠陥密度が極端に低い領域では、テスト観点の妥当性や網羅性を点検し、摘出した不良と似た欠陥が他のモジュールに潜んでいないかまで広げて調べます。

テスト消化件数・累積バグ件数・未解決バグ件数の3本の線を重ねるバグ管理図でも、累積バグの線だけを単独で読むことはできません。テスト消化が順調に進み、摘出されたバグが修正されて未解決バグが減りながら累積バグの増加が落ち着くかを合わせて見ます。3本の線すべてが変化しなくなった場合は、バグが収束したと即断するのではなく、解決困難なバグに直面してテスト消化や修正が止まっていないかを確認する必要があります。

操作性・顧客体験価値（UX）や生成AIの自動採点精度のように、プログラムのバグ件数だけでは測れない品質目標を扱うプロジェクトでは、設計段階のプロトタイプ評価から結合テスト・利用者を交えた総合テストまで複数回に分けて適合性を確かめます。機械学習や生成AIを組み込む場合は、業務知識をもつ担当者が、学習に用いるデータに誤りがないか、偏りや対象領域の不足がないかを初期構築時と運用開始後の双方で点検し、既存機能の改修では回帰テストによって処理結果の正確性と性能の維持を確かめます。

品質改善で用いる図表は、「集めた材料が数値か言語データか」と「重点を絞るか、相関を見るか、意見をまとめるか」で役割が分かれます。数値データを扱う図表では、項目別の件数と累積比率を重ねて対策の優先順位を決める図、2つの量の組を点で表して相関を見る図、単位規模当たりの欠陥数などの値を上下の管理限界線と比べる図を使い分けます。一方、ブレーンストーミングなどで出した多様な意見や課題を内容の近さでグループにまとめて課題を浮かび上がらせる手法と、複雑に絡み合う原因と結果の因果関係を矢印で結んで主要因を探る手法は、整理する対象のまとまり方が異なります。

4. 間違えやすいところ

品質特性の「信頼性」に分類される品質副特性の説明を選ぶ問題（JIS X 25010:2013）では、2つ以上のシステムや構成要素が情報を交換し、交換した情報を使用できる度合いとする誤答肢がありました。複数のシステム間で情報をやり取りして利用できる度合いは、信頼性ではなく互換性の副特性（相互運用性）に当たります。

ソフトウェア品質特性の保守性を評価する指標を選ぶ問題で、移植対象のソースコード行数に対して、書き換えを要するコード行数が占める比率とする誤答肢がありました。プログラムを別の動作環境へ移す際にどれだけ書き換えが必要かという比率は、別の環境への移しやすさを表す移植性の指標に当たります。

抜取検査において、本来は合格とすべきロットを誤って不合格と判定してしまうリスクの名前を選ぶ問題では、消費者危険とする誤答肢がありました。消費者危険は、本来は不合格とすべき不良ロットが検査を通過して受け入れられ、受け取る買い手側が不利益を被る確率のことです。

新QC七つ道具である系統図法の活用例を選ぶ問題では、結果とそれに影響する要因とのつながりを体系的に整理し魚の骨の形にまとめるとする誤答肢がありました。起きた結果（特性）に対して原因（要因）がどう枝分かれして影響しているかを魚の骨の形でたどるのは、原因分析に使う特性要因図の作り方です。