【PMBOK対応】PM試験の知識体系まとめ（#5 品質編）

2021年7月20日 14:10

概要

#3の「スケジュール（Delivery）」、#4の「コスト（Cost）」と、QCDの観点を学んできて、最後に残った１つが「品質（Quality）」である。
「安かろう悪かろう」が通用する業界もあるが、IT業界における品質低下は、予測していない障害を発生させ、事業・サービス・プロジェクトに大きな影響を与える。
「明日リリースだけど、品質は大丈夫だよね？」と聞かれた時に、自信を持って回答できるよう学んで欲しい。

#5.1 品質マネジメントの計画

品質マネジメントの計画プロセスでは、「#5.2 品質のマネジメント」「#5.3 品質のコントロール」プロセスのマネジメント方法や進め方を確定し、プロジェクトマネジメント計画書の補助計画書を作成する。
具体的な内容としては、まず顧客が要求する品質を把握する。
それを調整する共に品質尺度を明確にし、品質尺度を達成するためのレビュー計画やテスト計画を立案する。

■#5.1.1　ISO/IEC9126（JIS X 0129-1：2003）
「#5.1品質マネジメント計画」のインプットに、「④組織体の環境要因」がある。
環境要因には、適用分野に特有の規則・ガイドライン等があり、ISO/IEC9126（JIS X 0129-1：2003）はその代表例である。
JIS X 0129-1には6つの特性と、それに対する副特性が定められているため、紹介する。
これを参考にして、品質の要求・標準・実現方法を決めることも可能。

■#5.1.2 品質コスト
品質コストとは、成果物の生成から廃棄までにかかるコストの総額である。
「欠陥」に対応するコストであり、以下２つに分類される。
※「欠陥」とは誤り全般のことであり、考慮漏れ・不具合・バグ・障害・エラー等をまとめた言葉である。

・#5.1.2.1 適合コスト
欠陥を回避するためのコスト、つまり事前の予防や評価に使うコストである。
具体的には、仕様レビュー・ソースコードレビュー等である。

・#5.1.2.2 不適合コスト
見つけた欠陥を修正するコスト。
具体的には、仕様考慮漏れの発見時・テストでのバグ発見時・リリース後の障害発生時等である。

・#5.1.2.2 コスト効果は「適合コスト」＞「不適合コスト」
全体の品質コストを抑えるためには、一般的に「適合コスト」側にコストを掛けた方が良い。
体の健康で例えると、「毎年健康診断を受けている人は、病気が悪化する前に対策を取れる」というイメージである。

■#5.1.3 品質マネジメント計画書
品質マネジメント計画書とは、品質方針の実施方法を記述した計画書である。
プロジェクトへの品質要求を達成するため、PM・メンバーがどにように実施するか、品質尺度を含め記載される。

■#5.1.4 品質尺度
簡単に説明すると、「プロジェクトの品質をどう測定するか具体的に記したもの」である。
実例として、
・実施するレビューの項目数
・レビュー項目密度（実施するレビュー項目数÷プログラムステップ数）
・コメントの行数
・実施テスト項目数
等がある。
「品質管理指標」とほぼ同じ意味であり、「#5.2.5 レビューおよびテストの計画、実行、監視・コントロール」で詳細を説明する。

#5.2 品質のマネジメント

別名「品質保証」とも呼ばれる。
品質マネジメントの計画を実施するプロセス。
「5.3 品質のコントロール」で得た結果を。ステークホルダに対し「品質報告書」という形で報告する。
マネジメント→コントロールという一方通行ではなく、適宜反復・並行して実施される。

#5.3 品質のコントロール

ここでは、顧客の要求する品質と実績報告とを「検査」という形で比較し、差異を把握する。
差異の結果を検証・記録し、「#5.2 品質のマネジメント」に引き渡す。

#5.4 レビュー・テスト技法

#5.1～#5.3のプロセスにおいて利用されるレビュー・テスト技法をまとめて紹介する。

■#5.4.1 QC7つ道具
QC7つ道具は主に、製造業での利用を前提に開発されてきた。
しかし、ソフトウェア開発での品質管理にも有効であるため、覚えておいて欲しい。

