ITシステムライフサイクルおよび変更管理に対するリスクベースアプローチ
掲載：2010年12月05日
執筆者：取締役副社長 兼 プリンシパルコンサルタント 勝俣 良介
コラム
情報システムコントロール協会（ISACA）は毎月、世界中のセキュリティ専門家からの寄稿をまとめたセキュリティジャーナルを発行しています。この機関誌はISACAの会員になることで読むことができますが、今回は、寄稿記事の中（2010年Volume5）から、Loic Jegoussee氏の書いた”Risk-based approach to IT Systems Life Cycle and Change Control（ITシステムライフサイクルおよび変更管理に対するリスクベースアプローチ）”の記事について、その概要をご紹介いたします。どうぞ、ご興味をもたれた方は会員になって詳細をご覧になってみてください。
大きな課題を持つリスクマネジメント
企業においてITシステムに関わるリスクを特定し、適切なコントロールを導入・運用するというアプローチは、いまや、極めて一般的です。リスクマネジメントに関わる、どのような法規制・規格（例：バーゼルII、SOX、ISMSなど）を見ても、その考え方に違いはありません。著者のJegoussee氏は、この点について、「リスクを特定していく作業は、有効性・効率性・正確性の観点で大きな課題が残る」と指摘しています。正確性という観点1つとってみても「たとえば、発生可能性という点で人は、過去にあまり経験したことのないリスクに対しては、過小評価する（これからも滅多なことでは起こらないだろう・・・と信じる）傾向が強いではないか」と述べています。地震による被災を経験したことのない組織ほど、BCPへの意識が低い、という事実と似ているのかもしれません。
さて、このような課題に対してJegoussee氏は、特に変更管理（ITサービスの品質を保つために、本番環境に加えられる変更のコントロールを行う仕組み）をテーマとして取り上げながら、一つのヒントを提示しています。
さて、このような課題に対してJegoussee氏は、特に変更管理（ITサービスの品質を保つために、本番環境に加えられる変更のコントロールを行う仕組み）をテーマとして取り上げながら、一つのヒントを提示しています。
変更管理におけるリスクアセスメントと課題
変更管理（ITサービスの品質を保つために、本番環境に加えられる変更のコントロールを行う仕組み）におけるリスクアセスメントは、一般的に、ITシステムの変更申請（例：新しいソフトウエアをサーバにインストールする、など）があった際に、その申請を、マネジメントが妥当性・適切性の観点から、認めるべきかどうかの判断をする際に行うものです。
IT運用管理のベストプラクティス集であるITILでは、変更申請の内容に応じてCAB（変更諮問委員会）などの組織を設けて評価することを薦めていますが、ここに組織が抱えやすい大きな課題があります。たとえば、膨大な変更申請が日々行われる企業であったとしたらどうでしょうか。1件2件程度の変更申請であれば、その都度CABを招集して評価することも現実的でしょうが、これが50件、60件となった場合、たとえ1週間に1回CABを招集してまとめて評価することになっていたとしても、なかなか、サステイナビリティ（持続可能性）という観点では現実的なコントロールであると言うことはできません。
IT運用管理のベストプラクティス集であるITILでは、変更申請の内容に応じてCAB（変更諮問委員会）などの組織を設けて評価することを薦めていますが、ここに組織が抱えやすい大きな課題があります。たとえば、膨大な変更申請が日々行われる企業であったとしたらどうでしょうか。1件2件程度の変更申請であれば、その都度CABを招集して評価することも現実的でしょうが、これが50件、60件となった場合、たとえ1週間に1回CABを招集してまとめて評価することになっていたとしても、なかなか、サステイナビリティ（持続可能性）という観点では現実的なコントロールであると言うことはできません。
ビジネス vs. コンプライアンス
変更管理における、効果的・効率的なリスクアセスメントの方法として、Jegoussee氏は、たとえば「ビジネスとコンプライアンスという2大観点による評価を用いてはどうか」と提示しています。つまり、ビジネスとコンプライアンスを軸に変更申請内容の重要性を定義し、その結果、特定された重要度に応じて（重要度が低いものであれば低いものであるほど）簡略化したプロセスを経るような仕組みを設ける、という意味です。（例：承認を省くなど）
なお、ここでビジネスの観点とは、主として、その変更を認めないことによりどれだけの組織の生産性や財務、訴訟や評判が損失が出る可能性があるのか？ということを指し、コンプライアンスの観点とは、その変更を認めないことによりどれだけコンプライアンスを満たせないことになるのか？ということを指します。
なお、ここでビジネスの観点とは、主として、その変更を認めないことによりどれだけの組織の生産性や財務、訴訟や評判が損失が出る可能性があるのか？ということを指し、コンプライアンスの観点とは、その変更を認めないことによりどれだけコンプライアンスを満たせないことになるのか？ということを指します。
チャートや表を上手に活用
変更作業要件表とは、たとえば「変更作業を行う際には正式なテストを要求するのか？」とか「変更申請には、より詳細なプランを記述した変更申請書を要求するのか？」などといったプロセスに関わる要件を示したものです。
あらゆる場面に使えるアプローチ
このようにいくつかの観点、チャートやテーブルなどを活用することにより、効果的な変更管理プロセスを構築することが可能になるわけですが、この記事で示されているチャートや表はあくまでも１つの例です。ここで最も重要なことはリスクアセスメントを考えるにあたり、ビジネスとコンプライアンスという2つの観点を取り入れること、そして、そこから得られたリスクレベルを元に、コントロールの程度を変化させること、ということです。Jegoussee氏自身認めていますが、この考え方は、何も変更管理のみに当てはまるわけではなく、ビジネスプロセスのあらゆる場面に活用できる考え方であるということができます。
