JISC62853:2020 ディペンダビリティ　マネジメント－マネジメント及び適用の手引－オープンシステムディペンダビリティ（開放系総合信頼性）

C 62853：2020 (IEC 62853：2018)

（1）

ページ

序文 ··································································································································· 1

1 適用範囲························································································································· 2

2 引用規格························································································································· 2

3 用語及び定義··················································································································· 3

4 オープンシステムディペンダビリティ ·················································································· 7

4.1 オープンシステム ·········································································································· 7

4.2 オープンシステム特有のディペンダビリティ課題 ································································ 8

4.3 目標 ···························································································································· 9

4.4 オープンシステムディペンダビリティの達成 ······································································ 9

4.5 適応力及びフォールトトレランスとの関係 ········································································ 10

5 適合性··························································································································· 10

6 オープンシステムディペンダビリティを達成するためのプロセスビュー ···································· 11

6.1 概要 ··························································································································· 11

6.2 合意形成プロセスビュー ································································································ 12

6.3 説明責任遂行プロセスビュー ·························································································· 18

6.4 障害対応プロセスビュー ································································································ 29

6.5 変化対応プロセスビュー ································································································ 39

附属書A（参考）オープンシステムディペンダビリティをもつライフサイクルモデルの例 ················ 52

附属書B（参考）ディペンダビリティケースのテンプレート例 ···················································· 56

附属書C（参考）スマートグリッド ························································································ 66

参考文献 ···························································································································· 74

日本産業規格 JIS

C 62853：2020

(IEC 62853：2018)

ディペンダビリティマネジメント−

マネジメント及び適用の手引−オープンシステム

ディペンダビリティ（開放系総合信頼性）

Dependability management-Guidance for management and application-

Open systems dependability

序文

この規格は，2018年に第1版として発行されたIEC 62853を基に，技術的内容及び構成を変更すること

なく作成した日本産業規格である。

なお，この規格で点線の下線を施してある参考事項は，対応国際規格にはない事項である。

オープンシステムとは，その境界，機能及び構造が時間とともに変化し，様々な視点に応じて異なった

認識及び記述のされ方をするシステムである。オープンシステムのディペンダビリティは，実環境で長期
的に運用されるシステムのライフサイクルに関して鍵となる属性である。オープンシステムディペンダビ

リティとは，期待されるサービスを要求されたときに要求されたように提供できるよう，目的，目標，環
境及び実際のパフォーマンスの変化に対応し，利害関係者の説明責任を継続的に維持する，というオープ

ンシステムの能力である。アベイラビリティ，信頼性，保守性及び支援性を含め，ディペンダビリティ属
性の概念自体は，オープンシステムについても従来のシステムと変わらない。しかし，オープンシステム

では，単独でシステム又はそのリスクを完全に理解する利害関係者はいない，という文脈でこれらの属性
を考える。

オープンシステムは，常にマルウェアによる攻撃にさらされているため，セキュリティは特に重要であ

る。また，オープンシステムは，その生涯を通じて継続的に変化するので，その設計プロセス（例えば，
製品開発のスパイラルモデルでモデル化されるもの）は，システムの全存続期間を通じて一定程度の活動
を継続する。

この規格は，IEC 60300-1の示すディペンダビリティマネジメントをオープンシステムに関して詳細化

するものであり，オープンシステムのディペンダビリティマネジメントのための追加的手引を提供する。

この規格は，四つのプロセスビューを用いてオープンシステムディペンダビリティの手引を提供する。

各プロセスビューは，システムのライフサイクルを記述するためのものとしてJIS X 0170:2020で規定さ

れているプロセス，アクティビティ及びタスクから連関するものを選択し，組み合わせている。

− 変化対応プロセスビュー

− 説明責任遂行プロセスビュー

− 障害対応プロセスビュー

− 合意形成プロセスビュー

C 62853：2020 (IEC 62853：2018)

これらのプロセスビューのアシュアランスを与えるディペンダビリティケースは，利害関係者がオープ

ンシステムディペンダビリティを達成するに当たって，次の点で極めて重要になる。

− 各々の責任の境界について理解し合意すること

− 実施に関する説明責任を割り当てること

− 変化を善良に管理すること

この規格の対象読者は，システムの利用者，所有者及び顧客から，オープンシステムディペンダビリテ

ィ要求事項充足のアシュアランスに関与し責任をもつ組織までと幅広い。組織には，全ての種類及び全て
の規模の公共・民間の団体（法人，政府機関，企業，非営利団体など）が含まれる。

適用範囲

この規格は，オープンシステムがオープンシステムディペンダビリティを達成するように，システムラ

イフサイクル（以下，“ライフサイクル”という。）に対して課される要求事項に関する手引について規定
する。

この規格は，IEC 60300-1の適用に際してオープンシステムの特徴に対処するために必要となる変更点

を詳述することでIEC 60300-1を詳細化している。詳細は，ライフサイクルのプロセスを定めるJIS X

0170:2020に基づくプロセスビューとして定められる。

この規格は，製品，システム，プロセス又はサービスのライフサイクルに適用可能である。製品などに

関わる要素には，ハードウェア，ソフトウェア，人的側面又はそれらの組合せが考えられる。

オープンシステムは，殊更攻撃にさらされるものであるため，オープンシステムにとってセキュリティ

は特に重要である。

この規格は，オープンシステムのディペンダビリティを向上させるために利用することが可能である。

期待される成果がオープンシステムに特化したプロセスビューによって達成されることのアシュアランス
を提供するためにも利用することが可能である。組織が，オープンシステムにおけるディペンダビリティ

目標を達成するために必要となるアクティビティ及びタスクを定義する際の助けともなる。アクティビテ
ィ及びタスクには，ディペンダビリティに関するコミュニケーション，ディペンダビリティのアセスメン
ト及びライフサイクルを通してのディペンダビリティの評価が含まれる。

注記この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。

IEC 62853:2018，Open systems dependability（IDT）

なお，対応の程度を表す記号“IDT”は，ISO/IEC Guide 21-1に基づき，“一致している”こと

を示す。

引用規格

次に掲げる引用規格は，この規格に引用されることによって，その一部又は全部がこの規格の要求事項

を構成している。これらの引用規格のうち，西暦年を付記してあるものは，記載の年の版を適用し，その

後の改正版（追補を含む。）は適用しない。西暦年の付記がない引用規格は，その最新版（追補を含む。）
を適用する。

JIS X 0170:2020 システムライフサイクルプロセス

注記対応国際規格における引用規格：ISO/IEC/IEEE 15288:2015，Systems and software engineering

C 62853：2020 (IEC 62853：2018)

−System life cycle processes

JIS Z 8115 ディペンダビリティ（総合信頼性）用語

注記対応国際規格における引用規格：IEC 60050-192，International Electrotechnical Vocabulary−

Part 192: Dependability

IEC 60300-1，Dependability management−Part 1: Guidance for management and application

用語及び定義

この規格で用いる主な用語及び定義は，次によるほか，JIS Z 8115による。

なお，IEC及びISOは，標準化に使用するための用語データベースを次のアドレスに維持している。

− IEC Electropedia：http://www.electropedia.org/

− ISO Online browsing platform：https://www.iso.org/obp

3.1

説明責任（accountability）

決定及び活動に関して，組織の統治機関，規制当局及びより広義にはその利害関係者に対して，責任の

ある対応をとれる状態

注釈1 説明責任には，一般に社会に対して責任のある対応をとれることが含まれる。

注釈2 ISO 26000:2010[1]の記載：説明責任によって，経営層はその組織の支配権をもつ人々に対して

説明する義務を負い，また，その組織は法規制に関し，規制当局に対して説明する義務を負う。

また，組織の決定及び活動が社会及び環境に与える全体的な影響の説明責任とは，組織が自ら
の決定及び活動によって影響を受ける人々及び一般に社会に対して，報告を行う義務が，その
影響及び状況の性質によって変わることを意味している。

注釈3 ISO 15489-1:2001[2]の定義：個人，組織及び集団はその行動に対する責任をもち，その行動を他

の人々に説明することを要求され得るという原則

（出典：ISO 26000:2010の2.1を一部変更し，注釈1，注釈2及び注釈3を追加）

3.2
アシュアランスケース（assurance case）

最上位の主張（又は主張の集まり）は成り立つ，という論旨を支えるためにつくられた，理由付けら

れ，監査可能な成果物であって，主張を支える系統的な議論並びに議論の根拠となる証拠及び明示的な仮
定を含むもの

注釈1 アシュアランスケースは，次のものとそれらとの間の関連付けを含む。

− 性質についての一つ以上の主張

− 証拠及び仮定から論理的に主張を導く議論

− 主張を支持する議論の根拠となる一式の証拠，及び場合によっては，仮定

− 最上位の主張の選択及び推論の方法の選択を正当とする事由

注釈2 アシュアランスケースは，“システム，サービス又は組織は明確に定義された用途，環境及び期

間において，意図どおりに働く”ということを論旨とする，理由付けられ，説得力があり，一
式の証拠で支えられた議論として理解することが可能である。

（出典：ISO/IEC 15026-1:2013[3]の3.1.3を一部変更し，注釈2を追加）

C 62853：2020 (IEC 62853：2018)

3.3
変化対応（change accommodation）

目的，目標，環境又は実際のパフォーマンスの変化のうち，利害関係者合意の再確立が必要になるよう

な変化に対して，システムを変化及び適応させる活動の集まり

3.4

合意（consensus）

本質的な問題について，重要な利害関係者の中に妥協できない反対意見がなく，かつ，全ての関係者の

見解を考慮することに努める過程及び対立した議論を調和させることに努める過程を経た上での全体的な
一致

注釈1 合意は，必ずしも全員の一致を必要としない。
（出典：ISO/IEC Guide 2:2004[4]の1.7）

3.5
ディペンダビリティケース（dependability case）

定義されたシステムがディペンダビリティ要求事項を満たしている及び／又は今後満たすという論旨を

支えるために作成された，証拠に基づく，理由付けられた，追跡可能な議論

注釈1 ディペンダビリティケースは，最上位の主張がディペンダビリティに関するアシュアランスケ

ースである。

（出典：IEC 62741:2015の3.1.1を一部変更し，注釈1を追加）

3.6
ディペンダビリティコミュニケーション（dependability communication）

ディペンダビリティのマネジメントについて，情報の提供，共有又は取得，及び他の利害関係者との対

話を行うために，利害関係者が継続的に及び繰り返し行うプロセス

注釈1 オープンシステムディペンダビリティのマネジメントにおけるディペンダビリティコミュニケ

ーションの役割は，リスクマネジメントにおけるリスクコミュニケーションと異ならない。

注釈2 ISO Guide 73:2009[5]の3.2.1にある用語“コミュニケーション及び協議”の定義を参照。

3.7
環境（environment）

＜システム＞システムに及ぼされる全ての影響について，その設定及び状況を特定する文脈
（出典：ISO/IEC/IEEE 42010:2011[6]の3.8）

3.8
障害対応（failure response）

障害が予測又は検出されたとき，障害を予防するため，障害の影響を最小化するため，原因を解析して

再発を防ぐため，及び説明責任を果たすために，直ちに開始される活動の集まり

3.9
準拠枠（frame of reference）

システム，その目的，目標，環境，実際のパフォーマンス，ライフサイクル並びにそれらの変化に関す

る共通理解及び明示的合意を記述した文書の構築，解釈及び利用のための規約の集まり

3.10
相互作用エラー（interaction error）

C 62853：2020 (IEC 62853：2018)

各アイテムのパフォーマンスが仕様に合致するにもかかわらず，アイテム間の相互作用が理由で起こる

エラー

3.11

監視（monitoring）

システム，プロセス又は活動の状況を明確にすること

注釈1 状態を明確にするために，点検，監督又は注意深い観察が必要な場合もある。
（出典：ISO 22301:2012[7]の3.29）

3.12
オープンシステム，開放系（open system）

その境界，機能及び構造が時間とともに変化し，様々な視点に応じて異なった認識及び記述のされ方を

するシステム

注釈1 システムの変化には，特定の目的をもった適応だけでなく，自然発生的な進化も含まれる。例

えば，管轄の異なる複数の領域にまたが（跨）るシステムの内部における，自然発生的かつ非
協調的なものが含まれる。

注釈2 オープンシステムの境界，機能及び構造は時間とともに変化するだけでなく，どの時点におい

ても曖昧で，異なる利害関係者によって異なって認識され得る。オープンシステムの定義は，
所与の抽象レベル及び視点に対するJIS Z 8115におけるシステムの定義を精緻化するものであ

る。ある抽象レベルでは明確に定義可能な境界も，より詳細なレベルではより曖昧になり得る。
ある目的に対して，又はある利害関係者にとって，どのレベルの詳細さが必要となるかは，あ

らかじめ定めることが可能であるとは限らず，そのレベルの詳細さを得られるという保証もな
い。

注釈3 オープンシステムは，他のシステム又は環境と境界とをまたが（跨）ってリソースを交換する。

場合によっては境界自体を変化させる。

注釈4 相当規模のシステムであれば，必ずオープンシステムとしての側面及び従来型システムとして

の側面の両側面をもつ。オープンシステムという用語はシステムの分類には用いられない。こ

の用語がシステムに適用されるのは，そのシステムのオープンな側面がシステムの課題検討に
おいて重要な意味をもつときである。

注釈5 ソフトウェアシステムは，“オープンソース”であり得るが，それはそのシステムがオープンシ

ステムであるかどうかとは関係がない。ただし，オープンソースソフトウェアであることは，
権限の一元化に欠けるなどのオープンシステム的側面を必然的にもたらす。

3.13
オープンシステムディペンダビリティ，開放系総合信頼性（open systems dependability）

期待されるサービスを要求されたときに要求されたように提供するために，目的，目標，環境及び実際

のパフォーマンスの変化に対応し，説明責任を継続的に果たす能力

注釈1 パフォーマンス（performance）の意味には，実施，実績，性能，能力及び動作様態が含まれる。

3.14

プロセス（process）

インプットを使用して意図した結果を生み出す，相互に関連する又は相互に作用する一連の活動

注釈1 プロセスの“意図した結果”を，アウトプット，製品又はサービスのいずれと呼ぶかは，それ

が用いられている文脈による。

C 62853：2020 (IEC 62853：2018)

注釈2 プロセスへのインプットは，通常，他のプロセスからのアウトプットであり，また，プロセス

からのアウトプットは，通常，他のプロセスへのインプットである。

注釈3 連続した二つ以上の相互に関連する及び相互に作用するプロセスを，一つのプロセスと呼ぶこ

ともあり得る。

注釈4 組織内のプロセスは，価値を付加するために，通常，管理された条件の下で計画され，実行さ

れる。

注釈5 結果として得られるアウトプットの適合が，容易に又は経済的に確認できないプロセスを，“特

殊工程（special process）”と呼ぶことが多い。

注釈6 この用語及び定義は，ISO/IEC専門業務用指針−第1部：統合版ISO補足指針の附属書SLに

示されたISOマネジメントシステム規格の共通用語及び中核となる定義の一つをなす。ただし，

プロセスの定義とアウトプットの定義との間の循環を防ぐため，元の定義を修正した。また，
元の定義にない注釈1〜注釈5を追加した。

（出典：ISO 9000:2015[8]の3.4.1）

3.15
プロセスビュー（process view）

プロセス，アクティビティ及びタスクの集まりであって，システムに関する利害関係者の特定の関心事

に，ライフサイクルの全部又は一部にわたって横断的に焦点を当てるもの

3.16
適応力（resilience）

複雑かつ変化する環境下で適応できる能力

注釈1 参考文献[9]における適応力の定義：ハザードにさら（曝）されたシステム，コミュニティ又は

社会が，基本的な機構及び機能を保持・回復することなどを通じて，ハザードからの悪影響に
対し，適切なタイミングで，効果的な方法で抵抗し，それを吸収・受容し，また，そこから復
興する能力。

注釈2 参考文献[10]における適応力の定義：正当な理由をもって信頼し得るサービス提供の，変化に

直面した際の持続性

（出典：ISO Guide 73:2009の3.8.1.7を一部変更し，組織以外のアイテム一般にも適用可能な定義と

し，注釈1及び注釈2を追加）

3.17
利害関係者（stakeholder）

システムに，権利，持分，請求権若しくは関心をもっている個人若しくは組織，又はニーズ及び期待に

合致する特性をシステムがもつことに，権利，持分，請求権若しくは関心をもっている個人若しくは組織

例最終利用者，最終利用者の組織，支援者，開発者，製作者，教育訓練者，保守者，廃棄者，取得者，

供給者の組織及び規制団体。

注釈1 利害関係者は，互いに相反する利害，又はシステムと対立する利害をもつ可能性がある。

注釈2 用語“interested party”（利害関係者）は，ISO/IEC 専門業務用指針−第1部：統合版ISO補足

指針の附属書SLに示された，ISOマネジメントシステム規格向け共通用語及び中核的定義の
一つである。その定義は，この規格の定義とは異なる。附属書SLでは，“interested party”を推

奨用語とし，同義の許容用語として“stakeholder”（ステークホルダ）を併記している。この規
格では，JIS X 0170:2020に従い，許容用語“stakeholder”に“利害関係者”の語を当ててJIS X

0170:2020での定義を用いる。

C 62853：2020 (IEC 62853：2018)

（出典：JIS X 0170:2020の4.1.44を一部修正し，注釈2を追加）

オープンシステムディペンダビリティ

4.1

オープンシステム

オープンシステムは，次の特性をもつ[11]。

− 大規模・複雑であり，相互に接続されている。

− ブラックボックスコンポーネントを含み得る。

注記1 ブラックボックスコンポーネントは，その利用者が実装の詳細を知らず，機能及びインタ

フェースを自由に管理できないコンポーネントである。

− 目的，目標，環境及び実際のパフォーマンスが不確定的であり，生涯を通して変化する。利用者要求，

サービス目標，ネットワーク経由で用いるサービス，ブラックボックスコンポーネント，技術基盤な
どにも，予測不可能な変化がしばしば起きる。

− 境界，機能及び構造が常に進化し，異なった利害関係者から異なった認識をもたれる。それらが曖昧

にならないようにするには，特別な努力を要する。

− 説明責任がシステムのライフサイクル及びリスク管理において極めて重要になる一方，有効な一元管

理ができないため，説明責任のために特別な努力を要する。

− システム及びそのリスクに関する利害関係者の理解は，どの時点でも，完全でも確実でもない。

− システムの不完全な理解，予期しない事象及び変更による障害発生の可能性は排除も予測も不可能で

ある。システムには適応力が必要であり，エラーからの防護を含むリスク管理が必要であり，障害か
ら回復する必要があり，かつ，再発防止のための適応ができる必要がある。

− オープンシステムのディペンダビリティの達成は，反復的なアプローチを要する。また，その達成は，

システムにおける運用及び開発の統合に依存する。ライフサイクル全体にわたってディペンダビリテ
ィ活動を実施し，必要なだけ何度でも繰り返すことがオープンシステムにとって特に重要になる。

注記2 これらの特徴の幾つかは，いわゆる“システムオブシステムズ”[12]，[13]及び“非有界又は弱

有界システム”と共有されている。

注記3 見方次第で，ほとんどのシステムはこれらの特徴をある程度もつといえる。場合によっては無

視できる程度であることもある。システムがオープンシステムであるのは，これらの特徴がシ
ステムの課題検討において重要な意味をもつときであり，システムオブシステムズであるかど
うかにはよらない。

システムは，必然的に，相互接続され，独立して管理される多種多様な他システムとサービスをやりと

りする。これらの周辺システムは，それぞれの原則及び利害関係者に従って管理され，また，そのインタ

フェースは，様々な理由で変化するものである。システムは，多様な利害関係者に対応しなければならな
い。各利害関係者は異なった目標をもち，システムを統べる一元的権限をもつ者はいないこともあり得る。

さらに，システム及び周辺システムの目標は，時間とともに変化する。要求事項，制約などのシステムの
条件は頻繁に，予測し難く変化する。したがって，これらの条件については不確実性及び不完全性があり，
どの時点においても完全には理解され得ない。

オープンシステムは，その生涯を通じて継続的に変化するので，その設計プロセス（例えば，製品開発

のスパイラルモデルでモデル化されるもの）は，システムの全存続期間を通じて一定程度の活動を継続す
る。

C 62853：2020 (IEC 62853：2018)

さらに，不確実性及び不完全性は，システム自体に内在してもいる。例えば，機能，内部構造及び境界

に関するものである。各サブシステムは，しばしば異なる当事者によって管理されており，システムイン
テグレーション及びサブシステム境界間での調整に当たる者が完全な知識をもってサブシステムを掌握し

ているとは限らない。様々な利害関係者によって，又は利害関係者のために，運用中のシステムにサービ
ス及びコンポーネントが追加又は削除されることもある。システムのこのように動的な性格は，システム

の境界，機能及び構造を事実上曖昧なものにする。特定の視点から，全ての特定の時点において曖昧さは
全くないと理論上示されたとしても，この事実上の曖昧さは避けられない。

これらの理由のため，さらに，システムの圧倒的な複雑さ及び規模のため，十分と見な（做）し得る完

全さ，確実さをもってシステム及びシステム管理を明確化する，把握する又は制御するということは利害

関係者にとって非常に困難である。様々な度合いの予期しない変化及び障害が生じることは，システムの
本質の一部である。オープンシステムという用語の使用は，システムのこの側面を強調する。

システムに対する真の暗黙の期待は，常に他の周辺システム及び利害関係者の成す文脈の中における相

対的なものである。対象システムを取り巻く，様々なレベルのシステムの目標を考慮することが望ましい。
文脈が変化して不完全さ及び不確実さが何らかの形で解消されたときは，対応して起きる要求事項及び仮

定の変化にシステムは適応することが望ましい。これらの変化は，完全に予期することも，事前に指定す
ることも不可能である。

4.2

オープンシステム特有のディペンダビリティ課題

オープンシステムディペンダビリティが目指すのは，変化及び障害の発生にもかかわらず，長期にわた

ってサービスの継続を達成することである。サービス継続の達成のためには，システムのライフサイクル
全体に対して，また，改良活動を通じてのその反復に対して，要求事項を課すことになる。

IEC 60300-1で提供されるディペンダビリティマネジメントは，一般にオープンシステムにも当てはま

るものであり，この規格はIEC 60300-1と併せて利用しなければならない。IEC 60300-1では，改良活動の

計画及び管理並びに進捗状況の適切なレビューを通じて，持続的改善が確実に行われることが要求される。
オープンシステムディペンダビリティは，この点をオープンシステム向けに詳述するものである。ディペ

ンダビリティが，頻繁かつ予測不可能な変化に対する改善に直接依拠する状況での詳細化となる。そのよ
うな変化に対応するには，ライフサイクルに対して反復的なアプローチをとることが可能である。附属書
Aを参照。

オープンシステムのディペンダビリティマネジメントが扱う範囲は，4.1で説明された特性のため，自

明ではない。単に明示的合意に適合することを扱うだけでは不十分である。オープンシステムが完全には

定義し得ないものである以上，明示的合意では対象システムの全ての側面を十分にカバーし得ないためで
ある。利害関係者は，システム及びその環境に関する共通理解に基づいて，明示的合意を超えて行動する

用意ができている必要がある。オープンシステムディペンダビリティは，システムに対する確信及び信頼
を求める。理念として追求されるのは，たとえ仮定は破れ，変化によって要求事項は妥当でなくなり，い
ずれはシステム障害が起きるような状況下でも持続するような確信及び信頼である。

上記の議論は，ディペンダビリティマネジメントの適用範囲を継続的に見直して改訂し，明示的な文書

にして合意するプロセスの重要性を強調する。適用範囲に関する利害関係者間の合意は，説明責任に関す
る合意によって裏打ちされている必要がある。

予期しない原因を防ぐことは不可能である。可能なことは，主要な機能を特定し，主要機能の喪失がも

たらし得る結果を予期し，迅速な復旧又は冗長運用ができるよう主要機能を保護することである。

C 62853：2020 (IEC 62853：2018)

4.3

目標

オープンシステムディペンダビリティの目標は，周辺システム，利害関係者及び環境の成す状況を踏ま

え，利害関係者の知見の不完全性及び不確実性に起因して不測の事態及び変化が起きる中で，実現可能な
限りシステムに一定のサービス継続を持続させることである。

システムは，もはや確定的なものとは捉えられない。システムは，完全な又は確実な知見をもつことは

不可能な，オープンシステムと捉えられる。オープンシステムディペンダビリティをもつシステムには，
次のような能力が望まれる。

− 障害を引き起こす可能性のある要因を継続的に取り除き，それによって自分自身を改善する。

− 障害が発生したときに迅速かつ適切な措置をとる。

− 被害を防止し，最小限に抑え，緩和する。

− 利害関係者が期待するサービスを，可能な限り最大限度，継続的に提供する（優美縮退）。

− システム運用及びプロセスに関する説明責任を遂行するアクティビティ及びタスクを維持する。

− 各段階で置かれる前提条件の理解及びコミュニケーションを支援する。ここで，前提条件には，シス

テム記述の際に置かれるもの，それが明示的に文書化される際に置かれるもの，並びにその文書及び
受入れ当局による承認を通じてシステムのディペンダビリティが確定される際に置かれるものがある。

これらの能力は，接続されている他のシステムの変化による影響を受ける可能性が高いオープンシステ

ムにとって特別な重要性をもつが，ディペンダビリティをもつどんなシステムにも期待される能力である

という点ではオープンか否かに関わらない。オープンシステムディペンダビリティの特異性は，不完全さ
及び不確実さの下で前述の能力を達成しようとすることから生じる。オープンシステムディペンダビリテ

ィの特性は，前述の能力を達成するプロセスにあり，オープンシステムディペンダビリティは従来のディ
ペンダビリティと異ならない。

4.4

オープンシステムディペンダビリティの達成

オープンシステムがディペンダビリティを達成するには，そのライフサイクルは次の事項を利害関係者

が実践できるようにするものであることが望ましい。

a) システム，その目的，運用，環境及びそれらの変化を扱うための，全ての利害関係者に理解された準

拠枠を確立し，次いでその枠組みの中でそれらに関する共通理解及び明示的合意を確立する。

b) 利害関係者合意の各項目について，その不履行と不履行が利害関係者及び社会一般にもたらす帰結と

の間の関係を透明化する。説明責任を負う利害関係者に課す救済義務を含めて帰結を明らかにするこ
とで合意遵守に向けた最善努力を促し，潜在的被害に対して救済措置が確保されるようにする。

c) 障害に対する即時対応を計画して実施し，期待されるサービスが可能な限り，最小の中断及び被害で，

文脈に最も適切な方法で提供されるようにする。

d) システムを環境，目的，合意などの変化に適応させる際に起きる活動及び障害の経験から学ぶ活動を

組織化して，ディペンダビリティを継続的に改善するようにする。

これら四つの取組は，一緒に働き，それぞれは他の取組に依存する。a)は，b)，c)及びd)の土台となる。

b)は，a)の合意の履行の徹底に役立ち，また，システムに対する公共の確信及び信頼をc)及びd)に基づい

て実施された計画及び活動のコミュニケーションを通じて促進する。c)は，b)に必要な情報を提供し，ま
た，d)の障害の再発防止のための活動を引き起こす。d)は，a)の活動を再開させ，時間依存の変化をa)の

共通理解及び明示的合意に反映させる。明示的合意は，常に暫定的なスナップショット（動的に変化する
合意の一時点における内容を写し取った静的な記録）であり，継続的に更新される必要があるものである。

C 62853：2020 (IEC 62853：2018)

