NTT DATA TECH
😱

非機能要求グレードの歩き方 Vol.11 C5サポート体制 C6その他の運用管理方針

Junichiroh Hirose
に公開
サポート
金融
運用保守
非機能
idea

はじめに - Vol.11

本記事では、IPA[1] が公開する 非機能要求グレード[2] の
「C.5 サポート体制」と「C.6 その他の運用管理方針」を対象に、
金融 IT 基盤に 30 年以上携わって得た知見をもとに “やらかしがちな” 技術課題と対策を解説します。

筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含め解説します。

Vol.11 バスタブ曲線と保守サポート期間

シリーズ全体の構成は 👉 非機能要求グレードの歩き方 Index をご覧ください。

C.5 サポート体制
C.6 その他の運用管理方針

中項目「C.5 サポート体制」では、どういったサポートが必要か定義します。
「C.6 その他の運用管理方針」では、運用保守フェーズにおける管理に関する要件を定義します。
なお、運用保守フェーズにおけるシステム環境に影響する要件は「C.4 運用環境」に記載します。

下表は、大項目「C 運用・保守性」-中項目「C.5 サポート体制」「C.6 その他の運用管理方針」を抜粋したものです。

表: 「C.5 サポート体制」の小項目とメトリクス（折りたたんでいます）
大項目 中項目 小項目 メトリクス(〇: 重要項目)
C 運用
・保守性		 C.5 サポート体制 C.5.1 保守契約（ハードウェア） C.5.1.1 ○ 保守契約（ハードウェア）の範囲
〃 〃 C.5.2 保守契約（ソフトウェア） C.5.2.1 ○ 保守契約（ソフトウェア）の範囲
〃 〃 C.5.3 ライフサイクル期間 C.5.3.1 ○ ライフサイクル期間
〃 〃 C.5.4 メンテナンス作業役割分担 C.5.4.1 　 メンテナンス作業役割分担
〃 〃 C.5.5 一次対応役割分担 C.5.5.1 　 一次対応役割分担
〃 〃 C.5.6 サポート要員 C.5.6.1 　 ベンダ側常備配備人数
C.5.6.2 　 ベンダ側対応時間帯
C.5.6.3 　 ベンダ側対応者の要求スキルレベル
C.5.6.4 　 エスカレーション対応
〃 〃 C.5.7 導入サポート C.5.7.1 　 システムテスト稼働時の導入サポート期間
C.5.7.2 　 システム本稼働時の導入サポート期間
〃 〃 C.5.8 オペレーション訓練 C.5.8.1 　 オペレーション訓練実施の役割分担
C.5.8.2 　 オペレーション訓練範囲
C.5.8.3 　 オペレーション訓練実施頻度
〃 〃 C.5.9 定期報告会 C.5.9.1 　 定期報告会実施頻度
C.5.9.2 　 報告内容のレベル
表: 「C.6 その他の運用管理方針」の小項目とメトリクス（折りたたんでいます）
大項目 中項目 小項目 メトリクス(〇: 重要項目)
C 運用
・保守性		 C.6 その他の運用管理方針 C.6.1 内部統制対応 C.6.1.1 ○ 内部統制対応の実施有無
〃 〃 C.6.2 サービスデスク C.6.2.1 ○ サービスデスクの設置有無
〃 〃 C.6.3 インシデント管理 C.6.3.1 　 インシデント管理の実施有無
〃 〃 C.6.4 問題管理 C.6.4.1 　 問題管理の実施有無
〃 〃 C.6.5 構成管理 C.6.5.1 　 構成管理の実施有無
〃 〃 C.6.6 変更管理 C.6.6.1 　 変更管理の実施有無
〃 〃 C.6.7 リリース管理 C.6.7.1 　 リリース管理の実施有無

以降、小項目ごとに、非機能要求グレードの内容（メトリクス）を記載し、「〇：重要項目」のある小項目について解説します。

〇：重要項目 とは

C.5.1 保守契約（ハードウェア）

小項目 メトリクス(〇: 重要項目)
C.5.1 保守契約（ハードウェア）
保守が必要な対象ハードウェアの範囲。
 C.5.1.1 ○ 保守契約（ハードウェア）の範囲
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.5.1.1
○
保守契約（ハードウェア）の範囲		 0: 保守契約を行わない
1: ベンダの自社製品（ハードウェア）に対してのみ保守契約を行う
2: マルチベンダのサポート契約を行う（一部対象外を許容）
3: マルチベンダのサポート契約を行う（システムを構成する全製品を対象）

