当記事のリンクには広告が含まれています
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.9 構成管理には合計9つの基本プラクティス（BP1～BP9）が存在します。
SUP.9（問題解決管理）の目的はプロジェクトで発生した問題が識別され、管理、分析、解決まで導くことを確実な状態にすることである。
BP1
問題解決管理のために戦略を策定することが求められています。戦略と聞くと回りくどいですが、問題解決のための環境を整えることを示します。開発プロジェクトではマイルストンを通して様々な問題が生じてきますが問題解決戦略を構築することで、どのマイルストンでも一貫した問題解決手法が取られ抜け漏れなく問題を管理することが必要となります。
問題解決戦略には、問題解決までの活動を行うためのリソース（例えば、人的リソースと責任・役割権限の明確化、窓口管理、問題解決ツールの構築等）や問題の種別定義や状況（ステータス）の管理、問題解決手段（例えば、フロー図や手順書等）、問題の分析や周知の方法などを織り込まなくてはなりません。
具体的に、問題解決管理計画書などを作成し、その中で問題の種別を定義し、どのような問題にはどういったフローで解決まで導くのかを定義します。その中で関係部門のRASIチャートや、必要とされる問題管理ツールを定義し、必要なスキルを明確にしたうえで関係者の教育を行わなくてはなりません。
なお問題解決の定義やプロセスはプロジェクト計画書などにも記載され、互いにリンクしていることが望ましいです。
BP2
問題管理のうえで、問題を識別し記録することが求められています。複数個ある問題を識別することで問題を抜け漏れなく管理し、過去の問題にも遡れ再発問題などの診断・分析に役立てます。実際に問題が起こりえるケースは様々あり、例えば作業成果物をレビューしていたときの不整合や開発スケジュールの遅れ、人的リソース不足などが挙げられる。
上記のような問題を管理するうえで、管理番号（ID）、問題の出所、発見者、問題解決にアサインされた人、初期情報、問題解決のクライテリア（何をもって問題解決と言えるのか）、再現方法、問題のステータス（何もしてない、調査中、キャンセル、解決済など）、緊急度等の情報を記録しなくてはなりません。
BP3
問題のステータスを記録することが求められています。問題をトラッキングするのが容易となるよう、問題がどのような状況なのかを割り当てなくてはなりません。
例えば、問題が発生して初期情報を割り当てた直後なのか、調査中なのか、それは本当に問題だったのか（再発問題で既に原因はわかっている問題だったり、本当は問題ではなくキャンセルできる事象だったり等）、対策済、源流へのフィードバック（再発防止）済等が挙げられます。
BP4
問題の原因と影響度の分析を行うことが求められています。問題にも程度が存在しマイナーな問題なのか、それとも他にも影響が出てくるようなメジャーな問題なのか等、問題の分類（例えば、低・中・高）などを定義をしたり、緊急で解決しなくてはならない問題なのかを分類しなくてはなりません。
BP5
緊急で解決しなくてはならない問題のために権限を付与しなくてはなりません。特に緊急で対処しなくてはならない問題が生じた場合、BP4で構築した仕組みに準じて緊急問題と定義付けます。その際に他とは異なる特別な対処方法を問題解決戦略に定義し、運用を行わなくてはなりません。
例えば、緊急問題は何日の間で解決しなくてはならないのか組織的に目標値を設定したり、程度が低い問題とは別管理を行ったり、緊急度が高い問題だけ特別にトラッキングを行って関係者へ報告を行ったり等が挙げられます。
BP6
問題が他システムやプロジェクトにも大きな影響を及ぼす場合は、戦略に基づき警告を通知しなくてはなりません。
問題が他システムやプロジェクトにも波及する恐れがある場合は、例えば問題管理システムや社内メールを通して他プロジェクトに情報を飛ばしたり、問題解決チケットを切ったりして水平展開ができる戦略を構築しなくてはなりません。
BP7
実際に問題解決に向け、原因調査や初期情報の収集を開始するために、何を行わなくてはならないのか戦略に織り交ぜる必要があります。例えば、問題を発見した人が初期情報（日付、場所、どうやって、どういった等）を入れ、設計を取りまとめる専門部署に情報を飛ばし、その専門部署が一次切り分けを行い、更なる深い調査を行うために具体的に何をしなくてはならないのか指示を行い調査促進をする、といったイメージです。
そのため、問題管理システムや戦略に調査フローが定義され、それに基づき問題解決を開始しなくてはなりません。なお、対策のレビュー（妥当性確認）及び何かを変更する際の変更依頼も戦略で考慮することが求められています。変更依頼とは、例えば図面といった社内ドキュメントを更新する指示を飛ばしCloseするまでトラッキングができるような仕組みです。
BP8
問題解決が完了するまで全てのステータスをトラッキングできる環境を構築しなくてはなりません。BP3で記載しているように、問題が具体的にどのステータスにいるのか管理して、トラッキングできる状態を構築しなくてはなりません。
このトラッキング情報をレポートをまとめ、プロジェクト進捗会議やマイルストンレビューなどで報告され監視される必要があります。
BP9
問題の傾向分析を行うことが求められています。上記BP1-8までで、問題の情報を管理してトラッキングできる状態になっているので、BP9ではその情報を元に問題の傾向を分析しなくてはなりません。
分析手法は様々ですが、例えばオープン/クローズの状況を確認したり、解決済/調査中/調査未開始などステータスの情報から状況を分析したり、バーンダウンチャートを用いて目標値との差分を検証したりといった方法が考えられます。
コメント