JIS C 5750-2:2010 ディペンダビリティ　マネジメント―第２部：ディペンダビリティ　マネジメントのための指針 | ページ 6

22
C 5750-2 : 2010
    安全性,経済性若しくは他の規定した特性に影響する条件及び要因の明確化及び解析を行う。指針を
    IEC 61025に示す。
− マルコフ解析は,故障の状態から運用の状態及びその逆への状態の推移の確率とともに,システムの
    アベイラビリティ性能を決定する。指針をIEC 61165に示す。
− 技術的リスク解析は,リスクにさらされる範囲及び事象の発生確率を決定する。指針をIEC 60300-3-9
    に示す。
A.3.6 タスク18 : 予測
  予測は,初期の設計及び開発段階で行い,設計の進行とともに更新することが望ましい。予測結果は,
故障までの平均時間,平均故障間隔又は故障率という観点からの製品の信頼性性能のアセスメントを提供
する。システムのアベイラビリティ性能は,規定した運用期間における,アップ時間又はダウン時間の割
合として解釈できる。
  製品に関する予測においては,適用環境,運用上の負荷及び複雑性,システムコンフィグレーションの
アーキテクチャ並びに製品の信頼性性能予測のための基本となる履歴データを考慮することが望ましい。
電気的機器の部品に対する信頼性予測のための故障率データの使用についてのガイダンスを,IEC 61709
に示す。
  ソフトウェアにおける予測手法として,一般的に三つの方法がある。まず,最初の方法は,ソフトウェ
ア開発プロセスの特性に基づくものである。二つ目は,製品の特性に基づくものである。三つ目は,ソフ
トウェアの検証プロセス及び実際の運用から収集した履歴データに基づくものである。
  ソフトウェア開発プロセスの特性による予測モデルは,プロセスのパラメータに影響する。その考え方
は,マネジメント及びソフトウェア開発に用いる技術的規範(つまり,プロセス管理の範囲,技術的な厳
密性の程度,正式な方法の適用など)が,ソフトウェアに関する信頼性推定目標を提供できるということ
である。この点において,プロセスのパラメータは,信頼性改善の基準として用いる。
  ソフトウェア製品の特性による予測モデルは,ソフトウェアの構造及び複雑性などのソフトウェア製品
のパラメータに影響する。そのようなモデルによる信頼性予測は,一般的に既製のソフトウェア製品の評
価及び比較分析に用いる。
  ソフトウェア性能データによる予測モデルは,ソフトウェアの特定の適用及び運用環境に影響する。観
察データを基に信頼性成長目標を推定するために,統計的方法を用いる。
A.3.7 タスク19 : トレードオフ解析
  トレードオフ解析は,信頼性のための配分について情報を適時に提供するため,構想及び定義段階並び
に設計及び開発段階の早い段階で行うことが望ましい。トレードオフ解析は,解析する問題によって,ラ
イフサイクルのどの段階で実行してもよい。持続運用又は交換のための経済的価値を決定するために,製
品の寿命の終わりに,トレードオフ解析も行うことが望ましい。ライフサイクル コストの解析は,トレー
ドオフ解析を補完する。
  トレードオフ解析は,設計の選択肢からの選択,内作か外注かの決定,及び代替解決策のための比較解
析に効果的に使用できる。トレードオフ解析は,費用対効果のあるプロジェクトの目標を満たすシステム
性能を達成する設計アーキテクチャにおいて,適切な技術的アプローチ,代替のハードウェア若しくはソ
フトウェアによる方法,又はハードウェアとソフトウェアとを組み合わせた解決策を選択するための意思
決定に用いることが望ましい。
A.3.8 タスク20 : ライフサイクル コスティング
  ライフサイクル コスティングでは,資源の配分及び考えられる支出を評価するため,作業の細分化構造

――――― [JIS C 5750-2 pdf 26] ―――――

                                                                                             23
                                                                                 C 5750-2 : 2010
に関連したライフサイクル プロセスのコストの細分化の定量的アセスメントを行う。その定量的結果は,
しばしば改良又は変更への推奨事項を正当化するための質的な根拠が支援する。ライフサイクル コスティ
ングは,プロジェクトの管理においてマネジメントの決定を促進する。感度解析は,しばしば“仮定”の
状況を決定するために行う。ライフサイクル分析の結果は,次に示す目的で使用できる。
− ディペンダビリティ目標の中で,割当て及びトレードオフを指示する。
− 重要なディペンダビリティの要因及びコストへの影響を明確にする。
− 設計の選択肢を選び,代案を支援する。
− 与えられたライフサイクル コストの制約の下で,アベイラビリティ性能の特性を最適化する。
− 与えられたコスト制限のなかで,環境への暴露を最小限にし,かつ,リスクを低減する製品の廃却方
    法を選択する。
  ライフサイクル コスティングについてのガイドラインを,JIS C 5750-3-3に示す。