これらの四つの取組を組み合わせて協働させる際の方式は，ライフサイクルモデルとして表現すること

が可能である。附属書Aに例を示す。オープンシステムディペンダビリティを具体的なオープンシステム
に適用する例を附属書Cに示す。

4.5

適応力及びフォールトトレランスとの関係

オープンシステムにおける適応力の概念と従来のシステムにおけるものとは非常によく似ている。伝統

的な適応力（3.16及びその注釈1）では，外乱の後に通常運用に復帰する能力が重視される。オープンシ

ステムディペンダビリティでは，時点又は視点が変われば“通常運用”の定義さえも変わるという事実が
受け止められる。より最近の適応力の概念（3.16の注釈2）は，より広く変化及び適応を考慮し，オープ

ンシステムディペンダビリティと適応力とは目的を共有する。違いは，オープンシステムディペンダビリ
ティでは変化及び適応の必要性がシステムのオープン性から生じる状況に焦点が当てられ，したがって，
ライフサイクル観点のアプローチにおける合意及び説明責任に焦点が当てられる点である。

一方，フォールトトレランスの考え方は，従来のシステムとオープンシステムとでは異なる。従来のシ

ステムでは，重大な潜在的フォールトを少なくとも原理的には全て列挙できるという前提がなされる。そ

うして逸脱状態及び通常運用状態が明示的に定義された状況で，逸脱から通常運用に戻るための具体的手
順を固定して与えることでフォールトトレランスは達成される。オープンシステムディペンダビリティは，
逸脱状態及び通常運用状態を明示的に定義できない状況を考慮する。

適合性

システムのライフサイクルがオープンシステムディペンダビリティを支えるものであるためには，次の

主張を論証するディペンダビリティケース（JIS X 0134-2 [14]及びIEC 62741 [15]）が提供されることが望

ましい。

a) 対象システムのライフサイクルは，箇条6で規定された全てのプロセスビューの要求事項を達成する

ものである。

b) a)で達成が主張される要求事項は，対象システムのオープンシステムディペンダビリティ達成の要求

事項として適切であることについて検討がなされている。

注記1 ディペンダビリティケースが求められるのは，利害関係者が各々の責務の境界について理解し

て合意し，実施に関する説明責任を割り振り，変化を適切に管理することを確実にするためで
ある。

注記2 オープンシステムディペンダビリティは，その性格上，所与の十分条件の集合として示される

ものではない。個々の対象に対するこの規格適用の適合性は，b)での追加検討の品質を対象の

詳細に照らして評価される。

上記の主張を論証するディペンダビリティケースの参考となるテンプレートは附属書Bに示される。

C 62853：2020 (IEC 62853：2018)

オープンシステムディペンダビリティを達成するためのプロセスビュー

6.1

概要

箇条6では，オープンシステムディペンダビリティの四つの取組4.4 a)〜d)のための四つのプロセスビ

ューについて説明する。これらのプロセスの実施に必要なアクティビティ及びタスクの一部は，JIS X

0170:2020から選択されたものである。

オープンシステムディペンダビリティの各取組には，多くのライフサイクルプロセスを横断する一連の

アクティビティ及びタスクが必要である。プロセスビューの概念は，関連する一群のアクティビティを1

か所に集めて見るために導入されたもので，JIS X 0170:2020の附属書Eに記載されている。

箇条6は，JIS X 0170:2020の提供するプロセスビューポイントに適合する，四つのプロセスビューを規

定する。プロセスビューは，次の情報を与えることによって定義される。

a) プロセスビューの名称

b) プロセスビューの目的

c) プロセスビューの成果

d) プロセスビューを実施するプロセス，アクティビティ及びタスクの識別及び記述，並びに他の作業標

準のプロセス，アクティビティ及びタスクも用いる場合にはそれらの出典への参照

箇条6は，上記のa)〜d)を与えて，四つのプロセスビューのそれぞれを規定する。

四つのプロセスビューは，連携してオープンシステムディペンダビリティの目的を達成する。JIS X

0170:2020は適用ごとにライフサイクルモデルを定めることを求めるが，この四つのプロセスビューは，他
のプロセス及びプロセスビューと合わさって，附属書Aで示されるようなライフサイクルモデルを構成す

る。

注記1 JIS X 0170:2020は，プロセス，アクティビティ及びタスクを詳述している。選択されたプロセ

スは，システムのライフサイクル段階の管理及び実行のためにライフサイクル全体で適用可能
である。

注記2 4.4の最後から2番目の段落は，四つのプロセスビュー間の関係を概説する。A.2は，ライフサ

イクルモデルの例でその詳細な関係を示す。

箇条6の残りの部分では，各細分箇条（すなわち，6.i）がプロセスビューを提供する。各細分箇条は次

のように構成される。

6.iは，プロセスビューの名称(a)である。

6.i.1“目的”は，プロセスビューの目的(b)を与える。最初の段落は目的の中核になる言明である。それ

に続く段落は説明を加える。

6.i.2“成果”は，プロセスの成果(c)を列挙する。成果は，階層的に整理されることもある。附属書Bは，

挙げられた成果を用いたディペンダビリティケースの議論構造テンプレートを与える。テンプレートは，
列挙された成果が選ばれた理由の一部を示す。

6.i.3“プロセス，アクティビティ及びタスク”は，この規格の主要部分を成す。プロセスビューの実施に

用いられるJIS X 0170:2020のプロセス，アクティビティ及びタスクのリスト(d)が，オープンシステムデ
ィペンダビリティの実現に特化した手引とともに提供される。JIS X 0170:2020の各プロセスについて，そ

C 62853：2020 (IEC 62853：2018)

のプロセスとプロセスビューとの関連性を示す段落が必要に応じて設けられた後に，より詳細な記述が関

連するアクティビティ及びタスクごとに列挙される。詳細記述は，プロセスビューのどの成果に関わるも
のかの示唆とともに与えられる。6.i.3の記述は，関連するプロセス，アクティビティ及びタスクの定義及

び文脈を規定するJIS X 0170:2020中の記載と併せて用いなければならない。

6.i.3では，JIS X 0170:2020の箇条及びこの規格の箇条のいずれもが参照される。それらは次のように区

別される。山括弧（< >）は，JIS X 0170:2020のプロセスの細分箇条番号及びそのプロセス内のアクティビ
ティ・タスクのリスト項目のラベルを参照するために用いられる。例えば，“<6.4.2>利害関係者ニーズ及び

利害関係者要求事項定義プロセス”は，JIS X 0170:2020の6.4.2を指し，かつ，<6.4.2>の文脈において，
<a)1)>は，アクティビティ “a) 利害関係者ニーズ及び利害関係者要求事項定義の準備を行う。”の中のタ

スク“1) システムのライフサイクルを通じて，システムに関係する利害関係者を識別する。”を指す。二
階層のリストの場合，第1レベルのリスト項目への参照，つまり“<a)>”は，第1レベルの項目<a)>を構

成する第2レベルの全ての項目<a)1)>，<a)2)>，…，<a)n)>を指す。角括弧（[ ]）は，この規格の6.i.2にあ
るプロセスビュー成果のリスト項目ラベルを参照するために用いられる。

6.2

合意形成プロセスビュー

6.2.1

目的

合意形成プロセスビューの目的は，システム，システムの目的，目標，環境，実際のパフォーマンス，

ライフサイクル，及びそれらの変化に関する共通理解及び明示的合意を確立し，維持することである。

注記1 明示的合意とは異なり，システムの共通理解は必ずしも明示的に文書化されているとは限らず，

利害関係者間で共有される態度，信念，認識及び価値を含む。

目的は，次の理解の下に達成されることが望ましい。

同じ理解が全ての利害関係者に共有され，残らざるを得ない解釈の相違を許容範囲内に確実に収めるこ

とが望ましい。明示的合意には，システムの開発及び運用において利害関係者が得る便益・負う責務に関
する合意及び前提条件に関する合意が含まれる。

共通理解及び明示的合意の確立は，予期外の事象に対抗する包括的な予防手段の提供につながる。

注記2 利害関係者によっては，望まれる結果が他の利害関係者によって確実にされていることを理解

するだけで十分で，それに関わる技術的詳細を理解する必要はないということもあり得る。

目的の達成は次からなる。

− 利害関係者間の共通理解及び明示的合意の確立[6.2.2（成果）a)1)〜a)7)]

− 理解及び合意の維持[b)1)〜b)5)]

目的と成果との間の関係は，B.2に示される。

6.2.2

成果

a) 利害関係者間の共通理解及び明示的合意が確立されている。

1) システムの利害関係者が識別されている。

注記1 利害関係者のリストは，時間及び視点によって変化する。

2) 全ての利害関係者に理解された準拠枠が確立されている。準拠枠には，語彙及びシステムの環境に

関する基本的仮定が含まれる。

C 62853：2020 (IEC 62853：2018)

3) システムの目的，目標，環境，実際のパフォーマンス，ライフサイクル及びそれらの変化は，準拠

枠の中で各利害関係者によって同様に理解される。これには，システムに関する仮定及び利害関係
者の責務についての理解が含まれる。

4) 利益相反を解決できるよう，合意を得られない場合の仲裁手続が事前に合意されている。

注記2 利益相反には，知的財産権に関連するものも含まれる。

5) 明示的合意が3)の理解に基づいて作られ，文書化されている。文書中の記録には，合意形成の経緯

説明及びなぜ合意事項は適切かつ実現可能と考えられるのかの理由付けが含まれる。

6) 合意文書の解釈の差異は，許容範囲に収まっている。

7) 以上の成果は，全利害関係者に対して公正かつ衡平な方法で達成されている。

注記3 公正性及び注意深さは，予期外の事象に対する適応力に寄与する。公正性及び注意深さ

の欠如は，最終的に全ての利害関係者に影響を与える問題につながる。

注記4 意見又は要求事項を強要して引き出すようなことは公正でも注意深くもない方法の例で

あり，大規模オープンシステムの目標達成失敗に関して，短期的利得をはるかに超える
長期的悪影響を与える。

b) 利害関係者間の共通理解及び明示的合意が維持されている。

1) 合意の変更管理の方針が確立されている。

注記5 この方針は，サービス要求事項の最初の識別及びそれに続く改訂を含め，全ての段階で

適用されるものである。

2) 事業目標，利害関係者のニーズ，システム又は環境の変化に際して，利害関係者間の合意状態は維

持される。

注記6 このような変化は，障害の事後処理によって必要とされる可能性がある。

注記7 利害関係者の合意を維持することは，変化後の新しい目標，ニーズ，システム及び環境

を反映するように，それを改訂，検証及び更新することを意味する。

3) 事業目標，利害関係者のニーズ，システム又は環境の変化に際して，合意達成のプロセスが見直さ

れる。

注記8 合意を限定して，活動の一部又は利害関係者の一部にだけ関わり，その他の活動又は利

害関係者には影響しないものとすることが可能である。また，利害関係者は，自身にと
って重要でないか，又は重要性の低い事項には関与せず，受動的に合意を受け入れるこ

とを選ぶことも可能である。少数の熱心な利害関係者が活動を主導するというしばしば
見られる状況では，他の利害関係者は，システムのパフォーマンスが受容可能なもので

あり，かつ，重要な関心事に影響を与えない限り，受動的に合意を受け入れることが多
い。

注記9 利害関係者の関与を促す活動は，IEC 60300-1:2014の5.3（箇条書きリストの3番目の項

目）に規定されている。

4) ディペンダビリティケースの構築及び承認に関する責任が定められている。

5) 合意達成の事実，その進展の経緯，及びなぜ合意が適切かつ実現可能であると考えられるのかの理

由付けがディペンダビリティケースに記録されている（IEC 62741[15]を参照）。

6.2.3

プロセス，アクティビティ及びタスク

合意形成プロセスビューは，JIS X 0170:2020が提供する次のプロセス，アクティビティ及びタスクを使

用して実施されることが望ましい。

C 62853：2020 (IEC 62853：2018)

注記1 以降では，山括弧（< >）を用いてJIS X 0170:2020の細分箇条の番号又はリスト項目のラベル

を参照している。角括弧（[ ]）は，この規格のプロセスビュー成果の，リスト項目のラベルを
参照するために用いられる。詳細については，6.1の最後の段落を参照。

<6.1.1>取得プロセスは，取得者と供給者との間の合意を確立し，維持する。この合意は，[a)及びb)]に

おける明示的合意の一部である。取得者は，最終利用者，地域社会，規制当局などの，取得者及び供給者
以外の関係者の関心事を考慮することが望ましい[a)]。

− <a)1)>：取得戦略は，[a)]の共通理解及び明示的合意を達成するための方策を明確にすることが望まし

い。

− <c)1)及びc)4)>：取得者と供給者との間の合意の策定及び変更交渉は，公正かつ注意深い方法で行わ

れることが望ましい[a)7)]。

− <d)>：合意の監視は，取得者組織の方針の一部であり，明示的合意の維持を目指す[b)1)，b)2)及びb)3)]。

− <d)1)>：合意の実施のアセスメントには，その公正性及び注意深さのアセスメントが含まれることが

望ましい[a)7)]。

<6.1.2>供給プロセスは，取得者と供給者との間の合意を確立し，維持するものである。この合意は，[a)

及びb)]における明示的合意の一部である。供給者は，最終利用者，地域社会，規制当局などの，取得者及
び供給者以外の関係者の関心事を考慮することが望ましい[a)]。

− <a)1)>：取得者の識別は，利害関係者の識別の一部である[a)1)]。

− <a)2)>：供給戦略は[a)]を達成するための方策を明確にすることが望ましい。

− <c)1)，c)4)及びd)1)>：合意の交渉及び実施は公正かつ注意深く行われることが望ましい[a)7)]。

− <d)2)>：合意の実施のアセスメントには，その公正性及び注意深さのアセスメントが含まれることが

望ましい[a)7)]。

<6.2.1>ライフサイクルモデル管理プロセスは，合意形成プロセスビューの全成果が達成されるようにラ

イフサイクルプロセス間の連関を規定することが望ましい[a)及びb)]。

<6.2.5>品質管理プロセスは，管理対象の品質とする共通理解及び明示的合意の側面を定式化する。また，

共通理解及び明示的合意の品質を管理する[a)及びb)]。

− <a)1)>：品質管理方針，目標及び手順は，共通理解の度合い及び明示的合意[a)及びb)]に対する合意の

度合いについて取り組むことが望ましい。利害関係者は，システム全体の品質を管理する中央組織が
一般には存在しないことを考慮しつつ，品質管理に関する共通理解及び明示的合意を策定することが
望ましい[a)及びb)]。

− <a)2)及びa)3)>：品質管理に関する共通理解は，次の認識を含むことが望ましい[b)]。

・管理実施責任の定義及び品質評価基準の定義は不完全で，変更され得るものであること

・利害関係者は，必要に応じて，全体の品質のために定められた責任を超えて行動する用意があるこ

とが望ましいこと

− <a)3)>：評価基準は公正かつ注意深いものであることが望ましい[a)7)]。

<6.2.6>知識管理プロセスは，共通理解の源泉を提供する。

− <a)1)，b)1)及びc)1)>：知識管理戦略，知識共有のための分類法及び知識を整理する分類体系は，全て

の利害関係者に理解される準拠枠を提供することが望ましい[a)2)]。

− <d)>：知識の維持は，共通理解及び明示的合意の維持と統合されていることが望ましい[b)]。

C 62853：2020 (IEC 62853：2018)

<6.3.1>プロジェクト計画プロセスは，共通理解及び明示的合意を計画として具現化する[a)及びb)]。

− <a)及びb)1)〜b)6)>：プロジェクトの定義及び計画（目標，制約，範囲，ライフサイクルモデル，作業

構成明細（WBS），スケジュール，ライフサイクル段階の達成基準，コスト及び予算，役割，責任，説

明責任など）は，共通理解及び明示的合意を反映し，翻ってそれらを深化させ明確化し，維持の基礎
を形成するものであることが望ましい[a)2)，a)3)，a)5)，a)6)，b)1)，b)2)及びb)3)]。

− <b)4)>：ディペンダビリティケースに対する責務が，プロジェクト計画に定義されることが望ましい

[b)4)]。

− <b)7)>：計画のコミュニケーション及び見直しは，明確な合意の策定及び維持の一環となることが望

ましい。レビューは，合意を動機付けた根拠を提供し，記録することが望ましい[a)5)，b)2)及びb)5)]。

<6.3.2>プロジェクトアセスメント及び制御プロセスは，変化が発生した場合の共通理解及び明示的合意

の維持を統率する。

− <b)及びc)>：プロジェクトのアセスメント及び制御には，次の事項のアセスメント及び制御が含まれ

る[b)1)，b)2)及びb)3)]。

・変化する状況の中での利害関係者の合意

・このプロセスビューで要求される成果と比しての，関連プロセスのパフォーマンス

<6.3.3>意思決定管理プロセスは，共通理解及び明示的合意を確立し，維持することに起因する対立を解

決する[a)及びb)]。反対のない意見について，それを受諾するという決定の管理もする。

− <a)1)>：意思決定戦略には，事前に合意された調停プロセスが含まれることが望ましい[a)4)]。

− <a)3)>：利益相反の利害関係者以外にも，決定の影響を受ける者を識別し，かつ，関与させることが

望ましい[a)1)及びa)7)]。

− <b)2)>：望ましい結果及び案中から解決策を選択する基準は，合意形成プロセスビューの再帰的適用

によって，公正かつ注意深い方法で決定されることが望ましい[a)6)及びa)7)]。

− <c)2)及びc)3)>：合意形成の経緯並びにその公正性及び注意深さの証拠が，次の事項の記録によって

提供されることが望ましい[a)7)及びb)5)]。

・意思決定した対立解決策

・決定の根拠及び前提

・決定の結果の追跡及び評価

注記2 合意形成プロセスビュー及び意思決定管理プロセスの呼出しは，相互に再帰的である。合意形

成には意思決定が必要であり，かつ，それぞれの決定には，望ましい結果及び解決策選択基準
についての合意が要求される。

<6.3.6>情報管理プロセスは，共通理解，明示的合意及びそれらの管理に関する情報を，生成し，取得し，

確認し，変換し，保持し，取り出し，配信し，廃棄する。

− <a)1)及びa)5)>：情報管理及び情報維持活動の戦略は，次の事項に関する方針を含むことが望ましい。

事項は，合意の変更管理[b)1)]，利害関係者合意の維持[b)2)]，合意を達成するためのプロセスのレビ

ュー[b)3)]である。それら戦略は，解釈の違いを減らし[a)6)]，かつ，全ての利害関係者の公正性及び衡
平性を支援する[a)7)]ことが望ましい。

− <a)2)>：管理すべき情報項目には，識別された利害関係者のリスト[a)1)]，準拠枠[a)2)]，システムの目

的などの理解[a)3)]，合意された仲裁手続[a)4)]，明示的合意[a)5)]，ディペンダビリティケース[b)4)]，
合意構築の経緯説明及び合意の背後にある理由付けの説明[b)5)]が含まれることが望ましい。

C 62853：2020 (IEC 62853：2018)

− <a)3)>：情報管理の権限及び責務の指定には，ディペンダビリティケースのためのものが含まれる

[b)4)]。

− <a)4)>：情報項目の形式及び構造は準拠枠の一部である[a)2)]。その内容は共通理解を反映することが

望ましい[a)3)及びa)5)]。

− <b)1)>：明示的合意に関する情報の構築において生じる利益相反の解決には，事前に合意された仲裁

手続を採用することが望ましい[a)4)]。このタスクで行う，収集した情報を利害関係者にとって有用な
情報となるように変換する作業には，[a)2)]で確立される準拠枠を用いることが望ましい。

− <b)5)>：情報の廃棄，特に明示的合意の構築経緯説明及び合意の背後にある理由付けの説明[b)5)]の廃

棄は，将来時点での変化対応及び説明責任遂行において情報がもつ価値を慎重に検討した後にだけ行
うことが望ましい。将来時点には，障害対応が変化対応及び説明責任遂行を引き起こす時点も含まれ
る。

<6.3.8>品質保証プロセスは，共通理解及び明示的合意が十分な品質で確立され維持されているという確

信及び合意中に品質要求事項として表された内容が満足されているという確信を提供する。

− <b)及びc)>：製品又はサービス及びプロセスの評価は，共通理解及び明示的合意の維持の一環となる

ことが望ましい[b)1)及びb)2)]。

− <d)>：品質保証活動の記録は，合意形成の経緯説明を提供することが望ましい[b)5)]。

− <e)>：品質管理上の問題の処置では，問題の原因から共通理解及び明示的合意の更新が求められるか

否か，又は合意形成プロセス自体の更新が求められるか否かを検討することが望ましい[b)1)，b)2)及
びb)3)]。

<6.4.1>ビジネス又はミッション分析プロセスは，準拠枠を提供し，環境などに関して準拠枠に基づく共

通理解の構築を開始する。このプロセスの適用に当たっては，システムの全ての利害関係者を包含する組
織はないかもしれないことを考慮に入れることが望ましい。

− <a)2)及びb)2)>：ビジネス又はミッションの分析戦略，及び問題又は機会の空間の定義は，準拠枠及

び枠に基づいた，共有されるべき共通理解を明確にすることが望ましい。また，準拠枠及び共通理解
は，公正かつ注意深いものであることが望ましい[a)2)，a)3)及びa)7)]。

− <b)1)>：問題及び機会を分析した後には，全ての利害関係者が同じ理解をもつことの確認を得ること

が望ましい[a)2)，a)3)及びa)6)]。理解の項目には，<b)1)の注記1>で挙げられている，問題又は機会の
範囲，基盤又は駆動要因の項目がある。

− <c)1)>：

・主要な利害関係者グループの識別では，次を考慮に入れることが望ましい[a)1)]。

− 利害関係者は時間とともに変化し得る。

− 誰又はどの組織が，システムの主要な利害関係者グループを成すかについての認識は，利害関係者ご

とに異なり得る。

・各利害関係者は，その役割とともに識別されることが望ましい[a)1)]。

・予備的運用概念には，サービスに関する方針として共通理解を言い表したものが含まれることが望

ましい[a)2)]。

− <c)2)>：このタスクで識別されたソリューション類型は，全ての利害関係者間で共有されることが望

ましい。各利害関係者が，自身の観点から公正性及び注意深さについてソリューションを精査できる
ことが望ましい[a)3)及びa)7)]。

− <d)>：ソリューション類型の評価では，評価者及び評価方法が識別され，利害関係者間で合意される

C 62853：2020 (IEC 62853：2018)

ことが望ましい[a)7)]。

− <e)1)>：環境などの変化を受けてこのプロセスを再実施する際に，変化前の分析結果と変化後の分析

結果との間のトレーサビリティを維持することが望ましい[b)2)及びb)5)]（<6.4.1.1の注記2>を参照）。

これは，ライフサイクル反復の各回において分析結果と他の成果物との間のトレーサビリティを維持
することに追加しての推奨である。

<6.4.2>利害関係者ニーズ及び利害関係者要求事項定義プロセスは，システムの目的などに関する共通理

解及び明示的合意を，利害関係者ニーズ及び要求事項として策定する[a)3)及びa)5)]。

− <a)1)>：利害関係者の識別では，次を考慮に入れることが望ましい[a)1)]。

・利害関係者は時間とともに変化する可能性があり，システムの利害関係者が誰又はどの組織である

のかの認識は，利害関係者ごとに異なり得ることを考慮することが望ましい。

・各利害関係者は，その役割とともに識別されることが望ましい。

− <a)2)>：利害関係者ニーズ及び利害関係者要求事項定義戦略は，システムアシュアランス及び完整性

の確保に役立つ形で，意見の相違及び対立の際に，公正かつ注意深い解決を与える備えをもつことが
望ましい[a)4)及びa)7)]（<6.4.2.3 a)2)の注記> を参照）。その戦略は，システムのサービスに関する方

針について，どう共通理解を達成するかを示すことが望ましい[a)3)]。

− <b)1)>：システムの使用文脈の定義は，利害関係者がそれぞれもつ暗黙の前提の相違を公正かつ注意

深い方法で解消することが望ましい[a)2)，a)3)及びa)7)]。

− <b)2)，b)3)及びb)4)>：明示的及び暗黙的なニーズの抽出では特に，次の点で<b)2)の注記1>に注意を

払うことが望ましい。

・利害関係者のニーズは，システム及びその環境に関して利害関係者がもつ暗黙の前提とともに引き

出されることが望ましい。

・暗黙の前提の相違は，ある程度の運用期間を経て初めて明らかになり得ることを考慮に入れること

が望ましい。

・暗黙の前提は，利害関係者間のディペンダビリティコミュニケーションを阻害し，合意形成の障害

となり得，かつ，不適切な決定につながり得る[a)2)及びa)3)]。

・利害関係者のニーズの抽出，識別，選択及び定義は，公正かつ注意深くあることが望ましい[a)7)]。

− <c)>：運用概念には，共通理解を反映したシステムのサービスに関する方針が含まれることが望まし

い[a)2)]。

− <f)>：利害関係者ニーズ及び利害関係者要求事項定義の管理では，定義の変化が管理されることが望

ましい[b)]。

<6.4.3>システム要求事項定義プロセスは，利害関係者の合意を具体的なシステム要求事項に変換する。

これは，このプロセスビューの成果のアセスメントだけでなく成果の保守を助ける[a)及びb)]。

− <b)及びc)>：技術的要求事項として特定の一組を選択する前に，利害関係者は，選択から予期される

結果及びリスクについて，自分たちの言葉で合意に達しておくことが望ましい[a)5)，a)6)及びa)7)]。

<6.4.4>アーキテクチャの定義は，準拠枠及び明示的合意の一部を提供する[a)2)及びa)5)]。

− <b)1)>：アーキテクチャビューポイントは，[a)2)]の準拠枠を形成することが望ましい。

− <f)2)>：利害関係者から得るアーキテクチャの明示的な受諾は，明示的合意の一部を形成することが

望ましい[a)5)]。

<6.4.9>検証プロセスは，明示的合意のアセスメントの一部である[a)6)及びb)2)]。

C 62853：2020 (IEC 62853：2018)

− <c)3)>：システムが要求事項を満たすという利害関係者合意は，成果[a)5)]の明示的合意の一部である。

<6.4.11>妥当性確認プロセスは，明示的合意のアセスメントの一部である[a)6)及びb)2)]。

6.3

説明責任遂行プロセスビュー

6.3.1

目的

説明責任遂行プロセスビューの目的は，明示的合意に対する違反及び違反の結果として利害関係者及び

社会一般にもたらされる帰結との間の対応関係を確立することである。これには，説明責任を負う利害関
係者に被害の救済措置提供を義務付け，もって合意実現の公算を増し，システムに関する確信及び信頼を
保ち，潜在的被害に対して救済措置を確保しておくことが含まれる。

注記1 合意事項違反には，予想外の有害事象のために利害関係者が合意を履行できない場合が含まれ

る。

注記2 合意は，各利害関係者が何について説明責任を負うのかを明確にできる程度に，明示的である

必要がある。明示的合意は，必要に応じて業界の実務規範などの暗黙の合意を参照する必要が
ある。

目的は，次の理解の下に達成されることが望ましい。

説明責任遂行プロセスビューは，社会一般に対して説明責任を提供する。説明責任は，システムのライ

フサイクルのあらゆる部分で行われた決定及び行動に対する全体的な責任である。説明責任には，利用者
及び他の利害関係者への情報提供に関する対外的責任並びに識別されたリスクに対する監視及び管理策維

持に関する対内的責任が含まれる。オープンシステムは一元管理に欠けるため，個々の決定，活動又は管
理策について，それに関する説明責任を負う当事者を識別することは困難である。