・#5.4.1.1 ①チェックシート
予めチェック項目を用意しておく。
そして、テストの際はそれにチェックを入れる形で品質の状況を確認する。
これにより、確認漏れが発生しなくなる。
間違っても、画像の「悪いチェックシート」のような項目にしないように。

・#5.4.1.2 ②ヒストグラム
縦軸に件数、横軸に管理項目（範囲）をとった統計グラフの一種。
データのばらつきを視覚的に認識するために使用する。
一般的には中央地の件数が一番多く、両端になるほど少なくなる。
具体的な利用例としては、
・縦軸：受注件数
・横軸：受注単価
等である。
・平均値：管理項目全体の合計を、件数で割った値
・中央値：山の横幅の、ちょうど中間の値。「メジアン」とも呼ばれる。
・最頻値：件数が一番大きい時の値。「モード」とも呼ばれる。

・#5.4.1.3 ③パレート図
件数の大きい順に縦棒を並べたグラフ。
補足として累積構成比を折れ線で表す。
パレート図を用いた分析に「パレート分析（ABC分析）」がある。
この分析は、「上位80％の問題は、20％の原因により発生する」という経験則「80対20の法則（パレートの法則）」を用い、主要な原因を特定する際に利用する。

・#5.4.1.4 ④特性要因図
結果とその要因の関係を、視覚的にわかりやすくした図であり、形が魚の骨に似ているため、「フィッシュボーン」とも呼ばれる。
横に伸びる太い骨に結果を記載し、小骨に原因を記載する。

・#5.4.1.5 ⑤層別（グラフ）
層（別名：セグメント）ごとにデータを集計し、特徴・傾向を把握するための手法。
手法自体の名称であり、表現は円グラフでも積み上げ棒グラフでも良い。

・#5.4.1.6 ⑥散布図
２つの軸を基に多数のデータを点で示した図。
点の集まり具合によって、相関関係を知ることができる。
- 左下から右上に集まる場合（サンプルイメージを添付）
　→「相関関係」にある（正の相関）
- 左上から右下に集まる場合
　→「逆相関関係」にある（負の相関）
- バラバラの場合
　→相関なし

・#5.4.1.7 ⑦管理図
品質のばらつきを分析・管理するためのグラフ。
中心線（CL：Center Line）・管理上限線（UCL：Upper Control line）・管理下限線（LCL：Lower Control Line）で構成されており、グラフの点の並びによって、異常原因が発生していないかを分析する。
代表的なものに「X-R管理図」があり、「7の法則」という法則が使われる。
具体的な使い方として、7回連続で中心線を上回ったか、あるいは下回った場合は異常が発生しているという考え方である。
連続で7回発生する確率は50％の7乗（つまり1%以下）となり、偶然である可能性が極めて小さくなるから、というのが7回の根拠である。

■#5.4.2 レビュー
レビューは、成果物の品質を検査する手法である。
一般的には、成果物が作成されたタイミングで行われ、後続フェーズに欠陥を残さないという意図で実施される。
レビュー方法は数種類があり、具体的な手順と特徴を紹介する。

・#5.4.2.1 ウォークスルー
特徴は以下の通りである。
- 開発者が自主的に開催する
- レビュー内容はパターン化されている
- 欠陥を見つけることだけに注力する（欠陥の修正方法は議論しない）
- ウォークスルー結果と人事評価を結び付けないよう、上司や管理者は原則参加しない
- レビュー用に資料を個別に作成するのではなく、成果物自体をレビューする
- 成果物は事前に共有し、レビュー者の確認期間を設ける
- 集中力低下を防ぐため、時間がかかっている場合は翌日に持ち越す
- 欠陥修正の責任者は、開発者本人である
- 欠陥が後日発見された場合の責任は、レビュー参加者全員とする

・#5.4.2.2 インスペクション
特徴は以下の通りである。
ウォークスルーの欠点である、開発者が開催を怠ってしまうことを防ぐ意図がある。
- モデレータの選出
モデレータは、レビュー実行の責任者であり、開催の主導、司会進行などを行う。
ウォークスルー同様、レビュー参加者に対する人事評価を行えない人員が望ましい。

