本文へジャンプ

ソフトウェア > Rational > Rational Developer Domain > Rationalソリューション >

コンプライアンスの管理:ITフレームワークの概要

 
Rational software
レベル: 入門者向け
     
発表日:2006年04月11日
Judith Myerson j.myerson@ieee.org
Software Verification Developer、IBM
インデックス
概要
はじめに
標準フレームワーク
フレームワークの比較:貴社にとって最適なのは
独自フレームワークの開発:その可能性
プロセス成熟度の取り組みの成功度を評価する Rational ツール
まとめ
 
概要
ITフレームワークとはどのようなもので、規制要件を満たすためのビジネス・プロセスはITフレームワークによってどのように規定されるのか、知りたくはありませんか。

この記事では、Judith M. Myersonが標準フレームワークの概要説明と比較を行い、フレームワークのカスタマイズ方法を紹介します。また、フレームワークで規定されるビジネス・プロセスを自動化するにはRational Portfolio Manager(以下、RPM)やRational Method Composer(以下、RMC)などのツールが必要ですが、その理由についても説明します。Rationalツールをこのコンテキストで使用する方法と、個々のフレームワークの詳細については、後続の記事で取り上げる予定です。
 
上に戻る
 
はじめに
大企業や中堅企業を含む株式公開企業は、財務管理の規制要件(サーベンス・オクスリー [SOX] 法やバーゼルIIなど)に順守することを目的としたさまざまな規模のITプロジェクトを、それぞれのタイミングで開始しています。プロジェクトの成果を左右する主な要因は、合法的管理を行うに当たって規制の文言をどのように解釈するのかという点と、技術的問題、管理要件、ビジネス・リスクなどの間に横たわるギャップを埋めることに対してどれほどオープンな企業文化が存在するのかという点にあります。

どれだけ迅速に欠陥を修正すべきかは規制ごとに異なるほか、個々の規制の解釈や施行方法によっても変わります。規制順守を進めるに当たって、企業はさまざまな問題を解決しなければなりません。例えば、ポートフォリオに含まれる複数のプロジェクトに対して適用すべきガバナンス・コントロール、プロジェクト依存関係の複雑さ、個々のユニットで使用される組織スタイル、あるいは各プロジェクトの成熟状況を追跡するためのメカニズムなどが問題となります。

期限内にプロジェクトを完了しようとしたときに企業が直面する課題は2つあります。第1の課題は、どのようなITフレームワークを使用すれば企業ポートフォリオに含まれるコンプライアンス・プロジェクトや管理プロジェクトの進捗状況を追跡できるのかを検討することです。第2の課題は、そういった新たなフレームワークを経済的かつ持続可能な方法で実装するには、どのように自動化し、どのように統合すればよいのかを検討することです。
 
上に戻る
 
標準フレームワーク
通常、成熟度モデルが示すのは、より未熟な状態での組織の基本機能(組織レベルやプロセス・レベル)と、より成熟した状態に達するために組織が必要とする追加機能です。標準フレームワークのすべてが成熟度モデルになるわけではありません。また、標準フレームワークを手法(またはツール)と見なすべきではありません。

成熟度モデルを使用すれば、プロセスの改善が必要な領域を組織が容易に特定し、評価できるようになります。成熟度を高めるために、組織は目標を達成するための必要措置を講じます。組織が目標を達成すると、評価結果の集計と複数プロジェクト間の比較が1つのレーティングとして示されます。成熟度モデルはすべて、段階表現の形式になっています。それぞれの段階は、プロセス改善の進化過程における成熟度レベルを示します。モデルは基本的なマネジメント作業から始まり、複数のレベルを連続的に通過します。どの段階も省略することはできません。

それでは、実際の標準フレームワークを見てみましょう。

  1. OPMMM(OPM3®):Organizational Project Management Maturity Model
  2. CMMI®:Capability Maturity Model Integration
  3. ITIL®:IT Infrastructure Library
  4. COBIT®:Control Objectives for Information Related Technology
  5. Six Sigma(Motorola, Inc. の登録商標)

