定義:リスク識別とは、プログラム、企業、または投資がその目的を達成するのを妨げる可能性のあるリスクを決定するプロセスです。 これには、懸念を文書化し、伝達することが含まれます。
キーワード:リスク、リスク識別、リスク管理
MITRE SEの役割&期待:政府プログラムに取り組んでいるMITREシステムエンジニア(SEs)は、プロジェクトとプログラムに影響を与える可能性のあるリスクを特定することが期待されています。 彼らは、明確で明確で、証拠によって支持されているリスク声明を書いてレビューすることが期待されています。
背景
リスク識別は、図1に示すリスク管理プロセスの重要な最初のステップです。
リスク識別の目的は、発生した場合に、プロジェクトのパフォーマンスまたは能力の成果目標を達成する能力に負の影響を及ぼす事象を早期かつ継続的に識別することである。 これらは、プロジェクト内または外部ソースから来る可能性があります。
リスク評価には、プログラムリスク評価、投資判断を支援するためのリスク評価、代替案の分析、運用またはコストの不確実性の評価など、複数のタイプ リスク識別は、リスク情報に基づいた意思決定を支援するために必要な評価の種類と一致する必要があります。 獲得プログラムの場合、最初のステップは、プログラムの目標と目的を特定し、プログラムの成功に必要なものについてチーム全体で共通の理解を育 これにより、リスクが特定され評価される範囲が文脈と範囲に与えられます。
システムエンジニアリングプログラムにおけるリスクの特定
リスクには複数の原因があります。 リスクを特定するには、プロジェクトチームは、プログラムの範囲、コスト見積もり、スケジュール(クリティカルパスの評価を含む)、技術的成熟度、主要なパフォーマンスパラメータ、パフォーマンスの課題、ステークホルダーの期待と現在の計画、外部および内部の依存関係、実装の課題、統合、相互運用性、サポート可能性、サプライチェーンの脆弱性、脅威を処理する能力、コスト偏差、テストイベントの期待、安全性、セキュリティなどを確認する必要があります。 さらに、同様のプロジェクト、利害関係者のインタビュー、およびリスクリストからの履歴データは、リスクを考慮するための領域に貴重な洞察を提供
リスクの特定は反復的なプロセスです。 プログラムが進行するにつれて、プログラムに関するより多くの情報（例えば、特定の設計）が得られ、リスクステートメントは現在の理解を反映するよう プロジェクトがライフサイクルを経て進行するにつれて、新たなリスクが特定されます。
ベストプラクティスと教訓
オペレーショナルリスク。 サポートしている機能の運用上の性質、およびエンドユーザーへのリスク、その任務、および機能の運用を理解します。 運用上の必要性/使命を理解すること（システムエンジニアリングガイドのコンセプト開発トピックを参照）は、リスクの重大さと、それらがエンドユー これは、リスク分析の重要な部分であり、運用中にリスクが発生した場合に発生する可能性のある現実世界の影響を実現します。 通常、運用ユーザーは、ミッションを達成できる場合（ミッション保証など）、ある程度のリスクを受け入れますが、ユーザーが受け入れているリスクを理解し、利用可能なオプション、残高、および代替案を評価するのを支援する必要があります。
技術的成熟度。 努力のために考慮されている技術と時間の経過とともに技術の可能性の高い移行を理解するために、産業界と学界と協力し、活用してください。 一つのアプローチは、リスクを評価することができるように、彼らが行っている機能と場所を理解するために、秘密保持契約の下でベンダーと協力するこ
非開発項目（NDI）。 NDIには、市販品と政府品が含まれています。 リスクを管理するには、NDIプロバイダーの実行可能性を考慮します。 プロバイダーは市場シェアを持っていますか？ プロバイダは、競合他社と比較して適切な寿命を持っていますか？ プロバイダは、機能の問題やリリースの修正などにどのように対処しますか。? 特定のNDIのユーザーベースは何ですか？ プロバイダは、好ましくはあなたの顧客のそれと同様の設定で、NDIを実証することができますか？ 政府はndiを使ってプロトタイプを作成することはできますか？ これらの要因のすべては、NDIとプロバイダの生存率のリスクを評価するのに役立ちます。 地域を働いているか、評価されているNDIを使用している他のマイタースタッフからこれらの質問への回答を求めます。
重要な機能イネーブラー、特に選択肢が限られているものを強調します。 買収の主な要因を評価し、決定し、リスク軽減の推奨事項を策定する際に関連するリスクを強調する。 能力の特定の側面がその成功にとって重要でない場合、そのリスクを評価する必要がありますが、リスク管理の主な焦点である必要はありません。 たとえば、提案されたユーザーインターフェイスにリスクがあるが、市場に多数の選択肢がある場合、提案されたアプローチの成功は、おそらく機能の全体的な成功にはあまり重要ではありません。 一方、情報セキュリティ機能は重要である可能性があります。 一つだけの代替アプローチが必要性を満たす場合は、それに重点を置く必要があります。 ニーズと設計を評価し、存在する代替案を決定することによって、主要な成功の要因を決定します。 成功へのクリティカルパス上のユニークな解決策はありますか？ クリティカルパス分析には、開発だけでなく、システムエンジニアリングサイクル全体が含まれていることを確認してください（つまり、システム開発自体は”ケーキ”かもしれませんが、アクティブな運用状況でのフィールディングは大きなリスクになる可能性があります）。
リスクを管理するために能力の進化を使用します。 特定の要件が、独自の開発、エッジ-オブ-ザ-エンベロープのパフォーマンスニーズなどのためにリスクの高い機能の実装を推進している場合。、条件は重要性のためのユーザーと論議されるべきです。 必要性が延期される可能性があり、開発コミュニティは将来的に満足する可能性があるときに評価する必要があります。 ユーザーと開発者は、リスクの低い機能をより早く受け取るために、特定の機能が要件に対してどのくらいのリスク（およびスケジュールとコストへの影響） あなたの勧告を開発する際には、技術的な実現可能性と関連する実装の成功と失敗の知識を考慮して、将来ではなく現在実装のリスクを評価します。 能力を延期する際には、全体的な成功に不可欠な複数のリスクの高い要件の将来のために、短期的な簡単な成功を取引することによって、究極の失敗
主要なパフォーマンスパラメータ(KPPs)。 KPPsを確立するためにユーザーと密接に協力してください。 プログラムのキャンセルの全体的なリスクは、KPPsを満たすために失敗に集中することができます。 変数が代表団の必要性に敏感技術的に実行可能であることを保障するユーザーと働き。 パラメータは、容易に満たすことができるほど寛大であってはならないが、ミッションの必要性を満たすことはできない。 パフォーマンスの実現可能性を判断するために、過去の操作、実験、パフォーマンス評価、および業界の実装の結果を求めます。
外部および内部の依存関係。 企業の視点を持つことは、買収者、プログラムマネージャー、開発者、インテグレータ、およびユーザーが開発努力の依存関係からのリスクを評価するのに役立 サービス指向アプローチの出現により、プログラムは、プログラムの開発努力で使用しようとする他の人が提供するサービスの可用性と運用に依存するよ 質の高いサービスが作成されていることを確認するために、サービスの開発者と協力し、思考は、それらのサービスの保守と進化に入れられています。 開発プログラムのスタッフと協力して、利用可能なサービス、その品質、およびプログラムがサービスを使用して依存する際に持つリスクを評価します。 同様に、サービスを作成し、別の企業の努力からサービスを使用しないことに関連するリスクがあります。 将来的にエンタープライズサービスに移行する可能性がある開発の内部サービスを作成することのリスクと潜在的な利点を判断するのに役立ちます。
統合と相互運用性(I&I)。 I&私はほとんど常に主要な危険因子になります。 これらは、統合または相互運用の価値が固有のリスクを上書きすると判断された依存関係の形態です。 エンタープライズフェデレーションアーキテクティング、オンデマンドで構成可能な機能、設計パターンなどの技術は、政府がi&iリスクをナビゲートするルートを計画し、実行するのに役立ちます。 I&i関連リスクに対処するための技術に関する記事については、”システムエンジニアリングガイド”のエンタープライズエンジニアリングセク
情報セキュリティ。 情報セキュリティは、ほぼすべての開発におけるリスクです。 これのいくつかは、この分野における政府のニーズと要件の独自性によるものです。 これのいくつかは、サイバー攻撃に対抗する際の固有の困難のためです。 攻撃の範囲をカバーするための防御機能を作成することは困難で危険です。 政府が弾力性のアプローチを開発するのを助けて下さい（例えば、緊急時対応計画、バックアップ/回復、等。). 国際的なパートナーとの連合業務におけるシステム間の情報共有を可能にすることは、開発リスクにつながる技術的課題と政策問題を提示する。 サプライチェーンマネジメントに関連する情報セキュリティの問題は非常に広範かつ複雑であるため、脅威に対する初歩的な認識を維持することでさえ大きな課題となっています。
スキルレベル。 開発者、インテグレータ、政府、およびその他の利害関係者のスキルや経験レベルは、リスクにつながる可能性があります。 不十分なスキルに目を光らせて、任意のギャップを埋めるために、企業全体に到達します。 そうすることで、あなたが耐えるために団体の技術および経験を持って来ている同時に政府のチーム・メンバーを教育するのを助けて下さい。
コストリスク。 プログラムは、通常、リスクを考慮した政府のコスト見積もりを作成します。 プログラムの技術的リスクやその他のリスクを開発して改善するにつれて、関連するコスト見積もりも進化するはずです。 コストの見積もりは、一度限りの活動ではありません。
リスク識別のためのガイドとしての履歴情報。 同様の政府プログラムからの履歴情報は、将来のリスクについての貴重な洞察を提供することができます。 アクションレポート、演習の概要、および実験結果の後に、学んだ様々な操作の教訓で運用上の課題とリスクに関する情報を探し出します。 顧客は、多くの場合、アクセスするためにこれらのリポジトリを持っています。 政府の指導者は、通常、彼らの戦略的なニーズや課題を通信します。 これらを理解し、顧客が必要とする最も重要な機能の評価に、そしてリスク評価の基礎として考慮します。
リスクの評価に役立つ履歴データは、過去の業績評価や買収プログラムや請負業者の教訓から頻繁に入手できます。 多くの場合、MITREのスタッフは、特定の買収のためのパフォーマンス情報を準備する際に政府を支援します。 AFには、将来の政府機関の情報源の選択に使用できるキャプチャする情報のタイプを識別する過去のパフォーマンス評価ガイド（PPEG）があります。 情報のこのリポジトリは、以前の課題の背景情報を提供するのに役立ち、それらが再び発生する可能性があります開発活動の特定のタイプだけでなく、特定の請負業者との両方のために。
ベンダー製品には、さまざまな製品のリスクと実行可能性を判断するためにアクセスできる多数の技術的評価があります。 ツールの評価の一つのマイターリポジトリは、分析ツールに関するガイダンスと経験が含まれている分析ツールシェッドです。 このようなリソースを使用し、プロトタイプや実験で製品や技術を試したことのある人を探すことは、特定の努力のリスクを評価するのに役立ちます。
リスクを書く方法-ベストプラクティス。 リスクステートメントを記述するためのベストプラクティスプロトコルは、Condition-If-Then構造です。 このプロトコルは、ほぼすべての環境向けに設計されたリスク管理プロセスに適用されます。 リスクは、その性質上、確率的であり、それが発生した場合、望ましくない結果をもたらすものであるという認識です。
Condition-If-Then構造とは何ですか？ この状態は今日知られているものを反映しています。 これは、特定されたリスクイベントの根本的な原因です。 したがって、条件は、発生した、現在発生している、または確実に発生するであろうイベントである。 リスクイベントは、現在の状態のために発生する可能性のある将来のイベントです。 以下は、このプロトコルの例です。
Ifは、存在する状態に関連するリスクイベントです。 Ifと条件を双対として認識することは非常に重要です。 共同で検討すると、リスクイベントの根本的なルート（条件）に直接介入または改善する方法があり、このイベントからの結果が発生した場合、プロジェクトを脅かしなくなる可能性があります。 Ifは、リスクステートメントの確率的部分です。
Thenは、リスクイベントが発生した場合にエンジニアリング-システム-プロジェクトに影響を与える結果、または結果のセットです。 Condition-If-Then構造の例を図2に示します。
チームにリスクを特定するよう奨励する。 いくつかの政府のプロジェクトやプログラムの文化は、リスクの特定を落胆させます。 これは、リスクの追跡、監視、および軽減のリスク管理活動が負担と役に立たないと見なされるために発生する可能性があります。 このような状況では、リスクを特定することの利点と、それをすべて頭の中で管理できないことについてチームに話すことは有益です（例：、優先順位を決定し、誰が関与する必要があるか、緩和行動）。 プロジェクトの結果に価値の管理投資のバランスをとるプロセスの実行の政府のチームを助けなさい。 一般的に、プロジェクトの範囲、スケジュール、およびコスト目標がアクションプランによって満たされているか、正常に軽減されているときに良いバラン リスクは、個人によって、または厳密にシステムエンジニアリングチームによって識別されるべきではありません（上記のリスクの原因を確認してくださ
組織的要因と環境要因を考慮する。 利害関係者のサポートや組織の優先順位などの組織的、文化的、政治的、およびその他の環境要因は、技術的要因だけではなく、プロジェクトに多くのリスク これらのリスクは、プロジェクトの生涯を通じて特定され、積極的に軽減されるべきです。 緩和活動には、プログラムやプロジェクトの使命に影響を与える可能性のある立法上の義務や緊急の変更、ユーザーの要件や能力の有用性に影響を与 いずれの場合も、プログラムへのリスクを考慮し、利害関係者との議論のための行動オプションを特定します。 詳細については、”リスク軽減の計画、実装、および進行状況の監視”の記事を参照してください。
リスク識別に利害関係者を含める。 プロジェクトおよびプログラムに通常結果に危険のさまざまな次元を持って来る多数の係争物受寄者がある。 彼らには、新しいシステムに圧倒される可能性のあるオペレータ、適切に訓練されていないか、仕事に不安を抱いているユーザー、権限を低下させるように見えるために新しい機能をサポートしない可能性のある監督者、立法の承認とコストに懸念を持つ政策立案者が含まれます。 さらに、誤って見落とされた場合、プログラムの後半で大きなリスクをもたらす可能性のある認証機関や認定機関など、すべての利害関係者を含めるこ 利害関係者は、政府やMITREプロジェクトチームには知られていないプロジェクトにリスクをもたらす可能性のある保留中の法律や政治的プログラム これらのリスクを表面化するために、リスク識別プロセスに利害関係者を含めます。
明確なリスクステートメントを記述します。 Condition-If-Then形式を使用すると、リスクステートメントを伝達して評価し、緩和戦略を策定するのに役立ちます。 根本的な原因は、リスクを導入した基礎となる状態(例えば、設計アプローチが原因である可能性がある)、Ifは確率を反映している(例えば、リスクステートメントのIf部分が発生する確率評価)、そしてその影響をプログラムに伝えている(例えば、テストをサポートするためのリソースの増加、追加のスケジュール、パフォーマンスを満たすための懸念など)。 緩和戦略は、明確に明確なリスク声明に基づいている場合、ほとんどの場合より優れています。
リスク評価と緩和戦略が策定されるにつれて、リスク声明の変更を期待する。 チームが影響を評価すると、リスクステートメントが洗練されるのが一般的です。 潜在的なリスクへの影響（コスト、スケジュール、技術的、または時間枠）を評価し、文書化するとき、リスクの理解と声明が変わる可能性があります。 たとえば、ソフトウェアスケジュールスリップのリスクへの影響を評価する場合、リスクステートメントは、日付ごとの必要性、および/または影響のさらなる明確化を含むように洗練される可能性があります例えば、xyzソフトウェアが2015年までに配信されない場合、限られたユーザーテストの前にインターフェイス交換をテストするのに十分な時間がありません。
リスク声明に緩和声明を含めないでください。 リスク声明に緩和声明を導入するという罠に陥らないように注意してください。 リスクは、潜在的な負の影響を持つ不確実性です。 リスクの軽減の結論にすばやくジャンプし、軽減すべきリスクを特定するのではなく（軽減オプションを特定して）、リスクを最適ではない設計アプロー 請負業者がテストにXYZを使用しない場合、テストは失敗します。 心配は実際にテスト充足である。 請負業者が分析のために測定可能な結果を得てテストを実施しない場合、プログラムは限られたユーザーテストに合格しない可能性があります。 XYZの使用は、テストの充足リスクを軽減するための緩和オプションである可能性があります。
リスクの確率と影響を評価する前に緩和戦略にジャンプしないでください。 リスクは、最も効率的/所望の緩和が何であるかに影響を与える可能性があり、さらなる分析を与えられた精製または変更することができます。 最初に問題を分解して理解するには、”リスク影響評価と優先順位付け”の記事で説明されている次のステップに移動することをお勧めします。 最終的には、これは懸念と密接に連携した戦略につながります。
参考文献&リソース
- THE MITRE Institute,September1,2007,MITRE Systems Engineering(SE)Competency Model,Version1,pp.10,40-41.
- Garvey,P.R.,2008,Analytical Methods for Risk Management:A Systems Engineering Perspective,Chapman-Hall/CRC-Press,Taylor&Francis Group(UK),Boca Raton,London,New York,ISBN:1584886374.米国空軍、2008年1月、空軍過去の性能評価ガイド（PPEG）、IG5315.305（a）。
- 米空軍,January2008,空軍過去の性能評価ガイド(PPEG),IG5315.305(a).
その他の参考文献&リソース
MITRE E520リスク分析および管理技術チームのチェックリスト、リスクチェック、リスク分析および管理文書。
Project Management Institute,A Guide to The Project Management Body of Knowledge,(PMBOK Guide),Fourth Edition,ANSI/PMI99-001-2008,pp.273-312,accessed March2,2010.
SEPO,”標準プロセス/プロセスのステップ,ステップ2:リスクの特定&ハザード,”MITRE SEPO Risk Management Toolkit,accessed May5,2010.
