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