OPM3とCMMIは段階表現の成熟度モデルです。CMMIでは、別の表現形式(連続)も提供されます。ITILは成熟度モデルではなく、カスタマイズ可能なベスト・プラクティスのフレームワークです。COBITの成熟度モデル・コンポーネントは、ITILの実装を確認するために使用することも可能です。Six Sigmaは成熟度モデルではなく、プロセス成熟度モデルを内包するものでもありません。プロセスを管理するための手法です。Six Sigmaは連続的改善に対する測定メカニズムを備えているため、CMMIの採用を促進するものとして知られています。 OPM3はProject Management Institute®(以下、PMI)によって開発されたものです。これを使用すれば、組織内のポートフォリオに含まれる複数のプロジェクトに対して組織がどの程度適切に戦略を実施しているかが判明します。その対象は、プロジェクトと戦略優先度とを整合させる作業から、プロジェクト環境を実現するインフラストラクチャーに至るまで、多岐にわたります。ポートフォリオに含まれるプロジェクトやプログラムは、相互に依存・関連しているとは限りません。この環境に関するプロジェクトとしては、4つのタイプ(戦略的プロジェクト、運用プロジェクト、増資プロジェクト、製品・市場関連プロジェクト)があります。財務管理は運用プロジェクトのカテゴリーに分類されます。またPMIは、プロジェクト・マネジメントのベスト・プラクティスに関する知識体系として記述された、Project Management Body of Knowledge(以下、PMBOK®)というフレームワークも提供しています。

CMMIは、カーネギーメロン大学のソフトウェア・エンジニアリング研究所が1991年に公開した統合モデル・セットです。これには、1つのプロジェクト内、1つの部門内、または組織全体のプロセス改善に関連した、さまざまなイニシアチブ(ソフトウェア開発、システム・エンジニアリング、製品およびプロセスの統合開発、人員など) が統合されています。

OPM3と同様にCMMIにも、初期プロセス、反復可能プロセス、定義済みプロセス、マネージド・プロセス、最適化プロセスという5つの成熟段階が設定されています。CMMIがOPMMMと異なるのは、(成熟度レベルと同じく)6つの機能レベルも設定されていて、機能レベルと成熟度レベルの両方について2種類の表現形式(段階表現と連続表現)が可能な点です。

英国政府機関CCTA(中央コンピューター電気通信局:Central Computer and Telecommunications Agency)が作成したITILは、ITサービス・マネジメントのベスト・プラクティス標準であり、企業が自社のITプロセスを文書化する際に役立ちます。なお、CCTA は現在では、OGC(商務局: Office of Government Commerce)に統合されています。ITILは、SOX法などの規制を順守するために必要となるデータを評価・追跡する、反復可能、監査可能、検証可能な作業を定義していますが、ITIL自体は成熟度モデルではありません。

ITILは一連のセットで構成されており、2つの主要領域(サービス・サポートとサービス・デリバリー)に分かれています。サービス・サポート・セットには、発生事象マネジメント、問題マネジメント、コンフィギュレーション・マネジメント、変更マネジメント、リリース・マネジメントが含まれます。サービス・デリバリー・セットには、サービス・レベル・マネジメント、財務マネジメント、キャパシティー・マネジメント、可用性マネジメント、コンティニュイティー・マネジメントが含まれます。

COBITがITGI(IT ガバナンス協会:IT Governance Institute®)によって初めて定義されたのは1996年のことです。COBIT は、情報およびその作成・保存・操作システムに対して適切な管理とガバナンスが提供するための、IT ガバナンス・フレームワークです。これにより、SOX法などの規制に確実に順守できるような管理体制が整っているかどうかが検証されるほか、財務管理を行う上でのさまざまなギャップ(管理要件、技術的問題、ビジネス・リスク、パフォーマンス測定要件などのギャップ)が解消されます。COBITコンポーネントのうちの2つに、管理目標と成熟度モデルがあります。

Six Sigmaは成熟度モデルではなく、プロセス成熟度モデルを内包するものでもありません。Six Sigmaは連続的改善に対する測定メカニズムを備えているため、CMMIの採用を促進するものとして知られています。Six Sigmaは、あらゆるプロセスの欠陥を取り除くための、統制の取れたデータ駆動型アプローチ(手法)です。このアプローチでは、平均値とそれに最も近い制限値(お客様が指定)との間の標準偏差が使用されます。
 
上に戻る
 
フレームワークの比較:貴社にとって最適なのは
では、フレームワークを比較するにはどのような種類の基準を使用すべきでしょうか。どのようなコンプライアンスを組織が選択したか(または義務付けられているか)によって、状況は異なります。おそらくご存じのように、SOX法は一般企業や株式公開企業を対象として財務管理の内部プロセスを規定したものですが、バーゼルIIは国際的な銀行コミュニティーに適しています。1996年に制定されたHIPAA(医療保険の相互運用性と説明責任に関する法律: Health Insurance Portability and Accountability Act)では、医療用電子データの交換に標準規格を使用することが義務付けられるとともに、患者、サービス提供者、費用負担者を特定するためのIDシステムを全国的に導入することが求められています。また21CFR11は、米国FDA(食品医薬品局:Food and Drug Administration)が定めた規則です。

