プロジェクトの計画

品質マネジメント計画 – 成果物の品質を作りこむための基準設定と対策

概要

品質マネジメント計画書とは、プロジェクトの品質管理に関するアプローチや手順を定義した文書です。
品質計画の主な目的は、プロジェクトが顧客の要求と期待を満たす製品やサービスを提供することを保証することです。

品質を高めるための活動については、以下の記事で解説しているので参考にしてください。
 ・品質分析5つのポイント
 ・品質を定量分析する方法

品質計画の要素

品質計画には以下のような要素が含まれます。

品質基準
プロジェクトの成果物が満たすべき具体的な品質基準やパフォーマンス基準を定義します。
これには国際基準や業界基準も含まれる場合があります。

品質目標
プロジェクトの品質に関する具体的な目標を設定します。
これには顧客満足度、遵守すべき法規制、内部品質基準などが含まれます。

品質管理活動
品質基準と目標を達成するために行われる活動を説明します。
品質計画、品質保証、品質管理、品質改善などのプロセスが含まれます。
プロジェクト計画では、どのような活動を行うことで品質を確保するのか計画に含めます。

品質メトリクス
品質の測定に使用される具体的な指標や方法を定義します。これには、エラー率、顧客満足度、テスト通過率などが含まれます。
システム開発では、主にテスト実施時の不具合検出密度やレビュー工数密度などの指標値を使うことがありますが、これは「達成したら合格」というゴール設定ではなく、品質状況を測るための基準値であることに注意しましょう。

品質監査とレビュー
品質管理プロセスを評価し、改善のためのフィードバックを提供するための監査やレビューの計画です。

トレーニング計画
プロジェクトチームが品質基準に従うために必要なスキルや知識を身につけるためのトレーニングの計画です。

品質確保するためのコスト

システムの品質を確保するためにレビューやテストを実施しますが、これらの作業にどれくらいコストをかけるのか検討します。
WBSまでタスク分解する前の段階では工程ごとの作業工数の比率で算出することが多いです。
参考としてIPAのソフトウェア開発データ白書を参考にすると、新規開発における中央値における割合は次の通りです。

  • 基本設計     :17%
  • 詳細設計     :17%
  • 製造・単体テスト :33%
  • 結合テスト    :20%
  • 総合テスト    :13%

これは平均的な割合であるため、システム特性により見直しが必要です。
例えば、システム停止したときの影響が「業務で少し困る程度」と「人命にかかわる」では品質の作り込みが異なります。
後者の場合はテストの量や期間も変わりますし、設計や製造段階における品質対策も異なってきます。
この辺りはスコープ・ベースラインで設定した作業範囲や制約事項をもとに算出します。

ちなみに品質コストには不具合を回避するために行う「適合コスト」と、不具合を解消するための「不適合コスト」の2種類があります。

不適合コストのうち、外部不良コストは内部不良コストに比べて影響が大きいです。
本番稼働後に不具合が発生した場合、プログラム修正だけではなく影響調査や、被害に対する補填といったコストが発生するためです。

品質尺度

品質尺度とは、いわゆる品質の基準値のことです。

例えば工場のロットで対象生産される部品の品質を測るのであれば、サンプリングした部品の欠陥頻度をもとに算出し、規定値と大小比較することで判断する方法があります。

しかし、システム開発では品質状況を目でみるのは難しいです。
単純に「テストで不具合が少ない品質と品質が良い」とは言えません。
もしかしたらテスト量が少ないだけかもしれません。

しかし何かしら基準がないと判断もできないため、次の数値をもとに判断します。

  • 設計書ページあたりの不具合発生率
  • ステップ数あたりのテスト項目件数
  • ステップ数あたりの不具合発生率

過去プロジェクトの設計書ページ数、ステップ数、不具合発生数を集計して発生率などを算出します。
ちなみに言語や業務内容によって分類分けすることで、精度の高い基準値として利用することができるのですが、諸元データがない場合はIPAのデータ白書を活用することも有効です。
ただし他企業のデータを使用しているため、各ベンダにマッチしていない可能性も高いです。
できるだけ自社内で基準値を設けるのが望ましいです。

この基準値を使った不具合の予定件数と、実際に発生した不具合件数を比較して判断するのですが、この数値に近ければ品質が高いというわけではありません

予測値と実績値を比較して、例えば「予想件数が10件のところ、1件しか出なかった」のように大きな乖離が発生したときに、その理由を考察するために使用します。
 例えば
 ・テストケースが少ない:追加テストを実施
 ・類似プログラムを流用したから不具合が出ない:問題なし

品質の作り込み

品質の作り込みは上流工程から始まります。
テストを大量に実施して不具合を出し切ることもありますが、上流工程で不具合を予防することが鉄則です。
上流工程で混入した1件の不具合が検知されずテスト工程で発見した結果、広範囲の修正につながることもよくあります。
要件漏れが発生しようものなら収拾がつかなくなることもあります。
そのため各工程で品質を作り上げる対策を行うのか検討します。

要件定義の品質対策例

要件トレーサビリティの作成

RFPから要件を全て一覧化し、要件定義書のいずれに該当するのか紐づけます。
要件定義以降も、どの設計書に紐づけているか明確化することで要件の対応漏れを防ぎます。

ウォークスルー

要件をパーツごとに検討した後、全体を通して整合性が取れているかステークホルダーを招集して全体の流れをチェックします。
これによりポテンヒットのような抜け漏れや、整合性の取れていない要件を確認します。

予防対策例

品質分析

不具合の発生率や原因区分をもとに傾向分析を行います。
例えば外部インターフェイスに関する不具合件数が多い場合は、その理由を考えて対策することで、次から不具合の混入を予防することができます。

レビューの自動化

設計書やプログラムを自動でチェックするツールを導入することで、指摘のバラつきを抑えたり、人手では難しい全量チェックなども実施可能にします。