米国企業改革法 (SOX 法) 第 404 条と Visual Studio Team System 2008

[アーティクル]
09/17/2008

Andrew Delin、Microsoft Corporation

2008 年 4 月

概要

Microsoft Visual Studio Team System 2008 は、企業がソフトウェア開発業務に関する情報を収集する際に利用できます。これは、米国企業改革法 (SOX 法) 第 404 条 (SOX 404) の内部統制の検証とテストなど、規制フレームワークの遵守に利用できる場合があります。

対象製品:

Visual Studio Team System 2008

背景

法令遵守の価値

法令順守関連の用語

米国企業法 (SOX 法) 第 404 条の認定に向けた準備

規制フレームワーク導入の概要

Visual Studio Team System 2008 による法令遵守の支援

シナリオの紹介

Visual Studio Team System 2008 に統制を実装するためのカスタマイズ

はじめに

Visual Studio Team System 2008 は、汎用の法令遵守パッケージ製品ではありません。米国企業改革法、特にその第 404 条は、ソフトウェアアプリケーション開発以外の事業も対象としているため、Visual Studio Team System 2008 が役立つのは、企業が取り組む必要がある法令遵守対策全体の一部に過ぎません。また、企業が抱える SOX 404 のリスクと統制は、企業によって異なります。この記事で紹介するシナリオは、顧客の法令遵守の報告に必要なものではなく、あくまでも例として参考にしてください。

この記事では、Visual Studio Team System 2008 を使用して、ソフトウェア開発における米国企業改革法への遵守を支援するシナリオの例を紹介します。米国企業改革法の遵守は、全社規模で適用される規制フレームワークの一例であり、一貫性のある管理方法が必要とされます。ここで説明する概念は、情報システムコントロール協会 (COBIT)、米国トレッドウェイ委員会組織委員会 (COSO)、国際標準化機構 (ISO) など、他の規制フレームワークに Visual Studio Team System 2008 を使用する場合にも当てはまるものがあります。

Visual Studio Team System 2008 は、コラボレーションによるソフトウェア開発の生産性を向上することを目的とした密接に統合されたソフトウェア開発ツール群です。ソフトウェア開発チームの詳細な作業状況を追跡し、ソフトウェア開発に関係のある米国企業改革法第 404 条の要件の遵守に利用できます。

法令遵守を実施する環境では、Visual Studio Team System 2008 を次のような形で利用できます。

意思決定の内容、生成された成果物、実行された対応など、詳細なプロジェクト情報の収集システムとして利用できます。
プロジェクトの過去または現在の状態についての詳細な臨時レポートをいつでも生成できます。
SOX 404 の専門家によって定義された正式なリスク統制フレームワークを採用している場合に、役立つ可能性があります。

注 :
この記事では、ソフトウェア開発に関する SOX 404 要件を組織内に実装するうえで Visual Studio Team System 2008 をどのように活用できるかを示すシナリオの例をいくつか紹介します。これらのシナリオは、あくまでも参考のためのもので、"標準" または "推奨"の SOX 404 統制ではありません。各組織では、それぞれの法的義務を果たすために、独自の法令遵守フレームワークが開発されており、収集するデータや確立されたプロセスは組織によって異なります。

この記事では、ソフトウェア開発に関する SOX 404 要件を組織内に実装するうえで Visual Studio Team System 2008 をどのように活用できるかを示すシナリオの例をいくつか紹介します。これらのシナリオは、あくまでも参考のためのもので、"標準" または "推奨"の SOX 404 統制ではありません。各組織では、それぞれの法的義務を果たすために、独自の法令遵守フレームワークが開発されており、収集するデータや確立されたプロセスは組織によって異なります。

Visual Studio Team System 2008 は、企業がソフトウェア開発業務に関する情報を収集する際に利用できます。これは、米国企業改革法 (SOX 法) 第 404 条 (SOX 404) の内部統制の検証とテストなど、規制フレームワークを遵守するうえで利用できる場合があります。

Visual Studio Team System 2008 は、コラボレーションによるソフトウェア開発の生産性を向上することを目的とした密接に統合されたソフトウェア開発ツール群です。Visual Studio Team System 2008 は、ソフトウェア開発チームの詳細な作業状況を追跡し、ソフトウェア開発に関係のある米国企業改革法第 404 条の要件の遵守に利用できます。