A.3.9 タスク21 : 信頼性成長
  信頼性成長プログラムは,製品の信頼性性能を改善する目的で実施することが望ましい。信頼性成長プ
ロセスには,フォールトの明確化,根本的原因の解析,是正処置及び実施した是正処置の効果検証の活動
を含む。可能かつ実用的であれば,継続的改善のために予防方法を推奨することが望ましい。IEC 61014
に,信頼性成長プログラム及び手順のガイダンスを示す。IEC 61164に,信頼性成長試験及び推定の方法
を示す。
  ソフトウェアに適用できる特定の信頼性成長モデルは,次の要素で構成する。
− あるパラメータを組み込んだ一連の数学的公式によって故障プロセスを表したもの
− 過去の故障データの分析によってパラメータを推定する方法
− 信頼性尺度の推定値を得るための公式によって推定したパラメータ値を組み合わせる方法
A.4 要素4 : 検証及び妥当性確認
  製品設計の信頼性及び保全性が,設計仕様書に適合していることを確認することが望ましい。ディペン
ダビリティに関する性能特性は,運用開始期間中又は運用及び保全段階の初期に,ディペンダビリティ目
標に関連した個別の性能特性の達成を確認することによって,妥当性を確認することが望ましい。検証及
び妥当性確認は,レビュープロセスの一部を形成することが望ましい。タスク22タスク24では,検証
及び妥当性確認の構成要素について説明する。
A.4.1 タスク22 : 検証及び妥当性確認の戦略
  検証及び妥当性確認の活動を計画することが望ましい。
  検証の戦略には,実際的であれば,ディペンダビリティ機能の設計の妥当性を判定するために,かつ,
環境条件及びストレス負荷条件に依存する信頼性及び保全性の特性の性能限界を評価するために,製品の
シミュレーション及び試験を含めることが望ましい。検証の戦略の目的は,評価,認定及び環境試験によ
って,エンジニアリングモデル又はプロトタイプの機能的及び物理的性能を確認することであることが望
ましい。
  妥当性確認の戦略は,実際的かつ実現可能であれば,最終製品に対して規定の運用条件下で実行するこ
とが望ましい。妥当性確認のプロセスは,通常,システムは顧客の建屋内に設置するため,顧客と連携し
て実施することが望ましい。妥当性確認の結果は,システムの受入れのための証拠として文書化すること
が望ましい。

――――― [JIS C 5750-2 pdf 27] ―――――

24
C 5750-2 : 2010
A.4.2 タスク23 : ディペンダビリティの実証
  ディペンダビリティの実証は,受入れ試験の一形態である。大規模で複雑なシステムでは,顧客におけ
る受入れのためのシステム運用開始の直前又はその期間中に実証を行うことが望ましい。機能デバイス又
は部品に対する実証は,通常,寿命試験又は加速寿命試験のような特別な試験プログラムの中で実施する。
  これらの試験の目的は,意図した目標を達成しているかという観点において性能の妥当性を実証するこ
とである。実行可能かつ経済的であれば,実証試験は,プロジェクトに適用可能な,他で計画した同様の
試験条件の試験と組み合わせて行うことが望ましい。これによって,受入れ基準に対して,試験結果のよ
り実際的な性能妥当性確認を提供できる。試験手順書は,試験方法及び試験条件の詳細を文書化すること
が望ましい。製品の受入れのための性能結果を確定するために,分析のための十分な情報を提供できるよ
うに試験データを記録しておくことが望ましい。
  ソフトウェアの受入れテストは,ソフトウェアの検証及び妥当性確認に関係する。ソフトウェアの受入
れテストには,次の三つのレベルがある。
− 規定した仕様書又は規格に適合していることを確実にするための,各ソフトウェアサブシステム及び
    モジュールのテスト。
− 集合体としての統合化したソフトウェアユニット及び構成品のテスト。一般的には統合テストとして
    知られる。
− 実際の環境下及び契約要求事項又はテスト仕様書の中で規定した所定の条件の下で動作するように構
    成したシステムにおいて,ソフトウェアが動作することを確実にするための,運用開始期間の試行運
    用及び最終的な受入れのためのソフトウェアの導入テスト。
A.4.3 タスク24 : 信頼性ストレススクリーニング
  信頼性ストレススクリーニングとは,不具合を発見する手段として環境及び/又は運用上のストレスを
