品質保証活動の実践活動（その１：リスク管理）

リスクは、先ず始めに、定義フェーズ＊で潜在的な要因を分析しリスク設定を立案することから始めなければならない。

次に、リスク設定で立案したリスクランク＊＊に対してリスクの回避策や軽減策を盛り込んだ開発計画書／プロジェクト計画書を作成し対策を具体的に推進していくことにより、トラブルプロジェクトの発生を未然防止するものである。

＊：ソフトウェアの品質（ソフトウェアのライフサイクル）を参照。
＊＊：考え方の事例を示す。


事例１：
例えばリスクランク１～４の４段階（要求される信頼性を秒オーダで回復要、分オーダで回復要、１時間以内に回復要、１時間以上で回復）とし、定義フェーズの見積り時に設定する。

ランク決定の要因項目としては、開発・構築するシステムの位置付け・影響度、及び信頼性に対する顧客ニーズから判断する。

リスクランクは、開発対象となるシステムに対するランクであり、当該システムのプロジェクトそれぞれの開発作業、及び稼働後の保守作業に対しても適用される。

すなわち、顧客見積りに反映・申請しなければならない事項であり、お客様に必要性を理解してもらうことが重要である。


事例２；
5段階のリスクランクの場合。

本事例は、システムの重要度（顧客の立場）よりメーカとしての立場からリスクランクを設定する事例である。

この場合でも事例１のシステムの考慮は部門内で行う必要があるのでリスクの高いものは、事例２においても必然的に監視が必要な高いランクに反映される。

５；全社重要プロジェクト：全社で特別に監視が必要な重要プロジェクト
４；事業部重要プロジェクト：事業部で特別に監視が必要なプロジェクト
３；部門の重要プロジェクト：部としての監視が必要なプロジェクト
２；課の重要プロジェクト：課としての監視が必要なプロジェクト
１；ユニット内プロジェクト：自主管理にとどめるプロジェクト