【ASPICE】SUP.1 品質保証 Basic Practice (BP) とは?基本プラクティスの解説と説明

ASPICE

ASPICE解説は下記リンクよりアクセスください
プロセスアセスメントモデルはコチラから
※当該解説をより詳細に知りたい方はアセスメントモデルを参照ください

▶ ASPICEの他解説ページへ

SUP.1で求められること

品質保証は独立した組織を形成し、独自の戦略に基づいて客観的な視点からプロジェクトチームがプロセスに準じて活動できているか監視し、品質目標を遵守することが主な活動となります。

そのため、
プロセスが定義した作業成果物などが計画通りに作成されているか?
何か問題が発生した場合は、その問題が展開され、トラッキングされ、解決されているのか?
またエスカレーションをするための方法や権限が確立されているのか?
等が求められます。

SUP.1で得れる成果

SUP.1を実装することで得れる成果は以下の通りです。

SUP.1では品質保証の戦略が求められており、品質保証戦略の作成・実施及び維持が確立されます。
品質保証戦略の策定により、組織における品質保証部門の立ち位置と品質保証活動の目的や目標が明確になります。ASPICEでは品質保証部門の独立性を担保することが求められており、これにより品質保証機能の独立と客観的観点での検証や監視の実現が可能となるのです。

この独立性が保たれた品質保証部門によって、プロジェクトチームがプロセスに準じた活動を行い、定義された作業成果物が作成され、組織の定めるルールやコンプライアンスに準じているのか監視/監査が行われます。

もし仮に上記の作業成果物や活動等に不適合が生じた場合は、それらの問題が、識別、記録、関係者へ伝達、トラッキングされ解決まで導かれているのか確認することも品質保証部門の活動の一環です。品質保証がでは問題の把握(何がどういう状態なのか)が求められることとなります。

なお、この独立した品質保証機能として独自のエスカレーション手法が確立されていなくてはなりません。必要な権限が確立され、適切な階層のマネジメントにエスカレーションされるような状態であることもSUP.1を実装することで得られる効果の一つとなります。

SUP.1の基本プラクティス (BP)

基本プラクティスの詳しい説明へ

基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SUP.1 品質保証には合計6つの基本プラクティス(BP1~BP6)が存在します。

BP1

BP1では品質保証戦略の策定し、実装することが求められています。

品質保証戦略とは品質保証部門の活動 (検証・監査) を定義したものです。活動の手法、技能、ツール、情報及びスケジュールをまとめた『品質保証計画書』であり、そのなかで活動の目標やゴールを定義します。

この計画書が品質保証部門の目的意識になり、この計画書をモチベーションに品質保証活動に取り組むことになります。

品質保証戦略では独立性のある品質保証部門を確立する必要があり、客観的視点を用いてプロジェクトチームが作成した作業成果物の状況や、プロセスに準じた活動が実施されているのか検証できる体制を構築します。プロジェクトチームの活動を検証するための手法、ツール、分析方法等が定義され、定期的に確認を行い関係者へ報告および改善に繋げるまでが含まれます。

この独立性には財政的または組織構造的に独立した体制を構築する必要があります。例えば品質保証部員のバジェットはプロジェクトが持つバジェットとは別に存在したり、品質保証本部は技術開発本部と別に存在したりするなどです。

プロジェクトチームが作成する作業成果物は適切な関係者でのレビューを通し、そこで見つかった問題点とその改善が行われているのか品質保証は確認をすることが必要となります。即ち、どの作業成果物はどういう手法でレビューをしなくてはならず、作業成果物の関係者が定義されており、それらのレビューをトラッキングできる状態を構築する必要があります。

BP2

BP2では作業成果物の品質保証が定義されています。

プロジェクトチームの活動によって作成される作業成果物は、品質保証によって保証される必要があります。具体的には、レビューなどを通し作業成果物の要件(品質要件や達成度合い等)を満たしているのか検証される必要があります。

各作業成果物に対して『どういう完成度であれば合格か』判断できる環境を整える必要があります。例えばチェックシートを作成し、必ずレビューを通して当該作業成果物をリリースできる環境を整えましょう。

このレビューで発見された問題点は文書化された情報として保存され、どのような対応(解決策)を、誰が、いつまでにするのかを明記し、問題が解決されるまでトラッキングすることも品質保証活動の一環です。