用いたプロセスである。これらの不具合は潜在不具合であり,出来映えの悪さ又は設計若しくは製造プロ
セスの不完全さに起因している可能性がある。信頼性ストレススクリーニング法は,デバイス及び部品に
内在又は潜在している不具合を,通常の試験で発見できるハード故障に至らしめることを可能にする。
  信頼性のストレススクリーニングは,ハードウェア製品の信頼性の改善手法である。スクリーニングは,
しばしば加速試験とともに導入され,特別な試験設備及び機器が必要になることもある。信頼性ストレス
スクリーニングの指針をJIS C 5750-3-7,IEC 61163-1及びIEC 61163-2に示す。
A.5 要素5 : 知識ベース
  ディペンダビリティの知識ベースは,組織の有効,かつ,効率的な運営にとって重要な必要条件である。
適切なディペンダビリティ データの収集,技術革新によって得た情報及び知識並びにプロセスの改良及び
市場情報は,競争力のあるビジネスの強みとなる。組織が保持する知識ベースは,リーダーとしての挑戦
及び市場の需要に適時にこたえるための戦略的製品展開において重要な役割を果たす。力量及び知識の維
持のための要点は,戦略的情報資源として扱うことが望ましい。タスク25タスク28では,知識ベース
の諸要素について説明する。
A.5.1 タスク25 : 知識ベースの確立
  組織のビジネスに適したディペンダビリティ知識ベースを確立することが望ましい。これによって,適
切かつ最新のディペンダビリティ情報が入手可能となり,新市場の開発と同様に製品のラインナップに関
する面において,継続中のビジネスの支援にも役に立つことが確実になる。ディペンダビリティの知識ベ
ースには,次の事項を含むことが望ましい。

――――― [JIS C 5750-2 pdf 28] ―――――

                                                                                             25
                                                                                 C 5750-2 : 2010
− ディペンダビリティに関する製品設計情報
− フィールドにおけるサービスの運用によって収集した製品性能データ
− 部品の信頼性及び品質に関する供給者の情報
  ディペンダビリティに関する製品設計情報には,必要に応じて,製品の設計目標,ディペンダビリティ
仕様書,部品の適用のためのガイドライン,信頼性及び保全性の予測データ,信頼性及び保全性のモデル
ソース,試験の歩留まり情報並びに製品の受入れ履歴を含むことが望ましい。
  製品性能データには,製品の信頼性成長の傾向,保全支援情報,保証期限内返品数量,事故報告書及び
解決までのフォローアップ,顧客クレーム並びにフィードバック情報を含むことが望ましい(JIS C
5750-3-2参照)。
  供給者の情報には,部品の信頼性履歴,機器の信頼性上の適用限界,スクリーニング及び検査データ,
認定基準並びに推奨部品納入業者を含むことが望ましい。
A.5.2 タスク26 : データ分析
  データ分析は,ディペンダビリティの傾向の提供及び適切な時期に予防処置又は是正処置を開始するた
めの不具合の識別に不可欠である。試験事例,試験結果,フィールドにおける性能データ又はその他の適
切なソースからのデータ分析によって,信頼性成長の監視,ソフトウェアリリースのための完成度合い並
びに根本原因の分析のための体系的な問題などの価値ある見識及び情報を提供できる。継続的改善プロセ
スに繋げるために,すべての分析データは,合理的に解釈し,マネジメントの判断及びフォローアップ活
動のためにレビューを行うことが望ましい。
A.5.3 タスク27 : データ収集及び普及
  データ収集及び普及のシステムは,適切なソースからのデータ収集及び重要な情報を,意思決定のため
に必要とする責任者に迅速に配付することを重視することが望ましい。事実に基づくデータは,ディペン
ダビリティの改良及びビジネス上の意思決定の支援のために不可欠である。データの解釈は,改善のため
の投資の提案を正当化する理論的根拠を提供することが望ましい。
  そのシステムを通じて収集及び普及させる代表的なデータは,稼動中の製品の性能,フィールドサービ
スの運用及び利用者からの履歴のフィードバックなどに関する適切なデータを含む。製品の評価結果,試
験事例,製品性能の検証及び妥当性確認,レビュー並びに供給者の調査は,収集データの一部に含まれる
ことが望ましい。データ収集及び普及のシステムは,ディペンダビリティの分析及び意思決定の支援のた
めに必要な本質的データを提供するための単純かつ適切なものであることが望ましい。理想的には,更な
る分析のため,ハードウェア故障,ソフトウェアフォールト及び手順のエラーに関連する生データを簡単
に分離できることが望ましい。したがって,データ収集手順の設計並びにデータ収集及び普及のシステム
の確立には,運用上の利便性及び有効性を考慮することが望ましい。データ収集及び普及のシステムは,
文書分類,保管及び検索,データ管理並びに情報の安全確保及び保護の下での使用を考慮することが望ま
しい。
A.5.4 タスク28 : ディペンダビリティの記録
  ディペンダビリティの記録には,契約書及び規制への適合目的で必要とされる適切なディペンダビリテ
