この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
序文
ISO (国際標準化機構) は、国家標準化団体 (ISO メンバー団体) の世界的な連合体です。国際規格の作成作業は通常、ISO 技術委員会を通じて行われます。技術委員会が設立された主題に関心のある各会員団体は、その委員会に代表される権利を有します。政府および非政府の国際機関も ISO と連携してこの作業に参加しています。 ISO は、電気技術の標準化に関するあらゆる事項について国際電気標準会議 (IEC) と緊密に協力しています。
この文書の作成に使用される手順と、そのさらなる保守を目的とした手順は、ISO/IEC 指令Part に記載されています。特に、さまざまなタイプの ISO 文書に必要なさまざまな承認基準に注意する必要があります。この文書は、ISO/IEC 指令Part の編集規則に従って起草されました ( www.iso.org/directives を参照)
この文書の要素の一部が特許権の対象となる可能性があることに注意してください。 ISO は、そのような特許権の一部またはすべてを特定する責任を負わないものとします。文書の作成中に特定された特許権の詳細は、序論および/または受け取った特許宣言の ISO リストに記載されます ( www.iso.org/patents を参照)
本書で使用されている商号は、ユーザーの便宜のために提供された情報であり、推奨を構成するものではありません。
適合性評価に関連する ISO 固有の用語や表現の意味の説明、および貿易の技術的障壁 (TBT) における世界貿易機関 (WTO) 原則への ISO の準拠に関する情報については、次の URL を参照してください。 www.iso .org/iso/foreword.html
この文書を担当する委員会は、ISO/TC 20, 航空機および宇宙船、SC 14 分科会、宇宙システムおよび運用です。
この第 2 版は、第 1 版 (ISO 17666:2003) を廃止し、置き換えるものであり、そのマイナーリビジョンを構成します。この版では付録 B が追加されており、リスク管理計画を作成する際に考慮するための DRD が含まれています。
導入
リスクはプロジェクトのコスト、スケジュール、技術的パフォーマンスに悪影響を与えるため、プロジェクトの成功に対する脅威ですが、リスクを適切に管理すれば、プラスの影響をもたらす新たな機会をもたらすこともあります。
プロジェクト リスク管理の目的は、プロジェクトの技術的およびプログラム上の制約を考慮し、体系的、事前対応的、包括的かつ費用対効果の高い方法で、宇宙プロジェクトのリスクを特定、評価、軽減、受け入れ、制御することです。リスクは、管理、プログラム（コスト、スケジュールなど）、技術（質量、電力、信頼性、安全性など）の領域内で、従来の既知のプロジェクト リソースに対してトレード可能であると考えられます。プロジェクトにおける全体的なリスク管理は、プロジェクトのライフサイクル全体を通じて反復的なプロセスであり、反復はプロジェクトのさまざまなフェーズを通じたプロジェクトの進捗状況、およびプロジェクト リソースに影響を与える特定のプロジェクト ベースラインの変更によって決まります。
リスク管理は、顧客とサプライヤーのネットワークの各レベルで実装されます。
システムおよびエンジニアリングの分析、安全性、重要項目、信頼性、クリティカル パス、コストの分析など、プロジェクト リスクに対処するための既知のプロジェクト プラクティスは、プロジェクト リスク管理の不可欠な部分です。プロジェクトの成功に対する重要度に応じてリスクをランク付けし、経営陣の注意を本質的な問題に向けることができるようにすることが、リスク管理の主要な目的です。
プロジェクトの関係者は、プロジェクトの定義と特性に応じて、特定のプロジェクトに実装されるリスク管理の範囲について合意します。
1 スコープ
この文書は、ISO 14300-1 の要件を拡張して、宇宙プロジェクトにおける統合リスク管理の原則と要件を定義します。これは、あらゆるレベル (つまり、顧客、第一レベルのサプライヤー、または下位レベルのサプライヤー) のあらゆるプロジェクト関係者がプロジェクトに統合されたリスク管理ポリシーを実装するために何が必要かを説明します。
この文書には、一般的なリスク管理プロセスの概要が含まれており、4 つの基本ステップと 9 つのタスクに細分されています。実装はプロジェクト固有の条件に合わせて調整できます。
リスク管理プロセスでは、すべてのプロジェクト ドメイン間での情報交換が必要であり、プロジェクトに対するリスクの重要度に応じたランク付けによるリスクの可視性が提供されます。これらのリスクは、それらが属するドメインに定義されたルールに従って監視および制御されます。
この文書の適用分野は宇宙プロジェクトのすべてのフェーズです。プロジェクトのフェーズの定義は ISO 14300-1 に記載されています。
特定のプログラムまたはプロジェクトのコンテキストの観点から見ると、この文書で定義されている要件は、プログラムまたはプロジェクトの特定のプロファイルおよび状況の真の要件に一致するように調整されています。
注調整とは、個々の要件または仕様、規格、および関連文書を評価し、選択によって特定のプログラムまたはプロジェクトに適用できるようにするプロセスであり、場合によっては、規格内の要件の変更や追加も行われます。
2 規範的参照
この文書には規範的な参照はありません。
3 用語、定義、および略語
3.1 用語と定義
この文書の目的上、次の用語と定義が適用されます。
ISO と IEC は、標準化に使用する用語データベースを次のアドレスで維持しています。
3.1.1
リスクの受け入れ
リスクシナリオが現実化した場合の結果に対処するための決定
注記 1:リスクは、その規模がリスク管理ポリシーで定義された所定のしきい値よりも小さい場合に受け入れられます。
注記 2:リスク管理の文脈において、受容とは、リスクが排除されないとしても、その存在と大きさが認められ、許容されることを意味する場合があります。
3.1.2
リスクコミュニケーション
リスク管理に必要なすべての情報とデータは、意思決定者とプロジェクト階層内の関連する関係者に宛てられます。
3.1.3
リスク指数
リスクの発生の可能性、規模、重大度を測定するために使用される複合スコア
3.1.4
個人のリスク
プロジェクト内の個別のリスク項目として特定、評価、軽減されるリスク
3.1.5
危機管理
確立されたプロジェクト リスク管理ポリシーに従って実行される、プロジェクト リソースの体系的かつ反復的な最適化
3.1.6
リスク管理方針
リスクに対する組織の態度、リスク管理の実施方法、受け入れる準備ができているリスク、およびリスク管理計画の主な要件をどのように定義するか
3.1.7
リスク管理プロセス
リスクの特定、評価、軽減、受け入れ、フィードバックに関連するすべてのプロジェクト活動
3.1.8
全体的なリスク
プロジェクト全体の文脈における、個々のリスクとその相互への影響の組み合わせの評価から生じるリスク
注記 1:全体的なリスクは、定性的評価と定量的評価の組み合わせとして表すことができます。
3.1.9
リスク削減
リスクの可能性または重大度の軽減につながる対策の実施
注記 1:予防措置は、問題状況の原因を除去することを目的とし、緩和措置は、原因から結果への伝播を防止すること、あるいは結果の重大度や発生の可能性を軽減することを目的としています。
3.1.10
残留リスク
リスク低減策の実施後に残るリスク
3.1.11
解決されたリスク
許容できるようになったリスク
3.1.12
危険
発生する可能性があり、プロジェクトに潜在的にマイナスの結果をもたらす、望ましくない状況または環境
注記 1:リスクは、事象の予測可能性または制御の欠如による不確実性から生じます。リスクはどのプロジェクトにも内在しており、プロジェクトのライフサイクル中いつでも発生する可能性があります。これらの不確実性を軽減すると、リスクが軽減されます。
3.1.13
リスクシナリオ
最初の原因から望ましくない結果に至るまでの一連の出来事またはその組み合わせ
注記 1:原因は、単一のイベントであることもあれば、眠っている問題を活性化させる何かであることもあります。
3.1.14
リスク傾向
プロジェクトのライフサイクル全体にわたるリスクの進化
3.1.15
未解決のリスク
リスク削減の試みが実行不可能、検証できない、または失敗したことが証明されているリスク
注記 1:許容できないリスクとして定義することもできます。
参考文献
| 1 | ISO 14300-1, 宇宙システム — プログラム管理 — Part 1: プロジェクトの構築 |
| 2 | ISO 14620-1, 宇宙システム — 安全要件 — Part 1: システムの安全性 |
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives ).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents ).
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html .
The committee responsible for this document is ISO/TC 20, Aircraft and space vehicles, Subcommittee SC 14, Space systems andoperations.
This second edition cancels and replaces the first edition (ISO 17666:2003), of which it constitutes a minor revision. Annex B has been added in this edition and contains a DRD for consideration when preparing the risk management plan.
Introduction
Risks are a threat to the project success because they have negative effects on the project cost, schedule and technical performance, but appropriate practices of controlling risks can also present new opportunities with positive impact.
The objective of project risk management is to identify, assess, reduce, accept, and control space project risks in a systematic, proactive, comprehensive, and cost-effective manner, taking into account the project’s technical and programmatic constraints. Risk is considered tradable against the conventional known project resources within the management, programmatic (e.g. cost, schedule), and technical (e.g. mass, power, dependability, safety) domains. The overall risk management in a project is an iterative process throughout the project life cycle, with iterations being determined by the project progress through the different project phases, and by changes to a given project baseline influencing project resources.
Risk management is implemented at each level of the customer-supplier network.
Known project practices for dealing with project risks, such as system and engineering analyses, analyses of safety, critical items, dependability, critical path, and cost, are an integral part of project risk management. Ranking of risks according to their criticality for the project success, allowing management attention to be directed to the essential issues, is a major objective of risk management.
The project actors agree on the extent of the risk management to be implemented into a given project depending on the project definition and characterization.
1 Scope
This document defines, extending the requirements of ISO 14300-1, the principles and requirements for integrated risk management on a space project. It explains what is needed to implement a project-integrated risk management policy by any project actor, at any level (i.e. customer, first-level supplier, or lower-level suppliers).
This document contains a summary of the general risk management process, which is subdivided into four (4) basic steps and nine (9) tasks. The implementation can be tailored to project-specific conditions.
The risk management process requires information exchange among all project domains and provides visibility over risks, with a ranking according to their criticality for the project; these risks are monitored and controlled according to the rules defined for the domains to which they belong.
The fields of application of this document are all the space project phases. A definition of project phasing is given in ISO 14300-1.
When viewed from the perspective of a specific programme or project context, the requirements defined in this document are tailored to match the genuine requirements of a particular profile and circumstances of a programme or project.
NOTE Tailoring is a process by which individual requirements or specifications, standards, and related documents are evaluated and made applicable to a specific programme or project by selection, and in some exceptional cases, modification and addition of requirements in the standards.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
3.1.1
acceptance of risk
decision to cope with consequences, should a risk scenario materialise
Note 1 to entry: A risk can be accepted when its magnitude is less than a given threshold, defined in the risk management policy.
Note 2 to entry: In the context of risk management, acceptance can mean that even though a risk is not eliminated, its existence and magnitude are acknowledged and tolerated.
3.1.2
risk communication
all information and data necessary for risk management addressed to a decision maker and to relevant actors within the project hierarchy
3.1.3
risk index
combined score used to measure the likelihood of occurrence, magnitude, and severity of risk
3.1.4
individual risk
risk identified, assessed, and mitigated as a distinct risk items in a project
3.1.5
risk management
systematic and iterative optimisation of the project resources, performed according to the established project risk management policy
3.1.6
risk management policy
organisation’s attitude towards risks, how it conducts risk management, the risks it is prepared to accept and how it defines the main requirements for the risk management plan
3.1.7
risk management process
all project activities related to the identification, assessment, reduction, acceptance, and feedback of risks
3.1.8
overall risk
risk resulting from the assessment of the combination of individual risks and their impact on each other, in the context of the whole project
Note 1 to entry: Overall risk can be expressed as a combination of qualitative and quantitative assessment.
3.1.9
risk reduction
implementation of measures that leads to reduction of the likelihood or severity of risk
Note 1 to entry: Preventive measures aim at eliminating the cause of a problem situation, and mitigation measures aim at preventing the propagation of the cause to the consequence or reducing the severity of the consequence or the likelihood of the occurrence.
3.1.10
residual risk
risk remaining after implementation of risk reduction measures
3.1.11
resolved risk
risk that has been rendered acceptable
3.1.12
risk
undesirable situation or circumstance that has both a likelihood of occurring and a potentially negative consequence on a project
Note 1 to entry: Risks arise from uncertainty due to a lack of predictability or control of events. Risks are inherent to any project and can arise at any time during the project life cycle; reducing these uncertainties reduces the risk.
3.1.13
risk scenario
sequence or combination of events leading from the initial cause to the unwanted consequence
Note 1 to entry: The cause can be a single event or something activating a dormant problem.
3.1.14
risk trend
evolution of risks throughout the life cycle of a project
3.1.15
unresolved risk
risk for which risk reduction attempts are not feasible, cannot be verified, or have proven unsuccessful
Note 1 to entry: It can also be defined as a risk remaining unacceptable.
Bibliography
| 1 | ISO 14300-1, Space systems — Programme management — Part 1: Structuring of a project |
| 2 | ISO 14620-1, Space systems — Safety requirements — Part 1: System safety |