【レベル】
ベンダの自社製品（ハードウェア）に対してのみサポート契約とは、システムを構成する製品個別の提供ベンダと、当該製品に対するサポート契約を行うことを意味しており、当該製品に対してのみサポートサービスが提供される契約形態のことである。 マルチベンダのサポート契約とは、システム全体に対するサポートサービスを提供するベンダと契約を行うことを意味しており、複数のベンダの製品から構成されるシステムに対してワンストップのサポート窓口が提供される契約形態のことである。
【運用コストへの影響】
サポート契約を行うと運用コストが増大するように感じられるが、問題が発生した際に必要となる費用が膨大となるため、サポート契約を行ったほうが結果として運用コストは小さくなる場合がある。

保守契約方針

  • 小項目「C.5.1 保守契約（ハードウェア）」では、保守契約を含むハードウェア (HW) の契約条件に関する要件（方針） を記述します。
  • なお、ライフサイクル期間（C.5.3）とサポート期間のギャップ対策については、「C.3.4 交換用部材の確保」に記載しますが、延長保守契約を必要とするなど契約に影響する事項は、本項に記載します。
  • クラウドなどのサービスやサブスクリプションなど、HWの概念が曖昧なものは、「C.5.1 保守契約（ハードウェア）」「C.5.2 保守契約（ソフトウェア）」の何れかに記載してください。（片方に寄せても構いません）

C.5.2 保守契約（ソフトウェア）

小項目 メトリクス(〇: 重要項目)
C.5.2 保守契約（ソフトウェア）
保守が必要な対象ソフトウェアの範囲。
 C.5.2.1 ○ 保守契約（ソフトウェア）の範囲
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.5.2.1
○
保守契約（ソフトウェア）の範囲		 0: 保守契約を行わない
1: ベンダの自社製品（ソフトウェア）に対してのみ保守契約を行う
2: マルチベンダのサポート契約を行う（一部対象外を許容）
3: マルチベンダのサポート契約を行う（システムを構成する全製品を対象）

【レベル】
ベンダの自社製品（ソフトウェア）に対してのみサポート契約とは、システムを構成する製品個別の提供ベンダと、当該製品に対するサポート契約を行うことを意味しており、当該製品に対してのみサポートサービスが提供される契約形態のことである。 マルチベンダのサポート契約とは、システム全体に対するサポートサービスを提供するベンダと契約を行うことを意味しており、複数のベンダの製品から構成されるシステムに対してワンストップのサポート窓口が提供される契約形態のことである。
【運用コストへの影響】
サポート契約を行うと運用コストが増大するように感じられるが、問題が発生した際に必要となる費用が膨大となるため、サポート契約を行ったほうが結果として運用コストは小さくなる場合がある。

ハードウェアと同様

  • 小項目「C.5.2 保守契約（ソフトウェア）」では、保守契約を含むソフトウェア (SW) の契約条件に関する要件（方針） を記述します。
    ※　留意事項は、「C.5.1 保守契約（ハードウェア）」と同じなので割愛します。

C.5.3 ライフサイクル期間

小項目 メトリクス(〇: 重要項目)
C.5.3 ライフサイクル期間
運用保守の対応期間および、実際にシステムが稼動するライフサイクルの期間。
 C.5.3.1 ○ ライフサイクル期間
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.5.3.1
○
ライフサイクル期間		 0: 3年
1: 5年
2: 7年
3: 10年以上

【メトリクス】
ここでのライフサイクルとは、次回のシステム更改までの期間と規定している。製品の保守可能期間よりも長い期間のライフサイクルとなる場合は、保守延長や保守可能バージョンへのアップ等の対応が必要となる。

HW/SWのライフサイクルを定義

  • 小項目「C.5.3 ライフサイクル期間」には、システムのライフサイクルの考え方と具体的期間を記述します。
  • ライフサイクルの期間として、少なくとも、ソフトウェア（OS・ミドルウェア・パッケージなど）のバージョンアップタイミングを定める必要があります。
    また、物理的ハードウェアの経年劣化に着目した保守サポート期間に基づく、ハードウェアリプレイスまでの期間も必要となります。

