X 0170：2020 (ISO/IEC/IEEE 15288：2015)
（1）
目 次
ページ
序文 ··································································································································· 1
1 概要······························································································································· 2
1.1 適用範囲 ······················································································································ 2
1.2 目的 ···························································································································· 2
1.3 適用分野 ······················································································································ 3
1.4 制限 ···························································································································· 3
2 適合性···························································································································· 4
2.1 意図した用途 ················································································································ 4
2.2 完全適合（Full conformance） ·························································································· 4
2.3 修整適合（Tailored conformance） ···················································································· 5
3 引用規格························································································································· 5
4 用語，定義及び略語 ·········································································································· 5
4.1 用語及び定義 ················································································································ 5
4.2 略語 ··························································································································· 14
5 基本概念及び適用 ············································································································ 14
5.1 はじめに ····················································································································· 14
5.2 システム概念 ··············································································································· 14
5.3 組織及びプロジェクト概念 ····························································································· 16
5.4 ライフサイクルの概念 ··································································································· 17
5.5 プロセスの概念 ············································································································ 18
5.6 この規格のプロセス ······································································································ 19
5.7 プロセスの適用 ············································································································ 22
5.8 プロセス参照モデル ······································································································ 23
6 システムライフサイクルプロセス ······················································································· 23
6.1 合意プロセス（Agreement processes） ··············································································· 23
6.2 組織のプロジェクトイネーブリングプロセス（Organizational project-enabling processes） ·········· 28
6.3 テクニカルマネジメントプロセス（Technical management processes） ····································· 36
6.4 テクニカルプロセス（Technical processes） ········································································ 53
附属書A（規定）修整（tailoring）プロセス ············································································ 101
附属書B（参考）プロセス情報項目の例·················································································· 103
附属書C（参考）アセスメント目的のプロセス参照モデル ························································· 105
附属書D（参考）プロセスのインテグレーション及びプロセスの構成概念 ····································· 107
附属書E（参考）プロセスビュー ·························································································· 109
附属書F（参考）アーキテクチャのモデル化 ············································································ 115
附属書G（参考）システム オブ システムズへのシステムライフサイクルプロセス適用 ··················· 118
X 0170：2020 (ISO/IEC/IEEE 15288：2015) 目次
（2）
ページ
参考文献 ··························································································································· 122
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
（3）
まえがき
この規格は，産業標準化法第16条において準用する同法第12条第1項の規定に基づき，一般社団法人
情報処理学会（IPSJ）及び一般財団法人日本規格協会（JSA）から，産業標準原案を添えて日本産業規格
を改正すべきとの申出があり，日本産業標準調査会の審議を経て，経済産業大臣が改正した日本産業規格
である。これによって，JIS X 0170:2013は改正され，この規格に置き換えられた。
この規格は，著作権法で保護対象となっている著作物である。
この規格の一部が，特許権，出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意
を喚起する。経済産業大臣及び日本産業標準調査会は，このような特許権，出願公開後の特許出願及び実
用新案権に関わる確認について，責任はもたない。
日本産業規格 JIS
X 0170：2020
(ISO/IEC/IEEE 15288：2015)
システムライフサイクルプロセス
Systems and software engineering-System life cycle processes
序文
この規格は，2015年に第1版として発行されたISO/IEC/IEEE 15288を基に，技術的内容及び構成を変
更することなく作成した日本産業規格である。
なお，この規格で点線の下線を施してある参考事項は，対応国際規格にはない事項である。
注記 この対応国際規格はISO/IEC 15288としては第3版に相当するが，ISO/IEC/IEEE 15288として
の第1版として出版されている。
人が作り出すシステムの複雑さは，かつてないほどに増大している。このことは，新たな機会を生むが，
システムを作成し活用する組織の課題を増加させている。これらの課題は，システムのライフサイクルの
全期間及び構造の全てのレベルの細部に存在している。この規格は人が作成するシステムのライフサイク
ルを記述し，システムエンジニアリング手法を適用するための共通のプロセスの枠組みを提供する。シス
テムエンジニアリングは分野横断的な取組みであり，成功を収めるシステムの実現を可能にする手段であ
る。開発サイクルの早い段階で利害関係者のニーズ及び必要な機能を定義し，要求事項を文書化し，全て
の問題を考慮しながら設計を統合してシステム検証を進めることに重点を置いている。そして全ての専門
分野における規律及び専門的な技術を，概念から製品開発及び運用へと続く構造化された開発プロセスを
形成するチームの取組みに統合する。システムエンジニアリングでは，利用者及びその他の該当する利害
関係者のニーズを満たす高品質の製品を提供することを目標として，全ての利害関係者のビジネス及び技
術ニーズを考慮する。このライフサイクルは，システムを構想する概念段階からシステムの廃止段階まで
に及んでいる。このライフサイクルは，システムの取得及び供給のためのプロセスを定めている。統合さ
れた，首尾一貫したやり方で当事者たちが働くことができるようになるために，このライフサイクルは，
現代的なシステムを作り出し，活用し，かつ，管理する当事者間の意思伝達及び協調を改善することを助
ける。加えて，この枠組みは，ライフサイクルプロセスのアセスメント及び改善を可能にする。
この規格のプロセスは，包括的な集合を形成しており，組織はこれらのプロセスからその製品及びサー
ビスに適したシステムライフサイクルモデルを構築することができる。目的に応じて，組織は，その目的
を果たすために，適切な部分集合を選択し，適用できる。
この規格は，次の一つ以上の形態で使用することができる。
− 組織によって：望ましいプロセスからなる環境の構築を支援するため。手法，手順，技法，ツール及
び教育訓練された人員からなるインフラストラクチャによって，これらのプロセスを支援することが
できる。組織は，ライフサイクル段階を通して，プロジェクトを実行及び管理し，並びにシステムを
進捗させるためにこのプロセスの環境を使用してもよい。この形態では，宣言され，確立されたプロ
セスの環境の，この規格の規定への適合性についてアセスメントを実施するためにこの規格を使用す
る。
2
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
− プロジェクトによって：製品及びサービスを提供するために，組織によって制定されたプロセスから
なる環境から，その構成要素であるプロセスを，プロジェクトが選択，構築及び使用することを支援
するため。この形態では，宣言され，制定されたプロセスの環境に対するプロジェクトの適合性につ
いてアセスメントを実施するためにこの規格を使用する。
− 取得者及び供給者によって：プロセス及びアクティビティに関する合意の形成を支援するため。合意
を通じて，この規格のプロセス及びアクティビティを選択，協議，合意及び実行する。この形態では，
合意の形成における手引として，この規格を使用する。
− プロセスのアセスメントの実行者によって：組織のプロセス改善支援のために行われることがある，
プロセスアセスメントの実施で用いるプロセス参照モデルとして使用する。
1
概要
1.1
適用範囲
この規格は，人が作り出すシステムのライフサイクルを記述するためのプロセス記述の共通的な枠組み
について規定する。この規格は，エンジニアリングの視点から一そろいのプロセス及び関連する用語を定
義する。これらのプロセスは，システムの階層構造のどのレベルにも適用可能である。これらのプロセス
から選定された集合は，システムのライフサイクルの段階を管理及び実行するために，ライフサイクルを
通じて，適用することができる。これは，顧客満足を達成するという最終目標をもつ，対象となる全ての
利害関係者の参加を通して達成される。
この規格は，組織内又はプロジェクト内で使用するシステムライフサイクルプロセスの定義，制御及び
改善を支援するプロセスも規定する。組織及びプロジェクトは，システムを取得及び供給する場合にこれ
らのプロセスを使用することができる。
この規格は，人が作ったシステム，すなわち，次に示すシステム要素のうち一つ以上のもので構成され
るシステムに関するものである。それは，ハードウェア，ソフトウェア，データ，人，プロセス（例えば，
利用者にサービスを提供するプロセス），手順（例えば，操作指示書），設備，資材及び自然に発生するも
のを指す。
システム要素がソフトウェアである場合は，そのシステム要素を実装するのに，ISO/IEC/IEEE 12207
で規定するソフトウェアライフサイクルプロセスを使用してもよい。この規格とISO/IEC/IEEE 12207と
は，単一のプロジェクト又は単一の組織で併用できるように調和がとられている。
注記1 対応国際規格中で記載されるISO/IEC/IEEE 12207ソフトウェアライフサイクルプロセスは，
この規格と同時に改正作業が開始された，ISO/IEC/IEEE 12207:2017を指しており，JIS X
0160:2012（ISO/IEC 12207:2008）の改正版であるので，この規格ではISO/IEC/IEEE 12207
の国際規格番号で表記している。
注記2 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。
ISO/IEC/IEEE 15288:2015，Systems and software engineering−System life cycle processes（IDT）
なお，対応の程度を表す記号“IDT”は，ISO/IEC Guide 21-1に基づき，“一致している”
ことを示す。
1.2
目的
この規格の目的は，システムのライフサイクルにおける，取得者，供給者及び他の利害関係者の間で円
滑に情報伝達を行う場合に必要な定義されたプロセスの集合を提供することである。
この規格は，組織が取得者の役割を行う場合でも，供給者の役割を行う場合でも適用される。単一の組
3
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
織が，自主的に計画し開発する状況又は複数の当事者で計画し開発する状況でも，使用することができる。
当事者は，同じ組織又は異なる組織であってもよく，この状況は非公式の合意から公式の契約にまで及ぶ。
この規格の中のプロセスは，例えば，方法，手順，手法，道具及び訓練された人員といった，業務環境
を確立するための基礎として使用することができる。附属書Aは，これらのシステムライフサイクルプロ
セスの修整の仕方に関する基準を示す。
1.3
適用分野
この規格は，システムの構想，開発，生産，利用，支援及び廃止を含めて，システムの全ライフサイク
ルに適用し，組織の内外にかかわらず実行されるシステムの取得及び供給に適用する。この規格のライフ
サイクルプロセスは，システムに対しては並行的に，反復的に，及び再帰的に，そしてそのシステム要素
に対しては段階的に適用することができる。
システムの目的，適用領域，複雑さ，規模，新規性，適応性，量，場所，寿命及び発展は，多種多様で
ある。この規格は，人が作ったシステムのライフサイクルを構成するプロセスを記述している。それゆえ，
この規格は，一品ずつ作るシステム，量産されたシステム，及び特注の融通の利くシステムに適用される。
この規格は，単体で機能するシステムにも，より複雑で完全なより大きなシステムに組み込まれて統合さ
れるシステムにも適用される。
この規格は，プロセスの目的，及びアクティビティのタスクの実施に成功した結果得られるプロセスの
成果によって特徴付けられたプロセス参照モデルを規定する。附属書Bには，様々なプロセスに関連させ
てもよい作成物及び情報項目の例を掲載している。それゆえ，この規格は，JIS X 33002で示されたプロセ
スアセスメントを支援する参照モデルとして使える。附属書Cは，プロセス参照モデルとしてシステムラ
イフサイクルプロセスの使用に関する情報を提供している。附属書Dは，プロセス参照モデルとして使用
する場合のプロセス構成を記述している。
注記 対応国際規格ではJIS X 0145-2（ISO/IEC 15504-2:2003）を参照しているが，JIS X 33002:2017
（ISO/IEC 33002:2015）へ改正されている。
1.4
制限
この規格は，特定のシステムライフサイクルモデル，開発方法論，手法，モデル，又は技法を規定しな
い。この規格の利用者は，プロジェクトのライフサイクルモデルを選択し，この規格におけるプロセス，
アクティビティ及びタスクをそのモデルに対応付けることに責任を負う。また，当事者は，プロジェクト
に適切な方法論，手法，モデル及び技法を選択し，かつ，適用することにも責任を負う。
この規格は，管理を行うためのマネジメントシステム（management system）を制定するものではないが，
JIS Q 9001によって提供される品質マネジメントシステム，JIS Q 20000-1:2012（IEEE Std 20000-1-2013）
によって提供されるサービスマネジメントシステム，及びJIS Q 27000によって提供される情報セキュリ
ティマネジメントシステムとの互換性をもつことを意図している。
この規格は，情報項目の名称，様式，具体的な内容及び記録媒体については詳述していない。JIS X 0171
においてライフサイクルプロセスの情報項目（文書）の内容を取り扱う。
注記1 対応国際規格で参照しているISO/IEC 27000はJIS Q 27000が参照できるが，ISO/IEC 27000
は複数の部からなるファミリ規格となっている。
注記2 JIS X 0171:2014（ISO/IEC/IEEE 15289:2011）を参照しているが，ISO/IEC/IEEE 15289は，
この規格に対応させてISO/IEC/IEEE 15289:2017へ改正されている。
4
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
2
適合性
2.1
意図した用途
この規格の要求事項は，箇条6及び附属書Aに規定されている。この規格は，システム又は製品のライ
フサイクルで使用するのに適切な幾つかのプロセスに対する要求事項を規定する。
特定のプロジェクト又は組織では，この規格で規定する全てのプロセスを利用しなくてもよいと認めら
れている。それゆえ，この規格を実施するには，一般的には，組織又はプロジェクトに適したプロセス集
合を選定し，かつ，宣言する。この規格の実施が，この規格に適合していることを主張する，二通りの方
法がある。それは，完全適合（Full conformance）及び修整適合（Tailored conformance）である。
完全適合を主張するには二つの基準がある。いずれの基準でも十分に適合できるが，選択された基準（又
は両方の基準）を，その主張の中で明示的に記述する。“タスクへの完全適合”を主張することは，宣言さ
れたプロセス集合のアクティビティ及びタスクの全ての要求事項が達成されたことを明言する。“成果へ
の完全適合”を主張することは，宣言されたプロセス集合に対する要求された成果が全て達成されたこと
を明言する。“成果への完全適合”は，適合しているプロセスを実行する方法について，“タスクへの完全
適合”よりも大きな自由度がある。このため，革新的なライフサイクルモデルを用いる状況で使われるプ
ロセスを実行するときにも，有用となる場合がある。
注記1 適合性の選択肢は，この規格の適用に必要な柔軟性をもたせるために提供されている。各プ
ロセスには，一そろいの目標（“成果”と表記）及び目標を達成する方法の一つを表す一そろ
いのアクティビティ及びタスクがある。
注記2 宣言されたプロセス集合のアクティビティ及びタスクを実施する利用者は，選択されたプロ
セスの“タスクへの完全適合”を明言できる。しかし，アクティビティ及びタスクの全てを
実施するのではなく，宣言されたプロセス集合の目標（成果）を達成する革新的なプロセス
に変形させて実施する利用者もいる場合がある。これらの利用者は宣言されたプロセス集合
の“成果への完全適合”を明言できる。タスクへの適合及び成果への適合という，二つの基
準は必然的に同等ではない。なぜならば，アクティビティ及びタスクの特定の実施には，場
合によって，成果だけを達成するよりも高いレベルの能力を必要とするからである。
注記3 この規格を取得者と供給者との間の合意形成の支援に使う場合，この規格の箇条は，変更の
有無にかかわらず合意の内容に組み込むために選択することができる。この場合，取得者及
び供給者にとっては，この規格に適合していることよりも，合意を遵守していることを主張
することがより適切である。
注記4 この規格を取引条件として課する組織（例えば，国家機関，産業団体，企業）は，取引条件
として供給者が遵守することを求める事項を構成する，最小限要求されるプロセス，成果，
アクティビティ及びタスクを規定し公表することができる。
注記5 この規格の要求事項は，“とする”又は“（し）なければならない”（shall）という動詞を使っ
て表現される。推奨事項は，“することが望ましい”（should）と表現される。許可事項は，“し
てもよい”，“すること（場合）がある”又は“することができる”（may）と表現される。し
かしながら，使われる動詞にかかわらず，適合に対する要求事項は前述のように選択される。
2.2
完全適合（Full conformance）
2.2.1
成果への完全適合（Full conformance to outcome）
完全適合の主張では，適合を主張するプロセス集合を宣言する。成果への完全適合は，宣言したプロセ
ス集合の全ての成果が達成されていることを，証拠を提示して立証することで実現する。この場合，宣言
5
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
された一そろいのプロセスのアクティビティ及びタスクに対する規定は，その規定で使用されている動詞
にかかわらず，要求事項であるよりも手引となる。
注記 この規格で意図している用途の一つは，プロセスのアセスメント及び改善を促進することであ
る。この目的のために，各プロセスの目標は，JIS X 33002の規定と互換性のある“成果”とい
う形で書かれている。それらの規格は，この規格におけるプロセスのアセスメントを提供し，
改善のための基礎を提供する。プロセスのアセスメント及び改善を意図する利用者は，JIS X
33002によって要求される“プロセス参照モデル”として，この規格に記載したプロセスの成
果を使用することができる。
2.2.2
タスクへの完全適合（Full conformance to tasks）
完全適合の主張では，適合を主張するプロセス集合を宣言する。タスクへの完全適合は，宣言したプロ
セス集合のアクティビティ及びタスクの全ての要求事項が達成されていることを，証拠を提示して立証す
ることで実現する。この場合，宣言された一そろいのプロセスの成果に対する規定は，その規定で使用さ
れている動詞にかかわらず，要求事項であるよりも手引となる。
注記 契約において，取得者又は規制機関が供給者のプロセスを詳細に理解することを要求するよう
な状況であれば，タスクへの完全適合を主張することが適切な場合がある。
2.3
修整適合（Tailored conformance）
この規格を，一そろいのプロセスを定める基礎として使用するが，定めたその一そろいのプロセスが完
全適合とはみなされないときは，附属書Aに規定した修整（tailoring）プロセスに従って，この規格の箇
条を選定するか又は修正する。修整適合であると主張する，修整文章を明示する。修整適合は，修整され
た，プロセスの成果，アクティビティ及びタスクが達成されていることを，証拠を提示して立証すること
で実現する。
3
引用規格
引用規格はない。
4
用語，定義及び略語
4.1
用語及び定義
この規格で用いる主な用語及び定義は，次による。
注記 その他の用語は，ISO/IEC/IEEE 24765を参照。その用語定義はwww.computer.org/sevocabから
も用語検索ができる。
4.1.1
取得者（acquirer）
供給者から，製品又はサービスを取得又は調達する利害関係者。
注記 取得者のことを指すために通常使われている用語には，ほかに納入先，買付け者，顧客，所有
者，購入者又は内部若しくは組織の出資者がある。
4.1.2
取得（acquisition）
システム製品又はシステムサービスを入手するプロセス。
4.1.3
アクティビティ（activity）
6
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
プロセスの構成要素で，関連の強いタスクの集合。
4.1.4
合意（agreement）
業務上の関係を実行するための取決めの相互確認。
例 合意の契約，覚書き。
4.1.5
アーキテクチャ（architecture）
＜システムに関する＞ システムが存在する環境の中での，システムの基本的な概念又は性質であって，
その構成要素，相互関係，並びに設計及び発展を導く原則として具体化したもの（ISO/IEC/IEEE
42010:2011）。
4.1.6
アーキテクチャ フレームワーク（architecture framework）
特定の適用領域及び／又はその利害関係者の関係者団体の中で確立された，アーキテクチャを記述する
ための規約，原則及び実践手法（ISO/IEC/IEEE 42010:2011）。
例1 アーキテクチャ及び方法論の汎用エンタープライズ参照モデル［Generalized Enterprise Reference
Architecture and Methodologies (GERAM)］の記載がISO 15704にあり，アーキテクチャ フレー
ムワークの一つである。
例2 開放型分散処理の参照モデル［Reference Model of Open Distributed Processing (RM-ODP)］の記
載がISO/IEC 10746-3にあり，アーキテクチャ フレームワークの一つである。
4.1.7
アーキテクチャ ビュー（architecture view）
特定の，システムに対する関心事の観点から，システムのアーキテクチャを表現している作業成果物
（ISO/IEC/IEEE 42010:2011）。
4.1.8
アーキテクチャ ビューポイント（architecture viewpoint）
特定の，システムに対する関心事を枠組みに収めるために，アーキテクチャ ビューを構築し，解釈し，
用いるための規約を確立している作業成果物（ISO/IEC/IEEE 42010:2011）。
4.1.9
監査（audit）
仕様，標準，契約合意，又は他の基準への適合性をアセスメントするための作業成果物又は作業成果物
の集合に対する独立した審査（ISO/IEC/IEEE 24765:2010）。
4.1.10
ベースライン（baseline）
媒体とは無関係に，構成品目のライフサイクル期間中の特定の時点で，正式に指定されて確定され，正
式に承認された構成品目の版（IEEE Std 828-2012）。
4.1.11
組織レベルの運用概念（concept of operations）
運用又は一連の運用に関する組織の前提条件・意図を，言葉及び／又は図で，全体像として記述するも
の（JIS X 0166:2014）。
注記1 組織レベルの運用概念（ConOps）は，しばしば長期戦略計画及び年間運用計画の形で具体化
7
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
される。後者の場合，その計画内の運用の概念は，同時に実施する又は順次実施する連結し
た一連の運用を網羅する。この概念は，組織の運用の全体像を与えるために設計される。シ
ステムレベルの運用概念（OpsCon）も参照。
注記2 これは，運用スペース・システム能力・インタフェース・運用環境を制限するための根拠に
なる。
注記3 対応国際規格ではANSI/AIAA G-043A-2012eの定義を参照していると記載されているが，JIS
X 0166:2014（ISO/IEC/IEEE 29148）で同一の定義をしている。
4.1.12
関心事（concern）
＜システム＞ システムにおいて関心を集める事柄のことで，システムの一人以上の利害関係者に関係
すること（ISO/IEC/IEEE 42010:2011）。
注記 関心事はシステムがその環境の中で受ける全ての影響に関して存在する。この影響には，開発
面，技術面，ビジネス面，運用面，組織面，政治面，経済面，法律面，規制面，生態系環境面
及び社会面での影響を含む。
4.1.13
構成品目（configuration item）
ハードウェア，ソフトウェア若しくはその両方の品目又は集合体で，構成管理のために指定され，構成
管理プロセスでは単一の構成要素である実体として取り扱われるもの（ISO/IEC/IEEE 24765:2010の定義
を，“品目”を含むように変更している。）。
4.1.14
顧客（customer）
製品又はサービスを受け取る組織又は人（JIS Q 9000:2015の定義の一部を変更している。）。
例 顧客には，消費者，依頼人，利用者，取得者，納入先，買付け者又は購入者がいる。
注記1 顧客は，組織の内部又は外部であることができる。
注記2 対応国際規格ではJIS Q 9000:2006（ISO 9000:2005）の定義にサービスを追加した定義として
いるが，改正されたJIS Q 9000:2015（ISO 9000:2015）から一部を変更した定義になっている。
4.1.15
設計（動詞）（design）
＜プロセス＞ システム又はシステム要素の，アーキテクチャ，システム要素，インタフェース及びそ
の他の特性を定義すること（ISO/IEC/IEEE 24765:2010の定義で，構成要素をシステム要素に変更してい
る。）。
4.1.16
設計（名詞）（design）
4.1.15で定義したプロセスの結果（ISO/IEC/IEEE 24765:2010）。
注記1 設計の情報は，システム要素及び要素間の相互関係についての仕様を含み，そのアーキテク
チャの適合する実装の支援を完了するために十分なもの。
注記2 設計は，システム要素について，詳細な実装レベルの物理的構成，振る舞い，一時的で経時
変化する関係，及びその他の属性を提供する。
4.1.17
設計特性（design characteristic）
8
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
設計の属性又は区別できる特徴（feature）であって，製品又はサービスの測定可能な記述に関連してい
るもの（ISO/IEC/IEEE 24765:2010）。
4.1.18
イネーブリングシステム（enabling system）
ライフサイクルの段階においては対象システムを支援するが，運用中はその機能に直接的に寄与すると
は限らないシステム。
例 対象システムが生産段階に入ると，生産イネーブリングシステムが必要となる。
注記 各イネーブリングシステムは，それ自身のライフサイクルをもつ。イネーブリングシステム自
体を対象システムとして扱う場合には，この規格は，各イネーブリングシステムに適用可能で
ある。
4.1.19
環境（environment）
＜システム＞ システムに影響を及ぼす全ての設定及び周囲の条件を決定付ける状況（ISO/IEC/IEEE
42010:2011）。
4.1.20
設備，施設（facility）
活動の実施を容易にする物理的手段又は装置。例えば，建物，器具，道具など。
4.1.21
インシデント（incident）
異常な若しくは予期しないイベント，イベントの集合，状態又は状況であって，プロジェクト，製品，
サービス又はシステムのライフサイクル期間中の全ての時点で起こるもの。
4.1.22
情報項目（information item）
人間が利用するために作成され，保存され，及び納入される個別に識別できる情報の本体（JIS X 0171）。
4.1.23
ライフサイクル（life cycle）
システム，製品，サービス，プロジェクト又は人が作った他の実体の構想から廃止までの漸進的な発展。
4.1.24
ライフサイクルモデル（life cycle model）
段階に編成されることもあるライフサイクルに関係するプロセス及びアクティビティの枠組みで，情報
伝達及び理解のための共通に参照できる役割をもつもの。
注記 “プロセス”，“アクティビティ”及び“タスク”は，システムのライフサイクルで行う作業を
階層化して表すものである。最上位の作業のくくりが“プロセス”，その“プロセス”の構成要
素が“アクティビティ”，さらに，“アクティビティ”の構成要素が“タスク”である。
4.1.25
システムレベルの運用概念（operational concept）
一つのシステム又は関連する一組のシステムの，運用又は一連の運用に関して，組織の前提条件・意図
を言葉及び図で記述するもの（JIS X 0166:2014）。
注記1 システムレベルの運用概念（OpsCon）は，一つ以上の特定のシステム，又は関連する一組の
システム，を利用する運用の全体像を与えるために設計する。組織の運用環境の中で利用者
9
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
及び運用操作者の視点から全体像を与えるものである。組織レベルの運用概念（ConOps）も
参照。
注記2 対応国際規格ではANSI/AIAA G-043A-2012eの定義を参照していると記載されているが，JIS
X 0166:2014（ISO/IEC/IEEE 29148）で同一の定義をしている。
4.1.26
運用操作者（operator）
システムの運用操作を行う個人又は組織。
注記1 運用操作者及び利用者の役割は，同一の個人又は組織に対して，同時に又は順次的に，付与
される。
注記2 知識，スキル（技能）及び手順を備えた個々の運用操作者は，システムの一要素としてみな
すことができる。
注記3 運用操作者は，運用されているシステム上での運用を行う場合，又は運用されているシステ
ムそれ自体の運用を行う場合がある。これは，運用指示がシステムの境界内にあるか，外に
あるかによる。
4.1.27
組織（organization）
責任，権限及び関係の取決めをもつ人々の集団及び施設（JIS Q 9000:2015の定義の一部を変更してい
る。）。
例 企業，法人，事務所，事業，協会，義援団体，個人事業者，同業者組合又はこれらの一部若しく
は組合せ。
注記1 組織の識別された部分（たとえ一個人のように小さくても）又は組織内の識別された集団は，
責任，権限及び関係をもてば組織とみなされる。クラブ，組合，会社，学会など特定の目的
のために組織された人の一群。
注記2 対応国際規格ではJIS Q 9000:2006の定義に注記1を追加したものと記載しているが，JIS Q
9000:2015の定義の一部を，この規格の内容に合うよう変更したものにしている。
4.1.28
当事者（party）
契約を含む合意に関わる組織。
注記 この規格では，合意する当事者は取得者及び供給者と呼ばれる。
4.1.29
問題（problem）
困難さ，不確定さ，若しくは現実のものとなった望まれないイベント，一連のイベント，状態又は状況
であって，調査及び是正処置が要求されること。
4.1.30
プロセス（process）
インプットをアウトプットに変換する，相互に関連する又は相互に作用する一連のアクティビティ（JIS
Q 9000:2015の定義の一部を変更している。）。
注記1 プロセスのアウトプット（output）は，プロセスの結果であり，作業成果物若しくは製品又
はサービスを通常は指す。この規格ではアウトプット，出力などと記す。
注記2 対応国際規格ではISO 9000:2005の定義を引用しているため，この規格では，改正されたJIS
10
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
Q 9000:2015（ISO 9000:2015）の定義の一部を変更したものにしている。
4.1.31
プロセスの目的（process purpose）
プロセスを実行する高水準の目標及びプロセスの効果的実施によって見込まれる成果。
注記 プロセスを実施することの目的は，利害関係者に便益を提供することである。
4.1.32
製品（product）
プロセスの結果。
注記1 合意される一般的な製品分類には次の四つの分類がある。ハードウェア（例えば，エンジン
の機構部品），ソフトウェア（例えば，コンピュータのプログラム），サービス（例えば，輸
送）及び処理した結果として得られた資材（例えば，潤滑油）。ハードウェア及び処理した結
果として得られた資材は形のある有形の製品となるのに対し，ソフトウェア及びサービスは
通常は形のない無形の製品となる。
注記2 対応国際規格ではISO 9000:2005の定義を引用しているため，この規格では，改正されたJIS
Q 9000:2015（ISO 9000:2015）の定義を変更したものにしている。
注記3 製品には，成果物，作成物，中間成果物，作業成果物などの，プロセスのアウトプットを含
む場合がある。
4.1.33
プロジェクト（project）
定められた資源及び要求事項に従って，製品又はサービスを作り出すために実施される，定義された開
始条件及び終了条件がある取組み。
注記 プロジェクトは，調整され制御されたアクティビティからなる固有のプロセスとして見られる
こともあるとともに，この規格に定義したテクニカルマネジメントプロセス及びテクニカルプ
ロセスのアクティビティで構成される。
4.1.34
品質保証（quality assurance）
品質要求事項が満たされるという確信を与えることに焦点を合わせた，品質マネジメントの一部（JIS Q
9000:2015）。
注記 対応国際規格ではISO 9000:2005の定義を引用しているが，改正されたJIS Q 9000:2015（ISO
9000:2015）でも同一の定義となっている。
4.1.35
品質特性（quality characteristic）
要求事項に関連する，製品，プロセス又はシステムに本来備わっている特性（JIS Q 9000:2015の定義の
一部を変更している。）。
注記1 重大な品質特性には，健康，安全性，セキュリティ，アシュアランス，信頼性，アベイラビ
リティ（availability可用性）及び運用の支援性に関連する特性を通常含む。
注記2 対応国際規格ではISO 9000:2005の定義の一部を変更しているが，改正されたJIS Q
9000:2015（ISO 9000:2015）からも一部を変更した定義としている。
4.1.36
品質マネジメント，品質管理（quality management）
11
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
品質に関して組織を指揮し，管理するための調整された活動（JIS Q 9000:2015の定義の一部を変更して
いる。）。
注記 対応国際規格ではISO 9000:2005の定義を引用しているため，改正されたJIS Q 9000:2015（ISO
9000:2015）から一部を変更した定義としている。
4.1.37
要求事項（requirement）
ニーズとそれに付随する制約・条件とを変換した又は表現する文（JIS X 0166:2014）。
4.1.38
資源（resource）
プロセスの実行中に利用又は消費される資産。
注記1 資源には，資金，要員，設備，資本設備，道具などの多様な実体，及び電力，水，燃料，通
信基盤などの公益物を含む。
注記2 資源には，再利用できるもの，再生できるもの，又は使い切ってしまうものも含む。
4.1.39
廃止（retirement）
運用組織又は保守組織が実施中の支援を中止する，新システムに一部分若しくは全体を置き換える，又
は改定したシステムを導入すること。
4.1.40
リスク（risk）
目的に対する不確かさの影響（JIS Q 0073:2010）。
注記1 影響とは，期待されていることから，好ましい方向及び／又は好ましくない方向にかい（乖）
離することをいう。肯定的な好ましい方向の影響は，機会（opportunity）となる。
注記2 目的には，財務，人の健康及び安全，環境面についての到達目標など，異なった側面があり，
戦略，組織横断的，プロジェクト，製品，プロセスなど異なるレベルで設定できる。
注記3 リスクを，起こり得る潜在的なイベント及び引き起こされる最終的な結果，又はこれらの組
合せについて述べることによって，その特徴を記述することが多い。
注記4 リスクを，あるイベント（イベントには周囲環境の変化を含む。）が引き起こす最終的な結果
とその起こりやすさとの組合せによって表現することがよくある。
注記5 不確かさとは，あるイベント，そのイベントが引き起こす最終的な結果，又は起こりやすさ
に関する，情報，理解若しくは知識が，たとえ部分的にでも欠落している状態をいう。
4.1.41
セキュリティ（security）
意図的な破壊改変又は強制的な故障に対する防護。確信性，完整性，アベイラビリティ及び責任追跡性
の四つの属性に五つ目に使用性の観点を加えて，これらのアシュアランスの課題に関係している全てのこ
とから構成したもの（NATO AEP-67）。
4.1.42
サービス（service）
活動，作業又は義務を遂行すること。
注記1 サービスは，それ自体で完結したものであり，一様になるよう整合化され，個別になってお
り，その他のサービス群から構成することができる。
12
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記2 通常，サービスは目には見えない製品である。
4.1.43
段階（stage）
実体のライフサイクル内の期間で，実体の記述又は実現の状態に関連するもの。
注記1 この規格では，段階は，実体のライフサイクルを通して，実体の大きな進捗及び達成のマイ
ルストーンに関係する。
注記2 段階は，並行して重なることがよくある。
4.1.44
利害関係者（stakeholder）
システムに，権利，持分，請求権若しくは関心をもっている個人若しくは組織，又はニーズ及び期待に
合致する特性をシステムがもつことに，権利，持分，請求権若しくは関心をもっている個人若しくは組織。
例 利害関係者の例は，最終利用者，最終利用者の組織，支援者，開発者，製作者，教育訓練者，保
守者，廃棄処理者，取得者，供給者の組織，規制機関。
注記 利害関係者には，利害関係者間で相互に相反する利害関係のある関心，又はシステムと相反す
る利害関係のある関心をもち得る。
4.1.45
供給者（supplier）
製品又はサービスの供給に関して取得者と合意を結ぶ組織又は個人。
注記1 供給者に対して通常使用される用語は，請負業者，生産者，販売者又はベンダ。
注記2 取得者及び供給者は，同一の組織に属することがある。
4.1.46
システム（system）
一つ以上の明記された目的を達成するために組織された相互に作用する要素の組合せ。
注記1 システムとは，それが提供する製品又はサービスとみなされることもある。
注記2 実際には，その意味の解釈は，例えば，航空機システムのように複合名詞の使用によってし
ばしば明確にされる。別の表現として，システムという言葉を使わずに，文脈が明らかな場
合は，例えば，“航空機システム”を“航空機”という用語に置き換えることができる。その
場合は，システムという捉え方の観点が曖昧になる。
注記3 完成したシステムは，それが意図された環境において，システム自体を十分に利用できるよ
う，必要な度合いで運用及び支援をするために要求される，次のものを含む。全ての関係す
る機器，設備・施設，資材，コンピュータのプログラム，ファームウェア，技術文書，サー
ビス及び要員。
4.1.47
システム要素（system element）
システムを構成する要素の集合の一部分。
例 システム要素の例は，ハードウェア，ソフトウェア，データ，人間，プロセス（例えば，利用者
にサービスを提供するプロセス），手順（例えば，操作指示），設備・施設，資材，自然に発生す
る実体又はそれらの組合せ。
注記 システム要素とは，指定された要求事項を満たすように実装できるシステムの個別の部分であ
る。
13
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
4.1.48
対象システム（system-of-interest）
この規格の文脈においてライフサイクルが検討対象となるシステム。
4.1.49
システムエンジニアリング（systems engineering）
利害関係者のニーズ，期待及び制約の集合を，解決するソリューションへ変換するため，及びソリュー
ションが用いられる全期間を通じて，それを支援するために要求される，技術上及び管理上の作業の全体
を統括するような，複数の専門分野を横断した取組方法。
4.1.50
タスク（task）
プロセスの一つ以上の成果の達成に貢献するように意図された，要求され，勧告され，又は許容される
行動。
4.1.51
トレードオフ（trade-off）
利害関係者にとっての実質利益に基づいて，様々な要求事項と，解決するための代替ソリューション候
補とから選定するという意思決定行為。
4.1.52
利用者（user）
利用中，システムと対話するか，又はシステムから利益を得る個人又はグループ（JIS X 25010:2013）。
注記1 利用者又は運用操作者の役割は，同一の個人又は組織の中で，同時に又は順番に担うことが
ある。
注記2 注記はJIS X 25010:2013から変更している。
4.1.53
妥当性確認（validation）
客観的証拠を提示することによって，特定の意図された用途又は適用に関する要求事項が満たされてい
ることを確認すること（JIS Q 9000:2015）。
注記1 妥当性確認とは，意図された運用環境下で，その意図された用途，利用の目標及び目的を，
システムが達成できる（利害関係者要求事項に合致できる。）こと。正しいシステムが構築さ
れたこと，を確認すること。
注記2 対応国際規格ではJIS Q 9000:2006の用語定義に注記1を追加したと記載しているが，改正さ
れたJIS Q 9000:2015にある定義の注記を変更したものになっている。
4.1.54
検証（verification）
客観的証拠を提示することによって，規定要求事項が満たされていることを確認すること（JIS Q
9000:2015）。
注記1 検証とは，システム又はシステム要素と要求される特性とを比較するという一連のアクティ
ビティである。この比較の対象となるシステム要素には，規定要求事項，設計記述及びシス
テム自身が含まれるが，これらに限定されるわけではない。システムが正しく構築されたこ
と，を確認すること。
注記2 対応国際規格ではJIS Q 9000:2006の用語定義に注記1を追加したと記載しているが，改正さ
14
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
れたJIS Q 9000:2015にある定義の注記を変更したものになっている。
4.2
略語
この規格では，次の略語を使用する。
CM（Configuration Management）：構成管理
CCB（Configuration Control Board）：構成管理委員会
COTS（Commercial-Off-The-Shelf）：商用既製品
FCA（Functional Configuration Audit）：機能構成監査
NDI（Non-developmental Items）：非開発項目
PCA（Physical Configuration Audit）：物理構成監査
QA（Quality Assurance）：品質保証
SDP（Software Development Plan）：ソフトウェア開発計画
SEMP（Systems Engineering Management Plan）：システムエンジニアリングマネジメント計画
SOI（System of Interest）：対象システム
SoS（System of Systems）：システム オブ システムズ
5
基本概念及び適用
5.1
はじめに
箇条5は，この規格の基礎となった本質的な概念を強調し，その説明に役立てるためのものである。こ
れらの概念の詳細は，ISO/IEC/IEEE 24748-1:2018及びISO/IEC/IEEE 24748-2:2018のライフサイクル管理
の適用の手引の中で提供されている。
5.2
システム概念
5.2.1
システム
この規格で考えるシステムとは，利用者及び他の利害関係者の利益となるよう，定義された環境におい
て製品又はサービスを提供するために，人が作り，創出し，活用するものである。これらのシステムは，
次のシステム要素の一つ以上のもので構成されてもよい。すなわち，ハードウェア，ソフトウェア，デー
タ，人間，プロセス（例えば，利用者にサービスを提供するプロセス），手順（例えば，運用操作者向け使
用説明書），施設，資材及び自然に発生する実体である。それらは，利用者視点から，製品又はサービスと
考えられる。
特定のシステム，そのアーキテクチャ及びシステム要素の認識及び定義は，利害関係者の関心及び責任
に依存する。ある利害関係者の対象システムは，他の利害関係者の対象システムにおけるシステム要素と
見ることができる。しかも，一つの対象システムは，他の利害関係者の対象システムに対する運用の環境
の一部と見ることができる。
対象システムの特性に関する要点を次に示す。
a) 定義された境界によって，対象システムを区切り，意味のあるニーズと現実的なソリューションとが
一つにまとまる。
b) システム要素間には階層的又は他の関係がある。
c) 対象システム内のどのレベルの実体もそれ自体一つのシステムと見ることができる。
d) システムは，定義された下位のシステム要素の集合が，統合されたものからなる。
e) 人間は，システムの外部の利用者と見ることができるし，システム内部のシステム要素（すなわち，
運用操作者）と見ることもできる。
15
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
f)
システムは，製品のように，独立した実体として，又は一組のサービスのように，周囲の環境との相
互作用ができる機能の集合として見ることができる。
システムを定義するためにどのような境界を選んだとしても，この規格における概念は一般的であり，
実際に規格を実施する各利用者が，ライフサイクルをそれぞれ具体化して，利用者のシステムの原則に関
連させる又は適応させることを可能にしている。
5.2.2
システム構造
この規格においてシステムライフサイクルプロセスは，システムとの関連で規定されている（図1参照）。
システムは，互いに影響し合うシステム要素の集合から構成され，各システム要素は，それぞれの指定さ
れた要求事項を実現するために実装される。そのため，どのシステム要素についても，その実装の責任を，
合意を得た上で別の当事者に委ねてもよい。
システムは，
相互作用するシ
ステム要素の集
合から構成される
システム
一つ以上の明示さ
れた目的を達成する
（一つの境界）
システム
要素
システム
要素
システム
要素
システムは，
相互作用するシ
ステム要素の集
合から構成される
図1−システムとシステム要素との間の関係
システムとそのシステム要素の完全な集合との間の関係を，対象システムの階層で表現するのが，一般
的には最も単純化した表現である。より複雑な対象システムの場合，システム要素と思われるもの自体を
一つのシステム（これも複数のシステム要素から構成される。）と考える必要がある。そうすることで，シ
ステム要素の完全な集合が，確信をもって定義できるようになる（図2参照）。このように，適切なシス
テムライフサイクルプロセスは，対象システムに再帰的に適用してその構造を分解し，理解可能で，管理
可能なシステム要素を実装（作成，購入又は再利用）する。図1及び図2は階層関係を意味するが，実際
には，ネットワーク及び他の分散システムのように，一つ以上の側面について，階層的ではないシステム
が増えている。附属書Gは，システム オブ システムズ（SoS）の概念を論じている。
対象
システム
システム
要素
システム
要素
システム
要素
システム
システム
要素
システム
要素
システム
システム
システム
システム
要素
システム
要素
システム
要素
システム
要素
システム
要素
システム
要素
システム
システム
システム
システム
要素
システム
要素
システム
要素
システム
要素
図2−対象システム構造
16
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
5.2.3
イネーブリングシステム
対象システムのライフサイクルを通じて，直接的には対象システムの運用環境の一部とならないシステ
ム（例えば，大量生産システム，教育訓練システム，保守システム）から不可欠なサービスが提供される
ことが要求される。これらのシステムの各々は，対象システムのライフサイクルの一部（例えば，段階）
の実施を実現できるようにする。これらは“イネーブリングシステム”と名付けられ，ライフサイクルを
通じて対象システムの発展を促進する。
対象システムによって運用環境に供給されるサービスと，イネーブリングシステムによって対象システ
ムに供給されるサービスとの間の関係を，図3に示す。イネーブリングシステムは，対象システムによっ
て提供されるサービスに間接的に寄与するのが分かる。対象システムとイネーブリングシステムとの間の
関係は，双方向か一方通行の関係である。イネーブリングシステムとの相互作用に加えて，対象システム
は，システムA，システムB及びシステムCで示されるように，運用環境の他のシステムとも相互作用す
ることがある。運用環境において，イネーブリングシステムと他のシステムとのインタフェースに対する
要求事項は，対象システムに対する要求事項に含まれることが必要とされる。
運用環境内の
システムB
対象システム
運用環境内の
システムA
運用環境内の
システムC
イネーブリング
システムX
イネーブリング
システムY
イネーブリング
システムZ
運用環境を構成する
システムとの
相互作用
イネーブリングシステムとの
相互作用
図3−対象システム，運用環境及びイネーブリングシステム
システムライフサイクルの段階の間に，関連したイネーブリングシステム及び対象システムが同時に考
慮される。イネーブリングシステム及び対象システムは，相互に依存しているので，それらは一つのシス
テムと見ることもできる。適切なイネーブリングシステムがまだ存在しないときは，対象システムに責任
をもつプロジェクトは，イネーブリングシステムを作り出し利用することについても直接的な責任をもつ。
イネーブリングシステムを作り出すことは，別個のプロジェクトとして考えることができ，それによって，
イネーブリングシステム自体も一つの対象システムと見ることができる。
これらの概念の更なる詳細は，ライフサイクルプロセスの適用の手引であるISO/IEC/IEEE 24748シリ
ーズで提供される。
5.3
組織及びプロジェクト概念
5.3.1
組織
組織全体又は組織の一部が合意する場合，組織全体又は組織の一部は合意の“当事者（party）”と呼ば
れることがある。複数の当事者の集合が，同じ組織内から形成されても，又は別々の組織から形成されて
17
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
もよい。個人が責任及び権限を割り当てられている場合，組織は小さくてもよく，一人でもよい。
プロセスの実行に責任をもって担当する組織は，そのプロセスに合わせた名称で参照されることがある。
例えば，取得プロセスを実行する組織は，“取得者”と呼ばれることがある。ほかには，“供給者”，“実装
者”，“保守者”，及び“運用操作者”が含まれる。
この規格の組織には，ほかにも幾つかの用語が用いられる。“利用者”とは，製品又はサービスを利用す
ることから便益を得る組織である。“顧客”とは，利用者及び取得者の総称を指す。“利害関係者”とは，
システムに関心をもつ個人又は団体を指す。
プロセス及び組織は，互いに機能面でだけ関連している。この規格は，組織の構造を規定するものでは
なく，特定のプロセスを組織の特定の部分が実行するように指定するものでもない。組織に適切な構造を
定義し，プロセスの実行のために適切な役割を割り当てるのは，組織の責任である。
この規格のプロセス群は，様々な組織に対応する包括的な集合を形成する。ビジネス上の目的又は取得
戦略に応じて，組織の規模の大小に関係なく，組織はその目的を達成するための適切な一連のプロセス集
合（及びそれに関連するアクティビティ及びタスク）を選択することができる。一つの組織が，一つ以上
の複数のプロセスを実行してもよい。
この規格は，二つ以上の複数の組織によって，組織内外に適用することを意図している。内部的に適用
される場合，合意する二つの当事者は，典型的には，異なる状況下で正式さの程度が異なる合意条件を基
に行動してもよい。外部的に適用される場合，合意する二つの当事者は，通常，契約条件を基に行動する。
この規格では，“合意”という用語を使用して，このようないずれの状況にも適用する。
この規格の目的上，どのプロジェクトも組織内で実施される状況にあるとしている。これは重要である。
なぜならば，プロジェクトは組織のビジネスプロセスが作り出す様々な成果に依存するからである（例え
ば，プロジェクトを実施する要員となる従業員，及びプロジェクトを収容する施設）。この目的のために，
この規格は一連の“組織的プロジェクトイネーブリング”プロセス群を提供する。このプロセス群が，ビ
ジネスを運営するのに十分であるとされているのではなく，組織に関するプロセス群を一まとまりとみな
したものが，プロジェクトが組織に依存関係をもつ状況では，最小限必要なものとして記述することを意
図している。
5.3.2
組織及びプロジェクトのレベルにおけるプロセスの採用
現代のビジネスは，ビジネスのプロジェクトに繰り返し適用される堅ろう（牢）なライフサイクルプロ
セスの開発に努めている。したがって，この規格は，組織レベル又はプロジェクトレベルで取り入れて役
に立つように意図したものである。組織はこの規格を採用し，適切な手順，実践方法，ツール及び方針を
補完することになる。ある組織内のプロジェクトは，通常，この規格に直接適合するよりも，その組織の
プロセスに適合することになる。場合によっては，組織レベルで導入するプロセスの適切な集合をもたな
い組織によって，プロジェクトが実行されることがある。そのようなプロジェクトは，この規格の規定を
プロジェクトに直接適用してもよい。
5.4
ライフサイクルの概念
5.4.1
システムライフサイクルモデル
あらゆるシステムには，ライフサイクルがある。ライフサイクルは，そのシステムのニーズの概念化，
その実現，利用，発展及び廃棄を表現する，抽象化した実用的なモデルを使って規定することができる。
システムは，そのライフサイクルを通じて，組織内の人によって実行され，管理された活動の結果とし
て進行する。これらの活動を実行するためにプロセスが用いられる。ライフサイクルモデルの中の詳細は，
これらのプロセス，それらのプロセスの成果，プロセスの関係及びプロセスの順序に関して表現される。
18
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
この規格は，特定のライフサイクルモデルを規定するものではない。その代わりに，ライフサイクルプロ
セスと呼ばれる，システムのライフサイクルの定義に使用できる，一まとまりのプロセスの集合を定義し
ている。この規格は，ライフサイクルモデル内のプロセスについて特定の順序を規定するものでもない。
プロセスの順序は，プロジェクトの目的及びシステムのライフサイクルモデルの選択によって決定する。
5.4.2
システムライフサイクル段階
ライフサイクルは，そのシステムの性質，目的，利用及び周囲の状況によって異なる。各段階（stage）
は，ライフサイクル全体に対する明確な目的及び貢献があり，システムライフサイクルを計画し，実行す
るときに考慮される。
段階は，システムと関連したライフサイクルとの主要期間を表し，システム記述の状態又はシステム自
身に関連する。段階は，そのライフサイクルを通してシステムの主要な進捗及び達成されるマイルストー
ンを記述する。段階は，ライフサイクルの主要な決定ゲートを生み出す。これらの決定ゲートは，システ
ムを作り出す又は利用するときに，コスト，スケジュール及び機能性に関係する固有の不確実性及びリス
クを理解し，対処するために，組織によって利用される。それゆえ，段階は，その中で組織の管理者がプ
ロジェクト及びテクニカルプロセスを概観できるレベルで可視性及び制御をもつ枠組みを組織に提供する。
ISO/IEC/IEEE 24748-1:2018によれば，典型的なシステムライフサイクル段階には，概念，開発，生産，
利用，支援及び廃止の各段階が含まれる。
組織によっては，対照的となるビジネス戦略とリスク緩和戦略とを満たすために，段階を異なった形で
使用する。複数の段階を同時並行させて使用したり，異なった順序で使用したりすることで，通常とは明
確に異なる特性をもつライフサイクルを形成することができる。
ライフサイクル段階についての概念の詳細は，ISO/IEC/IEEE 24748-1:2018にあるライフサイクル管理
の適用の手引で記載している。
5.5
プロセスの概念
5.5.1
プロセスの基準
この規格におけるライフサイクルプロセスの決定は，三つの基本原則に基づいている。
− 各ライフサイクルプロセスは，成果，アクティビティ及びタスクの間に強い関係がある。
− プロセス間の依存関係は，実行可能であることを確保できる範囲までは，可能な限り減らす。
− 一つのプロセスは，ライフサイクルの中で単一の組織によって実行可能である。
5.5.2
プロセスの記述
この規格の各プロセスは，次の属性によって記述する。
− 名称は，プロセスの全体としての適用範囲を表す。
− 目的は，プロセスを実行する目標を記述する。
− 成果は，プロセスの実施に成功することによって期待される観察可能な結果を表す。
− アクティビティは，プロセスの構成要素で，関連の強いタスクの集合である。
− タスクは，成果の達成を支援することを意図した要求事項，推奨，又は容認された行動である。
プロセス記述の形式に関する更なる詳細は，ISO/IEC TR 24774に記載されている。
5.5.3
プロセスの一般的な特性
5.5.2で説明した基本属性に加えて，全てのプロセスに共通する他の属性によって，プロセスを特徴付け
てもよい。JIS X 33002をはじめとするプロセスアセスメントの規格は，プロセス能力測定の枠組みの中で
6段階の達成レベルを特徴付けるための共通プロセス属性を識別している。この規格の附属書Cに，それ
らに定義されている，レベルのより高いプロセス能力の達成に貢献するプロセス属性を一覧する。
19
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記 対応国際規格ではJIS X 0145-2（ISO/IEC 15504-2:2003）を参照しているが，JIS X 33002:2017
（ISO/IEC 33002:2015），JIS X 33020:2019などへ改正されている。
5.5.4
プロセス修整（Tailoring）
附属書Aは，この規格の修整を行うために必要な基本的アクティビティを定義する。修整することで，
この規格への適合の主張によって認められている価値が減少してしまう可能性があることに注意するのが
よい。その理由は，修整によって，望ましい規定が削除された度合いを他の組織が理解するのが難しいか
らである。この規格への適合を単独で主張して明言する組織は，多くのプロセスを列挙して，それらに対
して修整適合するよりも，より少ないプロセスを列挙して，それらに対しての完全適合を主張した方が有
利であると判断してもよい。
5.6
この規格のプロセス
5.6.1
はじめに
この規格では，ソフトウェアシステムのライフサイクルで実行する活動を四つのプロセスグループに分
けている。これらのグループ内のライフサイクルプロセスは，その目的及び望まれる成果に関して記述し
ており，これらの成果を達成するために実施すべきアクティビティ及びタスクを列挙している。
四つのプロセスグループ及び各グループに含まれるプロセスを図4に示す。この規格で記述されたプロ
セスは，組織が有用であるとした追加のプロセスの使用を排除又は阻止する意図はない。次に続く四つの
細分箇条で，各プロセスグループについて記述している。
20
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
システムライフサイクルプロセス
合意プロセス
取得プロセス
（6.1.1）
供給プロセス
（6.1.2）
組織のプロジェクト
イネーブリングプロセス
ライフサイクルモデル
管理プロセス
（6.2.1）
インフラストラクチャ
管理プロセス
（6.2.2）
ポートフォリオ
管理プロセス
（6.2.3）
人的資源管理プロセス
（6.2.4）
品質管理プロセス
（6.2.5）
テクニカルプロセス
利害関係者ニーズ及び
利害関係者要求事項定義
プロセス（6.4.2）
システム要求事項定義
プロセス（6.4.3）
アーキテクチャ定義
プロセス（6.4.4）
実装プロセス
（6.4.7）
インテグレーション
プロセス（6.4.8）
検証プロセス
（6.4.9）
移行プロセス
（6.4.10）
妥当性確認プロセス
（6.4.11）
運用プロセス
（6.4.12）
保守プロセス
（6.4.13）
廃棄プロセス
（6.4.14）
テクニカルマネジメント
プロセス
プロジェクト計画
プロセス（6.3.1）
プロジェクト
アセスメント及び制御
プロセス（6.3.2）
意思決定管理プロセス
（6.3.3）
リスク管理プロセス
（6.3.4）
構成管理プロセス
（6.3.5）
情報管理プロセス
（6.3.6）
測定プロセス
（6.3.7）
設計定義プロセス
（6.4.5）
システム分析プロセス
（6.4.6）
ビジネス又はミッション
分析プロセス（6.4.1）
知識管理プロセス
（6.2.6）
品質保証プロセス
（6.3.8）
図4−システムライフサイクルプロセス
5.6.2
合意プロセス
組織は，システムの生産者であり利用者でもある。製品又はサービスに対して，（取得者として行動する）
一つの組織は，（供給者として行動する）別の組織に仕事を課すことができる。これは，合意を用いて達成
される。
一般に，組織は，同時に又は順次にシステムの取得者及び供給者の両者として行動する。取得者及び供
給者が同一組織に属するときは余り形式ばらないで合意プロセスが使える。同様に，組織，プロジェクト
及び技術部門のそれぞれの責任について合意するために，組織内でも合意プロセスが使える。図4に，こ
のプロセスグループに含まれるプロセスの一覧を示す。
5.6.3
組織のプロジェクトイネーブリングプロセス
組織のプロジェクトイネーブリングプロセスは，プロジェクトが組織の関係者のニーズ及び期待を満た
21
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
すことができるように，必要な資源を提供することに関係している。組織のプロジェクトイネーブリング
プロセスは，一般的に戦略レベルにおいて次の三つに関係している。
− 組織のビジネス又は事業の管理及び改善
− 資源及び資産の準備及び配置
− 競合又は不確実な状況におけるリスク管理
組織のプロジェクトイネーブリングプロセスは，プロジェクトが遂行される環境を確立する。組織は，
次のことを行う。
− プロジェクトで使われるプロセス及びライフサイクルモデルを確立する。
− プロジェクトを確立する，又は方向転換するか，若しくは取り消す。
− 人的及び財政資源を含む必要資源を提供する。
− 内部及び外部顧客のためにプロジェクトによって開発されるシステム及び他の納入品目に対して品質
測定量を設定し，監視する。
組織のプロジェクトイネーブリングプロセスは，多くの組織に対してビジネスのために行うという強い
印象を与え，商用及び営利的な動機があることを示唆している。しかしながら非営利組織も，利害関係者
への説明責任があり，資源に対して責任があり，非営利活動におけるリスクにも遭遇する組織であるので，
組織のプロジェクトイネーブリングプロセスは，非営利組織にも同様に関係している。したがって，この
規格は，営利組織と同じように非営利組織にも適用できる。図4に，このプロセスのグループに含まれる
プロセスの一覧を示す。
5.6.4
テクニカルマネジメントプロセス
テクニカルマネジメントプロセスは，組織の管理者によって割り当てられた資源及び資産を管理するこ
と，並びに一つ以上の組織が行った合意を果たすために資源及び資産を適用することに関係している。
テクニカルマネジメントプロセスは，プロジェクトの技術面の作業に関係するが，特に次に関係する。
− コスト，期間の長さ及び達成に関して計画すること
− 計画及び達成度を示す実績基準を遵守することを確実なものにするよう助けるために，活動をチェッ
クすること
− 進捗及び達成における未達成の部分を取り戻す是正処置の識別及び選択すること
これらは，次のために利用する。
− プロジェクトのための技術面の計画の立案及び実施
− 技術チームを横断した情報の管理
− システム製品又はサービスの計画に対する技術面の進捗のアセスメント
− 完了までの技術的タスクの制御
− 意思決定プロセスにおける支援
注記1 テクニカルマネジメントは，“エンジニアリング機能を計画，整理及び制御するための技術的
及び管理的資源の適用”である（ISO/IEC/IEEE 24765:2010）。
一般的に，組織の中には，幾つかのプロジェクトが共存する。テクニカルマネジメントプロセスは，内
部のニーズを満たすために企業レベルで使うことができる。図4に，このプロセスグループに含まれるプ
ロセスの一覧を示す。
注記2 テクニカルマネジメントプロセスは，各テクニカルプロセスを実施している期間中に適用す
る。
22
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
5.6.5
テクニカルプロセス
テクニカルプロセスは，ライフサイクルを通して技術的活動に関係する。テクニカルプロセスは，利害
関係者のニーズを製品及びサービスに変換する。テクニカルプロセスは，その製品を適用するか，又はそ
のサービスを運用することによって，必要なときに必要な所で，現時点から将来にわたって持続的に，利
害関係者要求事項を満たし顧客満足を獲得できるようにする。テクニカルプロセスは，モデルとして表現
されたシステムであるか，完成品のシステムであるかにかかわらず，システムを開発して使用するために
適用する。テクニカルプロセスは，システム構造の階層のどのレベルにおいても，及びライフサイクルの
どの段階においても適用する。図4に，このプロセスグループに含まれるプロセスの一覧を示す。
5.7
プロセスの適用
この規格に定義したライフサイクルプロセスは，システムを取得，利用，創出又は供給するときに，ど
のような組織でも使用できるものである。ライフサイクルプロセスは，システムの階層のどのレベルでも，
ライフサイクルのどの段階でも適用できる。
これらのプロセスが実行する機能は，特定の目的，成果及びプロセスを構成するアクティビティ及びタ
スクの集合で構成される。
図4の各ライフサイクルプロセスは，ライフサイクルを通して，必要に応じて呼び出すことができる。
この規格でプロセスが記述されている順序は，プロセスを使用する順番を定めて指定したものではない。
しかしながら，プロセス相互の順序関係は，ライフサイクルモデルを定義することによって導入されるこ
とになる。ライフサイクルを通して，これらのプロセスの使用の詳細な目的及び時期は，次のような複数
の要因の影響を受ける。それは，システムの耐用寿命の期間中にいずれも変化するような，社会的，取引
上，組織上及び技術上の考慮である。したがって，個々のシステムライフサイクルは，同時並行的，反復
的，再帰的及び時間に依存する特性を定常的にもったプロセス群が複合したシステムとなる。
プロセスを同時並行して使用することは，一つのプロジェクト内でも行うことができるし（例えば，シ
ステム構築のための設計活動及び準備活動を同時に実行する場合），複数プロジェクト間でも行い得る（例
えば，複数のシステム要素を異なるプロジェクトの責任の下で同時に設計する場合）。
同一のプロセス又は同一のプロセス集合が同じシステムに繰り返し適用された場合，その適用は反復的
と呼ぶ。プロセスの反復的使用は，プロセスの出力を漸進的に洗練するために重要である。例えば，連続
的な検証活動と統合活動との間の相互作用は，製品の適合に関して信用を徐々に築くことができる。反復
は適切であるだけでなく，反復することが期待される。新しい情報が，プロセス又はプロセスの集合を適
用することによって生まれる。通常，この情報は，要求事項，分析されたリスク又は機会に関する質問
（question）の形態をとる。このような質問は，プロセス又はプロセスの集合のアクティビティを完了する
前までには回答を見つけて解決することが望ましい。
プロセスの再帰的使用は，すなわち，システムの構造の中にあるシステム要素の連続した階層レベルに
おける，同一のプロセス又は同一のプロセス集合の繰返し適用であり，この規格の適用の重要な側面であ
る。どのレベルでもプロセスの出力は，情報，成果物又はサービスのいずれかであり，（例えば，トップダ
ウンで設計する場合の）下位のレベル，又は（例えば，システムを組み上げて実現する場合の）上位のレ
ベルで使用されるプロセスへの入力となる。一つの適用から得られる成果は，システム構造の中の次の下
位（又は上位）のシステムの入力となり，下位における，より詳細な成果，又は上位における，より成熟
した成果の集合へ到達する。このような取組方法は，システム構造の中にある連続する各システムへ価値
を付加する。
システムへの影響は変化する性質があり（例えば，運用環境の変化，システム要素の実装に対する新し
23
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
い機会，組織内の変更された構造及び責任），そのことが，プロセスの使用の選択及び時期を継続的にレビ
ューすることを要求する。したがって，ライフサイクル内でのプロセスの使用は，システムに対する多く
の外部的影響に応じた，動的なものとなる。ライフサイクルの取組方法は，次の段階の中で変化を組み込
むことも可能にする。ライフサイクル段階が，理解可能で認識可能な高い抽象レベルの目的及び構成を提
供することによって，ライフサイクルにおける，動的なプロセス使用という複雑さを前にしたときにも，
ライフサイクルプロセスを立案，実行及び管理することをライフサイクル段階が支援する。ライフサイク
ル段階内のプロセスの集合は，その段階に対する完了基準，又はその段階内の正式な進捗レビューの開始
基準を満たす，共通の目標をもたせて適用される。
ここでのシステムのライフサイクルプロセスの反復的及び再帰的使用に関する記述は，対象システム，
イネーブリングシステム，組織又はプロジェクトに対して特定の階層的，垂直的又は水平的なシステム構
造をもたせようとする意図はない。
製品の品質リスクによって正当化される場合は，特定の製品で使用する中でプロセスを実際に実施する
ために具体化した，プロセスインスタンスについての詳細な記述を作成してもよい。プロセスのインスタ
ンス化では，プロセスインスタンスに対する，製品への要求事項から導き出された特定の成功基準を識別
すること，並びにこの規格のアクティビティ及びタスクから導き出された，成功基準の達成に必要な特定
のアクティビティ及びタスクを識別することを含む。プロセスインスタンスの詳細な記述を作成すること
で，プロセスと特定の製品要求事項との間の関連を確立することによって，製品の品質リスクのより良い
管理を実現できるようにする。
システムのライフサイクルプロセスの適用についての，こうした概念について，ISO/IEC/IEEE
24748-1:2018の手引に更なる詳細の記載がある。
5.8
プロセス参照モデル
附属書Cで，この規格の箇条6に記載した詳細な要求事項よりも抽象度を上げて“プロセス参照モデル”
（PRM）を定義している。PRMは，これらのプロセスの実施能力を調査決定するためにそのプロセスをア
セスメントする組織で適用できる。目的及び成果は，それぞれのプロセスを実施したときの実績について
の目標の記述である。この目標記述は，単なる適合性のアセスメントだけではなく，実施しているプロセ
スの有効性のアセスメントを可能にする。
注記 この規格では，”プロセス参照モデル”という用語は，JIS X 33002と同じ意味で使われている。
6
システムライフサイクルプロセス
6.1
合意プロセス（Agreement processes）
ここでは，組織の内外を含む複数の組織間の関係者による合意を確立するための要求事項を明記する。
合意プロセスは，次によって構成される。
a) 取得プロセス（Acquisition process）−製品又はサービスを取得する組織によって使用される。
b) 供給プロセス（Supply process）−製品又はサービスを供給する組織によって使用される。
これらのプロセスは，二つの組織の間での合意を確立するために必要なアクティビティを定義する。取
得プロセスを呼び出して実施すると，取得プロセスは，供給者と共にビジネスを遂行する手段を提供する。
これには，運用可能なシステムとして利用する製品の供給者，システムを運用するアクティビティを支援
するサービスの供給者，又はシステムを構成するシステム要素の供給者と共同してビジネスを遂行する手
段を含む場合がある。供給プロセスを呼び出して実施すると，供給プロセスは，その結果である取得者に
提供される製品又はサービスを，合意されたものにする手段を提供する。
24
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記 システムエンジニアリングにおいてセキュリティがますます関心事となっている。供給者との
関係についての情報セキュリティ，どのようにして供給者との関係における情報セキュリティ
を保つかについての供給者及び取得者のための要求事項及び手引については，ISO/IEC 27036
シリーズのセキュリティ技法を参照。供給者との関係についての情報セキュリティ特有の観点
が，第3部及び第4部で取り扱われている。
6.1.1
取得プロセス（Acquisition process）
6.1.1.1
目的
取得プロセスは，取得者の要求事項に従って，製品又はサービスを得ることを目的とする。
注記 このプロセスの一部として，変更依頼が取得者及び供給者の両方によって合意されたときに，
合意の修正が行われる。
6.1.1.2
成果
取得プロセスの実施に成功すると次の状態になる。
a) 供給依頼が準備されている。
b) 一つ以上の供給者が選定されている。
c) 取得者と供給者との間で合意が確立されている。
d) 合意に適合する製品又はサービスが受け入れられている。
e) 合意で定義された取得者の義務が満たされている。
6.1.1.3
アクティビティ及びタスク
取得者は，取得プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアクティビティ
及びタスクを実施しなければならない。
注記 このプロセスのアクティビティ及び結果としての合意は，下請負契約をしている供給者を含む
サプライチェーンの供給者に適用することがよくある。
a) 取得の準備を行う。このアクティビティは，次のタスクからなる。
1) 取得方法の戦略を定義する。
注記 この戦略では次を記述又は参照している。ライフサイクルモデル，リスク及び課題の軽減，
マイルストーンのスケジュール，並びに供給者が取得者の組織外であるときに供給者を選
定する基準。また，次のような，取得を駆動する重要事項及び特性も含む。責任及び法的
な義務，特定のモデル，手法又はプロセス，重大度のレベル，正式さ，並びに関連するト
レードオフ要因の優先度。
2) 要求事項を含む製品又はサービスの供給依頼を準備する。
注記1 供給者が外部の組織である場合，依頼には，供給者が遵守することを期待しているビジ
ネス上の行動規範，及び供給者の選定基準を含める。
注記2 一つ以上の供給者へ要求事項の定義を提供する。その要求事項は，利害関係者又はシス
テムの要求事項であって，関連する要求事項を定義するプロセスによるものであり，取
得への取組方法の種別に依存したものになる。
注記3 取得者は，要求事項を自ら開発するか，又は開発する供給者を雇用する。取得者が要求
事項を開発するためにも供給者を雇用する場合，取得者は，供給者が開発する要求事項
に対して承認する権限をもった者を擁立して保持する。
b) 取得を通知し供給者を選定する。このアクティビティは，次のタスクからなる。
1) 識別された供給者に対して，製品又はサービスの供給の依頼を伝達する。
25
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
2) 一つ以上の供給者を選定する。
注記 供給者から競争力のある提案書が得られる入札とするために，選定基準を適用して，供給
者の提案書を評価し比較する。個々の提案に対する評定の理由を明らかにし，選定された
理由又は選定されなかった理由を供給者に知らせる。
c) 合意を確立し維持する。このアクティビティは，次のタスクからなる。
注記 プロジェクトのコスト，スケジュール及び実績は，プロジェクトアセスメント及び制御プロ
セスによって監視される。合意の修正を必要とする全ての課題は，このアクティビティにも
ち込まれて扱われる。システム要素又は情報の変更提案は，構成管理プロセスの変更管理ア
クティビティによって制御される。
1) 受入れ基準を含む供給者との合意を作成する。
注記1 この合意は，書面による契約から口頭で了解された合意までの正式さに幅がある。正式
さのレベルに応じて，合意によって次の事項を確立する。要求事項，開発及び納入のマ
イルストーン，検証，妥当性確認及び受入れ条件，例外処理手順，合意の変更管理手順，
並びに支払いスケジュール。その結果，合意する双方の当事者が，合意を実行するため
の基本的事項を理解することになる。技術的データ及び知的財産に関する権利及び制約
は，合意事項として記載される。詳細事項が交渉の中で議論されて変更され，その後，
取得者及び供給者はその合意された条項を受け入れ，合意を開始する。書面による契約
では，これは契約への署名なつ（捺）印時に行われる。
注記2 参加している下請負契約している各供給者に対して，適用する必要があるプロセス要求
事項を識別するように合意する。そうしたプロセス要求事項には，構成管理の要求事項，
リスクの報告，並びに測定量及び測定分析についての報告がある。
2) 合意についての必要な変更を識別する。
注記 合意に対する変更依頼では，取得者又は供給者は，その変更の規定内容，論理的根拠，及
び背景を詳述する。
3) 合意の変更による影響を評価する。
注記 いずれの変更についても，プロジェクト計画，スケジュール，コスト，技術的能力，及び
品質への影響を調査する。合意の変更は，既存の合意の中で扱うか，合意の修正を要求す
るか，又は新しい合意を要求することができる。
4) 供給者と合意を取り付ける交渉をする。
注記 合意の条項を，取得者と供給者との間で交渉する。交渉は，初期の合意，及び何らかの変
更のために要求されたときの合意に対して行う。変更された合意は，要求された変更，及
び識別された変更の影響に基づいたものとなる。
5) 必要に応じて，供給者と共に合意を更新する。
注記 合意の修正の結果は，プロジェクト計画に組み込まれ，全ての影響する当事者へ連絡され
る。
d) 合意を監視する。このアクティビティは，次のタスクからなる。
1) 合意の実行をアセスメントする。
注記 これには，全ての当事者の合意に従って責任を果たしていることの確認を含む。プロジェ
クトアセスメント及び制御プロセスが，見積もられたコスト，スケジュール，実績，及び
望ましくない結果となった成果が組織に及ぼす影響を評価するために用いられる。この情
26
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
報は，合意の条項の実行のアセスメントと統合される。
2) 適切な時機を逃さない方法で，供給者が必要とするデータを提供し，課題を解決する。
e) 製品又はサービスを受け入れる。このアクティビティは，次のタスクからなる。
1) 納入される製品又はサービスが合意を遵守していることを確認する。
注記 合意の実施中に生じた例外又は納入される製品若しくはサービスに起因する例外は，合意
で確立された手順に従って解決される。
2) 支払金又はそれに代わる合意した対価を提供する。
3) 合意によって指示されたように，供給者又は他の当事者から，製品又はサービスを受け入れる。
4) 合意を終了する。
注記 プロジェクトは，ポートフォリオ管理プロセスによって終了される。
6.1.2
供給プロセス（Supply process）
6.1.2.1
目的
供給プロセスは，合意された要求事項に合致した製品又はサービスを取得者に提供することを目的とす
る。
注記 このプロセスの一部として，変更依頼が取得者及び供給者の両者によって合意されたときに，
合意の修正が行われる。
6.1.2.2
成果
供給プロセスの実施に成功すると次の状態になる。
a) 製品又はサービスの取得者が識別されている。
b) 取得者の依頼への回答が行われている。
c) 取得者と供給者との間で合意が確立されている。
d) 製品又はサービスが提供されている。
e) 合意で定義された供給者の義務が満たされている。
f)
合意によって指示されたとおり，取得された製品又はサービスに対する責任が移転されている。
6.1.2.3
アクティビティ及びタスク
供給者は，供給プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアクティビティ
及びタスクを実施しなければならない。
a) 供給の準備を行う。このアクティビティは，次のタスクからなる。
1) 製品又はサービスへのニーズをもつ取得者の存在を調査決定し，取得者を識別する。
注記 これは，ビジネス又はミッション分析プロセスを通じて行われる。消費者のために開発さ
れる製品又はサービスについては，代理者，例えば，供給組織内の市場調査部門が，取得
者を代表することがよくある。
2) 供給の戦略を定義する。
注記 この戦略では次を記述又は参照する。ライフサイクルモデル，リスク及び問題の軽減策，
並びにマイルストーンのスケジュール。また，次のような，取得を駆動する重要事項及び
特性も含む。責任及び債務，特定のモデル，手法又はプロセス，重大度のレベル，正式さ，
並びに関連するトレードオフ要因の優先度。
b) 入札への対応を行う。このアクティビティは，次のタスクからなる。
1) 実現可能性及び対応回答の仕方を決定するため，製品又はサービスの供給依頼を評価する。
2) 提案による入札の要請を満たす回答の準備をする。
27
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
c) 合意を確立し維持する。このアクティビティは，次のタスクからなる。
1) 受入れ基準を含む合意を取得者と取り付ける交渉をする。
注記 この合意には，書面による契約から口頭で了解された合意までの正式さに幅がある。供給
者は，要求事項，納入マイルストーン及び受入れ条件が達成可能であること，例外処理手
順，合意の変更管理手順及び支払いスケジュールが受入れ可能であること，並びに不要な
リスクを伴わずに合意を実施できる基礎を確立することを確認する。課題は全て交渉の中
で議論され解決される。その後，取得者及び供給者はその合意の条項を受け入れ，合意を
開始する。書面による契約では，これは契約への署名なつ（捺）印時に行われる。
2) 合意についての必要な変更を識別する。
注記 合意に対する変更依頼では，取得者又は供給者は，その変更の内容記述，根拠，及び背景
を詳述する。
3) 合意の変更による影響を評価する。
注記 いずれの変更についても，プロジェクト計画，スケジュール，費用，技術的可能性，又は
品質への影響を調査する。合意の変更は，既存の合意の中で扱うか，合意の修正を要求す
るか，又は新しい合意を要求することができる。
4) 取得者と合意を取り付ける交渉をする。
注記 合意における，いずれの条項への変更も，供給者と取得者との間で交渉する。これは，変
化する市場の状況による変更を含む。交渉は，初期の合意，及び何らかの変更のために要
求されたときの合意に対して行う。変更された合意は，要求された変更，及び識別された
変更の影響に基づいたものとなる。
5) 必要に応じて，取得者と共に合意を更新する。
注記 合意の修正の結果は，プロジェクト計画に組み込まれ，全ての影響する当事者に連絡され
る。
d) 合意を実行する。このアクティビティは，次のタスクからなる。
1) 確立したプロジェクト計画に従って合意を実行する。
注記 供給者は，取得者のプロセスを採用，又は使用することに合意することがある。
2) 合意の実行をアセスメントする。
注記 これは，全ての当事者が，その合意に従った責任を果たしていることを確認することを含
んでいる。プロジェクトアセスメント及び制御プロセスが，計画された費用，スケジュー
ル，実績，及び望ましくない結果となった成果が組織に及ぼす影響を評価するために用い
られる。構成管理プロセスにおける変更管理アクティビティは，システム要素の変更を制
御するために使用される。この情報は，合意の条項の実行のアセスメントと統合される。
e) 製品又はサービスを納入・提供し支援する。このアクティビティは，次のタスクからなる。
1) 合意基準に従って製品又はサービスを納入・提供する。
2) それぞれの合意について，納入・提供した製品又はサービスを支援して，取得者を援助する。
3) 支払金又はそれに代わる合意した対価を受け取る。
4) 合意によって指示されたように，製品又はサービスを取得者又は他の当事者へ引き渡す。
5) 合意を終了する。
注記 プロジェクトは，ポートフォリオ管理プロセスによって終了される。
28
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
6.2
組織のプロジェクトイネーブリングプロセス（Organizational project-enabling processes）
組織のプロジェクトイネーブリングプロセスは，プロジェクトの立上げ，支援及び制御を通じて，製品
又はサービスを取得又は供給するための組織の能力を，確実なものにするよう援助する。このプロセスは，
プロジェクトを支援するために必要な資源及びインフラストラクチャを提供し，組織の目標及び確立され
た合意を確実に満たすよう援助する。この組織のプロジェクトイネーブリングプロセスは，組織のビジネ
スを戦略的に管理できるようにする広範なビジネスプロセスの集合を意図したものではない。
組織のプロジェクトイネーブリングプロセスは，次によって構成される。
a) ライフサイクルモデル管理プロセス（Life Cycle Model Management process）
b) インフラストラクチャ管理プロセス（Infrastructure Management process）
c) ポートフォリオ管理プロセス（Portfolio Management process）
d) 人的資源管理プロセス（Human Resource Management process）
e) 品質管理プロセス（Quality Management process）
f)
知識管理プロセス（Knowledge Management process）
6.2.1
ライフサイクルモデル管理プロセス（Life Cycle Model Management process）
6.2.1.1
目的
ライフサイクルモデル管理プロセスは，この規格の適用範囲に関して，組織によって使われる方針，ラ
イフサイクルプロセス，ライフサイクルモデル及び手順を定義し，維持し，アベイラビリティを保証する
ことを目的とする。
このプロセスは，次の内容をもつライフサイクルの方針，プロセス及び手順を提供する。
− 組織の目標との一貫性をもっている。
− 組織内でプロジェクトを行う状況で，個々のプロジェクトのニーズに応えるために，定義，適用，改
善及び保守がなされている。
− 効果的で，証明済みの方法及びツールを使用して適用できる。
6.2.1.2
成果
ライフサイクルモデル管理プロセスの実施に成功すると次の状態になる。
a) ライフサイクルモデル及びプロセスの，管理及び展開のための組織的な方針及び手順が確立されてい
る。
b) ライフサイクルの方針，プロセス，モデル及び手順の中で，責任，説明責任及び権限が定義されてい
る。
c) 組織が使用するライフサイクルモデル及びプロセスがアセスメントされている。
d) プロセス，モデル及び手順の改善が順位付けられて行われている。
6.2.1.3
アクティビティ及びタスク
組織は，ライフサイクルモデル管理プロセスに関する，適用可能な組織の方針及び手順に従って，次に
示すアクティビティ及びタスクを実施しなければならない。
a) プロセスを確立する。このアクティビティは，次のタスクからなる。
注記 プロジェクト内のライフサイクル実施の細部は，作業の複雑さ，用いられる手法，作業遂行
に参加する要員のスキル（技能）及び教育訓練に依存する。プロジェクトは，規制及び組織
の方針との一貫性を維持しながら，プロジェクトへの要求事項及びニーズに応じて方針，プ
ロセス，モデル及び手順を修整する。修整に関する情報は附属書Aに含まれる。
1) 組織の戦略との一貫性をもったプロセス管理及び展開のための方針及び手順を確立する。
29
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
2) この規格の要求事項を実施し，組織の戦略との一貫性をもったプロセスを確立する。
3) ライフサイクルのプロセスの実施及びライフサイクルの戦略的な管理を可能にする役割，責任，説
明責任及び権限を定義する。
4) ライフサイクルを通して進捗を制御するビジネス上の基準を定義する。
注記 各ライフサイクル段階及び主要なマイルストーンの開始及び終了に関する意思決定基準が
確立される。これらはビジネスの達成という観点で表現されることがある。
5) 複数の段階で構成される標準のライフサイクルモデルを組織のために確立し，各段階の目的及び成
果を定義する。
注記 ライフサイクルモデルは，必要に応じて，一つ以上の段階に分けたモデルから構成する。
ライフサイクルモデルは，対象システムの範囲，規模，複雑さ，変化するニーズ及び機会
に対して適切なものとなるように，同時並行又は反復する一連の段階として組み立てる。
ISO/IEC/IEEE 24748-1:2018で，ライフサイクル段階の通常見られる例を用いて，段階を説
明している。システムに対する特定の例は，ISO/IEC/IEEE 24748-2:2018に掲載されている。
その段階の目的及び成果を満たすように，ライフサイクルプロセス及びアクティビティを
選択し，適切に修整して，その段階で用いる。
b) プロセスのアセスメントを行う。このアクティビティは，次のタスクからなる。
注記 JIS X 0145規格群及びJIS X 33000規格類は，プロセスアセスメントの一連のより詳細なア
クティビティ及びタスクを記載しており，それらは次に示されるタスクに沿っている。
1) 組織全体にわたってプロセスの実行を監視する。
注記 これには，プロセス測定量を分析しビジネス上の基準に照らして傾向をレビューすること，
プロセスの有効性及び効率に関してプロジェクトからフィードバックすること，並びに規
制及び組織の方針に従った実行を監視することを含む。
2) プロジェクトで使用されるライフサイクルモデルの定期的なレビューを実施する。
注記 これには，各プロジェクトで使用されているライフサイクルモデルが合目的性，必要十分
性及び有効性を持続していることを確認し，適切に改善することを含む。これは，ライフ
サイクルを通じて進捗を制御する，段階，プロセス及び達成の基準の確認も含む。
3) アセスメントの結果から改善の機会を識別する。
c) プロセスを改善する。このアクティビティは，次のタスクからなる。
1) 改善の機会を優先順位付け，計画する。
2) 改善の機会について改善を実施し，直接関係する利害関係者に伝達する。
注記 プロセスの改善には，組織内のどのようなプロセスでの改善も含む。学んだ教訓を記録に
残る形にして集め，利用可能にする。
6.2.2
インフラストラクチャ管理プロセス（Infrastructure Management process）
6.2.2.1
目的
インフラストラクチャ管理プロセスは，ライフサイクルを通して組織及びプロジェクトの目標を支援す
るために，インフラストラクチャ及びサービスをプロジェクトに提供することを目的とする。
このプロセスは，この規格の適用範囲に関して，組織の業務に必要な施設，ツール及び情報通信技術の
資産を定義し，提供し，維持する。
6.2.2.2
成果
インフラストラクチャ管理プロセスの実施に成功すると次の状態になる。
30
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
a) インフラストラクチャに対する要求事項が定義されている。
b) インフラストラクチャ要素は識別され，仕様が規定されている。
c) インフラストラクチャ要素が開発されているか又は取得されている。
d) インフラストラクチャが利用可能になっている。
6.2.2.3
アクティビティ及びタスク
組織は，インフラストラクチャ管理プロセスに関する，適用可能な組織の方針及び手順に従って，次に
示すアクティビティ及びタスクを実施しなければならない。
a) インフラストラクチャを確立する。このアクティビティは，次のタスクからなる。
1) プロジェクトのインフラストラクチャの要求事項を定義する。
注記1 インフラストラクチャ要素の例は，設備，ツール，ハードウェア，ソフトウェア，サー
ビス，標準である。
注記2 組織の方針及び戦略的計画と同様に，プロジェクトに対するインフラストラクチャの資
源のニーズを組織内の他のプロジェクト及び資源との関連で考慮する。プロジェクトへ
のインフラストラクチャの資源及びサービスの提供に影響を及ぼし，かつ，制御するよ
うな，ビジネス上の制約及び適時性をも評価する。プロジェクト計画及び将来のビジネ
スに関するニーズは，要求される資源のインフラストラクチャの理解に寄与する。施設
などの物理的要因，ロジスティクスのニーズ，並びに健康及び安全面を含む人的要因も
また考慮する。
注記3 供給者に対する情報セキュリティに関するISO/IEC 27036シリーズは，外部へ委託した
インフラストラクチャのセキュリティに対処するための手引を提供する。
2) プロジェクトを実施し，支援するために必要なインフラストラクチャの資源及びサービスを識別し，
獲得し，提供する。
注記 インフラストラクチャ要素の追跡及び再利用の援助のため，所有資産を一覧した登記保管
が確立されることがよくある。
b) インフラストラクチャを維持する。このアクティビティは，次のタスクからなる。
1) 納入されたインフラストラクチャ資源がプロジェクトのニーズを満たす度合いを評価する。
2) プロジェクトの要求事項が変化するに従って，インフラストラクチャの資源への改善又は変更を識
別し，提供する。
6.2.3
ポートフォリオ管理プロセス（Portfolio Management process）
6.2.3.1
目的
ポートフォリオ管理プロセスは，組織の戦略的な目標を満たすために必要十分かつ適切なプロジェクト
を開始し，維持することを目的とする。
このプロセスは，組織の資金及び資源の適切な投入を確約し，選ばれたプロジェクトを立ち上げて確立
するために必要な権限を認可する。これは，投入を継続することに値することを確認するため，又は値す
るように軌道修正できることを確認するために，継続してアセスメントを実施する。
6.2.3.2
成果
ポートフォリオ管理プロセスの実施に成功すると次の状態になる。
a) ビジネスベンチャーの機会，投資又は必要性が適格であると認められ，優先順位付けされている。
b) 複数のプロジェクトが識別されている。
c) 各プロジェクトに対して資源及び予算が割り当てられている。
31
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
d) プロジェクト管理の責任，説明責任及び権限が定義されている。
e) 合意及び利害関係者要求事項を満たすプロジェクトは維持されている。
f)
合意に合致しない又は利害関係者要求事項を満足しないプロジェクトは，軌道修正又は中止されてい
る。
g) 合意を完遂し，利害関係者要求事項を満たしたプロジェクトは，終了されている。
6.2.3.3
アクティビティ及びタスク
組織は，ポートフォリオ管理プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すア
クティビティ及びタスクを実施しなければならない。
a) 複数のプロジェクトからなるプロジェクト群を定義し認可する。このアクティビティは，次のタスク
からなる。
1) 潜在的な，新規の又は修正された，能力又はミッションを識別する。
注記 組織のビジネス戦略，組織レベルの運用概念，又はギャップ分析若しくは機会分析が，現
状におけるギャップ，問題又は機会に対してレビューされ見直される。新規の能力又は事
業に求められるニーズは，ビジネス及びミッション分析プロセスの中で通常は決定され，
さらに，利害関係者ニーズ及び利害関係者要求事項の定義プロセスの中で定義され，この
プロセスを通じて管理される。
2) 新規ビジネスの機会，ビジネスベンチャーの機会，又は取組み中のビジネスを優先順位付けし，選
択し，立ち上げて確立する。
注記 これらはビジネス戦略及び組織の行動計画と通常は一貫性をもっている。実施する可能性
のある候補である，潜在的な複数のプロジェクトは，どのプロジェクトを実行に移すかを
決定するため，優先順位付けされ，しきい（閾）値が確立される。成功に対する利害関係
者の価値，成功を妨げるリスク及び障害，依存関係及び内部関係，制約，資源のニーズ，
並びに資源間の相互の競合を含む特性を，識別されたプロジェクトの特性として調査し決
定することがよくある。各々の潜在的なプロジェクトは成功の可能性及び費用対利益・便
益に関して評価される。意思決定管理プロセス及びシステム分析プロセスで，代替案の分
析を遂行する上での詳細を記載している。
3) 複数のプロジェクトからなるプロジェクト群，説明責任及び権限を定義する。
4) 各プロジェクトに期待される最終目標となるゴール，目標及び成果を識別する。
5) プロジェクトのゴール及び目標を達成するための資源を識別し，割り当てる。
6) プロジェクトによって管理又は支援されるべき，複数プロジェクト間のインタフェース及び依存関
係の全てを識別する。
注記1 これは，複数のプロジェクトによって使われるイネーブリングシステムの利用又は再利
用，及び複数のプロジェクトによって使われる共通のシステム要素の利用又は再利用を
含む。
注記2 事業アーキテクチャの中に位置付けて個々のプロジェクトを理解することで，インタフ
ェース及び制約を識別することを確実にする。
7) 各プロジェクトの実行を統制する，プロジェクト報告の要求事項，及び節目となるレビューによる
マイルストーンを規定する。
8) 各プロジェクトに対し，プロジェクト計画の実行を開始する権限を与える。
注記 プロジェクト計画の策定に関する更なる情報についてはプロジェクト計画プロセスを参照
32
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
する。プロジェクト計画は，プロジェクトライフサイクルの早い段階で策定され，かつ，
承認される場合，最も有用である。
b) プロジェクトのポートフォリオを評価する。このアクティビティは，次のタスクからなる。
1) 現在進行中のプロジェクトの存続可能性を確認するため，プロジェクトを評価する。
注記 存続可能性には次が含まれる。
− プロジェクトは，設定されたゴール及び目標の達成に向かって進行している。
− プロジェクトは，プロジェクト指示書を遵守している。
− プロジェクトは，システムライフサイクルの方針，プロセス及び手順に従って実行さ
れている。
− プロジェクトは，存続可能であり続けている。それは，例えば，サービスの継続的ニ
ーズ，実用的な製品の実装，及び受入れ可能な投資利益で示されている。
2) 満足できるように進行しているプロジェクトを継続する，又は適切な軌道修正があれば満足できる
ように進行すると期待できるプロジェクトに対して軌道修正するために行動する。
c) プロジェクトを終了させる。このアクティビティは，次のタスクからなる。
1) 合意によって認められている場合には，組織に対する不利益又はリスクが継続的な投資で得られる
利益・便益を上回るプロジェクトを，取り消すか又は中断するために行動する。
2) 製品及びサービスの合意が完遂された後，プロジェクトを終了するために行動する。
注記 プロジェクトの終了は，組織の方針及び手順，並びに合意に従って成し遂げられる。
6.2.4
人的資源管理プロセス（Human Resource Management process）
6.2.4.1
目的
人的資源管理プロセスは，組織に必要な人的資源を提供し，ビジネスニーズに見合った能力を要員が維
持することを目的とする。
このプロセスは，組織，プロジェクト及び利害関係者の目標を達成するために，ライフサイクルプロセ
スを実行する資格のある，スキル（技能）及び経験のある要員の供給を行う。
6.2.4.2
成果
人的資源管理プロセスの実施に成功すると次の状態になる。
a) プロジェクトで要求されるスキルが識別されている。
b) プロジェクトに必要な人的資源が供給されている。
c) 要員のスキルが，開発され，維持され，又は強化されている。
d) 複数プロジェクト間の人的資源要求の重複又は競合が解決されている。
6.2.4.3
アクティビティ及びタスク
組織は，人的資源管理プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアクティ
ビティ及びタスクを実施しなければならない。
a) スキルを識別する。このアクティビティは，次のタスクからなる。
1) 現在及び予期されるプロジェクトに基づくスキルのニーズを識別する。
2) 要員のスキルを識別し，記録する。
b) スキルを開発する。このアクティビティは，次のタスクからなる。
1) スキルの開発戦略を確立する。
注記 この計画は，教育訓練の種類及びレベル，要員の区分，スケジュール，要員の人的資源へ
の要求事項，及び教育訓練のニーズを含む。
33
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
2) 教育訓練，専門教育又は個人指導を行う資源を，獲得又は開発する。
注記 これらの資源は，組織，又は組織外の業者若しくは教育関係者によって開発される教材，
組織外の供給者から提供される教育訓練コース，コンピュータを使用した個別学習などを
含む。
3) 計画されたスキル開発を提供する。
4) スキル開発の記録を維持する。
c) スキルを取得し提供する。このアクティビティは，次のタスクからなる。
注記 このアクティビティは，次を含む。
− プロジェクトの適切な要員配備に必要な経験のレベル及びスキルを備えた人員の採用及
びその保持
− 例えば，熟練度，やる気（モチベーション），チーム環境で働く能力，さらに，再教育訓
練，配置転換又は再配置のニーズなどについての要員のアセスメント及びレビュー
1) スキルの不足が識別されたときは適格性のある有資格者を要員として獲得する。
注記 これには外部委託先の人的資源を含む。
2) 進行中のプロジェクトに配置するために，共用できるようにして確保した必要なスキルのある要員
を，維持し管理する。
3) プロジェクト及び要員開発のニーズに基づいてプロジェクトの配属を行う。
4) 要員を動機付ける。例えば，キャリア開発及び報奨制度によって動機付ける。
5) 複数プロジェクト管理インタフェースを制御して，要員の重複競合問題を解決する。
注記 これには，進行中のプロジェクト群における，組織のインフラストラクチャ及び支援サー
ビスの容量，並びに要員資源の許容量についての重複若しくは競合の問題，又はプロジェ
クト要員が過度に作業に従事していることによる重複若しくは競合の問題を含む。
6.2.5
品質管理プロセス（Quality Management process）
6.2.5.1
目的
品質管理プロセスは，製品，サービス及び品質管理プロセスの実施が組織及びプロジェクトの品質目標
に合致し，顧客満足を達成することを保証することを目的とする。
6.2.5.2
成果
品質管理プロセスの実施に成功すると次の状態になる。
a) 組織の品質管理の方針，目標及び手順が定義され，実施されている。
b) 品質評価の基準及び評価方法が確立されている。
c) プロジェクトの品質保証活動アクティビティの運用及び監視を支援するために，資源及び情報がプロ
ジェクトに提供されている。
d) 品質保証の評価結果が収集され，分析されている。
e) 品質管理の方針及び手順は，プロジェクト及び組織の結果に基づいて改善されている。
注記 これらの成果は，JIS Q 9001で規定している要求事項に沿ったものである。品質マネジメン
トシステムの確立についての情報は，JIS Q 9001を参照。
6.2.5.3
アクティビティ及びタスク
組織は，品質管理プロセスに関して，適用可能な組織の方針及び手順に従って，次のアクティビティ及
びタスクを実施しなければならない。
a) 品質管理を計画する。このアクティビティは，次のタスクからなる。
34
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
1) 品質管理方針，品質管理目標及び品質管理手順を確立する。
注記1 JIS Q 9001は，品質マネジメントシステムについてのプロセスモデルであり，JIS Q 9004
では実績の改善のための指針について言及している。
注記2 品質管理方針，品質管理目標及び品質管理手順は，顧客満足のためのビジネス戦略に基
づいている。
2) 品質管理の実施に対する責任及び権限を定義する。
注記 多くの場合，品質管理のための資源は，プロジェクト管理からの独立性のために，プロジ
ェクト管理とは異なる組織から割り当てられる。
3) 品質評価基準及び品質評価方法を定義する。
4) 品質管理のための資源及び情報を提供する。
b) 品質管理のアセスメントを行う。このアクティビティは，次のタスクからなる。
1) 定義された基準に従って，品質保証における評価結果を収集し，分析する。
2) 顧客満足度をアセスメントする。
注記 ISO 10004:2012には，顧客満足度を監視及び測定するための指針が含まれている。
3) 品質管理方針，品質管理目標及び品質管理手順の順守のために，プロジェクト品質保証活動の定期
的なレビューを実施する。
4) プロセス，製品及びサービスの品質改善状況を監視する。
c) 品質管理の是正処置及び予防処置を実施する。このアクティビティは，次のタスクからなる。
1) 品質管理目標が達成されない場合に是正処置を計画する。
2) 品質管理目標が達成されないリスクが十分ある場合，予防処置を計画する。
3) 是正処置及び予防処置を完了まで監視し，関係する利害関係者に通知する。
注記 是正処置及び予防処置の実施は，ライフサイクルモデル管理プロセス，プロジェクトアセ
スメント及び制御プロセスなどの他の関連プロセスで実施される。
6.2.6
知識管理プロセス（Knowledge Management process）
6.2.6.1
目的
知識管理プロセスは，組織が既存の知識を再適用する機会を活用できる能力及び資産を開発することを
目的とする。
知識管理プロセスは，その対象として，知識，スキル（技能）及び知識資産を含み，システム要素も含
む。
6.2.6.2
成果
知識管理プロセスの実施に成功すると次の状態になる。
a) 知識資産の適用のための分類法が識別されている。
b) 組織の知識，スキル及び知識資産が開発又は取得されている。
c) 組織の知識，スキル及び知識資産が利用可能になっている。
d) 知識管理利用のデータが収集されて分析されている。
6.2.6.3
アクティビティ及びタスク
組織は，知識管理プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアクティビテ
ィ及びタスクを実施しなければならない。
a) 知識管理を計画する。このアクティビティは，次のタスクからなる。
1) 知識管理の戦略を定義する。
35
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記1 一般に，知識管理の戦略は次を含む。
− 知識の再適用を目指す領域，及びそれらの領域で知識を再適用する可能性の識別
− 知識，スキル及び知識資産を獲得して，それらが有用であるように維持する計画
− 収集されて維持される知識，スキル及び知識資産の種別の特徴付け
− 知識，スキル及び知識資産の受入れ，適格性及び取下げを判断する基準
− 知識，スキル及び知識資産の変更を制御する手順
− 極秘又は機密データの保護，制御及びアクセスのための計画，仕組み及び手順
− 蓄積及び検索の仕組み
注記2 知識管理は，組織内で内部的に共有される知識，並びに知的財産及び守秘義務の合意に
従って，利害関係者，取得者及びビジネスパートナーと共に組織外で共有される知識を
含む。
2) 管理される知識，スキル及び知識資産を識別する。
3) 知識，スキル及び知識資産の適用から利益を得ることができるプロジェクトを識別する。
b) 組織全体で知識及びスキルを共有する。このアクティビティは，次のタスクからなる。
1) 組織全体で，知識及びスキルを捕捉し，（形あるものに）記録・保存して共有するための分類を確立
して維持する。
注記 分類は，専門，一般共通及び領域別の知識及びスキル，並びに学習された教訓を含む。
2) 知識及びスキルを組織が自ら捕捉し確保するか又は他から取得する。
3) 組織全体で知識及びスキルを共有する。
c) 組織全体で知識資産を共有する。このアクティビティは，次のタスクからなる。
1) 知識資産を体系化するための分類法を確立する。
注記1 分類法は次を含む。
− 領域の境界及びそれらの他との関係の定義
− 必須で共通の特徴，能力，概念及び機能，並びに異なる特徴，能力，概念及び機能
を，捕捉して（形あるものに）記録・保存する領域モデル
− 領域内のシステム群に向けた，共通の特徴及び異なる特徴を含むアーキテクチャ
注記2 プロダクトラインモデルの詳細についてはISO/IEC 26550を参照。アーキテクチャのフ
レームワーク，ビューポイント，モデル種別，ビュー及びモデルに関する要求事項は
ISO/IEC/IEEE 42010を参照。
2) 知識資産を開発又は取得する。
注記 知識資産は，教訓及び次を含む。
− システム要素又はそれらを表現したもの（例えば，再利用可能なコードのライブラリ，
参照されるアーキテクチャ）
− アーキテクチャ又は設計の要素（例えば，アーキテクチャ パターン又はデザインパタ
ーン）
− プロセス
− 基準
− 領域についての知識に関連する，その他の技術情報（例えば，教育訓練用の教材）
3) 組織全体で知識資産を共有する。
d) 知識，スキル及び知識資産を管理する。このアクティビティは，次のタスクからなる。
36
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
1) 知識，スキル及び知識資産を維持する。
2) 知識，スキル及び知識資産の利用を監視して記録する。
3) 定期的に，技術の動向及び知識資産の市場ニーズを再度アセスメントする。
6.3
テクニカルマネジメントプロセス（Technical management processes）
テクニカルマネジメントプロセスは，計画を確立し発展させ，計画を実行し，計画に対する実績及び進
捗のアセスメントを行い，達成するまで，実行を制御するために用いられる。個々のテクニカルマネジメ
ントプロセスは，計画又は予期しないイベントによって要求されることになれば，ライフサイクルのどの
時点でも，また，プロジェクトにおける階層レベルのどのレベルにおいても実行してもよい。テクニカル
マネジメントプロセスは，プロジェクトのリスク及び複雑性に応じた厳密さ及び正式さを伴うように適用
される。
テクニカルマネジメントプロセスの範囲は，システムを含む，プロジェクトの技術面の管理又はそのプ
ロジェクトの製品の技術面の管理である。
注記 この一連のテクニカルマネジメントプロセスは，システムに特有なテクニカルプロセスを効果
的に実行できるように実施される。これらテクニカルマネジメントプロセスは，システム管理
又はプロジェクト管理のための一連のプロセス全てを包括的に含んだものではなく，それはこ
の規格の適用範囲外である。
テクニカルマネジメントプロセスは，次によって構成される。
a) プロジェクト計画プロセス（Project Planning process）
b) プロジェクトアセスメント及び制御プロセス（Project Assessment and Control process）
c) 意思決定管理プロセス（Decision Management process）
d) リスク管理プロセス（Risk Management process）
e) 構成管理プロセス（Configuration Management process）
f)
情報管理プロセス（Information Management process）
g) 測定プロセス（Measurement process）
h) 品質保証プロセス（Quality Assurance process）
プロジェクト計画プロセス，並びにプロジェクトアセスメント及び制御プロセスは，あらゆる管理を実
践するための鍵となっている。これらのプロセスは，プロジェクト又はプロセスを管理するための共通し
た取組方法を確立する。このプロセスグループに含まれる他のプロセスは，それぞれに特化した管理目標
を遂行するために特定の焦点を当てた一連のタスクを提供する。それらは，組織全体から単一のライフサ
イクルプロセス及びそのタスクに至るまでの，様々な取組みの管理において全て明らかにされる。この規
格では，プロセス群を記述する中で，プロジェクトという表現を用いているが，サービスの遂行において
も同じプロセス群を適用できる。
6.3.1
プロジェクト計画プロセス（Project Planning process）
6.3.1.1
目的
プロジェクト計画プロセスは，効果的で実行可能な計画を作成し，調整することを目的とする。
このプロセスは，プロジェクト管理及びテクニカルプロセスのアクティビティの範囲を決定し，プロセ
スの出力，プロジェクトのタスク及び納入物を識別し，達成基準を含むプロジェクトのタスク実施のスケ
ジュール及びプロジェクトのタスクを達成するために要求される資源を確立する。これは，計画の定期的
な改訂によって，プロジェクト全体を通して進行し続けるプロセスである。
注記 他のプロセスの各プロセスの中で定義された戦略は，プロジェクト計画プロセスへの入力を提
37
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
供し，かつ，プロジェクト計画プロセスの中に統合される。計画が統合されたものになってお
り，整合化されており，かつ，実現可能なものになっているかをアセスメントするために，プ
ロジェクトアセスメント及び制御プロセスが用いられる。
6.3.1.2
成果
プロジェクト計画プロセスの実施に成功すると次の状態になる。
a) 目標及び計画が定義されている。
b) 役割，責任，説明責任及び権限が定義されている。
c) プロジェクト目標を達成するのに必要な資源及びサービスが正式に依頼され，確約されている。
d) プロジェクト実行のための計画が作成されて用いられている。
6.3.1.3
アクティビティ及びタスク
プロジェクトは，プロジェクト計画プロセスに関する，適用可能な組織の方針及び手順に従って，次に
示すアクティビティ及びタスクを実施しなければならない。
a) プロジェクトを定義する。このアクティビティは，次のタスクからなる。
1) プロジェクトの目標及び制約条件を明確にする。
注記1 目標及び制約条件は，システムの遂行能力・性能・運用時の実績及び他の品質側面，コ
スト，時間並びに顧客の満足を含む。各目標は，適切なプロセス及びアクティビティの
選定，修整及び実施が可能な程度の詳細に識別される。
注記2 ISO/IEC 15026シリーズは，システム及びソフトウェアのアシュアランスに関して，及
びISO/IEC 27036シリーズは，供給者との関係に対する情報セキュリティに関して，目
標及び制約条件の追加の手引を提供する。
注記3 ISO/IEC 15026シリーズのうち，第2部はJIS X 0134-2も参照できる。
2) 合意を確立するためのプロジェクトの適用範囲を定義する。
注記 プロジェクトには，ビジネスの意思決定基準を満たしプロジェクトを成功裏に完了させる
ために要求される全ての関連アクティビティを含む。プロジェクトは，システムライフサ
イクル全体の中の一つ以上の段階の責任をもつことができる。計画には，プロジェクト計
画を維持し，アセスメントを実施し，プロジェクトを制御するための適切な行動を含む。
3) 組織の定義されたライフサイクルモデルを用いた段階から構成されるライフサイクルモデルを定義
し，維持する。
注記 ISO/IEC/IEEE 24748-1:2018が，ライフサイクル段階及び適切なライフサイクルモデルの定
義に関する詳細な情報を提供する。そこではライフサイクル段階の一般的な例を定義して
おり，概念，開発，生産，利用，支援及び廃棄の各段階を含む。
4) 発展していくシステムアーキテクチャに基づく作業分解構造（Work Breakdown Structure。以下，WBS
という。）を確立する。
注記1 システムアーキテクチャの各要素，並びに適切なプロセス及びアクティビティは，識別
されたリスクと同じレベルの詳細さで記述する。WBSにおいて関連するタスクは，プロ
ジェクトタスク群にグループ分けする。プロジェクトのタスクは，開発又は生成される
全ての作業項目を識別する。PMI実務標準規程では，WBSについて詳細を追加している。
注記2 PMI（Project Management Institute）は米国のプロジェクト管理協会のことである。
5) プロジェクトに適用されるプロセスを定義し，維持する。
注記 これらのプロセスは，組織の定義されたプロセス（ライフサイクルモデル管理プロセスを
38
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
参照）に基づいている。附属書Aに，プロジェクトに固有なニーズを取り扱うために用い
ることができる修整の情報を含む。プロセスの定義には次を含める。
− プロセスの開始基準
− プロセスの入力
− プロセスの実施順序の制約（事前又は事後実施の関係）
− プロセスの同時並行実施の要求事項（どのプロセス及びタスクが他のプロセスの領域
のタスク又はアクティビティと同時並行に作業されるか）
− プロセスの実施についての効果の測定量又は実績属性の測定量
− 範囲及びコストパラメータ（重大なコストの見積に対するもの）
b) プロジェクト及び技術面の管理を計画する。このアクティビティは，次のタスクからなる。
1) 管理面及び技術面における，目標及び作業見積に基づいてプロジェクトのスケジュールを定義し維
持する。
注記 これは，プロジェクトの適時の完了を達成するために必要なアクティビティ，達成のマイ
ルストーン，使用資源並びにリスク管理のためのレビュー及びリスク管理を考慮したスケ
ジュールの確保についての期間，関係，依存性及び順序の定義を含む。
2) ライフサイクル段階における意思決定ゲート，納入日及び外部入出力への主要な依存性に対する達
成基準を定義する。
注記 内部レビューの時間間隔は，ビジネス及びシステムの重大性，スケジュール並びに技術面
のリスクといった問題に対する組織の方針に従って定義される。
3) コストを定義し，予算を計画する。
注記 コストは，スケジュール，作業量見積，インフラストラクチャのコスト，購入品目，取得
したサービス及びイネーブリングシステム見積，並びにリスク管理のために確保された予
算に基づく。
4) プロジェクト作業のための役割，責任，説明責任及び権限を定義する。
注記 これは，プロジェクトの組織化した体制，要員の確保，要員スキル（技能）の開発及びチ
ーム作業の手法の定義を含む。適切な場合には，法的に責任ある役割及び個人への権限付
与を含める。例えば，設計の認可，安全性の認可，資格の証明又は認定の授与などによっ
て付与される権限である。
5) 要求されるインフラストラクチャ及びサービスを定義する。
注記 これは，必要な容量性，アベイラビリティ及びプロジェクトタスクへの割当てを含む。イ
ンフラストラクチャの設備，ツール及び情報通信技術資産を含む。各ライフサイクル段階
に対するイネーブリングシステムの要求事項も指定する。
6) プロジェクトの外部から供給される資材及びイネーブリングシステムのサービスの取得を計画す
る。
注記1 これは，必要ならば，提案入札要請，供給者選定，受入れ，契約管理及び契約終了の計
画を含む。合意プロセスが，計画された取得に用いられる。
注記2 ISO/IEC 27036シリーズは，供給者との関係に対する情報セキュリティを考慮したイン
フラストラクチャ及びサービスを取得するための手引を提供している。
7) レビューの実施を含めてプロジェクト及び技術面の管理及びそれらの実行の計画を生成し，伝達す
る。
39
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記1 システムに対する技術面の計画は，システムエンジニアリングマネジメント計画
（Systems Engineering Management Plan，SEMP）の中で記述することがよくある。
ISO/IEC/IEEE 24748-4は，システムエンジニアリングテクニカル計画策定について，よ
り詳細に説明してSEMPの概略を提供している。システムに対するソフトウェア計画は，
ソフトウェア開発計画（Software Development Plan，SDP）の中で記述することがよくあ
る。プロジェクトに対する計画は，プロジェクト管理計画の中で記述することがよくあ
る。ISO/IEC/IEEE 16326は，プロジェクト管理について，より詳細な説明を提供してい
る。
注記2 他のプロセスの各々からの戦略に関するアクティビティ及びタスクは，プロジェクト計
画プロセスへ入力され統合される。プロジェクトアセスメント及び制御プロセスは，計
画が統合され，整合し，実行可能となることを確実なものにすることを助けるために使
われる。
c) プロジェクトを開始する。このアクティビティは，次のタスクからなる。
1) プロジェクトに対する認可を得る。
注記 ポートフォリオ管理プロセスは，認可を与える。
2) プロジェクトの実施に必要な資源を要求し，確約を得る。
3) プロジェクト計画を実施する。
6.3.2
プロジェクトアセスメント及び制御プロセス（Project Assessment and Control process）
6.3.2.1
目的
プロジェクトアセスメント及び制御プロセスは，計画が整合していて実現可能かどうかをアセスメント
し，プロジェクト実行の実績，技術面での達成の実績及びプロセス実施の実績の状態を判定し，計画及び
スケジュールに従って予測した予算に収めながら，技術面の目標を満足するようにプロジェクトを遂行す
ることを確実にするのを助けるために，プロジェクトの実行を指示監督することを目的とする。
このプロセスは，定期的に及び主要なイベントにおいて，要求事項，計画及び全体的なビジネス目標に
対する進捗及び達成度を評価する。著しい差異が検出された場合は，管理活動のために情報が提供される。
このプロセスは，識別された他のテクニカルマネジメント又はテクニカルプロセスからの逸脱及びばらつ
きを是正するため，必要に応じて，プロジェクトのアクティビティ及びタスクを軌道修正することも含む。
軌道修正には，適切ならば再計画することを含めてもよい。
6.3.2.2
成果
プロジェクトアセスメント及び制御プロセスの実施に成功すると次の状態になる。
a) 実績の測定量又はアセスメント結果が利用可能になっている。
注記 この実績には，プロジェクトの実行，プロセスの実施，及び技術面の達成についての実績を
含む。
b) 役割，責任，説明責任及び権限の必要十分性がアセスメントされている。
c) 資源の必要十分性がアセスメントされている。
d) 技術進捗レビューが実施されている。
e) プロジェクト実績における計画からの逸脱が調査及び分析されている。
f)
影響を受ける利害関係者がプロジェクトの状況を知らされている。
g) プロジェクトの達成度が目標に達していない場合，是正処置が定義され指示監督されている。
h) 必要に応じて，プロジェクトの再計画が開始されている。
40
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
i)
スケジュールした一つのマイルストーン又はイベントから次に進める（又は進めない）ためのプロジ
ェクト行動が認可されている。
j)
プロジェクトの目標が達成されている。
6.3.2.3
アクティビティ及びタスク
プロジェクトは，プロジェクトアセスメント及び制御プロセスに関する，適用可能な組織の方針及び手
順に従って，次に示すアクティビティ及びタスクを実施しなければならない。
a) プロジェクトのアセスメント及び制御を計画する。このアクティビティは，次のタスクからなる。
1) プロジェクトのアセスメント及び制御の戦略を定義する。
注記 戦略は，計画されたアセスメントの手法及び期限，必要な管理及び技術レビューを含む，
期待されるプロジェクトアセスメント及び制御アクティビティを識別する。
b) プロジェクトのアセスメントを行う。このアクティビティは，次のタスクからなる。
1) プロジェクトの目標及び計画とプロジェクトが実行される状況との整合性をアセスメントする。
2) 計画の必要十分性及び実現可能性を判定するために，目標に対する管理面及び技術面の計画をアセ
スメントする。
3) コスト，スケジュール及び実績についての予測値と実績値との差異を判定するために，妥当な計画
に対するプロジェクト及び技術面の状況をアセスメントする。
4) 役割，責任，説明責任及び権限の必要十分性をアセスメントする。
注記 これには，プロジェクトの役割を担いプロジェクトのタスクを完遂するための，人員の能
力の必要十分性のアセスメントを含む。例えば，資源利用効率，プロジェクト達成度など，
可能な限り客観的測定量が使われる。
5) 資源の必要十分性及びアベイラビリティをアセスメントする。
注記 資源には，インフラストラクチャ，要員，資金，時間，又は他の附属項目を含む。このタ
スクには，組織内での資源提供の確約があることの確認を含む。
6) 測定された達成度及びマイルストーンの完了を用いて進捗をアセスメントする。
注記 これには，例えば，費用面での入手可能性のような，目標に関する他の技術的データとと
もに，労力，資材，サービスのコスト，及び技術面の達成実績に対するデータを集めて評
価することを含む。これらは達成度の測定量と比較する。これには，要求事項に対して，
発展中のシステムが必要十分なものとなっているかを判定する有効性アセスメントを含む。
必要なときにサービスを提供するイネーブリングシステムの準備ができていることも含む。
7) 要求される管理レビュー及び技術レビュー，監査，並びにインスペクションを実施する。
注記 これらは，ライフサイクル又はプロジェクトのマイルストーンの次の段階に進む準備がで
きていることを判定するため，プロジェクト目標及び技術的目標が満たされることを確実
にするのを助けるため，又は利害関係者からのフィードバックを得るために，公式又は非
公式に実施される。
8) 重要なプロセス及び新技術を監視する。
注記 これには，技術の成熟度及び技術が組み入れられたかどうかの識別及び評価を含む。
9) 測定結果を分析し勧告を行う。
注記 潜在的な関心事を示す値を含めた，計画された値からの逸脱，ばらつき又は望ましくない
変化の傾向を識別するため，及び是正処置又は予防処置を行うのに適切な勧告を行うため
に，測定結果を分析する。これには，適切な場合に，傾向を示す測定量の統計的分析を含
41
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
む。そうした測定量には，例えば，成果物の品質を示す欠陥密度，プロセスを繰り返せて
いる程度についてのプロセス反復可能性を示す測定されたパラメータ値の分布などがある。
10) アセスメントのタスクから得た状況及び所見を記録して提供する。
注記 これらは通常，合意，方針及び手順において指定される。
11) プロジェクトにおけるプロセスの実行を監視する。
注記 これには，プロジェクト目標に関するプロセス測定量の分析及びその変化傾向のレビュー
を含む。識別された全ての改善活動は，品質保証プロセス又はライフサイクルモデル管理
プロセスを通じて取り組まれる。
c) プロジェクトを制御する。このアクティビティは，次のタスクからなる。
1) 識別された課題に取り組むために必要な処置を開始する。
注記1 これは，プロジェクト又は技術面の達成度が，計画された目標に合致していない場合に
生じる。これには，是正処置，予防処置及び問題解決処置を含む。不十分な点若しくは
利用できない点が検知された場合，又はプロジェクト若しくは技術面の達成度が目標若
しくは計画を超えた場合，処置は通常，要員，ツール及びインフラストラクチャといっ
た資産の再計画又は再配置を必要とする。これが，コスト，スケジュール，又は技術的
な適用範囲若しくは定義に影響を与えることがよくある。処置は，ライフサイクルプロ
セスの実施手段及び実行に対する変更を必要とすることがある。
注記2 処置は，それらの必要十分性及び適時性を確認するために，記録及びレビューされる。
2) 必要なプロジェクトの再計画を開始する。
注記1 プロジェクトの再計画は，プロジェクトの目標若しくは制約が変わった場合，又は計画
の前提が無効であることが示された場合に開始される。
注記2 取得者と供給者との間の合意の変更を必要とする全ての変更は，取得及び供給プロセス
を呼び出す。
3) 取得者又は供給者からの依頼の影響で，コスト，時間又は品質について契約変更があった場合，変
更する行動を開始する。
注記 これには，供給のために修正された契約条項及び取引条件の考慮又は新たな供給者選定の
開始を含む。これによって，取得プロセス及び供給プロセスが呼び出される。
4) 正当な理由がある場合は，次のマイルストーン又はイベントに向かって進むことをプロジェクトに
認可する。
注記 プロジェクトアセスメント及び制御プロセスは，マイルストーンの完了に関して合意に達
するために用いられる。
6.3.3
意思決定管理プロセス（Decision Management process）
6.3.3.1
目的
意思決定管理プロセスは，ライフサイクル中のいずれの時点でも，意思決定に関する代替案を客観的に
識別し，特徴付け及び評価するために，構造化された分析的な枠組みを提供し，行動の最も有利な進路を
選定することを目的とする。
注記1 このプロセスは，状況に好ましい結果をもたらす代替案の集合を識別するために，技術面又
はプロジェクト面の課題を解決し，システムライフサイクル中に遭遇する意思決定の要請に
対応するために用いられる。
意思決定管理で最も頻繁に使用される手法は，トレードオフ分析及びエンジニアリング面での分析であ
42
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
る。それぞれの代替案は，意思決定基準（例えば，コストへの影響，スケジュールへの影響，プログラム
の制約，規制に関係する事項，技術面の遂行能力・性能・運用時の実績がもつ特性，重大な品質特性，リ
スク）に照らして評価される。これらの比較の結果は，適切な選択モデルを介してランク付けされ，その
後，最適解を意思決定するために使用される。
鍵となる調査データ（例えば，前提及び意思決定根拠）は，通常は，意思決定者に情報を提供し，かつ，
将来の意思決定を支援するために維持されている。
注記2 いずれかの基準に対するパラメータの詳細なアセスメントを行う必要がある場合，そのアセ
スメントを実施するためにシステム分析プロセスが用いられる。
6.3.3.2
成果
意思決定管理プロセスの実施に成功すると次の状態になる。
a) 代替案の分析を必要とする意思決定が識別されている。
b) 行動の進路の代替案が識別され評価されている。
c) 好ましい行動の進路が選定されている。
d) 解決案，意思決定の論理的根拠及び前提が識別されている。
6.3.3.3
アクティビティ及びタスク
プロジェクトは，意思決定管理プロセスに関する，適用可能な組織の方針及び手順に従って，次に示す
アクティビティ及びタスクを実施しなければならない。
a) 意思決定を準備する。このアクティビティは，次のタスクからなる。
1) 意思決定管理の戦略を定義する。
注記 意思決定管理の戦略は，役割，責任，説明責任及び権限の識別を含む。戦略には，意思決
定の種類の分類，及び優先順位の付け方について識別することも含む。次のようなことを
決めるために，意思決定を行うことがよくある。
− 有効性のアセスメント結果
− 技術面のトレードオフ
− 解決が必要な問題
− 受容可能なしきい（閾）値を超えるリスクへの対応として必要とされる行動
− 次のライフサイクル段階へプロジェクトを進めるための新たな機会又は承認
組織又はプロジェクトの指針で，意思決定の分析に適用される厳密さ，及び形式を整え
た正式さの度合いを決定する。
2) 意思決定を行う状況及びニーズを識別する。
注記 問題又は機会及びそれらの結果を解決する作業の，代替案を含めた複数の進路を記録し，
分類し，かつ，報告する。
3) 経験及び知識を活用するために，意思決定に関連する利害関係者を意思決定に参加させる。
注記 分析及び決定に必要な領域の専門家が誰かを識別することは良い行動である。
b) 意思決定の情報を分析する。このアクティビティは，次のタスクからなる。
1) それぞれの意思決定のための意思決定管理の戦略を選択し，宣言する。
注記 代替案を評価するために要求されるデータ及びシステムの分析だけでなく，これらの問題
及び機会を解決するために要求される厳密さの度合いも決定する。
2) 望まれる成果及び測定可能な選定基準を決定する。
注記 全ての基準のための重み付けの要因だけでなく，全ての定量化可能な基準に望まれる値，
43
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
及びその値を超えると属性が満たされなくなる，しきい（閾）値を決定する。
3) トレードオフを考えられる空間及び代替案を識別する。
注記 多数の代替案が存在する場合，更なる詳細なシステム分析を行う目的で，それらを管理可
能な数まで削減するため，代替案を定性的に選抜する。この選抜は，リスク，コスト，ス
ケジュール，規制上の影響などの要因の定性的なアセスメントに基づいている。
4) 基準に照らし合わせて，それぞれの代替案を評価する。
注記 システム分析プロセスは，必要に応じて，評価されることになる，トレードオフされ得る
各代替案に対する，特定の基準を定量化するために用いられる。これには，新しい設計パ
ラメータ，異なるアーキテクチャ特性及び重大な品質特性の値の範囲を含む。システム分
析プロセスは，評価され，トレードオフされ得る各代替案についての感度分析を得るため
に，パラメータが変動する範囲をアセスメントする。これらの結果は，トレードオフされ
得る様々な代替案の実現性を確立するために使われる。
c) 意思決定を実施し管理する。このアクティビティは，次のタスクからなる。
1) それぞれの意思決定に対して好ましい代替案を決定する。
注記 代替案は，選択基準を使って，定量的に評価される。選択された代替案は，通常，識別さ
れた意思決定の最適化又は改善を広く提供する。
2) 意思決定した解決策，意思決定根拠及び前提を記録する。
3) 意思決定を記録，追跡，評価及び報告する。
注記1 これには，合意又は組織の手順に定められているように，監査及び経験からの学習を可
能にする方法を用いて，問題及び機会，並びにそれらの処置を記録することを含む。
注記2 これによって，問題が効果的に解決されたこと，望ましくない傾向が好転したこと，及
び好機を生かして有利となったことを，組織は確認できる。
6.3.4
リスク管理プロセス（Risk Management process）
6.3.4.1
目的
リスク管理プロセスは，リスクを継続的に識別し，分析し，処置し，監視することを目的とする。
リスク管理プロセスは，システム製品又はサービスのライフサイクルを通して，リスクに系統的に対応
する継続的プロセスである。それは，システムの取得，開発，保守又は運用に関連したリスクに適用でき
る。
注記 リスクは，JIS Q 0073:2010にあるように，“目的に対する不確かさの影響”と定義される。こ
の定義には注記1として，“影響とは，期待されていることから，好ましい方向及び／又は好ま
しくない方向にかい（乖）離することをいう。”が付加されている。好ましい方向へ影響をもた
らす肯定的なリスクは，機会（opportunity）として広く知られ，リスク管理プロセスの中で取
り扱う。
6.3.4.2
成果
リスク管理プロセスの実施に成功すると次の状態になる。
a) リスクが識別されている。
b) リスクが分析されている。
c) リスクの処置方法の選択肢が識別され，優先順位付けされて選定されている。
d) リスクに対する適切な処置が実施されている。
e) リスクの状態の変化及び処置の進行状況をアセスメントするために，リスクが評価されている。
44
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
6.3.4.3
アクティビティ及びタスク
プロジェクトは，リスク管理プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すア
クティビティ及びタスクを実施しなければならない。
注記 JIS X 0162は，より詳細なリスク管理に関するアクティビティ及びタスク群を規定している。
このリスク管理プロセスは，JIS Q 31000:2010にあるリスク管理の原則及び指針，及びJIS Q
0073:2010のリスク管理の用語に対応している。JIS Q 9001でも，リスクに基づく予防処置に対
する要求事項を規定している。
a) リスク管理を計画する。このアクティビティは，次のタスクからなる。
1) リスク管理の戦略を定義する。
注記 これには，サプライチェーンにおける全ての供給者のリスク管理プロセスを含み，全ての
供給者からのリスクを，プロジェクトのリスクプロセスに組み込むために，どのようにし
て次のレベルのリスクとして扱うように昇格させるかの方法を記述する。
2) リスク管理プロセスを適用する状況を定義し，記録する。
注記1 これには，利害関係者がもつ観点の記述，リスクの種類を分類する記述，技術面及び管
理面の目標，仮定，並びに制約の記述（記述は参照することによって示す場合が多い。）
を含む。リスクの分類には，システムが関係する技術領域を含み，システムのライフサ
イクルを横断するリスクの識別を容易にする。JIS Q 31000に記載されているとおり，こ
の段階的な手順は，目的の達成の実現，促進，阻害，縮退，加速又は遅延をもたらし得
るイベントに基づくリスクを全て含むような一覧を作成することが目的である。
注記2 リスクの種類の一つである機会は，システム又はプロジェクトのための潜在的な利得を
提供する。追求される各機会は，その期待する利得を損失するリスクが対応付けられる。
これには，機会の影響である効果を達成しないことのリスクとともに，機会を追求しな
いことに対応付けられているリスクも含まれる。
b) リスクプロファイルを管理する。このアクティビティは，次のタスクからなる。
1) リスクのレベルが受け入れられるリスクしきい（閾）値及び条件を定義し，記録する。
2) リスクプロファイルを確立し，維持する。
注記 リスクプロファイルは，次のものを記録する。
− リスク管理を適用する状況
− リスク発生の可能性，帰結，及びリスクしきい（閾）値を含む各リスクの状態の記録
− 利害関係者から提供されるリスク基準に基づく各リスクの優先順位
− リスクの処置の状況に応じたリスク処置作業活動の依頼
リスクプロファイルは，個々のリスクの状態に変化があったときに更新される。リスク
プロファイルの中の優先順位を，リスク処置のための資源の配分を決定するのに使用する。
3) 関連するリスクプロファイルを，利害関係者のニーズに基づき定期的に利害関係者に伝達する。
c) リスクを分析する。このアクティビティは，次のタスクからなる。
1) リスク管理を適用する状況に対応するように記述されたリスク種類別にリスクを識別する。
注記 リスクは通常，次のような様々な分析を通じて識別される。
− 安全性，信頼性，生産可能性，及びシステムの遂行能力・性能・運用時の実績の分析
− 技術，アーキテクチャ，及び運用準備完了を判断するアセスメント
− トレードオフの調査
45
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
これらのリスクは，ライフサイクルの初期の段階で識別され，かつ，システムの利用段
階，支援段階及び廃棄段階まで継続されることがある。さらに，システムに関する測定量
の分析から，リスクが識別されることがよくある。
2) 識別した各リスクが顕在化するリスク発生確率，及び発生したときの帰結である影響を見積もる。
3) 各リスクをリスクしきい（閾）値に対して評価する。
4) リスクしきい（閾）値を超える各リスクに対し，推奨する処置の戦略及び測定量を定義し，記録す
る。
注記 リスク処置の戦略は，リスクの除去，発生確率若しくは発生時の帰結の重大度の軽減，又
はリスクの受容を含むが，これらに限るものではない。リスク処置は，機会の追求のため
に，リスクを積極的に獲得する，又はリスクを増やすことも含む。測定量は，処置の選択
肢の有効性に関する情報を提供する。
d) リスクを処置する。このアクティビティは，次のタスクからなる。
1) リスク処置のための，推奨される選択肢を識別する。
2) 利害関係者が決定した，リスクを受入れ可能にするために行うことが望ましいリスク処置の選択肢
を実施する。
3) しきい（閾）値を超えるリスクであっても，それを利害関係者が受容するときは，優先順位の高い
リスクとして考慮し，その時点以後に追加のリスク処置のための対処作業が必要となるか否かを決
定するために，継続的に監視する。
4) リスク処置を選択したら，管理のための作業を調整する。
注記 プロジェクトアセスメント及び制御プロセスを参照。
e) リスクを監視する。このアクティビティは，次のタスクからなる。
1) 全てのリスク及びリスク管理の適用状況の変化を継続的に監視し，リスクの状態が変化した場合に
は，それらのリスクを評価する。
2) リスク処置の効果を評価するために，測定を実施し，測定量を監視する。
3) ライフサイクルを通じて継続的に，新たなリスクの出現及びリスクの発生源を監視する。
6.3.5
構成管理プロセス（Configuration Management process）
6.3.5.1
目的
構成管理（CM）は，ライフサイクルにわたってシステム要素及び構成を管理及び制御することを目的
とする。また，CMは，製品とそれに関連する構成定義との一貫性を管理する。
6.3.5.2
成果
構成管理プロセスの実施に成功すると次の状態になる。
a) 構成管理をすることが要求される品目が識別され管理されている。
b) 構成のベースラインが確立されている。
c) 構成管理下の品目の変更が制御されている。
d) 構成状態情報が利用可能になっている。
e) 要求される構成監査が完了されている。
f)
システムのリリース及び納入が管理され承認されている。
6.3.5.3
アクティビティ及びタスク
プロジェクトは，構成管理プロセスに関して適用可能な組織の方針及び手順に従って次のアクティビテ
ィ及びタスクを実施しなければならない。
46
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
a) 構成管理を計画する。このアクティビティは，次のタスクからなる。
1) 構成管理戦略を定義する。
注記1 これには，次のことを含む。
− 役割，責任，説明責任及び権限
− 構成品目の取扱い，アクセス，リリース及び変更の制御
− 必要とするベースラインの確立
− 指定された完整性（integrity）レベル，セキュリティレベル及び安全性レベルに応じ
た，保管の場所及び条件，保管媒体，並びにそれらの環境
− 構成制御を始めるため，及び発展していく構成のベースラインを維持するための，
基準又はイベント
− 構成定義情報の継続的な完整性，及びセキュリティをアセスメントするための監査
戦略及び責任
− 計画された構成管理委員会，定期的及び緊急の変更依頼，並びに変更管理の手順を
含む変更管理
注記2 構成管理戦略では，一連の取得者，供給者及びサプライチェーン組織全体で構成管理を
調整する方法を識別する必要がある。この戦略は，システムの耐用寿命の期間又は契約
に含める範囲も適切な場合には網羅する。
注記3 構成管理アクティビティに関する追加の手引は，ISO 10007，IEEE Std 828及びANSI
EIA-649-Bに記載されている。また，民間航空機向け指針のSAE ARP4754A（Guidelines
for Development of Civil Aircraft and Systems）などの領域特有の実践方法は，当該分野に
おける適用方法の詳細を追加して提供している。
2) 構成品目，構成管理作成物及び構成管理データの，保存管理及び検索の手段を定義する。
注記 これにはデータを更新保持する手順を含む。
b) 構成の識別を実施する。このアクティビティは，次のタスクからなる。
1) 構成品目となるシステム要素及び情報項目を識別する。
注記 構成品目は特別な注意を必要とする。通常は一意に定まる識別子を割り当て，レビュー及
び構成監査の対象とする。構成管理対象の品目には，通常，要求事項，製品及びシステム
要素，情報項目及びベースラインが含まれる。
2) システム情報の階層及び構造を識別する。
注記 これには，製品又はシステム要素の階層，システム分解などが含まれる。
3) システム，システム要素及び情報項目を，それぞれ構成品目として指し示す識別子を確立する。
注記 品目は，適切な場合に，一意で，永続性のある識別子又は印によって区別する。識別子は，
構成制御下にある品目が，その仕様書又は同等の記録に残っている記述へと明白に追跡で
きるように，関連する標準及び製品分野の慣例規則に従うようにする。
4) ライフサイクルを通してベースラインを定義する。
注記 ベースラインは指定された時点，又は定義された状況下で，システム要素の発展していく
構成状態を捕捉して形あるものとして保存する。ベースラインの内容は，テクニカルプロ
セスを通じて作成されるが，CMプロセスを通じてある時点で正式化された内容とされる。
ベースラインは次の変更のための基盤を形成する。選択されたベースラインは，産業界で
用いられる実践方法及び構成管理プロセスにおける取得者の契約に基づいた関与に合わせ
47
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
て，通常，取得者と供給者との間で正式化されたベースラインとなる。通常，システムレ
ベルには次の三つの主要な種別のベースラインがある。
− 機能ベースライン
− 割り当てられたベースライン
− 製品（成果物）ベースライン
これらのどの種別にするかは，領域又は個別の戦略によって異なる。
5) ベースラインを確立するために取得者及び供給者の合意を獲得する。
注記 プロジェクトアセスメント及び制御プロセスが合意に達するために用いられる。
c) 構成の変更管理を実施する。このアクティビティは，次のタスクからなる。
注記 構成変更管理は，一度確立されたベースラインへの変更を管理するための手順及び手法を確
立する。これは，構成制御と呼ばれることもある。
1) 変更依頼（Requests for Change）及び差異化依頼（Requests for Variance）を識別し記録する。
注記 差異化依頼は，少しずつ違いのある差分をもたせて変更管理すること，変更管理を免除す
ること，又は一部の変更管理を非適用とすることの依頼を指すことがある。
2) 変更依頼及び差異化依頼を調整し，評価して処理する。
注記 これにはプロジェクトの計画，コスト，便益，リスク，品質及びスケジュールへの影響を
含めて，提案された変更の影響をアセスメントすることを含む。変更依頼を実施するか，
又は終了するかの決定を行う。
3) 変更依頼及び差異化依頼のレビュー及び承認の依頼を提出する。
注記 変更依頼，及び少しずつ違いのある差分をもたせる差異化依頼は，多くの場合，構成管理
委員会（CCB）の正式な管理下にある。評価は変更の影響と必要性とを対比する分析を含
む。
4) ベースラインに対して，承認された変更，変更依頼及び差異化依頼を追跡し管理する。
注記1 このタスクには，優先順位付け，追跡，スケジューリング及び変更の終了を含む。さら
に，テクニカルプロセスを通じて変更を行う。これらの変更を，検証及び妥当性確認プ
ロセスを通じて検証又は妥当性確認し，承認された変更の実施を確実にするのを助ける。
注記2 通常，全ての変更及び変更の理由を示す根拠が記録される。
d) 構成状態の説明報告を実施する。このアクティビティは，次のタスクからなる。
1) システム要素，ベースライン及びリリースの構成管理状態情報を作成し維持する。
注記1 構成状態の説明報告は，製品のライフサイクル全体を通じて，システム要素に関する意
思決定に必要な，制御対象製品の状態についてのデータを提供する。これは，構成制御
下の品目の性質を考慮することを含む。構成記述は，可能な場合には，製品又は技術標
準に適合したものにする。構成情報には，前後の構成状態へのトレーサビリティをもた
せる。通常は，ベースライン及びリリースのための論理的根拠及び構成データに関連す
る認可は，記録に残す。構成記録は合意，関連する法令又は関連する産業での最良の実
践方法に従って，システムライフサイクルを通じて維持し，保存管理する。
注記2 情報の正確性，適時性，完整性及びセキュリティを確認するために，現在の構成状態及
び以前の全ての構成状態を記録，検索及び統合確認できるように管理する。ベースライ
ンが，図面，インタフェース制御文書及びその他の合意した要求事項へ適合しているこ
とを検証するために監査を実施する。
48
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
2) 構成管理データを捕捉し形あるものにして，保管及び報告する。
e) 構成評価を実施する。このアクティビティは，次のタスクからなる。
1) CM監査の必要性を識別し，監査イベントのスケジュールを決定する。
2) 製品（成果物）の構成が構成要求事項を満たしていることを検証する。
注記 これは要求事項，制約及び免除（少しずつ違いのある差分の存在）を正式な検証アクティ
ビティの結果と比較することによって実行する。
3) 承認された構成変更の組込みを監視する。
4) システムが，ベースライン化した機能及び遂行能力・性能・運用時の実績についての能力を満たし
ているかどうかをアセスメントする。
注記 これは機能構成監査（FCA Functional Configuration Audit）と呼ばれることもある。
5) システムが，運用操作用情報及び構成情報の項目に適合しているかどうかをアセスメントする。
注記 これは物理構成監査（PCA Physical Configuration Audit）と呼ばれることがある。
6) CM監査結果及び監査結果への処理作業項目を記録する。
f)
リリースの制御を実施する。このアクティビティは，次のタスクからなる。
1) システムのリリース及び納入を承認する。
注記1 リリースは制限の有無にかかわらず，特定の目的のためにシステムを使用する権限を認
可することを目的とする。例えば，テスト又は運用のためのリリースである。
注記2 リリースには，通常，一連の変更が含まれている。これらの変更はテクニカルプロセス
を通じて行われ，検証プロセス及び妥当性確認プロセスを通じて検証又は妥当性確認さ
れる。リリースの承認には，通常，検証及び妥当性確認された変更の受入れが含まれる。
2) システムのリリース及び納入を追跡し管理する。
注記 必要に応じて，システムの全要素のマスターコピーを，通常，システムの耐用寿命がある
期間にわたって維持する。システム要素を，関係する組織の方針に従って取り扱い，格納
し，パッケージ化し，かつ，納入する。
6.3.6
情報管理プロセス（Information Management process）
6.3.6.1
目的
情報管理プロセスは，指定された利害関係者に対して，情報を生成，入手，確認，変換，保持，検索，
配布及び廃棄することを目的とする。
情報管理は，指定された利害関係者に対し，次のような情報の提供を計画，実行及び制御する。明確で
ある，完全で抜け漏れがない，検証可能である，一貫性がある，変更可能である，トレーサビリティをも
つ，及び提示可能である情報。
情報には，技術，プロジェクト，組織，合意及び利用者の情報が含まれる。情報は多くの場合，組織，
システム，プロセス又はプロジェクトの記録データから導出して得られる。
6.3.6.2
成果
情報管理プロセスの実施に成功すると次の状態になる。
a) 管理すべき情報が識別されている。
b) 情報を表現する形式が定義されている。
c) 情報は，入手され，作成され，変換され，保管され，妥当性確認され，説明され，かつ，廃棄されて
いる。
d) 情報の状態が識別されている。
49
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
e) 情報は，指定された利害関係者が利用可能になっている。
6.3.6.3
アクティビティ及びタスク
プロジェクトは，情報管理プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアク
ティビティ及びタスクを実施しなければならない。
注記 JIS X 0171が，ライフサイクルプロセスでの情報項目（文書）の内容に関する要求事項をまと
めており，それらを作成するための手引を提供している。
a) 情報管理の準備を行う。このアクティビティは，次のタスクからなる。
1) 情報管理の戦略を定義する。
注記 同じ題材についての情報を，ライフサイクルの異なる時点で，異なる情報利用者のために，
異なる方法で開発できる。
2) 管理する情報項目を定義する。
注記 これには，システムライフサイクル中に管理される情報，及びライフサイクルを超えて定
義された期間中にわたって保守される可能性のある情報が含まれる。これは，組織の方針，
合意又は法律に従って行われる。
3) 情報管理の権限及び責任を指定する。
注記 情報及びデータに関する法令，セキュリティ及びプライバシー（例えば，所有権，合意条
件，アクセス権，知的財産及び特許）に対し，適切に配慮する。制限又は制約が当てはま
れば，情報は，それに応じて識別される。情報の中で，このような情報項目の知識をもっ
ている要員は，義務及び責任を通知される。
4) 情報項目の内容，形式及び構造を定義する。
注記 情報は，多くの形式（例えば，オーディオビジュアル，テキスト，グラフィック，数値）
及び媒体（例えば，電子，印刷，磁気，光学）から始まり，最終形となる。インフラスト
ラクチャ，組織間の情報伝達，分散プロジェクトの作業など，組織の制約が考慮される。
関連する情報項目の標準及び慣例規則は，方針，合意及び法令の制約に従って使用される。
5) 情報維持作業を定義する。
注記 情報維持には，完整性（integrity），妥当性及びアベイラビリティについて，格納された情
報の状態をレビューすることを含む。また，技術の変更があっても，保存管理媒体を読み
込めるようにインフラストラクチャを保持するか，又は保存管理媒体を新しい技術を用い
た媒体へ移行するかのいずれかを行う，代替媒体への複製又は変換のニーズも，必要に応
じて含める。
b) 情報管理を実施する。このアクティビティは，次のタスクからなる。
1) 識別された情報項目を入手，開発又は変換する。
注記 これには，データ，情報又は情報項目を適切な情報源から（例えば，いずれかのライフサ
イクルプロセスの結果として）収集し，利害関係者にとって有用な情報となるように書く，
図示する，又は変換することを含む。これには，それぞれの情報標準に基づいて情報をレ
ビュー，妥当性確認及び編集することを含む。
2) 情報項目及びその保管記録を維持し，情報の状態を記録する。
注記1 情報項目を，その完整性（integrity）要求事項，セキュリティ要求事項及びプライバシー
要求事項に従って維持する。情報項目の状態を維持する（例えば，バージョン記述，発
行日又は有効日付，配布記録，セキュリティ分類）。読みやすい情報にして，容易に取り
50
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
出せるような方法で保存し，保持する。
注記2 情報を変換するために使用された変換前の元データ及び変換用のツールは，変換結果の
文書とともに，構成管理プロセスに従って構成制御下に置かれる。JIS X 0154は，ライ
フサイクル情報及び文書化に役立つコンテンツ管理システムの要求事項を提供する。
3) 指定された利害関係者へ情報及び情報項目を発行若しくは配布するか，又は指定された利害関係者
がアクセスできるようにする。
注記 合意されたスケジュール又は定義された状況によって要求されたように，情報を指定され
た利害関係者に適切な形式で提供する。情報項目には，要求に応じて，認証，適格性認定，
免許又はアセスメントの評定に使用される公式文書を含める。
4) 指定された情報を保存管理する。
注記 保管は，監査，知識保持及びプロジェクト終了という目的に従って行う。情報の媒体，場
所及び保護は，指定された保管期間及び検索期間，並びに組織の方針，合意及び法令に従
って選択する。プロジェクトの終了後に必要な情報項目を保持するための手配をする。
5) 不必要な情報，無効な情報，又は妥当性が確認できない情報を廃棄する。
注記 これは組織の方針，セキュリティ及びプライバシーの要求事項に従って行う。
6.3.7
測定プロセス（Measurement process）
6.3.7.1
目的
測定プロセスは，製品，サービス及びプロセスの品質について，効果的な管理を支援し，これらの品質
を実証するために，これらに関する客観的なデータ及び情報を収集し，分析し，報告することを目的とす
る。
6.3.7.2
成果
測定プロセスの実施に成功すると次の状態になる。
a) 情報ニーズが識別されている。
b) 情報ニーズに基づいた測定量の適切な集合が，識別又は開発されている。
c) 要求されるデータが収集され，検証され，蓄積されている。
d) 必要なデータが分析され，結果が解釈されている。
e) 意思決定を支援する客観的な情報が，情報項目によって提供されている。
6.3.7.3
アクティビティ及びタスク
プロジェクトは，測定プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアクティ
ビティ及びタスクを実施しなければならない。
注記1 JIS X 0141では，次に示されるアクティビティ及びタスクと整合した測定のための，一連の
より詳細なアクティビティ及びタスクを提供している。
注記2 JIS Q 9001:2015の箇条9では，プロセス及び製品の測定及び監視のための品質マネジメント
システムの要求事項を規定している。
注記3 対応国際規格の注記1ではJIS X 0141にもなっているISO/IEC 15939（IEEE Std 15939）の
2007年版を参照と記載しているが，その後ISO/IEC/IEEE 15939の2017年版として改正され
ている。また，注記2ではISO 9001の2008年版の箇条8を参照と記載しているが，その後
に改正されたISO 9001（JIS Q 9001）の2015年版では箇条9に相当する。
a) 測定戦略を定義する。このアクティビティは，次のタスクからなる。
1) 測定の戦略を定義する。
51
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
2) 測定に関連する組織の特性を記述する。
3) 情報ニーズを識別し，優先順位付けする。
注記 情報ニーズは，組織のビジネス目標，プロジェクトの目標，識別されたリスク，及びプロ
ジェクトの意思決定に関連するその他の項目に基づく。
4) 情報ニーズを満たす測定量を選択し仕様化する。
5) データ収集，分析，アクセス及び報告の手順を定義する。
6) 情報項目の評価基準及び測定プロセスの評価基準を定義する。
7) 測定に利用する必要のあるイネーブリングシステム又はサービスを識別し計画する。
b) 測定を実施する。このアクティビティは，次のタスクからなる。
1) 測定に関連するプロセスの中で，データの生成，収集，分析及び報告の手順を統合する。
注記 これらに関して要求される変更の幾つかは，他のプロセスの中で統合される。
2) データを収集し，蓄積し，かつ，照合してデータ検証する。
3) データを分析し，情報項目を作成する。
4) 結果を記録し，測定の利用者へ情報を伝達する。
注記 意思決定を支援し，是正処置，リスク管理及び改善を援助するために，測定の分析結果を，
関係する利害関係者へ遅滞なく適時に，利用しやすい様式で報告する。測定の分析結果を，
意思決定のプロセスの参加者，技術レビュー及び管理レビューの参加者，並びに製品改善
及びプロセス改善のプロセスの管轄者へ報告する。
6.3.8
品質保証プロセス（Quality Assurance process）
6.3.8.1
目的
品質保証プロセスは，組織の品質管理プロセスのプロジェクトへの効果的な適用を確実なものにするよ
う支援することを目的とする。
品質保証は，品質要求事項が満たされるという確信を与えることに焦点を合わせる。プロジェクトのラ
イフサイクルプロセス及びプロセスのアウトプットについて先を見越した分析を行う。この分析は，生産・
製作される製品が要望されている品質を備えること，並びに組織及びプロジェクトの方針及び手順が遵守
されて実施されることを保証するために実施する。
6.3.8.2
成果
品質保証プロセスの実施に成功すると次の状態になる。
a) プロジェクトの品質保証手順が定義され実施されている。
b) 品質保証のための評価の基準及び手法が定義されている。
c) プロジェクトの製品，サービス及びプロセスの評価が，品質管理の方針，手順及び要求事項に従って
実施されている。
d) 評価結果が関係する利害関係者へ提供されている。
e) インシデントが解決されている。
f)
問題が優先順位付けされて，処置されている。
注記 a)からd)までの成果は，品質管理プロセスの成果及びJIS Q 9001にある規定要求事項に整合し
ている。
6.3.8.3
アクティビティ及びタスク
プロジェクトは，品質保証プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアク
ティビティ及びタスクを実施しなければならない。
52
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
a) 品質保証の準備を行う。このアクティビティは，次のタスクからなる。
1) 品質保証戦略を定義する。
注記1 戦略は，品質管理の方針，目標及び手順との一貫性をもたせ，次を含める。
− プロジェクトの品質保証手順
− 定義された役割，責任，説明責任及び権限
− 各ライフサイクルプロセスに適したアクティビティ
− 各供給者（下請負契約者を含む。）に適したアクティビティ
− 製品又はサービスに特有のアクティビティとして要求される，検証，妥当性確認，
監視，測定，インスペクション及びテストのアクティビティ
− 製品又はサービスの受入れのための基準，並びにプロセス，製品及びサービスの評
価を行うための評価基準及び手法
注記2 組織の品質管理の方針及び手順が満たされることを確実なものにするのを支援するため，
戦略には，組織の品質管理プロセスとの一貫性をもたせる。
2) 他のライフサイクルプロセスからの品質保証の独立性を確立する。
注記 プロジェクト管理からの独立性を確保するために，プロジェクト管理とは異なった組織か
ら品質保証のための資源を割り当てることがよくある。
b) 製品又はサービスの評価を実施する。このアクティビティは，次のタスクからなる。
1) 製品及びサービスの，確立された基準，契約，標準及び規制への適合性を評価する。
注記 これには，利害関係者ニーズ及び利害関係者要求事項定義プロセス，並びにシステム要求
事項定義プロセスから導出された，システム品質要求事項に対する評価が含まれる。更な
る情報は，JIS X 25010を参照。
2) 規定要求事項に対する適合性を決定するため，ライフサイクルプロセスのアウトプットに対する検
証及び妥当性確認を実施する。
c) プロセスの評価を実施する。このアクティビティは，次のタスクからなる。
1) プロジェクトのライフサイクルプロセスの適合性を評価する。
2) プロセスを支援又は自動化するツール及び環境の適合性を評価する。
3) 供給者のプロセスに対して，プロセス要求事項への適合性を評価する。
注記 共同作業ができる開発環境，供給者が提供するよう要求されるプロセス測定量，又は供給
者が利用するよう要求されるリスクを取り扱うプロセスなどの項目を考慮する。
d) 品質保証の記録及び報告を管理する。このアクティビティは，次のタスクからなる。
1) 品質保証活動アクティビティに関係する記録及び報告を作成する。
注記 記録及び報告は，情報管理プロセスを利用し，組織，規制及びプロジェクトの要求事項に
従って作成する。
2) 記録及び報告を維持し，保管し，配布する。
3) 製品，サービス及びプロセスの評価に関連するインシデント及び問題を識別する。
注記 これには，学んだ教訓を捕捉して形のある記録に残すこと，及びサプライチェーンを通じ
たプロセス実施の監視レビューを実行することが含まれる。
e) インシデント及び問題を処置する。このアクティビティは，次のタスクからなる。
注記1 品質管理の用語では，問題は，対処をしなければプロジェクトがその要求事項を満たさな
くなるという“不適合”として記述されることがよくある。
53
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記2 問題の分類及び優先度の分類についての，更なる情報及び例は，ISO/IEC/IEEE
24748-1:2018を参照。
1) インシデントを記録し，分析し，分類する。
2) インシデントを解決するか，又は問題へと格上げする。
3) 問題を記録し，分析し，分類する。
注記 分析結果に，可能性のある処置の選択肢を含める。
4) 問題の処置を優先順位付け，処置の実施を追跡する。
注記 処置の実施は，プロジェクトアセスメント及び制御プロセスが始動させるテクニカルプロ
セスの中で遂行する。
5) インシデント及び問題の傾向を確認し分析する。
6) 利害関係者へインシデント及び問題の状況について通知する。
7) インシデント及び問題を終了まで追跡する。
6.4
テクニカルプロセス（Technical processes）
テクニカルプロセスは，システムに対する要求事項を定義し，要求事項を製品を利用したときに効果の
ある製品へ変換し，必要に応じて，一貫性をもたせた再製品化・再生産を可能にし，要求されたサービス
を提供するために製品を利用し，そうしたサービス提供を維持し，かつ，製品がサービスにおいて利用さ
れなくなったときには製品を廃棄するために用いる。テクニカルプロセスは，組織及びプロジェクトの機
能が便益を最適化するためのアクティビティ，並びに技術的な決定及び行動から発生するリスクを軽減す
るためのアクティビティを定義する。これらのアクティビティは，製品及びサービスが次に示す事項を備
えられるようにする。
− 適時性及びアベイラビリティ（可用性）
− コストに対する効果の高さ（費用対効果）
− 機能性，信頼性，保守性，生産可能性，使用性，並びに取得する組織及び供給する組織によって要求
される，その他の品質
これらのアクティビティは，製品及びサービスが，人の健康，安全性，セキュリティ及び環境上の要因
を含めた，社会の期待又は法令の要求事項に適合できるようにもする。
テクニカルプロセスは，次によって構成される。
a) ビジネス又はミッション分析プロセス（Business or Mission Analysis process）
b) 利害関係者ニーズ及び利害関係者要求事項定義プロセス（Stakeholder Needs and Requirements Definition
process）
c) システム要求事項定義プロセス（System Requirements Definition process）
d) アーキテクチャ定義プロセス（Architecture Definition process）
e) 設計定義プロセス（Design Definition process）
f)
システム分析プロセス（System Analysis process）
g) 実装プロセス（Implementation process）
h) インテグレーションプロセス（Integration process）
i)
検証プロセス（Verification process）
j)
移行プロセス（Transition process）
k) 妥当性確認プロセス（Validation process）
l)
運用プロセス（Operation process）
54
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
m) 保守プロセス（Maintenance process）
n) 廃棄プロセス（Disposal process）
注記1 ソフトウェア及びハードウェアのシステム要素に対して，これらのプロセスは，システム定
義のために下位レベルへ再帰的に適用し，かつ，システム実現のために上位レベルへも再帰
的に適用する。利害関係者ニーズ及び利害関係者要求事項の定義，システム要求事項定義，
アーキテクチャ定義，設計定義，システム分析，インテグレーション，検証及び妥当性確認
のために，これらのプロセスをそれぞれのレベルで適用する。
注記2 要求事項，重大なシステムの遂行能力・性能・運用時の実績についての測定量，及び重大な
品質特性の間でバランスさせたソリューションを確立するため，これらのプロセスを，互い
に同時並行し，反復して，実施することがよくある。いずれの抽象度レベルであっても，シ
ステムの要求事項とモデルとの間は，テクニカルプロセスを反復して適用することによって
一貫性をもたせる。要求事項及びモデルがそのまま直接的に実装されるものではないときは，
例えば，システムの階層の一段下位レベルのような，より詳細なレベルで同じプロセスを再
帰的に繰り返す。
注記3 ライフサイクル段階の概念，及び各段階における，これらのプロセスの適用についての詳細
は，ISO/IEC/IEEE 24748-1:2018に記述されている。そこには，システムライフサイクル内
でテクニカルプロセスを制定するときの段階の例及び段階ごとの成果の例がまとめられてい
る。
注記4 インタフェース管理は，システムエンジニアリングプロセスを横断するアクティビティの集
合となる。これらのアクティビティは，テクニカルプロセス及びテクニカルマネジメントプ
ロセスを横断しているアクティビティで，特定のプロセスビュー及びシステムビューとして
適用され，追跡される。インタフェース管理プロセスビューの例は，附属書Eを参照。より
詳細な情報はINCOSEシステムエンジニアリングハンドブック第4版の9.6を参照。
注記5 INCOSEはThe International Council on Systems Engineering（国際システムエンジニアリング協
議会）を指す。
6.4.1
ビジネス又はミッション分析プロセス（Business or Mission Analysis process）
6.4.1.1
目的
ビジネス又はミッション分析プロセスは，ビジネス又はミッションにおける問題又は機会を定義し，ソ
リューション空間を特徴付け，問題を取り上げ解決できる又は機会を有益にいかすことができるような，
一つ以上の潜在的な可能性をもつソリューションの集まりを決定することを目的とする。
注記1 ビジネス又はミッションの分析は，システムライフサイクルのアクティビティに関与する全
ての利害関係者を包含する組織に関係する。このプロセスは，一般的にはこの規格の適用範
囲外となる組織の戦略と相互に連携するものである。
組織の戦略分析結果は，組織における組織レベルの運用概念（ConOps），戦略的な最終目
標であるゴール及び計画，新規市場又はミッション要素，並びに識別された問題（problems）
及び機会（opportunities）を含む。組織の戦略は，指定した状況の範囲内でビジネス又はミッ
ションの分析を実施するように，その状況を確立する。
組織における組織レベルの運用の概念は，組織で指導的役割をもった者の意図する組織の
運用方法に関係する。それは，ビジネスの運用全体又は連携した運用を支援する中で，組織
が想定している前提，並びに開発されることになるシステム，既存システム，及び実現する
55
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
可能性のある将来のシステムをどのようにして用いることを意図しているのかを記述したも
のになる。組織が対象システムである場合には，組織の戦略はシステム定義の一部分となる。
注記2 このプロセスは，システムのソリューションが有効な期間を通して適用され，環境，ニーズ
又は他の駆動要因に変更があれば再度行われる。
注記3 幾つかの領域において，これは組織が必要としているか又は要望している能力を，識別及び
分析するという概念に関係する。このプロセスは，能力を取り扱うことが可能なトレードオ
フ空間を識別するために行う，ポートフォリオ管理プロセスとの必要な連携，及びトレード
オフ空間内で調整して得られる必要な能力に焦点を当てている。
識別された問題又は機会は，どのようなことがどの程度まで可能になることを目標とする，
という目標能力に変換されることがよくある。所与の領域内において適用可能なときには，
問題又は機会の空間には目標能力が含まれる。
6.4.1.2
成果
ビジネス又はミッション分析プロセスの実施に成功すると次の状態になる。
a) 問題又は機会が存在し得る範囲を表す，問題又は機会の空間が定義されている。
b) ソリューションが存在し得る範囲を表す，ソリューション空間が特徴付けられている。
c) ライフサイクル段階における，予備的な，システムレベルの運用概念（OpsCon）及び他の概念が定義
されている。
d) 複数の，選択候補となる代替ソリューションの集まりが識別及び分析されている。
e) 一つ以上の，好ましい代替ソリューションの集まりの候補が選定されている。
f)
ビジネス又はミッション分析の実施を可能にするために必要な全てのイネーブリングシステム又はサ
ービスが利用可能になっている。
g) ビジネス又はミッションの問題及び機会と，好ましい代替ソリューションの集まりとの間のトレーサ
ビリティが確立されている。
6.4.1.3
アクティビティ及びタスク
プロジェクトは，ビジネス又はミッション分析プロセスに関する，適用可能な組織の方針及び手順に従
って，次に示すアクティビティ及びタスクを実施しなければならない。
a) ビジネス又はミッション分析の準備を行う。このアクティビティは，次のタスクからなる。
1) 組織が要望しているゴール及び目標の観点から，組織の戦略において識別された問題及び機会をレ
ビューする。
注記 これには，組織のビジネス又はミッション，展望，組織レベルの運用概念，並びに組織の
戦略的な最終目標であるゴール及び当面の目標に関する問題及び機会を含む。これは，現
在の能力，システム，製品又はサービスにおける欠如又はギャップも含む。
2) ビジネス又はミッション分析の戦略を定義する。
注記 これには，問題空間を識別及び定義し，ソリューション空間を特徴付けし，かつ，ソリュ
ーションの集まりを選定するために用いる取組方法を含む。
3) ビジネス又はミッション分析を支援するために必要とする，イネーブリングシステム又はサービス
を識別し計画する。
注記 これには，イネーブリングシステムに対する要求事項及びインタフェースの識別を含む。
ビジネス又はミッション分析のためのイネーブリングシステムには，組織のビジネスで用
いているシステム及びリポジトリも含む。
56
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
4) 利用されるイネーブリングシステム若しくはサービスを，獲得する又はそれらへのアクセスを取得
する。
注記 ビジネス又はミッション分析の実現を支援するイネーブリングシステムの支援機能が，意
図されたように利用できるかを客観的に確認するために，妥当性確認プロセスが用いられ
る。
b) 問題又は機会の空間を定義する。このアクティビティは，次のタスクからなる。
1) トレードオフ空間の要因に関係付けられた状況の中で，問題及び機会を分析する。
注記1 この分析は，問題又は機会の，範囲，基盤又は駆動要因を理解することに焦点を当てた
ものである。この分析は，トレードオフ分析に必要なシステム分析及び意思決定管理に
焦点を当てた総合化とは反対方向のものである。ここで焦点を当てる対象は，ミッショ
ンの要求事項の変更，ビジネスにおける機会，能力，既存システムの遂行能力・性能・
運用時の実績の改善又は不足，セキュリティ及び安全性の改善，コスト及び有用性のよ
うな要因，規則の変更，利用者の不満足，並びにPESTEL要因［政治（Political），経済
（Economic），社会（Social），技術（Technological），環境（Environmental）及び法律（Legal）］
を含む。これは外部からの分析，内部での分析，又はSWOT分析［強み（Strengths），
弱み（Weaknesses），機会（Opportunities）及び脅威（Threats）］によって達成される場合
がある。
注記2 分析の出力は，ポートフォリオ管理の意思決定の一部分とも考えられる。
2) ミッション，ビジネス又は運用における問題又は機会を定義する。
注記 この定義には，特定のソリューションを考慮することなく，状況及び全ての主要パラメー
タを含める。その理由は，運用上の変更，既存の製品若しくはサービスの変更，又は新シ
ステムのいずれもがソリューションとなる可能性があるからである。
c) ソリューション空間を特徴付ける。このアクティビティは，次のタスクからなる。
1) ライフサイクルの段階における，予備的な，システムレベルの運用概念及び他の概念を定義する。
注記1 これには，顧客，利用者，運営管理者，規制機関，システムの所有者などの，主要な利
害関係者のグループの識別を含む。これら主要な利害関係者は，利害関係者ニーズ及び
利害関係者要求事項定義プロセスで定義されることになる。
注記2 ライフサイクルを構想した予備的なライフサイクル概念には次を含める。予備的な取得
概念，予備的な展開概念，予備的なシステムレベルの運用概念，予備的な支援概念，及
び予備的な廃棄概念。システムレベルの運用概念には，抽象度の高いレベルでの運用モ
ード若しくは状態，運用シナリオ（operational scenarios），可能性のあるユースケース，
又は提案されているビジネス戦略における利用法を含む。これらの概念は，実現可能性
の分析及び代替案の評価を可能にする。これらの概念は，利害関係者ニーズ及び利害関
係者要求事項定義プロセスで更に詳細化される。
注記3 運用中の環境は，特定のセキュリティへの脅威及び安全性へのハザード（危害の潜在的
な源，潜在危険 hazard）に関する，ぜい弱性があると考えられる場合がある。このよ
うな，ぜい弱性は，開発中の製品に関係付けて理解される必要がある。システムと人間
とのインタフェースは，システムのアシュアランスを実現する状況における一つの要素
であり，インタフェースに関連するぜい弱性は重大なミッションが連鎖する状況におい
て詳細に調査される。
57
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
2) 潜在的な可能性をもったソリューション空間を広げる，複数の，代替ソリューションの集まりの候
補を識別する。
注記 これらは，単に運用上の変更から様々なシステムの開発又は変更までに範囲が広がる場合
がある。ソリューション空間は，その運用又は機能の変更へのニーズを取り上げて解決で
きるような，既存システム，製品，サービスを識別することを含めることができる。これ
には，必要とされるであろう，潜在的に望まれているサービスには何があるかを推定する
ことも含む。ソリューション空間に特性を付与するときは，アーキテクチャ ビュー（例え
ば，能力ビュー，プログラムビュー及び運用ビュー）にした利用者のアーキテクチャ ビュ
ーポイントに対して，アーキテクチャ定義プロセスを実行することもよくある。これは
ISO/IEC/IEEE 42010によって提案されている。
d) 複数ある代替ソリューションの集まりを評価する。このアクティビティは，次のタスクからなる。
1) 代替ソリューションの集まりそれぞれのアセスメントを行う。
注記1 代替ソリューションの集まりそれぞれを，組織の戦略に基づいて確立され，定義された
基準に対してアセスメントを行う。ソリューションの集まりの実現可能性は重要な意思
決定基準の一つとなる。ポートフォリ管理プロセスから考慮の対象となる幾つかの基準
が提供される。
注記2 システム分析プロセスが，代替ソリューションの集まりの各集合に対する各基準につい
て，アセスメントを行って値を決めるために用いられる。構造化されているトレードオ
フ分析が推奨される。コストを基準に含めると，無理のない費用で利用しやすい意思決
定を助けることになる。複数ある代替ソリューションの集まりがもつリスク，実現可能
性及び基準についての値を理解するために，代替案のアセスメントでは，モデル化，シ
ミュレーション，分析技法又は専門家による判断を含めることができる。
2) 一つ以上の，好ましい代替ソリューションの集まりを選定する。
注記 意思決定管理プロセスが，代替案を評価し，選定方法を手引きするために用いられる。選
定された代替案について組織の戦略における状況の中で妥当性確認が実施される。リスク，
実現可能性，市場の要因及び代替案へのフィードバックが，組織の戦略の更新に使用する
ために提供される。
e) ビジネス又はミッション分析を管理する。このアクティビティは，次のタスクからなる。
1) ビジネス又はミッション分析のトレーサビリティを維持する。
注記 ライフサイクルを通じて，ビジネス及びミッションの問題及び機会と，好ましい代替ソリ
ューションの集まりとの間で，双方向のトレーサビリティを維持する。これには，組織の
戦略，利害関係者のニーズ及び利害関係者要求事項，並びに意思決定を助けたシステム分
析結果も付加する。
2) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが，構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス（ビジネス又はミッション分析プロセス）で，ベースラインのための候補とな
る情報項目を識別し，CM（構成管理）へ情報項目を提供する。
6.4.2
利害関係者ニーズ及び利害関係者要求事項定義プロセス（Stakeholder Needs and Requirements
Definition process）
6.4.2.1
目的
58
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
利害関係者ニーズ及び利害関係者要求事項定義プロセスは，定義された環境において，利用者及び他の
利害関係者によって必要とされる能力を提供できるように，システムに対する利害関係者の要求事項を定
義することを目的とする。
このプロセスでは，システムのライフサイクルを通じて，システムに関係している利害関係者又は利害
関係者の集まり，及びそれら利害関係者のニーズを識別する。このプロセスでは，これらのニーズを分析
し，利害関係者要求事項の共通集合に変換する。利害関係者要求事項は，システムがその運用環境との間
にもつように意図された相互作用を表現する。さらに，利害関係者要求事項は，運用したときに結果とし
て得られる運用の能力の妥当性を確認するために対比して参照する対象となる。対象システムをシステム
及びイネーブリングシステムと接続して相互運用する状況を考慮して，利害関係者要求事項を定義する。
6.4.2.2
成果
利害関係者ニーズ及び利害関係者要求事項定義プロセスの実施に成功すると次の状態になる。
a) システムの利害関係者が識別されている。
b) ライフサイクルの段階の中で，能力及び概念に要求される特性，並びに能力及び概念を利用する状況
が，システムレベルの運用概念を含めて定義されている。
c) システムに課された制約が定義されている。
d) 利害関係者ニーズが定義されている。
e) 利害関係者ニーズが優先順位付けされ，明確に定義された利害関係者要求事項に変換されている。
f)
重大なシステムの遂行能力・性能・運用時の実績の測定量が定義されている。
g) 利害関係者のニーズ及び期待が要求事項へ必要十分に反映され，利害関係者の合意に到達している。
h) 利害関係者ニーズ及び利害関係者要求事項定義の実施を可能にするために必要な全てのイネーブリン
グシステム又はサービスが利用可能になっている。
i)
利害関係者要求事項と，利害関係者及びそれらの利害関係者ニーズとの間のトレーサビリティが確立
されている。
6.4.2.3
アクティビティ及びタスク
プロジェクトは，利害関係者ニーズ及び利害関係者要求事項定義プロセスに関する，適用可能な組織の
方針及び手順に従って，次に示すアクティビティ及びタスクを実施しなければならない。
a) 利害関係者ニーズ及び利害関係者要求事項定義の準備を行う。このアクティビティは，次のタスクか
らなる。
1) システムのライフサイクルを通じて，システムに関係する利害関係者を識別する。
注記 これには，利害関係者の個人及び集まりを含む。こうした利害関係者の個人及び集まりは，
利用者，運用操作者，支援者，開発者，制作者，教育訓練指導者，保守者，廃棄担当者，
取得者及び供給者の組織，インタフェースを介して接続している外部の様々な実体につい
て責任のある団体，規制機関，並びにシステムについて合法的に正当な利害をもつその他
の人たちからなる。意思伝達を直接行うことが現実的ではない場合（例えば，不特定多数
の一般消費者向け製品又はサービス）は，代表者又は指定されて委任を受けた代理人とな
る利害関係者を選定する。
2) 利害関係者ニーズ及び利害関係者要求事項の定義戦略を定義する。
注記 システムに反対しているか，又は互いに対立している利害関係者がいる場合がある。利害
関係者が，それぞれの利害関係者間で互いに対立しているが，システムには反対していな
い場合は，このプロセスでは，利害関係者の集まりの中で共通合意を得て，受入れ可能な
59
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
要求事項の共有集合を確立するようにする。利害関係者の意図若しくは要望がシステムに
反対するものである場合，又は利害関係者がシステムの価値を落としめようとする者であ
る場合は，リスク管理プロセス，システム分析プロセスでの脅威分析によって，又はセキ
ュリティ，適応性若しくは危機に弾力的な対応ができる復元性（resilience）についてのシ
ステム要求事項によって取り扱う。このような場合は，反対する利害関係者のニーズを満
たすのではなく，システムの価値を落としめようとする者からの行動に遭遇したときに，
システムのアシュアランス及び完整性を確実にすることを援助する方法によって取り組む。
3) 利害関係者ニーズ及び利害関係者要求事項の定義を支援するために必要とするイネーブリングシス
テム又はサービスを識別し計画する。
注記 これには，イネーブリングシステムに対する要求事項及びインタフェースの識別を含む。
利害関係者ニーズ及び利害関係者要求事項定義のためのイネーブリングシステムには，定
義を促進するツール及び要求事項を管理するツールも含む。
4) 利用されるイネーブリングシステム若しくはサービスを，獲得する又はそれらへのアクセスを取得
する。
注記 利害関係者ニーズ及び利害関係者要求事項の定義の実現を支援するイネーブリングシステ
ムの支援機能が，意図したように利用できるかを客観的に確認するために，妥当性確認プ
ロセスが用いられる。
b) 利害関係者ニーズを定義する。このアクティビティは，次のタスクからなる。
1) 組織レベルの運用概念及び予備的なライフサイクル概念の範囲内で，利用する状況を定義する。
注記 利用する状況は，ISO/IEC 25063にあるような利用状況の記述によって，捕捉して形ある
ものとして記録することもよくある。事前準備のための予備的なライフサイクル概念が，
ビジネス又はミッション分析プロセスによって開発される。
2) 利害関係者ニーズを識別する。
注記1 利害関係者ニーズの識別には，利害関係者から直接的にニーズを引き出すこと，領域の
知識及び利用状況の理解に基づくが明示されない暗黙の利害関係者ニーズを識別するこ
と，並びにそれまでの活動とのギャップを文書化することを含む。ニーズに，有用性の
測定量を含めることがよくある。ニーズの引出しを助けるために機能分析を行うことが
よくある。また，利害関係者が明示しない，暗黙のニーズとなりがちな非機能要求事項
の品質要求事項を引き出し，かつ，識別するために，JIS X 25010にある品質モデルの品
質特性を用いて，JIS X 25030にあるように要求分析へ適用することが役立つ。
注記2 利害関係者ニーズは，識別された利害関係者がもつ必要性，欲求，要望，期待及び認知
された制約を記述する。運用環境に必要となる，最小限のセキュリティ及びプライバシ
ー要求事項に対する利害関係者ニーズを理解することが，運用の計画，スケジュール及
び重大な遂行能力・性能・運用時の実績を損なう潜在的な可能性を最小限に抑える。
利用者及びその他の利害関係者，並びにそれらの人がシステムの一部に含まれて関与
するか又はシステムと対話操作することに関して，重要な課題が発生しそうな場合は，
人間とシステムとの間の課題を識別して対処するための推奨事項がある。それは，
ISO/TS 18152を参考にできる。
3) ニーズを優先順位付け，選定して絞り込む。
注記 意思決定管理プロセスが優先順位付けを支援するために通常用いられる。システム分析プ
60
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
ロセスを用いて，実現可能性又は他の要因に対してニーズを分析する。
4) 利害関係者のニーズ及び根拠を定義する。
注記 ニーズは，システムの目的及び振る舞いに着目したものに集中させて，それらの運用の環
境及び条件についての状況と合わせて記述する。ニーズの提供元及びニーズの理由を示す
根拠までトレースすることが役に立つ。
c) システムレベルの運用概念及びその他のライフサイクル概念を開発する。このアクティビティは，次
のタスクからなる。
注記 その他のライフサイクル概念には，システム取得の概念，展開配備の概念，運用・保守の支
援概念，セキュリティの概念及び廃棄の概念を含めることができる。このアクティビティで
は，ビジネス又はミッション分析プロセスの中で定義された予備的なライフサイクル概念を，
利害関係者に関連するシナリオ及び対話操作・相互作用が定義されるような，特定の利害関
係者ニーズが存在する状況下で更に発展させた概念を開発する。要求エンジニアリングに関
するJIS X 0166の箇条5及び箇条6ではシステムレベルの運用概念について，並びにその附
属書Aで運用概念の情報項目の概要について，追加情報が参照できる。
1) 想定されるシステムレベルの運用概念及びその他のライフサイクル概念に対応付けた，全ての要求
される能力を識別するために，シナリオ群の代表的な集合を定義する。
注記1 利害関係者の誰からもまだ明示的に識別されていない可能性がある，追加のニーズ又は
要求事項（例えば，法律，規則及び社会的な制約など）を識別する目的で，意図された
環境におけるシステムの運用を分析するために，シナリオ群を用いる。システムを利用
する状況は，次を含めて識別及び分析する。
− 利用者がシステムの目標を達成するように実行する活動
− システムの最終利用者に関連した各種の特性（例えば，期待される教育訓練，疲労
の程度）
− 物理的環境（例えば，利用可能な照明，温度）
− 利用する全ての機器（例えば，防護機器又は通信機器）
システムの利用に影響を及ぼすか，又はシステムの利用法の設計に制約を与える可能
性があるような，利用者へ波及するような社会的及び組織的な影響は，該当するものが
あれば分析する。攻撃者，攻撃者の環境，ツール，技法及び能力に焦点を当てたシナリ
オ群を考慮することはシステムレベルの運用概念の開発にとって重要である。様々な運
用ニーズの重要度を重み付けして反映するために，シナリオ群に優先順位を付ける。
注記2 これらのシナリオ群は，システムレベルの運用概念又はライフサイクル概念を更新する
動機付けとなることがよくある。誤使用及び故障発生のシナリオ群は，各シナリオによ
って識別される誤使用又は故障発生のリスクを軽減するための，追加の機能要求事項の
ニーズ（又はそのようなリスクを軽減するために導出される，より特定の要求事項）を
見つけやすくする。
2) 利用者とシステムとの間の対話操作・相互作用を識別する。
注記1 使用性（ユーザビリティ usability）の要求事項では，人間の能力及びスキルの限界を考
慮する。可能な場合には，例えば，人間工学に関するJIS Z 8511，JIS Z 8520，JIS Z 8530
などのISO 9241シリーズの適用可能な規格及び受け入れられた専門的な実践方法を用
いて次を定義する。
61
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
− 身体面，心理面及び学習面での能力
− 利用状況における，作業場所，環境及び機器を含む設備
− 通常の正常な状況，通常でない状況及び緊急状況
− 運用操作者及び利用者の採用，教育訓練及び組織文化
注記2 使用性が重要なときは，ライフサイクルプロセスを通じて使用性の要求事項を計画，仕
様化及び実装する。人間とシステムとの間の課題に関する情報についてはISO/TS 18152
を，使用性に関する情報についてはISO/IEC TR 25060:2010をそれぞれ参照。
d) 利害関係者ニーズを利害関係者要求事項へ変換する。このアクティビティは，次のタスクからなる。
1) システムソリューションにおける制約を識別する。
注記 次の結果から，制約がもたらされる。
− 利害関係者の定義されたソリューションの事例又は領域
− システムの階層構造の上位レベルで判断される実装についての意思決定
− 定義されたイネーブリングシステム，資産となっているシステム，若しくはインタフ
ェースを介して接続するシステム，又はそれらのシステム要素，資源及び要員につい
ての，要求された利用法
− 利害関係者によって定義された，費用面での容易さの目標
既存の合意，管理面及び技術面の意思決定がもたらす不可避の帰結も制約に含める。
2) アシュアランス，安全性，セキュリティ，環境，人の健康など，重大な品質特性に関係する利害関
係者要求事項及び機能を識別する。
注記1 システム及びソフトウェアのアシュアランスについての追加情報は，JIS X 0134-2を含
むISO/IEC 15026シリーズを参照。
注記2 安全性のリスクを識別することが，安全要求事項及び安全機能の識別を促進する。安全
性リスクには，運用及び支援の方法，人の健康及び安全性，資産への脅威，並びに環境
への影響に関連する事項を含む。例えば，JIS C 0508規格群のような適用可能な規格及
び広く受け入れられている実践方法を用いる。
注記3 セキュリティのリスクを識別することが，追加のセキュリティ要求事項及びセキュリテ
ィ機能の識別を促進する。契約で保証される場合は，物資，手順，通信，コンピュータ，
プログラム，データ及び排出物質を含め，システムセキュリティが該当する領域を含む。
これには，保護対象となる人員，資産及び情報へのアクセス及び損傷，機密情報を危
うくすること並びに資産及び情報に対して認められたアクセスへの拒否を含む。
また，必須又は適切な場合に，適用可能な標準及び受け入れられた専門的な実践方法
への参照を基にした，軽減及び抑制を含め，要求されたセキュリティ機能も含む。
注記4 利用時の品質の観点をもった品質特性に関する，更なる情報についてはJIS X 25030を
参照。
3) ライフサイクル概念，シナリオ，相互作用，制約，及び重大な品質特性との一貫性をもたせるよう
に，利害関係者要求事項を定義する。
注記1 利害関係者要求事項の，更なる情報についてはJIS X 0166の箇条5及び箇条6を，利害
関係者要求事項仕様書の記述及び注釈を含む概要については，箇条8及び箇条9を参照。
注記2 どのようなニーズの変更も考慮することを確実に行うことを援助するため，ライフサイ
クル中の重要な意思決定の時点で，利害関係者要求事項をレビューする。
62
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記3 ライフサイクルを通じて要求事項管理を行うという目的に合った様式で，利害関係者要
求事項を記録する。これらの記録は，利害関係者要求事項ベースラインを確立し，ライ
フサイクルの初めから終わりまで，ニーズの変更及び利害関係者要求事項の起源を保持
する。これらの記録は，利害関係者のニーズ，システム要求事項及び導かれる結果とな
るシステム要素へのトレーサビリティと同様に，ビジネス又はミッション分析プロセス
によって実施された意思決定へのトレーサビリティの基礎になる。
注記4 利害関係者要求事項は，システム及びシステム要素に対する妥当性確認のための基準の
基礎となる。
e) 利害関係者要求事項を分析する。このアクティビティは，次のタスクからなる。
1) 利害関係者要求事項の全ての集合を分析する。
注記1 利害関係者要求事項を，要求事項の集合としての特性に対して分析するとともに，個々
の要求事項の特性に対しても分析する。個々の要求事項に関して，潜在的な可能性につ
いて分析される特性には，次の全てが含まれる。
− 要求事項が必要なものであること
− 実装方法に依存しないものであること
− 曖昧性がないこと
− 矛盾なく一貫性があること
− 抜け漏れなく完全にそろ（揃）っていること
− 単独性があり他の要求事項との重複がないこと
− 実現可能であること
− トレース可能であること
− 検証可能であること
− 費用面で可能であること
− 定義範囲を示す境界が明確にされていること
要求事項の特性についての追加情報がJIS X 0166で提供されている。
注記2 実現が可能か，及び適切な費用で入手しやすいかどうかをアセスメントするためには，
システム分析プロセスが用いられる。利害関係者要求事項のレビューにおいては，検証
プロセス及び妥当性確認プロセスが用いられる。
2) 技術面での達成度をアセスメントできるようにする，重大な遂行能力・性能・運用時の実績の測定
量を定義する。
注記 これには，技術及び品質の測定量，並びに有効性の各測定量に関連する，重大な遂行能力・
性能・運用時の実績のパラメータを，利害関係者要求事項から識別して定義することを含
む。重大な遂行能力・性能・運用時の実績の測定量（例えば，有用性の測定量及びシステ
ムの目的への適合性の測定量）を定義，分析及びレビューし，利害関係者要求事項に合致
させることを確実にし，何らかの不適合につながるようなプロジェクトのコスト，スケジ
ュール又はプロジェクト実行の実績及びシステムの遂行能力・性能・運用時の実績に関す
るリスクの識別を確実にすることを助ける。JIS X 0141では適切な測定量を識別，定義及
び利用するためのプロセスを提供している。技術面での測定量に関するINCOSE
TP-2003-020-01では，重大な遂行能力・性能・運用時の実績の測定量の選定，定義及び実
装についての情報を提供している。JIS X 25000シリーズでは関連する品質測定量を提供し
63
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
ている。
3) 利害関係者のニーズ及び期待が適切に把握されて表現されていることを妥当性確認するために，分
析された要求事項を適用可能な利害関係者へフィードバックする。
4) 利害関係者要求事項の課題を解決する。
注記 この課題には，JIS X 0166で定義されている特性のような，個々の要求事項の特性又は要
求事項の集合の特性から逸脱するような要求事項を含む。
f)
利害関係者ニーズ及び利害関係者要求事項の定義を管理する。このアクティビティは，次のタスクか
らなる。
1) 利害関係者要求事項についての明示的な合意を獲得する。
注記 これには，利害関係者要求事項が正しく表現されているか，要求事項の提供元の利害関係
者にも理解できるか，及び矛盾のある要求事項の解決策が利害関係者の意図を損なってし
まう又は失ったものになっていないか，を確認することを含む。
2) 利害関係者ニーズ及び利害関係者要求事項のトレーサビリティを維持する。
注記 ライフサイクルを通じて，利害関係者ニーズ及び利害関係者要求事項と，それらの提供元
及び利害関係者，組織の戦略，並びにビジネス及びミッションの問題及び機会との間で，
双方向のトレーサビリティを維持する。さらに，システムのソリューションを作り上げつ
つあるシステムへのトレーサビリティによって，システム要求事項定義プロセスへ移行す
ることを容易にする。適切なデータリポジトリによって，これが容易になることがよくあ
る。
3) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが，構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス（利害関係者ニーズ及び利害関係者要求事項定義）で，ベースラインのための
候補となる情報項目を識別し，CMへ情報項目を提供する。このプロセスにおいてベース
ライン化される典型的な情報項目は，利害関係者ニーズ，利害関係者要求事項及びシステ
ムレベルの運用概念である。
6.4.3
システム要求事項定義プロセス（System Requirements Definition process）
6.4.3.1
目的
システム要求事項定義プロセスは，要望されている能力についての利害関係者から見た利用者主体のビ
ューを，利用者にとっての運用時のニーズに合致するソリューションについての技術面のビューへ変換す
ることを目的とする。
このプロセスは，供給者の観点から，利害関係者要求事項を満足させるためには，どのような特性，属
性，並びに機能及び遂行能力・性能・運用時の実績への要求事項をシステムが備えることになるのかを仕
様化した，測定可能なシステム要求事項の集合を作り出す。
制約が許す限り，特定の実現方法については何ら示さない要求事項とすることが望ましい。
6.4.3.2
成果
システム要求事項定義プロセスの実施に成功すると次の状態になる。
a) システムソリューションのためのシステム記述が定義されている。記述にはシステムのインタフェー
ス，機能及び境界が含まれている。
b) システム要求事項（機能，遂行能力・性能・運用時の実績，プロセス，非機能，及びインタフェース
への要求事項）及び設計上の制約が定義されている。
64
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
c) 重大なシステムの遂行能力・性能・運用時の実績の測定量が定義されている。
d) システム要求事項が分析されている。
e) システム要求事項定義プロセスの実施を可能にするために必要な全てのイネーブリングシステム又は
サービスが利用可能になっている。
f)
システム要求事項と利害関係者要求事項との間のトレーサビリティが確立されている。
6.4.3.3
アクティビティ及びタスク
プロジェクトは，システム要求事項定義プロセスに関する，適用可能な組織の方針及び手順に従って，
次に示すアクティビティ及びタスクを実施しなければならない。
a) システム要求事項定義の準備を行う。このアクティビティは，次のタスクからなる。
1) 提供される振る舞い及び性質の観点から，システムの機能的な境界を定義する。
注記 機能的な境界の定義の一部は，利害関係者ニーズ及び利害関係者要求事項定義プロセスの
枠組みで定義された，利用の状況及び運用シナリオに基づいている。これには，次を含む。
利用者及び環境の振る舞いに対してシステムが受ける刺激及びそれらへのシステムの反応，
並びにシステムとその環境との間に要求される相互作用の分析及び記述。これらには，機
械的，電気的，質量，熱，データ及び手順的な流れのようなインタフェース上の性質及び
制約の観点を用いる。これによって，システムの境界となるところで期待されるシステム
の振る舞いを，定量的な用語で表現して確立する。
2) システム要求事項定義の戦略を定義する。
注記 これには，システム要求事項を識別及び定義し，ライフサイクルを通じて要求事項を管理
するために用いる取組方法を含む。
3) システム要求事項定義の支援に必要なイネーブリングシステム又はサービスを識別し計画する。
注記 これには，要求事項の識別及びイネーブリングシステムとのインタフェースを含む。シス
テム要求事項定義のためのイネーブリングシステムには，要求事項定義の促進及び要求事
項管理のためのツールを含む。
4) 利用されるイネーブリングシステム若しくはサービスを獲得する，又はそれらへのアクセスを取得
する。
注記 システム要求事項定義の実現を支援するイネーブリングシステムの支援機能が，意図され
たように利用できるかを客観的に確認するために，妥当性確認プロセスが用いられる。
b) システム要求事項を定義する。このアクティビティは，次のタスクからなる。
1) システムが遂行するよう要求されている各機能を定義する。
注記1 これは次を含む。システムが運用操作者を含めて，どのように良好に機能を遂行するこ
とが要求されているか，並びにシステムが機能を遂行することができる条件，システム
が機能の遂行を開始する条件，及びシステムが機能の遂行を停止する条件がどのような
条件であるか。機能は，重大な品質特性の分析から導出される場合もある（例えば，信
頼性のためのシステム診断機能，高頻度データバックアップ機能）。
注記2 機能の遂行能力・性能・運用時の実績に対する条件には，システム運用中に要求される
運用状態及び運用モードへの参照を組み入れることもできる。システム要求事項は，提
案されたシステム特性の抽象的な表現に大きく依存し，要望されるシステム要求事項全
体を抜け漏れなく完全に十分に記述するために，複数種類のモデル化の手法及び観点を
採用することもある。
65
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記3 対象システムの機能性の達成を支援するために要求されるイネーブリングシステムの支
援機能を，対象システムの機能と同時に識別し定義する。これは，対象システムが機能
性を達成することを支援するように，イネーブリングシステムの支援機能を識別し，か
つ，構成することを確実なものにするよう助けるために必要である。
2) 必要な実装制約条件を定義する。
注記 これには，システム構造のより高いレベルのアーキテクチャ定義から割り当てられた実装
上の決定，及び利害関係者要求事項によってもち込まれたか，又はソリューションの制限
となっている，実装上の決定を含む。
3) リスク，システムの重大性又は重大な品質特性に関連するシステム要求事項を識別する。
注記 重大な品質特性は，一般に，健康，安全性，セキュリティのアシュアランス，信頼性，ア
ベイラビリティ，及び運用の支援性に関連するものを含む。このタスクには，運用及び保
守の方法，環境上の影響並びに人員の負傷に関係するものを含めた安全性への考慮事項の
分析及びその定義を含む。
また，安全性に関する各機能及びそれに関連する安全性についての完整性が，必要なリ
スク軽減の観点から表現され，明示され，かつ，指定された安全性に関するシステムに割
り当てられることを確実にするよう支援することを含む。機能安全性に関して適用可能な
規格，例えば，JIS C 0508規格群，及び環境保護に関して適用可能な規格，例えば，JIS Q
14001が利用される。
機密の情報，データ及び資材を，危険にさらすこと及び保護することに関連するものを
含めたセキュリティの考慮事項を分析する。該当する場合には，適用できるセキュリティ
規格を利用して，管理，人員，身体，コンピュータ，通信，ネットワーク，排出物質及び
環境の要素を含めて，セキュリティに関連するリスクを定義する。ただし，リスクはこれ
らに限定されるものではない。システム及びソフトウェアのアシュアランスの手引は
ISO/IEC 15026-4を参照。ISO/IEC 27036シリーズは，製品及びサービスのアウトソーシン
グのための情報セキュリティに関する要求事項の手引を提供する。
品質要求事項に関するJIS X 25030は，外部システムの品質要因及び品質特性に関する
手引を提供する。人間との対話操作・相互作用をもつシステムでは，人的要因に対するエ
ンジニアリング（人間工学）面の仕様が検討される。使用性についての要求事項があるシ
ステムでは，使用性について要望されるレベルを得るための推奨事項を，人間中心のライ
フサイクルプロセスについて記載がある人間工学に関する標準報告書ISO/TR 18529で見
つけることもできる。
4) システム要求事項及び根拠を定義する。
注記1 これには，利害関係者要求事項，機能的な境界，機能，制約，コスト目標，識別された
インタフェース，及び重大な品質特性と一致したシステム要求事項の定義を含む。シス
テム開発の実践によって一貫して示されているように，このプロセスは，他のライフサ
イクルプロセスとともに，システムの各階層にわたって反復的・再帰的に適用する段階
的な手順を要求するものである。システム要求事項に関する追加情報はJIS X 0166の箇
条5及び箇条6を，システム要求仕様書の記述及び注釈付きの目次概要は箇条8及び箇
条9を参照。
注記2 システム要求事項は，ライフサイクルを通して，要求事項の管理に適した形式で記録さ
66
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
れる。これらの記録は，システム要求事項のベースラインを確立し，関連する論理的根
拠，決定及び前提を含む。これらは，情報項目及び次に続くシステム要素へのトレーサ
ビリティの基礎となる。システム要求事項の変更依頼は，利害関係者要求事項との一貫
性を含めて，提案された変更を受容するかを決定するために役立つ根拠も提供する。
注記3 システム分析プロセスは，システムのコスト見積り，スケジュール，及び技術面での遂
行能力・性能・運用時の実績を考慮して，要求事項のパラメータの適切な値を決定する
ために使用される。妥当性確認プロセスは，要求事項が利害関係者のニーズを満たして
いるかどうかを判定するために使用される。検証プロセスは，良い要求事項の属性及び
性質（JIS X 0166を参照）に関して，要求事項の品質を判定する。
c) システム要求事項を分析する。このアクティビティは，次のタスクからなる。
1) システム要求事項を抜け漏れなく集め，完全な全体集合にして分析する。
注記1 システム要求事項は，要求事項の集合としての特性に対して分析されるとともに，個々
の要求事項の特性に対しても分析される。個々の要求事項に関して，潜在的な可能性に
ついて分析される特性には次が含まれる。要求事項が必要なものであること，実装方法
に依存しないものであること，曖昧性がないこと，矛盾なく一貫性があること，抜け漏
れがなく完全にそろ（揃）っていること，単独性があり他の要求事項との重複がないこ
と，実現可能であること，トレース可能であること，検証可能であること，費用面で可
能であること，及び定義範囲を示す境界が明確にされていること。JIS X 0166は，要求
事項の特性についての追加情報を提供する。欠陥，矛盾点及び弱点は，システム要求事
項の完全な全体集合内で識別され，解決される。
注記2 システム分析プロセスが，システムの実現可能性，費用面での可能性及びこれらのバラ
ンスをアセスメントするために使用される。
2) 技術面での達成度のアセスメントを可能にする，重大な遂行能力・性能・運用時の実績の測定量を
定義する。
注記 これには，システム要求事項の中で識別された有効性の測定量に関連付けられた，技術面
の測定量及び品質測定量，並びに重大な遂行能力・性能・運用時の実績を表すパラメータ
を定義することを含む。重大な遂行能力・性能・運用時の実績についての測定量（例えば，
システムの遂行能力を表す運用時の実績の測定量及び技術面での性能の測定量）を，分析
及びレビューし，次のことに役立てる。システム要求事項が満たされることを確実なもの
にすること，及びプロジェクトのコスト，スケジュール又はシステムの遂行能力・性能・
運用時の実績に関する，何らかの不適合に関連したリスクの識別を確実なものにすること。
JIS X 0141は，適切な測定量を識別し，定義し，利用するためのプロセスを規定する。
INCOSE TP-2003-020-01は，重大な遂行能力・性能・運用時の実績についての測定量の選
択，定義，及び実装に関する技術面の測定について情報を提供する。JIS X 25000シリーズ
は，関連する品質測定量を提供する。
3) レビューのため，分析された要求事項を該当する利害関係者にフィードバックする。
注記 フィードバックは，指定されたシステム要求事項が適切に捉えられ，表現されていること
を確実なものにするよう助ける。システム要求事項が利害関係者要求事項への必要十分な
対応をもって応えていることの確認，並びに他のプロセス，特にアーキテクチャ及び設計
への必要十分な入力であることの確認がされる。これは，特定の要求事項に対して用いら
67
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
れる妥当性確認プロセスの適用の一つである。
4) システム要求事項の課題を解決する。
注記 これには，JIS X 0166に定義されているように，個々の要求事項又は要求事項の集合がも
つ特性を損なってしまう要求事項を課題として解決することを含む。
d) システム要求事項を管理する。このアクティビティは，次のタスクからなる。
注記 システム要求事項の維持は，例えば，アーキテクチャ，設計など他のライフサイクルプロセ
スの適用に起因する全ての変更を管理することに連動して，一般に正式の構成管理下で，ベ
ースラインを定義し，記録し，かつ，制御することを含む。
1) システム要求事項についての明示的な合意を獲得する。
注記 これには，システム要求事項が正しく表現され，要求事項を発案した各利害関係者から見
て理解できるものになっていることを確認し，かつ，要求事項間の対立した矛盾に対する
解決が，利害関係者の意図を改悪又は損なっていないことの確認を含む。
2) システム要求事項のトレーサビリティを維持する。
注記 ライフサイクルを通じて，システム要求事項と，利害関係者要求事項，アーキテクチャ要
素，インタフェース定義，分析結果，検証手法又は技法，及び割り当てられ，分割され，
導出された要求事項との間で，双方向のトレーサビリティが維持される。これは，全ての
達成可能な利害関係者要求事項が，一つ以上のシステム要求事項で満たされ，かつ，全て
のシステム要求事項が，少なくとも一つの利害関係者要求事項を満たすか又は満たすこと
に寄与することを確実なものにするよう助ける。適切なデータリポジトリによって，これ
が容易になることがよくある。
3) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが，構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス（システム要求事項定義）で，ベースラインのための候補となる情報項目を識
別し，CMへ情報項目を提供する。このプロセスにおいて，ベースライン化される典型的
な情報項目は，システム要求事項である。
6.4.4
アーキテクチャ定義プロセス（Architecture Definition process）
6.4.4.1
目的
アーキテクチャ定義プロセスは，システムアーキテクチャの代替案を作成し，利害関係者の関心事を捉
え，システム要求事項を満たす一つ以上の代替案を選定し，一貫した一連の複数のビューの中でアーキテ
クチャを表現することを目的とする。
解決するべき問題を協議によって理解し，満足するソリューションを識別するように，アーキテクチャ
定義プロセス，ビジネス又はミッション分析プロセス，システム要求事項プロセス，設計定義プロセス，
並びに利害関係者ニーズ及び利害関係者要求事項定義プロセスを反復して用いることがよくある。アーキ
テクチャ定義プロセスの結果はライフサイクルプロセスにわたって広く用いられる。アーキテクチャ定義
は多くの抽象的なレベルに適用することができ，そのレベルでの決定に必要な関連する詳細を強調する。
注記1 システムアーキテクチャは，基本となる原則，概念，性質及び特性，並びにそれらの対象シ
ステムへの組込みを扱う。アーキテクチャ定義は単に設計を駆動するもの（又は設計の一部）
というだけではなく，それ以上の用途がある。アーキテクチャ記述，並びにアーキテクチャ
の用途及び性質についての詳細はISO/IEC/IEEE 42010:2011を参照。
注記2 アーキテクチャ定義プロセスは，複数の利害関係者の識別及びそれら利害関係者の関心事の
68
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
識別を支援する。プロセスが進むにつれ，システムに対して指定された要求事項と，システ
ム要素間の相互作用及び関係から生じて，システムに発現する特性である創発性（emergent
properties）及びシステムの振る舞いとの間の関係について洞察が得られる。
一方，設計定義プロセス（6.4.5）は，アーキテクチャ及び実現可能性についてのより詳細
な分析によって入念に精査された要求事項によって駆動される。アーキテクチャは，システ
ムの目的に適合できる特性，実行可能性，及び望ましさの特性に焦点を当て，一方で設計は，
技術及び他の設計要素との互換性，並びに構築及びインテグレーションの実現可能性に焦点
を当てている。効果的なアーキテクチャは，可能な限り設計にとらわれることなく，設計ト
レードオフ空間の中で最大限の柔軟性をもったものである。
効果的なアーキテクチャは，また，設計定義プロセスに対して，トレードオフの所在を強
調し，支援する。ほかにもポートフォリオ管理，プロジェクト計画，システム要求事項定義，
検証などのプロセスに対して，同様にトレードオフの所在を示す可能性がある。
注記3 プロダクトラインアーキテクチャでは，アーキテクチャは幾つかの設計にまたがっている必
要がある。アーキテクチャはプロダクトラインをまとまりのあるものにし，プロダクトライ
ンにわたって互換性及び相互運用性を確実なものにすることを支援する。一つの製品のシス
テムに対しても，アーキテクチャが一定で変わらない一方で，時間の経過とともに製品の設
計が変化する可能性がある。
6.4.4.2
成果
アーキテクチャ定義プロセスの実施に成功すると次の状態になる。
a) 識別された利害関係者の関心事がアーキテクチャで取り組まれている。
b) アーキテクチャ ビューポイントが作成されている。
c) システムが利用される状況，境界及び外部インタフェースが定義されている。
d) システムのアーキテクチャ ビュー及びモデルが作成されている。
e) システムのアーキテクチャの決定に重要な概念，性質，特性，振る舞い，機能又は制約が，アーキテ
クチャの要素となる実体（architectural entities，以下，アーキテクチャ エンティティという。）に割り
当てられている。
f)
システム要素及びシステム要素間のインタフェースが識別されている。
g) アーキテクチャ候補のアセスメントが行われている。
h) ライフサイクル全体にわたるプロセスに対するアーキテクチャの基礎の構築が達成されている。
i)
アーキテクチャの，要求事項と設計特性との整合が達成されている。
j)
アーキテクチャ定義の実施を可能にするために必要な全てのイネーブリングシステム又はサービスが
利用可能になっている。
k) アーキテクチャ要素と，利害関係者要求事項及びシステム要求事項との間のトレーサビリティが構築
されている。
6.4.4.3
アクティビティ及びタスク
プロジェクトは，アーキテクチャ定義プロセスに関する，適用可能な組織の方針及び手順に従って，次
に示すアクティビティ及びタスクを実施しなければならない。
a) アーキテクチャ定義の準備を行う。このアクティビティは，次のタスクからなる。
1) システムの核心に関する情報をレビューし，アーキテクチャを駆動する重要な事項を識別する。
注記 次に示す，アーキテクチャ定義を駆動する重要事項をレビューによって識別する。
69
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
− 市場調査，産業予測，競合製品計画，及び科学的発見
− 組織の戦略，組織レベルの運用概念，組織の方針及び指示，規制及び法令による制約，
並びに利害関係者要求事項
− ミッション又はビジネスの組織レベルの運用概念，システムレベルの運用概念，運用
環境，技術ロードマップ，及びシステム要求事項
− ライフサイクル全体を通じてシステムの目的への適合性に影響を与える他の要因
2) 利害関係者の関心事を識別する。
注記 利害関係者は，利害関係者ニーズ及び利害関係者要求事項定義プロセスで最初に識別され，
通常は，アーキテクチャ定義プロセスを実施する間に追加の利害関係者が識別される。ア
ーキテクチャに関連する利害関係者の関心事には，次のようなシステムのライフサイクル
に関係する期待及び制約がある。
− 利用（例えば，アベイラビリティ，セキュリティ，有効性，使用性），運用・保守の支
援（例えば，修復性，陳腐化の管理）
− システム及び環境の発展的な開発（例えば，適応性，拡張性，生存性）
− 生産（例えば，生産可能性・製造性，テスト容易性），廃棄（例えば，環境への影響，
輸送性）など。
これには，意図の有無に関係なく，脅威を与え得る者によって，又は安全性を脅かすハ
ザードによって偶発的に，システムが侵害される懸念についての関心事も含まれる。
3) アーキテクチャ定義ロードマップ，取組方法及び戦略を定義する。
注記 これには，利害関係者が参加して合意する機会の識別，アーキテクチャのレビューをする
アクティビティの定義，評価の取組方法及び評価基準の定義，測定の取組方法，並びに測
定手法（測定プロセスを参照）を含める。ロードマップでは，アーキテクチャをどのよう
に目指す最終の状態へと発展させるのかを示す。このため，その時点での当面の対象シス
テムに対する時間枠よりも，更に長い時間枠をもつことがよくある。取組方法は，利害関
係者と共同作業して合意する方法，結果の入念な精査方法，作業を行う場所など，作業を
達成するための方法である。戦略は，ロードマップとの一貫性をもった取組方法を実施す
るための系統的な行動計画を扱う。
4) 利害関係者の関心事及び重要な要求事項に基づく評価指標を定義する。
5) アーキテクチャ定義プロセスを支援するために必要なイネーブリングシステム又はサービスを識別
し計画する。
注記 これには，アーキテクチャ定義を有効なものにするよう支援するイネーブリングシステム
のための要求事項及びインタフェースの識別を含む。アーキテクチャ定義のためのイネー
ブリングシステムは，共同作業及びアーキテクチャを開発するためのツール及びアーキテ
クチャの再利用リポジトリ（アーキテクチャ パターン，アーキテクチャ成果物，参照アー
キテクチャなどのためのもの）を含む。
6) 利用されるイネーブリングシステム若しくはサービスを，獲得する又はそれらへのアクセスを取得
する。
注記 アーキテクチャ定義の実現を支援するイネーブリングシステムの支援機能が，意図された
ように利用できるかを客観的に確認するために，妥当性確認プロセスが用いられる。
b) アーキテクチャ ビューポイントを開発する。このアクティビティは，次のタスクからなる。
70
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
1) 利害関係者の関心事に基づくビューポイント及びモデルの種別を選定するか，適応させるか，又は
策定する。
2) モデル及びビューを策定するために用いられる可能性のあるアーキテクチャ フレームワークを確
立又は識別する。
注記 幾つかのアーキテクチャ フレームワークは，利害関係者及びそれらの関心事，並びにそれ
らの関心事を取り上げた関心事に関連するビューポイントを識別する。一方で，他のアー
キテクチャ フレームワークは，より一般的な手引となる。ビューポイントは，用いられる
モデルの種別を規定し，結果として得られるモデルを用いてアーキテクチャ ビューを作り
出すための方法を規定する。アーキテクチャ フレームワーク及びアーキテクチャ記述の実
践に関する詳細情報については，ISO/IEC/IEEE 42010を参照。
3) フレームワーク，ビューポイント及びモデル種別の選定の根拠を捕捉して形あるものに記録する。
4) モデルの策定を支援する技法及びツールを選定又は開発する。
c) 候補となるアーキテクチャのモデル及びビューを策定する。このアクティビティは，次のタスクから
なる。
1) システム外部エンティティとのインタフェース及び相互作用によって，システムが利用される状況
及びシステムの境界を定義する。
注記1 このタスクは主にビジネス又はミッション分析プロセスの成果に基づいて実施し，利害
関係者ニーズ及び利害関係者要求事項定義プロセスと同時並行させて遂行する。タスク
は，システム外部エンティティ（システムが利用される状況を構成する，既存及び将来
に存在することが予測されるシステム，製品及びサービス）を識別し，システムの境界
（境界を横切るインタフェースを通じて行う，これらのシステム外部エンティティとの
相互作用）を定義することからなる。システム外部エンティティには，必要となるイネ
ーブリングシステムを含められる。アーキテクチャ定義プロセスは，重要なアーキテク
チャの決定及び理解を支援するために必要な範囲に対してインタフェースを定義する。
さらに，これらのインタフェース定義は，設計定義プロセスによって詳細化される。
注記2 システム外部エンティティ（external entities, entities external to the system）とは，対象シ
ステムの外部に存在する複数の実体で，対象システムの外部を構成する要素であり，対
象システムと相互作用する。対象システムの外部に現時点で存在しているか，又は将来
には存在する可能性があると判断されるシステム，製品及びサービスを指す。
2) 重要な利害関係者の関心事及び重大なシステム要求事項を取り扱うアーキテクチャ エンティティ
及びそれらのエンティティ間の関係を識別する。
注記 アーキテクチャは必ずしも全ての要求事項に関係するのではなく，アーキテクチャを駆動
する要求事項と関係する。逆に，設計定義プロセスは全ての要求事項を考慮する。場合に
よっては，アーキテクチャ定義プロセスを通して，不適切か，費用面で引き合わないか，
又はシステムの目的に適合するものではないとみなされる要求事項があるが，それらはシ
ステム要求事項定義プロセスの反復を通して解決する要求事項の課題となる。重要な利害
関係者の関心事の全てが，要求事項として捕捉されて形あるものに記録されるとは限らな
いため，アーキテクチャが重要な利害関係者の関心事を取り扱うことも重要である。
3) システムのアーキテクチャの決定に重要な概念，性質，特性，振る舞い，機能又は制約を，アーキ
テクチャ エンティティへ割り当てる。
71
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記 割り当てられる項目は，物理的，論理的又は概念的なものである場合もある。
4) 候補となるシステムのアーキテクチャを選定するか，適応させるか又は開発する。
注記 一般的にはアーキテクチャ定義でモデルを用いる。用いられるモデルは利害関係者の関心
事を取り扱うのに最も適したモデルにする。どのように行うかはISO/IEC/IEEE 42010に
記載がある。アーキテクチャ定義の中で論理モデル及び物理モデルを用いることが，これ
まで一般的である。論理モデル，物理モデル及びその他のモデルに関する情報は附属書F
に記載している。
5) アーキテクチャがどのように利害関係者の関心事を取り上げ，利害関係者及びシステム要求事項に
合致するかを表すため，識別したビューポイントに従ってモデルからビューを構成する。
6) アーキテクチャ モデルとアーキテクチャ ビューとを互いに調和させる。
注記 アーキテクチャ フレームワークからの対応規則は，ビュー間の調和を確立する一つの方法
である。ISO/IEC/IEEE 42010を参照。
d) アーキテクチャを設計に関係付ける。このアクティビティは，次のタスクからなる。
1) アーキテクチャ エンティティ及びそれらのエンティティ間の関係がもつ性質に関わる，システム要
素を識別する。
注記 システム要素は，実際に行われる設計に依存するため，設計定義を行うまで，当初は概念
的であることがよくある。アーキテクチャの意図を伝え，設計の実現可能性をチェックす
る方法として，概念的なシステム要素を用いて“参照アーキテクチャ”を作ることがよく
ある。
2) システム要素とシステム外部エンティティとの間のインタフェース及び相互作用を定義する。
注記 これはアーキテクチャの意図を伝えるのに必要な詳細度で定義され，設計定義プロセスで
更に詳細化される。
3) アーキテクチャ エンティティ及びシステム要素に対して要求事項を分割し，互いに整合するように
して，割り当てる。
4) システム要素及びアーキテクチャ エンティティと設計特性とを対応付ける。
5) システムの設計及び発展に対する原則を定義する。
e) アーキテクチャ候補のアセスメントを行う。このアクティビティは，次のタスクからなる。
1) 各アーキテクチャ候補を，制約及び要求事項に対してアセスメントする。
2) 評価基準を用いて，各アーキテクチャ候補を，利害関係者の関心事に対してアセスメントする。
注記 このタスクを支援するため，システム分析プロセス及びリスク管理プロセスが用いられる。
3) 好ましいアーキテクチャを選定し，重要な決定及び根拠を捕捉して形あるものとして記録する。
注記 このタスクを支援するため，意思決定管理プロセスが用いられる。
4) 選定されたアーキテクチャのアーキテクチャ ベースラインを確立する。
注記 アーキテクチャ ベースラインは，モデル，ビュー，及び他の関係するアーキテクチャ記述
からなる。
f)
選定されたアーキテクチャを管理する。このアクティビティは，次のタスクからなる。
1) アーキテクチャを統括する取組方法を正式なものとし，統括に関係する役割及び責任，説明責任，
並びに権限（設計，品質，セキュリティ，安全などに関係する。）を規定する。
2) アーキテクチャについての利害関係者による明示的な受入れを獲得する。
注記1 アーキテクチャ モデル及びビューが，利害関係者及びシステム要求事項を反映している
72
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
ことを確認するために，検証及び妥当性確認プロセスが用いられる。
注記2 アーキテクチャを認証することが必要となるシステムの応用分野がある。認証で確認す
ることは，アーキテクチャの意図に合致し，アーキテクチャがもつ展望及び重要な概念
が正しく実装され，利害関係者の関心事が正しく取り扱われていることである。また，
学習するプロセスを支援し，アーキテクチャを将来にわたって反復して設計することで，
利害関係者の関心事をより確実に取り扱ったアーキテクチャにすることを支援するため，
アーキテクチャ定義プロセスにとって重要なフィードバックを提供する。
3) アーキテクチャ エンティティ及びそれらのアーキテクチャ特性の調和性及び完全性を維持する。
注記 チェックするべきアーキテクチャ エンティティは技術面だけではない。例えば，通常では
利害関係者の要求事項及び関心事の一部として，法律面，経済面，組織面及び運用面のア
ーキテクチャ エンティティもある。
4) アーキテクチャ モデル及びビューの発展を体系化し，アセスメントし，制御する。
5) アーキテクチャ定義及び評価戦略を保守する。
注記 これには，システムを分解したレベルで定義される外部及び内部インタフェースの管理と
ともに，技術面，実装面及び運用面の経験に基づくアーキテクチャの更新を含む。
6) アーキテクチャのトレーサビリティを維持する。
注記 ライフサイクルを通じて，要求事項（割り当てられ，分解され，導出された要求事項を含
む。），インタフェース定義，分析結果，及び検証の手法又は技法に対し，アーキテクチャ エ
ンティティ（モデル，ビュー及びビューポイント）との間で，双方向のトレーサビリティ
を維持する。可能ならば，トレーサビリティは，アーキテクチャ エンティティと利害関係
者の関心事との間でも維持される。
7) ベースラインに対して選定された重要な情報項目を提供する。
注記 構成管理プロセスは，構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス（アーキテクチャ定義）は，このベースラインに対してアーキテクチャ候補を
識別し，そしてその情報項目をCMへ提供する。
6.4.5
設計定義プロセス（Design Definition process）
6.4.5.1
目的
設計定義プロセスは，システムアーキテクチャのモデル及びビューで定義されるアーキテクチャ エンテ
ィティとの一貫性をもった実装を可能にするために，システム及びその構成要素に関する十分に詳細なデ
ータ及び情報を提供することを目的とする。
注記1 アーキテクチャ定義プロセスでは，利害関係者の識別及び利害関係者の関心事の識別を支援
する。アーキテクチャ プロセスを用いることで，システムに対して指定された要求事項と，
システム要素間の相互作用及び関係から生じて，システムに発現する特性である創発性及び
システムの振る舞いとの関係についての洞察が得られる。一方，設計定義プロセスは，アー
キテクチャ及び実現可能性についてのより詳細な分析によって入念に精査された要求事項に
よって駆動される。アーキテクチャでは，システムの目的に適合できる特性，実行可能性，
及び望ましさの特性に焦点を当て，設計は，技術及び他の設計要素との互換性，並びに構築
及びインテグレーションの実現可能性に焦点を当てる。設計トレードオフ空間の中で最大限
の柔軟性を備え，可能な限り設計にとらわれないアーキテクチャが有効なアーキテクチャで
ある。
73
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記2 設計定義では，適用可能な技術及びそれら技術によるシステムソリューションへの貢献を考
慮する。設計は，図面及び詳細な設計記述のような，定義の“実現方法”レベルを提供する。
注記3 この設計定義プロセスは，システムを構成するシステム要素へのアーキテクチャ エンティテ
ィの割当て，分割及び相互の整合性を確固たるものにし，又は確認するために，システムア
ーキテクチャにフィードバックを提供する。
6.4.5.2
成果
設計定義プロセスの実施に成功すると次の状態になる。
a) 各システム要素の設計特性が定義されている。
b) システム要求事項はシステム要素に割り当てられている。
c) 設計定義に必要な設計実現手段（enabler）が選択又は定義されている。
d) システムを構成するシステム要素間のインタフェースが定義又は詳細化されている。
e) システム要素の設計選択肢がアセスメントされている。
f)
設計作成物が作成されている。
g) 設計定義の実施を可能にするために必要な全てのイネーブリングシステム又はサービスが利用可能に
なっている。
h) 設計特性と，システムアーキテクチャのアーキテクチャ エンティティとの間のトレーサビリティが確
立されている。
6.4.5.3
アクティビティ及びタスク
プロジェクトは，設計定義プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアク
ティビティ及びタスクを実施しなければならない。
a) 設計定義の準備を行う。このアクティビティは，次のタスクからなる。
1) システムを構成する各システム要素に要求される技術を決定する。
注記 システム要素（例えば，機械，エレクトロニクス，ソフトウェア，運用操作者の役割など）
には，幾つかの複数の技術が使用されることがある。
2) 必要な設計特性の種別を決定する。
注記 各技術に対して，必要な設計特性の種別（例えば，詳細なパターン，構造，サイズ，量，
基準寸法，テンプレートなど）が定義される。設計特性には，セキュリティに関する次の
ような事項の考慮が含まれる。最小権限の原則，多層防御，システムサービスへのアクセ
ス制限，並びにシステムへの攻撃にさらされる境界面の最小化及び防護。
3) 設計の発展についての原則を定義する。
注記 これには次を含む。
− システム及びそのアーキテクチャが発展する場合には，設計特性の定期的なアセスメ
ントを定義すること。
− システム要素及び技術に起こり得る潜在的な陳腐化を予測すること。
− システムのライフサイクルにわたる時間の経過に伴う，他のシステム要素及び技術へ
の置換えを予測すること。
− 設計定義の最終的な結果を予測すること。
4) 設計定義の戦略を定義する。
5) 設計定義を支援するために必要なイネーブリングシステム又はサービスを識別し計画する。
注記 これは，イネーブリングシステムの要求事項及びインタフェースの識別を含む。設計定義
74
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
のイネーブリングシステムは，共同作業及び設計開発のためのツール並びに設計再利用リ
ポジトリ（設計パターン，設計作成物，設計基準などのためのもの）を含む。
6) 利用されるイネーブリングシステム若しくはサービスを，獲得する又はそれらへのアクセスを取得
する。
注記 設計定義の実現を支援するイネーブリングシステムの支援機能が意図されたように利用で
きるかを客観的に確認するために，妥当性確認プロセスが用いられる。
b) 各システム要素に関連する設計特性及び設計実現手段を確立する。このアクティビティは，次のタス
クからなる。
1) システム要求事項をシステム要素に割り当てる。
注記 システム要求事項の幾つかは，アーキテクチャ定義の中でシステム要素に既に割り当てら
れている場合がある。このタスクの目的は，全てのシステム要求事項に対処するために，
必要な範囲で割当てを完了することである。
2) アーキテクチャ特性を設計特性に変換する。
注記 このタスクでは，システム要素に割り当てられたアーキテクチャ エンティティに関連する
各アーキテクチャ特性を，図面，ダイアグラム，モデル，アーキテクチャ，測定法及びそ
れらの値を列記した表などの必要十分な表現を使用して，設計特性（寸法，形状，材料，
重大な品質特性，データ処理構造など）に変換する。（この段階で関連する場合には）全て
のデータは，実装のための詳細な許容される誤差・あそび値に関連付けられている。
3) 必要な設計実現手段を定義する。
注記 このタスクでは，設計特性の実現に必要な設計実現手段を定義及び／又は選択する。設計
実現手段としては，設計特性に関連するモデル，方程式，アルゴリズム，計算，形式的記
述表現及びパラメータ値，パターン，試行錯誤による発見的な手段などがある。計画され
た運用環境の利用状況における互換性，費用面での可能性，セキュリティ，及びその他の
重大な特性は，必要な設計実現手段を定義する中で考慮する事項である。JIS Z 8530は人
間中心設計・人間工学的設計の指針を提供する。
4) 設計の代替案を詳細調査する。
注記 設計特性の実現可能性をアセスメントし，設計特性を実装できない場合には，アーキテク
チャ又は要求事項の中でトレードオフして調整する。
5) システム要素とシステム外部エンティティとのインタフェースを詳細化又は定義する。
注記 インタフェースは，アーキテクチャ定義プロセスで，アーキテクチャの意図及び理解に必
要なレベル又は度合いまで識別及び定義される。それらは，設計定義プロセスで，設計特
性，並びにシステム要素と，システムを構成する他のシステム要素，及びシステム外部エ
ンティティとのインタフェース及び相互作用に基づいて詳細化される。アーキテクチャ定
義で対処されていない追加のインタフェースを識別及び定義する必要がある可能性がある。
6) 設計作成物を確立する。
注記 このタスクでは，実装技術に依存した専用の作成物を作ることを通してシステム要素の設
計特性を形式性のある記述にする。そうした作成物の例として，データシート（電子部品
についての記述），データベース（ソフトウェアについての記述を格納），文書類（運用操
作者の役割についての記述），及び外部のデータ形式へ変換可能なデータファイル（機械加
工についての記述）がある。
75
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
c) システム要素を取得するための代替案をアセスメントする。このアクティビティは，次のタスクから
なる。
1) 利用する場合があると考えられる非開発項目（NDI）の候補を識別する。
注記 これには，商用既製品（COTS，Commercial-Off-The-Shelf），以前の設計の再利用又は取得
者からの提供品目が含まれる。
2) 意図する適用の目的への適合性を判断するために，期待される設計特性又はシステム要素の要求事
項から作成された判断基準に照らして，各NDIの候補及び新しい設計代替案をアセスメントする。
3) 任意のNDIソリューションの候補，及びシステム要素の新しい設計代替案の中から，好ましい案を
決定する。
注記 システム分析プロセスは，選択を実行する意思決定管理プロセスと同じく，分析又はアセ
スメントで用いられる。
d) 設計を管理する。このアクティビティは，次のタスクからなる。
1) 設計特性をシステム要素に至るまで対応付ける。
注記1 このタスクでは，詳細設計特性とシステムアーキテクチャのアーキテクチャ エンティテ
ィとの間のトレーサビリティを確立することからなる。
注記2 これは，上位レベルの親システムアーキテクチャが利害関係者の関心事を満たすために
期待されるアーキテクチャ特性（例えば，モジュール性，使用性，相互運用性，事故予
防用の安全機構など）を得るために，可能ならばシステム要素の物理的配置を変更する
ような，アーキテクチャ定義プロセスへのフィードバックをすることを容易にする。
2) 設計及び根拠を捕捉して形あるものに記録する。
注記1 根拠には，主要な実装の選択肢，及び実現手段に関する情報が含まれる。
注記2 詳細設計特性及び実装の選択肢を検証及び妥当性確認するために，検証及び妥当性確認
プロセスが実行される。
3) 設計のトレーサビリティを維持する。
注記 ライフサイクルを通じて，設計特性と，アーキテクチャ エンティティ，識別されたインタ
フェース，分析結果，検証方法又は技法及びシステム要素の要求事項との間で，双方向の
トレーサビリティを維持する。
4) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが，構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス（設計定義）で，ベースラインのための候補となる情報項目を識別し，CMへ
情報項目を提供する。
6.4.6
システム分析プロセス（System Analysis process）
6.4.6.1
目的
システム分析プロセスは，ライフサイクル全体にわたる意思決定を支援するために，技術面の理解のた
めの厳密なデータ及び情報の基盤を提供することを目的とする。
システム分析プロセスは，技術面のアセスメントに必要な入力の開発に適用する。それは，システム要
求事項，アーキテクチャ，並びに設計の有用性及び完整性に対する信頼を提供することができる。システ
ム分析は，幅広く異なる分析機能，複雑さのレベル及び厳密さのレベルを包含する。
システム分析には，数学的分析，モデル化，シミュレーション，実験及びその他の技法を含む。それら
の分析技法は，技術面での遂行能力・性能・運用時の実績，システムの振る舞い，実現可能性，費用面で
76
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
の可能性，重大な品質特性，技術面のリスク，及びライフサイクルのコストの分析，並びに全てのライフ
サイクル段階にわたるパラメータの可能性のある値の範囲についての感度分析の実行のための技法である。
システム分析は，システムレベルの運用概念，要求事項とする値の決定，要求事項間の対立した矛盾の
解決，代替アーキテクチャ又は代替システム要素のアセスメント，及びエンジニアリング戦略（どのよう
に統合し，検証し，妥当性確認及び保守するか）の評価に関する幅広い分析ニーズに使用される。
分析の正式さ及び厳密さの度合いは，分析して支援する情報ニーズ又は作業成果物の重大性，利用可能
な情報・データの量，プロジェクトの規模，及び結果を得るためのスケジュールに依存する。
注記 このプロセスは，意思決定管理プロセスとともに用いられることがよくある。
6.4.6.2
成果
システム分析プロセスの実施に成功すると次の状態になる。
a) システム分析ニーズが識別されている。
b) システム分析の前提条件及び結果の妥当性が確認されている。
c) システム分析の結果が意思決定に提供されている。
d) システム分析に必要とする全てのイネーブリングシステム又はサービスが利用可能になっている。
e) システム分析結果のトレーサビリティが確立されている。
6.4.6.3
アクティビティ及びタスク
プロジェクトは，システム分析プロセスに関する，適用可能な組織の方針及び手順に従って，次に示す
アクティビティ及びタスクを実施しなければならない。
a) システム分析の準備を行う。このアクティビティは，次のタスクからなる。
1) システム分析が要求される問題又は質問を識別する。
注記 これには，分析の技術面，機能面及び非機能面の目標が含まれる。非機能面の目標には，
重大な品質特性，様々な特性，技術面の成熟度，製造面の成熟度，技術面のリスクなどが
含まれる。分析によって回答しようとする，問題の記述又は質問は，分析の目標，並びに
分析結果の期待及び有用性を確立するため，欠くことができない。
2) システム分析の利害関係者を識別する。
3) システム分析の範囲，目標及び実際を忠実に表現するレベルを定義する。
注記 必要とされる，実際を忠実に表現する度合い（正確性又は精度）のレベルは，厳密さの適
切なレベルを決定する要因である。
4) システム分析の方法を選択する。
注記 分析方法は，分析に要する時間，コスト，分析方法が実際を忠実に表現する度合い，技術
面の駆動要因及び分析の重大さに基づいて選択する。分析方法には，幅広いレベルの厳密
さがあり，専門家の判断，人手による簡易計算，表計算，履歴データ及び傾向分析，エン
ジニアリングのモデル，シミュレーション，視覚化並びにプロトタイピングが含まれる。
コスト及びスケジュールの制約によって，ほとんどのシステムでは，重大な特性に対する
システム分析だけを実行することになる。
5) システム分析戦略を定義する。
6) システム分析を支援するために必要とするイネーブリングシステム又はサービスを識別し計画す
る。
注記 これには，イネーブリングシステムの要求事項及びインタフェースの識別を含む。システ
ム分析用イネーブリングシステムには，分析を支援するために必要なツール，関連モデル，
77
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
及び分析に利用できる可能性のあるデータリポジトリが含まれる。選択された方法は，ど
のツールが分析を支援するのに適しているかを決定する主要な要因となる。これには，関
連するモデル及びデータのアベイラビリティを決定することも含まれている。
7) 利用されるイネーブリングシステム若しくはサービスを，獲得する又はそれらへのアクセスを取得
する。
注記 システム分析の実現を支援するイネーブリングシステムの支援機能が，意図されたように
利用できるかを客観的に確認するために，妥当性確認プロセスが用いられる。
8) 分析のために必要なデータ及び入力を集める。
b) システム分析を実施する。このアクティビティは，次のタスクからなる。
1) 前提条件を識別し，その妥当性を確認する。
2) 要求されるシステム分析を実行するために，選択された分析方法を適用する。
3) 品質及び妥当性に対して，分析結果をレビューして吟味する。
注記 結果は，それ以前に完了した関連する分析と合わせて調整される。
4) 結論及び勧告を確定する。
注記 このタスクでは，システム分析で扱う内容に関する適切な専門家及び利害関係者を識別し，
参加を得る。
5) システム分析の結果を記録する。
c) システム分析を管理する。このアクティビティは，次のタスクからなる。
1) システム分析の結果のトレーサビリティを維持する。
注記 ライフサイクルを通じて，システム分析結果と，分析が決定を支持しているか又は根拠を
提供しているシステム定義項目（例えば，システム要求事項として求められた定量値，ア
ーキテクチャの代替案）との間で，双方向のトレーサビリティが維持される。これは，適
切なデータリポジトリによって容易になることがよくある。
2) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスは，構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス（システム分析）は，ベースラインの候補を識別し，情報項目を構成管理に提
供する。このプロセスでは，分析結果又は報告がベースライン化される典型的な情報項目
である。
6.4.7
実装プロセス（Implementation process）
6.4.7.1
目的
実装プロセスの目的は，指定されたシステム要素を実現することである。
実装プロセスは，インタフェースを含む要求事項，アーキテクチャ及び設計を，選択された実装技法の
実践方法に従って，適切な技術専門性又は規範を用い，システム要素を作成する作業に変換する。このプ
ロセスの結果として，規定されたシステム要求事項（割り当てられた要求事項及び導出された要求事項を
含む。），アーキテクチャ及び設計を満たすシステム要素を生成する。
注記 これは，単一の要素（概念及び開発段階）及び（生産の段階における）生産の実行の両方に適
用される。これは，支援の段階で必要とされる変更の解決にも適用できる。
6.4.7.2
成果
実装プロセスの実施に成功すると次の状態になる。
a) 要求事項，アーキテクチャ又は設計に影響を及ぼす実装の制約が識別されている。
78
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
b) システム要素が実現されている。
c) システム要素が一つにまとめられパッケージ化されているか又は保管されている。
d) 実装の実施を可能にするために必要な全てのイネーブリングシステム又はサービスが利用可能になっ
ている。
e) トレーサビリティが確立されている。
6.4.7.3
アクティビティ及びタスク
プロジェクトは，実装プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアクティ
ビティ及びタスクを実装しなければならない。
a) 実装の準備を行う。このアクティビティは，次のタスクからなる。
1) 実装戦略を定義する。
注記1 実装戦略には，新規作成，新規取得又は（変更の有無にかかわらず）既存要素の再利用
が含まれる。再利用する戦略である場合は，プロジェクトは再利用されるシステム要素
が対応するシステム階層中のレベル，システム要素の供給源及び再利用目的への適合性
を決定する必要がある。実装戦略には，実装手順，組立てプロセス，ツール及び機器，
実装の許容誤差，並びに検証の不確実性が含まれる。システム要素の実装が繰り返され
る場合（例えば，大量生産，システム要素の置換）は，一貫性及び再現性のある生産可
能性・製造性を達成するために実施する実装手順及び組立てプロセスが定義される。
注記2 実装戦略では，合意プロセスを呼び出して実行するか，又は実装に合わせて特化したラ
イフサイクル開発及び支援環境を含む，イネーブリングシステム及びサービスを要求す
ることがよくある。
2) システム要求事項，アーキテクチャ特性，設計特性又は実装技法に課される制約を，実装戦略及び
実装技術に関して識別する。
注記 これには，次に関する現在及び将来の予想される制限が含まれる。
− 選択された実装技術，適用するために取得者が供給した資材又はシステム要素
− 要求された実装支援用イネーブリングシステムを利用した結果の制限
3) 実装を支援するために必要とするイネーブリングシステム又はサービスを識別し計画する。
注記 これには，イネーブリングシステムの要求事項及びインタフェースを含む。
4) 利用されるイネーブリングシステム若しくはサービス，及び資材を，獲得する又はそれらへのアク
セスを取得する。
注記 実装・インテグレーションの実現を支援するイネーブリングシステムの支援機能が，意図
されたように利用できるかを客観的に確認するために，妥当性確認プロセスが用いられる。
b) 実装を行う。このアクティビティは，次のタスクからなる。
注記 実装プロセスを通じて，検証プロセスは，要求事項に対するシステム要素の適合性及び製品
の品質特性を客観的に確認するために用いられる。妥当性確認プロセスは，利害関係者要求
事項に対応するように，意図された運用環境でシステム要素を使用することが可能な状態に
あることを客観的に確認するために用いられる。
1) 戦略，制約，及び定義された実装手順に従って，システム要素を実現又は適応させる。
注記 これは，実装支援用イネーブリングシステム及び指定された資源を使用して行われる。シ
ステム要素の実現には，それらの開発又は取得を含めてもよい。適応には，再利用又は変
更されたシステム要素を構成して実装することが含まれる。実現又は適応は，適用可能な
79
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
安全性，セキュリティ，プライバシー，及び環境指針又は法令，並びに関連する実装技術
の実践方法を統括する標準に沿って行う。
− ハードウェア
ハードウェア要素は，取得されるか又は組立て・製造される。ハードウェア要素は，
選択された物理的な実装技術及び資材に関連する適用可能な技術を用いて組立て・製
造される。適切な場合は，ハードウェア要素が，指定されたシステム要求事項及び重
大な品質特性に適合していることが検証される。
− ソフトウェア
ソフトウェアで実現されるシステム要素は，取得されるか又は開発される。適切な
場合は，これらの要素はシステム要求事項及び設計基準に適合していることが検証さ
れる。ISO/IEC/IEEE 12207は，ソフトウェアで実現されるシステム要素に適用される。
− サービス
サービス要素には，提供される一連のサービスが含まれる。適切な場合は，サービ
ス要素が，システム要求事項及びサービス基準に適合していることが検証される。JIS
Q 20000-1:2012（IEEE Std 20000-1-2013）は，サービスで実現されるシステム要素に
適用される。
− 利用及び支援の資源
その他のシステム要素には，運用手順，保守手順，利用者の教育訓練などの，利用
及び支援の資源が含まれる。適切な場合は，利用及び支援の資源の要素が，システム
要求事項及びシステムレベルの運用概念に適合していることが検証される。
2) システム要素を一つにまとめてパッケージ化し，保管する。
注記 システム要素がもっている特性の持続を達成するために，システム要素を保つ。運搬及び
保管，並びにそれらの期間は，指定された特性保持の制御に影響を及ぼす。最終的な構成
及び製品情報は，システム要素が保管されるときに，構成管理及び情報管理プロセスによ
って，捕捉され，形あるものに記録保存される。
3) システム要素がシステム要求事項に合致することを示す客観的証拠を記録する。
注記 証拠は，供給合意，法律及び組織方針に従って提供される。証拠には，処理の変更による
要素の変更，又は検証及び妥当性確認プロセスで見つかった不適合のために行われた要素
の変更が含まれる。客観的証拠は，構成管理プロセスを通じて確立された，システム要素
の，実際に実装されたときの実装構成ベースラインの一部となる。客観的証拠には，単体
テスト，分析，インスペクション，ウォークスルー実施イベント，実演による実証説明，
製品レビュー若しくは技術レビュー，又はその他の検証を実行した結果が含まれる。
c) 実装の結果を管理する。このアクティビティは，次のタスクからなる。
1) 実装結果及び遭遇した全ての不具合（anomalies）を記録する。
注記 これには，実装戦略，実装支援用イネーブリングシステム，又は誤りのあるシステム定義
を起因とした不具合が含まれる。根本原因を識別し，是正処置又は改善作業を実現可能に
し，かつ，学んだ教訓を記録する目的でデータを分析するために，プロジェクトアセスメ
ント及び制御プロセスが用いられる。
2) 実装されたシステム要素のトレーサビリティを維持する。
注記 実装されたシステム要素と，実装に必要なインタフェース要求事項及び定義を含むシステ
80
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
ム要求事項，システムアーキテクチャ，並びに設計との間で，双方向のトレーサビリティ
が維持される。
3) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが，構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス（実装）で，ベースラインのための候補となる情報項目を識別し，そしてCM
へ情報項目を提供する。このプロセスにおいてベースライン化される典型的な情報項目は，
システム要素である。
6.4.8
インテグレーションプロセス（Integration process）
6.4.8.1
目的
インテグレーションプロセスは，システム要求事項，アーキテクチャ及び設計を満たす，実現されたシ
ステム（製品又はサービス）へと，システム要素の集合を統合することを目的とする。
このプロセスは，実装されたシステム要素を組み立てる。システム要素の相互運用を意図どおりできる
ようにするために，インタフェースを識別し，有効化する。このプロセスでは，相互運用が容易となるよ
う，イネーブリングシステムを対象システムと統合する。
注記1 このプロセスでは，指定されたシステム階層レベルについて，製品又はサービスを構築する
ために，実装されたシステム要素を繰り返し組み合わせ，完全に要素をそろえたシステム構
成か，又は部分的なシステム構成を形成する。このプロセスは，システム階層の連続してい
る各階層レベルで再帰的に用いられる。
注記2 インタフェースは，アーキテクチャ定義及び設計定義プロセスによって定義される。このプ
ロセスは，これらの他プロセスと連携，及びインタフェース定義が必要十分となるようにチ
ェックし，並びにインタフェース定義がインテグレーションのニーズを考慮したものにする。
6.4.8.2
成果
インテグレーションプロセスの実施に成功すると次の状態になる。
a) インタフェースを含むシステム要求事項，アーキテクチャ又は設計に影響を及ぼすインテグレーショ
ン制約が識別されている。
b) 組み立てられたインタフェース及びシステム機能の，適正な運用のための取組方法及びチェックポイ
ントが定義されている。
c) インテグレーションを可能にするために必要な全てのイネーブリングシステム又はサービスが利用可
能になっている。
d) 実装されたシステム要素からなるシステムが統合によってインテグレーションされている。
e) システムを構成する実装されたシステム要素間のインタフェースがチェックされている。
f)
システムと外部環境との間のインタフェースがチェックされている。
g) 統合されたインテグレーション結果及び不具合が識別されている。
h) 統合されたシステム要素のトレーサビリティが確立されている。
6.4.8.3
アクティビティ及びタスク
プロジェクトは，インテグレーションプロセスに関する，適用可能な組織の方針及び手順に従って，次
に示すアクティビティ及びタスクを実施しなければならない。
a) インテグレーションの準備を行う。このアクティビティは，次のタスクからなる。
1) 組み立てられたインタフェース及び選択されたシステム機能の，適正な運用及び完整性のためのチ
ェックポイントを識別し，定義する。
81
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記1 インタフェースの詳細な検証は，検証プロセスを用いることによって実施する。
注記2 アシュアランス，完整性及びセキュリティについては，ISO/IEC 15026シリーズ及び
ISO/IEC 27000シリーズを参照。チェックポイントを識別して定義するときは，偽造防
止，改ざん防止，システム・ソフトウェアのアシュアランス及び相互運用性の要素を考
慮する。
2) インテグレーション戦略を定義する。
注記1 インテグレーションは，あらかじめ定義されたインテグレーション戦略に従って実行さ
れる。インテグレーション戦略は，インテグレーションの時間，コスト及びリスクを最
小限に抑えながら，インタフェースに焦点を当てたシステム要求事項及びアーキテクチ
ャ定義の優先順位に基づいて，実装されたシステム要素を組み立てる順序を決める。
注記2 この戦略は，システム要素の構成を段階的により完全なものにし，その順序に対応させ
て検証ができるようにすることがよくある。それはシステム要素のアベイラビリティに
依存し，障害部分の切分け及び診断の戦略との一貫性をもっている。可能な場合は通常，
統合された構成にシステムの運用を担当する人間の運用操作者を含む。対象システムが
実現されるまで，途中段階の各階層のシステムに対し，インテグレーションプロセス，
検証プロセス，及び適切な場合には妥当性確認プロセスも含めたプロセスを順次適用す
ることが繰り返される。
3) インテグレーションを支援するために必要とするイネーブリングシステム又はサービスを識別し計
画する。
注記 これには，イネーブリングシステムの要求事項及びインタフェースの識別を含む。インテ
グレーションのためのイネーブリングシステムには，インテグレーション設備，組立て機
器，教育訓練システム，不一致報告システム，シミュレータ，計測機器，施設セキュリテ
ィなどがある。イネーブリングシステムがインテグレーションタスクを支援するために必
要な変更を識別し，定義する必要がある。これらの変更の必要性は，イネーブリングシス
テムを統括管理する利害関係者に提供される。
4) 利用されるイネーブリングシステム若しくはサービス，及び資材を，獲得する又はそれらへのアク
セスを取得する。
注記 インテグレーションの実現を支援する，インテグレーション用イネーブリングシステムの
支援機能が意図されたように利用できるかを客観的に確認するために，妥当性確認プロセ
スが用いられる。
5) システム要求事項，アーキテクチャ，又は設計に組み込まれるシステム制約を，インテグレーショ
ンに関して識別する。
注記 これは，次に関する要求事項を含む。アクセス可能性，インテグレーション担当者の安全
性，実装されたシステム要素の集合及びインテグレーション実現手段の間に要求される相
互接続，並びにインタフェースの制約など。
b) インテグレーションを実施する。システムが完全に統合されるまで，システム要素構成を順次統合す
る。このアクティビティは，次のタスクからなる。
1) 合意されたスケジュールに従って実装されたシステム要素を取得する。
注記 実装されたシステム要素を，供給者，取得者から受け取るか，又は格納場所から取り出す。
システム要素は，関連する人の健康，安全性，セキュリティ，及びプライバシーに関する
82
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
考慮事項に従って取り扱う。実装されたシステム要素の受入れの一環として，各要素は，
合意の中で指定された受入れ基準に対して検証及び妥当性確認がなされていることを確認
するためにチェックされる。納入された構成，適合性，インタフェースの互換性，及び必
須情報項目の存在がチェックされる。検証に合格しない実装されたシステム要素は，その
ことが識別され，定義された手順に従って取り扱う。
2) 実装されたシステム要素を組み立てる。
注記 インテグレーション戦略に規定されているように，実装されたシステム要素を接続するシ
ステム要素構成（完全又は部分）を達成するために，組立てを実行する。このとき，定義
された組立て手順，インタフェース制御記述及び関連するインテグレーション用イネーブ
リングシステムを使用する。
3) インタフェース，選択された機能及び重大な品質特性のチェックを実施する。
注記 これは，インタフェース（外部及び内部），機能及び品質特性の運用を確実にするために実
行する。インタフェースは，インタフェース要求事項に対して照合する検証プロセスを用
いてチェックする。
c) インテグレーション結果を管理する。このアクティビティは，次のタスクからなる。
1) インテグレーション結果及び遭遇した全ての不具合を記録する。
注記 これには，インテグレーション戦略，インテグレーション用イネーブリングシステム，イ
ンテグレーションの実行，又はシステム若しくは要素についての誤りのある定義を起因と
した不具合が含まれる。システム，指定された運用環境及び利用段階を実現可能にするた
めの各システムの間のインタフェースに不整合が存在する場合，その逸脱は是正処置又は
要求事項の変更につながる。根本原因を識別し，是正処置又は改善処置を可能にし，かつ，
学んだ教訓を記録する目的でデータを分析するために，プロジェクトアセスメント及び制
御プロセスが用いられる。
2) 統合されたシステム要素のトレーサビリティを維持する。
注記 統合されたシステム要素と，インテグレーション戦略，インテグレーションに必要なイン
タフェース要求事項及び定義を含むシステム要求事項，システムアーキテクチャ及び設計
との間で，双方向のトレーサビリティを維持する。
3) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが，構成品目及びベースラインを確立し維持するために利用される。こ
のプロセス（インテグレーション）で，ベースラインのための候補となる情報項目を識別
し，そしてCMへ情報項目を提供する。このプロセスにおいてベースライン化される典型
的な情報項目は，インテグレーション戦略である。
6.4.9
検証プロセス（Verification process）
6.4.9.1
目的
検証プロセスは，システム又はシステム要素がその指定された要求事項及び特性を満たしていることの
客観的な証拠を提供することを目的とする。
検証プロセスは，任意の情報項目（例えば，システム要求事項又はアーキテクチャ記述），実装されたシ
ステム要素又はライフサイクルプロセスにおける不具合（エラー，欠陥又は障害）を，適切な手法，技法，
標準又は規則を用いて識別する。このプロセスは，識別された不具合の解決策を決定するために必要な情
報を提供する。
83
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記 検証プロセスは，“製品が正しく作られた”ことを判断する。妥当性確認プロセスは，“正しい
製品が作られた”ことを判断する。
6.4.9.2
成果
検証プロセスの実施に成功すると次の状態になる。
a) 要求事項，アーキテクチャ，又は設計に影響を及ぼす検証の制約が識別されている。
b) 検証の実施を可能にするために必要な全てのイネーブリングシステム又はサービスが利用可能になっ
ている。
c) システム又はシステム要素が検証されている。
d) 是正処置のための情報を提供するデータが報告されている。
e) 実現されたシステムが，要求事項，アーキテクチャ及び設計を満たすことを示す，客観的な証拠が提
供されている。
f)
検証結果及び不具合が識別されている。
g) 検証されたシステム要素のトレーサビリティが確立されている。
6.4.9.3
アクティビティ及びタスク
プロジェクトは，検証プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアクティ
ビティ及びタスクを実施しなければならない。
a) 検証の準備を行う。このアクティビティは，次のタスクからなる。
注記 この戦略は，一般に，システム又はシステム要素が“正しく作られている”ことを確認する
ためのバランスのとれた取組方法を提供することによって，コスト及びスケジュール，並び
にリスクの双方又はいずれかを最小化することに焦点を当てる。
1) 検証範囲及び範囲に対応する検証作業を識別する。
注記 検証範囲には，要求事項，アーキテクチャ及び設計の特性又はその他の検証すべき性質を
含む。各検証作業に対する戦略には，次を記述する。検証対象となるシステム要素又は作
成物（実際のシステム若しくはモデル，モックアップ，プロトタイプ，手順，計画，又は
他の文書），及びその遂行能力・性能・運用時の実績又は適合性から導かれるような期待さ
れる結果。設計の特性は，計画されている運用環境の状況に対応する設計に含め得るセキ
ュリティの度合い，及び重大な品質特性の達成度を含む。
2) 検証作業の実現可能性を制限する可能性のある制約を識別する。
注記 制約には，技術面の実現可能性，コスト，時間，検証の実現手段が利用可能か，又は適格
性のある有資格の検証要員が作業可能かの，アベイラビリティ，契約上の制約，及びミッ
ションの重大性のような特性を含む。
3) 各検証作業に対して，適切な検証手法又は技法，及び対応付けられた基準を選択する。
注記 検証手法又は技法には，インスペクション（ピアレビューを含む。），分析（モデリング，
シミュレーション，及び相似性・類似性の分析を含む。），具体例の実演による実証，又は
テストを含む。検証手法又は技法の選択は，システムの種別，プロジェクトの目標，及び
受容可能なリスクに対応させて決める。検証の取組方法が受入れ可能なものになることを
確実にするのを助けるため，選択された検証手法は関係する利害関係者と調整する。
4) 検証戦略を定義する。
注記1 この定義は，制約又は制限に対して，何を検証していくか（検証の範囲）のトレードオ
フ分析を含み，どのような検証作業を利用すべきかを導出する。実施せずに削除する候
84
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
補とした検証作業は，それらを実施しないことが与えるリスクを評価する。優先順位付
けされた検証戦略として次を含める。各検証作業についての最も適切な検証手法又は技
法，及び選択された検証手法又は技法が必要とする検証用イネーブリングシステム（シ
ミュレータ，テスト環境，適格性のある有資格の検証要員，作業場所，施設・設備など）。
注記2 検証戦略及びスケジュールは，プロジェクトの進捗に応じて更新する。特に，予期しな
いイベント又はシステムの発展が起きたときは，計画されていた検証作業を，再定義又
は再スケジュールする。
5) システム要求事項，アーキテクチャ又は設計に組み込まれるシステム制約を，検証戦略から識別す
る。
注記 これは，精度も含めた正確性，不確実性及び再現性に関する実用上の制限を含む。これら
の制限は，次によって課せられる。検証の実現手段，関連する測定手法，システムインテ
グレーションの必要性，並びに検証実現手段のアベイラビリティ，アクセス性及び相互接
続。
6) 検証を支援するために必要とするイネーブリングシステム又はサービスを識別し計画する。
注記 検証用イネーブリングシステムには，検証用の装置・機器，シミュレータ，テスト自動化
ツール，検証用の施設・設備などを含む。
7) 利用されるイネーブリングシステム若しくはサービスを，獲得する又はそれらへのアクセスを取得
する。
注記 検証用イネーブリングシステムの取得は，貸借，調達，開発，再利用又は下請負契約のよ
うな様々な方法を通じて実施可能である。通常，これらの方法を組み合わせて，検証実現
手段をそろえた完全な集合を取得する。検証の実現を支援する検証用イネーブリングシス
テムの支援機能が，意図したように利用できるかを客観的に確認するために，妥当性確認
プロセスが用いられる。
b) 検証を実施する。このアクティビティは，次のタスクからなる。
1) それぞれが一つの検証作業，又は一連の複数の検証作業を支援するような，検証手順を定義する。
注記 これらの検証手順は，次を用いて検証の目的を識別する。成功の判断基準（期待される結
果），適用される検証技法，必要なイネーブリングシステム（施設・設備，装置・機器など），
及び各検証手順を実施するための環境条件（資源，適格性のある有資格の検証要員など）。
2) 検証手順を実施する。
注記 検証戦略に従った検証は，スケジュールにおける適切な時期に実施される。検証アクティ
ビティは，定義された環境におけるシステムライフサイクルの適切な時点で，定義された
イネーブリングシステム及び資源を用いて遂行される。検証作業の遂行は，検証手順の実
行結果を把握して記録に残すこと，期待される結果と得られた結果とを比較すること，及
び検証へ提供された要素の，誤りのない正しさの度合いを導出することからなる。
c) 検証の結果を管理する。このアクティビティは，次のタスクからなる。
1) 検証結果及び遭遇した全ての不具合を記録する。
注記1 これは，検証戦略，検証用イネーブリングシステム，検証の実行，又は誤りのあるシス
テム定義が原因となった不具合を含む。根本原因の識別，是正処置又は改善作業の実現，
及び学んだ教訓の記録を目的としてデータを分析するために，プロジェクトアセスメン
ト及び制御プロセスが用いられる。
85
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記2 プロジェクトアセスメント及び制御プロセスでの検証結果の評価，及び検証後に追跡調
査して行う是正処置は，検証の目的に大きく依存し，様々なものになり得る。システム
要素に対して，検証に失敗したシステム要素の対処を行って再検証を単に行うような問
題解決作業となるか，又は，例えば，システムテストの失敗のような，重要な節目とな
るマイルストーンの達成の失敗に基づいて，プロジェクトの重大な方向転換を設定する
ような，より重要な作業にもなり得る。
2) インシデント及び問題を記録し，それらの解決を追跡する。
注記 問題解決の実行は，品質保証プロセス，並びにプロジェクトアセスメント及び制御プロセ
スを通じて取り扱う。要求事項，アーキテクチャ，設計，又はシステム要素への実際の変
更は，他のテクニカルプロセス内で行う。
3) システム又はシステム要素が明示された要求事項に合致していることについて，利害関係者の合意
を得る。
4) 検証されたシステム要素のトレーサビリティを維持する。
注記 検証されたシステム要素と，検証戦略，システムアーキテクチャ，設計及びシステム要求
事項との間で，双方向のトレーサビリティを維持する。
5) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが，構成品目及びベースラインを確立し維持するために利用される。こ
のプロセス（検証）で，ベースラインのための候補となる情報項目を識別し，そしてCM
へ情報項目を提供する。このプロセスにおいてベースライン化される典型的な情報項目は，
検証戦略である。
6.4.10 移行プロセス（Transition process）
6.3.10.1 目的
移行プロセスは，システムが運用環境において，利害関係者要求事項によって規定されたサービスを供
給する能力を確立することを目的とする。
このプロセスは，システムを秩序ある計画された方法で，システムが機能し，運用操作可能で，他の運
用システムと相互に運用できるような，運用状態へ移す。このプロセスは，合意によって定めたように，
例えば，計画システム，支援システム，運用操作者向け教育訓練システム，利用者向け教育訓練システム
といった関連するイネーブリングシステムとともに，検証済みのシステムを導入する。このプロセスは，
段階の終了に対して確立されている基準を完了するために，システム構造の中の各レベル及び各段階で使
用される。それには，該当する保管，取扱い及び出荷用のイネーブリングシステムの準備を含む。
注記 システムをアップグレードする場合は，進行中の運用の中断を最小限に抑えるように，移行ア
クティビティの実施を達成する必要がある。
6.4.10.2 成果
移行プロセスの実施に成功すると次の状態になる。
a) システム要求事項，アーキテクチャ又は設計に影響を及ぼす移行の制約事項が識別されている。
b) 移行の実施を可能にするために必要な全てのイネーブリングシステム又はサービスが利用可能になっ
ている。
c) 移行先の運用サイトが準備されている。
d) 運用場所に導入されたシステムが規定された機能を提供する能力がある。
e) システムの利用及び支援に必要な運用操作者，利用者及び他の利害関係者が教育訓練されている。
86
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
f)
移行の結果及び不具合が識別されている。
g) 導入されたシステムが起動されて運用の準備が整っている。
h) 移行された要素のトレーサビリティが確立されている。
6.4.10.3 アクティビティ及びタスク
プロジェクトは，移行プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアクティ
ビティ及びタスクを実施しなければならない。
a) 移行の準備を行う。このアクティビティは，次のタスクからなる。
1) 移行戦略を定義する。
注記 移行戦略は，システムを運用するサイトでの納入及び導入設置から，システムの展開配備
及び試験的運用を含めた運用開始の権限付与までの，合意に従って行う，全てのアクティ
ビティを含む。それは，システムの完整性が維持されるように支援する適切な仕組みを使
用して行う。戦略は，運用操作者を含めた全ての利害関係者が関与する。戦略は，役割及
び責任，施設の考慮事項，受渡し，移行中に問題が発生する有事に対応して作業を取り消
し後退させるための計画，教育訓練，導入受入れの実演による実証作業，運用準備レビュ
ー，運用開始，移行成功基準，並びに他の計画と統合することを含む。システムの試験的
運用は，旧システムが存在する場合には，それを廃止することと併せて考慮される。この
場合，移行プロセス及び廃棄プロセスは並行して用いられる。
2) 施設又はサイトについて，全ての必要な変更を識別して定義する。
注記 これは，導入又は利用に必要な変更を含む。
3) システムの利用及び支援に必要な運用操作者，利用者及びその他の利害関係者の教育訓練を識別し
て用意する。
4) システム要求事項，アーキテクチャ又は設計に組み込まれるシステム制約を，移行に関して識別す
る。
5) 移行を支援するために必要とするイネーブリングシステム又はサービスを識別し計画する。
注記 これは，イネーブリングシステムの要求事項及びインタフェースの識別を含む。
6) 使用されるイネーブリングシステム又はサービスへのアクセス権を取得又は獲得する。
注記 移行の実現を支援する移行用イネーブリングシステムの支援機能が，意図したように利用
できるかを客観的に確認するために，妥当性確認プロセスが用いられる。
7) システム要素及びイネーブリングシステムの受渡しを識別し準備する。
b) 移行を実施する。このアクティビティは，次のタスクからなる。
1) システムの導入についての要求事項に従って，運用サイトを準備する。
注記 移行先の運用サイトの準備は，適用可能な人の健康，安全性，セキュリティ及び環境に関
する規則に従って実施する。
2) 適正な場所及び時間に導入するように，システムを納入する。
注記 納入する前の中間時点の保管についても説明が必要になることがある。
3) システムを運用場所に導入し，そこでの環境とのインタフェース接続を確立する。
注記 システム導入には，運用環境への変更又はビジネス上のプロセスの変更を考慮して，シス
テムを要求される運用データとともに構成することを含む。データ移行を検討する必要が
ある場合もある。
4) システムが適切に導入されたことを実証する。
87
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記 一般的に，納入のための合意で定義された受入れテストを行うことによって，導入が満足
のいくものであったことを示す。運用の正確な場所又は環境が利用できない場合には，代
表的な例となる運用場所及び環境を選択する。物理的なインタフェースには特に注意を払
う。
5) システムの利用及び支援に必要な運用操作者，利用者及びその他の利害関係者の教育訓練を提供す
る。
6) システムを起動し動作チェックを実施する。
注記1 このタスクでは，運用手順，組織の方針及び規制に従って，電源の投入，機器チェック，
環境条件のアセスメント及びその他の準備状況の評価を含む，システムを運用可能な稼
動状態にするために必要な全ての手順を実行する。このタスクは，妥当性確認プロセス
とも相互作用し，システムが運用環境で利害関係者の要求事項を満たしていることを客
観的に確認する。
注記2 このタスクには，完整性のチェック及び技術標準への適合を含む。チェックポイントを
識別し定義するときは，偽造防止，システム及びソフトウェアのアシュアランス，並び
に相互運用性をもった要素を通常考慮する。
7) 導入されたシステムがその要求される機能を供給する能力をもつことを実証する。
注記1 合意で規定された受入れテストでは，システムが運用場所に導入されて運用操作者が要
員配置されているときに，システム又はシステム要素が，要求される機能及びサービス
を供給する能力をもっていることを，実演によって実証する基準を定義することができ
る。重要な機能及び論理インタフェースに特に注意が払われる。
注記2 これは，運用状態に向けて機能的な能力の準備を詳細調査する運用準備のタスクである。
妥当性確認プロセスは，システムが利害関係者のニーズを満たすかどうかを評価する。
8) システムによって提供される機能がイネーブリングシステムによって持続可能であることを実証す
る。
注記 これは，運用状態に向けてイネーブリングシステムの準備を詳細調査する運用準備のタス
クである。
9) 運用準備に向けてシステムをレビューする。
注記 これには，結果として運用できるようになった機能の実演による実証，妥当性確認アクテ
ィビティ，及びシステム運用維持の実演による実証が含まれる。
10) システムに運用の権限を与える。
注記 これは，システムの運用開始（試験的な運用）の期間中に，利用者及び運用操作者への支
援を提供することを含む。
c) 移行の結果を管理する。このアクティビティは，次のタスクからなる。
1) 移行の結果及び遭遇した全ての不具合を記録する。
注記 これは，移行戦略，移行用イネーブリングシステム，移行の実行又は誤りのあるシステム
定義に起因する不具合を含む。システムと，その指定された運用環境及び利用段階の実現
を可能にする任意のシステムとの間のインタフェースに不整合が存在する場合，その逸脱
は，是正処置又は要求事項の変更によって解決される。根本原因の識別，是正処置又は改
良作業の実現，及び学んだ教訓の記録を目的としてデータを分析するために，プロジェク
トアセスメント及び制御プロセスが用いられる。
88
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
2) インシデント又は問題を記録し，解決を追跡する。
注記 問題解決の実行は，品質保証プロセス，並びにプロジェクトアセスメント及び制御プロセ
スを通じて取り扱う。要求事項，アーキテクチャ，設計又はシステム要素への実際の変更
は，他のテクニカルプロセス内で行う。
3) 移行されるシステム要素のトレーサビリティを維持する。
注記 移行されるシステム要素と，移行戦略，システムアーキテクチャ，設計及びシステム要求
事項との間で，双方向のトレーサビリティを維持する。
4) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが，構成品目及びベースラインを確立し維持するために利用される。こ
のプロセス（移行）で，ベースラインのための候補となる情報項目を識別してCMへ情報
項目を提供する。このプロセスにおいてベースライン化される典型的な情報項目は移行戦
略である。
6.4.11 妥当性確認プロセス（Validation process）
6.4.11.1 目的
妥当性確認プロセスは，システムがその利用中に，意図された運用環境で意図された用途を達成するこ
とで，そのビジネス又はミッションの目標及び利害関係者要求事項を満たすという客観的証拠を提供する
ことを目的とする。
システム又はシステム要素の妥当性を確認することの目標は，それらが，特定の運用条件下で，意図さ
れたミッションを達成できる，又は意図されたように利用できるという確信を得ることである。妥当性確
認は利害関係者によって承認される。このプロセスは，識別された不具合を，不具合原因が作り込まれた
ところで，適切なテクニカルプロセスによって解決できるために必要な情報を提供する。
注記1 妥当性確認プロセスは，“正しい製品が作られた”ことを判断する。検証プロセスは，“製品
が正しく作られた”ことを判断する。
注記2 妥当性確認は，システムの定義及び実現中に作成された，エンジニアリングの中間作成物（シ
ステム要素とみなされる。）に対しても適用可能である。
6.4.11.2 成果
妥当性確認プロセスの実施に成功すると次の状態になる。
a) 利害関係者要求事項に対する妥当性確認基準が定義されている。
b) 利害関係者が要求するサービスのアベイラビリティが確認されている。
c) 要求事項，アーキテクチャ又は設計に影響を及ぼす妥当性確認の制約が識別されている。
d) システム又はシステム要素が妥当性確認されている。
e) 妥当性確認の実施を可能にするために必要な全てのイネーブリングシステム又はサービスが利用可能
になっている。
f)
妥当性確認結果及び不具合が識別されている。
g) 実現したシステム又はシステム要素が利害関係者ニーズを満たすことを示す，客観的な証拠が提供さ
れている。
h) 妥当性確認されたシステム要素のトレーサビリティが確立されている。
6.4.11.3 アクティビティ及びタスク
プロジェクトは，妥当性確認プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すア
クティビティ及びタスクを実施しなければならない。
89
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
a) 妥当性確認の準備を行う。このアクティビティは，次のタスクからなる。
1) 妥当性確認の範囲及び対応する妥当性確認作業を識別する。
注記1 範囲には，評価される利害関係者要求事項を含める。各妥当性確認作業に対する戦略に
は，次を記述する。妥当性確認のための利害関係者ニーズ及び利害関係者要求事項，妥
当性確認が実施されるシステム又はシステム要素，並びにその実施から期待される結果。
範囲は，何を妥当性確認することがそのシステムライフサイクル段階でふさわしいか，
に依存する。それは対象システム若しくは任意のシステム要素，又はエンジニアリング
の中間作成物であり，例えば，概念の記述若しくは文書，運用シナリオ，モデル，モッ
クアップ又はプロトタイプであり得る。範囲は，次を評価することも含む。製品又はサ
ービスが意図された環境下で予測どおりの振る舞いをすること，及びシステムの意図さ
れた用途に悪影響を及ぼす意図しない使用ができないこと。
注記2 供給者，取得者又は取得者の代理者は，妥当性確認に参加，又は妥当性確認を実施する。
その責任は一般に，合意によって示される。
2) 妥当性確認作業の実現可能性を制限する可能性のある制約を識別する。
注記 制約には，技術面の実現可能性，コスト，時間，妥当性確認の実現手段が利用可能か，又
は適格性のある有資格の妥当性確認要員が作業可能かの，アベイラビリティ，契約上の制
約，及びミッションの重大性のような特性を含む。
3) 各妥当性確認作業に対して，適切な妥当性確認手法又は技法，及び対応付けられた基準を選択する。
注記1 妥当性確認の手法又は技法には，インスペクション，分析，相似性・類似性，具体例の
実演による実証，シミュレーション，ピアレビュー，テスト又は認証を含む。妥当性確
認の手法又は技法の選択は，システムの種別及び目的，プロジェクトの目標，規制又は
法律面の要求事項，並びに妥当性確認作業における受容可能なリスクに対応させて決め
る。
注記2 適切な場合には，妥当性確認の実施の段階又は状態が定義される（例えば，組織内での
妥当性確認，現地の運用サイトでの妥当性確認，運用中の妥当性確認）。それは，納入さ
れたシステム，導入され設置されたシステム，稼働したシステムが順に段階を経て適合
することを示して信頼を漸進的に構築し，発見し遭遇した全ての不具合の診断を支援す
る。妥当性確認の各段階の目的，条件及び適合基準で定義されているように，妥当性確
認作業の実施に必要な，適切な妥当性確認技法が選択される。
4) 妥当性確認戦略を定義する。
注記1 この定義は，制約又は制限に対して，何を妥当性確認していくか（妥当性確認の範囲）
のトレードオフ分析を含み，どの妥当性確認作業を維持するかを推論して決定したもの
にする。実施せずに削除する候補としている妥当性確認作業については，それらの妥当
性確認作業を実施しないことが与えるリスクを評価する。優先順位付けされた妥当性確
認戦略は同時並行して次を定義することで策定する。各妥当性確認作業についての最も
適切な妥当性確認技法，及び選択された妥当性確認技法が必要とする妥当性確認の実現
手段（シミュレータ，テストベンチ，適格性のある有資格の妥当性確認要員，作業場所，
施設・設備など）。
注記2 妥当性確認戦略及びスケジュールは，プロジェクトの進捗に応じて更新する。特に，予
期しないイベント又はシステムの発展が起きたときは，計画されていた妥当性確認作業
90
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
を，再定義又は再スケジュールする。
注記3 この戦略は一般に費用及びスケジュール，並びにリスクの，双方又はいずれかを最小化
することに焦点を当てる。
5) 利害関係者要求事項に組み込まれるシステム制約を，妥当性確認戦略から識別する。
注記 これは，精度も含めた正確性，不確実性及び再現性に関する実用上の制限を含む。これら
の制限は，次によって課せられる。妥当性確認の実現手段，関連する測定手法，並びに妥
当性確認の実現手段のアベイラビリティ，アクセス性及び相互接続。
6) 妥当性確認を支援するために必要とするイネーブリングシステム又はサービスを識別し計画する。
注記 これには，イネーブリングシステムに対する要求事項及びインタフェースの識別を含む。
妥当性確認用イネーブリングシステムには，妥当性確認用の装置・機器，シミュレータ，
テスト自動化ツール，施設・設備などを含む。
7) 利用されるイネーブリングシステム若しくはサービスを，獲得する又はそれらへのアクセスを取得
する。
注記 妥当性確認用イネーブリングシステムを獲得にするには，貸借，調達，開発，再利用，下
請負契約など，様々な方法がある。通常，これらの方法を組み合わせて，妥当性確認の実
現手段をそろえた完全な集合へアクセスする。妥当性確認の実現を支援する妥当性確認用
イネーブリングシステムの支援機能が，意図したように利用できるかを客観的に確認する
ためにも，妥当性確認プロセスが用いられる。
b) 妥当性確認を実施する。このアクティビティは，次のタスクからなる。
1) それぞれが一つの妥当性確認作業，又は一連の複数の妥当性確認作業を支援するような，妥当性確
認手順を定義する。
注記 これには，期待される結果，適用される妥当性確認技法，対応する妥当性確認の実現手段
（施設・設備，装置・機器など），及び妥当性確認手順を実施するための環境条件（資源，
適格性のある有資格の妥当性確認要員など）の識別を含む。
2) 定義した環境において，妥当性確認手順を実施する。
注記 妥当性確認作業は，システムライフサイクルの適切な時点で，定義した環境（運用環境又
はそれを代表した環境にできるだけ近くなるように定義した環境）で，定義した実現手段
及び資源を使用して実施する。妥当性確認作業の実施は，妥当性確認手順の実行結果を把
握して形のある記録に残すこと，得られた結果を期待した結果と比較すること，結果の要
素の適合の度合いを推測すること，及び不確かさが残っている可能性がある場合に適合と
して受容される許容度を決定することからなる。
3) 利害関係者から要求されたシステムのサービスが利用可能であることを確認するため，妥当性確認
結果をレビューする。
c) 妥当性確認の結果を管理する。このアクティビティは，次のタスクからなる。
1) 妥当性確認結果及び遭遇した全ての不具合を記録する。
注記 これには，妥当性確認戦略，妥当性確認用イネーブリングシステム，妥当性確認の実行又
は誤りのあるシステム定義に起因する不具合を含む。根本原因の識別，是正処置又は改善
作業の実現，及び学んだ教訓の記録を目的としてデータを分析するために，プロジェクト
アセスメント及び制御プロセスが用いられる。
2) インシデント及び問題を記録し，それらの解決を追跡する。
91
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記 問題解決の実行は，品質保証プロセス，並びにプロジェクトアセスメント及び制御プロセ
スを通じて取り扱う。要求事項，アーキテクチャ，設計，又はシステム要素への実際の変
更は，他のテクニカルプロセス内で行う。
3) システム又はシステム要素が利害関係者ニーズに合致していることについて，利害関係者の合意を
獲得する。
4) 妥当性確認されたシステム要素のトレーサビリティを維持する。
注記 妥当性確認されたシステム要素と，妥当性確認戦略，ミッション又はビジネス分析，ライ
フサイクル概念，利害関係者要求事項，システムアーキテクチャ，設計及びシステム要求
事項との間で，双方向のトレーサビリティを維持する。
5) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが，構成品目及びベースラインを確立し維持するために利用される。こ
のプロセス（妥当性確認）で，ベースラインのための候補となる情報項目を識別し，そし
てCM（構成管理）へ情報項目を提供する。このプロセスにおいてベースライン化される
典型的な情報項目は，妥当性確認の戦略である。
6.4.12 運用プロセス（Operation process）
6.4.12.1 目的
運用プロセスは，システムを利用してサービスを提供することを目的とする。
このプロセスは，要員がシステムを運用操作するための要求事項を確立して，要員をシステムの運用操
作を担当するよう割り当て，サービス及び運用操作者によって運用されるシステムの遂行能力・性能・運
用時の実績を監視する。サービスを持続させるために，運用操作上の不具合を，合意，利害関係者の要求
事項，及び組織面の制約に関して識別し分析する。
注記 JIS Q 20000-1:2012（IEEE Std 20000-1:2013）は，目的を達成するよう運用プロセスを支援する
サービス管理システムを確立するための要求事項を規定している。
6.4.12.2 成果
運用プロセスの実施に成功すると次の状態になる。
a) システム要求事項，アーキテクチャ又は設計に影響を与える運用操作の制約が識別されている。
b) 運用の実施を可能にするために必要な全てのイネーブリングシステム，サービス及び資材が利用可能
になっている。
c) 教育訓練された，適格性のある有資格の運用操作者が運用に従事することが可能となっている。
d) 利害関係者要求事項を満たすシステムサービスが提供されている。
e) 運用中のシステムの遂行能力・性能・運用時の実績が監視されている。
f)
顧客への支援が提供されている。
6.4.12.3 アクティビティ及びタスク
プロジェクトは，運用プロセスに関する該当する組織の方針及び手順に従って，次のアクティビティ及
びタスクを実施する。
a) 運用の準備を行う。このアクティビティは，次のタスクからなる。
1) 運用戦略を定義する。
注記 これはシステムの運用操作を実行するために要求される，取組方法，スケジュール，資源
及び特定の考慮事項を定義する。これは，次を含むことがよくある。
− サービスが導入され，日常的に運用され，取り下げられるときのアベイラビリティ。
92
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
これには，同一又は類似したサービスを提供している他のシステムが提供する，既
存か，同時並行か又は継続のサービスとの調整を行うことを含めることができる。
− 運用操作者を要員配置する戦略及びスケジュール
− 既存又は強化されたサービスを維持する修正を可能にするためのシステムのリリース
並びに再受入れの基準及びスケジュール
− 正常時の運用及び予想される種類の有事発生に対応する緊急時の運用を含むシステム
レベルの運用概念における運用モードを実施するための取組方法
− 運用時のシステムの遂行能力・性能・運用時の実績のレベルを洞察できるような，運
用に対する測定量
− いかなる安全規定についても責任をもって対応する，運用中のシステムを使用するか
又はシステムとの接点がある運用操作者及び人々のための，運用安全及び業務安全に
関する安全戦略
− システムを運用するための環境を保護及び持続可能にする戦略
− 脅威の変化及び運用監視活動の結果の監視手順
2) システム要求事項，アーキテクチャ，又は設計に組み込まれるシステム制約を，運用操作に関して
識別する。
3) 運用を支援するために必要とするイネーブリングシステム又はサービスを識別し計画する。
注記 これにはイネーブリングシステムの要求事項及びインタフェースの識別を含む。
4) 利用されるイネーブリングシステム若しくはサービスを獲得する，又はそれらへのアクセスを取得
する。
注記 運用の実現を支援する運用支援用イネーブリングシステムの支援機能が，意図したように
利用できるかを客観的に確認するために，妥当性確認プロセスが用いられる。
5) システム運用に必要な人材の教育訓練及び適格性についての要求事項を識別又は定義する。
6) 教育訓練された，適格性のある有資格者の要員を運用操作者として任命する。
注記 教育訓練及び適格性の認定資格には，運用環境でのシステムの認識，並びに適切な故障の
検出及び分離の指導を伴う定義された習熟プログラムを含める。運用操作者の知識，スキ
ル及び経験についての要求事項を用いて要員選定基準を導き出し，関連がある場合は，運
用操作に携わる権限を認可する。適格性の範囲は，対象システム及びその環境に依存する。
例えば，環境に関する規制の要求事項に，運用操作者の適格性についての資格認証が含ま
れる場合があるが，そのような要求事項がない場合もある。教育訓練モードで運用される
システムは，サービスのアベイラビリティに影響を及ぼすことがある。
b) 運用を実施する。このアクティビティは，次のタスクからなる。
1) 意図された運用環境でシステムを利用する。
注記 運用戦略はシステムの利用法を手引きする。合意がある場合，新システムが廃止される既
存のシステムと置き換わるときに，継続したサービスの能力及び品質を維持する。運用切
替え又は並行運用の指定期間中，利害関係者の持続したニーズへ引き続き適合することが
達成されるように，サービスの移行を管理する。
2) システムの運用及びサービスを維持するため，要求に応じて資材及び他の資源を提供する。
注記 ハードウェアのためのエネルギー源の供給及び運用操作者への支給を含む。
3) システム運用を監視する。
93
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記1 これには次を含む。
− 運用戦略の遵守を管理する。
− システムが安全な方法で運用されること，並びに業務安全及び環境保護に関する法
的な指針に適合して運用されることを保証する。
− 戦略で定義された測定量を使用して分析し，運用のサービス実績が受入れ可能な範
囲内であることを確認する。
注記2 システムを監視することは，運用時のシステムの遂行能力・性能・運用時の実績が確立
されたしきい（閾）値以内であること，定期的な測定結果の指示値が受入れ可能である
こと，並びにサービス及び応答時間が受入れ可能であることを，それぞれレビューする
ことを含む。運用操作者のフィードバック及び提案は，システムの運用時のシステムの
遂行能力・性能・運用時の実績を向上させるための有用な入力である。
注記3 目標及び制約に照らして運用コストも監視し，潜在的な改善点を識別する。
4) システムサービス遂行能力・性能・運用時の実績が許容可能な範囲内にない場合，識別して記録す
る。
注記 ハードウェア内に実装されているシステム要素がその耐用年数を超過しているとき又はシ
ステムの運用環境が運用要員及び保守要員に影響を与えているとき（要員の配置転換，運
用操作者の過負荷及び疲労を含めて），システムの遂行能力・性能・運用時の実績が許容可
能な範囲内にないことを示しているとされることがある。
5) 必要に応じて，システムの有事発生に対応する緊急時の運用を実施する。
注記 これには，システムを縮退させた劣化モードによって運用操作すること，運用操作の取消
し及び修復，システムシャットダウンによる運用停止，運用操作を復元するための問題解
決手順を実施すること，又は特殊な条件に対する他の運用操作モードを実行することを含
む。必要があれば，運用操作者は有事発生時の運用操作を開始するために必要となる操作
手順を実行し，停止させることも含めてシステムの利用可能範囲を縮小することがある。
システムの有事発生時の運用操作は，そのようなシステムの有事発生イベントを想定して
あらかじめ事前に確立された手順に従って実行する。このようなシステムの有事発生時の
運用操作手順は，システム持続計画とともにあらかじめ計画されることがよくある。
c) 運用結果を管理する。このアクティビティは，次のタスクからなる。
1) 運用の結果及び遭遇した不具合を記録する。
注記 これには，運用戦略，運用支援用イネーブリングシステム，運用の実行，又は誤ったシス
テム定義に起因する不具合が含まれる。根本原因の識別，是正処置又は改良作業の実現，
及び学んだ教訓の記録を目的としてデータを分析するために，プロジェクトアセスメント
及び制御プロセスが用いられる。
2) 運用中のインシデント及び問題を記録し，それらの解決を追跡する。
注記1 問題解決の実行は，品質保証及びプロジェクトアセスメント及び制御プロセスを通じて
取り扱う。要求事項，アーキテクチャ，設計，又はシステム要素への実際の変更は，他
のテクニカルプロセス内で行う。
注記2 運用中にインシデントが発生した場合，運用操作者はそのインシデントを記録し，妥当
性が確認されている運用手順にあらかじめ規定された作業を実施して通常の運用へ復元
する。
94
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
3) 運用要素のトレーサビリティを維持する。
注記 運用要素と，ビジネス又はミッションのニーズ，システムレベルの運用概念，組織レベル
の運用概念，利害関係者要求事項との間で双方向のトレーサビリティが維持される。
4) ベースラインとして選択された主要な情報項目を提供する。
注記 構成管理プロセスは，構成品目及びベースラインを確立し維持するために使用される。こ
のプロセス（運用）は，ベースラインの候補を識別し，CMに情報項目を提供する。
d) 顧客を支援する。このアクティビティは，次のタスクからなる。
1) 依頼に応じて顧客を支援し相談に応じる。
注記 支援及び相談には，教育訓練，文書化，ぜい弱性解決，偽造防止報告，及び製品の効果的
な使用を支援するその他の支援サービスの提供又は推奨情報源の提供が含まれる。
2) 支援の依頼及び依頼に応じて支援する活動を記録し監視する。
3) 提供したシステムサービスが利用者のニーズを満たしている程度を判定する。
注記 結果は分析され，利害関係者の満足を継続的に維持して提供するために，システムサービ
スを修復又は改善するのに要求される活動が識別される。可能な限り，常時そうした活動
の有益さについて，利害関係者又はそれらの代表者と合意しておく。顧客満足度データは，
品質管理プロセスへの入力としても役立つ。
6.4.13 保守プロセス（Maintenance process）
6.4.13.1 目的
保守プロセスは，サービスを提供するシステムの能力を維持することを目的とする。
このプロセスは，サービスを提供するシステムの能力を監視し，分析のためにインシデントを記録し，
是正処置，適応処置，完全化処置及び予防処置の作業を実施し，修復された能力を確認する。
6.4.13.2 成果
保守プロセスの実施に成功すると次の状態になる。
a) システム要求事項，アーキテクチャ，又は設計に影響を及ぼす保守上の制約が識別されている。
b) 保守の実施を可能にするために必要な全てのイネーブリングシステム又はサービスが利用可能になっ
ている。
c) 交換，修理又は改訂されたシステム要素が利用可能になっている。
d) 是正保守，完全化保守又は適応保守に取り組むような変更に対するニーズが報告されている。
e) 故障データ及び耐用寿命時間データが，関連するコストを含めて調査決定されている。
6.4.13.3 アクティビティ及びタスク
プロジェクトは，保守プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアクティ
ビティ及びタスクを実施しなければならない。
a) 保守の準備を行う。このアクティビティは，次のタスクからなる。
1) 保守戦略を定義する。
注記1 保守概念としても知られている保守戦略は，運用操作のアベイラビリティに対する要求
事項に合致させるよう，是正保守及び予防保守を実施するために要求される取組方法，
スケジュール，資源及び特定の考慮事項を定義する。一般的には次を含む。
− 顧客の満足の達成を目的として，運用環境におけるサービスを維持するための是正
保守及び予防保守の戦略
− サービスの過度の損失，又は通常運用への影響（例えば，サービスの中断又は制限）
95
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
を及ぼさずに，システム故障の発生確率を減少させるための，スケジュール化され
た予防保守作業
− 取得ロジスティクス（補給，logistics）を含む，ライフサイクル全体を通したロジス
ティクス戦略［支援性（supportability）に含意されている，システム運用の支援をど
の程度まで行うかについて，開発段階の早期に検討することを確実にするのに役立
つ。］及び運用ロジスティクス（適正な量及び質の，必要な資材及び資源が，システ
ムの利用段階及び支援段階の，適切な場所及び時点に利用可能であることを確実に
するのに役立つ。）。
− 保管される交換用のシステム要素の数量及び型式，それらの保管の場所及び条件，
予想される交換の割合，並びに保管可能期間及び更新頻度
− 偽造されたシステム要素が，システムに導入されないことを保証する取組方法
− 保守要員に対する要求事項を満たすための，修理，交換及び復元を完遂して有効な
ものとするために要求される，スキル及び要員のレベル，並びに人の健康，安全性，
セキュリティ及び環境に関する全ての法令
− システムの遂行能力・性能・運用時の実績レベル，有効性，及び効率性を洞察する
ための保守作業の測定
注記2 信頼性中心保全（Reliability Centered Maintenance，以下，RCMという。）は，機器の故障
の主原因に取り組むための費用対効果の高い保守戦略である［故障モード影響・重大度
解析（Failure Modes, Effects, and Criticality Analysis，FMECA）及び障害木解析（Fault Tree
Analysis，FTA）によって支援される。］。それは，重要な機能を保持するための，費用対
効果の高い，一連の決められた保守プログラムを定義する体系的な取組方法を提供する。
SAE JA1011:2009のRCMのプロセスのための評価基準は，詳細な情報を提供する。状
態基準保全（Condition Based Maintenance，CBM/CBM+）は，システムが定常的な保守又
は修正保守を実行している期間中の利用不可能になる時間を減らすことによって，シス
テムの信頼性を改善する戦略である。
注記3 ほとんどの場合，能力の拡張，耐用寿命期間の途中でのアップグレード，又は旧来のシ
ステムの発展が，該当する適切なライフサイクルの中で一連のプロセスの集合を適用す
る，新しいシステム開発プロジェクトとなる。
2) システム要求事項，アーキテクチャ，又は設計に組み込まれるシステム制約を，保守に関して識別
する。
注記 これらは，次のことを必要とした結果であることがよくある。
− 既存の保守用イネーブリングシステムの再利用
− 既存の交換可能なシステム要素の再利用，及び再供給についての制約への適応
− 特定の場所・所在地又は環境での保守の実行
3) システム，並びに関連する保守及びロジスティクスの作業が，適用可能，運用可能，支援可能及び
持続可能な解決をもたらすようなトレードオフ関係を識別する。
注記 システム分析及び意思決定管理プロセスが，アセスメント及びトレードオフの意思決定を
行うために用いられる。
4) 保守を支援するために必要とするイネーブリングシステム又はサービスを識別し計画する。
注記 これはイネーブリングシステムに対する，要求事項及びインタフェースの識別を含む。
96
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
5) 利用されるイネーブリングシステム若しくはサービスを，獲得する又はそれらへのアクセスを取得
する。
注記 保守の実現を支援する保守支援用イネーブリングシステムの支援機能が，意図したように
利用できるかを客観的に確認するために，妥当性確認プロセスが用いられる。
b) 保守を実施する。このアクティビティは，次のタスクからなる。
1) 将来の修正保守，適応保守，完全化保守及び予防保守のニーズを識別するため，インシデント及び
問題報告をレビューする。
2) 保守のインシデント及び問題を記録し，それらの解決を追跡する。
注記1 保守の間にインシデントを経験した場合は，保守要員は，そのインシデントを記録し，
妥当性が確認されている手順の中であらかじめ規定された処置作業を実施する。
注記2 保守上の問題の識別及び解決の実施は，品質保証，並びにプロジェクトアセスメント及
び制御プロセスを通じて取り扱う。
3) システム要素のランダムな障害の是正又はスケジュールされたシステム要素交換のための，手順を
実施する。
注記 システムのランダム故障に対し，システム要素の交換，修理，改訂又は再構成が計画され
るレベルまで故障を分離する。そして，システム要素に対する是正処置を実行し，是正さ
れたシステムの遂行能力・性能・運用時の実績を検証する。劣化の可能性があるシステム
要素の有効耐用寿命を見積もるために，処置作業を記録する。
4) システムの故障を引き起こす，ランダムな障害を検出した場合は，システムを運用状態に復元する
ための作業を展開する。
注記 完全な運用状態への復元は，障害の原因が修正されるまでは不可能な場合がある。そのよ
うな場合，問題が顕在化したときの対応策である有事対応計画との一貫性をもたせ，シス
テムを縮退させて運用する劣化モードへ復元する。
5) 計画されたスケジュール及び保守手順に沿って，故障が発生する前にあらかじめシステム要素の交
換又は提供を行うことによって予防保守を実施する。
6) システムの中で不適合が発生したときには，故障を識別する作業を実施する。
7) 適応保守又は完全化保守が要求される時点を識別する。
注記 適応保守及び完全化保守の作業は，通常，システム要求事項，アーキテクチャ又は設計へ
の変更をもたらす。それは，既存のシステムを修正するための新しいプロジェクトを確立
する必要がある場合がある。その場合は，ポートフォリオ管理プロセスが，開発段階から
作業を始動するための起点となることがある。
c) ロジスティクス支援を実施する。このアクティビティは，次のタスクからなる。
1) 取得ロジスティクスを実施する。
注記 取得ロジスティクスへの配慮を，合意プロセスの結果である合意事項に含める。支援性に
含意されている，システム運用の支援をどの程度まで行うかについても，開発段階で考慮
する。これは，システムの初期設計に反映させておくか，又は運用支援のために補充及び
修理の計画をするか，そのいずれの方が，費用対効果をより大きくできるかを決定するた
めの分析の実施を含む。これらの意思決定は，アベイラビリティについての要求事項によ
って制約を受け，サプライチェーン管理に影響を与えることがよくある。取得ロジスティ
クスでは，システム運用の支援性へのニーズをシステム要求事項の定義と同時並行して検
97
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
討する。
2) 運用ロジスティクスを実施する。
注記 運用ロジスティクスは，システム機能の効果的及び効率的な提供を確実にすることに役立
てるための，運用寿命期間の全体を通した対象システム（SOI）及びイネーブリングシス
テムの両者を同時並行して運用できるように同調させる調整である。適正な量及び質にお
いて必要な資材及び資源が適材適所で利用可能になることを確実にすることに役立てるた
め，必要な段階的手順を用いることも含む。
3) ライフサイクルの中で必要となる，パッケージ化，取扱い，格納及び輸送を実施する。
注記 これは，システム，システム要素，及び要求される交換用システム要素の，パッケージ化，
取扱い，格納及び輸送を含む。これはインテグレーションプロセス及び移行プロセスの目
標を支援するために要求されることもよくある。
4) 格納されたシステム要素が，修理率及び計画された修理交換スケジュールに合うような，要求され
る交換補充レベルをロジスティクス作業が満たしていることを確認する。
注記 保管期間中の，交換用の予備品の品質及びアベイラビリティ，それらの輸送，並びにそれ
らの継続的な完整性を監視する。必要に応じて，運用操作者の人数及びスキルを維持する
ために，要員の取得，教育訓練及び認定を行う。
5) ロジスティクス作業が，計画され，資源配分され，そして実施される，システム運用の支援性に関
する能力についての要求事項を含んでいることを確認する。
注記 ロジスティクス作業は，システムが運用準備完了となることを可能にする。その作業は，
要員計画，供給支援，支援設備，技術的データへのニーズ（運用操作の手順説明書，取扱
説明書，一覧表など），教育訓練支援，設備・コンピュータ機器資源支援及び施設を含む。
d) 保守及びロジスティクスの結果を管理する。このアクティビティは，次のタスクからなる。
1) 保守及びロジスティクスの結果，並びに遭遇した全ての不具合を記録する。
注記 これは，保守戦略，保守イネーブリングシステム，保守及びロジスティクスの実行，又は
誤ったシステム定義に起因する不具合を含む。根本原因の識別，是正処置又は改善作業の
実現，及び学んだ教訓の記録を目的としてデータを分析するために，プロジェクトアセス
メント及び制御プロセスが用いられる。
2) インシデント及び問題を記録し，それらの解決を追跡する。
注記 問題解決の実行は，品質保証，並びにプロジェクトアセスメント及び制御プロセスを通じ
て取り扱う。要求事項，アーキテクチャ，設計又はシステム要素に対する全ての実際の変
更は，他のテクニカルプロセス内で行う。
3) インシデント，問題，並びに保守及びロジスティクス作業の傾向を識別し，記録する。
注記1 これは，運用及び保守の要員，並びに類似のシステムエンティティ（システム実体要素，
system entities）を開発又は利用している他のプロジェクトに知らせるために使用される。
注記2 インシデント及び問題報告が，結果として実行された対処作業も含めて，品質保証プロ
セスのインシデント及びプロセス管理に関するアクティビティを通して追跡される。
4) 保守要素のトレーサビリティを維持する。
注記 保守作業と，システム要素及びライフサイクルにおける作成物との間で，双方向のトレー
サビリティを維持する。
5) ベースラインのために選定された重要な情報項目を提供する。
98
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記 構成管理プロセスが，構成品目及びベースラインを確立し維持するために利用される。こ
のプロセス（保守）で，ベースラインのための候補となる情報項目を識別し，そしてCM
へ情報項目を提供する。例えば，保守計画及びライフサイクル支援計画である。
6) システム及び保守支援に対する顧客満足度を監視する。
注記 顧客満足度データは，品質管理プロセスの中で使用される。ISO 10004:2012は，顧客満足
度の監視及び測定に関する指針を含んでいる。
6.4.14 廃棄プロセス（Disposal process）
6.4.14.1 目的
廃棄プロセスの目的は，指定された利用目的のためのシステム要素又はシステムの存在を終了させ，置
換又は廃棄される要素を適切に処理し，識別された重大な廃棄ニーズに，（例えば，合意，組織方針，環境，
法律，安全性，セキュリティの観点から）適切に対処することである。
このプロセスは，特定の用途からシステムそのもの又は全てのシステム要素を不活性化，分解及び除去
する。全ての廃棄物を取り扱い，廃棄物を最終的な状態にして，環境を元の状態又は許容可能な状態にま
で戻す。廃棄物は，どのライフサイクル段階の期間中にも，例えば，製造中の廃棄資材のように廃棄処理
中ということがあり得る。このプロセスは，法令，合意，組織上の制約，及び利害関係者要求事項に従っ
て，システム要素及び廃棄物を環境にやさしい方法で破壊，保管又は再利用する。
廃棄には，次のものがサプライチェーンに戻らないようにすることを含む。
− 有効期限切れの要素
− 再使用不可能な要素
− 使用には不十分な要素
要求に応じて，運用操作者及び利用者の健康状態，並びに環境の安全性を監視できるように記録を保持
する。
注記 廃棄プロセスは，概念及び開発段階でのプロトタイプの廃棄，製造段階での廃棄物の処理，並
びに利用段階及び支援段階での修正変更による要素の廃止を含む，システムのライフサイクル
全体に適用されることを意図する。
6.4.14.2 成果
廃棄プロセスの実施に成功すると次の状態になる。
a) 廃棄に関する制約が，要求事項，アーキテクチャ，設計及び実装への入力として提供されている。
b) 廃棄の実施を可能にするために必要な全てのイネーブリングシステム又はサービスが利用可能になっ
ている。
c) システム要素又は廃棄物は，安全性及びセキュリティ要求事項に従って破壊，保管，再利用又は再生
利用されている。
d) 環境は元の状態又は合意された状態に戻されている。
e) 廃棄処置作業及び分析の記録が利用可能になっている。
6.4.14.3 アクティビティ及びタスク
プロジェクトは，廃棄プロセスに関する，適用可能な組織の方針及び手順に従って，次に示すアクティ
ビティ及びタスクを実施しなければならない。
a) 廃棄の準備を行う。このアクティビティは，次のタスクからなる。
1) 各システム要素及び結果として生じる廃棄物を含めた，システムの廃棄戦略を定義する。
注記 廃棄戦略では，次についてのスケジュール，処置作業及び資源を定義する。
99
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
− システムの機能及びサービスの提供を恒久的に終了する。
− システムを社会的及び物理的に受容可能な状態に変え，それを保持し，その後の結果
が利害関係者，社会及び環境へ悪影響を及ぼすことを回避する。
− 廃棄作業，及び廃棄の結果として生じる，物理的な資材及び情報の長期的な状態にお
いても適用可能な，人の健康，安全性，セキュリティ及びプライバシーを考慮する。
− その時点までの資産を移行することを含め，修正された形態又は適応させるように変
更された形態で，将来に利用するためのシステム移行を考慮する。
2) システム要求事項，アーキテクチャ及び設計特性，又は実装技術におけるシステム制約を，廃棄に
関して識別する。
注記 これには，分解の問題，関連付けられているイネーブリングシステム，格納場所へのアク
セス及びアベイラビリティ，並びに利用可能なスキルレベルが含まれる。
3) 廃棄を支援するために必要なイネーブリングシステム又はサービスを識別し計画する。
注記 これには，イネーブリングシステムの要求事項及びインタフェースの識別を含む。
4) 利用されるイネーブリングシステム若しくはサービスを，獲得する又はそれらへのアクセスを取得
する。
注記 廃棄の実現を支援する廃棄用イネーブリングシステムの支援機能が，意図されたように利
用できるかを客観的に確認するために，妥当性確認プロセスが用いられる。
5) システムを保管する場合は，格納施設，保管場所，インスペクションによる検査点検基準及び保管
期間を規定する。
6) 転用，再生又は再利用しないことが望ましい，廃棄された要素又は資材を，サプライチェーンに再
投入することを未然に防止するための予防方法を定義する。
b) 廃棄を実施する。このアクティビティは，次のタスクからなる。
1) システム又はシステム要素を不活性化して取り除くための準備をする。
注記 例えば，次に示す，他のシステムとのインタフェースを考慮する。
− 分解指示に従った電力又は燃料の供給の遮断
− 関連する人の健康，安全性，セキュリティ及びプライバシーの法律
技術又は能力のアップグレードのために対象システムが修正されるとき，影響を受ける
システム要素だけが無効化され，取り除かれる。これは，概念段階又は開発段階での対象
システムのプロトタイプにも適用できる。
2) 適切な廃棄処分及び廃棄処置作業のために，システム，システム要素又は廃棄物を利用又は生産・
製造から取り除く。
注記 廃棄処分には，再利用，再生利用，再調整，分解修理又は破壊が含まれる。廃棄処置作業
及び廃棄処理後の処置作業は，関連する安全性，セキュリティ，プライバシー及び環境の
基準，指示，並びに法律に従って行われる。有効な寿命がまだ残っているシステムの要素
は，現在の状態で，又は分解修理若しくは変更後に，他の対象システム又は組織に移行さ
れる。必要に応じて，システムの有効期間を延長するためにシステム要素を再調整する。
運用操作者を再配置する又は退去させる。システム要素が有効期限切れ，再使用不可能又
は不十分である場合，要素がサプライチェーンに戻らないようにする必要がある。この作
業には，生産・製造段階又は他の段階からの廃棄物の除去が含まれる。
3) システム又はシステム要素から影響を受けた運用要員を撤退させ，関連する操作知識を記録する。
100
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
注記 これは，関連する安全性，セキュリティ，プライバシー，環境基準，指示及び法律に従っ
て実施する。運用操作者が保有する知識及びスキルを保護し，確保するように行動する。
知識管理プロセスを参照。
4) 再利用，再生利用，再調整，分解修理，保管又は破壊のために要素を取り外しやすくするよう，シ
ステム又はシステム要素を管理可能な要素に分解する。
5) サプライチェーンに戻らないことを確実にする方法で，再使用を意図していないシステム要素及び
その部品を取り扱う。
6) 必要に応じて，廃棄物処理の量を減らすため，又は廃棄物を取り扱いやすくするために，システム
要素の破壊を実施する。
注記 このアクティビティは，必要に応じてシステム若しくはそのシステム要素を，溶解する，
粉砕する，焼却する，破壊する又は根絶するために要求される破壊処理サービスを取得す
ることを含む。
c) 廃棄を確実化する。このアクティビティは，次のタスクからなる。
1) 廃棄後に人の健康，安全性，セキュリティ及び環境に有害な要因が存在しないことを確認する。
2) 環境を元の状態に戻すか，又は合意によって指定された状態に戻す。
3) システムの存続期間を通じて収集された情報を保存管理することで，人の健康，安全性，セキュリ
ティ及び環境への危害が，長期間存続するハザードによるイベントとして発生することについての
監査及びレビューを可能にし，将来のシステム作成者及び利用者が過去の経験から知識ベースを構
築できるようにする。
101
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
附属書A
（規定）
修整（tailoring）プロセス
A.1 序文
この附属書Aは，修整プロセスを実施する場合の要求事項を規定する。
注記1 修整（tailoring）は，規格に適合させるための要求事項ではない。事実上，“完全な適合”を
主張する場合は，修整は許されない。“修整された適合”を主張する場合に，このプロセスが，
修整を実施するために適用される。
注記2 修整についての追加の手引は，ISO/IEC/IEEE 24748-1:2018に記載している。
A.2 修整プロセス（Tailoring process）
A.2.1 目的
修整プロセスは，次のような特定の状況又は要因に対応するために，この規格のプロセスを適応させる
ことを目的とする。
a) 合意において，この規格を用いる組織を取り巻く状況又は要因
b) この規格が参照されている合意を満たすことを要求される，プロジェクトに影響する状況又は要因
c) 製品又はサービスを供給するために組織のニーズを反映する状況又は要因
A.2.2 修整（tailor）プロセスの成果
修整プロセスの実施に成功すると次の状態になる。
a) ライフサイクルモデルの目的及び成果を達成するために，修正（modify）されたライフサイクルプロ
セス又は新しいライフサイクルプロセスが定義されている。
A.2.3 修整（tailor）プロセスのアクティビティ及びタスク
この規格を修整する場合，組織又はプロジェクトは，要求に応じて，修整プロセスに関して適用可能な
方針及び手順に従って，次のタスクを実施しなければならない。
a) 修整に影響を与える状況を識別し記録する。これらの影響は，次を含むが，それらに限定するもので
はない。
1) 運用環境の安定性及び多様性
2) 当事者の懸念する関心事である商業リスク又は業績リスク
3) 新規性，規模及び複雑さ
4) 利用開始日及び利用期間
5) 安全性，セキュリティ，プライバシー，使用性，アベイラビリティなどの完整性（integrity）に関す
る課題
6) 新たな技術の利用機会
7) 利用可能な予算及び組織の資源のプロファイル（概要）
8) イネーブリングシステムのサービスのアベイラビリティ
9) システムの全般的なライフサイクルにおける役割，責務，説明責任及び権限
10) 他の規格に従う必要性
b) 特性がシステムに対して重大な場合，重大性の側面に関連する標準が推奨する，又は要求するライフ
102
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
サイクルの構造を十分に考慮する。
c) 修整の決定によって影響を受ける当事者から意見を聞く。当事者には，次のものを含むが，それらに
限定するものではない。
1) システムの利害関係者
2) その組織による合意に関心をもつ当事者
3) 寄与する組織の部門
d) 選択されたライフサイクルモデルの目的及び成果を達成するため，意思決定管理プロセスに従って修
整の決定を下す。
注記1 組織は，ライフサイクルモデル管理プロセスの一部として標準のライフサイクルモデルを
確立する。確立するライフサイクルモデルの段階の目的及び成果を達成するために，組織
がこの規格のプロセスを修整することが適切な場合がある。
注記2 プロジェクトは，組織で設定したライフサイクルモデルを，プロジェクト計画プロセスの
一部として，そのプロジェクトのために選択する。選択されたライフサイクルモデルの段
階の目的及び成果を達成するために，組織が採用したプロセスを修整することがある。
注記3 プロジェクトがこの規格を直接的に適用する場合，適切なライフサイクルモデルの段階の
目的及び成果を達成するために，この規格のプロセスを修整することがある。
e) 修整を必要とするライフサイクルプロセスを選択し，かつ，選択された成果，アクティビティ又はタ
スクを削除する。
注記1 修整にかかわりなく，組織及びプロジェクトは，この規格に適合するために要求される成
果又はアクティビティ及びタスクのほかに，追加の成果を達成するか又は追加のアクティ
ビティ及びタスクを実施するプロセスを実施することは常に許される。
注記2 組織又はプロジェクトは，この規格の規定を修正（modify）したい状況に遭遇することが
ある。他のプロセス，成果，アクティビティ又はタスクに予測できない結果に至る可能性
があるので，修正（modification）を避けることが望ましい。必要な場合は，［修整（tailor）
された適合性を適切に主張して］規定を削除することによって修正（modification）が実行
され，かつ，影響に注意深く配慮して，修整（tailor）された規格の成果又はアクティビテ
ィ及びタスクのほかに，追加の成果を達成するか又は追加のアクティビティ及びタスクを
実行するプロセスを実施することによって修正（modification）が実行される。
103
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
附属書B
（参考）
プロセス情報項目の例
B.1
序文
表B.1は，各プロセスと関連し得る，情報項目の集合を提供している。
注記1 情報項目に関する追加の手引はJIS X 0171を参照。
注記2 JIS X 0171:2014（ISO/IEC/IEEE 15289:2011）が参照できるが，この規格に対応させた
ISO/IEC/IEEE 15289:2017へ改正がされている。
表B.1−情報項目の例
合意プロセス
適格性のある有資格要員
取得プロセス
スタッフ割当て記録
供給依頼（入札依頼）
品質管理プロセス
供給者選定報告
品質管理方針，目標及び手順
合意
品質保証アセスメント報告
合意変更管理手順
是正及び予防処置報告
合意変更報告
知識管理プロセス
供給者アセスメント報告
知識，スキル及び知識資産記録
納入受入れ報告
知識，スキル及び知識資産報告
供給プロセス
知識，スキル及び知識管理要素
供給者の対応回答（例 提案，入札）
テクニカルマネジメントプロセス
合意変更管理手順
プロジェクト計画プロセス
合意変更依頼
プロジェクトのテクニカルマネジメント計画
供給者の納入記録
プロジェクトライフサイクルモデル
組織のプロジェクトイネーブリングプロセス
作業分解構造（WBS）
ライフサイクルモデル管理プロセス
プロジェクトスケジュール
ライフサイクルの方針，プロセス
プロジェクト予算
ライフサイクルの手順
プロジェクトインフラストラクチャ及びサービス要求
事項
ライフサイクルモデル
プロジェクト承認記録
プロセスアセスメント結果
プロジェクトアセスメント及び制御プロセス
プロセス改善報告
プロジェクトアセスメント記録
インフラストラクチャ管理プロセス
測定分析結果及び推奨事項
インフラストラクチャ要求事項
プロジェクトアセスメント報告
インフラストラクチャ要素
プロジェクト制御依頼
インフラストラクチャ変更依頼
次のマイルストーンへの進行許可
ポートフォリオ管理プロセス
意思決定管理プロセス
ポートフォリオ分析報告
意思決定手続
プロジェクト開始報告
意思決定報告
プロジェクト評価報告
リスク管理プロセス
プロジェクト終了報告
リスクプロファイル
人的資源管理プロセス
リスク処置作業依頼
要求スキル報告
リスクプロファイル報告
スキル一覧表
構成管理プロセス
スキル開発資産
構成管理記録
スキル開発記録
構成ベースライン
104
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
表B.1−情報項目の例（続き）
構成管理の変更・差分化依頼
トレーサビリティ対応付け
構成状況報告
システム分析プロセス
構成評価報告
システム分析報告
システムリリース報告
実装プロセス
情報管理プロセス
システム要素
情報項目登録
実装記録
情報管理報告
実装報告
測定プロセス
トレーサビリティ対応付け
測定記録
インテグレーションプロセス
測定情報ニーズ報告
インテグレーションで統合されたシステム要素
品質保証プロセス
インテグレーション記録
品質保証評価報告
インテグレーション報告
品質保証記録
トレーサビリティ対応付け
インシデント記録
検証プロセス
問題記録
検証されたシステム
テクニカルプロセス
検証記録
ビジネス又はミッション分析プロセス
検証報告
予備的なライフサイクル概念
トレーサビリティ対応付け
問題又は機会
移行プロセス
代替ソリューション及び推奨ソリューション
運用のために用意された場所
利害関係者ニーズ及び利害関係者要求事項定義プロセス
導入されたシステム
システムレベルの運用概念
移行記録
ライフサイクル概念
移行報告
利害関係者ニーズ
トレーサビリティ対応付け
利害関係者要求事項
妥当性確認プロセス
利害関係者要求事項報告
妥当性確認されたシステム
重大なシステムの遂行能力・性能・運用時の実績の測定量 妥当性確認記録
トレーサビリティ対応付け
妥当性確認報告
システム要求事項定義プロセス
トレーサビリティ対応付け
システム記述
運用プロセス
システム要求事項
運用記録
システム要求事項報告
運用上の問題報告
重大なシステムの遂行能力・性能・運用時の実績の測定量 顧客支援記録
トレーサビリティ対応付け
運用報告
アーキテクチャ定義プロセス
保守プロセス
アーキテクチャ ビューポイント
交換システム要素
アーキテクチャ ビュー及びモデル
保守記録
論拠を伴ったアーキテクチャ報告
保守依頼
インタフェース定義（初期）
保守問題報告
アーキテクチャ アセスメント報告
ロジスティクス作業及び報告
トレーサビリティ対応付け
保守報告
設計定義プロセス
廃棄プロセス
設計特性報告
廃棄された項目
設計作成物
廃棄記録
論拠を伴った設計作成物報告
保存管理報告
インタフェース定義
−
105
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
附属書C
（参考）
アセスメント目的のプロセス参照モデル
C.1 序文
この規格の利用者の中には，実施されたプロセスをJIS X 33002に従ってアセスメントを実施したいと
思っている人がいることが知られている。この附属書Cは，JIS X 33002と関連させて使用することで適
切なプロセス参照モデルを提供する。
注記 対応国際規格で引用しているJIS X 0145-2:2008（ISO/IEC 15504-2）はプロセスアセスメントの
実施に関する要求事項を規定しているが，これはプロセスアセスメントを規定するJIS X
33002:2017（ISO/IEC 33002:2015），プロセスの測定の枠組み及びプロセス属性のレベルに関す
るJIS X 33003:2019（ISO/IEC 33003:2015）及びJIS X 33020:2019（ISO/IEC 33020:2015），並び
にプロセス参照モデルへの規定要求事項を含むISO/IEC 33004:2015として改正が進み，JIS X
0145規格群もJIS X 33000規格類として改正が進められている。
プロセス参照モデルは，各プロセスの名称，目的の記述及び成果の記述を含めて，この規格の本文中の
プロセスから構成されている。C.3は，プロセス参照モデル内のプロセス及びそれらを定義する箇条を識
別している。
C.2 JIS X 0145-2及びISO/IEC 33004との適合
C.2.1 概要
JIS X 0145-2及びISO/IEC 33004は，その規格を用いたアセスメントに適しているプロセス参照モデル
に対する要求事項を示している。C.2.2及びC.2.3は，プロセス参照モデルに対する要求事項を引用し，こ
の規格がどのようにこれらの要求事項を満たしているかを記述する。C.2.2及びC.2.3の斜体の記載は，JIS
X 0145-2及びISO/IEC 33004の要求事項を引用して記載したものであり，斜体でない記載は，要求事項が
この規格によってどのように満たされるかを記述している。
C.2.2 プロセス参照モデルに対する要求事項
プロセス参照モデルは，次の事項を含まなければならない。
a) プロセス参照モデルの領域の宣言
これは，箇条1に規定されている。
b) JIS X 0145-2及びISO/IEC 33004の要求事項を満足する，プロセス参照モデルの適用範囲内のプロセ
スの記述
これは，C.3に記載されている。
c) プロセス参照モデルとそれを利用しようとしている背景との関係の記述
これは，箇条5に規定されている。
d) プロセス参照モデルに定義しているプロセス間の関係の記述
これは，各プロセス記述においてC.3に記載されている。例えば，プロセスの記述の中には，プロ
セスが下位のプロセスを含むという記述を含むものがある。
プロセス参照モデルは，そのモデルに関心をもっている人たち及びその人たちの中で合意を得るための
106
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
行動を，次のように文書化しなければならない。
a) 直接的に関心のある人たちを特徴付けるか，指定する。
直接的に関心のある人たちは，この規格及びISO/IEC/IEEE 12207の利用者である。
b) 合意の達成度合いを文書化する。
この規格及びISO/IEC/IEEE 12207は，ISO/IEC JTC 1の合意の要求事項を満たす規格である。
c) 合意達成のための行動をとらない場合，その影響を文書化する（該当なし）。
プロセス参照モデルで定義されたプロセスは，一意のプロセス記述及び識別情報をもっていなければな
らない。
プロセスの記述は一意であり，識別は一意に決まるプロセス名称及びこの附属書Cにあるような箇条番
号を識別情報とすることによって行える。
C.2.3 プロセスの記述
プロセス参照モデルの基本的な構成要素は，そのモデルの適用範囲内でのプロセスの記述である。プロ
セス参照モデルでのプロセス記述は，プロセスの目的の十分な達成を実証する一連の成果とともに，プロ
セスを実施する全体的な目標を高い水準で記載したプロセスの目的の記述から成り立っている。これらの
プロセス記述は，次の要求事項を満足しなければならない。
a) プロセスは，プロセスの目的及びプロセスの成果を記述する。
b) どのプロセス記述においても，一連のプロセスの成果はそのプロセスの目的を達成するために必要十
分である。
c) プロセス記述は，JIS X 0145-2及びJIS X 33020のレベル（水準）1を超えたところの測定の枠組みの
側面を含んでいないし，また，暗示もしていない。
成果の記述の項目には，次のいずれか一つを記述する。
− 作業生産物の生産
− 状態の重要な変化
− 特定の制約条件（例えば，要求事項，目標など）の合致
これらの要求事項は，この附属書Cの中のプロセスの記述によって満たされる。成果の中にはレベル2
以上のレベルの能力へ寄与すると解釈されるものもある。しかしながら，適合したプロセスの実施は，こ
れらの上位レベルの能力の達成を要求するものではない。
C.3 プロセス参照モデル
プロセス参照モデルは，この規格の箇条6に含まれる各プロセスの目的及び成果の記述によって構成さ
れている。システムライフサイクルに対するプロセス参照モデルは，図4のプロセス集合から構成されて
いる。
107
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
附属書D
（参考）
プロセスのインテグレーション及びプロセスの構成概念
D.1 序文
ISO/IEC JTC 1/SC 7内の調和化プロジェクト（すなわち，この規格であるISO/IEC/IEEE 15288及び
ISO/IEC/IEEE 12207の並行した，注意深く調整された改正及びこれら両国際規格の利用の指針となる
ISO/IEC/IEEE 24748-1:2018の作成）は，システムライフサイクル及びソフトウェアライフサイクルを記
述している統合化された一組の規格を形成する大きな歩みである。継続的なプロセス改善及び能力アセス
メントの概念は，今やかなり確立され，認識されていて，JIS X 33000（ISO/IEC 33000）規格類として規
格化されている。この規格及びISO/IEC/IEEE 12207の附属書Cで規定されたプロセス参照モデルは，ラ
イフサイクルプロセスの能力アセスメントに対して，JIS X 33000規格類とともに使用されることを意図し
ている。プロセスの能力判定には，プロセス記述がそのプロセスの目的の明確な記述及び期待される成果
の記述を含むことを必要としている。プロセスの矛盾のない実施は，アクティビティ，タスク及び定義さ
れた実施の注記をもつことによって支援されている。それゆえ，システムライフサイクル及びソフトウェ
アライフサイクルの両ライフサイクル規格におけるライフサイクルプロセスは，D.2に記述しているよう
に，共通のプロセス構成概念に適用されており，ISO/IEC TR 24774に含まれるプロセス定義の手引と調和
している。
D.2 プロセス構成概念及びその使用
この規格の中のプロセスの記述は，明確に定義された規則に従う。まず第一に，それらは，論理的形態
でグループにまとめられている。これらのグループ分けは，次によって決められている。
− プロセス間の論理的関係
− プロセスの実行に対する責任
この規格では，システムのライフサイクルで実行するアクティビティを四つのプロセスグループに分け
ている。これらのグループの最上位の記述は，5.6に見いだされる。これらのグループ内の各ライフサイク
ルプロセスは，その目的及び望まれる成果に関して記述されており，これらの成果を達成するために実施
することが必要なアクティビティ及びタスクを列挙している。
a) 合意プロセス
2個のプロセス（6.1）
b) 組織のプロジェクトイネーブリングプロセス
6個のプロセス（6.2）
c) テクニカルマネジメントプロセス
8個のプロセス（6.3）
d) テクニカルプロセス
14個のプロセス（6.4）
プロセス記述規則の矛盾のない適用によって，正規化した細分箇条の番号付けが可能となる。この規格
の中では，細分箇条番号は，次のようになっている。
− 6.xは，プロセスグループの名称である。
− 6.x.yは，そのグループ内のプロセスの名称である。
− 6.x.y.1は，プロセスの目的を記述する。
− 6.x.y.2は，プロセスの成果を記述する。
− 6.x.y.3は，プロセスのアクティビティ及びタスクを記述する。
108
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
図D.1は，この規格及びISO/IEC 12207:2017の中で使用されているプロセス構成のUML表現である。
プロセスには，目的及び成果が必要である。全てのプロセス
は，少なくとも一つのアクティビティをもつ。プロセスは，
目的及び成果の記述を伴って，プロセス参照モデル（PRM）
を構成する。
アクティビティは，関連するタスクをまとめる構造をしてい
る。アクティビティは，プロセスの理解及び伝達を向上する
ために，プロセス内の関連するタスクを調べる方法を提供す
る。アクティビティの凝集度が十分に高い場合は，目的及び
成果の集合を定義することによって，（より下位の）プロセ
スに昇格することができる。
タスクは，プロセスを実行するための詳細な規定である。タ
スクは，要求事項（shall），推奨事項（should）又は許容事
項（may）のいずれかである。
プロセスの意図及び構造をよりわかりやすく説明するために
解説情報を必要とするとき，注記を使用する。注記は，行い
得る実施手段又は適用可能な領域に関する洞察を提供する
（例えば，一覧，例，その他の検討事項などで注記する）。
JIS X 0170のプロセス構成
名称
注記
タスク
プロセス
名称,目的，成果
アクティビティ
０….＊
１….＊
０….＊
１
１
１
１
１….＊
図D.1−この規格及びISO/IEC/IEEE 12207のプロセス構成
109
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
附属書E
（参考）
プロセスビュー
E.1
序文
特定のエンジニアリングに対する関心を代表している人たちが，その関心について直接的及び端的に対
応した一組のプロセスのアクティビティを1か所に集めてみたいという場合がある。そのような人たちに
対して，ライフサイクルの全部又は一部を横断する形態で，特定の関心に焦点を当てるために，この規格
又はISO/IEC/IEEE 12207から選ばれたプロセス，アクティビティ及びタスクを編成して，プロセスビュ
ーを作成することができる。この附属書Eは，これらの場合にプロセスビューを定義するために使用して
もよいプロセスのビューポイントを提供する。
E.2
プロセスビューの概念
ライフサイクルプロセスにわたって使われるプロセスにまたがる重要な概念又は脈絡を分かりやすくす
るために，全く異なるプロセスから選ばれたアクティビティ及びタスクに対して，統一した焦点が必要と
される場合があり得る。特定の関心事に対応する単一のプロセスを見つけられなくても，使用するために
アクティビティをどのようにして識別し，定義するかを，作業標準の利用者に助言することは有用である。
この目的のために，プロセスビューの概念が正式化された。プロセスのように，プロセスビューの記述
は目的及び成果の記述を含む。プロセスとは異なり，プロセスビューの記述は，アクティビティ及びタス
クを含まない。その代わりに，その記述は，この規格及びISO/IEC/IEEE 12207の様々なプロセスのアク
ティビティ及びタスクを用いてどのようにして成果を達成できるかを説明する手引を含んでいる。
プロセスビューは，E.3に見いだされるプロセスビューポイントテンプレートを使用して構成できる。
E.3
プロセスビューポイント
プロセスビューは，プロセスビューポイントに適合している。ここに挙げられたプロセスビューポイン
トは，プロセスビューを生成するために使用できる。
プロセスビューポイントは，次によって定義される。
− その利害関係者：作業標準の利用者
− それが枠組みとなる関心事：特定のエンジニアリングの関心事を反映するために必要なプロセス
結果であるプロセスビューの内容には，次を含んでいる。
− プロセスビューの名称
− プロセスビューの目的
− プロセスビューの成果
− プロセスビューを実施するプロセス，アクティビティ及びタスクの識別及び記述，並びにこれらのプ
ロセス，アクティビティ及びタスクの元が他の作業標準のどこにあるかを示す参照
注記 ビューポイントの文書化に対する要求事項は，ISO/IEC/IEEE 42010の5.4に含まれている。こ
の記述は，それらの要求事項と矛盾がない。
110
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
E.4
スペシャルティエンジニアリングに対するプロセスビュー
ここでは，スペシャルティエンジニアリングに対するプロセスビューを生み出すためにプロセスビュー
ポイントを適用する例を示す。これは，特に興味深いものとして選択された製品特性の達成に注目するた
めに，プロジェクトがこの規格のプロセス，アクティビティ及びタスクをどのように組み立てるかを解説
することを意図している。
注記 “スペシャルティエンジニアリング”は，システムエンジニアリングにおける主要なエンジニ
アリング（例えば，ハードウェアエンジニアリング，ソフトウェアエンジニアリング，人間工
学など）を除くエンジニアリングドメイン（領域）のことをいう。電磁障害，電気接地（アー
ス），安全性，セキュリティ，電力フィルタ・無停電電源などのエンジニアリングドメイン，及
び環境エンジニアリングをシステムエンジニアリングに含めるとき，これらのものを“スペシ
ャルティエンジニアリング”とみなす。
この例は，一般にスペシャルティエンジニアリングと呼ばれる一群の関心事を取り扱う。これには，次
のものに限定はしないが，アベイラビリティ，保守性，信頼性，安全性，セキュリティ，人的要因，使用
性などの領域を含んでいる。この規格内では，これらの“〜性”要求事項は，“重大な品質特性”として参
照される。これらの特性は，焦点を当てるために選択された領域内で，指定された要求事項を製品がどの
程度うまく満たしているかを決定する。これらの特性は，焦点を当てるために選択された特定領域内で，
指定された要求事項を製品がどの程度うまく満たしているかを決定する。
注記 これは，スペシャルティエンジニアリングに関連する幅広い一連の機能的な特性及び非機能的
な特性を包含するプロセスビューの一般化された具体例である。それは，プロセスをまたがっ
た幅広いビューを提供する。特定の重大な品質特性が他の特性と比較して高い優先順位をもつ
場合，より詳細な情報及び要求事項を含む特定のプロセスビューをその特性に対して作成する
ことができる。
名称：スペシャルティエンジニアリングプロセスビュー
目的：スペシャルティエンジニアリングプロセスビューの目的は，特に関心のある選択された，重大な品
質特性について満足できる水準をシステムが達成することの客観的な証拠を提供することである。
成果：
a) 製品の重大な品質特性が，特別に注目されるために選択されている。
b) 重大な品質特性の達成のための要求事項は，定義されている。
c) 要求事項に対する測定量は，選択され，求められる，重大な品質特性に関係付けられている。
d) 求められる重大な品質特性を達成するための取組方法が定義され，実施されている。
e) 要求事項の達成の範囲は，継続的に監視されている。
f)
重大な品質の達成度が，指定され，作成される。
注記 成果では，望まれる重大な品質特性が直接測定できない場合は，測定可能な他の製品又はプロ
セスの特性に基づいて論証し，推測することも許容される。
プロセス，アクティビティ及びタスク：
このプロセスビューは，JIS X 0170の次のプロセス，アクティビティ及びタスクを使用して実施できる。
注記1 JIS X 25030は，ソフトウェア製品の品質要求事項を規定するのに役立つ場合がある。
注記2 多くのスペシャルティエンジニアリング領域及びそれに関連する重大な品質特性についての
説明及び詳細は，INCOSEシステムエンジニアリングハンドブックに記載がある。
a) ビジネス又はミッション分析プロセス（6.4.1）は，関連するトレードオフ空間を構成する要因，及び
111
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
事前に準備されるライフサイクルの概念を含んだ，問題空間の定義，並びにソリューション空間の特
徴付けを提供する。これには，重大な品質特性（例えば，セキュリティ上の脅威，安全上のハザード，
ヒューマンインタフェース，運用操作上の特性，及びシステムのアシュアランスを行う状況）などの
全ての重要なパラメータ，及びそれらが適用される状況への理解を深めることが含まれる。関連する
アクティビティ及びタスクには，6.4.1.3のb) 1)及び2)，c) 1)並びにd) 1)を含む。
b) 利害関係者ニーズ及び利害関係者要求事項定義プロセス（6.4.2）は，重大な品質特性を含めた特性の
選択及び定義並びに関連する情報項目を提供する。アクティビティ及び文書化は，重大な品質特性に
ついての要求事項を識別し，優先順位を付け，定義し記録するには有効である。関連するアクティビ
ティ及びタスクは，6.4.2.3のa) 1)及び2)，b) 2)，3)及び4)，c) 1)及び2)，d)の全タスク並びにe) 2)を
含む。
c) システム要求事項定義プロセス（6.4.3）は，重大な品質特性のパラメータの指定，及び開発する特定
のシステムに関するこれらの要求事項の達成状況を追跡するための手段の選択を提供する。関連する
アクティビティ及びタスクは，6.4.3.3のa) 1)，b)の全タスク及びc) 2)を含む。
d) アーキテクチャ定義プロセス（6.4.4）は，アーキテクチャの観点から利害関係者の関心事を識別する
ためのものである。これらの関心事は，利用率（アベイラビリティ，セキュリティ，有効性，有用性
など），支援（修復性，陳腐化管理など），システム及び環境（適応性，拡張性，生存性など）の発展，
生産（生産可能性・製造性，テスト容易性など），廃止（環境への影響，輸送性など）などの重大な品
質特性に関連するライフサイクル段階全体にわたる期待又は制約に変換されることが多い。これには，
関心事及び関連する特性に関するアーキテクチャのアセスメントも含む。関連するアクティビティ及
びタスクは，6.4.4.3のa) 2)及び4)，b) 1)，c) 2)，3)，4)及び5)，d) 1)並びにe) 2)を含む。
e) 設計定義プロセス（6.4.5）は，スペシャルティ特性に対する設計基準の安全性，及びそれらの基準に
照らした代替設計の評価などの重大な品質特性を含む，必要な設計特性の決定を提供する。関連する
アクティビティ及びタスクは，6.4.5.3のa) 2)，b) 1)，2)，3)，4)及び6)並びにc) 2)を含む。
f)
システム分析プロセス（6.4.6）は，数学的分析，モデリング，シミュレーション，実験及び他の技法
の実施を通じて，重大な品質特性に関してトレードオフ空間を理解するために必要な分析のレベルを
提供する。分析結果は，他のテクニカルプロセスを支援する意思決定プロセスを通じて行われるトレ
ードオフ分析への入力となる。関連するアクティビティ及びタスクは，6.4.6.3のa)の全タスク及びb)
の全タスクを含む。
g) 実装プロセス（6.4.7）は，重大な品質要求事項が満たされている証拠の記録を提供する。関連するア
クティビティ及びタスクは，6.4.7.3のb) 3)を含む。
h) インテグレーションプロセス（6.4.8）は，重大な品質要求事項についての配慮を含めて，インテグレ
ーションの計画及び特性の達成が決定され，記録されているという保証を提供する。関連するアクテ
ィビティ及びタスクは，6.4.8.3のa) 1)，b) 3)及び c) 1)を含む。
i)
検証プロセス（6.4.9）は，重大な品質特性を含め，検証を実施するための方針の計画及び実行を提供
する。選択された検証方針は，その特性の達成に影響を及ぼす設計の制約を導入してもよい。関連す
るアクティビティ及びタスクは，6.4.9.3のa) 1)及び3)，b) 1)及び2)並びにc) 1)及び2)を含む。
j)
移行プロセス（6.4.10）は，その運用環境にシステムを導入することを提供する。幾つかのスペシャル
ティプロパティは，設計の制約及び運用の制約とのトレードオフを伴うので，導入での注意が重要に
なることが多い。関連するアクティビティ及びタスクは，6.4.10.3のa) 4)，b) 4)及び6)並びに7)を含
む。
112
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
k) 妥当性確認プロセス（6.4.11）は，重大な品質特性を含め，システムの提供するサービスが利害関係者
のニーズに合致している証拠を提供する。関連するアクティビティ及びタスクは，6.4.11.3のa) 1)及
び3)，b) 1)及び2)並びにc) 1)及び2)を含む。
l)
運用プロセス（6.4.12）は，システムの利用を提供する。重大な品質特性が適切に達成されていること
を保証することは，システムの運用を監視することを含む。関連するアクティビティ及びタスクは，
6.4.12.3のb) 3)及び4)，c) 1)及び2)並びにd) 1)及び2)を含む。
m) 保守プロセス（6.4.13）は，その重大な品質特性を含む，機能を継続的に提供できるよう，システムの
能力を維持する。これには，システムの継続的な運用を保証するために必要な障害分析，保守タスク，
及びロジスティクスのタスクが含まれる。関連するアクティビティ及びタスクは，6.4.13.3のb)の全
タスク，c)の全タスク並びにd) 1)及び2)を含む。
n) 廃棄プロセス（6.4.14）は，システムの存在を終わらせる。廃棄を予測する固有のニーズは，システム
開発に制約を課することがある。実際，これらの制約は，それ自身，重大な品質特性であってもよい。
関連するアクティビティ及びタスクは，6.4.14.3のa) 2)，b) 1)及び2)並びにc) 3)を含む。
o) プロジェクトアセスメント及び制御プロセス（6.3.2）は，要求事項及び重大な品質特性の達成の度合
いの監視，並びに利害関係者及び管理者への結果の通知を提供する。関連するアクティビティ及びタ
スクは，6.3.2.3のb) 6)，7)，9)及び10)を含む。
p) 意思決定管理プロセス（6.3.3）は，重大な品質特性を含む決定基準に対する代替要求事項，アーキテ
クチャ特性及び設計特性のアセスメントを提供する。これらの比較の結果は，適切な選択モデルを介
してランク付けされ，次いで，最適なソリューションを決定するために使用される。関連するアクテ
ィビティ及びタスクは，6.3.3.3のb)の全タスク及びc) 1)を含む。
q) リスク管理プロセス（6.3.4）は，全体として，重大な品質特性を満たすことに関連するものを含め，
システムのリスクの識別，評価及び対処を提供する。
r) 情報管理プロセス（6.3.6）は，全体として，達成の度合いの文書化及び伝達のための情報項目の仕様，
開発及び保守を提供する。重大な品質特性の目的のために使用される情報項目は，その性質から，ス
ペシャルティ成果物となることがあるということを書きとめておくことが望ましい。これらの情報項
目を記述するための情報源には，業界団体，規制機関及び特定の標準が含まれる。
s)
測定プロセス（6.3.7）は，全体として，要求される重大な品質特性に測定量を関連付ける取組方法の
定義を提供する。
t)
品質保証プロセス（6.3.8）は，識別された，重大な品質特性の達成に関係する不具合（インシデント
及び問題）を取り扱う。
E.5
インタフェース管理に対するプロセスビュー
ここでは，プロセスビューポイントを適用して，インタフェース管理のプロセスビューを生成する例を
示す。この例は，プロジェクトがこの規格のプロセス，アクティビティ及びタスクをどのように組み立て，
特別な関心事として選択された製品特性の達成に焦点を当てるかを説明することを意図している。
この例では，インタフェース管理と呼ばれるプロセスビューの特定のインスタンスを扱う。これには，
インタフェース定義，設計及び変更管理が含まれるが，これに限定されない。この規格では，インタフェ
ース管理を構成するタスクは既存のプロセスに完全に含まれている。
名称：インタフェース管理プロセスビュー
目的：インタフェース管理プロセスビューの目的は，システムのインタフェースの識別，定義，設計及び
113
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
管理を容易にすることである。
成果：
a) インタフェースに関連するビジネス又はミッションのニーズが識別されている。
b) インタフェースに関係する利害関係者のニーズが識別されている。
c) インタフェース要求事項が定義されている。
d) システム要素間のインタフェースが識別され，定義されている。
e) システムと外部システムとの間のインタフェースが識別され，定義されている。
f)
インタフェース要求事項の実現範囲が継続的に監視されている。
g) インタフェース要求事項の達成度が識別され，開発されている。
プロセス，アクティビティ及びタスク：
このプロセスビューは，JIS X 0170の次のプロセス，アクティビティ及びタスクを使用して実施できる。
注記 インタフェース管理についての説明及び詳細は，INCOSEシステムエンジニアリングハンドブ
ックに記載がある。
a) ビジネス又はミッション分析プロセス（6.4.1）は，問題空間の定義，環境及び利用状況の記述，並び
に予備的なシステムレベルの運用概念を含むソリューション空間の特徴付けを提供する。これは，対
象システムとのインタフェースをもたなければならない外部システムを識別することがよくある。関
連するアクティビティ及びタスクには，6.4.1.3のb) 1)及び2)並びにc) 1)を含む。
b) 利害関係者ニーズ及び利害関係者要求事項定義プロセス（6.4.2）は，システムレベルの運用概念の定
義，並びにシステムと利用者及び意図された環境（他のシステムを含む。）との相互作用を定義する。
これは，対象システムとのインタフェースをもたなければならない外部システムを識別することがよ
くある。関連するアクティビティ及びタスクには，6.4.2.3のc) 1)及び2)並びにd) 1)及び3)を含む。
c) システム要求事項定義プロセス（6.4.3）は，インタフェース要求事項の定義を提供する。関連するア
クティビティ及びタスクには，6.4.3.3のa) 1)，b)の全タスク，c)の全タスク及びd)の全タスクを含む。
d) アーキテクチャ定義プロセス（6.4.4）は，アーキテクチャモデルが発展するにつれて，アーキテクチ
ャの観点からインタフェースの識別を提供する。このプロセスは，アーキテクチャ記述に必要な範囲
でインタフェースを更に記述し定義する。関連するアクティビティ及びタスクには，6.4.4.3のa) 2)及
び4)，c) 1)〜4)，d)の全タスク並びにf) 3)〜6)を含む。
e) 設計定義プロセス（6.4.5）は，インタフェースの洗練された完全な定義及び必要な情報項目の作成を
提供する。関連するアクティビティ及びタスクには，6.4.5.3のb) 5)及び6)並びにd) 1)〜3)を含む。
f)
システム分析プロセス（6.4.6）は，数学的分析，モデリング，シミュレーション，実験及び他の技法
の実施を通じて，インタフェース要求事項及び定義に関するトレードオフ空間を理解するために必要
な分析のレベルを提供する。分析結果は，他のテクニカルプロセスを支援する意思決定プロセスを通
じて行われるトレード分析への入力となる。関連するアクティビティ及びタスクには，6.4.6.3のa)の
全タスク及びb)の全タスクを含む。
g) 実装プロセス（6.4.7）は，インタフェースの開発，及び実装されたシステム要素に対するインタフェ
ース要求事項が満たされているという証拠の記録を提供する。関連するアクティビティ及びタスクは，
6.4.7.3のb) 3)を含む。
h) インテグレーションプロセス（6.4.8）は，システム要素間のインタフェースに関する考慮事項を含む，
インテグレーションの計画を提供する。また，システム又はシステム要素及びインタフェースの統合
も含まれる。関連するアクティビティ及びタスクには，6.4.8.3のa) 1)，b)の全タスク及びc) 1)を含む。
114
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
i)
検証プロセス（6.4.9）は，システムによって提供されるサービスがインタフェース要求事項を含むシ
ステム要求事項を満たすという証拠を提供する。このプロセスは，インタフェースの要求事項を含む
検証を実行する戦略の計画及び実行を提供する。選択された検証戦略は，それらの達成に影響を与え
る可能性のあるインタフェースの制約を導入してもよい。関連するアクティビティ及びタスクは，
6.4.9.3のa) 1)及び3)，b) 1)及び2)並びにc) 1)を含む。
j)
移行プロセス（6.4.10）は，システムを運用環境に導入するためのものである。これには，制約の識別，
インタフェースの導入及び動作状態の確認が含まれる。関連するアクティビティ及びタスクは，
6.4.10.3のa) 4)並びにb) 3)，4)，6)及び7)を含む。
k) 妥当性確認プロセス（6.4.11）は，システムによって提供されるサービスが，インタフェース要求事項
を含む利害関係者のニーズを満たすという証拠を提供する。選択された検証戦略は，その成果に影響
を与える可能性のあるインタフェース制約を導入してもよい。関連するアクティビティ及びタスクは，
6.4.11.3のa) 1)，2)及び3)，b) 1)及び2)並びにc) 1)及び2)を含む。
l)
運用プロセス（6.4.12）は，システムの使用方法を提供する。また，操作のためのインタフェースに制
約がある場合がある。インタフェース要求事項が適切に達成されることを保証するには，システムの
動作を監視する必要がある。関連するアクティビティ及びタスクは，6.4.12.3のa) 2)，b) 3)及び4)並
びにc) 1)及び2)を含む。
m) 保守プロセス（6.4.13）は，システムの機能を維持し，インタフェースを含む機能を提供する継続的な
アベイラビリティを確保するのに役立つ。これには，システムの継続的な運用を保証するために必要
な障害分析，保守タスク，及びロジスティクスのタスクが含まれる。また，保守のためにインタフェ
ースに制約がある場合がある。関連するアクティビティ及びタスクは，6.4.13.3のa) 2)，b)の全タス
ク並びにd) 1)及び2)を含む。
n) 廃棄プロセス（6.4.14）は，システムの存在を終了させる。インタフェースを解除するためのアクティ
ビティが必要な場合がある。廃棄を予定する固有の必要性は，インタフェースに制約を課す場合があ
る。関連するアクティビティ及びタスクは，6.4.14.3のa) 2)並びにb) 1)及び2)を含む。
o) プロジェクトアセスメント及び制御プロセス（6.3.2）は，インタフェースを含む要求事項の達成度を
監視し，その結果を利害関係者及び意思決定者に伝えるためのものである。関連するアクティビティ
及びタスクは，6.3.2.3のb) 6)，7)，9)及び10)を含む。
p) 意思決定管理プロセス（6.3.3）は，インタフェースを含む決定基準に対する選択肢となる代替要求事
項，アーキテクチャ特性及び設計特性をアセスメントすることを提供する。これらの比較の結果は，
適切な選択モデルを介してランク付けされ，次いで，最適なソリューションを決定するために使用さ
れる。関連するアクティビティ及びタスクは，6.3.3.3のb)の全タスク及びc) 1)を含む。
q) リスク管理プロセス（6.3.4）は，全体として，インタフェースに関連するものを含め，システムのリ
スクの識別，評価及び対処を提供する。
r) 情報管理プロセス（6.3.6）は，全体として，達成度を文書化し，伝達するための情報項目の仕様，開
発及び維持を規定する。
s)
測定プロセス（6.3.7）は，要求されたインタフェースの情報ニーズに測定量を関連付け，識別された
インタフェース情報ニーズに取り組むためにこれらの測定量を生成し，使用する方法を定義する。
t)
品質保証プロセス（6.3.8）は，識別された，インタフェース要求事項の達成に関連する不具合（イン
シデント及び問題）を取り扱う。
115
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
附属書F
（参考）
アーキテクチャのモデル化
F.1
序文
この附属書は，この規格のアーキテクチャ定義及び設計定義プロセスに関して，旧規格のJIS X
0170:2013（ISO/IEC/IEEE 15288:2008）のアーキテクチャ設計プロセスとの関連についての情報を提供す
るものである。
この規格におけるアーキテクチャ及び設計のアクティビティは，複雑なシステムを扱うシステムエンジ
ニアリングのコミュニティにおける異なる実践方法を反映し，二つのプロセスに分割される。一つの例と
して，一つのアーキテクチャから，プロダクトラインにおいては，異なるシステムのための異なる設計へ
と続くこともある。この場合は，これらアーキテクチャ定義及び設計という二つのプロセスを区別された
方法で実施することが重要である。さらに，アーキテクチャはしばしば設計の基礎というより，もっと別
の理由から実施されることがある。例えば，技術面での投資を推進する，複数のプロジェクトを集約した
ポートフォリオを調整する，入札する又は入札しない決定を手引きする，などである。
システムのアーキテクチャは，機能，機能フロー，インタフェース，資源フロー項目，情報・データ要
素，物理的なコンポーネント，コンテナ，ノード，リンク，通信資源などの，構造化された実体要素であ
るアーキテクチャ エンティティ及びそれらの関係の集合として理解することができる。これらのアーキテ
クチャ エンティティは，次元，環境の復元性，アベイラビリティ，堅ろう（牢）性，実行効率，ミッショ
ンに対する有効性などの特性をもち得る。
F.2
アーキテクチャで利用されるビューポイント，ビュー及びモデル種類
アーキテクチャ定義プロセスでは，F.3に列挙するモデルの例を含む様々なモデルを利用する（伝統的
なシステムエンジニアリングの実践では，それらのモデルを“論理モデル”，“物理モデル”などと分類す
るが，この規格の適用においては，分類学的な区別は不要である。）。
ビューの多様性は，システムのアーキテクチャがいかに利害関係者のシステムについての関心事を扱う
かを表現するために利用される。ビューはモデルによって構成される。アーキテクチャに関する用語，並
びにより詳細なアーキテクチャに関する概念及びモデルの定義は，ISO/IEC/IEEE 42010を参照。
F.3
論理モデル及び物理モデル
F.3.1
機能モデル
システムの機能モデル（Functional model）は，そのミッション又は目的を達成するためにシステムによ
って実行される入力から出力への変換を定義する機能の集合を表現したものである。これらの機能は，シ
ステムが利用されたときに，どのように振る舞うことが意図に合うものとして期待されているかによって
決定される。結果として，全てのシステムの機能は，システム及びその環境の間の相互作用に対応付けら
れる。機能要求事項，実行性能要求事項，非機能要求事項，及び制約に関する要求事項が，通常，機能及
び入力から出力への流れを決定するために分析される。機能がシステム要素と対応付けられるとき，設計
定義プロセスは，それぞれのシステム要素が，それを構築する又は購入するために，十分に規定されてい
るかを決定するために必要になる。システム要素がこの十分性の達成のために更に分析が必要ならば，そ
116
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
のシステム要素に関連付けられている機能についても，更なる分析，及び厳密な部分要素への対応付けが
必要となる。典型的には，複数のアーキテクチャの候補の定義に貢献するような機能の分解は，複数の方
法が存在する。
F.3.2
振る舞いモデル
システムの振る舞いモデル（Behavioral model）は，順次実行及び並行実行，振る舞いが変化する条件，
並びにシステムの遂行能力・性能・運用時の実績を含む運用シナリオを維持するための条件下で，システ
ム又はその要素がどのように振る舞うかを定義する，機能及びインタフェース（内部及び外部）の取決め
である。振る舞いモデルは，シナリオ間の関係の集合によって記述することができる。これは，ライフサ
イクルを通じた振る舞いの要素（モード又は状態，遷移，発動イベント，運用シナリオなど）を識別する
ことを含む。
F.3.3
時相モデル
システムの時相モデル（Temporal model）は，機能の実行頻度のレベル（戦略レベル，戦術レベル，運
用監視レベル，統制レベルなど）を示すシステム又はその要素において，時間が振る舞いの中でいかに考
慮に入れられているかを表す表現である。ここで，機能の実行レベルは，人及びプログラムの論理がシス
テムの運用を監視及び制御することを決定するレベルに対応する。これは，システムレベルの運用概念及
びシステム要求事項から，時相的要素（期間，頻度，応答時間，トリガー，タイムアウト，停止条件など）
を識別することを含む。
F.3.4
構造モデル
システムの構造モデル（Structural model）は，他の要素との関係についての要素の配置，並びに要素間
及び外部実体とのインタフェースを必要に応じて示す表現である。そのようなモデルは，システム階層の
あるレベルにおける，及びシステム階層のレベル間におけるシステム要素間の物理的インタフェースを明
確化又は識別することができる。外部実体から当該システム（その環境及び利用状況において）への物理
インタフェースについても同様である。
F.3.5
質点モデル
システムの質点モデル（Mass model）は，システム要素の物理体積，又はそれらが地理的に分散してい
る場合には，それらの部分の位置を示す表現である。システムの質点モデルは，重心及び運動の動的な振
る舞いなどの質点の性質の決定を支援するために，期待する質点の性質又は実際の性質を記録することが
できる。システムの質点モデルは，また，システムの総質量をその要素に割り当てることを支援するため
にも利用することができる。
F.3.6
レイアウトモデル
システムのレイアウトモデル（Layout model）は，システム要素が他のシステム要素に対して地理的に
どこに配置されているかを表現するものである。鉄道のモデルにおいては，レイアウトモデルは運行する
列車のための縮尺線路を含むジオラマである。自動車レイアウトは，エンジン及び駆動輪が車両上のどこ
にあるかを記述する。
F.3.7
ネットワークモデル
システムのネットワークモデル（Network model）は，資源が一つのノードから他のノードへどのように
移動するかを理解することを助けるための，ノード及びリンクの配置を定義する。ネットワークモデルは，
スループット，待ち時間，ふくそう（輻輳）点などを決定するために使用できる。ネットワークモデルは，
ネットワーク内の階層がいかに上位及び下位のスタックと垂直に相互作用するかを理解するために，しば
しばプロトコルスタックとともにモデル化される。
117
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
F.3.8
他のモデルの考慮すべき事柄
保守，発展，廃棄，潜在的な環境の変化，又は陳腐化管理，及び非機能要求事項といった利害関係者の
ライフサイクルに関する関心事は，モジュール性，相対的な独立性，アップグレード可能性，複数の環境
への適合，有効性のレベル，信頼性，堅ろう（牢）性（robustness），拡張可能性（scalability），環境条件に
対する抵抗などといったアーキテクチャ特性を定義することによって扱われる。
他の必要なモデルは，これらの特性又は他の重大な品質特性の幾つかを含み得る。例えば，信頼性モデ
ルは，重大な関心事及び機能に関連する運用上のリスク（ミッションの損失，安全性又はセキュリティ）
の最小化を目的とする潜在的なアーキテクチャによる緩和の導出を支援するため，故障モード及び影響解
析（FMEA又はFMECA）の機能レベルを決めることができる。
システム定義において，どのモデルを使うかを決定することは，利害関係者の関心事の検討に基づくこ
とができる。モデル及び得られたビューは，システムアーキテクチャ及び設計が，利害関係者らの関心事
を扱うかを表現するための方法，並びに利害関係者らの実際の必要性，欲求及び期待のより良い理解を得
るための方法として利用することができる。
さらに，モデルは，アーキテクチャ定義及び設計定義プロセス以外のライフサイクルプロセスにおいて
も利用できることがある。モデルに基づくシステムエンジニアリング（MBSE，Model-Based Systems
Engineering）は，ライフサイクルにおけるシステム要求事項，アーキテクチャ，設計，分析，検証，及び
妥当性確認に関する作業を支援するための，形式性を高めたモデル化の系統的な適用である。
118
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
附属書G
（参考）
システム オブ システムズへのシステムライフサイクルプロセス適用
G.1
はじめに
システム オブ システムズ（SoS，System of Systems）は，その要素それぞれがシステムである一つの対
象システムである。SoSは個々のシステムでは達成できないあるタスクのために一連のシステムをまとめ
ている。SoSを構成する，個々の構成システム（constituent system）は，SoS内で協調し，かつ，SoSの目
標に合致するために適応しながら，自身の管理，ゴール及び資源を保つ。5.2.3で説明しているように用語
を用いる状況（図3）では，元の対象システム，イネーブリングシステム及び相互作用するシステムを含
む，システム群の混成集合体（composite set of systems）が，共にSoSを構成する。システム群の混成集合
体に影響する関心事がある場合，SoSは対象システムとして検討される。そのようにするのは，独立した
構成システムでは充足できないビジネス若しくはミッションの目標をSoSで充足するため，又は個々の構
成システムを組み合わせたことで，個々の能力を超えた全体としての能力を発揮する，SoSの創発的な振
る舞い（emergent behavior）を理解するためである。
この附属書は，こうしたSoSに対するシステムライフサイクルプロセスの適用を扱っている。一般的な
特性，汎用的に用いることができるSoSの種類，及びライフサイクル全体にわたる関係を記述している。
G.2
SoSの特性及び種類
SoSは，多くの場合，開発された構成システムの管理及び運用の独立性によって特徴付けられ，最初に
特定されていた元からの利用者を，SoSの利用者と同時に支援し続ける。他の状況では，それぞれの構成
システムは，それ自体がSOI（対象システム，System of Interest）であり，SoSよりも前から存在している
ことも多く，その特性はそれらの初期の利用者のニーズに合致するように元から作られていた。SoSがも
つ，より大きなニーズを網羅するため，SoSの構成要素として，構成システムで検討する範囲が拡張され
る。このことは，特に，システムがSoSとは独立して発展し続ける場合には，複雑さが増すことを意味す
る。構成システムは，通常，元からの利害関係者及び統治機構も保持する。このことがSoSのニーズに取
り組むために，代替の構成システムを用いるという選択肢を制限することになる。
SoSは構成システムとSoSとの間の統治関係に基づいて，4種類の型に特徴付けて分類される（図G.1）。
“指揮管理された”SoSは，最も強い統治関係をもつ。これは，SoS組織が，SoSを支援するために構成
システムが元々設計されていない場合があっても，構成システム全体に権限をもつ。“認められた”SoSは，
与えられる統制が幾らか少なく，そこでは，構成システムとSoSとの間に割り当てられた権限が，幾つか
のシステムエンジニアリングプロセスの適用に影響を及ぼす。“協調的な”SoSは，SoS権限が欠けている。
これは，システムエンジニアリングの適用が構成システム間の協調に依存する。“仮想的な”SoSは，おお
むね自己組織的で，SoSのシステムエンジニアリングの機会が極めて限定的である。
創発性（emergence）はSoSの重要な特性であり，SoSでの予期しない影響は，構成システム群の複雑な
相互作用の動的変化に起因する。SoSでは，システム単体では得られない結果を得て分析するために，構
成システムを意図的に組み合わせて検討する。構成システムの複雑さ，及びSoSの中での構成システムの
役割を考慮せずに設計されている場合があるという事実が，新たな予期しない振る舞いを招き得る。予期
しない創発的な結果を識別し，対処することはSoSのエンジニアリングの中で特に課題となる。
119
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
SoSの種類
（System of System Types）
説明
仮想的な（Virtual）
− 管理権限の中心がない。
− 集約して合意された目的がない。
− 他の種類のSoSに比べて見えにくい，SoSを維持するためのメカニ
ズムによって，創発的に振る舞う。
協調的な（Collaborative）
− 合意された目的を満たすためにコンポーネントシステムが自発的に
相互作用する。
− 標準を相互運用し，実施し，そして維持する方法を共同で決定する。
認められた（Acknowledged）
− SoSに対する目標，指定された管理者，及び資源が認識されている。
− 構成システムは独立した所有，管理及び資源を保持する。
指揮管理された（Directed）
− 特定の目的を満たすために構築され管理される統合されたSoS。
− 中央から管理し発展させる。
− コンポーネントシステムは独立して運用する能力を維持する。
− 通常の運用モードが中央の目的に従属している。
注記 この種類のSoSでは，SoSを指揮する何らかの中央がある。
図G.1−SoSの種類
G.3
SoSへ適用されるシステムエンジニアリングプロセス
G.3.1 概要
前述したSoSの特性は，システムライフサイクルプロセスの次に示す4種類のSoSの適用に関係する。
G.3.2 合意プロセス
合意プロセスは，SoS及び独立していることが多い構成システムに対して責任をもつ組織間で，開発及
び運用統制のモードを確立するため，SoSには重要である。異なる組織によって取得され管理される構成
システムは，SoSの目標とは合わない元来の目標を保持していることがよくある。“指揮管理された”SoS
の場合を除いて，SoSの組織は，それらの協力なしに構成システム組織に仕事を課すことはできない。“認
められた”SoS又は“協調的な”SoSでは，これらのタスクは，それ自体のSOIとしての構成システムの
タスクに対してバランスがとれている。“仮想的な”SoSの場合，合意プロセスは非公式なものか，又は分
析の目的でだけ検討されることがある。
G.3.3 組織のプロジェクトイネーブリングプロセス
典型的な対象システムでは，組織のプロジェクトイネーブリングプロセスは，プロジェクトが実施され
る環境を確立する。組織は，プロジェクトによって用いられるプロセス及びライフサイクルモデルを確立
し，プロジェクトを設立し，方向性を変更，又は中止し，人的及び財政的資源を含めた要求される資源を
提供し，並びに組織内及び組織外の顧客向けにプロジェクトによって開発されたシステム及びその他の成
果物の品質基準を設定し，監視する（6.2）。
SoSでは，構成システムの所有者は通常，構成システムのエンジニアリングに関する責任を保持し，そ
れぞれ独自の組織プロジェクトを有効にするプロセスをもつ。SoSの種類に依存して，SoSは，SoSの特
定の検討のためにこれらの組織のプロジェクトイネーブリングプロセスを適用し，既存のシステム及び新
しいシステムを混合した能力を計画し，分析し，編成し，そしてSoS能力へ統合する。
その結果，SoSでは，これらの組織のプロジェクトイネーブリングプロセスは，二つのレベルで実装さ
れる。構成システムに責任をもつ組織は，SoSの独立したSOIに対してこれらのプロセスを実装する。SoS
の組織（又はSoSの合意による“協調的な”SoS）は，SoS全体に適用するそれらの検討に対してSoSの
120
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
ためのこれらのプロセスを実装する。例えば，人的資源管理プロセスは，構成システムをエンジニアリン
グ活動によって作成するために，各構成システムの組織によって取り組まれる。SoSの組織は，構成シス
テム全体をSoSへ適用するシステムエンジニアリング活動だけのための人的資源管理プロセスに取り組む
こともあり得る。
SoSエンジニアリングに特有の課題は，構成システムの組織のプロジェクトイネーブリングプロセス，
及びSoSのそれらのプロセスとの連携の欠如にある。構成システムのプロセスは，独自の成果を達成する
ために設計されていて，SoSのプロセスと合わない場合がある。例えば，ポートフォリオ管理プロセスは，
次の場合，構成システムの責任となる。それは，構成システムの組織が，構成システム及び他のシステム，
並びにポートフォリオ内のプロジェクトを全て統制することができ，かつ，SoSの組織がこのことを認識
するポートフォリオ管理への取組方法を必要とする場合である。
G.3.4 テクニカルマネジメントプロセス
典型的な対象システムにおいて，テクニカルマネジメントプロセスは，次に関係する。
− 組織の管理によって割り当てられた資源及び資産を管理すること
− 一つ以上の組織の間の合意を履行するために，資源及び資産を充当すること
テクニカルマネジメントプロセスは，プロジェクトの管理について，特に，次に関係する。
− コスト，期間の長さ及び達成に関して計画すること
− 計画及び達成度を示す実績基準を遵守するために活動をチェックすること
− 進捗及び達成における未達成の部分を取り戻す是正処置の識別及び選択すること
テクニカルマネジメントプロセスは，プロジェクトの技術計画の立案及び実施，技術チーム全体の情報
管理，システム製品又はサービスの計画に対する技術面の進捗のアセスメント，完了までの技術的タスク
の制御，並びに意思決定プロセスの支援に使用される（6.3）。
テクニカルマネジメントプロセスを，SoSのレベル及びその構成システムのレベルでも実施する。
既存及び新規システム群を混成させたものがもつ能力を計画し，分析し，編成し，SoS能力へ統合する
ことを行うSoSエンジニアリングについて，その特定の考慮事項に対し，テクニカルマネジメントプロセ
スを適用する。それと並行して，構成システムの組織は，それらの構成システムのエンジニアリング，及
び自身のテクニカルマネジメントプロセスの責任をもち続ける。
SoS組織は，SoS全体にわたって適用するテクニカルマネジメントプロセスに取り組む。それと並行し
て，そのプロセスは構成システムの組織でも独立して実施される。例えば，構成管理では，構成システム
は自身の構成を管理すると同時に，SoSはSoS内のシステムの組合せに適用される構成管理に取り組む。
SoSでのリスク管理がSoSへのリスクを見ている間に，構成システムの成果に適用されるリスクのアセス
メントに基づいて，リスクは構成システムによって管理される。
プロジェクト計画プロセス，並びにプロジェクトアセスメント及び制御プロセスは，全てのマネジメン
トプラクティスにとって重要である（6.3）。システム オブ システムズ エンジニアリングにおける重要な
課題は，構成システムのためのプロセスについてSoS組織による制御が欠如していることである。独自の
組織要求事項によって，構成システムのそれぞれは，他の構成システムのスケジュールとは異なるスケジ
ュール又はアップグレードスケジュールで開発される場合がある。
SoS組織は，SoSをSOIとして扱うライフサイクルにおいて，SoSによって開始された変更に加えて，
構成システムの独立した変更を認識する統合ライフサイクルを計画をすることが求められる。
構成システム間で追加される，能力の段階的な増加分によって，SoSは発展するが，そうしたSoSの発
展を段階に区切る，安定した中間形態を定義しておくことを，統合ライフサイクルに含めることが多い。
121
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
G.3.5 テクニカルプロセス
テクニカルプロセスは，ライフサイクルを通じた技術的な作業に関係する。それらは，はじめに利害関
係者のニーズを製品に変換し，そして，顧客満足度を達成するために必要なタイミング及び場所で，その
製品を適用することで，持続的なサービスを提供する。テクニカルプロセスは，システムがモデルの形態
であるか完成品であるかにかかわらず，システムを作成し使用するために適用され，システム構造の階層
内の任意のレベルで適用される（6.4）。
SoSに適用される他のプロセスと同様に，テクニカルプロセスはSoS及び構成システムの両方で実施す
る。SoSの実装は，SoS全体ではなく，構成システムのプロセス実行によって行われる場合もある。
SoSのためのビジネス又はミッションの分析は，SoSビジネス及びミッションを取り巻く環境の全体を
調査する。その空間内で運用するように構成システムを開発したその程度まで，SoS及び構成システムに
対するビジネス又はミッション分析は広く共有される。目的は，要望される能力を提供するための最良の
手段を決定することである。
利害関係者ニーズ及び利害関係者要求事項定義は，トップレベルのSoSに焦点を当てるだけでなく，個々
のシステムの利害関係者の様々なニーズがSoSにどのように制約をもたらすかを検討するようになる。SoS
のためのシステム要求事項定義は，利害関係者のニーズ及びミッション目標を満たすために必要なレベル
で定義するようになる。そして，SoSが，構成システムのための新しい要求に対する“利害関係者”とし
ての役割をもつことで，定義したSoSのシステム要求事項が，SoSの構成システムの要求事項に変換され
るようにする。
SoSのアーキテクチャは，既存のシステム及び新しいシステムを組み合わせた能力を編成してSoS能力
に統合するための枠組みであり，構成システムのアーキテクチーはそれぞれの組織に委ねられている。SoS
の構成システムは，通常SoSに先立つため，SoSアーキテクチャ定義はしばしばSoSの現存アーキテクチ
ャから始まる。利害関係者の関心事を捉え，最上位のSoS要求事項を満たし，構成システムに対する新し
い要求事項の影響を認識し，かつ，構成システムのアーキテクチャの制約を受け入れるために，アーキテ
クチャの代替案を検討することがよくある。
設計定義プロセスは，SoSの実装を可能にするのに十分な詳細なデータ及び情報を提供する。これには，
システムに適用されるSoS要求事項に取り組む方法を識別するために，独自の設計トレードオフを行う構
成システムと協調して設計することを伴う。これらの設計定義は，構成システム組織の責任であり，監視
する役割を果たすSoS組織とともに，構成システムによって実施される。
インテグレーション，検証，移行及び検証の全てが，SoSの要求事項を支援するために構成システムが
実装する変更に対して実施される。これらのプロセスは，アップグレードされた構成システムがSoSに統
合され，かつ，そのSoSの遂行能力・性能・運用時の実績が検証及び妥当性確認されるときに，SoSに対
しても適用される。従来のSOIで実装されているのと同様に，これらのプロセスを効果的に実施するには，
SoSにおける構成システムの独立性及び非同期的な性質は障壁となる。SoSレベルの評価は，運用環境で
しか実行できない場合がある。この場合，SoSの振る舞いが悪化することを避けるために予防処置を考慮
する必要がある。
運用，保守及び廃棄プロセスは，管理及び運用操作の独立性が認められている構成システムによって実
施される傾向がある。これらのプロセスを促進するため，SoSレベルの相互作用があることがある。
122
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
参考文献
[1] JIS Q 9000:2015 品質マネジメントシステム−基本及び用語
注記 対応国際規格：ISO 9000:2015，Quality management systems−Fundamentals and vocabulary
[2] JIS Q 9001:2015 品質マネジメントシステム−要求事項
注記 対応国際規格：ISO 9001:2015，Quality management systems−Requirements
[3] JIS Q 9004:2010 組織の持続的成功のための運営管理−品質マネジメントアプローチ
注記1 対応国際規格：ISO 9004:2009，Managing for the sustained success of an organization−A quality
management approach
注記2 この規格に対応させたJIS Q 9004:2018（ISO 9004:2018）が改正版として発行されている。
[4] JIS Z 8530:2019 人間工学−インタラクティブシステムの人間中心設計
注記 対応国際規格：ISO 9241-210:2010，Ergonomics of human-system interaction−Part 210:
Human-centred design for interactive systems
[5] ISO 10004:2012，Quality management−Customer satisfaction−Guidelines for monitoring and measuring
[6] ISO 10007:2003，Quality management systems−Guidelines for configuration management
[7] ISO/IEC 10746-3:2009，Information technology−Open distributed processing−Reference model:
Architecture
[8] JIS Q 14001:2015 環境マネジメントシステム−要求事項及び利用の手引
注記 対応国際規格：ISO 14001:2015，Environmental management systems−Requirements with guidance
for use
[9] ISO/IEC 15026-3:2011，Systems and software engineering−Systems and software assurance−Part 3: System
integrity levels
[10] ISO/IEC 15026-4，Systems and software engineering−Systems and software assurance−Part 4: Assurance in
the life cycle
[11] JIS X 0171:2014 システム及びソフトウェア技術−ライフサイクルにおいて生成する情報の内容（ド
キュメンテーション）
注記1 対応国際規格：ISO/IEC/IEEE 15289:2011，Systems and software engineering−Content of life
cycle information products (documentation)
注記2 この規格に対応させたISO/IEC/IEEE 15289:2017が改正版として発行されている。
[12] JIS X 0145規格群及びJIS X 33000規格類 情報技術−プロセスアセスメント
注記1 対応国際規格：ISO/IEC 15504，ISO/IEC 33000, (multiple parts)，Information technology−
Process assessment
注記2 これらISO/IEC 15504規格群はISO/IEC 33000規格類へ改正され，対応するJIS X 0145規
格群はJIS X 33000規格類として改正が進んでいる。
[13] ISO 15704:2000，Industrial automation systems−Requirements for enterprise-reference architectures and
methodologies
[14] JIS X 0141:2009 システム及びソフトウェア技術−測定プロセス
注記1 対応国際規格：ISO/IEC 15939:2007，Systems and software engineering−Measurement process
注記2 この規格に対応させたISO/IEC/IEEE 15939:2017が改正版として発行されている。
123
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
[15] JIS X 0162:2008 システム及びソフトウェア技術−ライフサイクルプロセス−リスク管理
注記 対応国際規格：ISO/IEC 16085:2006，Systems and software engineering−Life cycle processes−
Risk management
[16] ISO/IEC 16326:2009，Systems and software engineering−Life cycle processes−Project management
[17] ISO/TS 18152:2010，Ergonomics of human-system interaction−Specification for the process assessment of
human-system issues
[18] ISO/TR 18529:2000，Ergonomics−Ergonomics of human-system interaction−Human-centred lifecycle
process descriptions
[19] JIS Q 20000-1:2012 情報技術−サービスマネジメント−第1部：サービスマネジメントシステム要求
事項
注記 対応国際規格：ISO/IEC 20000-1:2011，Information technology−Service management−Part 1:
Service management system requirements（IEEE Std 20000-1:2013）
[20] ISO/IEC TR 24748-1:2010，Systems and software engineering−Life cycle management−Part 1: Guide for
life cycle management（IEEE Std 24748-1-2011，IEEE Guide−Adoption of ISO/IEC TR 24748-1:2010
Systems and Software Engineering−Life Cycle Management−Part 1: Guide for Life Cycle Management）
注記1 http://www.iso.org/から無償利用可能。
注記2 この規格に対応させたISO/IEC/IEEE 24748-1:2018として改正版が発行されている。
[21] ISO/IEC TR 24748-2:2011，Systems and software engineering−Life cycle management−Part 2: Guide to the
application of ISO/IEC 15288 (System life cycle processes)［IEEE Std 24748-2-2012，IEEE Guide−Adoption
of ISO/IEC TR 24748-2:2011 Systems and Software Engineering−Life Cycle Management−Part 2: Guide to
the Application of ISO/IEC 15288 (System Life Cycle Processes)］
注記 この規格に対応させたISO/IEC/IEEE 24748-2:2018として改正版が発行されている。
[22] ISO/IEC/IEEE 24748-4:2016，Systems and software engineering−Life cycle management−Part 4: Systems
engineering planning
[23] ISO/IEC/IEEE 24765:2010，Systems and software engineering−Vocabulary
[24] ISO/IEC TR 24774:2010，Systems and software engineering−Life cycle management−Guidelines for process
description
注記 http://www.iso.org/から無償利用可能。
[25] JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソ
フトウェア品質モデル
注記 対応国際規格：ISO/IEC 25010:2011，Systems and software engineering−Systems and software
Quality Requirements and Evaluation (SQuaRE)−System and software quality models
[26] JIS X 25030:2012 ソフトウェア製品の品質要求及び評価（SQuaRE）−品質要求事項
注記 対応国際規格：ISO/IEC 25030:2007，Software engineering−Software product Quality
Requirements and Evaluation (SQuaRE)−Quality requirements
[27] ISO/IEC TR 25060:2010，Systems and software engineering−Systems and software product Quality
Requirements and Evaluation (SQuaRE)−Common Industry Format (CIF) for usability: General framework
for usability-related information
[28] ISO/IEC 25063:2014，Systems and software engineering−Systems and software product Quality
Requirements and Evaluation (SQuaRE)−Common Industry Format (CIF) for usability: Context of use
124
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
description
[29] JIS X 0154:2018 システム及びソフトウェア技術−製品ライフサイクル，利用者及びサービスマネジ
メントの文書化のためのコンテンツ管理
注記 対応国際規格：ISO/IEC/IEEE 26531:2015，Systems and software engineering−Content
management for product life-cycle, user and service management documentation
[30] ISO/IEC 27036 (multiple parts)，Information technology−Security techniques−Information security for
supplier relationships
注記 この規格中ではISO/IEC 27000，Information technology−Security techniques−Information
security management systemsのファミリ規格も参照しているが，JIS Q 27000（情報技術−セキ
ュリティ技術−情報セキュリティマネジメントシステム）のファミリ規格としてJIS Q 27000，
JIS Q 27001及びJIS Q 27002が参照できる。
[31] JIS X 0166:2014 システム及びソフトウェア技術−ライフサイクルプロセス−要求エンジニアリング
注記1 対応国際規格：ISO/IEC/IEEE 29148:2011，Systems and software engineering−Life cycle
processes−Requirements engineering
注記2 この規格に対応させたISO/IEC/IEEE 29148:2018として改正版が発行されている。
[32] JIS Q 31000:2010 リスクマネジメント−原則及び指針
注記1 対応国際規格：ISO 31000:2009，Risk management−Principles and guidelines
注記2 この規格に対応させたJIS Q 31000:2019（ISO 31000:2018）が改正版として発行されている。
[33] JIS X 33002:2017 情報技術−プロセスアセスメント−プロセスアセスメント実施に対する要求事項
注記 対応国際規格：ISO 33002:2015，Information technology−Process assessment−Requirements for
performing process assessment
[34] ISO/IEC/IEEE 42010:2011，Systems and software engineering−Architecture description
[35] JIS C 0508（規格群） 電気・電子・プログラマブル電子安全関連系の機能安全
注記 対応国際規格：IEC 61508 (multiple parts)，Functional safety of electrical/electronic/ programmable
electronic safety-related systems
[36] JIS Q 0073:2010リスクマネジメント−用語
注記 対応国際規格：ISO Guide 73:2009，Risk management−Vocabulary
[37] ANSI/AIAA G-043A-2012e，ANSI/AIAA Guide to the Preparation of Operational Concept Documents
[38] ANSI EIA-649-B-2011，Configuration Management Standard
[39] IEEE Std 828-2012，IEEE Standard for Configuration Management in Systems and Software Engineering
[40] INCOSE-TP-2003-002-03.2.2，Systems Engineering Handbook, A Guide for System Life Cycle Processes and
Activities, October 2011
[41] INCOSE-TP-2003-020-01，Technical Measurement, Version 1.0, 27 December 2005
[42] NATO AEP-67，Engineering for System Assurance in NATO Programs
[43] SAE ARP4754A:2010，Guidelines for Development of Civil Aircraft and Systems
[44] SAE JA1011:2009，Evaluation Criteria for Reliability-Centered Maintenance (RCM) Processes
（このJISに追加する参考文献）
JIS Z 8511 人間工学−視覚表示装置を用いるオフィス作業−通則
JIS Z 8520 人間工学−人とシステムとのインタラクション−対話の原則
125
X 0170：2020 (ISO/IEC/IEEE 15288：2015)
ISO/IEC/IEEE 12207，Systems and software engineering−Software life cycle processes
ISO/IEC 26550，Software and systems engineering−Reference model for product line engineering and
management