説明責任は，システムに対する人々の確信及び信頼に直接影響を与える。さらに，システムのそのよう

な主観的特性は，ディペンダビリティにとって本質的である。実際，システムによっては，説明責任の欠

如は障害後のサービス再開の妨げとなる。これは，技術的には障害復旧した後でも規制当局の要求を満た
せない，世論の支持を得られないなどの社会的な要因による。

説明責任は，対象システムのディペンダビリティを達成するために必要であり，また，相互接続されな

がら独立管理下にある諸システムの全体的なディペンダビリティを強化する。一つのシステムの障害の影
響は，相互接続先の諸システムで障害に関する情報を共有することによって緩和することが可能である。

目的の達成は，次からなる。

− 説明責任が求められる事象の発生前の，合意違反とその帰結との間の関係の確立（説明責任を負う利

害関係者に課される救済措置提供義務の確立を含む。）[6.3.2（成果）のa)〜e)]

− 説明責任が求められる事象を予期し，対応するアクションの実施[f)〜h)]

− 利害関係者及び社会一般への適切な情報の提供[i)1)〜i)5)]

目的と成果との間の関係は，B.3に示される。

6.3.2

成果

a) 主要意思決定事項が識別されている。主要意思決定事項は，ライフサイクル及びライフサイクルにお

けるリスクを制御する決定事項であり，プロセス及びプロセスビューの成果を制御する決定事項を含
む。

C 62853：2020 (IEC 62853：2018)

注記1 主要意思決定事項には，ライフサイクル段階の決定ゲートでなされる決定及びライフサイ

クルの後の進捗に大きな影響を及ぼす決定が含まれる。

b) ライフサイクル及びライフサイクルにおけるリスクを制御する各主要意思決定事項について，説明責

任を負う者又は組織が識別されている。

c) 各明示的合意の各事項について，失敗又は違反の原因となり得る主要意思決定事項はどれかが識別さ

れている。

注記2 システム外の要因によって引き起こされる合意事項違反について，その要因となる主要意

思決定事項には，リスクの受容及び不十分なリスク分析の結果の検収が含まれる。

注記3 合意事項違反に対して説明責任を負う利害関係者は，その違反の原因になる可能性がある

と識別された主要意思決定事項について説明責任を負う者である。

d) 各明示的合意に対する各違反について，説明責任を負わない利害関係者及び社会一般に対する影響の

アセスメントが行われている。

注記4 アセスメントには，影響の制御可能性の分析が含まれる。ここで制御可能性は，説明責任

を負う利害関係者が，与えられた権限及び資源の下でなし得る制御の可能性を指す。

注記5 各明示的合意の各項目はそのような検討が可能となるように策定される。

e) 各明示的合意に対する各違反について，説明責任を負う利害関係者にもたらされる帰結並びに説明責

任を負わない利害関係者及び社会一般に対する救済措置が合意されている。

注記6 説明責任を負う利害関係者にもたらされる帰結には，合意された救済措置を提供する義務

が含まれる。救済措置は，説明責任を負わない利害関係者及び社会一般に対するものであ
る。説明責任を負う利害関係者の制御能力が義務を履行するのに十分であるように，合意
は合意形成プロセスビューを用いて改訂される。

注記7 合意違反の帰結及び救済措置に関して元の合意に付加される合意では，a)〜d)で考慮され

ていない破壊的な変化によって違反が生じる場合も考慮される。

意思決定での決定から生じた結果が，予期されたものも予期されなかったものも幅広くシステム全体
にわたって監視され，アセスメントされている。これには，合意事項違反の監視も含まれる。

g) とられた決定及び措置から生じた結果を意思決定者及び他の利害関係者に知らせるフィードバックル

ープが確立している。

注記8 フィードバックループは，意図されていなかった結果を認識し，それに対処するアクショ

ンを開始する。

注記9 フィードバックループは，システムの動作及び相互作用について，システムの様々な部分

を担当する各意思決定者間での理解を向上させる。良好なフィードバックループは極めて

重要である。なぜならば，各意思決定者はシステム全体を完全には理解しておらず，した
がって決定は，システムの他の部分で意図しない結果を招き得るためである。

注記10 意思決定管理は，オープンシステムでは特に困難であり，合意形成プロセスビュー及び説

明責任遂行プロセスビューの両者にまたが（跨）って関わる。管理上の問題が起きる時点
には，合意された決定の実施時，決定がもたらした結果のフィードバック時，システムの

他の部分にもたらされた意図しない結果への対処時がある。フィードバックループは，こ
れらの問題を解決するのに役立つ。

h) 合意事項違反があった場合，違反について説明責任を負う利害関係者は，説明責任を負わない利害関

係者及び社会一般に対し，遅滞なく救済を提供する。

十分かつ的確な情報が，説明責任を負う利害関係者から，説明責任を負わない利害関係者及び社会一

C 62853：2020 (IEC 62853：2018)

般に対して遅滞なく提供される。

注記11 複数のライフサイクルプロセスからの情報を統合する必要がある場合がある。

注記12 情報が十分かつ適切であるのは，次を満たすときである。(1)包括的である。(2)情報受領者

に容易に理解される。(3)受領者自身による障害からの危害緩和を可能にする。(4)情報の十
分性及び妥当性について，受領者が正当な確信及び信頼をもつ。

1) 利害関係者からのシステムに関する正当な情報請求には，速やかに適正かつ十分な返答が与えられ

る。

2) システムに関して提供された情報について，利害関係者は正当な確信及び信頼をもつ。

3) 障害発生後には，十分かつ的確な情報が選定され，対象システムの利害関係者，接続先の他システ

ムの利害関係者及び公衆に対し提供される。

注記13 情報は，障害対応プロセスビューから与えられる。

4) 次の変化に関する情報が選定され，対象システムの利害関係者，接続先の他システムの利害関係者

及び公衆に対し提供される。対象とする変化は，システム要求事項の変化，システムへの期待の変
化，システム記述の変化及びシステム性能の変化である。

5) 次のそご（齟齬）に関する情報が，見つかり次第選定され，対象システムの利害関係者，接続先の

他システムの利害関係者及び公衆に対し提供される。対象とするそご（齟齬）は，システムに関す
る要求事項，期待，記述及び性能の間のそご（齟齬）である。

6.3.3

プロセス，アクティビティ及びタスク

説明責任遂行プロセスビューは，JIS X 0170:2020が提供する次のプロセス，アクティビティ及びタスク

を使用して実施されることが望ましい。

<6.1.1>取得プロセス

− <c)>：取得者と供給者との間の合意（受入れ基準及び取得者の義務を含む。）の確立には，システムの

ライフサイクルを制御する主要な意思決定が伴う[a)]。取得者供給者間合意の不履行は合意事項違反
であり，不履行につながり得る主要意思決定事項などは識別されていることが望ましい[b)，c)，d)及

びe)]。

− <d)>：合意の監視はフィードバックループの一部である[f)及びg)]。

<6.1.2>供給プロセス

− <c)>：取得者と供給者との間の合意（受入れ基準及び取得者の義務を含む）の確立には，システムの

びe)]。また，このアクティビティでの合意の維持は，成果[f)及びg)]を実現できるように行うことが
望ましい。

− <e)4)>：製品又はサービスに対する責任を供給者から取得者に移す際は，成果の継続的な達成を確実

にする方法をとることが望ましい[f)，g)，h)及びi)]。

<6.2.1>ライフサイクルモデル管理プロセス

− <a)3)>：役割などの確立には，各主要意思決定事項について説明責任を負う者又は組織の識別を含め

ることが望ましい[b)]。

− <a)4)>：ライフサイクルの進捗を管理するビジネス基準及び基準に基づくライフサイクル段階の管理

方法の定義には，主要な意思決定が伴う[a)及びb)]。基準及び管理方法の策定の経緯は文書化される

C 62853：2020 (IEC 62853：2018)

ことが望ましい[i)]。

− <a)5)>：このタスクで確立される標準ライフサイクルモデルは，説明責任遂行プロセスビューの全成

果が達成されるようにライフサイクルプロセス間の連関を規定することが望ましい[a)〜i)]。

<6.2.3>ポートフォリオ管理プロセスは，対象システムのライフサイクルと他システムのライフサイクル

との間のインタフェースをつかさど（掌）る主要な意思決定を識別することが望ましい[a)]。

− <a)3)>：説明責任及び権限の定義は，成果[a)及びb)]達成活動の一部であり，成果[c)，d)及びe)]とと

もに考慮されることが望ましい。

− <a)5)>：説明責任を負う者又は組織への資源の配分には，主要な意思決定が伴う[a)及びb)]。

− <c)1)>：プロジェクトの中止及び一時停止は，適時適宜に行うことが望ましい[i)]。

<6.2.5>品質管理プロセス

− <a)1)及びa)3)>：品質管理方針などの策定，品質評価基準の定義及び評価方法の定義には，主要な意

思決定が伴う[a)]。これらは成果[b)，c)，d)，e)及びh)]とともに考慮されることが望ましい。各識別又
は定義には，説明責任の割当てが伴うことが望ましい。

− <a)2)>：品質管理の実施に対する責任及び権限を定義することは，成果[b)]達成活動の一部である。

− <b)>：顧客満足度アセスメントは，成果[d)，f)及びg)]達成活動の一部である。

− <c)>：是正措置及び予防措置を計画することは，説明責任を負う利害関係者の義務の一部である[e)及

びh)]。これらの措置はフィードバックループの一部である[g)]。

<6.2.6>知識管理プロセスの実施は，知識は複数の組織間で共有されるものであるという文脈で行われる

ことが望ましい[f)，g)及びi)]。成果[i)]における十分な情報には，得られた教訓を含めることが望ましい。

教訓は，説明責任を負う利害関係者が過去の経験から得て意思決定に活用した知見である。

<6.3.1>プロジェクト計画プロセス：このプロセスで行われる全ての定義及び識別には，主要な意思決定

[a)]が伴う。成果[b)，c)，d)，e)及びh)]とともに考慮されることが望ましい。

− <a)4)>：作業構成明細（WBS）は，説明責任の割当て及び伝ぱ（播）する関連情報の識別を伴うこと

が望ましい[b)及びi)]。

− <b)4)>：このタスクで定義される説明責任には，システム障害の際に配信されるべき，的確な情報の

識別作業を含めることが望ましい[i)]。

− <b)6)>：計画策定には主要な意思決定が伴う[a)]。策定は成果[b)，c)，d)，e)及びh)]とともに考慮され

ることが望ましい。

<6.3.2>プロジェクトアセスメント及び制御プロセス

− <a)1)>：プロジェクトのアセスメント及び制御の戦略の定義には，主要な意思決定が伴う[a)]。定義は

成果[b)，c)，d)，e)及びh)]とともに考慮されることが望ましい。

− <b)>：プロジェクトのアセスメントは，[d)]のアセスメントを含むことが望ましい。結果は，説明責任

情報[i)]として提供されることが望ましい。

− <c)>：プロジェクトの制御には，フィードバックループ[g)]，是正措置の開始[h)]及び説明責任情報の

提供[i)]に関する制御が含まれることが望ましい。

<6.3.3>意思決定管理プロセス：意思決定及び意思決定の管理に関する説明責任には，説明責任を負う利

害関係者が全ての関連情報を考慮し，意思決定管理プロセスの規定に正しく従ったことを示す責任が含ま
れる。

C 62853：2020 (IEC 62853：2018)

− <a)1)及びc)3)>：意思決定管理戦略は，良好なフィードバックループを提供することが望ましい[g)]。

− <c)2)及びc)3)>：意思決定の記録には，意思決定及び意思決定の管理に関する説明責任が達成されて

いるという証拠が含まれることが望ましい[i)]。

<6.3.4>リスク管理プロセス：識別されたリスクの管理活動に関する説明責任，すなわち，それらの監視

及び管理策の維持に関する説明責任は特に重要である。よく理解されていないリスクについても，明確に
定義されている必要がある[b)，e)，f)及びh)]。

− <a)1)及びd)>：リスク管理戦略の定義及びリスク処置に関する決定には，主要な意思決定が伴う[a)]。

これらは成果[b)，c)，d)，e)及びh)]とともに考慮されることが望ましい。

<6.3.5>構成管理プロセス

− <b)及びc)>：構成管理プロセスにおける構成品目の識別及びその変更管理には，主要な意思決定が伴

う[a)]。これらは成果[b)，c)，d)，e)及びh)]とともに考慮されることが望ましい。

− <d)及びe)>：構成状態説明報告及び構成評価は，成果[i)]における十分な情報の一部を提供する。この

一部は，利害関係者に与えられるシステムに関する情報について，利害関係者からの信頼及び確信を
得ることに役立つものであることが望ましい[i)2)]。

− <e)4)及びe)5)>：構成のアセスメントの実施は，合意事項違反の監視[f)]及び意思決定者に決定の結果

を知らせるフィードバックループ[g)]の一環として行われることが望ましい。

<6.3.6>情報管理プロセスは，成果[i)]で参照される十分な情報を管理し，提供することが望ましい。特に，

利害関係者が情報について，正当な確信及び信頼をもつことの達成が望ましい[i)2)]。情報の提供に当たっ

ては，複数のライフサイクルプロセスの連携を考慮することが望ましい。

− <a)1)>：情報管理戦略は，意思決定者への決定の結果に関するフィードバックループの提供を支援す

ることが望ましい[g)]。

− <a)2)>：全てのプロセスが情報管理プロセスを呼び出し，ログデータ及びその他の証拠を収集し管理

することが望ましい。ログデータ及び証拠は，説明責任情報の十分性及び妥当性を確立し正当化する
ためのものである。この際に正当性理由の客観的表現が提供されることが望ましい[i)2)]。

− <b)1)>：情報項目の収集及び利用は，情報の信ぴょう（憑）性の証拠の収集及び利用とともになされ

ることが望ましい。証拠は，受信者による信ぴょう（憑）性の検証を可能とする形のものであること
が望ましい[i)2)]。

− <b)3)>：情報の発行，配布又は情報へのアクセスの提供は，成果[i)]を実現できるよう実施されること

が望ましい。

− <b)5)>：情報の廃棄には主要な意思決定が伴う。情報が廃棄されるのは，廃棄が将来時点で説明責任

遂行に及ぼす影響を慎重に検討した後だけとすることが望ましい[a)〜i)]。

<6.3.7>測定プロセスは，フィードバックループの一部を形成することが望ましい[g)]。

− <a)3)>：予期しなかった結果を監視するというフィードバックループにおける目標に照らした情報ニ

ーズが考慮されることが望ましい[f)及びg)]。

<6.3.8>品質保証プロセス

− <a)1)>：品質保証戦略の定義には，主要な意思決定が伴う[a)]。定義は成果[b)，c)，d)，e)及びh)]とと

もに考慮されることが望ましい。

<6.4.1>ビジネス又はミッション分析プロセス

C 62853：2020 (IEC 62853：2018)

− <c)>：解空間の特徴付けには，識別された各主要利害関係者が負う説明責任の特徴付けが含まれてい

ることが望ましい[b)]。

<6.4.2>利害関係者ニーズ及び利害関係者要求事項定義プロセス

− <a)1)，b)，c)及びd)>：利害関係者の識別，利害関係者ニーズの定義，運用概念の定義及びその他のラ

イフサイクル概念，利害関係者要求事項の定義には，主要な意思決定が伴う[a)]。これらは成果[b)，
c)，d)，e)及びh)]とともに考慮されることが望ましい。

− <b)2)及びd)3)>：利害関係者のニーズは，利害関係者が負う説明責任とともに識別されることが望ま

しい[b)，c)，d)，e)及びh)]。

− <c)>：運用概念及びその他のライフサイクル概念には，<6.4.1>で識別された主要な利害関係者グルー

プが負う説明責任の定義が含まれることが望ましい。シナリオの分析は，シナリオ内で利害関係者が

とった主要な意思決定を識別し，かつ，それら意思決定の潜在的な影響及び結果を分析することが望
ましい[a)，b)，c)，d)，e)及びh)]。

− <e)>：利害関係者ニーズ分析の結果を適切なものと認めて受け入れることには，主要な意思決定が伴

う。利害関係者ニーズ及び利害関係者要求事項定義プロセスの責任者は，意思決定に対する説明責任
を負う[a)，b)，c)，d)，e)及びh)]。

− <e)3)>：分析された要求事項を該当する利害関係者にフィードバックすることは，フィードバックル

ープの一部である[g)]。

− <f)1)>：利害関係者要求事項に関する明示的合意では，合意の各項目に関する説明責任が識別されて

いることが望ましい[c)，d)，e)及びh)]。

− <f)2)>：利害関係者ニーズ及び利害関係者要求事項のトレーサビリティの維持では，説明責任の割当

ても追跡されることが望ましい[b)]。トレーサビリティの維持は，成果[c)，d)，e)及びi)]の達成に適切

な方法でなされることが望ましい。利害関係者要求事項は，システム監視の要求事項に至るまで追跡
されることが望ましい[f)及びg)]。

− <f)3)>：ベースラインに含める主要情報項目の選択の経緯が，成果[i)]達成活動での使用に向けて記録

されることが望ましい。

<6.4.3>システム要求事項定義プロセス

− <a)1)，b)2)，b)4)及びd)3)>：機能境界の定義，実装制約，システム要求事項，及びベースラインに含

める主要情報項目の選択には，主要な意思決定が伴う[a)]。これらは成果[b)，c)，d)，e)及びh)]ととも
に考慮されることが望ましい。

− <a)1)>：機能境界は，説明責任の境界とともに定義されることが望ましい[a)，b)，c)，d)，e)及びh)]。

− <b)1)>：機能は，その実現に関する説明責任とともに定義されることが望ましい[a)，b)，c)，d)，e)及

びh)]。

− <b)3)>：リスク関連のシステム要求事項及び重大なシステム要求事項の識別は，それらに関する説明

責任の識別とともになされることが望ましい[c)，d)及びe)]。

− <b)4)>：このタスクで定義される利害関係者要求事項及びその根拠は，次を明らかにすることが望ま

しい[a)，b)，c)，d)，e)及びh)]。

・要求事項の定義に影響した主要な意思決定

・要求事項に関する説明責任の定義に影響した主要な意思決定

− <c)>：システム要求事項分析の結果を適切なものと認めて受け入れることには，主要な意思決定が伴

う。この意思決定に対する説明責任は，システム要求事項定義プロセスの責任者が負う[a)，b)，c)，

C 62853：2020 (IEC 62853：2018)

d)，e)及びh)]。

− <c)3)>：このタスクでの，分析された要求事項の関連する利害関係者へのフィードバックは，[g)]のフ

ィードバックループの一部である。

− <d)2)>：システム要求事項のトレーサビリティの維持では，説明責任の割当ても追跡されることが望

ましい[b)]。トレーサビリティの維持は，成果[c)，d)，e)及びi)]の達成に適切な方法でなされることが

望ましい。

<6.4.4>アーキテクチャ定義プロセス

− <a)1)，a)2)，a)4)，b)，d)1)，d)2)，e)3)及びf)2)>：次の事項には主要な意思決定が伴う[a)]。これらは

成果[b)，c)，d)，e)及びh)]とともに考慮されることが望ましい。

・アーキテクチャを駆動する重要事項の識別

・利害関係者の関心事の識別

・評価基準の定義

・アーキテクチャビューポイントの定義

・システム要素の識別

・システム要素と外部エンティティとの間のインタフェース及び相互作用の定義

・アーキテクチャの選定

・アーキテクチャの受入れ

− <a)4)>：アーキテクチャの評価基準には，候補アーキテクチャがいかに説明責任について記述してい

るかに関する評価基準を含めることが望ましい。

− <c)>：候補アーキテクチャのモデル及びビューは，成果[a)，b)，c)，d)，e)及びh)]がどのように達成

されるかを明らかにするように構築されることが望ましい。

− <d)>：アーキテクチャと設計との関係付けには，アーキテクチャ要素に関する説明責任とシステム要

素に関する説明責任との間の対応関係が含まれることが望ましい。

− <f)6)>：アーキテクチャのトレーサビリティの維持では，説明責任の割当ても追跡されることが望ま

しい[b)]。トレーサビリティの維持は，成果[c)，d)，e)及びi)]の達成に適切な方法でなされることが望
ましい。

− <f)7)>：ベースラインに含める主要情報項目の選択の経緯が，成果[i)]達成活動での使用に向けて記録

されることが望ましい。

<6.4.5>設計定義プロセス

− <b)1)，b)2)，b)5)，c)及びd)4)>：次の事項には主要な意思決定が伴う[a)]。これらは成果[b)，c)，d)，

e)及びh)]とともに考慮されることが望ましい。

・システム要求事項の，システム要素への割当て

・アーキテクチャ特性の，設計特性への変換

・システム要素同士の間及びシステム要素と外部実体との間のインタフェースの定義

・非開発項目の識別（システム要素を得るための選択肢のアセスメント）

・ベースラインに含める主要情報項目の選択

− <b)1)>：システム要求事項のシステム要素への割当ては，前者に関する説明責任の後者に関する説明

責任への割当てを含むことが望ましい[b)，c)，d)，e)及びh)]。

− <b)2)>：アーキテクチャ特性が設計特性に変換されるとき，前者に関する説明責任も後者に関する説

C 62853：2020 (IEC 62853：2018)

明責任に割り当てられることが望ましい[b)，c)，d)，e)及びh)]。

− <b)5)>：システム要素間のインタフェースは，各システム要素に関する説明責任の範囲とともに定義

されることが望ましい[b)，c)，d)，e)及びh)]。

− <c)>：非開発項目候補の識別及びアセスメントでは，非開発項目に関する説明責任が明確にされるこ

とが望ましい[b)，c)，d)，e)及びh)]。

− <d)3)>：設計のトレーサビリティの維持では，設計に関する説明責任のトレーサビリティも維持され

ることが望ましい[b)，c)，d)，e)，h)及びi)]。

− <d)4)>：ベースラインに含める主要情報項目の選択の経緯が，成果[i)]達成活動での使用に向けて記録

されることが望ましい。

<6.4.6>システム分析プロセス：次の事項に関する経緯が，[i)]における十分な情報としての使用に向けて

記録されることが望ましい。

− <a)1)>：システム分析を必要とする問題の識別

− <a)2)>：システム分析の利害関係者の識別

− <a)3)>：システム分析の適用範囲，目標，及び忠実度の定義

− <b)1)>：仮定の識別

− <b)4)>：分析の結論の確立

− <c)2)>：ベースラインに含める主要情報項目の選択

<6.4.7>実装プロセス

− <a)1)及びa)2)>：実装戦略の定義，実装制約の識別及び実装技術の識別には，主要な意思決定が伴う

[a)]。これらは成果[b)，c)，d)，e)及びh)]とともに考慮されることが望ましい。

− <c)>：正常と異常の弁別に用いる基準の確立の経緯及びベースラインに含める主要情報項目の選択の

経緯が，成果[i)]達成活動での使用に向けて記録されることが望ましい。

− <c)2)>：実装されたシステム要素のトレーサビリティの維持では，システム要素に関する説明責任の

トレーサビリティも維持されることが望ましい[b)，c)，d)，e)，h)及びi)]。

<6.4.8>インテグレーションプロセス

− <a)5)>：インテグレーションの都合から生じるシステム制約は，フィードバックの一部としてシステ

ム要求事項，アーキテクチャ又は設計に組み込むことが望ましい[g)]。

− <c)1)及びc)3)>：正常と異常の弁別に用いる基準の確立の経緯及びベースラインに含める主要情報項

目の選択の経緯が，成果[i)]達成活動での使用に向けて記録されることが望ましい。

− <c)2)>：統合されたシステム要素のトレーサビリティの維持では，システム要素に関する説明責任の

トレーサビリティも維持されることが望ましい[b)，c)，d)，e)，h)及びi)]。

− <b)1)及びb)3)>：実装されたシステム要素の受入れ，及びインタフェースなどのチェック実施結果が

満足なものであると判断することには主要な意思決定が伴う[a)]。これらは成果[b)，c)，d)，e)及びh)]
とともに考慮されることが望ましい。

<6.4.9>検証プロセス

− 次の事項に関する経緯が，[i)]における十分な情報としての使用に向けて記録されることが望ましい。

・ <a)1)>：検証範囲の識別及びそれに対応する検証作業の識別

・ <b)>：検証の実施

C 62853：2020 (IEC 62853：2018)

・ <c)1)>：正常と異常の弁別に用いる基準の確立

・ <c)3)>：システム又はシステム要素が明示された要求事項に合致していることについての利害関係

者合意の確保

・ <c)5)>：ベースラインに含める主要情報項目の選択

− <a)5)>：検証戦略の考察から生じるシステム制約のシステム要求事項，アーキテクチャ又は設計への

組込みは，フィードバックの一部として行われることが望ましい[g)]。

− <c)3)>：システム又はシステム要素が明示された要求事項に合致していることの確認は，主要な意思

決定事項である[a)]。成果[b)，c)，d)，e)及びh)]とともに考慮されることが望ましい。

− <c)4)>：検証されたシステム要素のトレーサビリティの維持では，システム要素に関する説明責任の

トレーサビリティも維持されることが望ましい[b)，c)，d)，e)，h)及びi)]。

<6.4.10>移行プロセス

− 次の事項には主要な意思決定が伴う[a)]。これらは成果[b)，c)，d)，e)及びh)]とともに考慮されること

が望ましい。

・ <a)1)>：移行戦略の定義

・ <a)2)>：必要となる設備又は運用場所の変更の識別

・ <a)3)>：運用者，利用者及び他の利害関係者に必要となる訓練の識別

・ <b)10)>：システムを運用開始可とする判断

− 次のものに関する経緯が，[i)]における十分な情報としての使用に向けて記録されることが望ましい。

・ <b)4)>：システムは適切に導入されている，とした判断

・ <b)6)>：利害関係者要求事項が運用環境において満足されていることは導入されたシステムのチェ

ックアウトによって正当に確認されている，とした判断

・ <b)7)>：要求された機能の遂行能力を導入されたシステムがもつことは実証されている，とした判

断

・ <b)8)>：導入されたシステムをイネーブリングシステムが持続できることは実証されている，とし

た判断

・ <b)9)>：運用準備態勢が十分であることがレビューによって実証されている，とした判断

・ <c)1)及びc)2)>：異常，運用上のインシデント及び問題の弁別に用いる基準の確立

・ <c)3)>：ベースラインに含める主要情報項目の選択

− <a)1)>：移行戦略は，説明責任の割当て[b)，c)，d)，e)及びh)]を含むことが望ましい。

− <a)3)>：運用者などに必要な訓練の識別には，その者の負う説明責任の識別が含まれることが望まし

い[b)，c)，d)，e)及びh)]。

− <a)4)>：移行の都合から生じるシステム制約は，フィードバックの一部としてシステム要求事項，ア

ーキテクチャ，又は設計に組み込まれることが望ましい[g)]。

− <b)5)>：運用者などの訓練には，その者の負う説明責任のコミュニケーションが含まれることが望ま

しい[b)，c)，d)，e)及びh)]。

− <b)9)>：運用準備態勢のレビューでは，システム導入後の環境における説明責任遂行の見通しもレビ

ューすることが望ましい[b)，c)，d)，e)及びh)]。

− <c)3)>：移行されたシステム要素のトレーサビリティの維持では，システム要素に関する説明責任の

トレーサビリティも維持されることが望ましい[b)，c)，d)，e)，h)及びi)]。

C 62853：2020 (IEC 62853：2018)

<6.4.11>妥当性確認プロセス

