当記事のリンクには広告が含まれています
ASPICE解説は下記リンクよりアクセスください
プロセスアセスメントモデルはコチラから
※当該解説をより詳細に知りたい方はアセスメントモデルを参照ください
能力レベル3の取得を目標とした記事となります
Generic Practices とは？
既に説明を読んでいる人は飛ばしてください
- 全てのプロセスカテゴリーに当てはまる、共通の活動が記述される
- BP（基本プラクティス）で実施されたプロセスを成熟させるために利用される
BP (Basic practices: 基本プラクティス)は能力レベル1（PA1.1）のみに適用され、それ以上の能力レベル（レベル2～5）ではGP (Ganeric Practices: 共通プラクティス)とGR（Generic Resources: 共通リソース）が適用されます。
より詳しく知りたい方は、アセスメントモデルの【5.3.1 実施管理プロセス属性】以降を参照ください。
能力レベル1-2-3を例えるのであれば、料理なんかが良い例だと思います。
レベル1：レシピ通りに作ってるが、何を調合したのかわからず同じ味を再現できるか不明な状態。
レベル2：レシピに何をどのタイミングで調合するのか記載され、似た味を再現できている状態。
レベル3：レシピがレストランの決まりに組み込まれ展開されており、誰でも同じくできる状態。
即ちの能力レベル1では何となく実施してリリースができている状態に対し、能力レベル2以上ではプロセス（レシピ）が存在して計画・実行・調整がかけられる状態を示します。
Generic Practices の構成
Generic Practicesを能力レベルで分けた表は以下の通りです。
| 能力 レベル |
プロセス属性 | 項 | 説明 |
| L2 | 実施管理プロセス | GP2.1 | プロセスの実施が管理されている程度を示す |
| 作業成果物管理プロセス | GP2.2 | プロセスにより作成される作業成果物が管理されている程度を示す | |
| L3 | プロセス定義プロセス | GP3.1 | 定義されたプロセスが維持されている程度を示す |
| プロセス展開プロセス | GP3.2 | 定義されたプロセスの展開されている程度を示す |
SUP.1 GP2.1 の説明と解説
GP 2.1.1
品質保証の活動の目的と達成すべき目標が設定されプロセスに織り込まれている状態にしなくてはなりません。
このプロセスに組み込まれた目標こそが、品質保証部員が活動を進めるうえでのモチベーションとなり品質保証機能が正しく運用されることになります。
一般的に品質保証活動はプロジェクトやプロセスが定める品質目標を厳守することが目的となるため、品質計画書などにおいて品質目標が掲げられ、その目標の達成をモチベーションに品質保証活動が行われている状態にします。
この目標は品質保証活動をするうえでの前提のリソース（品質保証担当者、評価ツール、品質保証ガイドライン、報告書、スケジュール等）を考慮し明記されることが望ましいです。
GP2.1.2
GP2.1.1で活動の目標を設定した次は、その目標を達成するために計画を策定する必要がでてきます。
品質保証の活動を実施するために必要なリソース、工数、コストや活動を定義して計画に織り込む必要があります。プロセスアセスメントモデルを参照いただくとわかりやすいですが、主要なマイルストーンを確立し、必要なタスクや作業成果物のレビュー計画を定める必要があります。それだけではなく、各タスクに対する工数も見積もり計画書に落とし込みます。
即ち、ただ単純にタスクや作業成果物が書かれるだけではなく時系列でのスケジューリングが求められます。自動車業界での事例でいうとSOPまでのマイルストーンが確立され、どのタイミングで何をしなくてはならないのか品質保証活動の視点で計画（スケジューリング）を立てます。
GP2.1.3
GP2.1.1/GP2.1.2はPDCAサイクルでいうと『P：計画』に該当する部分でしたが、GP2.1.3が品質保証活動での『監視』を示した部分となります。
品質保証が作成しなくてはならない作業成果物のみではなくプロジェクト全体での作業成果物作成状況やプロジェクトの進捗度合いや問題解決の状況を監視する必要があります。
プロセスが定めている決まりを守れているのか品質保証は監視をしていかなくてはなりませんので、品質保証は、監査報告書や各ドメインが作成する作業成果物をあらかじめ特定しておく必要があります。
GP2.1.4
GP2.1.4では活動の調整を確実に行うことが述べられています。調整とは、品質保証による監視を通して問題や変更が見つかった時に、品質保証の活動自体を調整していくことをいいます。
プロジェクトは開発マイルストーンと同様に進んでいっているものになるので、その中で逸脱や変更は多々発生します。例えば、プロセスが定める決まりから逸脱したり、顧客からの仕様変更、開発計画の変更などが挙げられます。
このような逸脱や変更が発生した場合は、品質保証計画書を更新して維持する必要があります。顧客要求事項（仕様や品質ガイドラインなど）の更新などが良い事例だと思います。品質保証もプロジェクトと共に活動をしているので、プロジェクト計画が前倒しや遅延が発生した際には、品質保証が持つ計画書やスケジュール表も更新しなくてはなりません。
GP2.1.5
GP2.1.5では、品質保証が活動をする上での責任及び権限を定めなくてはなりません。
品質保証がどのような機能や権限を持ち、どういう仕事を担うのかプロセスで定める必要があります。例えばチームメンバーリストや組織図、プロセスのRoleなどに品質保証の仕事が明確に記載されている状態が必要となってきます。
GP2.1.6
GP2.1.6では、品質保証が活動をする上でのリソースが明確にされて、いつでも誰でも利用可能な状態にしなくてはなりません。またそのリソースを使いこなすためのトレーニングや教育を行うことも定められています。
まず品質保証が活動（監視）を行う上でのツールはどういうものが存在するのか明確にします。そのうえで、品質計画書や社内プロセスなどにそのツールが定義されなくてはなりません。例えば、ワークプロダクトが何でそれらのレビューはどうだったのか、またトラッキングができたり、確かなレビューが行われた履歴が確認できたりする環境を構築する必要があります。
そのうえでのポイントとして『品質保証が監視するべき対象が明確になっていること』『どのように監視をするのか方法論が明確になっている』『人的異動があるなか誰しも使える状態になっている（ツールの在処／教育・トレーニング）』『人的リソース（工数）が明確になっている』ことになります。
このようなツールなどは体制的に定義され誰しも使える状態にしておき、更に人的リソースに対しても教育・トレーニングを通して誰しもが業務遂行ができるプロセスになっていなくてはなりません。
ワークプロダクトに対してどのようなチェックをしていけば良いのかはGP2.2が参考になるかと思います。
GP2.1.7
関係者間での窓口が明確になっている必要があります。品質保証における個人・グループが明確になっており、関係者間の窓口が明確になっている必要があります。
例えば組織における部門や役割（階級）などが明確になっている体系的な組織図が存在し、エスカレーション手法と結び付けて説明できる情報や手段を確立しておく必要があります。
実際に図示化された体系的な組織図が存在し管理職・経営層が明確になり、どの情報が誰に伝達されるのかを明確にしておくべきです。これは情報伝達が抜け漏れのなく効率的なコミュニケーションを実現するためでもあります。
コメント