高信頼業務システムにおける課題（「C.3.4 交換用部材の確保」再掲）

  • 特に、金融機関の基幹系システムなど、大量のAP資産を抱える高信頼業務システムでは、製品のバージョンアップに伴うリグレッション試験のコストが非常に大きいため、同一バージョンの製品（特にミドルウェア）を長期間利用する方針が長年採用されてきました。
  • しかし、近年、クラウドの普及により、製品やサービスのサポート期間が短くなる傾向が強まっており、以下のようなシステムライフ自体の概念を再構成する方針も登場しています。
    • システムライフの途中でバージョンアップする
    • CI/CD（継続的インテグレーション／継続的デリバリー）対応により、定期的にバージョンアップと包括パッチを適用する

C.5.4～9　「〇：重要項目」なし

  • 中項目 C.5.4～9 には、ユーザにベンダがシステムもしくは機器やサービスを提供するスキームを前提に、システム構築時からベンダと合意しておくべきサポート関連の要件が挙げられています。
  • なお、高信頼なシステムほど、しっかりしたサポートが必要なので、特に新規ベンダ参画や公開入札の場合、認識齟齬がないよう予めしっかり合意することが重要です。

以降、非機能要求グレードで示されているメトリクスを掲載します

C.5.4 メンテナンス作業役割分担

小項目 メトリクス(〇: 重要項目)
C.5.4 メンテナンス作業役割分担
メンテナンス作業に対するユーザ/ベンダの役割分担、配置人数に関する項目。
 C.5.4.1 　 メンテナンス作業役割分担
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.5.4.1
　
メンテナンス作業役割分担		 0: 全てユーザが実施
1: 一部ユーザが実施
2: 全てベンダが実施

C.5.5 一次対応役割分担

小項目 メトリクス(〇: 重要項目)
C.5.5 一次対応役割分担
一次対応のユーザ/ベンダの役割分担、一次対応の対応時間、配備人数。
 C.5.5.1 　 一次対応役割分担
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.5.5.1
　
一次対応役割分担		 0: 全てユーザが実施
1: 一部ユーザが実施
2: 全てベンダが実施

C.5.6 サポート要員

小項目 メトリクス(〇: 重要項目)
C.5.6 サポート要員
サポート体制に組み入れる要員の人数や対応時間、スキルレベルに関する項目。
 C.5.6.1 　 ベンダ側常備配備人数
C.5.6.2 　 ベンダ側対応時間帯
C.5.6.3 　 ベンダ側対応者の要求スキルレベル
C.5.6.4 　 エスカレーション対応
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.5.6.1
　
ベンダ側常備配備人数		 0: 常駐しない
1: 1人
2: 複数人
C.5.6.2
　
ベンダ側対応時間帯		 0: 対応無し
1: ベンダの定時時間内（9～17時）
2: 夜間のみ非対応（9～21時）
3: 引継ぎ時に1時間程度非対応有り（9～翌8時）
4: 24時間対応
C.5.6.3
　
ベンダ側対応者の要求スキルレベル		 0: 指定無し
1: 有識者の指導を受けて機器の操作を実施できる
2: システムの構成を把握し、ログの収集・確認が実施できる
3: システムの運用や保守作業手順に習熟し、ハードウェアやソフトウェアのメンテナンス作業を実施できる
4: システムの開発や構築に携わり、業務要件やユーザの事情にも通じている
C.5.6.4
　
エスカレーション対応		 0: 指定無し
1: オンコール待機
2: 拠点待機
3: 現地待機

【メトリクス】
障害発生時にエスカレーション対応が必要となるISV/IHV製品に関してエスカレーション先の有識者の待機方法について確認する。

C.5.7 導入サポート

小項目 メトリクス(〇: 重要項目)
C.5.7 導入サポート
システム導入時の特別対応期間の有無および期間。
 C.5.7.1 　 システムテスト稼働時の導入サポート期間
C.5.7.2 　 システム本稼働時の導入サポート期間
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.5.7.1
　
システムテスト稼働時の導入サポート期間		 0: 無し
1: 当日のみ
2: 1週間以内
3: 1ヶ月以内
4: 1ヶ月以上
C.5.7.2
　
システム本稼働時の導入サポート期間		 0: 無し
1: 当日のみ
2: 1週間以内
3: 1ヶ月以内
4: 1ヶ月以上

C.5.8 オペレーション訓練

小項目 メトリクス(〇: 重要項目)
C.5.8 オペレーション訓練
オペレーション訓練実施に関する項目。
 C.5.8.1 　 オペレーション訓練実施の役割分担