− 次の事項に関する経緯が，[i)]における十分な情報としての使用に向けて記録されることが望ましい。

・ <a)1)>：妥当性確認範囲の識別及びそれに対応する妥当性確認措置

・ <b)>：妥当性確認の実施

・ <c)1)>：正常と異常の弁別に用いる基準の確立

・ <c)3)>：システム又はシステム要素は利害関係者ニーズを満たしている，とする利害関係者合意の

確保

・ <c)5)>：ベースラインに含める主要情報項目の選択

− <b)3)及びc)3)>：システム又はシステム要素は利害関係者ニーズを満たしている，と確認することに

は主要な意思決定が伴う[a)]。成果[b)，c)，d)，e)及びh)]とともに考慮されることが望ましい。

− <b)3)>：妥当性確認結果のレビューでは，説明責任遂行の見通しも検討することが望ましい[b)，c)，

d)，e)及びh)]。

− <c)4)>：妥当性確認されたシステム要素のトレーサビリティの維持では，説明責任のトレーサビリテ

ィも維持されることが望ましい[b)，c)，d)，e)，h)及びi)]。

<6.4.12>運用プロセスは説明責任遂行の中核にある[f)，g)，h)及びi)]。

− 次の事項には主要な意思決定が伴う[a)]。これらは成果[b)，c)，d)，e)及びh)]とともに考慮されること

が望ましい。

・ <a)1)>：運用戦略の定義

・ <a)2)>：システム要求事項，アーキテクチャ，又は設計に組み込まれるべき，運用の都合から生じ

るシステム制約の識別

・ <a)3)>：運用の支援に必要なイネーブリングシステム又はサービスの識別及び計画

・ <a)6)>：教育訓練を受けた有資格要員の運用者としての配属

・ <b)3)>：システム運用中監視の対象とするデータ項目の定義

・ <b)5)>：必要に応じた不測事態対応運用の実施又は不実施の判断

− 次の事項に関する経緯が，[i)]における十分な情報としての使用に向けて記録されることが望ましい。

・ <b)4)>：サービス性能パラメタの許容範囲の定義

・ <c)1)及びc)2)>：異常，運用上のインシデント及び問題の弁別に用いる基準の確立

・ <c)4)>：ベースラインに含める主要情報項目の選択

・ <d)3)>：提供されたシステムサービスが顧客のニーズをどの程度満たしているかの判定

− <a)1)>：運用戦略は，システム運用の監視に関する説明責任及び顧客支援に関する説明責任の割当て

を明確にすることが望ましい[b)，c)，d)，e)，f)，g)，h)及びi)]。

− <a)3)>：運用のためのイネーブリングシステムの識別には，システムとイネーブリングシステムとの

間の説明責任境界の識別が含まれることが望ましい[b)，c)，d)，e)及びh)]。

− <a)6)>：運用者の教育訓練及び資格認定には，説明責任に対する意識に関する啓もう（蒙）及び認定

が含まれる[h)]。

− <b)3)>：システム運用の監視では，意思決定の結果について，予期されたものも予期されなかったも

のも，システム全体にわたって広く検出対象とすることが望ましい[f)]。監視は，フィードバックルー
プの一部を形成することが望ましい[g)]。監視は，異常又は障害の発生時に，説明責任を負う利害関係

者の識別及び説明責任情報の提供を迅速にできるようにすることが望ましい[h)及びi)]。監視動作と合

C 62853：2020 (IEC 62853：2018)

意事項違反との間のトレーサビリティ[6.3.2]は，<6.4.5 d)3)，6.4.7 c)2)，6.4.8 c)2)，6.4.9 c)4)，6.4.10 c)3)

及び6.4.13 d)4)>を通じて維持される説明責任のトレーサビリティの連鎖によって確立されることが
望ましい。

− <b)4)>：運用上の異常を合意，利害関係者要求事項及び組織の制約との関連において識別し，分析し，

記録するには，システム分析プロセスを用いることが望ましい[h)及びi)]。

− <b)5)>：不測事態対応運用は，説明責任を負う利害関係者による是正措置の開始[h)]及び説明責任情報

の適時提供[i)3)]を含むことが望ましい。

− <c)2)>：運用上のインシデント及び問題の事態解決に至るまでの追跡では，説明責任を負う利害関係

者及びその者らが取った行動まで追跡がなされることが望ましい[h)及びi)]。

− <c)3)>：運用要素のトレーサビリティの維持では，運用要素に関する説明責任のトレーサビリティも

維持されることが望ましい[b)，c)，d)，e)，h)及びi)]。

− <d)1)及びd)2)>：顧客支援は，信頼できる情報を次の時機で迅速に提供することが望ましい。

・要請があったとき[i)1)及びi)2)]

・障害発生時[i)3)]

・変化発生時[i)4)]

・実際のパフォーマンスと要求などとの間にそご（齟齬）が見つかったとき[i)5)]

− <d)3)>：顧客満足度の判定は，フィードバックループの一部として実施されることが望ましい。利害

関係者の満足度の監視は，説明責任の達成度の監視と併せてなされることが望ましい[f)及びg)]。

<6.4.13>保守プロセス

− 次の事項には主要な意思決定が伴う[a)]。これらは成果[b)，c)，d)，e)及びh)]とともに考慮されること

が望ましい。

・ <a)1)>：保守戦略の定義

・ <a)2)>：保守の都合から生じるシステム制約の識別

・ <b)1)>：事後保守，適応保守，完全化保守及び予防保守の将来的ニーズの識別

・ <b)5)>：予防保守の実施又は不実施の判断

・ <b)6)>：障害の識別

・ <b)7)>：適応保守及び完全化保守のニーズの識別

・ <c)5)>：ロジスティクス作業の中に，適切に計画され資源配分され実施された支援性要求事項が含

まれていることの確認

・ <d)3)>：インシデント，問題，並びに保守及びロジスティクス作業の傾向の識別

− 次の事項に関する経緯が，[i)]における十分な情報としての使用に向けて記録されることが望ましい。

・ <a)3)>：システム，保守活動及びロジスティクス作業の間の適切なトレードオフ関係の識別

・ <d)1)及びd)2)>：異常，運用上のインシデント及び問題の弁別に用いる基準の確立

・ <d)6)>：システム及び保守支援に対する顧客満足度の判定

・ <d)5)>：ベースラインに含める主要情報項目の選択

− <a)2)>：保守の都合から生じるシステム制約は，フィードバックの一部としてシステム要求事項，ア

ーキテクチャ又は設計に組み込まれることが望ましい[g)]。

− <b)1)>：インシデント及び問題のレビューを今後の保守ニーズの識別のために実施する際は，成果[b)，

c)，d)，e)及びh)]の達成度合いも併せてレビューすることが望ましい。

C 62853：2020 (IEC 62853：2018)

− <b)2)及びd)2)>：保守インシデント及び運用インシデントの事態解決に至るまでの追跡では，説明責

任を負う利害関係者及びその者らが取った行動まで追跡されることが望ましい[h)及びi)]。

− <d)4)>：保守要素のトレーサビリティの維持では，保守要素に関する説明責任のトレーサビリティも

維持されることが望ましい[b)，c)，d)，e)，h)及びi)]。

− <d)6)>：顧客満足度の判定は，フィードバックループの一部として実施されることが望ましい。利害

関係者の満足度の監視は，説明責任の達成度の監視と併せてなされることが望ましい[f)及びg)]。

<6.4.14>廃棄プロセス

− 次の事項には主要な意思決定が伴う[a)]。これらは成果[b)，c)，d)，e)及びh)]とともに考慮されること

が望ましい。

・ <a)1)>：廃棄戦略の定義

・ <a)2)>：システム要求事項，アーキテクチャ，又は設計に組み込まれるべき，廃棄の都合から生じ

るシステム制約の識別

・ <a)5)>：貯蔵施設，保管場所，検査基準及び保管期間の指定（システムを保管する場合）

・ <a)6)>：次の廃棄済み要素及び素材がサプライチェーンに再び入ることを防ぐ予防手段の定義

− 転用されない方がよいもの

− 回収再生されない方がよいもの

− 再利用されない方がよいもの

・ <b)1)>：撤去準備に向けてシステム又はシステム要素を非活性化する決定

・ <b)3)>：安全性，セキュリティ，プライバシー，環境基準，指令及び法律関連する運用知識のうち，

記録に残すとするものの選択

・ <c)1)>：健康，安全性，セキュリティ及び環境に有害な要因が廃棄後に残存しないことの確認

− <c)3)>：保存するとした情報の選択の経緯が，[i)]における十分な情報としての使用に向けて記録され

ることが望ましい。

− <c)>：廃棄の完了を確定する際には，廃棄されたシステムに関して説明責任の問題が残っていないこ

とを確認することが望ましい[i)]。

6.4

障害対応プロセスビュー

6.4.1

目的

障害対応プロセスビューの目的は，障害に際してもサービス中断及び被害を最小にとどめ，その状況の

下で最も適切なやり方で，可能な限りサービス提供を続けることである。

目的は，次の理解の下に達成されることが望ましい。

防止されずに発生する障害には，次のようなものが考えられる。

− 予見されなかったもの

− 予見されたが，防止を考えるには発生の可能性が余りに低い，又は防止のコストが余りに大きいとみ

なされたもの

− 予見され，対処されたが，予期されなかった事象のために防止されなかったもの

障害を起こす予期外の事象に対して，特定の処方を準備しておくことは不可能である。しかし，包括的

対策をあらかじめ準備し，それらを迅速に実行できるようにしておくことは可能である。包括的対策には，

C 62853：2020 (IEC 62853：2018)

目下の状況で生じた障害に対して特定の対抗手段を素早く編み出し，必要によっては問題の文脈を変えて

考えるような手順を含む。考え得る障害類型に対して，原因を問わずに防御をしておくこともそのような
包括的対策につながる。

人間による介入は，障害対応に主要な役割を果たす。全ての障害を事前に作成された手段で防止又は緩

和することは不可能であるためである。迅速かつ適切な対応に向けて，人間の介入における意思決定及び
決定された措置の実施はコンピュータによって支援されることが望ましい。

障害対応プロセスビューは，システム運用における有害な結果を事後的に管理する手段を準備する。こ

れらの障害後の活動には，識別された障害結果に抗する対策であって，結果識別の時点では何の原因も考

えられないようなものも含まれる。そのような結果への準備は可能だが，それは，そのような結果が現れ
た後に何をすべきかを準備することによってだけ可能である。

障害対応プロセスビューは，フォールト，エラー，故障及びそれらの前兆に対して取られる活動を識別

する。障害対応には，前兆検出に続く障害予防，障害検出時の不測事態対応運用，完全化保守及び予防保
守が含まれる。

目的の達成は，次からなる。

− 障害対応の準備[6.4.2（成果）のa)1)〜a)8)]

− 障害発生時の障害対応の実施[b)1)〜b)8)]

− 障害及び障害対応に関する説明責任遂行[c)1)〜c)4)]

− 障害から得られた経験による対象システムのライフサイクルの改善[d)1)及びd)2)]

目的と成果との間の関係は，B.4に示される。

6.4.2

成果

a) 障害対応が準備されている。

1) サービス継続性の確保のために保護されるべき主要機能が識別されている。

2) 主要機能の保護について，サービスの継続的提供に必要となる保護のゴールが識別されている。

3) 主要機能に影響するフォールト，エラー，故障及びそれらの前兆が識別されている。

注記1 フォールト，エラー，故障及びそれらの前兆には，識別されていないものもある。これ

には，予見されなかったもの及びどの利害関係者にも認識されなかったものが含まれる。

注記2 フォールト，エラー，故障及びそれらの前兆の識別及び検出の対象には，相互作用エラ

ーも含まれる。

4) 識別されたフォールト，エラー，故障及びそれらの前兆について，結果分析及び起こりやすさ分析

が実施されている。

注記3 準備時の分析の前提は，実際に起きた障害に対する対応の前に再確認される。b)2)を参

照。

5) 識別されたフォールト，エラー，故障及びそれらの前兆について，サービスの継続的提供に必要な

処置のゴールが定義され，合意されている。

注記4 ゴールには，被害予防のゴールが含まれる。

6) 識別されたフォールト，エラー，故障及びそれらの前兆に対する処置について，次のいずれの種類

の対応をとるかが選択されている。

監視対象とし，特定の対応処理を設計に組み込んで備える。

C 62853：2020 (IEC 62853：2018)

ii) 監視対象とするが，設計で備えることはしない。

iii) 監視対象とせず，設計で備えることもしない。

注記5 “設計で備える”とは，サービス継続を可能にする一連の具体的対応を提供するよう，

システムを設計しておくことを意味する。

7) フォールト，エラー，故障及びそれらの前兆から主要機能を保護する次の対応処理が開発されてい

る。

− a)6)i)に属する障害などに対する特定の対応処理

− a)6)ii)及びa)6)iii)に属する障害などに対するデフォルト対応処理

注記6 特定の対応処理は，結果分析及び起こりやすさ分析の結果に基づいて行われる。対応処

理の実施は，システムによっても，そのライフサイクルに関わる要員によっても行われ
る。

注記7 特定の対応処理には，障害発生後の事後処置が含まれる。

注記8 障害発生後の事後処置に障害が発生することも考慮に入れられる。そのような障害に対

しては，何層にもなった事後処置を用意し，自身に起きる障害に対して再帰的に適用で
きるようにしておくことが可能である。

8) 原因不明の障害からの危害を減らす包括的対策が開発されている。

注記9 包括的対策には，次のものが含まれる。

− フォールトがあるシステム部分の迅速な識別

− 機能不全部分の分離による正常動作部分の保護

− 残存サービスの，利害関係者間で合意された水準での維持

− 障害からの回復

b) 必要があるとき，障害対応が遂行される。

1) フォールト，エラー，故障及びそれらの前兆は，検出される。

2) 実際に起きたフォールト，エラー，故障又はそれらの前兆に対して，原因分析及び結果分析が行わ

れる。

注記10 障害などを検出した後の結果分析は，検出前の準備段階での結果分析の結果を確認又は

修正する。これは，検出前の分析の前提を実際の状況に照らして検分して行われる。

3) 検出されたフォールト，エラー，故障及びそれらの前兆に対する処置のゴールは，実際の状況に照

らして調整される。

4) フォールト，エラー，故障又はそれらの前兆が検出されたとき，a)7)で準備された処理が実施され

る。

− a)6)i)に属する障害などに対しては，特定の対応処理が実施される。

− a)6)ii)及びa)6)iii)に属する障害などに対しては，デフォルト対応処理が実施される。

5) 実際に起きたフォールト，エラー，故障及びそれらの前兆でa)6)ii)及びa)6)iii)に属するものに対し

ては，対応処理が事後的にも考案される。

注記11 a)6)ii)に属する障害などを監視することには，監視されないa)6)iii)に属するものと比べ

て，より迅速に，より詳細なデータとともに，障害などを認識して対応処理を策定する
ことを可能にする効果がある。

6) フォールト，エラー，故障及びそれらの前兆に対する対応処理は，危害を悪化させたり，更なる危

害発生のリスクを増加させたりしない。

C 62853：2020 (IEC 62853：2018)

注記12 危害の緩和措置が新たな危害をもたらす場合もある。そのような措置がもたらす危害に

ついては，介入がない場合に生じたであろう危害よりも小さいものであることが期待さ
れる。

7) 対象システム及び接続先の他システムに対する危害が全体として減じられている。

8) 検出された障害などに対する対応処理のアセスメントが，b)3)で調整されたゴールに照らして行わ

れている。

c) 障害対応に関する説明責任が，説明責任遂行プロセスビューの呼出しを通じて果たされている。

1) 障害による被害に対する補償が，確立された合意に基づいてなされている。

2) システムに対する確信及び信頼が維持されている。

注記13 確信及び信頼は，例えば，各障害対応の後に次のものを広く発信することで維持される。

− 対応処理がそのゴールを達成したこと又は今後達成することを論証するアシュアラ

ンスケース

− 箇条5に求められる，対象システムのライフサイクルに関するディペンダビリティ

ケースを，将来の再発が防止されていることも論証するように改訂したもの

3) 障害対応の経緯に関する情報が，利害関係者及び社会一般に提供されている。この情報には次が含

まれる。

識別の対象としたフォールト，エラー，故障及びそれらの前兆の範囲の正当性

ii) 検出されたフォールト，エラー，故障及びそれらの前兆に対する対応処理についてなされていた

計画の正当性

iii) 検出されたフォールト，エラー，故障又はそれらの前兆に対して行った結果分析の結果

iv) 障害対応の結果及びそのアセスメント

4) 説明責任遂行プロセスビューに対して必要な情報が提供されている。

注記14 破壊的変化は，説明責任を負う利害関係者のいない障害及び対処することが不可能な障

害を引き起こす可能性がある。説明責任遂行プロセスビューに必要な情報を提供するこ

とで，そのような破壊的変化を迅速に認識し，変化対応プロセスビューによる破壊的変
化への対処につなげることが可能になる。

d) 障害対応後，起きた障害の経験に基づいたライフサイクルの改善が，変化対応プロセスビューの呼出

しによってなされている。

1) 改善のゴールが定義され，合意されている。

注記15 改善のゴールには，障害の再発防止，運用戦略の改善，システム目的の改良，障害を識

別するプロセスの改善及びリスク管理プロセスの改善を含む。ゴールの定義には，障害

が実際にもたらした結果を識別する作業が伴う。この作業は，結果分析，危害の評価及
びシステムのサービス価値の評価を通じて行われる。

2) 変化対応プロセスビューに対して必要な情報が提供されている。

6.4.3

プロセス，アクティビティ及びタスク

障害対応プロセスビューは，JIS X 0170:2020が提供する次のプロセス，アクティビティ及びタスクを使

用して実施されることが望ましい。

<6.1.1>取得プロセス

− <c)1)>：取得者と供給者との間の合意は，障害から保護されるべき主要機能及び保護のゴールを識別

C 62853：2020 (IEC 62853：2018)

することが望ましい[a)1)，a)2)及びa)5)]。

− <d)1)>：合意の実施のアセスメントは，<c)1)>で定めた保護のゴール及び障害対応プロセスビューの成

果[b)及びc)]が達成され，アシュアランスがなされていることを確認することが望ましい。

<6.1.2>供給プロセス

− <c)1)>：取得者と供給者との間の合意は，障害から保護されるべき主要機能及び保護のゴールを識別

することが望ましい[a)1)，a)2)及びa)5)]。

− <d)2)>：合意の実施のアセスメントは，<c)1)>で定めた保護のゴール及び障害対応プロセスビューの成

果[b)及びc)]が達成され，アシュアランスがなされていることを確認することが望ましい。

<6.2.1>ライフサイクルモデル管理プロセス

− <a)5)>：このタスクで確立される標準ライフサイクルモデルは，障害対応プロセスビューの全成果が

達成されるようにライフサイクルプロセス間の連関を規定するものであることが望ましい[a)，b)，c)
及びd)]。

<6.2.4>人的資源管理プロセス

− <a)>：識別されるべきスキルには，次のものが含まれる[a)7)，a)8)及びb)]。

・システム目的の理解に必要なスキル

・人的介入による成果達成方法をシステム目的の理解に基づいて考案するために必要なスキル

<6.2.5>品質管理プロセス

− <b)>：品質管理のアセスメントは，それが，[a)3)]で識別したフォールト，エラー，故障及びそれらの

前兆を，[b)及びc)]で予期したとおりに検出及び処置できるかどうかをレビューすることが望ましい。

<6.3.2>プロジェクトアセスメント及び制御プロセス

− <a)>：プロジェクトアセスメント及び制御戦略は，次の支援に[6.2.2a)]で確立した共通理解を反映する

ものであることが望ましい。

・設計で備えなかった障害及び識別できない原因をもつ障害に対する包括的対策の開発[a)8)]

・障害に対する処置のゴールの調整[b)3)]

・設計で備えていなかった障害に対する対応処理の考案[b)5)]

− <c)>：プロジェクト制御は，障害再発をシステムの適応によって防止するために変化対応プロセスビ

ューを取り入れたものであることが望ましい[d)]。

<6.3.4>リスク管理プロセス

− <a)1)，a)2)，b)2)，c)，d)1)，d)2)，d)4)及びe)>：リスクを管理及び評価するためのプロセス及び手順

は，ISO 31000[16]及びIEC 31010[17]に示される。加えて，次が識別されることが望ましい[a)及びb)8)]。

・リスク，リスク管理及びリスク処置についての，コミュニケーション及び相談の手段

・原因不明の障害からの危害軽減の手段

・対象システムからの危害だけでなく接続先の他システムからの危害を軽減する手段

・客観的に明文化された，結果分析及び起こりやすさ分析の結果

・有害事象に関する次のリスト

− 発生し得る有害事象のリスト

− まず発生しないと判断されたが監視対象とする決定がなされた有害事象のリスト

C 62853：2020 (IEC 62853：2018)

− まず発生しないと判断され，監視対象ともしないとする決定がなされた有害事象のリスト

・フォールト，エラー，故障及びそれらの前兆を検出する一連の手段が適切にとられていることを正

当化する客観的な記述

・障害に関わる変化に対してシステムを適応させる手段

<6.4.2>利害関係者ニーズ及び利害関係者要求事項定義プロセス

− <b)2)>：利害関係者ニーズの識別は，障害からの保護のニーズの識別とともになされることが望まし

い[a)1)及びa)2)]。利害関係者ニーズには，対象システム及び接続先の他システムからなる総体に対し
て危害を与えないというニーズを含めることが望ましい[a)8)及びb)7)]。

− <c)1)>：代表的シナリオの分析は，保護されるべき主要機能の識別を助けるようなされることが望ま

しい[a)1)]。これには，障害のリスク分析による障害からの保護のニーズの定義[a)2)]及び対象システ
ムが接続先の他システムに与え得る危害の分析[b)7)]が含まれる。

− <d)2)>：利害関係者要求事項及び機能の識別には，障害から保護されるべき主要機能の指定[a)1)]及び

保護のゴールの指定[a)2)]が含まれる。利害関係者要求事項には，対象システムが，自分自身及び接続

先の他システムからなる総体に対して危害を及ぼさないという要求事項が含まれていることが望まし
い[b)7)]。

− <e)1)>：利害関係者要求事項の全集合の分析には，次の目的を念頭に置いて主要機能の障害のリスク

分析を含めることが望ましい。

・主要機能の保護のゴールの定義[a)2)]

・原因不明の障害に対する包括的対策の検討[a)8)]

・対象システムが接続先の他システムに与え得る危害の検討[b)7)]

この分析によって，主要機能に影響を及ぼすフォールト，エラー，故障及びそれらの前兆並びにそれら

が及ぼす結果が識別されることが望ましい[a)4)及びa)5)]。

− <e)2)>：重大な遂行能力・性能・運用時の実績の測定量には，主要機能の保護[a)2)]の水準の尺度，障

害などに対する処置[a)5)]の水準の尺度が含まれていることが望ましい。

− <f)1)>：利害関係者要求事項に関する合意には，次の各項のリストがあることが望ましい。

・保護されるべき主要機能[a)1)]

・主要機能の保護のゴール[a)2)]

・主要機能に影響を及ぼす障害などに対する処置のゴール[a)5)]

<6.4.3>システム要求事項定義プロセス

− <b)1)>：主要機能の定義には次が含まれることが望ましい。

・障害からの保護のゴール[a)2)]

・相互作用エラーを含む，機能に影響を与えるフォールト，エラー，故障及びそれらの前兆の識別[a)3)]

・識別された障害などに対する処置のゴール[a)5)]

・識別された各障害などに対する処置の分類[a)6)]

− <b)3)>：リスクなどに関連するシステム要求事項を識別する作業は，障害から保護されるべき主要機

能を識別できるようになされることが望ましい[a)1)]。次の事項が識別されることが望ましい。

・主要機能保護に関する要求事項[a)2)]

・関連する障害などに対する処置に関する要求事項[a)5)]

C 62853：2020 (IEC 62853：2018)

・障害対応は障害による危害を悪化させず，更なる危害発生のリスクを増加させないという要求事項

[b)6)]

・検出されるべき障害などの監視に関する要求事項[b)1)]

・対象システムが接続先の他システムに与え得る危害の軽減に関する要求事項[b)7)]

− <b)4)>：このタスクで定義されるシステム要求事項及びその根拠によって，次の事項が明確にされる

ことが望ましい。

・主要機能の保護に関する要求事項[a)2)]，障害などに対する処置に関する要求事項[a)5)]

・上記の要求事項と，その元となった主要機能に関する要求事項との間のトレーサビリティ[c)]

− <c)1)>：システム要求事項の全集合の分析には，次の事項を実現できるよう主要機能に起こり得る障

害の結果分析を含めることが望ましい[a)4)]。

・主要機能保護のゴールの定義[a)2)]，識別された障害などに対する処置のゴールの定義[a)5)]

・原因不明の障害に対する包括的対策の開発[a)8)]

・障害対応による危害の悪化及び更なる危害発生のリスクの増加の回避[b)6)]

・対象システムが接続先の他システムに与え得る危害の軽減[b)8)]。

− <c)2)>：重大な遂行能力・性能・運用時の実績の測定量には，主要機能の保護[a)2)]の水準の尺度，障

害などに対する処置[a)5)]の水準の尺度が含まれていることが望ましい。

− <d)1)>：システム要求事項に関する合意には，次の各項のリストがあることが望ましい。

・保護されるべき主要機能[a)1)]

・主要機能の保護のゴール[a)2)]

・主要機能に影響を及ぼす障害などに対する処置のゴール[a)5)]

− <d)2)>：システム要求事項のトレーサビリティの維持では，障害対応に関する説明責任を遂行できる

よう，監視に関する要求事項と主要機能に関する要求事項との間のトレーサビリティが維持されるこ
とが望ましい[b)1)及びc)]。

<6.4.4>アーキテクチャ定義プロセス

− <a)2)>：識別された利害関係者の関心事は，主要機能保護のゴール[a)2)]，障害などに対する処置のゴ

ール[a)5)]に反映されることが望ましい。この反映は，利害関係者ニーズ及び利害関係者要求事項定義

プロセス，システム要求事項定義プロセス及びアーキテクチャ定義プロセスが反復される中で行われ
る。対象システムの接続先の他システムに対する危害について利害関係者がもつ関心事が識別される
ことが望ましい[b)7)]。

− <c)>：次の事項を取り扱うためのモデル及びビューが開発されることが望ましい。

・障害などに対する処置[a)5)及びa)6)]

・障害などの検出[b)1)]

・障害などに対する特定の対応処理及び包括的対策[a)7)及びa)8)]

障害対応処理と他のシステム機能との間の相互作用も，障害対応処理による危害悪化を避けるよう取り

扱われることが望ましい[b)7)]。

− <c)2)>：アーキテクチャエンティティの識別では，主要機能及びその保護に関連する主要なアーキテ

クチャエンティティが識別されることが望ましい[a)1)及びa)7)]。

− <d)1)>：システム要素の識別では，主要機能保護のための主要なアーキテクチャエンティティに関連

する主要なシステム要素が識別されることが望ましい[a)1)及びa)7)]。

C 62853：2020 (IEC 62853：2018)

− <d)2)及びd)3)>：システム要素同士間のインタフェースを定めるとき，外部エンティティとの間のイ

ンタフェースを定めるとき，及び要求事項をシステム要素に分割して割り当てるときには，相互作用
エラー，相互作用エラーの検出，相互作用エラーに対する特定の対応処理及び包括的対策について考
慮することが望ましい[a)3)，b)1)，a)7)及びa)8)]。障害対応処理と他のシステム機能との間の相互作用
が，障害対応処理による危害悪化を避けるよう考慮されることが望ましい[b)6)]。