実際に行われる監査では、規定された指定のテンプレートに従って作成されていることや、記載されるべき内容がすべて記載されているのか、日付や改定履歴に問題はないかなどに着目されます。必要に応じて日ごろから作業成果物を更新し維持する必要があります。

BP3

BP3ではプロセス活動の品質保証が定義されています。

プロジェクトチームはプロセスに定義されたルールや手順に沿って活動を行いますが、品質保証はプロジェクトチームとは別の視点でプロジェクトチームの活動を保証します。BP1で品質保証は他部門とは独立性のある組織を構築しなくてはならないと定義されていましたが、プロジェクトチームとは独立した利害関係のない視点からプロジェクトチームの活動を保証します。

具体的には品質保証独自の評価手法が確立され、その手法に基づきプロジェクトチームの活動を検証・評価することで、それぞれの活動がしなくてはならない要件を満たし達成しているのか確認します。

品質保証としての評価手法としては、確認しなくてはいけない項目(作業成果物、プロセスやルールの厳守など)を定義し、それらの達成状況を監視することです。例えば、作成された作業成果物に対するレビューやレビューを通して発見された問題を分析しプロジェクトチームに結果をフィードバックし改善へ繋げることです。

BP4

BP4では品質保証活動の結果を要約し、関係者へ伝達することが求められています。

作業成果物のレビュー結果やそこで発見された問題点を記録化して要約します。その記録をプロジェクトチームへフィードバックして是正を依頼し、品質保証活動の取り組みと、プロセスからの逸脱や目標の達成度を定期的に報告する必要があります。

この報告はプロジェクトチーム関係者のみではなく、品質保証責任者にもフィードバックされなくてはなりません。

なお監査ではフィードバックを行った記録(エビデンス)を確認されるため、すぐに出せる準備をしておくことが望ましいです。

BP5

BP5では発見された問題の解決することを保証するよう定められています。

発見された問題はどういったもので、それらが解決されるまで状態を把握しトラッキングできる状態にしなくてはなりません。状態というのは問題が解決されたのかどうか解決状況を品質保証部門は把握する必要があります。この結果・状況をBP4で定義されている通り、プロジェクトチームへフィードバックしなくてはなりません。

品質保証部門は問題の把握のみではなく、不適合事項が再発しないように予防することも重要となります。真因究明の手法を理解し、実際に実施された事例をもとに監査では根本対策が行われたことを説明できるように準備することが望ましいです。

BP6

BP6では品質保証のエスカレーション手順・手法を確立し実装することが求められています。

様々な事情からプロジェクトチームにフィードバックを行ったのにも関わらず是正が行われないこともあります。単純に怠慢で行われないこともありますが、リソース不足や納期が迫っているなどです。そのため、品質保証独自のエスカレーション手順・手法によってプロジェクトの不適切な状況を上解決に導くことのできる実行力のある上位管理職へエスカレーションを行います。

独立した組織である品質保証が独自の検証項目に基づき、プロジェクトチームとは別にフラグを立てて解決まで導くことができる組織構築がポイントです。

このエスカレーションの仕組みはBP1で述べた品質保証戦略の一部として品質保証計画書に織り込む必要があります。

SUP.1 BPのまとめ

  • 品質保証戦略(品質保証としての目標やモチベーション)を立て品質保証計画書を文書化する必要があります。
  • 品質保証はプロジェクトチームとは独立(財政的・構造的)している必要があります。
  • 品質保証はプロセスで定義された作業成果物の作成を徹底する必要があり、レビューで検出された問題点は解決されるまで追跡する必要があります。
  • 品質保証活動は要約され関係者(プロジェクトチームメンバー/上位管理職)へフィードバックされなくてはなりません。
  • 品質保証独自のエスカレーション手法が定義される必要があります。プロジェクトチームが是正を行わない場合には解決する実行力をもつ上位管理層へエスカレーションされ解決まで導きます。

1万PV以上のアクセスを誇るブログに広告掲載!

ASPICEの解説はコチラ!

▶ASPICEの解説をもっと見る

\noteを始めました/
年収情報から品質経験を綴っています

\他にも色々なブログを書いています/

転職2回を経験→年収200万UP
この経験を配信します!

私が転職に至るまで(体験記)

品質基礎知識の情報発信!
品質ツールをまとめました

このカテゴリをもっと読む

トップページへ戻る

コメント