ィ データを含むことが望ましい。保存するにふさわしい代表的な記録として,次の事項を含む。
− 望ましい供給者の選定のための,製品信頼性の履歴
− 信頼性,保全性及びアベイラビリティの報告書
− 製品の完成傾向及び製品の使用目的への適合性の保証を支援するための,検証及び妥当性確認の情報
− リスク軽減及びコスト削減の取組みを開始するために必要な知識を獲得するための,根本原因の分析

――――― [JIS C 5750-2 pdf 29] ―――――

26
C 5750-2 : 2010
    報告書
− 製品受入れのための,ディペンダビリティの実証記録
− 改善及び強化のための,フィールド追跡及び保証の記録
  サブアセンブリ及び構成品のトレーサビリティ(例えば,バーマーキング)は,ディペンダビリティ記
録の価値を著しく高める。記録の保存期間は,契約及び法的条件に依存する。
A.6 要素6 : 改善
  改善は,ビジネスのプロセス及びその製品の改善によって,ビジネスの生き残り及び成長を確実にする
ための重要なプロセスである。継続的改善は,持続性のある開発に必要な誘因を提供する。時折の技術的
な打開及び製品の改革は,競争の激しい市場における強みとなる。投資効率の改善の取組みを生かすには,
時機が大切である。タスク29タスク32では,改善の諸要素について説明する。
A.6.1 タスク29 : 予防処置及び是正処置
  予防処置は,潜在的な問題又は望ましくない状況の原因を取り除くために実施する。是正処置は,既存
の問題又は望ましくない状況の原因を取り除くために実施する。予防処置は発生を防ぐために実施し,是
正処置は再発を防ぐために実施する。
  予防処置及び是正処置は,改善プロセスの一部である。予防処置及び是正処置の成功又は有効性は,採
用する実行の仕方又は方法に依存する。情報システムを用いて,予防処置及び是正処置の開始を促進する
ことが望ましい。タスクの完了又は終了を指定したスケジュールとともに,責任者を任命することが望ま
しい。処置の結果は,問題の除去における有効性を決定するために,検証することが望ましい。予防処置
及び是正処置は,文書化し,かつ,参照のために追跡可能にすることが望ましい。
A.6.2 タスク30 : アップグレード及び部分変更
  アップグレードは,特徴又は能力の強化に関する製品改善のために行うことが望ましい。部分変更は,
製品の変更手順と関連して進めることが望ましい。アップグレード及び部分変更は,改善プロセスの開始
及び有効な実施による結果を反映することが望ましい。それらは,改善の傾向を確立するための記録のト
レーサビリティ及びデータ分析の推進のために,コンフィグレーションのマネジメントプロセスに適合す
ることが望ましい。ISO 10007は,コンフィグレーション管理の指針を規定する。
  ソフトウェアのアップグレードは,通常ソフトウェアの保全中に行う。例として,ソフトウェア機能の
強化,記憶容量の増加及び費用対効果のための管理手順の簡略化がある。ソフトウェアのイベントデータ
は,改善の傾向の指標として維持することが望ましい。ソフトウェア改善のための是正及び“完全”保全
は,保全プロセスで考慮することが望ましい。ソフトウェアの強化のための完全保全は,システムの故障
の発生に対応するというよりも,むしろソフトウェアの実行における欠点を減らすためのものである。
  ハードウェア及びソフトウェアの部分変更管理は,適切な管理上及び技術上の手順を適用し確立したコ
ンフィグレーション管理プロセスに適合することが望ましい。これは,継続的なサービスの品質及び有効
性の保全に対する,その完全性,一貫性及び正確性を確実にするように,部分変更の状態を識別,記録及
び報告するためである。
A.6.3 タスク31 : 力量の開発及び強化
  人の力量の開発は,知識ベースの強化及び継続的改善のための資源投資として考えることが望ましい。
重要な力量は,技術的な優位を継続し,かつ,市場における競争力を維持するための組織力にとって不可
欠である。
  ディペンダビリティの知識及び力量は,技術的向上のためのディペンダビリティ マネジメントにおける

――――― [JIS C 5750-2 pdf 30] ―――――

次のページ PDF 31