− <f)2)>：利害関係者によるアーキテクチャの受入れでは，障害などに対する処置[a)6)]，特定の障害対

応処理[a)7)]，包括的対策[a)8)]，及び検出[b)1)]に関するアーキテクチャも明示的に受け入れられるこ
とが望ましい。

− <f)6)>：アーキテクチャのトレーサビリティの維持では，障害対応に関する説明責任を遂行できるよ

う，次の事項の間を結ぶトレーサビリティが維持されることが望ましい[c)]。

・障害などに対する処置のゴール[a)5)]

・次の事項のアーキテクチャ

− 障害などに対する処置[a)6)]

− 特定の障害対応処理[a)7)]

− 包括的対策[a)8)]

− 障害などの検出[b)1)]

・主要機能保護のゴール[a)2)]

<6.4.5>設計定義プロセス

− <a)2)>：必要な設計特性種別の決定では，原因不明の障害に対する包括的対策に関連する設計特性の

種別が決定されることが望ましい[a)8)]。

− <a)3)>：設計の発展についての原則は，障害対応後の変化対応プロセスビューに関して手引を提供す

るものであることが望ましい[d)]。

− <b)1)>：システム要求事項のシステム要素への割当てでは，主要機能保護に関する要求事項[a)2)]，障

害などに対する処置に関する要求事項[a)5)]の割当てがなされることが望ましい。

− <d)3)>：設計のトレーサビリティの維持では，障害対応に関する説明責任を遂行できるよう，次の事

項の間を結ぶトレーサビリティが維持されることが望ましい[c)]。

・障害などに対する処置[a)6)]，特定の障害対応処理[a)7)]，包括的対策[a)8)]及び障害などの検出[b)1)]

の設計特性

・主要機能保護に関するアーキテクチャエンティティ[a)2)]及び障害などに対する処置のゴール[a)5)]

<6.4.6>システム分析プロセス

− <c)1)>：システム分析の結果のトレーサビリティの維持は，障害対応に関する説明責任遂行を適時に

できるようなされることが望ましい[c)]。

<6.4.7>実装プロセス

− <c)2)>：実装されたシステム要素のトレーサビリティの維持では，障害対応に関する説明責任遂行の

ために，次の各項目から設計特性までを結ぶトレーサビリティが維持されることが望ましい[c)]。

・フォールト，エラー，故障及びそれらの前兆に対する処置のためのシステム要素[a)6)]

・特定の障害対応[a)7)]

・包括的対策[a)8)]

・フォールト，エラー，故障及びそれらの前兆の検出[b)1)]

C 62853：2020 (IEC 62853：2018)

<6.4.8>インテグレーションプロセス

− <a)1)>：組み立てられたインタフェース及び選択されたシステム機能の，正しい運用及び完整性のた

めのチェックポイントには，次が含まれることが望ましい。

・ [a)1)]で識別された保護されるべき主要機能のインタフェース

・主要機能を保護するための機能のインタフェース[a)2)，a)5)，a)7)，b)1)及びb)5)]

・システム要素間の相互作用エラーの点検[a)2)，a)8)及びb)7)]

・障害に対するシステム全体にわたる包括的対策の点検[a)8)，b)6)及びb)7)]

・障害対応が危害を悪化させず，更なる危害発生のリスクを増加させないことの点検[b)6)]

・対象システムが接続先の他システムに与え得る危害の点検[b)8)]

− <b)3)>：インタフェース，選択された機能及び重大な品質特性の点検には，次が含まれる。

・起こり得る相互作用エラーの識別[a)3)，a)7)及びb)7)]

・障害に対する包括的対策の有効性の点検[a)8)]

・障害対応が危害を悪化させず，更なる危害発生のリスクを増加させないことの点検[b)6)]

・対象システムが接続先の他システムに与え得る危害の点検[b)8)]

− <c)2)>：統合されたシステム要素のトレーサビリティの維持は，迅速な障害対応処理[b)]及び障害対応

に関する説明責任の適時な遂行[c)]ができるようになされることが望ましい。

<6.4.9>検証プロセス

− <a)1)>：検証範囲及び検証活動には，主要機能の保護のゴール[a)2)]，障害などに対する処置のゴール

[a)5)]が達成されたことの検証が含まれることが望ましい。

− <c)2)>：運用上のインシデントの記録及び事態解決に至るまでの追跡は，障害対応に関する説明責任

遂行を適時にできるようなされることが望ましい[c)]。

− <c)3)>：システム又はシステム要素が指定の要求事項を満たしていることについての利害関係者間の

合意には，障害などに対する処置のゴールが満たされていることについての合意が含まれることが望
ましい[a)5)]。

− <c)4)>：検証結果のトレーサビリティの維持は，迅速な障害対応処理[b)]及び障害対応に関する説明責

任の適時な遂行[c)]ができるようになされることが望ましい。

<6.4.10>移行プロセス

− <b)5)>：運用者などの教育訓練は，障害に対するデフォルト対応処理及び包括的対策の一環として計

画されることが望ましい[a)7)及びa)8)]。また，教育訓練は，利害関係者のスキルを向上させて，人間
による介入を活用して[b)]の成果を達成できるようにすることが望ましい。

− <b)9)>：運用準備態勢のレビューでは，[a)2)，a)5)，a)8)，b)1)〜b)7)]にあるゴールの達成が実証され

ていることを確認することが望ましい。

− <c)2)>：運用上のインシデントの記録及び事態解決に至るまでの追跡は，障害対応に関する説明責任

遂行を適時にできるようなされることが望ましい[c)]。

− <c)3)>：移行したシステム要素のトレーサビリティの維持は，迅速な障害対応処理[b)]及び障害対応に

関する説明責任の適時な遂行[c)]ができるようになされることが望ましい。

<6.4.11>妥当性確認プロセス

− <a)1)>：妥当性確認の範囲及び妥当性確認作業には，次が含まれることが望ましい。

C 62853：2020 (IEC 62853：2018)

・主要機能の保護の，保護ゴールに照らした妥当性確認[a)2)]

・障害などに対する処置の，処置ゴールに照らした妥当性確認[a)5)]

・原因不明の障害に対する包括的対策の妥当性確認[a)8)，b)1)，b)4)〜b)7)]

− <c)2)>：運用上のインシデントの記録及び事態解決に至るまでの追跡は，障害対応に関する説明責任

遂行を適時にできるようなされることが望ましい[c)]。

− <c)4)>：妥当性が確認されたシステム要素のトレーサビリティの維持は，迅速な障害対応処理[b)]及び

障害対応に関する説明責任の適時な遂行[c)]ができるようになされることが望ましい。

<6.4.12>運用プロセス

− <a)1)>：運用戦略は，[b)]のための次の手順を含むことが望ましい。

・障害などの検出の手順[b)1)]及びそれらの前兆からの障害予測の手順

・ [a)6)i)]及び[a)6)ii)]に属する障害などの監視の手順

・障害などの検出時に人的介入を迅速にする備えを確実なものとする，[b)3)]及び[b)5)]のための手順

− <a)5)>：要員の教育訓練は，[a)8)]における包括的対策の一環として計画されることが望ましい。利害

関係者の能力開発として，システム目的の理解を反映した人間の介入を通して[b)]の成果を達成する

能力が開発されることが望ましい。要員の資格要件には，この能力を含めることが望ましい。

− <b)3)>：システム運用の監視では，[a)6)i)]及び[a)6)ii)]に属するフォールト，エラー，故障及びそれら

の前兆を監視し，検出できるようにしておくことが望ましい[b)1)]。障害などの検出時には，[b)2)〜

b)7)]の成果を達成する運用戦略の手順を実施し，その結果を評価することが望ましい[b)8)]。

− <b)4)>：システムサービス遂行能力・性能・運用時の実績のうち許容できないものを識別する際には，

障害対応のアセスメントの結果も考慮に含めることが望ましい[b)8)]。許容できないものに関しては，

変化対応プロセスビューを呼び出してシステム改善を進めることが望ましい[d)]。

− <b)5)>：システムの緊急事態運用について，サービスの継続的提供に必要な緊急事態運用のゴール及

びその開始条件が，主要機能の保護のゴール[a)2)]，障害などに対する処置のゴール[a)5)]に含まれて

いることが望ましい。

− <c)1)>：運用の結果及び異常の記録は，障害対応に関する説明責任の遂行[c)]及びシステムの改善[d)]

に資するようになされることが望ましい。

− <c)2)>：運用上のインシデント及び問題の，記録及び事態解決に至るまでの追跡は，障害対応に関す

る説明責任の遂行[c)]及びシステムの改善[d)]に資するようになされることが望ましい。

− <c)3)>：運用要素のトレーサビリティの維持は，障害対応に関する説明責任の遂行[c)]及びシステムの

改善[d)]に資するようになされることが望ましい。

− <d)>：顧客支援は，積極的に障害対応に関する情報を提供して説明責任を遂行することが望ましい[c)]。

<6.4.13>保守プロセス

− <a)1)>：保守戦略は，主要機能の保護のゴール[a)2)]，障害などに対する処置のゴール[a)5)及びb)]を反

映したものであることが望ましい。

− <b)1)>：将来の保守ニーズを識別する作業は，障害などの識別及び検出と統合されていることが望ま

しい[a)3)及びb)1)]。

− <b)2)>：保守のインシデント及び問題の，記録及び事態解決に至るまでの追跡は，障害対応に関する

説明責任の遂行[c)]及びシステムの改善[d)]に資するようになされることが望ましい。

− <b)3)及びb)4)>：偶発フォールトに対する是正手順の実装及びその実施による通常運用状態への復帰

は，障害対応プロセスビューに統合されていることが望ましい[a)，b)，c)及びd)]。

C 62853：2020 (IEC 62853：2018)

− <b)5)>：識別された障害などに対する処置のゴールを達成する手段として，予防保守を選択してもよ

い[a)5)及びa)7)]。

− <b)6)>：このタスクでの障害の識別は，成果[b)1)及びb)2)]の達成に向けた活動の一部である。

− <c)>：障害の前兆に対する特定の対応処理は，ロジスティクス支援を含んでいることが望ましい[a)7)

及びb)4)]。

− <d)1)>：保守の結果及びロジスティクスの結果並びに異常の記録は，障害対応に関する説明責任の遂

行[c)]及びシステムの改善[d)]に資するようになされることが望ましい。

− <d)2)>：運用上のインシデント及び問題の，記録及び事態解決に至るまでの追跡は，障害対応に関す

る説明責任の遂行[c)]及びシステムの改善[d)]に資するようになされることが望ましい。

− <d)3)>：インシデント及び問題の傾向の識別は，ライフサイクルの改善を促すように行われることが

望ましい[d)]。

− <d)4)>：保守要素のトレーサビリティの維持は，迅速な障害対応処理[b)]及び障害対応に関する説明責

任の適時な遂行[c)]ができるようになされることが望ましい。

− <d)6)>：顧客満足度の監視は，障害対応のアセスメント[b)8)]及びライフサイクルの改善[d)]と統合さ

れていることが望ましい。

<6.4.14>廃棄プロセス

− <a)1)>：廃棄戦略の定義は，[b)7)]が実現されるようなされることが望ましい。

6.5

変化対応プロセスビュー

6.5.1

目的

変化対応プロセスビューの目的は，要求事項，環境，目標及び／又は目的が変化しても，システムを“目

的にかな（適）っている（fit-for-purpose）”状態に維持することである。

目的は，次の理解の下に達成されることが望ましい。

このプロセスビューは，変化に起因する問題に対して応急以上の中長期的解決策を与えることでサービ

スを継続する能力を維持する。同種の障害の再発を防ぐことに焦点が当てられる。

適応が必要になる変化には多くの種類のものがある。対象システムに接続されている他のシステムは変

化する。技術環境，ビジネス環境及び社会環境の変化は，急速なイノベーションとともにますます頻繁に
なっている。システム，環境などについての前提は常に不完全かつ不確定なものであるが，何であれ予期

外の事象が検出されるときには，前提とした事項に変化が生じている。変化は，明示的に自明なものばか
りではない。定期的レビューなどによって積極的に探究されなければならない場合も往々にしてある。変

化によって求められる適応は，システム自体の適応に限らない。ライフサイクルプロセス群全体を見直し，
必要に応じた適応をしなければならない。システムの側でなく環境の方に影響を及ぼして環境を変えるこ
とも，適応となり得る。

変化対応プロセスビューは，システムを変化に適応させる際のアクティビティをまとめたものであり，

次を含む。

− 変化の検出

− 検出された変化の分析

− サービスが継続されるようにする活動の策定及び実施

C 62853：2020 (IEC 62853：2018)

・必要に応じてサービスを更新する活動を含む。

・障害を生じる変化への適応では，障害の顕在化又は再発を防止するための活動を含む。

変化対応プロセスビューでは，用いる計画を硬直的なものとしないことに注意を払い，計画外の状況で

組織が柔軟性を失わないようにすることが望ましい。

目的の達成は次からなる。

− 変化発生時の適応の実施及びアセスメント[6.5.2（成果）a)〜d)]

− 対象システムのライフサイクルの継続的な改善，及び変化への適応に関する説明責任遂行[e)及びf)]

目的と成果との間の関係は，B.5に示される。

6.5.2

成果

a) 変化は認識され，識別されている。

1) システムの置かれた文脈，前提，リスクなどの変化で，システムの適応を必要とし得るものが識別

されている。

注記1 そのような変化の対象となる事項には，次が含まれる。

− 利害関係者要求事項

− 対象システムに接続されたシステム

− 技術環境，ビジネス環境及び社会環境

− サービスに対して利害関係者がもつ認識

− 合意について利害関係者がもつ理解

注記2 変化は，見て明らかなものばかりとは限らない。定期的レビューなどによって積極的に

変化が探究されることも多い。

2) 障害を含め，予期外の事象が検出されたときは，事象の原因となったシステムの変化及び／又は環

境の変化が識別される。この識別は，障害対応プロセスビューによって引き起こされる場合もある。

注記3 障害を含め，予期外の事象の検出は，変化の検出である。変化は，現実にある事柄に生

じた変化であることもあれば，事実と仮定していた事柄についての理解の変化であるこ
ともある。

3) 破壊的変化は認識され，管理されている。

注記4 破壊的変化は，既存の利害関係者では有意義な適応を施すことが不可能又は実現困難な

変化を指す。必要な適応のコストが，現行の合意で説明責任を負うとされる利害関係者
が事業的に耐え得る限界を超える場合はこれに含まれる。そのような場合の秩序ある管

理は，新しい利害関係者の導入，成績不良な利害関係者の放逐，新たな合意の再構築，
システムの早期廃棄などをもって可能な限り事前に計画しておくことが可能である。

b) システムの適応が準備されている。

1) システムの“目的にかな（適）っている”状態に対して変化が与える影響のアセスメントがなされ，

変化と影響との間の関係が文書化されている。

注記5 アセスメントには原因分析が含まれる。

2) “目的にかな（適）っている”状態を維持する適応のゴールが定義されている。これには次が含ま

れる。

利害関係者に，適応の必要性及び適応に関する選択肢並びに各選択肢がもたらす帰結に関する情

C 62853：2020 (IEC 62853：2018)

報が提供されている。

ii) 利害関係者は，変化した状況下での合意形成の交渉に必要な支援を得ている。

iii) 障害対応プロセスビューによって開始された適応は，障害の再発を防止している。

iv) 適応のゴールが定義されている。

3) 合意形成プロセスビューの呼出しによって，適応のゴールが合意され，更新された合意文書に反映

されている。

注記6 これには，識別された変化にシステムを適応させて応えることとする，という意思決定

が含まれる。

注記7 破壊的変化に対する適応には，特別な注意が払われる。

c) システムの適応が遂行されている。

注記8 適応には技術的適応も非技術的適応もあり得る。ライフサイクルプロセス群全体が見直さ

れ，必要に応じて適応がなされる。適応は，必ずしもシステムそのものに関するものでは
ない。環境に影響を及ぼし，環境を変えることさえ，適応となり得る。適応は，システム
自体の適応に限らない。環境に影響を及ぼして環境を変えることも，適応となり得る。

注記9 適応に関する検討には，適応によって変更されるシステム部分と，されない部分との間の

相互作用エラーの防止が含まれる。

1) 必要な適応のための技術的支援が得られている。

2) 過去の経験から得られた知識が効果的に用いられている。

3) ゴールを実現する適応形質が定義されている。

4) 適応形質が開発される。

5) 既存サービスの中断及び接続先の他システムへの悪影響を最小とするように，適応後のサービスが

展開される。

d) 適応後のシステムは，適応のゴールに照らしてアセスメントされている。

e) ライフサイクルの改善が不断に続けられている。

注記10 継続的な改善が期待されるのは，システムの“目的にかな（適）っている”状態を維持す

るという，ライフサイクルの能力である。これは，より高いシステム性能を追求し続ける
こととは異なる。

適応に関する説明責任が，説明責任遂行プロセスビューの呼出しによって果たされている。

1) システムの置かれた文脈などの変化から適応結果に至るトレーサビリティが維持されている。

2) 利害関係者及び社会一般に，適応の開発経緯及び結果に関する情報が提供されている。

6.5.3

プロセス，アクティビティ及びタスク

変化対応プロセスビューは，JIS X 0170:2020が提供する次のプロセス，アクティビティ及びタスクを使

用して実施されることが望ましい。

<6.1.1>取得プロセス

− <c)1)及びc)4)>：取得者供給者間合意の交渉について，変化した文脈の下での交渉に必要な支援が利

害関係者に提供されることが望ましい[b)2)ii)]。

− <c)2)及びc)5)>：合意の中で変更が必要な点の識別は，適応のゴールに基づいてなされることが望ま

しい。適応のゴールは，更新された合意として表されることが望ましい[b)3)]。

C 62853：2020 (IEC 62853：2018)

− <c)3)>：合意変更の影響の評価結果は，適応ゴールの定義にフィードバックされることが望ましい[b)]。

− <d)1)>：合意実施のアセスメントにおいて，実際の進捗が計画から大きくかい（乖）離していると認

められた場合，システムの適応を必要とし得る変化が生じたものとして識別されることが望ましい
[a)1)]。

<6.1.2>供給プロセス

− <c)1)及びc)4)>：取得者供給者間合意の交渉について，変化した文脈の下での交渉に必要な支援が利

害関係者に提供されることが望ましい[b)2)ii)]。

− <c)2)及びc)5)>：合意の中で変更が必要な点の識別は，適応のゴールに基づいてなされることが望ま

しい。適応のゴールは，更新された合意として表されることが望ましい[b)3)]。

− <c)3)>：合意変更の影響の評価結果は，適応のゴールの定義にフィードバックされることが望ましい

[b)]。

− <d)2)>：合意実施のアセスメントにおいて，実際の進捗が計画から大きくかい（乖）離していると認

められた場合，システムの適応を必要とし得る変化が生じたものとして識別されることが望ましい
[a)1)]。

<6.2.1>ライフサイクルモデル管理プロセス

− <a)5)>：このタスクで確立される標準ライフサイクルモデルは，変化対応プロセスビューの全成果が

達成されるようにライフサイクルプロセス間の連関を規定することが望ましい[a)〜f)]。

− <c)2)>：プロセスの改善には，変化対応の反復の各回から得られた教訓が将来の変化に適用できるよ

うに取り込まれることが望ましい[e)]。

<6.2.2>インフラストラクチャ管理プロセス：プロジェクトのインフラストラクチャ及びインフラストラ

クチャ要求事項の変化は，システムの適応を必要とする可能性のある変更として識別されることが望まし
い[a)]。

<6.2.3>ポートフォリオ管理プロセス

− <a)1)>：潜在的な，新規の又は修正された，能力又はミッションの識別は，変化の識別及びその影響

のアセスメントの一環として実施されることが望ましい[a)1)及びb)1)]。

− <a)2)>：このタスクで新規ビジネスの機会などを優先順位付けし，選択し，確立する際には，対象シ

ステムの“目的にかな（適）っている”状態をアセスメントする際の判断材料及び適応のゴールを定
義する際の判断材料を組織のポートフォリオ内の他のプロジェクトとの関係の面から提供するように
することが望ましい[b)1)及びb)2)]。

− <a)3)>：対象システムに関するプロジェクト，説明責任及び権限の定義は，システム適応のゴールと

整合したものであることが望ましい[b)2)及びb)3)]。

− <a)4)>：このタスクで識別される，プロジェクトに期待される目的，目標及び成果は，システムの“目

的にかな（適）っている”状態のアセスメント及び適応のゴールの定義に，組織のポートフォリオ内
の他のプロジェクトとの関係の面から根拠を与えるものであることが望ましい[b)1)及びb)2)]。

− <a)8)>：定義されたゴールでのシステム適応開始の認可は，組織のポートフォリオ内の他のプロジェ

クトが受ける影響を考慮した上でなされることが望ましい[b)3)及びc)]。

− <b)1)>：プロジェクトの存続可能性の評価は，変化の識別及びシステムの“目的にかな（適）ってい

る”状態のアセスメントの一環として実施されることが望ましい[a)1)及びb)1)]。

− <b)2)>：このタスクでの，対象システムのプロジェクトの継続又は軌道修正のための活動には，シス

C 62853：2020 (IEC 62853：2018)

テム適応を実施するか否かの意思決定及び適応のゴールの定義が含まれる[b)3)及びb)2)]。

<6.2.5>品質管理プロセス

− <a)>：品質管理の計画は，システム目的などが変化するときには品質管理目標も変化することを考慮

してなされることが望ましい[a)〜d)]。

− <b)1)>：品質保証評価結果の収集及び分析は，関係する変化の認識及び識別の一環として実施される

ことが望ましい[a)]。

− <b)2)>：顧客満足度のアセスメントは，システムの“目的にかな（適）っている”状態のアセスメン

トに取り入れられることが望ましい[b)1)]。

− <b)4)>：品質改善状況の監視は，関係する変化の認識及び識別[a)]並びに適応システムのアセスメント

[d)]の一環として実施されることが望ましい。

− <c)1)及びc)2)>：品質管理の是正処置及び予防処置を計画する作業は，適応のゴールを定義する作業

と統合されていることが望ましい[b)2)]。

− <c)3)>：是正処置及び予防処置の監視は，適応後のシステムを適応のゴールに照らしてアセスメント

する際に用いられることが望ましい[d)]。

<6.2.6>知識管理プロセスは，変化対応の反復の各回から得られた教訓の情報を，将来の変化に適用でき

るように維持することが望ましい[c)2)及びe)]。

<6.3.1>プロジェクト計画プロセス

− <a)1)>：プロジェクト目標の識別では，そう識別した理由も与え，変化が起きた際の“目的にかな（適）

っている”状態のアセスメント[b)1)]及び適応ゴールの定義[b)2)]を根拠付けるようにすることが望ま
しい。

− <a)2)>：プロジェクト範囲には，変化対応プロセスビューの全成果を達成するためのアクティビティ

を含めることが望ましい[a)〜f)]。プロジェクト制御活動の計画（<a)2)の注記>）は，プロジェクトの
目標が変化する状況も扱うことが望ましい[a)]。範囲定義の後に範囲内のアクティビティに変化が生

じる場合も考慮し，そのような変化が認識され，識別されるようにしておくことが望ましい[a)]。

− <a)3)>：プロジェクト用に定義するライフサイクルモデルは，変化対応プロセスビューの全成果が達

成されるようにライフサイクルプロセス間の連関を規定するものであることが望ましい[a)〜f)]。

− <b)2)>：各ライフサイクル段階の決定ゲートでの判定に用いる達成基準を定義する際に利用段階を脱

して変化対応プロセスビューを開始する決定ゲートの達成基準を定義することが望ましい[a)]。

− <b)4)>：変化対応プロセスビューのための役割，責務，説明責任及び権限の定義は，変化対応に関す

る説明責任が遂行できるようになされることが望ましい[f)]。

− <b)5)>：プロジェクトに必要なインフラストラクチャ及びサービスを定義する際は，それらに生じる

変化を認識し，識別することが望ましい[a)]。

− <b)7)>：このタスクで行う適応の計画のコミュニケーションは，適応のゴールについての合意形成に

資するものとすることが望ましい[b)3)]。また，適応に関する説明責任の遂行に用いられることが望ま

しい[f)]。

<6.3.2>プロジェクトアセスメント及び制御プロセスは，変化対応プロセスビューを統括し，その全成果

が達成されるようにすることが望ましい[a)〜f)]。特に，このプロセスは，技術目標の変化，要求事項の変

化，及び全体的なビジネス目標の変化に対処することが望ましい。これには，開発者が可能な適応を考案

する際の支援，文脈・前提・リスクなどに生じる変化でシステムの適応が必要となるもの識別，及び各変
化に対する適応に必要となる技術的又は非技術的な手段の識別が含まれる。

C 62853：2020 (IEC 62853：2018)

− <b)>：プロジェクトのアセスメントには，変化の認識及び識別が含まれることが望ましい[a)]。プロジ

ェクトは，システムの“目的にかな（適）っている”状態のアセスメント[b)1)]及び適応のゴールの定
義[b)2)]をするために，プロジェクトの文脈，目標及び計画に変化が生じた可能性を考慮してアセスメ

ントされることが望ましい。

− <b)7)>：このタスクでのマネジメントレビュー，技術レビュー，監査及びインスペクションは，シス

テムの適応に進む必要性及び準備状況を明確にすることが望ましい[a)及びb)]。

− <b)8)>：重要プロセス及び新技術の監視は，変化の認識及び識別の一環として行われることが望まし

い[a)]。

− <b)9)>：測定結果の分析は，変化を識別し，適応のゴールに関する勧告を出すことが望ましい[a)及び

b)2)]。

− <b)11)>：プロジェクトにおけるプロセスの実行の監視で，実際の進捗が計画から大きくかい（乖）離

していると認められた場合，システムの適応を必要とし得る変化が生じたものとして識別されること
が望ましい[a)1)]。

− <c)>：このアクティビティでプロジェクトを制御することには，必要に応じてシステム適応を開始す

ることが含まれる[b)及びc)]。

− <c)1)>：このタスクで開始されるプロジェクト制御のための活動には，適応のゴールを定義すること

が含まれる[b)2)]。

− <c)2)>：このタスクでのプロジェクトの再計画は，合意された適応のゴール及び更新された合意を反

映してなされることが望ましい[b)3)]。

− <c)4)>：プロジェクトをシステム適応に進めることの認可は，定義された適応のゴールの認可ととも

になされることが望ましい[b)3)及びc)]。

<6.3.3>意思決定管理プロセス

− <a)1)及びc)>：意思決定戦略は，文脈，前提条件，リスクなどに生じる変化による意思決定基準の変

化に対処するものであることが望ましい。変化が認識されたとき及び識別されたときには，意思決定
の管理は過去になされた決定をレビューすることが望ましい[b)1)及びb)2)]。

<6.3.4>リスク管理プロセス：リスクを管理及び評価するための手順及びプロセス一般については，ISO

31000[16]及びIEC 31010[17]に示されている。加えて，次が考慮されることが望ましい。

− <a)1)>：リスク管理戦略は，リスク管理の文脈に生じる変化に対処することが望ましい。また，変化

が認識されたとき及び識別されたときに現在のリスク管理策をレビューする手順を含んでいることが
望ましい[a)，b)1)及びb)2)]。

− <a)2)>：リスク管理の文脈及びリスク識別プロセスは，次の事項に生じる変化に伴うリスクを考慮す

ることが望ましい[a)]。

・利害関係者要求事項

・対象システムの接続先の他システム