- 欠陥の修正状況把握と催促
ウォークスルーの欠点である、開発者が修正を怠ってしまうことを防ぐ意図がある。
モデレータが欠陥の修正状況把握を行い、開発者に修正を催促する。

- レビュー結果の収集と分析、フィードバック
モデレータは、レビュー結果（成果物・作成者・レビュー時間・欠陥摘出数・出席者等）を収集する。
これを基に、欠陥発生箇所の傾向や、有効なレビュー観点などを分析し、関係者にフィードバックする。
これにより、レビュー精度向上が期待できる。

・#5.4.2.3 ラウンドロビン
ラウンドロビンという言葉は、「持ち回り」「順繰り」「総当り」の意味で使われ、「DNSラウンドロビン」等の用語でも使われる。
レビューでもラウンドロビンの手法が用いられることが多い。
具体的には、
- 主催者を持ち回りにし、参加意欲を高める
- 発言を順繰りにさせ、参加意欲を高めると共に、些細な懸念も拾える状況を作る
というメリットがある。

■#5.4.3 テストフェーズ
情報システム開発におけるテストは、フェーズごとに複数回実施される。
一例として「V字モデル」がある。
要件定義・コーディング等のフェーズごと、対応するテストフェーズが設けられている。

・#5.4.3.1 単体テスト
モジュール単位で実施されるテストである。
一般的にブラックボックステスト・ホワイトボックステストが併用され、
モジュール単体で動作しない場合、ドライバやスタブを用意し、テストする。
※詳細は後述

・#5.4.3.2 結合テスト
複数モジュールを結合した状態で行われるテスト。
主にブラックボックステストが実施される。
単体テスト同様、モジュール不足で動作しない場合は、ドライバやスタブを用意する。
- ドライバ
テスト実施のために用意されたモジュール。
テスト対象モジュールの上位プログラムのことを指す。
- スタブ
テスト実施のために用意されたモジュール。
テスト対象モジュールの下位プログラムのことを指す。
- トップダウンテスト
上位モジュールから下位モジュールに向かって結合していくテスト。
スタブの用意が必要。
- ボトムアップテスト
下位モジュールから上位モジュールに向かって結合していくテスト。
ドライバの用意が必要。
- サンドイッチテスト
トップダウンテストとボトムアップテストを同時並行して進めるテスト
- ビッグバンテスト
単体テスト実施後、一度に全モジュールを結合して行うテスト。
- 一斉テスト
単体テストを省略して、一度に全モジュールを結合して行うテスト。

・#5.4.3.3 システム(総合)テスト
システム開発者が行う、システム全体で行われるテスト。
運用手順に従い、最初から最後まで一通りをテストする。
開発者観点で行われるため、
・連携システムの動作確認
・障害発生時の例外処理
・性能試験
等も行われる。
一般的にはブラックボックステストにて実施される。

・#5.4.3.4 受け入れ(運用)テスト
運用担当者が行う、システム全体で行われるテスト。
運用者観点で行われるため、
・バックアップの所要時間
・イレギュラー期間（例：休日等）の稼働
・障害発生時の対応方法
等を確認し、課題を洗い出す。

■#5.4.4 テスト技法
テストフェーズで行われるテスト技法を紹介する。

・#5.4.4.1 ホワイトボックステスト
プログラムのソースコードを把握した上でテストケースを作成し、テストする技法。
以下5種類の技法がある。
補足の図は、特によく見て欲しい。
違いを明確に示すため、非常に工夫した力作である。

- 命令網羅
すべての命令を少なくとも1回は実行する。

- 判定条件網羅（分岐網羅）
「判定条件（分岐）」の真と偽を少なくとも1回は実行する。

- 条件網羅
「判定条件（分岐）」ではなく、「条件」の真偽を少なくとも1回は実行する。

- 判定条件/条件網羅
「判定条件（分岐）」の真と偽を少なくとも1回実行する。
それに加えて、「条件」の真偽を少なくとも1回実行する。

- 複数条件網羅
考えられるすべての条件パターンを実行する。

・#5.4.4.2 ブラックボックステスト
プログラムのソースコードを把握せず、仕様書に基づいてテストケースを作成し、テストする技法。