法令遵守を実施する環境では、Visual Studio Team System 2008 を次のような形で利用できます。

意思決定の内容、生成された成果物、実行された対応など、詳細なプロジェクト情報の収集システムとして利用できます。
プロジェクトの過去または現在の状態についての詳細な臨時レポートをいつでも生成できます。
SOX 404 の専門家によって定義された正式なリスク統制フレームワークを採用している場合に、役立つ可能性があります。

注 :
この記事では、ソフトウェア開発に関する SOX 404 要件を組織内に実装するうえで Visual Studio Team System 2008 をどのように活用できるかを示すシナリオの例をいくつか紹介します。これらのシナリオは、あくまでも参考のためのもので、"標準" または "推奨"の SOX 404 統制と見なさないようにしてください。各組織では、それぞれの法的義務を果たすために、独自の法令遵守フレームワークが開発されており、収集するデータや確立されたプロセスは組織によって異なります。

この記事では、ソフトウェア開発に関する SOX 404 要件を組織内に実装するうえで Visual Studio Team System 2008 をどのように活用できるかを示すシナリオの例をいくつか紹介します。これらのシナリオは、あくまでも参考のためのもので、"標準" または "推奨"の SOX 404 統制と見なさないようにしてください。各組織では、それぞれの法的義務を果たすために、独自の法令遵守フレームワークが開発されており、収集するデータや確立されたプロセスは組織によって異なります。

背景

米国企業改革法 (SOX 法) は、米国内のコーポレートガバナンスの不備に対応するために、2002 年 7 月 30 日に制定された法律です。米国企業の多くが、アジア、アフリカ、欧州、オーストラリアで事業を展開し、パートナーシップを結んでいることから、同法は世界的に影響があると言われています。SOX 404 では、財務報告に関する内部統制 (ICFR) の有効性を保証する証明書の提出を義務付けています。証明書だけでなく、同法の要件を実装することは、組織がプロセスを改善し、業績目標を達成するうえで役立つ可能性があります。

この記事で紹介する例は、SOX 404 が規定する企業の内部統制の対象領域の 1 つであるソフトウェアアプリケーション開発において、使用できる業務管理に該当します。この記事では、監査やテスト段階で必要になる可能性がある内部統制のための情報の収集や生成に、Visual Studio Team System に付属の MSF for CMMI Process Improvement プロセステンプレートを利用する方法を紹介します。この記事で説明する方法で Visual Studio Team System 2008 を使用すると、監査担当者による監査プロセスで必要な情報収集を支援したり、必要なときに必要な情報を生成できます。

