当記事のリンクには広告が含まれています
ASPICE解説は下記リンクよりアクセスください
プロセスアセスメントモデルはコチラから
※当該解説をより詳細に知りたい方はアセスメントモデルを参照ください
能力レベル3の取得を目標とした記事となります
Generic Practices とは？
既に説明を読んでいる人は飛ばしてください
- 全てのプロセスカテゴリーに当てはまる、共通の活動が記述される
- BP（基本プラクティス）で実施されたプロセスを成熟させるために利用される
BP (Basic practices: 基本プラクティス)は能力レベル1（PA1.1）のみに適用され、それ以上の能力レベル（レベル2～5）ではGP (Ganeric Practices: 共通プラクティス)とGR（Generic Resource: 共通リソース）が適用されます。
より詳しく知りたい方は、アセスメントモデルの【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.9の基本プラクティス
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SUP.10 変更依頼管理には合計8つの基本プラクティス（BP1～BP8）が存在します。
SUP.10（変更依頼管理）の目的はプロジェクトで発生した変更依頼を管理して追跡し、変更を完了されることを確実な状態にすることである。
BP1
変更依頼管理戦略の策定を求められています。変更に関わる活動を組織の標準やプロセスとして定義しなくてはなりません。必要となる手順、リソース、責任分担や影響度分析を定義し、変更依頼管理を実施するうえでの戦略を構築しなくてはなりません。
変更をクローズするまでの大まかな流れとしては下記です。
① 変更内容を明確化
② 変更の重要度を定義
③ 変更による影響度分析
④ 実施可否判断
⑤ 変更承認
⑥ クローズ
この変更プロセスの中に、初期流動管理やレポーティング、影響度分析手法などが織り交ぜられて戦略を定義していきます。
変更依頼管理戦略に入れ込むべき内容の事例としては下記のようなものが挙げられます。
・ リソース管理（人、責任分担と権限の定義、変更管理システム及び教育資料やトレーニング等）
・ 影響度分析（ツール、手法、技能、クライテリア設定等）
・ 変更ステータス（変更のトラッキングを行うためのステータス定義及び管理手法の確立等）
・ 作業成果物（テンプレート、関係するドキュメントの明確化等）
・ 変更の検証（ツール、手法、技能、期間等）
・ 承認回覧ルールの確立（影響度によって承認レベルを変えたりする等）
BP2
変更依頼を管理するうえで、戦略に定義された内容に従い、各変更依頼を識別して変更依頼者と変更理由を記録することが求められています。
変更依頼を識別するうえで一般的に上げられる変更理由としては以下のようなものが挙げられます。
・ 問題解決に伴う変更（不具合や監査、レビューなどによって検出された問題を解決するためにドキュメントや工程等を変更する。）
・ ステークホルダーからの変更（関係するステークホルダーからの要請で行われる変更。例えば、仕様変更や工程変更申請などが挙げられる。）
なお誰が変更依頼をしてきたのか管理する必要もあり、例えば開発プロジェクト、サプライヤ、顧客、自社工場等も管理するうえで記録を残さなくてはなりません。
その他にも、変更依頼管理をするうえで記録をしなくてはならない項目の事例としては下記が挙げられます。
・ 識別ID
・ 変更依頼の申請日
・ 変更概要
・ 変更申請者
・ 変更の影響度／緊急度
・ 現状ステータス
BP3
変更依頼をトラッキングできるようにステータスを記録することが求められています。BP1に変更をクローズするまでの大まかな流れを記載しましたが、現在の進捗がどのステータスにいるのかを変更依頼管理戦略に従い割り当てる必要があります。
BP4
変更依頼を戦略に従い影響を受ける作業成果物を含めて分析を行う必要があります。変更依頼の影響を評価して何を変更しなくてはならないのかを確認するための基準を確立しなくてはなりません。
変更が生じた際の影響度を分析しなくてはなりません。影響度分析の際に考慮する事例は以下のようなものが挙げられます。
・ 影響を受ける作業成果物（例えば、起票（図面やFMEA等）、ソフトウェアデータ、BOM等）
・ 影響度レベル（低、中、高）
・ 緊急度レベル（緊急か否か）
・ 変更リソース（関係部門等）
・ 変更スケジュールの明確化
・ 変更によるメリット
BP5
戦略に従い、変更を実施する前に分析結果に基づいて変更の承認を行う必要があります。変更の承認には、適切な権限を持つ人に承認を貰った上で実施しなくてはなりません。
変更影響分析に基づき CCB（Change Control Board：変更制御委員会）が変更の実現性や優先度を審議し実装の計画を行う必要があります。CCBが考慮するポイントとして、リソース、スケジュール、影響度等が挙げられます。
BP6
変更依頼の実装内容をレビューすることが求められています。BP4で求められている影響度分析の結果から、影響を受けた作業成果物の更新がレビュー／完了しているのか、実装を行う際の判断基準を満足しているのか、変更依頼管理戦略（プロセス）に基づいているのか等をレビューしなくてはなりません。
このレビューに基づいて変更を実施しなくてはならず、レビューの記録（エビデンス）に項目が抜け漏れなく記載されているのかも重要となってきます。
BP7
変更依頼がクローズするまで案件をトラッキングしていく必要があります。そしてその追跡結果を変更依頼者へフィードバックしなくてはなりません。
トラッキングするにあたり、BP1で定義した変更依頼管理戦略に基づき変更ステータスを付与する必要があります。
変更ステータスの事例としては以下が挙げられます。
・ 新規申請
・ 調査中（影響度分析）
・ 審議中
・ 変更承認済
・ 変更実装済
・ クローズ
BP8
双方向トレーサビリティの確立を行わなくてはなりません。双方向トレーサビリティとは、相互関係にある変更依頼と影響を受けた内容（作業成果物更新等）が、それぞれ両方向からトラッキングできる仕組みのことをいいます。
例えば、とある変更依頼により作業成果物の更新が必要となった際、その変更依頼でどの作業成果物更新が必要となったのか、逆にその作業成果物更新はどの変更依頼で生じたものなのか、両方向からでもトラッキングできるようにしなくてはなりません。
作業成果物更新が複数ある場合でも、変更依頼とのトレーサビリティ（紐づけ）が一貫性を持ち、完全なものである必要があります。
コメント