- 同値分割
テストデータを「同値クラス」と呼ぶ集合に分類し、その中から１つずつデータを選定してテストする手法。
「有効同値クラス」・・判定条件に当てはまるデータの集合
「無効同値クラス」・・判定条件に当てはまらないデータの集合
以下図の場合、テストデータは「-1」「3」「7」の３つで良い。

- 限界値分析
同値分割の発展型と考えても良い。
有効・無効同値クラスの境界（限界）になる値をテストデータに用いる手法である。
以下図の場合、テストデータは「1」「2」「5」「6」の4つが必要である。

- 原因結果グラフ
条件が複合的に設定されている場合に利用する表現方法。
一般的にはフローチャートが用いられるため、ここでは凡例のみ紹介する。

・#5.4.4.3 レグレッションテスト
「退行テスト」「回帰テスト」「リグレッションテスト」とも呼ぶ。
仕様変更に伴う開発時、変更対象の機能以外にも変更（影響）が発生していないかを確認するテスト。

■#5.4.5 レビュー(テスト)の計画、実行、監視、コントロール
レビュー・テストは、実施タイミングは別だが、目的や手法は共通点が多い。
よって、まとめて説明する。

・#5.4.5.1 レビュー(テスト)の計画
- 品質管理指標
冒頭「#5.1 品質マネジメントの計画」で説明した、品質尺度とほぼ同じ意味である。
代表的な指標を紹介する。

この指標を基に、基準値・許容範囲を以下のように設定する。
この設定は、「#5.4.5.3 レビュー(テスト)の監視・コントロール」で使用される。

- スケジュール等を含むレビュー(テスト)計画の立案レビュー(テスト)計画は、品質マネジメント計画の一部として行われ、計画書が作成される。
計画書に含まれる内容は、レビュー(テスト)フェーズごとに以下のようなものがある。
・実施期間
・実施者
・項目とその数
・テストデータ（準備方法・件数・正しい処理結果・異常データ）
・レビュー(テスト)の摘出欠陥予定数
・採用するレビュー(テスト)技法
・プログラムステップ数

・#5.4.5.2 レビュー(テスト)の実行
品質実績データの記録を行う。
具体的な記録としてレビューであれば、
レビュー対象成果物に対する「名称」「レビュー項目・数」「実施日」「出席者」「実施時間」「摘出欠陥数」など、
テストであれば、
「対象の機能・プログラム」「テスト対象プログラムの行数」「実施者」「テスト項目・数」「テストデータ」「摘出欠陥数」などである。

欠陥を摘出した場合、欠陥1件に対し1枚の欠陥記録表を作成する。
内容には、「日付」「起票者氏名」「ドキュメント(プログラム)名」「欠陥のタイトル」「発生状況」「原因」「原因分析者氏名」「解決策」「是正措置日」「是正措置対応者氏名」などを含める。

・#5.4.5.3 レビュー(テスト)の監視・コントロール
- 差異分析と品質評価
品質マネジメント計画書に記載された評価実施日に、品質状況を把握・評価する。
タイミングとして、例えば「要件定義終了」「設計終了」「テスト終了」の5営業日前、等である。

具体的な実施内容に、差異分析がある。
「#5.4.5.1 レビュー(テスト)の計画」で設定した品質指標・基準・許容範囲をベースに以下のような表を作成し、許容範囲外の場合は是正措置を実施する。

- レビュー(テスト)工程品質管理図
工程品質管理図は、ソフトウェア開発における品質評価のために作成される。
管理図に記述される曲線は以下3つである。

「信頼性成長曲線」
　横軸：レビュー(テスト)期間
　縦軸：累積摘出欠陥数
　一般的には、ゆるいS字カーブを描く。もし、期間終了に近づいても摘出欠陥数が逓減(ていげん)しない場合、期間を延長する等の是正措置を取る必要がある。

「レビュー(テスト)消化曲線」
　横軸：レビュー(テスト)期間
　縦軸：未消化のレビュー(テスト)項目数
　
「未解決欠陥数」※必要に応じて
　　横軸：レビュー(テスト)期間
　　縦軸：解消方法が原因不明の、摘出欠陥数