注 :
Software Engineering Institute の能力成熟モデル (Capability Maturity Model Integration (CMMI、能力成熟度モデル統合) は、カーネギーメロン大学のソフトウェア開発のベンチマークモデルであり、Visual Studio Team System 2008 のプロセステンプレートはこれを採用しています。SEI とその資料 (2005 Carnegie Mellon University) を MSF for CMMI Process Improvement で使用するための特別許可が、Software Engineering Institute により与えられています。CMMI は、カーネギーメロン大学により、米国特許商標局に登録されています。

Software Engineering Institute の能力成熟モデル (Capability Maturity Model Integration (CMMI、能力成熟度モデル統合) は、カーネギーメロン大学のソフトウェア開発のベンチマークモデルであり、Visual Studio Team System 2008 のプロセステンプレートはこれを採用しています。SEI とその資料 (2005 Carnegie Mellon University) を MSF for CMMI Process Improvement で使用するための特別許可が、Software Engineering Institute により与えられています。CMMI は、カーネギーメロン大学により、米国特許商標局に登録されています。

法令遵守の価値

規制フレームワークの遵守は、人に負担を強いて、組織のさまざまな部分のリソースを消費する厄介な作業として見なされることがあります。しかし、基本的に法令遵守の目的はリスク管理であり、業務プロセスの不備や欠如によるリスクから企業の所有者と株主を保護することを目的としています。このような問題が発生し、業者、パートナー、または消費者に影響が出ると、財務状況に大きな影響を受けるだけでなく、企業イメージや評判に傷が付くことになり得ます。法令遵守を達成することは、監査担当者が来社したときだけでなく、営業年度中をとおして、全社レベルで規定された規制目標が達成されることになります。採用したフレームワークの質にもよりますが、法令遵守によって、上層部の管理者や投資家が "正しいことが行われている" ことを確信できるようになります。また、そのことを実証でき、CXO やビジネス意思決定者が「何が起きているのかわからない」と認めなけれなならない事態を避けられます。SOX 法には、後者のような事態を許容する隙はほとんどありません。

法令順守関連の用語

この記事では、企業の法令遵守に関する特殊な意味を持つ専門用語を多数使用しています。このセクションでは、このような用語の一部を紹介します。

フレームワーク : 定義されているリスクと、全社レベルで適用され、特定の法令遵守の要件 (企業財務報告など) を伴う関連対策 (つまり、統制) をすべてまとめたものです。
リスクベース : フレームワークは、SOX 404 に関わる、最新で明確に定義されたリスク評価に基づいています。このリスク評価によって、統制目標の主眼となる、一連の特定の財務関連リスクが定義されます (統制目標については後で説明します)。
正式に定義されたフレームワーク従った実施 : フレームワークは、かなり厳格に規定されており、通常、資格のある認可された鑑定人により定義され、それを各企業に合わせてカスタマイズします。フレームワークには、チェックポイントとテストが含まれ、上層部の管理者に企業財務報告書のデータが正しいことの保証を求めるなど、さまざまな要件があります。

証拠ベース : フレームワークは実質的なものです。つまり、フレームワークによって、特定されたリスクを実際に管理するために企業内で対策がとられていることの証拠が生まれます。このような証拠がなければ、統制が機能していることは実証できません。

注 :
この記事で Visual Studio Team System 2008 に関連して "証拠" という表現を使用した場合、これは基本的に "情報" を意味するもので、Visual Studio Team System 2008 によって生成された情報が法令遵守の実現に十分な情報であることを示すものではありません。この点については、契約されている法律顧問や SOX 404 の専門家にご相談ください。

この記事で Visual Studio Team System 2008 に関連して "証拠" という表現を使用した場合、これは基本的に "情報" を意味するもので、Visual Studio Team System 2008 によって生成された情報が法令遵守の実現に十分な情報であることを示すものではありません。この点については、契約されている法律顧問や SOX 404 の専門家にご相談ください。

継続性 : フレームワークに含まれる対策は、繰り返し、かつ継続して実施されるものです。つまり、監査の時点でのみ "発生する" ものではなく、継続して行われるプロセスです。通常、監査担当者は、規定プロセスの継続的な実施が確立されるように取り組み、継続的に実施されていることを確認するために、不定期でサンプルとなる報告書を生成して細かく確認します。
行動指向 : 法令遵守は、ツールで達成できるものではなく、規定された対策を人が日常的に実施することで達成されます (たとえば、プロジェクトチームは、定期的にリスクを見直し、各実施項目についての意思決定を文書化する必要があります)。これは、ツールによるサポートと人的な活動を組み合わせて、必要な法令遵守レベルを実現できている、フレームワーク実装に見られる特徴です。多くの場合、部門の境界をまたいだり、人またはシステム間で活動フローが発生するため、法令遵守を達成するには調整を行う必要があります。
顧客に関連がある : 顧客 (または事業主) は、ソフトウェアアプリケーション開発業務の委託主である (内部または外部の) グループであり、この業務は SOX 404 要件に関する監査上重要であると見なされます。

米国企業法 (SOX 法) 第 404 条の認定に向けた準備

SOX 404 では、ICFT の有効性に関して、年次報告書を作成することが求められています。これは、会社の経営陣による正確な評価であることが、その会社の監査担当者によって保証される必要があります。この準備として、会社は、統制が機能していることを実証するための試査に耐え得る内部統制が実施されていることを証明する必要があります。通常、このような統制を策定したり、検証したりする作業には時間がかかります。このような統制は、リスクのフレームワーク内にあり、ここから統制が確立され、活動を定義し、証拠が作られます。これらは、フィードバックとして、プロセスのリスクと改善の管理に役立てられます。

次のセクションでは、このフレームワークの一例を紹介します。

フレームワークの導入後は、年次の SOX 404 報告書を作成する際に、特定の業務に対して定義された一連の統制のデータを作成する必要があります。この記事の後半で紹介するシナリオでは、ソフトウェアアプリケーション開発の統制の例に基づいて、この活動を説明します。また、Visual Studio Team System 2008 が、このような統制の証拠の作成と報告にどのように役立つかを紹介します。各シナリオでは、SOX の証明書に使用する年次報告書を作成するデータが作成されます。

規制フレームワーク導入の概要

さまざまな会社に共通する業務 (受注処理、買掛金、製造、研究開発、流通、販売、マーケティングなど) があるとはいっても、企業は自社の事業のリスク評価を独自に実施する必要があります。企業にとってリスク評価を行う目標は、SOX 404 に関連のある特定の一連のリスクを確立し、これらのリスクを長期間にわたって適切に管理する手続きを確立することです。図 1 は、最初のリスク評価の重要性と、各リスク管理とこの評価の関連を示しています。

図 1. ある企業の規制フレームワーク

図 1. ある企業の規制フレームワーク

この最初のリスク評価は、企業が、その企業の法令遵守関連の専門家の協力を得て実施します。この評価の範囲は広く、企業のさまざまな領域が対象になる可能性があります。これは段階的に実施され、より重要な事業領域とリスクを最初に確定する場合もあります。

企業で特定された妥当なリスクごとに、規制の統制目標を文書化し、リスク管理の意図を定義します。たとえば、"特定のリスク" が "ソフトウェアの変更に伴う費用が顧客または事業主に請求されないこと" である場合、これに対応する統制目標は、"すべての請求すべきソフトウェアの変更費用が請求されるように保証すること" になります。次に "統制活動" が行われます。これは、この統制目標を達成する手順で構成された一連の手続きです。たとえば、システムのすべての変更についての請求の可否状況 ("はい" または "いいえ") を示す報告書を定期的に準備することです。また、この統制活動では、報告書が会計部門に提出され、請求記録とずれがないようにする必要もあります。そして、報告書と会計部門への報告書の提出記録が、この統制の "証拠" になります。

Visual Studio Team System 2008 による法令遵守の支援

規制フレームワークは、IT だけでなく、事業活動のさまざまな分野を対象としているため、Visual Studio Team System 2008 は、組織内に導入した規制フレームワークの一部のみを支援するものと位置付けてください。Visual Studio Team System 2008 は、汎用の法令遵守パッケージ製品ではありません。ただし、次のセクションでは、Visual Studio Team System 2008 を使用して、準拠レビューや監査の監査段階やテスト段階において必要な証拠の作成と収集を支援できることを説明します。

図 2 は、組織の SOX 404 準拠要件全体のうち、Visual Studio Team System 2008 が支援できる範囲を示しています。

図 2. 企業のすべての法令遵守要件 (全統制目標)

図 2. 企業のすべての法令遵守要件 (全統制目標)

SOX 404 は、特に資産に影響する取引に関連するものであることに留意してください。ソフトウェア開発による財務的な影響が大きい組織では、Visual Studio Team System 2008 を利用して、SOX 404 要件に準拠していることを示すさらに強力な証拠を収集して報告できます。SOX 404 は、財務統制を対象としていますが、COBIT、COSO、ISO など他の規制フレームワークでは、品質や業界標準への準拠など、より一般的な目標を掲げています。Visual Studio Team System 2008 は、この記事の後半で説明するものと同様のカスタマイズを行うことで、このような他のフレームワークに使用する証拠の収集と報告も支援できます。

また、Visual Studio Team System 2008 は、ソフトウェア開発プロセスについての情報収集と、開発プロセスの累積記録の作成にも役立つことがありますが、このような累積記録に対するアクセス権管理機能は組み込まれていません。また、企業では、SOX 404 の専門家と相談したうえで、Visual Studio Team System 2008 で管理および生成される記録の信頼性の向上を図ることができます。たとえば、手続きの統制 (正式な承認や記録など) や、プロジェクト管理者やチームメンバに対する教育 (データを変更または削除する特定のツールを使用することの重要性や、これが法令遵守の取り組み全体に対してどのような影響があるかを啓蒙する) などを組み込みます。

シナリオの紹介

この記事では、Visual Studio Team System 2008 を使用していくつかの統制例をサポートする方法を示す一連の簡単なシナリオを紹介します。この記事では、Visual Studio Team System 2008 の CMMI テンプレートと、一般的な作業項目について、ある程度の理解があることを前提としています。ここでは、ある企業が SOX 404 に詳しい鑑定人と協力して、事業の包括的なリスク分析を行うことを想定しています。

一般的に、このような評価では、結果として作成された登録簿には全社で収集された 50 ～ 300 件のリスクが含まれます。これらのリスクに対して統制を実装する必要があります。下記の一覧には、この企業の IT 部門におけるソフトウェアアプリケーション開発に関連する 6 件のリスクが含まれています。これらのリスクが発生し得るシナリオは次のとおりです。

表 1. SOX 法 404 条 : アプリケーション開発のリスクシナリオ

1.	プロジェクト進行中に発生する重大なリスクが、認識または軽減されない。
2.	未承認の変更がプロジェクトに組み込まれる。
3.	顧客からの変更要求のステータスが追跡されない。
4.	顧客の要件を理解または定義できていないものがある。
5.	顧客または事業主にシステムの変更費用が請求されない。
6.	既にリリースしているシステムに変更が組み込まれない。

以下のセクションでは、上記の IT 関連のリスクシナリオの詳細を確認し、Visual Studio Team System 2008 も含め、その実装について説明します。ただし、これらのシナリオを発展させて、その他の Visual Studio Team System 2008 機能 (ソースコードの分岐によるリリースの管理など) を説明することは、この記事の範囲外となるため行いません。

シナリオ 1: 重大なプロジェクトリスクの効果的な管理

このシナリオでは、組織のソフトウェアプロジェクトに対するリスク管理の適正性に関する特定の領域を検証します。ソフトウェア開発プロジェクトのリスク管理が適切に実施されていない場合、確認されなかった重大なリスクは、企業で追加の費用が発生する原因となり、外部の関係者に直接的な財務上の影響を及ぼす可能性があります。

項目	詳細
特定されたリスク	重大なプロジェクトリスクが、プロジェクトのライフサイクルで発生した場合に、認識されず軽減されない。
領域	リスク管理。
統制目標	プロジェクトのライフサイクルで発生したすべての重大なプロジェクトリスクが認識および軽減されるようにする。
統制活動	プロジェクトのライフサイクルを通じて Visual Studio Team System 2008 内でリスク登録簿を管理する。プロジェクトマネージャは、リスクが Visual Studio Team System 2008 に登録され、エスカレートされたリスクがプロジェクトリスク担当チームによってレビューされるようにします。
"証拠"	リスクの記録、エスカレーションレポートとリスク追跡レコード、プロジェクトリスク担当チームの議事録。

Visual Studio Team System 2008 を使用した実装

このシナリオは、重大なリスクの管理プロセスを定義し、CMMI リスク作業項目に追加のフィールドをいくつか追加することで、Visual Studio Team System 2008 に実装できます (詳細については、このセクションの「使用されるフィールド」を参照してください)。ここでは、深刻度が "致命的" または "高" に設定されているリスク作業項目を "重大" であるとします (深刻度は既存のフィールドです)。

必要なプロセスの概要

Visual Studio Team System 2008 の標準の CMMI テンプレートには、リスク作業項目が含まれています。このセクションの後半で説明するフィールドを追加することで、CMMI テンプレートを使用して、法令遵守目的で "重大なリスク登録簿" という概念をサポートできます。

簡単にクローズできない重大なリスクがプロジェクト内で発生した場合、このリスクは "エスカレート済み" (Escalated) に設定され、履歴フィールドにコメントが追加されます。これにより、リスクがプロジェクトリスクのレビューチーム (またはそれに相当する機関) によりレビューされるようにすることができます。このチームは、重大なリスクを 1 つ 1 つレビューして発生し得る影響を評価し、リスクの軽減計画とコンティンジェンシー計画を管理する正式に決定されたグループです。このレビューミーティング中に控えられたメモは、各作業項目の (既存の) 履歴フィールドに記録されます。

イテレーションパス (既存のフィールド) を使用して、どのイテレーションでリスクが解決されるかを推論できますが、新しい目標期日 (Target Date) フィールドを使用すると、このリスクが重大でない状態に軽減されると予測される期日をより明示的に宣言できます。目標期日 (Target Date) フィールドは、担当のリスク所有者 (Accountable Risk Owner、新しいフィールド) によって設定されます。

(既存の) 終了者フィールドと終了日フィールドは、担当のリスク所有者 (Accountable Risk Owner) が設定する必要があります。リスクの終了は、"解決者" や "解決日" と同じであるとは見なされません。解決は、最終的な承認を受けてリスクが終了する前の状態です。リスクの終了は、定期的に行っている重大なリスクのレビューミーティング中に、プロジェクトリスク担当チームによって承認された状態です。作業項目の状態ワークフローを変更して、(新しい担当のリスク所有者セキュリティグループのメンバである) 担当のリスク所有者 (Accountable Risk Owner) のみが状態を解決から終了に変更できるようにすることもできます (リスク所有者は技術スタッフとは限らないので、Visual Studio Team System 2008 へのアクセスには、Web アクセスクライアントが適している場合があります)。

企業は、プロジェクトリスクに関する規定ドキュメントを作成できます。これは、重大なリスクのリスク管理方法を規定するドキュメントです。これには、プロジェクトリスク担当チームのメンバの一覧が含まれます。この一覧は、Accountable Risk Owners セキュリティグループのメンバの一覧と同じものになります。プロジェクトリスク担当チームのメンバシップの変更は、このドキュメントに反映され、セキュリティグループも変更当日に更新されます。プロジェクトリスクに関する規定ドキュメントには、プロジェクトリスク担当チームのミーティングの予定も記載されます。また、プロジェクトリスクに関する規定ドキュメントでは、CMMI テンプレートのリスクの深刻度 (Risk Severity) フィールドの値が "高" または "致命的" であるものが "重大" なリスクであることが規定されています。プロジェクトリスクに関する規定ドキュメントには、Visual Studio Team System 2008 サーバーがある場所や、リスク担当チームの監視対象となった Visual Studio Team System 2008 のプロジェクト名などの詳細情報も含まれます。

プロジェクトリスク担当チームのミーティングのメモや議事録は、どの規制フレームワークでも有用なコンポーネントになります。このような議事録をリスク作業項目に添付するか (既存の添付ファイルフィールドを使用)、リソースポインタ (URL またはファイル参照) を履歴フィールドに入力します (Microsoft Office SharePoint Server (MOSS) 内のドキュメントへのポインタなど)。議事録には、リスク作業項目の軽減計画やコンティンジェンシー計画がレビューまたは更新されたかどうかや、リスクが積極的に管理されている別の方法などが記録される場合があります。

企業では、Team System を使用して、次のようなクエリを行うことで、管理対象の重大なプロジェクトリスクを体系的かつ適切な方法で追跡できます。

深刻度が "高" と "致命的" に設定されているリスクの一覧を作成します。
各リスクの状態フィールドを確認して、アクティブなリスク、解決したリスク、および終了したリスクがすべて確認されるようにします。
リンクフィールドを使用して、この一覧にある各リスクを対応するタスク作業項目にリンクして、各リスクに対応するためにいずれ実施されるプロジェクト活動を示します。Office Excel にクエリを実装して、親リスクから派生しているリンクされたタスクを表示することもできます。
各リスク作業項目の履歴フィールドを確認して、これまでのリスクに対する実際の変更を洗い出します。リスクのライフサイクル中に、実際に活動が行われていることを確認します。たとえば、リスクが "エスカレート済み" (Escalated) に設定された時点で、履歴にどのような理由が記録されているかを確認します。
リスクの解決日と終了日を比較して、この両日間に、プロジェクトリスク担当チームのミーティングが開催されている (つまり、解決と終了が同じ日ではない) ことを確認します。
終了日と目標期日を比較して、リスク管理のタイミングの有効性を検証します。
終了者フィールドと正式に明文化されている Accountable Risk Owners セキュリティグループとを比較します。

上記の一覧は完全なものではなく、Visual Studio Team System 2008 を使用して実現できる作業の一例です。これを、ソフトウェアアプリケーション開発プロジェクト用の正式なプロジェクトリスク登録簿を実装するための基盤として使用することもできます。

このシナリオから、企業の規制フレームワークの目標をサポートするには、人的な活動とツールによる支援を組み合わせることが必要なことがおわかりいただけると思います。Visual Studio Team System 2008 を使用するメリットは、プロジェクトの日々の実作業に、ツールが沿っていることです。したがって、収集される情報は、実際の出来事を反映したものになる可能性が高く、このように忠実にチームソフトウェア開発の状態が反映されるため、チームプロセス (リスク管理など) の有効性が向上する傾向があります。

使用されるフィールド

リスク作業項目の既存のフィールドのほかに、CMMI テンプレートをカスタマイズして、以下のフィールドを追加できます。

新しいフィールド	説明
担当のリスク所有者 (Accountable Risk Owner)	リスクのライフサイクルと、その最終結果に責任を持つ人物の名前を指定するフィールドです。この名前は、新しい Accountable Risk Owners セキュリティグループのメンバにする必要があります。
エスカレート済み (Escalated)	リスクがプロジェクトリスク担当チームのレビュー対象としてエスカレートされているかどうかを示すフラグフィールドです。このフィールドで "エスカレート済み" (Escalated) と設定されているリスクはすべて、プロジェクトリスク担当チームの定期ミーティングでレビューが行われます。
目標期日 (Target Date)	リスクが終了されるべき目標の期日を指定するフィールドです。

例

このセクションでは、Visual Studio Team System 2008 クライアントのビュー画面をいくつか示し、前述のリスク方法を実装する手順を示します。CMMI テンプレートで、リスク作業項目をカスタマイズすると、これらのビューを表示できるようになります。

図 3 は、プロジェクトのリスクを検証するために実行されるクエリを示しています。リスク作業項目に追加した 3 つの追加のフィールド (担当のリスク所有者/Accountable Risk Owner、エスカレート済み/Escalated、目標期日/Target Date) は、黄色で強調表示されています。

図 3. プロジェクトのリスクを検証するクエリ

図 3. プロジェクトのリスクを検証するクエリ

このクエリによって、深刻度が "致命的" または "高" に該当する 8 つのリスクを含む一覧が生成されます。一覧の最初の項目が強調表示され、一覧の下には作業項目フォームが表示されます。各リスクには、完了までそのリスクを監視する正式な責任者である担当のリスク所有者 (Accountable Risk Owner) と、前のセクションで説明した解決の目標期日 (「必要なプロセスの概要」参照) が指定されています。

このクエリでは、表示するレコードを制限するフィルタを適用して、関連フィールドの任意のセットを取得できます。クエリは、Visual Studio チームエクスプローラに簡単に組み込むことができるので、監査を行うためのクエリをすばやく作成できます。

図 4 は、SOX 404 Escalated Risks を表示する場合のクエリの定義です。

図 4. SOX 404 Escalated Risks を表示するクエリの定義

図 4. SOX 404 Escalated Risks を表示するクエリの定義

この画像は、前述のリスクを選択する条件を示しています。この場合、ユーザーが、深刻度が "致命的" または"高" で、状態が "アクティブ"、"解決"、または "終了" であるリスク作業項目のみを表示するように選択しています。また、プロジェクトリスク担当チームにエスカレート済み (Escalated) であるリスクのみを表示するために、この条件もクエリ定義に含まれています。

結果一覧に表示されるフィールドは、クエリ定義自体とは別に構成することもできます。このようにすると、並べ替えの際に使用する追加のデータを表示できます。

図 5 は、クエリの結果セットに表示するフィールドを選択するダイアログボックスです。

図 5. クエリの結果セットに表示するフィールドを選択する [列のオプション] ダイアログボックス

図 5. クエリの結果セットに表示するフィールドを選択する [列のオプション] ダイアログボックス

シナリオ 2: プロジェクトに対する未承認の変更の防止

このシナリオでは、開発中のソフトウェアを変更するプロセスに関連付けられている厳密度について説明します。変更が厳しく管理されないと、契約上の機能と、提供される機能に差異が生じる可能性があります。変更を明らかにできない場合、重大な影響がある可能性があります。たとえば、プロジェクトのスケジュール、セキュリティ、既存の機能に影響を与えることがあります。

項目	詳細
特定されたリスク	未承認の変更がプロジェクトに組み込まれる。
領域	変更管理。
統制目標	プロジェクトの変更要求すべてが、正式な手続きにより承認され、プロジェクトの障害とならないようにする。
統制活動	変更要求を、プロジェクト変更担当チームの取り決め事項 (ドキュメント) に従って承認する。すべての変更要求に対して、影響とリスクの評価を実施する。変更担当チームは、変更に関するレビューと承認プロセスの一環として、適切な影響とリスク分析が完了しているように管理する。各変更要求ドキュメントに関連情報を記録する。
"証拠"	承認された変更要求と、変更要求のレビュー内容を記載したプロジェクト変更担当チームの議事録のコピー。