どのフレームワークを選択するかは、組織のポートフォリオにおいてプロジェクトがどの程度適切に管理されているか、あるいはソフトウェア開発、システム・エンジニアリング、製品統合などの必要性があるかどうかなどによっても左右されます。また、プロセス優先度の設定方法や、フレームワークの成熟段階に到達するためのプロセス改善アプローチとして段階表現と連続表現のどちらを選択するかということも、フレームワークの選択に影響します。しかしすべての中で最も重要なのは、組織の文化がフレームワークの実装にどのような影響を及ぼすのか、そして、管理体制やプロジェクトを組織の戦略目標と整合させるためにその文化を変更する必要性があるのかという点です。

フレームワークを比較する際には、フレームワークとそのプロセス(各フレームワークで取り扱うプロセス)の間にどのような重複や相違があるのかを見極める必要があります。ここでは、COBITのドメインを、PMBOK、CMMI、ITILとの比較基準として使用しましょう。 各ドメインはさらに複数のプロセスに分類されます。COBITでは、以下のドメインが定義されています。

  • PO(計画と組織:Plan and Organize)
  • AI(調達と実装:Acquire and Implement)
  • DS(デリバリーとサポート:Deliver and Support)
  • ME(モニターと評価:Monitor and Evaluate)

「COBITマッピング: 国際的ITガイダンスの概要(COBIT Mapping: Overview of International IT Guidance)」の第2版によると、DSドメインでは、COBITプロセスの要件を解決するのは通常はITILであり、OPM3やCMMIが解決することはほとんど(あるいは一切)ありません。PO ドメインでは、COBITプロセスの要件を解決するのは一般にITILとPMBOKであり、CMMIが解決することはめったに(あるいは一切)ありません。AIドメインでは、COBITプロセスの要件を解決するのは通常は CMMIですが、ITILが解決する場合もあります。ただし、PMBOKが解決することは一切ありません。MEドメインでは、COBITプロセスの要件を解決するのは一般にCMMIであり、ITILとPMBOKが解決することはめったに(あるいは一切)ありません。ただし、この3つのフレームワークを比較したドメイン・ランキングは、ドメイン内の個々のプロセスに対するランキングを集計したものなので、ご注意ください。
 
上に戻る
 
独自フレームワークの開発:その可能性
既存のITフレームワークに含まれない特定クラスのプロセスを取り扱うために、独自のフレームワークを開発したい場合は、目的のフレームワークが成熟度モデルとプロセス・セットのどちらなのかを指定する必要があります。ただし、コンプライアンスを実現するまでの期限が決まっている、リソースが限られている、トリガー・メカニズム(開発中にリスク・イベントが発生したことを通知するメカニズム)が欠如しているといった制約がある場合は、標準フレームワークをそのまま使用するか、IBMビジネスコンサルティングサービスにフレームワークの構築を依頼するほうがよいでしょう。

選択したフレームワークを組み合わせれば、フレームワークをカスタマイズすることができます。フレームワークをカスタマイズする際には、現状を確認するための変更管理プロパティーを定義する必要があります。まずプロセスのワークフローと用語における重複や相違点を見つけ出し、次に、ベースとするプロセス標準の欠陥を探して、それ以外のプロセス標準でその欠陥部分を埋めます。その後、カスタム・フレームワークのワークフローを確認しながら、構築を進める必要があります。
 
上に戻る
 
プロセス成熟度の取り組みの成功度を評価するRationalツール
RPMを使用すれば、上記のフレームワークによって規定されるあらゆるビジネス・プロセスを定義し、体系化し、自動化することができます。RMCで作成されたテンプレートは、フレームワーク・プロセスに従うためのガイドラインとして機能します。またPortfolio Managerのワークフローがあれば、繰り返し発生する離散プロセスを自動化し、規制要件の順守に対する監査を実施できます。
このシステムには、プロジェクト・レベル、ポートフォリオ・レベル、およびエンタープライズ・レベルでリスク・マネジメントを実施できるように、フレームワーク(COSO II)が装備されています。リアルタイム・アクセスを実現しながら直ちに結果を提供できる集中型システムは、プロセスの測定・管理という面において、担当チームにとってもエグゼクティブにとっても有用です。
 