・技術環境，ビジネス環境及び社会環境

・サービスに対して利害関係者がもつ認識

・合意について利害関係者がもつ理解

− <b)1)>：変化に伴うリスクの受容のしきい（閾）値及び条件は，変化がシステムの“目的にかな（適）

っている”状態に与える影響を反映して定義されることが望ましい[b)1)]。

− <b)3)>：利害関係者へのリスクプロファイルの提供は，適応のゴールに関する交渉及び適応に関する

C 62853：2020 (IEC 62853：2018)

説明責任遂行の一環として実施されることが望ましい[b)2)及びf)2)]。

− <c)1)>：変化に伴うリスクの識別は，変化の認識及び識別の一環として行われることが望ましい[a)1)]。

− <c)2)及びc)3)>：変化に伴うリスクの結果の見積り及びリスクしきい（閾）値に照らしたリスクの評価

は，システムの“目的にかな（適）っている”状態のアセスメントの一環として実施されることが望
ましい[b)1)]。

− <c)4)>：変化に伴うリスクでリスクしきい（閾）値を超えるものについて，推奨するリスク処置の戦略

及び測定量を定義することは，適応のゴール定義の一部であり[b)2)]，実施される適応の定義の一部で
ある[c)3)]。

− <d)1)>：変化に伴うリスクについて推奨するリスク処置の選択肢の識別は，適応のゴール定義の一部

である[b)2)]。

− <d)2)>：変化に伴うリスクについて，リスク処置を行うことが望ましいとした利害関係者の決定は，

更新された利害関係者合意に記録されることが望ましい[b)3)]。変化に伴うリスクに対してリスク処置

を実施することは，[c)3)]で実施されるべき適応を定めること及び[c)4)]でそれを実施することの一部
である。

− <e)1)>：全てのリスク及びリスク管理の文脈について変化が生じていないか継続的に監視すること，

及び変化が起きたときにリスクを再評価することは，変化の認識及び識別[a)1)]及びシステムの“目的
にかな（適）っている”状態のアセスメント[b)1)]の一環として実施されることが望ましい。

− <e)2)>：リスク処置の有効性を評価する測定量は，適応後のシステムをアセスメントできるようにす

るものであることが望ましい[d)]。測定値を監視することは，変化の認識及び識別の一部である[a)]。

<6.3.5>構成管理プロセス

− <b)1)>：このタスクで行われる構成品目の識別は，システム内に生じる変化を認識し識別する上で極

めて重要である[a)]。システム要素のうち，変化するとシステムの適応を必要とし得るものは，構成品
目として識別されることが望ましい。構成品目がブラックボックスコンポーネントであることもある。

− <b)2)>：システム情報の構造の識別は，システムの構造自体が変化し得ることを考慮してなされるこ

とが望ましい[a)及びf)]。システム構造は，システムに内在する不確実性及び不完全性のために意図さ
れずに変化することもあれば，適応によって意図的に変化することもある。

− <b)3)>：構成品目の識別子を確立する際は，次の二つの間にトレーサビリティがあるようにすること

が望ましい[f)]。

・適応のために導入又は変更された構成品目

・その適応が必要となった原因である変化

− <b)4)>：ベースラインの定義は，システム内に生じる変化がライフサイクルを通して認識及び識別さ

れるようになされることが望ましい[a)]。

− <b)5)>：ベースラインを確立するために取得者と供給者との間で結ぶ合意は，将来起きる変化につい

て適応のゴールを定める際に，ゴールをそのベースラインへの更新として定義するように用いられる
ことが望ましい[b)3)]。

− <c)>：構成の変更管理には，次が含まれることが望ましい。

・変更がシステムの“目的にかな（適）っている”状態に与える影響の分析[b)1)]

・考え得る適応の選択肢に関する情報の，関係する利害関係者への提供[b)2)i)]

・適応のゴールについて交渉し合意する際の，利害関係者に対する支援[b)2)ii)及びb)3)]

− <c)4)>：承認された変更の追跡及び管理は，適応に関する説明責任遂行を支援するようになされるこ

C 62853：2020 (IEC 62853：2018)

とが望ましい[f)]。特定の適応を行うに至った理由は，将来の適応に用いる教訓として記録されること

が望ましい[c)2)]。

− <d)>：構成状態に関する説明責任遂行では，構成品目のトレーサビリティが，品目を変更するに至っ

た理由と併せて維持されることが望ましい[f)]。

− <e)2)>：製品構成の検証は，システムの不確定性及び不完全性のために意図せずシステム内に生じた

変化の認識及び識別を支援することが望ましい[a)]。

− <f)1)>：システムリリースの承認は，リリースの方法がシステムの既存サービスの中断及び接続先の

他システムへの悪影響を最小限に抑えるものであることを確認した上でなされることが望ましい
[c)5)]。

<6.3.6>情報管理プロセスは，次の目的を念頭に実施されることが望ましい。

− 変化し得る事項について過去及び現在の情報を利用可能にすることによる，変化の認識及び識別[a)]

− 考え得る適応の選択肢に関する情報の利害関係者への提供[b)2)i)]

− 過去の適応開発の経験から得られた情報の提供[c)2)]

− 適応に関して利害関係者に対して負う説明責任の遂行[f)]

<6.3.7>測定プロセス

− <a)3)>：情報ニーズの識別は，変化の認識及び識別[a)]及びシステムの“目的にかな（適）っている”

状態のアセスメント[b)1)]ができるようになされることが望ましい。

− <b)4)>：測定結果は，変化の重要性について利害関係者に判断材料を与えるものであることが望まし

い[a)及びb)]。

<6.3.8>品質保証プロセス

− <b)>：製品及びサービスの評価は，適応後のシステムの適応のゴールに照らしたアセスメントの一環

として行われることが望ましい[d)]。

− <c)1)>：プロジェクトライフサイクルプロセスの評価は，ライフサイクルの継続的改善ができるよう

になされることが望ましい[e)]。

− <e)>：インシデント及び問題を処置した後は，システムの適応を必要とし得る変更がないかどうかを

検討することが望ましい[a)2)]。

<6.4.1>ビジネス又はミッション分析プロセス

− <a)〜e)>：ビジネス又はミッション分析プロセスは，[a)及びb)]の達成に必要なときにはいつでも適用

されることが望ましい（<6.4.1.1の注記2>を参照）。適用開始の条件には次が含まれる。

・運用プロセス又は保守プロセスで変化が検出されたとき

・障害対応プロセスビューで障害対応後にライフサイクル改善のゴールを定義するとき

・このプロセスへの入力に生じた変化が識別されたとき

注記1 ビジネス又はミッション分析プロセスへの入力で変化する可能性のあるものには，組織の

戦略，その中で識別された問題及び機会，組織のゴール及び目標，使用予定のイネーブリ
ングシステム又はサービスが含まれる[a)1)の注記1]。

ビジネス又はミッション分析プロセスの結果には，システムの適応を開始するかどうかについての利害

関係者間の明示的合意及び考え得る適応のゴールの選択肢が含まれる[b)2)及びb)3)]。

− <a)1)>：組織の戦略には，問題及び機会のレビューが定期的になされるようにする引き金が定義され

C 62853：2020 (IEC 62853：2018)

ていることが望ましい[a)]。このレビューは，変化の認識，特に組織に何らかの事象が生じたときの変

化の認識のために行われる。

− <b)及びc)>：問題又は機会の範囲を表す空間の定義及びソリューション空間の特徴付けは，変化がシ

ステムの“目的にかな（適）っている”状態に与える影響の分析を基礎付けるものであることが望ま
しい。また，考え得る適応のゴールに取り込まれることが望ましい[b)1)及びb)2)]。

− <d)>：候補ソリューション類型の評価は，システム適応を開始するかどうかの意思決定[b)3)]及び考え

得る適応のゴールの選択肢の定義[b)2)]をする際の判断材料を提供するようなされることが望ましい。

− <e)1)>：ビジネス又はミッション分析のトレーサビリティの維持では，このプロセスが再適用される

原因となった変化の前に行われた分析の結果と，変化の後に行われた分析の結果との間のトレーサビ
リティが維持されることが望ましい[d)，e)及びf)]。これは，分析の結果と分析に続くライフサイクル

段階での成果物との間のトレーサビリティを維持することに加えて行われる。

<6.4.2>利害関係者ニーズ及び利害関係者要求事項定義プロセス

− <a)〜f)>：利害関係者ニーズ及び利害関係者要求事項定義プロセスは，必要なときにはいつでも適用

されることが望ましい。適用開始の条件は，ビジネス又はミッション分析プロセスと同じである。

注記2 利害関係者ニーズ及び利害関係者要求事項定義プロセスへの入力で変化する可能性のある

ものには，ビジネス又はミッション分析プロセスからの出力，識別された利害関係者のリ
スト，利害関係者のニーズ，代表的シナリオを定義する際に前提とされた環境が含まれる。

− <a)1)>：利害関係者の識別は，破壊的変化の管理を支援するようになされることが望ましい[a)3)]。破

壊的変化では，既存の利害関係者リストの変更が必要となり得る。

− <a)2)>：利害関係者ニーズ及び要求事項の定義戦略には，識別された利害関係者に生じる変化並びに

定義された利害関係者ニーズ及び要求事項に生じる変化を認識するためのレビューの計画が含まれる
ことが望ましい。このようなレビューは，定期的に，また，必要なときにはいつでも，開始されるこ
とが望ましい[a)]。

− <b)及びc)>：利害関係者ニーズ及び根拠の定義（<b)>）並びに運用概念及びその他のライフサイクル

概念の開発（<c)>）は，その出力が将来の変化発生時には次の活動の基盤となることを考慮して行わ

れることが望ましい。

・変化がシステムの“目的にかな（適）っている”状態に与える影響の分析[b)1)]

・システム適応に進むかどうかの意思決定[b)3)]

・適応のゴールに関する定義及び合意[b)2)及びb)3)]

利害関係者ニーズの定義及びそう定義した理由は，得られた教訓として将来の適応に役立つように記録

されることが望ましい[c)2)]。

− <e)2)>：重大な遂行能力・性能・運用時の実績の測定量には，適応のアセスメントを支援する測定量が

含まれていることが望ましい[d)]。

− <e)4)及びf)1)>：適応のゴール及びそれに関する合意は，利害関係者要求事項の定義及び利害関係者要

求事項に関する明示的合意に対する更新として表されることが望ましい[b)3)]。

− <f)2)>：利害関係者ニーズ及び利害関係者要求事項のトレーサビリティの維持では，適応前の利害関

係者ニーズ及び利害関係者要求事項と適応後のそれとの間のトレーサビリティも維持されることが望
ましい[f)1)]。

<6.4.3>システム要求事項定義プロセス

− <a)〜d)>：システム要求事項定義プロセスは，必要なときにはいつでも適用されることが望ましい。

C 62853：2020 (IEC 62853：2018)

適用開始の条件は，ビジネス又はミッション分析プロセスと同じである。

注記3 システム要求事項定義プロセスへの入力で変化する可能性のあるものには，利害関係者要

求事項，利用の文脈及び運用シナリオ，環境の振る舞い，実装上の制約が含まれる。

− <a)1)，a)2)，b)及びc)>：機能境界の定義（<a)1)>），システム要求事項定義の戦略（<a)2)>），システ

ム要求事項（<b)>）及びシステム要求事項の分析（<c)>）は，次の事項の支援に適した出力をするよ

うに実施されることが望ましい。

・将来の変化がシステムの“目的にかな（適）っている”状態に与える影響の分析[b)1)]

・適応のゴールの定義[b)2)]

− <b)2)>：実装上の制約に生じる変化が，潜在的変化を認識する活動の一環としてプロジェクトアセス

メント及び制御プロセスで監視されていることが望ましい[a)]。

− <b)3)>：リスクに関連するシステム要求事項の識別では，変化に伴うリスクに関連するものを識別す

ることが望ましい[a)及びb)1)]。

− <b)4)>：適応のゴールは，システム要求事項及び根拠の定義に対する更新として表されることが望ま

しい[b)2)]。この更新は，対象システムの接続先の他システムを含む環境に生じた変化を反映するもの

である。要求事項の定義を理由付ける根拠は，システムの“目的にかな（適）っている”状態のアセ
スメントを支援すること[b)1)]及び将来の適応を助ける教訓とすること[c)2)]を念頭に記録されること

が望ましい。

− <c)1)>：適応のゴールは，適応前のシステム要求事項の全集合と併せて，次の観点から分析されるこ

とが望ましい。

・適応がもたらし得る，対象システムの既存サービスの中断及び接続先の他システムへの悪影響の可

能性[c)5)]

・障害再発防止についての，適応の有効性[b)3)]

− <c)2)>：重大な遂行能力・性能・運用時の実績の測定量には，適応後のシステムを適応のゴールに照ら

してアセスメントできるようにする測定量が含まれていることが望ましい[d)]。

− <c)3)>：分析された要求事項を関係する利害関係者にフィードバックすることは，次の目的を念頭に

なされることが望ましい。

・利害関係者とのコミュニケーション[b)2)i)]

・交渉に当たる利害関係者の支援[b)2)ii)]

・適応に関する説明責任の遂行[f)]

− <d)1)>：適応のゴールへの合意は，システム要求事項に関する明示的合意に対する更新として表され

ることが望ましい[b)3)]。

− <d)2)>：システム要求事項のトレーサビリティの維持では，適応前のシステム要求事項と適応後のシ

ステム要求事項との間のトレーサビリティも維持されることが望ましい[f)1)]。

<6.4.4>アーキテクチャ定義プロセスは，変化に応える適応形質を開発する[c)4)]。

− <a)〜f)>：アーキテクチャ定義プロセスは，必要なときにはいつでも適用されることが望ましい。適用

開始の条件は，ビジネス又はミッション分析プロセスと同じである。

注記4 アーキテクチャ定義プロセスへの入力で変化する可能性のあるものには，システム要求事

項，市場環境，規制及び法的制約，ミッション又はビジネスの運用概念，技術ロードマッ

プ，利害関係者の関心事，接続されたシステムのインタフェース，及びその他システムの
適切さにライフサイクルを通じて影響を与える要因の全てが含まれる。

C 62853：2020 (IEC 62853：2018)

− <a)1)，a)2)，b)及びc)>：次の事項は，将来の変化がシステムの“目的にかな（適）っている”状態に

与える影響の分析の支援に適した出力をするように実施されることが望ましい[b)1)]。

・ <a)1)>でのアーキテクチャを駆動する重要事項の識別

・ <a)2)>での利害関係者の関心事の識別

・ <b)>でのアーキテクチャビューポイントの開発

・ <c)>での候補となるアーキテクチャのモデルの開発

− <a)4)，b)，c)及びe)>：次の出力は，適応のゴールの定義及びそれに対する合意をするのに適したもの

であることが望ましい[b)2)及びb)3)]。

・ <a)4)>で定義されるアーキテクチャ評価基準

・ <b)>で開発されるアーキテクチャビューポイント

・ <c)>で開発される候補となるアーキテクチャのモデル

・ <e)>でのアーキテクチャ候補のアセスメントの結果

<6.4.5>設計定義プロセスは，変化に応える適応形質を開発する[c)4)]。

− <a)〜d)>：設計定義プロセスは，必要なときにはいつでも適用されることが望ましい。適用開始の条

件は，ビジネス又はミッション分析プロセスと同じである。

注記5 設計定義プロセスへの入力で変化する可能性のあるものには，アーキテクチャ定義プロセ

スの結果，利用可能な技術，利害関係者の関心事，システム要素の陳腐化の予測，外部エ
ンティティとのインタフェース，及び利用可能な非開発項目が含まれる。

− <a)1)，a)2)及びc)>：次の事項は，将来の変化がシステムの“目的にかな（適）っている”状態に与え

る影響の分析の支援に適した出力をするように実施されることが望ましい[b)1)]。

・要求される技術の決定（<a)1)>）

・必要な設計特性の種別の決定（<a)2)>）

・システム要素を得るための代替案のアセスメント（<c)>）

− <b)及びc)>：次の出力は，適応のゴールの定義及びそれに対する合意をするのに適したものであるこ

とが望ましい[b)2)及びb)3)]。

・ <b)>で確立される設計特性及び設計実現手段

・ <c)>でなされるシステム要素を得るための代替案のアセスメントの結果

<6.4.6>システム分析プロセスは，システムの“目的にかな（適）っている”状態のアセスメント[b)1)]及

び適応後のシステムの適応のゴールに照らしたアセスメント[d)]に用いられることが望ましい。

<6.4.7>実装プロセスは，変化に応える適応形質を実装する[c)4)]。実装プロセスが開始されるのは，変化

が起きた後に設計定義プロセスで設計が更新されたとき，及び障害発生後に障害対応プロセスビューで実
装上のエラーが識別されたときである。

<6.4.8>インテグレーションプロセスは，変化に応える適応形質を実現する[c)4)]。インテグレーションプ

ロセスが開始されるのは，変化が起きた後にシステム要素の実装が更新されたとき，及び障害発生後に障
害対応プロセスビューでインテグレーションエラーが識別されたときである。

<6.4.9>検証プロセスは，次の活動に用いられることが望ましい。

− 適応後のシステムの適応のゴールに照らした評価[d)]

− 変化を認識し，識別するために行われるレビュー[a)]（このレビューは，プロジェクトアセスメント及

C 62853：2020 (IEC 62853：2018)

び制御プロセスにおいて，定期的に，また，必要なときにはいつでも行われるものである。）

<6.4.10>移行プロセスは，次の事項を行う。

− 適応後のサービス又はシステムの展開[c)5)]

− 適応後のシステムの適応のゴールに照らしたアセスメント[d)]

− 適応に関する運用前時点での説明責任の遂行[f)]

これには，次の事項が含まれる。

− 責任を負う者又は組織の識別

− 運用中の既存サービスの中断及び接続先の他システムへの悪影響を最小限に抑えた，修正サービスの

展開

移行プロセスが開始されるのは，変化が起きた後に適応後のシステムが再統合されたとき，及び運用サ

イト他の環境に変化が生じたためにシステムの再導入が必要になったときである。

<6.4.11>妥当性確認プロセスは，次の活動に用いられることが望ましい。

− 適応後のシステムの適応のゴールに照らした評価[d)]

− 変化を認識し識別するために行われるレビュー[a)]（このレビューは，プロジェクトアセスメント及び

制御プロセスにおいて，定期的に，また，必要なときにはいつでも行われるものである。）

<6.4.12>運用プロセスは，次の事項が確実になされるように，システム運用及び環境を監視する。

− システムの適応を必要とし得る変化の認識及び識別[a)]

− 適切なプロセスの適用による適応の開始[b)，c)，d)及びe)]

このプロセスは，説明責任遂行プロセスビューを適用して適応に関する説明責任を果たす[f)]。

<6.4.13>保守プロセスは，変化対応プロセスビューを統括することについてプロジェクトアセスメント

及び制御プロセスを補助する。ただし，保守プロセスが関わるのは，システム設計が安定しており，かつ，
起きる変化を概して予測可能な場合である。

− 次の事項は，変更の認識及び識別の一環として実施されることが望ましい[a)]。

・ <a)2)>：保守の都合から生じるシステム制約の識別

・ <b)1)>：将来の保守ニーズを識別するための，インシデント及び問題の報告のレビュー

・ <b)6)>：不適合が検出されたときに障害を識別する作業

・ <b)7)>：適応保守又は完全化保守がいつ必要になるかの識別

・ <d)1)>：保守及びロジスティクスの結果における，正常と異常の弁別

・ <d)3)>：インシデント，問題，保守活動及びロジスティクス活動の傾向の識別

・ <d)6)>：システム及び保守支援に対する顧客満足度の監視

− 次の事項は，適応の準備の一環として実施されることが望ましい[b)]。

・ <a)2)>：保守の都合から生じるシステム制約の識別

・ <a)3)>：システム，保守及びロジスティクス作業の間のトレードオフ関係の識別

・ <b)1)>：将来の保守ニーズを識別するための，インシデント及び問題の報告のレビュー

・ <d)3)>：インシデント，問題，並びに保守及びロジスティクス作業の傾向の識別

− <b)2)及びd)2)>：保守上の問題及び運用上の問題は，適切なプロセスを適用して解決することが望ま

C 62853：2020 (IEC 62853：2018)

しい[b)，c)，d)及びe)]。

<6.4.14>廃棄プロセス

− <b)3)>：運用知識の記録は，将来の変化対応[c)2)]及びライフサイクルの改善[e)]に用いられるようにす

ることが望ましい。

− <c)1)>：廃止するシステム要素の廃棄後に行う健康に有害な要因などが存在しないことの確認は，適

応に関する説明責任遂行の一部とすることが望ましい[f)]。

− <c)3)>：システムの存続期間を通じて収集された保管情報は，適応に関する説明責任遂行で提供され

る情報の一部とすることが望ましい[f)]。また，将来の変化対応に用いられるように記録することが望

ましい[c)2)]。

C 62853：2020 (IEC 62853：2018)

附属書A

（参考）

オープンシステムディペンダビリティをもつライフサイクルモデルの例

A.1 概要

この規格は，四つのライフサイクルプロセスビューを規定しているが，これらのプロセスビューを使用

するライフサイクルモデルは規定していない。この附属書は，参考になる二つのライフサイクルモデル例，
DEOSライフサイクルモデル及びWCMライフサイクルモデルを示す。

この附属書では，山括弧（< >）はJIS X 0170:2020のプロセスの細分箇条への参照を表す。

A.2 オープンシステムのディペンダブルエンジニアリング（Dependable Engineering for Open Systems，

DEOS）ライフサイクルモデル

DEOSライフサイクルモデル（参考文献[11]ではDEOSプロセスと呼ばれる。）は，次のような利害関係

者の種類を考慮する。

− サービス又は製品の利用者（社会基盤となるシステムの場合は，社会全体）

− サービス又は製品の提供者

− サービス又は製品の認証者（認可者）

− 次を含むシステム提供者

・設計者及び開発者

・保守担当者

・ハードウェア提供者

DEOSライフサイクルモデルは，[11]では“サイクル”と呼ばれる，二つの反復的な作業フローで編成さ

れている（図A.1参照）。二つのサイクルは，変化対応サイクル（外側のループ）及び障害対応サイクル

（内側のループ）である。各サイクルは，そのプロセスビューに必要な作業フロー及び／又は順序を指定
することによって，同名のプロセスビューを実装する。また，この二つのサイクルは，変化対応及び障害

対応のそれぞれに関して，合意形成及び説明責任遂行プロセスビューの一部も実装する。両サイクルは，
通常運用段階から開始される。

a) 変化対応サイクルは，システムの目的，目標，環境又は実際のパフォーマンスの変化に応じてシステ

ムが修正されようとするときに開始される。合意形成段階，開発段階，及び説明責任遂行段階から構
成される。

b) 障害対応サイクルは，障害が生じたとき又は予測されたときに開始される。障害対応段階及び説明責

任遂行段階から構成される。

c) 変化対応サイクルは，障害対応サイクルから開始され得る。これは，障害原因が分析された後に，シ

ステムを修正する必要性があると認められた場合に行われる。

d) 合意記述データベースには，ディペンダビリティケース及びスクリプト（プログラム）が格納される。

このスクリプトは，システムの監視，障害対応及び説明責任遂行を現行のディペンダビリティケース
に基づいて自動化するものである。ディペンダビリティケース及びスクリプトは，システム運用に利

用される。システム運用は開発プロセスに統合されている。ディペンダビリティケースは継続的に更

C 62853：2020 (IEC 62853：2018)

新される。

障害対応サイクル

変化対応サイクル

6.4.8

インテグレー

ション

6.4.7

実装

6.4.4

アーキテク

チャ定義

6.4.5

設計定義

6.4.1

ビジネス

又はミッ
ション分

析

合意形成

開発

障
害
対
応

合意記述
データベース

目標/ 環境

変化

異常検知/

故障

説明責任遂行

原因究明
迅速対応
未然回避

6.4.2 利害関

係者ニーズ

及び利害関
係者要求事

項定義

6.4.3

システム要求

事項定義

6.1 合意

...

6.4.9

検証

6.4.10

移行

6.4.11

妥当性確認

...

通常運用

説
明
責
任
遂
行

6.4.12 運用
6.4.13 保守

6.3.7 測定

6.3.8 品質保証

...

6.3.2 プロジェクトア
セスメント及び制御

6.4.12 運用

...

6.3.6 情報管理

...

6.4.13 保守

6.3.4リスク管理

6.3.3 意思決定管理
6.3.4 リスク管理
6.3.5 構成管理
6.3.6 情報管理

図A.1−DEOSライフサイクルモデル（出典：参考文献[11]，一部変更）

DEOSライフサイクルモデルには五つの段階がある。次に，この規格のプロセスビューの成果及び各段

階に最も関連するJIS X 0170:2020のライフサイクルプロセスを示す。

− 合意形成段階には次が含まれる。

・合意形成プロセスビュー（6.2.2 a)及びb)）

・説明責任遂行プロセスビューの冒頭部分（6.3.2 a)〜e)及びg)）

・障害対応プロセスビューの冒頭部分（6.4.2 a)1)及びa)2)），及び障害後の合意再形成（6.4.2 d)）

・変化対応プロセスビューの冒頭部分（6.5.2 a)及びb)）

関連するライフサイクルプロセスには，<6.1.1>取得プロセス，<6.1.2>供給プロセス，<6.4.1>ビジネ

ス又はミッション分析プロセス，<6.4.2>利害関係者ニーズ及び利害関係者要求事項定義プロセス，及

び<6.4.3>システム要求事項定義プロセスが含まれる。

注記1 JIS X 0170:2020のライフサイクルプロセスは，システムに対して並行的に，反復的に，及

び再帰的に適用され，また，そのシステム要素に対して段階的に適用される（<1.3>及び

<5.7>を参照）。これは，特にオープンシステムにとって核心的な点である。オープンシス

テムは継続的に更新され，変更されるものであるため，システムの利用開始後に，上記プ
ロセスは何度も繰り返される。

− 開発段階には次が含まれる。

・なされる決定がより詳細なものになりその結果が判明してくる中での，説明責任の維持及び監視

C 62853：2020 (IEC 62853：2018)

（6.3.2全て）

・障害対応の開発（6.4.2 a)3)〜a)8)）

・適応の開発及びアセスメント（6.5.2 c)及びd)）

関連するライフサイクルプロセスには，<6.4.4>アーキテクチャ定義プロセス，<6.4.5>設計定義プロ

セス，<6.4.7>実装プロセス，<6.4.8>インテグレーションプロセス，<6.4.9>検証プロセス，<6.4.10>移
行プロセス及び<6.4.11>妥当性確認プロセスが含まれる。

− 説明責任遂行段階には次が含まれる。

・障害対応及び変化に対する適応に関する情報を含めて，必要な情報の収集（6.3.2 f)及びg)，6.4.2 c)

並びに6.5.2 f)）

・説明責任を負う利害関係者に課された，責任説明を負わない利害関係者に合意された救済措置を提

供する義務の履行（6.3.2 e)及びh)）

・利害関係者及び社会一般への，説明責任情報の提供（6.3.2 i)）

関連するライフサイクルプロセスには，<6.3.6>情報管理プロセスが含まれる。

− 通常運用段階には次が含まれる。

・障害の検出（6.4.2 b)1)）

・変化の検出（6.5.2 a)）

・説明責任遂行のための監視（6.3.2 f)）

関連するライフサイクルプロセスには，<6.4.12>運用プロセス，<6.4.13>保守プロセス，<6.3.7>測定

プロセス，<6.3.8>品質保証プロセスが含まれる。