C.5.8.2 　 オペレーション訓練範囲
C.5.8.3 　 オペレーション訓練実施頻度
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.5.8.1
　
オペレーション訓練実施の役割分担		 0: 実施しない
1: 全てユーザが実施
2: 一部ユーザが実施
3: 全てベンダが実施
C.5.8.2
　
オペレーション訓練範囲		 0: 実施しない
1: 通常運用の訓練を実施
2: 通常運用に加えて保守運用の訓練を実施
3: 通常運用、保守運用に加えて、障害発生時の復旧作業に関する訓練を実施

【レベル】
通常運用とは、システム基盤に対する通常時の運用（起動・停止等）にかかわる操作を指す。保守運用とは、システム基盤に対する保守作業（部品交換やデータ復旧手順等）にかかわる操作を指す。
C.5.8.3
　
オペレーション訓練実施頻度		 0: 実施しない
1: システム立ち上げ時のみ
2: 定期開催

C.5.9 定期報告会

小項目 メトリクス(〇: 重要項目)
C.5.9 定期報告会
保守に関する定期報告会の開催の要否。
 C.5.9.1 　 定期報告会実施頻度
C.5.9.2 　 報告内容のレベル
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.5.9.1
　
定期報告会実施頻度		 0: 無し
1: 年1回
2: 半年に1回
3: 四半期に1回
4: 月1回
5: 週1回以上

【メトリクス】
障害発生時に実施される不定期の報告会は本メトリクスには含まない。
C.5.9.2
　
報告内容のレベル		 0: 無し
1: 障害報告のみ
2: 障害報告に加えて運用状況報告を行う
3: 障害および運用状況報告に加えて、改善提案を行う

C.6 その他の運用管理方針

中項目「C.6 その他の運用管理方針」では、運用保守フェーズにおける管理に関する要件を定めます。
なお、運用保守フェーズにおけるシステム環境に影響する要件は「C.4 運用環境」に記載します。

「その他の運用管理方針」は、内部統制対応と、6つのITIL[5]の関連項目（ITIL V2のサービスサポート[6]）が小項目となっています。
まず、小項目単位に管理を行うかどうかを確認したうえで、具体的な実現方法まで確認する必要があります。

C.6.1 内部統制対応

小項目 メトリクス(〇: 重要項目)
C.6.1 内部統制対応
IT運用プロセスの内部統制対応を行うかどうかに関する項目。
 C.6.1.1 ○ 内部統制対応の実施有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.6.1.1
○
内部統制対応の実施有無		 0: 内部統制対応について規定しない
1: 既存の社内規定に従って、内部統制対応を実施する
2: 新規に規定を制定し、内部統制対応を実施する

【メトリクス】
ここでは内部統制対応の実施有無について確認する。内部統制対応の具体的な対応方法（オペレーションで実施するか、システムへの機能実装で実現するか等）については、有無の確認後に具体化して確認する。

IT運用プロセスに限定

  • 内部統制対応とは、一般に、業務の正確性・継続性・説明責任を担保するための統制フレームワーク（承認・記録・監査証跡など）に組み込むことを指します。
  • 小項目「C.6.1 内部統制対応」では、対象システムのIT運用プロセスに対する内部統制対応について記述します。
  • 具体的には、ITIL V2で定義されたプロセスに該当する C.6.3～7の管理プロセスに対して、自社・自組織が定める統制フレームワーク（承認・記録・監査証跡など）の適用方針を定めます。
    なお、具体的に必要な対応は、各管理プロセス[C.6.3～7]ごとに定めてください。

C.6.2 サービスデスク

小項目 メトリクス(〇: 重要項目)
C.6.2 サービスデスク
ユーザの問合せに対して単一の窓口機能を提供するかどうかに関する項目。
 C.6.2.1 ○ サービスデスクの設置有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.6.2.1
○
サービスデスクの設置有無		 0: サービスデスクの設置について規定しない
1: 既存のサービスデスクを利用する
2: 新規にサービスデスクを設置する

【メトリクス】
ここでは、ユーザとベンダ間におけるサービスデスクの設置の有無について確認する。サービスデスク機能の具体的な実現方法については、有無の確認後に具体化して確認する。

ITIL V2のサービスサポート

  • C.6.2～7は、ITIL V2のサービスサポート[6:1]で定義された項目が小項目となっており、
    「C.6.2 サービスデスク」がファンクションに該当し、C.6.3～7 がプロセスに該当します。
    各小項目の具体的内容は、ITILを確認してください。
  • なお、「サービスデスク」は、以下の理由から「〇：重要項目」となっています。
    • 運用保守フェーズの体制に直接影響し、ひいてはコストにも影響する
    • 他の管理プロセス[C.6.3～C.6.7]を具体化する際の前提となる