上に戻る
 
まとめ
RPMで自動化することのできるビジネス・プロセスをどのフレームワークで記述するかを選択する際には、事前の計画が求められます。システム管理者、ビジネス・アナリスト、開発者などで構成されるチームとコミュニケーションを図り、「システムやフレームワークの過負荷を引き起こすことなく、技術的問題、ビジネス・リスク、コンプライアンス要件の間のギャップを解消する」という課題について慎重に話し合う必要があります。

特に、複数の財務管理プロジェクトを抱えている場合や何らかの制約(例:リソースが限られている、コンプライアンスを実現するまでの期限が決まっているなど)がある場合、この種の課題が解決されれば、はるかに作業が容易になります。課題を解決することがソフトウェア開発プロジェクトの管理容易化につながることを、管理者は実感できることでしょう。今後の記事では、ビジネス・プロセスで必要とされている管理をIBM Rational ツールによって自動化する方法を検討します。この方法は、コンプライアンス要件を順守しながら、より簡単かつ効率的にプロセスを管理していく上で役立ちます。
 
上に戻る
 
参考文献
学ぶために

  Rational Portfolio Managerについては、Michael F. Hanford 著の入門記事、「Introduction to Portfolio Management(US)」および「Portfolio Management Essentials(US)」をお読みください。
  Rational Portfolio Managerの詳細については、developerWorks の「Rational Portfolio Manager(US)」のページをご覧ください。
  COBITの詳細については、ITGI の Web サイトをご覧ください。
ITGI(US)
  CMMI の詳細については、カーネギーメロン大学ソフトウェア・エンジニアリング研究所のWebサイトをご覧ください。
カーネギーメロン大学ソフトウェア・エンジニアリング研究所(US)
  ITIL の詳細については、「ITIL and IT Service Management」のWebサイトをご覧ください。
ITIL and IT Service Management(US)
  OPM3の詳細については、Project Management Institute のWebサイトに掲載されているFAQをお読みください。
Project Management Institute(US)
  Six Sigmaの詳細については、モトローラ大学のWebサイトをご覧ください。
モトローラ大学(US)
  この記事の関連トピックや他の技術トピックに関する書籍は、Safariのオンライン書店で検索していただけます。
Safariのオンライン書店(US)


製品や技術を入手するために

  Rational Portfolio Managerの機能、システム要件、購入情報などについては、Rational Portfolio Managerの製品ページを参照してください。
  Rational Method Composerの機能に関して詳細な情報が必要な場合は、Rational Method Composerの製品ページから入手してください。


議論するために

  developerWorks → RationalのRational Portfolio Managerディスカッション・フォーラム(US)を覗いてみてください。
  Rational Global User Group Communityで、自社の領域に該当するユーザー・グループを探してください。Rational User Groupsはユーザーが運営する独立組織であり、お客様とRationalスタッフの間の情報交換を促すオープンなフォーラムを提供しています。
Rational Global User Group Community(US)
 
上に戻る
 
執筆者について

Judith M. Myersonは、システム・アーキテクト兼システム・エンジニアです。専門分野は、ミドルウェア・テクノロジー、エンタープライズ規模のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク・マネジメント、セキュリティー、およびプロジェクト・マネジメントです。

 

Copyright© International Business Machines Corporation, 2007. All rights reserved.
本記事は、全部または一部をIBM社の事前の書面による許可なしに複製することはできません。本書の内容は、予告なく変更されることがあります。

本書の内容および関連する RationalソフトウェアはIBMかそのライセンス管理者、またはその両者の所有物であり、米国著作権法、特許法、その他の国際条約により保護されています。一部または全部を複製することは禁じられています。本書またはソフトウェアの追加の複製に関しては、IBMにお問い合わせください。
IBM、IBMのロゴ、Rational、Rationalのロゴ、Rational Portfolio Manager、Rational Method Composerは、IBM Corporationの米国およびその他の国における商標または登録商標です。
ITILは英国Office of Government Commerceの登録商標および共同体登録商標であって、米国特許商標庁にて登録されています。
IT Infrastructure Libraryは英国Office of Government Commerceの一部であるthe Central Computer and Telecommunications Agencyの登録商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。

 
上に戻る
 
 
 
上に戻る
 
レベルマークについて

このページで紹介されている情報はレベル別にカテゴライズされています。

上級者向け
中級者向け
初級者向け
入門者向け