− 障害対応段階には次が包含される。

・検出された障害に対する即時対応（6.4.2b)）

・説明責任遂行及び継続的な改善のための，障害情報の提供（6.4.2 c)及びd)2)）

関連するライフサイクルプロセスには，<6.3.2>プロジェクトアセスメント及び制御プロセス，

<6.3.4>リスク管理プロセス，<6.4.12>運用プロセス，及び<6.4.13>保守プロセスが含まれる。

注記2 上記は簡略な列記であって，網羅的ではない。各段階は，その段階に明示的に関連付けられて

はいないプロセスビューの成果にも影響を与える。また，プロセスビューの各成果の達成は，
その成果に明示的に関連付けられてはいない段階のパフォーマンスにも依存する。

DEOSライフサイクルモデルの具体例のこの規格の規定に対する適合性は，ディペンダビリティケース

によって確立されることが可能である。ここで必要になるディペンダビリティケースは，箇条6に規定さ

れる四つのプロセスビューが，図A.1の一連の関連プロセス，アクティビティ及びタスクによって実装さ
れていることを実証するものである。

A.3 ワランティチェーンマネジメント（Warranty Chain Management，WCM）ライフサイクルモデル

ワランティチェーンマネジメント（以下，WCMという。）は，周期的なビジネスプロセスのマネジメン

トである。サイクルの1ラウンドは，製品に障害が発生したときに始まり，全てのフィードバックデータ

の分析及び根本原因分析（Root Cause Analysis，RCA）を経て，期待を満たす改訂版の製品を顧客に提供し，
次のラウンドに向けて再始動する。WCMで考慮される事象には，障害に加えて，製品使用現場で又はラ

ウンド開始前の開発段階で生じる他の事象も含まれる。これは，オープンシステムは継続的に更新され変
更されるものであるためである。WCMには，事前の能動的活動も含まれる。この活動は，将来の障害を

C 62853：2020 (IEC 62853：2018)

軽減することを意図してなされる。

WCMの対象となるライフサイクルプロセスは，顧客サービス，障害分析，エンジニアリング及びサプ

ライチェーンの四つのグループに分類される。

顧客サービスは，製品保守サービスの継続的運用である。顧客からのクレームを受理し，顧客に修理サ

ービスを提供し，更なる分析のために製品使用現場の情報を記録する。障害分析プロセスは，製品使用現
場の情報を監視し，根本原因及び是正措置の識別を管理する。エンジニアリングプロセスは，製品の技術

上の管理を担う。これには，製品開発，製造技術及びポートフォリオ管理が含まれる。サプライチェーン
は，調達，製造及び流通を担い，製品の生産及び顧客への納入に責任をもつ。

WCMは四つのライフサイクルプロセスをシューハートデミングの円Plan-Do-Study-Actによって結び

つける。

顧客サービス

<6.4.13> 保守プロセス
<6.1.1> 取得プロセス
<6.1.2> 供給プロセス
<6.3.6> 情報管理プロセス

障害分析

<6.1.1> 取得プロセス
<6.4.13> 保守プロセス

エンジニアリング

<6.3> テクニカルマネジメント
<6.4> テクニカルプロセス
<6.2.3> ポートフォリオ管理

サプライチェーン

<6.4.8> インテグレーションプロセス
<6.4.12> 運用プロセス

サプライチェーン

ワランティチェーン

顧客

(顧客満足)

ク
レ
ー

ム

修

理

図A.2−WCMライフサイクルモデル

顧客サービス（クレーム−修理の内側のサイクル）は，障害対応プロセスビュー及び説明責任遂行プロ

セスビューのうち直接顧客と向かい合う部分を表す（6.4.2 b)，6.4.2 c)，6.3.2 h)及び6.3.2 i)）。障害分析は，

変化対応プロセスビューの最初の部分に対応する。これは，予期されなかった障害として現れる変化が検
出され，分析され，是正措置が識別される部分である（6.5.2 a)2)及びb)）。エンジニアリングは，適応を開
発する（6.5.2 c)4)）。サプライチェーンは，新しく適応したサービスを展開する（6.5.2 c)5)）とともに新サ

ービスについて供給者と顧客との間で合意形成プロセスビューを実現する（6.2.2）。同様に，他のプロセス
ビュー成果と対応関係をつける先となる部分がこのライフサイクルモデルの中に見出せる。

WCMライフサイクルモデルの具体例のこの規格の規定に対する適合性は，ディペンダビリティケース

によって確立されることが可能である。ここで必要になるディペンダビリティケースは，箇条6に規定さ
れた四つのプロセスビューが，図A.2の一連の関連プロセス，アクティビティ及びタスクによって実装さ

れていることを実証するものである。

C 62853：2020 (IEC 62853：2018)

附属書B

（参考）

ディペンダビリティケースのテンプレート例

B.1

概要

箇条5では，オープンシステムディペンダビリティの達成を主張するディペンダビリティケースが提供

されることが望ましいとされている。この附属書は，そのようなディペンダビリティケースのテンプレー
ト議論構造を例示する。議論構造は，ゴール構造記法（Goal Structuring Notation，GSN[18]）で示される。

注記この附属書の幾つかの図にある破線の枠線のゴールは，別の図で更に展開されるゴールを示す。

プロセスビューの各成果は，テンプレート構造内のゴールである。分解されていないゴール（葉ゴール）

は全て成果である。成果に階層構造がある場合，上位階層にある成果は分解される中間ゴールとなる。中

間ゴールではあるが上位の成果ではないものは，その下にある一連のゴールがどのような意義をもつもの
としてまとめられたのかを示す。ストラテジーは，ゴールを図示されたように分解する理由を示す。

対象とするライフサイクルを与えられたとして，そのライフサイクルに関する議論の具体例を構築する

には，各ゴールを更に分解し，発展させて具体化し，得られた各葉ゴールについてエビデンス（ソリュー
ション）をそろえるようにする。ゴール及びストラテジーの記述は，目下の状況において適切かつ十分な

ものであるか精査されることが望ましい。また，議論構造は必要に応じて修正され，増強されることが望
ましい。ここで示すテンプレート例にはコンテキストノード及びエビデンスのテンプレートが含まれてい
ないが，それらも必要に応じて追加する必要がある。

最上位のゴール“絶え間なく変化し続けるシステムにおいて，サービス継続性及び説明責任が達成され

る”は，この規格が規定する四つのプロセスビューに従って分解される。ゴールを分解するとは，一連の
サブゴールを識別することを意味する。この一連のサブゴールは，その全てが達成されたことからゴール
が達成されたことが推論されるというものである。図B.1を参照。

絶え間なく変化し続けるシステムにおいて，

サービス継続性及び説明責任が達成されている。

4つのプロセスビューと

対象に特定の要求事項とへの分解

変化対応
プロセス
ビューが
達成され

ている。

障害対応
プロセス
ビューが
達成され

ている。

説明責任遂行
プロセスビュ
ーが達成され

ている。

合意形成
プロセス
ビューが
達成され

ている。

対象に特定の

要求事項が達

成されている。

図B.1−全体の議論

B.2

合意形成の議論

ゴール“合意形成プロセスビューが達成される”は，このプロセスビューの目的が満たされることを意

味する。したがって，6.2.1の第1段落に従って，次の言明に展開される。

C 62853：2020 (IEC 62853：2018)

システム，システムの目的，目標，環境，実際のパフォーマンス，ライフサイクル，及びそれらの変化

に関する共通理解及び明示的合意が確立され，維持されている。

合意形成の議論は，理解及び合意の確立と，その維持とに分解される（図B.2参照）。確立は，準備[6.2.2

a)1)，a)2)及びa)4)]，確立されるべき内容[a)3)及びa)5)]，及び結果のアセスメント[a)6)及びa)7)]の観点か
ら示される（図B.3参照）。維持のゴールは，維持に必要な活動に関連するもの[b)1)，b)2)及びb)3)]及び維

持活動とディペンダビリティケースの保守との間の関連を確保するもの[b)4)及びb)5)]の二つのグループ
に分解される（図B.4参照）。

合意形成プロセスビューが達成されている。

合意の確立とその維持とへの分解

a)利害関係者間の共通理解及び
明示的合意が確立されている。

b)利害関係者間の共通理解及び
明示的合意が維持されている。

目的の言明に従った展開

システム，システムの目的，目標，環境，実際のパフォーマンス，
ライフサイクル，及びそれらの変化に関する共通理解及び明示
的合意が確立され維持されている。

図B.2−合意形成 1

a)利害関係者間の共通理解及び
明示的合意が確立されている。

a)5)明示的合意
が3)の理解に基
づいて作られ，文
書化されている。
文書中の記録に
は，合意形成の
経緯説明及びな
ぜ合意事項は適
切かつ実現可能
と考えられるのか
の理由づけが含
まれる。

a)7)以上の成果
は，全利害関係
者に対して公正
かつ衡平な方法
で達成されてい
る。

a)2)全ての利害
関係者に理解さ
れた準拠枠が
確立されている。
準拠枠には，語
彙及びシステム
の環境に関する
基本的仮定が
含まれる。

a)3)システムの
目的，目標，環境，
実際のパフォー
マンス，ライフサ
イクル及びそれら
の変化は，準拠
枠の中で各利害
関係者によって
同様に理解され
る。これには，シ
ステムに関する
仮定及び利害関
係者の責務につ
いての理解が含
まれる。

a)4)利益相反を解決できるよう，合意
を得られない場合の仲裁手続きが事
前に合意されている。

a)1)システムの
利害関係者が
識別されている。

システムに特有の合意が
確立されている。

共通理解と明示的合意

とへの分解

合意形成の基礎が
準備されている。

合意がアセスメントされている。

準備，確立及びアセスメントにわたる議論

定義されるべき

項目による分解

曖昧さのアセスメントと

公正性及び注意深さと

への分解

a)6)合意文書
の解釈の差異
は，許容範囲
に収まってい
る。

図B.3−合意形成 2

C 62853：2020 (IEC 62853：2018)

b)利害関係者間の共通理解及び明示的合意が維持されている。

b)3)事業目標，
利害関係者の
ニーズ，システム
又は環境の変化
に際して，合意
達成のプロセス
が見直される。

b)5)合意達成の事実，
その進展の経緯，及び
なぜ合意が適切かつ実
現可能であると考えられ
るのかの理由づけが
ディペンダビリティケー
スに記録されている。

必要な活動による分解

b)2)事業目標，
利害関係者の
ニーズ，システム
又は環境の変化
に際して，利害関
係者間の合意状
態は維持される。

b)1)合意の
変更管理の
方針が確立
されている。

b)4)ディペンダビリ
ティケースの構築
及び承認に関する
責任が定められて
いる。

事業目標，利害関係者のニーズ，システム又は環境
が変化するときには，維持活動が実施されている。

維持活動がディペンダビリティケース
によって説明されている。

実施と説明とへの分解

図B.4−合意形成 3

B.3

説明責任遂行の議論

ゴール“説明責任遂行プロセスビューが達成される”は，このプロセスビューの目的，すなわち，6.3.1

の第1段落に従って，次の言明に展開される。

明示的合意事項に対する違反及び違反の結果として利害関係者及び社会一般にもたらされる帰結との間

の対応関係が確立されている。これには，説明責任を負う利害関係者に被害の救済措置提供を義務付け，
もって合意実現の公算を増し，システムに関する確信及び信頼を保ち，潜在的被害に対して救済措置を確
保しておくことが含まれる。

このゴールは，二つの観点から示される。一つは説明責任が求められる事象発生前の準備の観点であり，

もう一つは，監視を含め，事象発生時に実際に責任を果たす実施の観点である（図B.5参照）。準備は，合

意違反とその帰結との間にあるべき関係を定めるものであるが，これはそのために必要な要素を識別し，
定義することに帰着する[6.3.2a)〜e)]（図B.6参照）。実施のゴールは二つのグループに分けられる。一つ

はシステム内部で達成されるべきゴールからなり[f)〜h)]（図B.7参照），もう一つは外部との関係におい
て得られるゴールからなる[i)，i)1)，i)2)，i)3)，i)4)及びi)5)]（図B.8参照）。

図B.5−説明責任遂行 1

説明責任遂行プロセスビューが達成されている。

目的の言明に従った展開

明示的合意事項に対する違反及び違反の結果として利害関係者及び社会一般にもた
らされる帰結との間の対応関係が確立されている。これには，説明責任を負う利害関
係者に被害の救済措置提供を義務づけ，もって合意実現の公算を増し，システムに関
する確信及び信頼を保ち，潜在的被害に対して救済措置を確保しておくことが含まれる。

準備と実施とへの分解

説明責任遂行が準備されている。

説明責任遂行が実施されている。

C 62853：2020 (IEC 62853：2018)

a)主要意思決定
事項が識別され
ている。主要意思
決定事項は，ライ
フサイクル及びラ
イフサイクルにお
けるリスクを制御
する決定事項で
あり，プロセス及
びプロセスビュー
の成果を制御す
る決定事項を含
む。

b)ライフサイクル
及びライフサイク
ルにおけるリスク
を制御する各主
要意思決定事項
について，説明責
任を負う者又は
組織が識別され
ている。

e)各明示的合意
に対する各違反
について，説明責
任を負う利害関
係者にもたらされ
る帰結並びに説
明責任を負わな
い利害関係者及
び社会一般に対
する救済措置が
合意されている。

d)各明示的合意
に対する各違反
について，説明責
任を負わない利
害関係者及び社
会一般に対する
影響のアセスメン
トが行われている。

c)各明示的合意
の各事項につい
て，失敗又は違
反の原因となりう
る主要意思決定
事項はどれかが
識別されている。

定義されるべき項目による分解

説明責任遂行が準備されている。

図B.6−説明責任遂行 2

説明責任遂行が実施されている。

システム内部及び外部のゴールへの分解

説明責任遂行のシステム内ゴールが達成されている。

説明責任遂行のシステム外
ゴールが達成されている。

f)意思決定での決定から
生じた結果が，予期され
たものも予期されなかっ
たものも幅広くシステム全
体にわたって監視され，ア
セスメントされている。こ
れには，合意事項違反の
監視も含まれる。

システム内で行われる活動毎の分解

g)とられた決定及び措置
から生じた結果を意思決
定者及び他の利害関係
者に知らせるフィードバッ
クループが確立している。

h)合意事項違反があった
場合，違反について説明
責任を負う利害関係者は，
説明責任を負わない利害
関係者及び社会一般に
対し，遅滞なく救済を提供
する。

（言明の精密化）

i)十分かつ的確な情報が，
説明責任を負う利害関係
者から，説明責任を負わ
ない利害関係者及び社会
一般に対して遅滞なく提
供される。

図B.7−説明責任遂行 3

C 62853：2020 (IEC 62853：2018)

i)十分かつ的確な情報が，説明責任を負う利害関係者から，説明責任
を負わない利害関係者及び社会一般に対して遅滞なく提供される。

情報のタイミング及び性質による分解

i)2)システムに関し
て提供された情報に
ついて，利害関係者
は正当な確信及び信
頼を持つ。

i)4)次の変化に関す
る情報が選定され，
対象システムの利害
関係者，接続先の他
システムの利害関係
者及び公衆に対し提
供される。対象とす
る変化は，システム
要求事項の変化，シ
ステムへの期待の変
化，システム記述の
変化及びシステム性
能の変化である。

i)1)利害関係者から
のシステムに関する
正当な情報請求には，
速やかに適正かつ
十分な返答が与えら
れる。

i)3)障害発生後には，
十分かつ的確な情報
が選定され，対象シ
ステムの利害関係者，
接続先の他システム
の利害関係者及び
公衆に対し提供され
る。

i)5)次のそご（齟齬）
に関する情報が，見
つかり次第選定され，
対象システムの利害
関係者，接続先の他
システムの利害関係
者及び公衆に対し提
供される。対象とす
るそご（齟齬）は，シ
ステムに関する要求
事項，期待，記述及
び性能の間のそご
（齟齬）である。

図B.8−説明責任遂行 4

B.4

障害対応の議論

ゴール“障害対応プロセスビューが達成される”は，このプロセスビューの目的，すなわち，6.4.1の第

1段落に従って，次の言明に展開される。

障害に際してもサービス中断及び被害を最小にとどめ，その状況の下で最も適切なやり方で，可能な限

りサービス提供が続けられている。

このゴールは，障害による直近の危害を軽減するゴールと障害による長期的な危害を軽減するゴールと

に分解される（図B.9参照）。直近の危害軽減は，障害事象発生前の準備[6.4.2 a)]及び障害発生時の実施[b)]

の観点から示される。準備は，障害対応処理のゴール設定及びゴールを達成する対応処理の開発で構成さ
れる。障害対応処理のゴール設定には，保護対象の識別，障害原因の識別及び処置のゴールの定義が含ま
れる[a)1)〜a)5)]（図B.10参照）。障害対応処理の開発では，障害原因が識別されたものである場合とそう

でない場合との両方を考慮する。前者の場合の開発では，識別された各障害原因について，特定の対応処
理が必要になるものか又は包括的対策で十分なものかの判別がなされ，その結果に応じて開発が進む[a)6)
及びa)7)]（図B.11参照）。障害原因が識別されたものでない場合については，包括的対策が開発される

[a)8)]。障害対応の実施のゴールは，対応処理が実際実施されるというゴールと対応処理のアセスメントに

関するゴールとに分解される。対応処理の実施は，障害検出，分析，対応処理の目下の状況に応じた調整，
及び実際の実施の点から示される[b)1)〜b)5)]。対応処理のアセスメントのゴールでは，プロセスビューの
目的に照らしての一般的なアセスメント[b)6)及びb)7)]及び準備で設定されたゴールに照らしての特定の

アセスメント[b)8)]が考慮される（図B.12参照）。障害からの長期的な危害を軽減するというゴールは，二
つのゴールに分かれる（図B.9参照）。一つは，システムに対する公共の確信及び信頼の維持[c)]であり，

これは説明責任遂行のインスタンスである。もう一つは，ライフサイクルの継続的改善[d)]であり，これは
変化対応のインスタンスである。確信及び信頼の維持は，6.3.1の第4段落で説明されたようにプロセスビ

ューの目的のために必要であり，障害事象発生後の説明責任のゴールからなる[c)1)〜c)4)]（図B.13参照）。

継続的改善のためのゴールは，障害の再発防止を含む改善目標の定義及び変化対応プロセスビューの適切
な呼出しから構成される[d)1)及びd)2)]（図B.14参照）。

C 62853：2020 (IEC 62853：2018)

障害に際してもサービス中断及び被害を最小にとどめ，その状況の下で最も適切なやり方で，

可能な限りサービス提供が続けられている。

a)障害対応が
準備されている。

c)障害対応に関する
説明責任が，説明責
任遂行プロセスビュー
の呼び出しを通じて果
たされている。

d)障害対応後，起きた
障害の経験に基づい
たシステムライフサイ
クルの改善が，変化対
応プロセスビューの呼
び出しによってなされ
ている。

説明と再発防止とへの分解

障害前の準備と

障害後の実施とへの分解

直近のゴールと長期的ゴールとへの分解

障害による直近の危害は軽減されている。

障害による長期的な危害は軽減されている

（システムへの公衆の信頼及び継続的改善が

維持されている）。

b)必要があるとき，
障害対応が遂行さ
れる。

目的の言明に従った展開

障害対応プロセスビューが達成されている。

図B.9−障害対応 1

a)障害対応が準備されている。

a)2)主要機能
の保護につい
て，サービス
の継続的提供
に必要となる
保護のゴール
が識別されて
いる。

a)3)主要機能
に影響する
フォールト，エ
ラー，故障及
びそれらの前
兆が識別され
ている。

ゴール定義と対応処理開発とへの分解

a)4)識別され
たフォールト，
エラー，故障
及びそれらの
前兆について，
結果分析及
び起こりやす
さ分析が実施
されている。

a)1)サービス
継続性の確
保のために
保護されるべ
き主要機能
が識別されて
いる。

a)5)識別され
たフォールト，
エラー，故障
及びそれらの
前兆について，
サービスの継
続的提供に
必要な処置
のゴールが
定義され，合
意されている。

定義されたゴールを達成する障害
対応処理が開発されている。

定義されるべき項目による分解

障害原因の識別可能性による分解

識別された原
因を持つ障害
への対応処理
が開発されて
いる。

a)8)原因不明
の障害からの
危害を減らす
包括的対策が
開発されてい
る。

障害対応のゴールが定義されている。

図B.10−障害対応 2

C 62853：2020 (IEC 62853：2018)

a)7)フォールト，エラー，故障
及びそれらの前兆から主要機
能を保護する以下の対応処理
が開発されている。
‒

a)6)i)に属する障害などに
対する特定の対応処理

‒

a)6)ii)又はa)6)iii)に属する
障害などに対するデフォル
ト対応処理

障害等に対してとりうる対応の種類
a)6)i)監視対象とし，特定の対応処理
を設計に組み込んで備える。
a)6)ii)監視対象とするが，設計で備
えることはしない。
a)6)iii)監視対象とせず，設計で備え
ることもしない。

a)6)識別されたフォールト，
エラー，故障及びそれらの
前兆に対する処置につい
て，いずれの種類の対応
をとるかが選択されている。

必要な活動による分解

識別された原因を持つ障害への対応処理が開発されている。

図B.11−障害対応 3

b)必要があるとき，障害対応が遂行される。

実施とアセスメントとへの分解

b)7)対象
システム及
び接続先
の他シス
テムに対
する危害
が全体とし
て減じられ
ている。

b)4)フォールト，エラー，故障
又はそれらの前兆が検出され
たとき，a)7)で準備された処理
が実施される。
‒a)6)i)に属する障害などに

対しては，特定の対応処理
が実施される。

‒a)6)ii)及びa)6)iii)に属する

障害などに対しては，デフォ
ルト対応処理が実施される。

b)5)実際に起きた
フォールト，エラー，
故障及びそれらの
前兆でa)6)ii)及び
a)6)iii)に属するも
のに対しては，対
応処理が事後的
にも考案される。

b3)検出された
フォールト，エラー，
故障及びそれらの
前兆に対する処置
のゴールは，実際
の状況に照らして
調整される。

b)8)検出さ
れた障害
などに対
する対応
処理のア
セスメント
が，b)3)で
調整され
たゴール
に照らして
行われて
いる。

障害発生時時に障害対応が遂行される。

検知，分析，調整及び実施への分解

(言明の精密化)

障害対応は
一般的な要
求事項を満
たす。

b)2)実際に起きた
フォールト，エラー，
故障又はそれら
の前兆について，
原因分析と結果
分析が行われる。

障害など
に対する
対応処理
が，実情
に照らし
て調整又
は考案さ
れる。

障害などに
対する調整
された対応
処理が実施
される。

b)6)フォールト，
エラー，故障及
びそれらの前兆
に対する対応処
理は，危害を悪
化させたり，さら
なる危害発生の
リスクを増加さ
せたりしない。

b)1)フォールト，
エラー，故障及
びそれらの前兆
は，検出される。

図B.12−障害対応 4

C 62853：2020 (IEC 62853：2018)

c)障害対応に関する説明責任が，説明責任遂行
プロセスビューの呼び出しを通じて果たされている。

障害後の説明責任遂行のゴールへの分解

c)4)説明責任遂行
プロセスビューに対
して必要な情報が提
供されている。

c)1)障害による被害
に対する補償が，確
立された合意に基づ
いてなされている。

c)2)システムに対する
確信及び信頼が維持
されている。

c)3)障害対応の経緯
に関する情報が，利害
関係者及び社会一般
に提供されている。

図B.13−障害対応 5

d)障害対応後，起きた障害の経験に基づいたシステムライフサイクルの
改善が，変化対応プロセスビューの呼び出しによってなされている。

必要な活動による分解

d)1)改善のゴールが定義され，
合意されている。

d)2)変化対応プロセスビューに対して
必要な情報が提供されている。

図B.14−障害対応 6

B.5

変化対応の議論

ゴール“変化対応プロセスビューが達成される”は，6.5.1に示されるこのプロセスビューの目的の第1

段落に従って，次の言明に展開される。

要求事項，環境，目標及び／又は目的が変化しても，システムは“目的にかな（適）っている（fit-for-

purpose）”状態に維持されている。

このゴールは，システムを変化に適応させるという直接的なゴールと，より長期的なゴールとに分解さ

れる。長期的なゴールは，ライフサイクルの継続的改善の持続とシステムに対する一般の確信及び信頼の
維持という二つの部分からなる。直接的なゴールは，変化の識別[6.5.2 a)]，適応の準備[b)]，適応の実施[c)]
及びアセスメント[d)]の観点から示される（図B.15参照）。変化の識別のゴールは，監視すべき変化の種類

を特定してサブゴールに分割される[a)1)〜a)3)]（図B.16参照）。適応の準備のゴールは，必要な行動が取
られるという観点から示される[b)1)〜b)3)]（図B.17参照）。適応の実施のゴールは，必要な支援が得られ

るかの観点[c)1)及びc)2)]及び適応に必要な活動が行われるかの観点[c)3)〜c)5)]から示される（図B.18参

照）。長期的なゴールの部分の一つ，継続的改善のゴールは，このテンプレートでは未開発のまま置かれて

いるが，具体的なライフサイクルモデルを文脈として用いて発展させる必要がある。その際は，反復され
る変化対応プロセスビュー実施の各回が，将来の改善に向けた持続的効果をいかに集積していくか詳しく

示すことが望ましい。長期的なゴールのもう一つの部分，システムに対する公共の確信及び信頼の維持は，
説明責任遂行の適応に関するインスタンスである[f)]。説明責任遂行プロセスビューに必要な入力がそろう

こと及び同ビューで適応に関する説明責任が果たされることから示される[f)1)及びf)2)]（図B.15参照）。

C 62853：2020 (IEC 62853：2018)

要求事項，環境，目標及び／又は目的が変化しても，システムは

“目的にかな（適）っている(fit-for-purpose)”状態に維持されている。

必要な活動（初期識別，準備，実施

及びアセスメント）による分解

d)適応後の
システムは，
適応の目的
に照らして
アセスメント
されている。

e)ライフサイクル
の改善が不断に
続けられている。

f)適応に関する説明責任が，
説明責任遂行プロセスビュー
の呼び出しによって果たされ
ている。

a)変化は
認識され，
識別され
ている。

b)システムの
適応が準備
されている。

c)システムの
適応が遂行さ
れている。

直接のゴールと長期的ゴールとへの分解

システムの置かれた文脈などに適応を必要としうる変化
が識別されたとき，システムの適応が実施されている。

システムへの継続的改善及び
公共の確信が維持されている。

目的の言明に従った展開

変化対応プロセスビューが達成されている。

f)1)システムの置かれた
文脈などの変化から適
応結果に至るトレーサビ
リティが維持されている。

f)2)利害関係者及び社会
一般に，適応の開発経緯
及び結果に関する情報が
提供されている。

図B.15−変化対応 1

変化の種類による分解

a)1)システムの置かれた
文脈，前提，リスクなどの
変化で，システムの適応
を必要としうるものが識別
されている。

a)2)障害を含め，予期外の事象が
検出されたときは，事象の原因と
なったシステムの変化及び／又は
環境の変化が識別される。この識
別は，障害対応プロセスビューに
よって引き起こされる場合もある。

a)3)破壊的変化は
認識され，管理され
ている。

a)変化は認識され，識別されている。

図B.16−変化対応 2

C 62853：2020 (IEC 62853：2018)

必要な活動による分解

b)システムの適応が準備されている。

b)1)システムの“目的にかな
（適）っている”状態に対して変
化が与える影響のアセスメント
がなされ，変化と影響との間
の関係が文書化されている。