C.6.3～7　「〇：重要項目」なし

  • 中項目 C.6.3～7 には、運用保守フェーズにおける主要な管理（マネジメント）観点が挙げられています。
    各小項目は、ITIL V2のサービスサポートで定義された5つのプロセスに該当します。
  • 企業や部署によって求めるマネジメント水準や管理・報告内容が異なるため、特に新規ベンダ参画や公開入札の場合、認識齟齬がないよう予めしっかり合意することが重要です。

各小項目の具体的内容は、ITIL V2[6:2]を確認してください。
以降、非機能要求グレードで示されているメトリクスを掲載します。

C.6.3 インシデント管理

小項目 メトリクス(〇: 重要項目)
C.6.3 インシデント管理
業務を停止させるインシデントを迅速に回復させるプロセスを実施するかどうかに関する項目。
 C.6.3.1 　 インシデント管理の実施有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.6.3.1
　
インシデント管理の実施有無		 0: インシデント管理について規定しない
1: 既存のインシデント管理のプロセスに従う
2: 新規にインシデント管理のプロセスを規定する

【メトリクス】
ここでは、当該システムで発生するインシデントの管理を実施するかどうかを確認する。インシデント管理の実現方法については、有無の確認後に具体化して確認する。

C.6.4 問題管理

小項目 メトリクス(〇: 重要項目)
C.6.4 問題管理
インシデントの根本原因を追究し、可能であれば取り除くための処置を講じるプロセスを実施するかどうかに関する項目。
 C.6.4.1 　 問題管理の実施有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.6.4.1
　
問題管理の実施有無		 0: 問題管理について規定しない
1: 既存の問題管理のプロセスに従う
2: 新規に問題管理のプロセスを規定する

【メトリクス】
ここでは、インシデントの根本原因を追究するための問題管理を実施するかどうかを確認する。問題管理の実現方法については、有無の確認後に具体化して確認する。

C.6.5 構成管理

小項目 メトリクス(〇: 重要項目)
C.6.5 構成管理
ハードウェアやソフトウェアなどのIT環境の構成を適切に管理するためのプロセスを実施するかどうかに関する項目。
 C.6.5.1 　 構成管理の実施有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.6.5.1
　
構成管理の実施有無		 0: 構成管理について規定しない
1: 既存の構成管理のプロセスに従う
2: 新規に構成管理のプロセスを規定する

【メトリクス】
ここでは、リリースされたハードウェアやソフトウェアが適切にユーザ環境に構成されているかを管理するための構成管理を実施するかどうかを確認する。構成管理の実現方法については、有無の確認後に具体化して確認する。

C.6.6 変更管理

小項目 メトリクス(〇: 重要項目)
C.6.6 変更管理
IT環境に対する変更を効率的に管理するためのプロセスを実施するかどうかに関する項目。
 C.6.6.1 　 変更管理の実施有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.6.6.1
　
変更管理の実施有無		 0: 変更管理について規定しない
1: 既存の変更管理のプロセスに従う
2: 新規に変更管理のプロセスを規定する

【メトリクス】
ここでは、ハードウェアの交換やソフトウェアのパッチ適用、バージョンアップ、パラメータ変更といったシステム環境に対する変更を管理するための変更管理を実施するかどうかを確認する。変更管理の実現方法については、有無の確認後に具体化して確認する。

C.6.7 リリース管理

小項目 メトリクス(〇: 重要項目)
C.6.7 リリース管理
ソフトウェア、ハードウェア、ITサービスに対する実装を管理するためのプロセスを実施するかどうかに関する項目。
 C.6.7.1 　 リリース管理の実施有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.6.7.1
　
リリース管理の実施有無		 0: リリース管理について規定しない
1: 既存のリリース管理のプロセスに従う
2: 新規にリリース管理のプロセスを規定する

【メトリクス】
ここでは、承認された変更が正しくシステム環境に適用されているかどうかを管理するリリース管理を実施するかどうかを確認する。リリース管理の実現方法については、有無の確認後に具体化して確認する。

あったら怖い本当の話

※　実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。

😱商用開始後いきなりバスタブ

  • 社会インフラ級の重厚長大システム更改、リスク回避のため多段階リリース。
  • 大きなトラブルもなく、最終移行もつつがなく完了し、安定稼働していました。

Vol.11 バスタブ曲線と保守サポート期間