b)2)“目的にかな（適）ってい
る”状態を維持する適応の
ゴールが定義されている。こ
れには以下が含まれる。

必要な活動による分解

b)2)i)利害関係者に，
適応の必要性及び適
応に関する選択肢並
びに各選択肢がもたら
す帰結に関する情報
が提供されている。

b)2)ii)利害関係者は，
変化した状況下での合
意形成の交渉に必要
な支援を得ている。

b)3)合意形成プロセスビュー
の呼び出しによって，適応の
ゴールが合意され，更新された
合意文書に反映されている。

b)2)iv)適応のゴール
が定義されている。

b)2)iii)障害対応プロセ
スビューによって開始さ
れた適応は，障害の再
発を防止している。

図B.17−変化対応 3

必要な活動による分解

c)システムの適応が遂行されている。

c)1)必要な適応
のための技術
的支援が得ら
れている。

c)4)適応
形質が
開発され
る。

c)5)既存サービスの中断及び
接続先の他システムへの悪
影響を最小とするように，適
応後のサービスが展開される。

c)3)ゴールを
実現する適応
形質が定義さ
れている。

c)2)過去の経験
から得られた知
識が効果的に
用いられている。

支援と実施とへの分解

適応が支援される。

支援を受けて適応が実施される。

図B.18−変化対応 4

C 62853：2020 (IEC 62853：2018)

附属書C
（参考）

スマートグリッド

C.1 概要

この附属書は，オープンシステムの一例として“スマートグリッド”を挙げ，オープンシステムディペ

ンダビリティがいかに達成され得るかについて説明する。A.2に示したDEOSライフサイクルモデルを説

明の基盤として採る。C.3では，箇条5を満たすためのスマートグリッドのディペンダビリティケース構
築を例示する。C.4では，スマートグリッドのDEOSライフサイクルの変化対応サイクルについて説明す

る。これは6.5の変化対応プロセスビューを実装する部分である。C.5では，障害対応サイクルについて説
明する。6.4の障害対応プロセスビューを実装する部分である。この二つのサイクルは，また，6.3の説明

責任遂行プロセスビュー及び6.2の合意形成プロセスビューを，スマートグリッドの適応及びその障害対
応それぞれに関して実装する。この例は，デンマークの電力網システムに基づく。

C.2 背景

現代社会では，安定した信頼性の高い電力供給が決定的に重要である。さらに，省エネルギー対策及び

風力タービン，太陽電池などの再生可能電源は，電力網の運用及び管理を複雑化している。電力網の最も

重要な要求事項は，ディペンダビリティ（アベイラビリティ並びにその要因たる信頼性，保守性及び支援
性）及び安全性である。

欧州連合（EU）では，送配電システムの所有権は，発電及び小売売買から分離されている。小売業者は，

発電業者から購入した電力を供給するために，送配電業者に送配電システムの利用料金を支払う。幾つか
の大きな石炭火力発電所及び原子力発電所とともに，現在，地域熱供給及び電力販売を行う小さな発電所

が数多くある。電力の消費者は，多くの場合に，風力タービン又は太陽電池による電力の生産者でもある。
電力需要及び供給の昼夜での変化によって，電力価格を時々刻々と変化させられる。そのため，スマート

グリッドの概念が導入された。これには，消費者ごとの電気メーターが含まれており，グリッドのオペレ
ーターはそれを遠隔で読み取ることが可能である。同時に，消費者は，現在の市場価格に依存して時々刻々
と変化する電力料金を支払うことにしてもよい。消費者は，また，余剰電力を市場で売却してもよい。

電力は蓄えることが非常に難しい。これは，過剰供給の時期に価格がマイナスになる可能性があること，

つまり，供給者が電力を供給するために金銭を支払う必要があること，を意味する。

スマートグリッドを制御するソフトウェアは，オープンシステムの一部である。実際，システムは絶え

ず変化し，新しい消費者，電力小売業者及び電力供給者が参入してくる。さらに，グリッド制御ソフトウ

ェアは数千人の消費者に接続されており，その多くは風力タービン及び太陽電池を制御するソフトウェア
を運用してもいる。これらのシステムはどんな消費者でも使える公共ネットワークで接続されることにな

るため，スマートグリッド全体は，ネットワーク内のマルウェアに影響され得るオープンシステムとなる。
以上のことから，スマートグリッドは“ファイアウォール”をもって消費者に面する必要があるだけでな
く，電力供給者に面するにもそうする必要がある。

C 62853：2020 (IEC 62853：2018)

C.3 スマートグリッドのディペンダビリティケースの構築

C.3.1 概要

スマートグリッドのライフサイクルがオープンシステムディペンダビリティの達成を支援するためには，

箇条5を満たすディペンダビリティケースが構築及び維持されることが望ましい。C.3では，その作業の

ためにとり得る一連のステップを例示し，併せてスマートグリッドの場合に各ステップで考慮されるべき
特定の課題を示す。次に示す九つのステップは，参考文献[11]にあるディペンダビリティケース記述のガ

イドラインから採られたものである。

C.3.2 スマートグリッドのディペンダビリティケース構築のためのステップ

C.3.2.1 ステップ1：対象システムのライフサイクルを明確に定義し，各段階の入力文書及び出力文書を

識別する。

スマートグリッドのライフサイクルを通じて入力及び出力される文書は，そのディペンダビリティケー

スの基礎を形成する。これには法的文書，規制規則並びに会社の定款及び契約が含まれる。

グリッド運営者は，電力網（鉄塔，ケーブル，変電所及び低電圧配電網）について何らかの運営権又は

所有権をもつ。所有権は，法律に基づくものである場合もあれば，公有又は私有の会社を通じた所有であ
る場合もある。

グリッド運営者は，多くの電力供給者及び電力小売業者と契約を結ぶことになる。契約先はグリッド運

営者と同じ国にある大規模発電所（石炭火力，原子力又は水力発電所）である場合もあれば，外国の場合

もある。また，外国のグリッド運営者と契約を結ぶこともある。さらに，グリッド運営者は，電力小売業
者を通じて，私有の風力発電所及び太陽光発電所から電力を購入する場合もある。供給者は，消費者でも

コンソーシアムでもあり得る。これらの契約は全て，ソフトウェアで実装する必要がある要求事項を含む。
例えば，誰が，いつ，どの価格で，電力を供給することができるかに関する要求事項である。この価格は，
昼夜によって，また，年間を通じて変化する可能性がある。

グリッド運営者は，電力小売業者の中でも公開市場で（固定価格又は変動価格の）電力を調達し，消費

者に販売するような業者との契約ももつ。これについても，スマートグリッドのソフトウェアに実装する
必要がある。

スマートグリッドソフトウェアのライフサイクルは次のとおりである。

− 合意形成段階は，インテリジェントメーターが消費者の所在地に設置される前に，運営権付与機関，

規制機関，供給者及び消費者との協議から入力を受け取り，要求事項定義文書及び契約書を出力する。

この段階は，障害対応の後又は環境変化の検出の後に，グリッドの改善及び適応のために再び開始さ
れる。

− 開発段階には，次が含まれる。

・アーキテクチャ設計は，要求事項定義が承認された後に行われる。ソフトウェアは，電力網を安定

した状態（仕様で許される範囲内）に保つサブシステム，電力の売買をして支払を処理するサブシ
ステム，契約を扱うサブシステム，及びシステムの安全性及びセキュリティを監視するサブシステ
ムに分かれる。

・要求事項定義及びアーキテクチャ設計の入力によって，各サブシステムは個別に実装され，テスト

され，段階的なインテグレーション及びインテグレーションテストプロセスによって，電力網ソフ

トウェアシステムとして統合される。ソフトウェアシステムは，テストケースによってテストされ，

C 62853：2020 (IEC 62853：2018)

シミュレートされた運用データによってテストされる。最後に，安全性，セキュリティ及び過負荷

テスト（サージ電圧テスト）がソフトウェアに対して実施される。ソフトウェアコード，開発ログ，
テスト結果，及びその他の成果物が出力される。

− 説明責任遂行段階は，運用免許が交付される前にアシュアランスを提供する。規制機関，供給者及び

消費者に提出されるアシュアランス議論及び証拠は，開発されたスマートグリッドは要求事項を満た
すこと及び契約は引き続き遵守されることを保証する。グリッドに障害が発生した後又は適応がなさ

れた後には，ライフサイクルは再びこの段階に入る。これは，障害対応処理又はなされた改善につい
て説明責任を果たすため，契約の補償条項を発動させるため，及び改善されたグリッドのアシュアラ
ンスをするためである。

− 運用段階は，完成されたソフトウェアを実行する。実行はまずは小さな“島”（孤立系統）を対象に始

められ，次いで“本土”での実行が始められる。グリッド及び環境は，障害又は合意再形成を必要と
し得る変化が起きていないかについて監視される。

− 障害対応段階は，検出された障害に対する即時対応を行う。対応は，規制及び契約の中に要求及び／

又は規定された計画に従って行われる。計画には，グリッドの緊急時活動と，グリッドに依存する多

くのサービスがそれぞれ行う緊急時活動との間のインタフェースが指定される。計画は完全なものと
はみなされず，これを補う柔軟性がこの段階には組み込まれる。組み込まれた柔軟性は，状況に適応

するため，及び上位権限機関に計画外の関与を求め対応のエスカレーションを図るために活用される
ものである。この段階では，対応の結果を記録し，説明責任遂行段階及び次回の合意形成段階の反復
で記録が用いられるようにする。

C.3.2.2 ステップ2：入力文書及び出力文書を分類する。

ステップ1に続いて，そこで識別された文書がディペンダビリティケースの構築にどのように用いられ

るかが検討される。文書は用いられ方に応じて分類される。次は，そのような分類に用い得る一連の区分
の例及び各区分に関わる国際規格の例である。

− スマートグリッド固有の課題に関する規格には，IEC 61850規格群，IEC 61000-4-30及びIEC TR 62351-

12がある。

− スマートグリッドのリスク分析の結果は，IEC 60812，IEC 61025及びIEC 62551の適用によって得ら

れる。

− スマートグリッドのディペンダビリティ要求事項は，語彙についてはIEC 60050-192及びIEC 60050-

692に基づいて，また，内容については，IEC 62853，IEC 60300-1，IEC 60300-3-4，IEC 61907，IEC
62347及びIEC 62673に基づいて策定される。

− スマートグリッドのライフサイクルを規定するライフサイクル文書は，IEC 62853，IEC 60300-1，JIS

X 0170:2020，ISO/IEC TR 24774，並びにISO/IEC TS 24748-1，ISO/IEC TR 24748-2，ISO/IEC TR 24748-
3，ISO/IEC/IEEE 24748-4，ISO/IEC/IEEE 24748-5及びISO/IEC TS 24748-6にある手引を基に開発さ

れる。

− システムアーキテクチャモデルは，ISO/IEC/IEEE 42010[6]，IEC 61078及びその他文書に基づいて策

定される。

− 運用関連情報は，IEC 61850規格群，IEC 61000-4-30，及びIEC TR 62351-12に従ってやり取りされ

る。

− 環境関連情報は，IEC 60721規格群を用いて分類される。

− テスト及び検証結果は，IEC 62741に従って管理される。

− プログラムコード：ソフトウェアプログラムは，特定の言語を使用してコード化される。コードに含

C 62853：2020 (IEC 62853：2018)

まれるソフトウェアモジュールには，電圧及び周波数を一定に保つもの，負荷を制御するもの，及び

ネットワークの障害に対応するものがある。また，コードには，ファイアウォールを作動させネット
ワークを監視するソフトウェアも含まれる。このファイアウォールは，消費者，電力小売業者及び電

力供給者のそれぞれに面するものである。監視されるのはネットワーク内の異常な活動，例えば，電
力消費の過度の変動，異常な支払い，異常なデータ通信量，及びマルウェアの疑いがあるコードであ
る。

C.3.2.3 ステップ3：“絶え間なく変化し続けるシステムにおいて，サービス継続性及び説明責任が達成さ

れる”を最上位の主張に設定する。

ステップ1及びステップ2の準備の後，ディペンダビリティケース構築の本体は，最上位の主張の定義

から始まる。上の文言は定型の緒言で，ケースがオープンシステムディペンダビリティに関するものであ

ることをケースの読者に通知するものとして提案されているものである。この最上位主張を定義するとは，
スマートグリッドの場合におけるこの文言の解釈を確立することである。解釈は，用語（例えば，“システ

ム”，“サービス継続性”）を定義し，グリッドの置かれた状況に関する文脈情報を明示化することで確立さ
れる。電力網は，ダウン時間を可能な限り最短にとどめ，障害後に迅速に復旧し，かつ，あらゆる負荷条

件の下で指定された電圧及び周波数の範囲内にとど（留）まる必要がある。これらのゴールは，最上位の
主張の定義を通じて成文化される。

C.3.2.4 ステップ4：ディペンダビリティ要求事項，環境情報，及び用語定義を最上位の主張に明示的な
コンテキストとして付加する。

ステップ3で設定された詳細及び詳細と最上位の主張との間の関連は，ディペンダビリティケースに明

示的に記録される。附属書BのようにGSNを用いる場合には，この記録は詳細文書への参照を含むコン

テキストノードを主張に付加することによってなされる。スマートグリッドの場合，詳細は，例えば，次
のようになる。

− “電力網には，0.999 97のアベイラビリティが要求される”

− “ダウン時間が生じる場合の98 %は1時間未満でなければならない”

− “電圧，周波数，瞬時停止及びじょう（擾）乱は，運用時間の99.8 %で仕様内になければならない”

− “用語の定義はIEC 60050-192及びIEC 60050-692に従う”

− “電力網の地理的供給区域は，IEC 61721で定義される温度，降水量，風及び太陽放射をもつ北ヨー

ロッパである”

C.3.2.5 ステップ5：ディペンダビリティケースの全体的な議論構造を計画する。

全体的な議論構造の計画は，附属書Bで提供されるテンプレートを出発点とする。スマートグリッド用

のテンプレートの適用，すなわち，テンプレートを具体的な，構造化された議論にすることには，次の事
項が伴う。

− テンプレート内のゴールをスマートグリッドに特有の詳細なサブゴールへ分割すること

− 元からあるゴール及び分割でできた新規ゴールを示すための議論ストラテジーを形成及び／又は精密

化すること

スマートグリッド固有のゴールで扱われる事項に適した議論ストラテジーの例を，次に示す。

a) ライフサイクルに基づく議論ストラテジーは，次の事項に関わるゴールに適切である。

1) 運営権（法的文書）

C 62853：2020 (IEC 62853：2018)

2) 電力網の所有権，不動産権利証書及び土地負担登録証書，契約書

3) 変電所−仕様及び図面

4) 高低圧配電系統−地中ケーブル及び架空送電線の位置，接続及び容量の地図

5) 風力発電施設及び太陽光発電施設との契約

b) システムの機能に基づく議論ストラテジーは，次の事項に関わるゴールに適切である。

1) 供給者の最大能力，グリッドの電圧維持能力

c) 作業フローに基づく議論ストラテジーは，次の事項に関わるゴールに適切である。

1) 負荷及び供給の変動

2) 価格の変動

d) 障害及びリスクの軽減に基づく議論ストラテジーは，次の事項に関わるゴールに適切である。

1) 負荷及び供給の将来予測

2) 発電予備力及び冗長性

3) 負荷を減らすための電力系統からの解列の手順

4) 解列後に再並列する手順

5) “島”限定の運用の手順

6) 制御システム内のマルウェアに対抗する手順

7) 価格交渉及び会計のシステム内のマルウェアに対抗する手順

注記消費の将来予測は，昼対夜，労働日対休日及び夏対冬の負荷変動の履歴データに基づいてなされ

得る。供給の将来予測は，一日の中の時刻に基づくことがある（太陽電池は夜には発電しない。）。
天気予報で，太陽電池に懸る雲量及び風車に流入する風速を予測することも可能である。例えば，

ある大嵐があったとき，デンマークにある風車は一時総体として全国の電力消費を賄う発電をし
ていた。しかし，ほどなくして風車は一つずつ脱落していった。風速が大き過ぎたためである。

C.3.2.6 ステップ6：必要な文書をコンテキスト及びエビデンスとして付加する。

議論の全体構造が決定された後，各議論に必要な文書がコンテキスト及びエビデンスとして添付される

ことが望ましい。スマートグリッドのライフサイクル全体にわたる文書の入力及び出力について行った分
類は，このステップでの指針となる。

C.3.2.7 ステップ7：文書から導き出せるディペンダビリティサブケースを開発する。

このステップに至った時点で，議論の構築がステップ6のコンテキストで添付された文書を踏まえて行

われることが望ましい。議論ストラテジーには，複雑なコンテキスト及びエビデンスを精査する定型的，
手続き的な作業が伴うことが多い。そのため，単にどのストラテジーが用いられたかを示唆するだけでは，

議論ストラテジーのゴールとその下のサブゴール及び／又はエビデンスとの間の隔たりを埋めてディペン
ダビリティケースの読者に理解してもらう目的には不十分であることが多い。そのような場合には，議論

ストラテジーはディペンダビリティサブケースに展開される。このサブケースは，手続き的な作業の結果
を，関係するコンテキスト文書及びエビデンス文書の内容に基づいて説明するものである。このサブケー
スは，関係文書が適切に構造化されていれば（半）自動的に導出可能であることが多い。

C 62853：2020 (IEC 62853：2018)

C.3.2.8 ステップ8：導出不可能なディペンダビリティサブケースを確立された議論構造を利用して構築
し，ディペンダビリティケースを完成させる。

全体の議論構造のうち，導出可能なサブケースとして埋められていない残りの部分は，手続き的には示

せない事柄を主張する議論，又はそのような事柄で支えられる議論を読者に伝える部分である。ここでい
う事柄には，専門家の判断，広く認められた規範，合意された仮定及び見解，不可避の影響力などがある。

これらのサブケースは，場合々々に手作業で構築されることになる。とはいえ，標準的に良い実践とされ
る取組み方はある。それは，目下の状況に近い状況で成功裏に適用された実績をもつ，確立された議論構

造を探し求めて採用することである。関連する規格及び規制の背後にある論拠，なぜそのように定められ
るに至ったかの理由を，成功する議論構造に転換できることもある。確立された議論構造を使用すること

によって，余りにも多様でアドホックな議論を評価しなければならなくなる困難を避けることが可能であ
る。

C.3.2.9 ステップ9：必要な回数だけ一連の上記ステップを繰り返す。

グリッドのシステムはオープンシステムであるため，ディペンダビリティケースは頻繁に更新される必

要がある。

グリッドの構成は，新しい地中ケーブルが敷設され，新しい架空送電線及び変電所が建設，改修，又は

閉鎖されるにつれ，刻々と変化する。

供給者の数及び発電能力，特に風車及び太陽電池パネルのそれには，変化が生じる。消費者（工場，事

務所及び家庭）も頻繁に変わり，また，供給元に選ばれる電力小売業者も変わる。それでも，グリッド運

営者に付与される運営権は，通常，供給区域内のどんな顧客にも給電することの要求が付帯したものであ
り続ける。

供給及び価格の合意も，しばしば時々刻々，昼夜で，また，年をおって，変化していく。

C.4以降では，図A.1の変化対応サイクル及び障害対応サイクルについて議論する。

この箇条の九つのステップは，参考文献[11]で導入されたもので，そこで更に議論されている。

C.4 変化対応サイクル

スマートグリッドのDEOSライフサイクルにおける変化対応サイクルは，全体として6.5の変化対応プ

ロセスビューを実装するものである。また，一部は，6.3の説明責任遂行プロセスビュー及び6.2の合意形
成プロセスビューを，スマートグリッドになされる適応に関して実装するものでもある（A.2を参照）。図

A.1にあるように，まず要求事項の抽出及びリスク分析が行われ，次いで利害関係者の合意が得られる。
その後，オープンシステムのソフトウェアの初版の開発，コンパイル，検証，及びテストがC.3.2.1に従っ

てなされる。試験所でのテスト及び限定された地理的区域（島）でのテストの後，ソフトウェアの利用が
開始される。この時点での達成事項及びそれに関する説明責任が，スマートグリッド運営免許申請時に添

付するディペンダビリティケースに明示される。通常運用の間は，結果及び問題が監視される。問題及び
観測された事象は，次の二つに分別される。

− 障害対応サイクルで扱われる，異常及び障害（C.5）

− 変化対応サイクルで扱われる，目標に生じた変化及び／又は環境に生じた変化

目標に生じる変化には，例えば，再生可能エネルギーへの重点化，CO2排出目標設定の低下，運営権付

C 62853：2020 (IEC 62853：2018)

与及び助成金交付の透明性向上がある。環境に生じる変化には，電力供給構造の変化から起きるものもあ

る。供給構造の変化の例には，原子力発電所の閉鎖，電力系統の新しい国際接続（ケーブル）の導入，エ
ネルギー貯蔵施設（上部調整池又は圧縮空気圧貯蔵用空洞）の導入，余剰電力の液体燃料への転換がある。

環境に生じる変化には，主要な水力発電所のある地域での干ばつ又は降雪不足もある。変化対応サイクル
が閉じられ次の反復が開始されるのは，新たな要求事項の引出し及びリスク分析の更新が利害関係者合意

の更新につながり，それが新たな設計，実装，検証，テストのプロセスを開始するものであるときである。
この点においては，オープンシステムディペンダビリティは，ソフトウェア開発のスパイラルモデルと似

ている。異なっているのは，オープンシステムのスパイラルなプロセスは全運用期間にわたって継続する
ものであって，初期のソフトウェア開発時だけのものではないという点である。

C.5 障害対応サイクル

スマートグリッドのDEOSライフサイクルにおける障害対応サイクルは，全体として6.4の障害対応プ

ロセスビューを実装するものである。また，一部は，6.3の説明責任遂行プロセスビュー及び6.2の合意形
成プロセスビューを，障害対応に関して実装するものでもある（A.2を参照）。障害対応サイクルは，障害

又は異常の検出によって開始される。障害には，例えば，短絡による区域内での電力喪失がある。短絡は，
例えば，電力網に生じることもあれば，変電所で起きることもある。短絡の原因には，落雷，風又は着雪

による高張力線の過負荷，掘削作業による地中ケーブル損傷，船舶のアンカーによる海底ケーブルの損傷
などがある。一般には，このような障害がいつ発生するかは予測不可能である。可能であるのは，変圧器
の障害発生確率を使用年数及び状態に基づいて予測することなどに限られる。

停電の際の初動活動は，システム内で停電が伝ぱ（播）しないように問題箇所を隔離することである。

負荷を軽減するために，システムの一部を切り離す必要があるかもしれない。極端な場合には，運用を“島

（孤立系統）運用”に切り替える必要もあり得る。つまり，システムを閉じられた区域内の従来型システ
ムとして運用し，外部からの供給を受けず外部への送電もしないようにする必要もあり得る。障害対応の
目的は，全ての消費者への電力供給を，可能な限り最短の時間で再確立することである。

これには，供給者と消費者との再接続を制御する必要がある。これら措置の大部分は，運用制御ソフト

ウェアモジュールによって，自動的に，又は半自動的に行われる。障害検出（又は障害予知）は，障害予

防，障害対応，及び原因分析からなる障害対応段階を開始させる。障害対応とは上で説明された活動であ
る。原因分析とは，障害の原因を特定するための活動である（IEC 62740[19]を参照）。典型的な原因は幾つ

か上で説明されている。障害予防とは，例えば，鉄塔に掛けられた架空送電線の地中ケーブル化，変電所
の予防保守などからなる活動である。掘削活動用に地中ケーブル配置を地図化しておくこと，海底ケーブ
ル近くでの船舶のびょう（錨）泊禁止なども，障害予防を助ける。

オープンシステムの場合，異常検出は非常に重要な活動である。監視ソフトウェアモジュールが，異常

な動作を継続的に監視している必要がある。この監視は主に，マルウェアによってソフトウェアに侵入し
これを制御しようとする試みを検出するためのものである。侵入は，消費者を通じて起こり得る。ここで

いう消費者は，インターネット，家庭内の電力消費装置及び発電装置，並びに供給配送価格交渉及び会計
サブシステムへのネットワーク接続をもつ消費者である。異常検出では，過剰送金，消費者の消費量又は

供給量の突然の変化など，異常な会計処理を警戒する必要もある。このような継続的な異常検出は，非オ
ープンシステムの組込みソフトウェアなどではさほど重要でなくとも，オープンシステムでは非常に重要
である。

オープンシステムの運用者は，潜在的なマルウェアを分離し，脅威を分析し，除去するための即応体制

を，絶え間なく維持することになる。これには，問題が分析され解決されるまで一部のアドレスを隔離す

C 62853：2020 (IEC 62853：2018)

参考文献

[1] ISO 26000:2010，Guidance on social responsibility

注記 JIS Z 26000:2012 社会的責任に関する手引が，この国際規格に対応している。

[2] ISO 15489-1:2001，Information and documentation−Records management−Part 1: General 1)

注1) ISO 15489-1:2001は廃止され，ISO 15489-1:2016に改正された。

[3] ISO/IEC 15026-1:2013，Systems and software engineering−Systems and software assurance−Part 1: Concepts

and vocabulary 2)

注2) ISO/IEC 15026-1:2013は廃止され，ISO/IEC/IEEE 15026-1:2019に改正された。

[4] ISO/IEC Guide 2:2004，Standardization and related activities−General vocabulary

注記 JIS Z 8002:2006 標準化及び関連活動−一般的な用語が，この国際規格に対応している。

[5] ISO Guide 73:2009，Risk management−Vocabulary

注記 JIS Q 0073:2010 リスクマネジメント−用語が，この国際規格に対応している。

[6] ISO/IEC/IEEE 42010:2011，Systems and software engineering−Architecture description

[7] ISO 22301:2012，Societal security−Business continuity management systems−Requirements 3)

注記 JIS Q 22301:2013 社会セキュリティ−事業継続マネジメントシステム−要求事項が，この国

際規格に対応している。

注3) ISO 22301:2012は廃止され，ISO 22301:2019に改正された。

[8] ISO 9000:2015，Quality management systems−Fundamentals and vocabulary

注記 JIS Q 9000:2015 品質マネジメントシステム―基本及び用語が，この国際規格に対応してい

る。

[9] United Nations International Strategy for Disaster Reduction (UNISDR). Terminology on Disaster Risk

Reduction. 2009

[10] Laprie, Jean-Claude. “From dependability to resilience.” 38th IEEE/IFIP Int. Conf. On Dependable Systems and

Networks. 2008

[11] Tokoro, Mario, ed. Open Systems Dependability−Dependability Engineering for Ever-Changing Systems.

Second edition, CRC Press, 2015

[12] Bloomfield, Robin and Gashi, Ilir. Evaluating the resilience and security of boundaryless, evolving socio-

technical systems of systems. Research report to DSTL, Centre for Software Reliability, City University, London,

2008

[13] Jamshidi, Mohammad, ed. System of systems engineering: innovations for the twenty-first century. John Wiley

& Sons, 2011

[14] ISO/IEC 15026-2，Systems and software engineering−Systems and software assurance−Part 2: Assurance case

注記 JIS X 0134-2 システム及びソフトウェア技術−システム及びソフトウェアアシュアランス

−第2部：アシュアランスケースが，この国際規格に対応している。

[15] IEC 62741，Demonstration of dependability requirements−The dependability case

[16] ISO 31000，Risk management−Guidelines

注記 JIS Q 31000 リスクマネジメント−指針が，この国際規格に対応している。

[17] IEC 31010，Risk management−Risk assessment techniques