敗因

  • 特別延長保守によるハードウェアの延命は原則避けるべきでした。
    • 商用ライフ期間中の保守切れを防ぐために、特別延長保守契約を締結していました。
      しかし、最終移行時にはすでに摩耗故障期の直前に差し掛かっていました。
    • 摩耗故障期に入ると相応にハード故障が増加、ヒヤリハット（ハインリッヒの法則）的に故障時に想定外の挙動も起きており、重大事故に相当する長時間停止を招きました。

再発防止

  • ベンダが定める通常保守サポート期間内に、ハードウェアの交換・ソフトウェアのバージョンアップを計画的に実施することを徹底しました。
  • 例外として、ハードウェアを特別延長保守で使用する場合は、製造元ベンダが提供する分解清掃による内部点検・整備を必須としました。
    ※分解清掃費用は、新規購入費用よりも高価となることがある点に注意

閑話休題：ハインリッヒの法則

1つの重大事故の背後には数10の軽微な事故があり、その背景には数百の異常（ヒヤリハット）が存在するという経験則。

以下にハインリッヒの法則とその後の代表的な研究を示します。
なお、比率の数字は各論あるため参考程度に。

  • ハインリッヒの法則 (1:29:300)
    1929年発表、労働災害における経験則の一つ。
    1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常（ヒヤリ・ハット）が存在する
  • バードの法則 (1:10:30:600)
    1969年発表、アメリカの21業種297社1,753,498件のデータから導出。
    ニアミス600:物損事故30:軽傷事故10:重大事故1、の比が成り立つ
  • タイ=ピアソンの結果 (1:3:50:80:400)
    1974‐1975年にイギリスの保険会社のデータ約100万件からTyeおよびPearsonにより導出。
    ニアミス400:物損事故80:応急処置を施した事故50:軽中傷事故3:重大事故1、の比が成り立つ

まとめ

本記事では、システムのライフサイクルは製品・サービスの保守サポート期間内におさまるよう計画する必要があることを説明しました。
また、ITIL V2のサービスサポート[6:3]に即して、運用保守フェーズに必要となる対応を示すことを説明しました。

最後に、NTTデータの金融高度技術本部では、ともに金融ITの未来を切り拓く仲間を募集しています。

[募集要領]
https://nttdata-career.jposting.net/u/job.phtml?job_code=1172
[NTTデータ 金融分野の取り組み]
https://www.nttdata.com/jp/ja/industries/finance/

脚注

  1. IPA（独立行政法人 情報処理推進機構, Information-technology Promotion Agency, Japan） ↩︎

  2. 非機能要求グレード:
    参照用pdf: 非機能要求グレード2018 改訂情報(PDF:897 KB)
    活用用xls: 非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の　06‗活用シート.xls ↩︎

  3. 重要項目 引用元1：
    非機能要求グレード 2018 利用ガイド［解説編］P17
    2 非機能要求グレードの詳細説明　2.1.1 グレード表　（５）重要項目選択の経緯：
    項目一覧は非機能要求項目をリストアップしたツールで 238 メトリクスがある。
    これらのメトリクスには決定順序が異なるものやシステム基盤のコストに対する影響度合が異なるものなどがあり、何らかのグルーピングが必要である。
    更に、項目数が多すぎて検討に時間がかかるといった点も考慮し、メトリクスを選択している。
    これを重要項目と定義する。重要項目の選択にあたってはコストや品質に影響を与える度合が大きいメトリクスをユーザ視点とベンダ視点の両面から評価し選択している。 ↩︎

  4. 重要項目 引用元2：
    非機能要求グレード 2018 利用ガイド［解説編］P19　
    2 非機能要求グレードの詳細説明　2.1.2 項目一覧 （２）項目一覧構成列の説明　（ｇ）重要項目：
    非機能要求を検討する上で品質やコストに大きな影響を与える項目。
    重要項目として選択された項目はグレード表を構成する項目として使用している。 ↩︎

  5. ITIL: Information Technology Infrastructure Library
    改版経緯　1989年:ITIL 初版、2001年:ITIL V2、2007年 ITIL V3、2019年 ITIL 4
    非機能要求グレードの初版が作成された時期(2009)は、ITIL V3が出ていたが、当時普及していたITIL V2の定義が採用されている。 ↩︎

  6. ITIL V2のサービスサポート: ファンクションとして「サービスデスク」、
    プロセスとして「インシデント管理」「問題管理」「構成管理」「変更管理」「リリース管理」が定義されている。 ↩︎ ↩︎ ↩︎ ↩︎

NTT DATA TECH
NTT DATA TECH

NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。

設定によりコメント欄が無効化されています